Wikipedia:Village pump (proposals)/Archive 147

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

---

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Wikipedia:Wikidata/2018 Infobox RfC

An RfC on the use of Wikidata in infoboxes has just started. Please !vote and/or comment on the RfC page. Thanks. Mike Peel (talk) 20:46, 6 April 2018 (UTC)

Back-tagging STiki edits (1,000,000+ revisions)

Noting here that backtagging is (or probably should be) blocked by phab:T185355. Further discussion is of course still welcomed :) — MusikAnimal ^talk 05:09, 9 April 2018 (UTC)

---

Hello! First to give some background... I requested that STiki start tagging edits, much like is done with Huggle and other popular off-wiki software. The author of STiki, West.andrew.g, was in favour and I think we're good to go for tagging STiki edits moving forward.

We also pondered at the idea of back-tagging edits made with STiki. I'm generally in favour, as this would make the tag data complete (in particular, this is useful for database reports and analysis). Wikipedia:Tags states "tags cannot be added to revisions yet", but it appears there is now an API endpoint for this. That same information page links to this December 2014 discussion, which seems to give consensus for bot-tagging of edits, subject to individual bot approval.

Meanwhile, Special:Log/tag is nearly empty. This tells me either folks are either unaware that tagging existing revisions is now possible, or consensus has changed. I can't find any evidence of the latter.

So, on behalf of West.andrew.g, I'm proposing we do this for STiki. The thing that is controversial is that there are over a million edits made with STiki. Mass-tagging would certainly pollute Special:Log. I think if the bot task is throttled, say, at 100 revisions a minute, this shouldn't really be that disruptive, and only take around a week to complete.

I'm personally a bit torn myself on whether this is a sane idea... mainly because of the volume of edits. I realize the benefit also isn't far-reaching, but it is of use. For instance XTools has the capability of identifying edits made with specific tools, and listing non-automated contributions, using tags or regular expressions. The latter does work to some degree (searching for edits with "using STiki" in the summary), but this is slow and not comprehensive because anyone can remove the STiki advert from the edit summary. The tag filter at Special:Contributions I'm sure will also be useful.

Thoughts? — MusikAnimal ^talk 17:45, 6 April 2018 (UTC)

No thank you! Adding a million log entries just for tagging ancient page versions? I'm not seeing how this will make our encyclopedia better - it certainly doesn't help anything for the readers. If this was really that important a one-time database update may be preferable. As for the mechanics of actually doing what you propose - are you going to rely on edit summaries to identify these edits? — xaosflux ^Talk 17:52, 6 April 2018 (UTC)

Logging is mainly for internal use, it wouldn't benefit readers even if it were a single revision. This is more for the data hungry people, and those who appreciate such statistics, which I realize probably isn't many :) I believe West.andrew.g has been keeping track of STiki edits in his own database, but he'll have to confirm. I had doubts back-tagging this many revisions was good idea (or of interest to many people), but I didn't think it was a bad one either. Andrew asked me to make the proposal, so here I am. WP:DWAP I think applies, especially since MediaWiki is now auto-tagging reverts and the like. And Enwiki's logging isn't that large compared to some other wikis with recent changes patrolling enabled (phab:T184485). Nonetheless, a million rows indeed is a lot! — MusikAnimal ^talk 18:14, 6 April 2018 (UTC)

Err, and actually STiki edits for each user are already counted at Wikipedia:STiki/leaderboard. So that much is moot, but the concept of viewing non-automated edits, and browsing STiki edits at Special:Contribs still stands. Frankly, overall I'd like to see everything that tags be backfilled (though I know that won't happen). Some things like identifying old reverts aren't possible, but it'd be neat if it was. It's a shame we have the capability of identifying such edits, but the data is incomplete. — MusikAnimal ^talk 18:27, 6 April 2018 (UTC)

But if the edits are known already, doesn't xaosflux's proposal make more sense? DWAP or not, do we actually need to add a million log entries if the only thing that people really want is to be able use the tags for those edits? Regards SoWhy 18:38, 6 April 2018 (UTC)

Yes certainly, but we (the community) aren't capable of doing direct database updates without going through the API, and hence creating log entries. Sysadmins definitely aren't going to grant a request to do this for something as unimportant as STiki tags. In my opinion creating all those log entries sounds worse than it really is, but probably worth running by the DBAs... especially if we wanted to backfill other things. I wasn't following the phab discussions for the MediaWiki auto-tagging of reverts/redirects, but I suspect backfilling would have been desirable there too, except that it isn't feasible. Especially redirect tagging, since that offers a more efficient way of detecting articles created from redirects, and by whom (currently only temporarily available through mw:Extension:PageCuration tables) — MusikAnimal ^talk 18:58, 6 April 2018 (UTC)

I'm all for this; given that nearly every damn phone edit has mobile edit (13 million and counting) in addition to either the mobile web edit or mobile app edit tag, I don't think tagging stiki is going to overwhelm anything. It's useful, and having better metadata will mean being better able to use metadata. Still, by the same rationale, should we not backtag huggle (1.1 million currently) or AWB (a laughable 13 thousand), or even twinkle (god forbid)? ~ Amory (u • t • c) 18:57, 6 April 2018 (UTC)

If we want to discuss backtaging things in general I can think of much more relevant things like "uploaded edit", "transwiki import", even "bot". — xaosflux ^Talk 18:59, 7 April 2018 (UTC)

Are those tags? I don't see them at Special:Tags. But yes, I'm glad this came up, because maybe we should consider backtagging everything (though I agree STiki isn't the top priority). The tagging feature is there for a reason, so I don't see why we shouldn't take advantage of it. From an analytics perspective, the incomplete data is a problem. I am going to try to talk to a DBA about this to see if the effect on logging is anything meaningful, along with backtagging that many edits in general. Database consumption aside, are there other concerns? Is that we don't want to see all those entries at Special:Log? It's unlikely, but possible, that we can use a maintenance script so that no log entries are created. — MusikAnimal ^talk 23:27, 7 April 2018 (UTC)

@MusikAnimal:, not yet....phab:T183061...... — xaosflux ^Talk 14:26, 8 April 2018 (UTC)

I would like to see all edits from the major scripts/tools properly tagged with Special:Tags (not just an edit summary that I could, um, "accidentally" change). AWB just started tagging edits a few weeks ago, but only for people using the latest software version. It would be nice to expand this, so more editors could find out how other people are being so productive.

I'd also like to see tags on all script-based edits, i.e., the ones that aren't using the major tools. Someone replaced the contents of thousands of pages at multiple wikis with basically "testtesttesttest" last week – thousands of pages basically blanked within minutes. IMO every single one of those would ideally have come with Special:Tags that broadcast "Hey, I am NOT a fully manual edit" to any person who even glanced at Special:RecentChanges. WhatamIdoing (talk) 04:52, 8 April 2018 (UTC)

For the record, that proposal has seen extensive discussion at phab:T188433. Anomie⚔ 22:47, 8 April 2018 (UTC)

This thread was originally about back-tagging STiki edits, but I think now we're all wondering about back-tagging everything (at least tools that can easily be identified). It's worth pursuing, getting broader input, etc., but phab:T185355 should be resolved first. That task makes it pretty clear the current system won't scale, so we probably shouldn't introduce millions of more rows into the change_tag table at this time. — MusikAnimal ^talk 05:09, 9 April 2018 (UTC)

Death knell sounding for Signpost? Proposals required

Signpost, our English Wikipedia 'newspaper', began when the project was started by Michael Snow who continues to contribute to the English Wikipedia. The first issue was released on 10 January 2005. Begun as a weekly publication, in July 2016 the official schedule was changed to every two weeks, but by November the issues were already running late with the next issue appearing on 26 November and the following Signpost not being published until 22 December three weeks later.

Signpost appeared on 17 January 2017 with a lead article from editor-in-chief, Peter Forsyth, entitled Next steps for the Signpost. Forsyth's article, which explained some of the concerns surrounding the newspaper, received a significant number of comments from readers including one from Blue Rasberry who suggested that a grant may be worth considering:

If there were a rotating internship program at The Signpost for journalism students then from one perspective it seems controversial to pay for content, but from another perspective for years the international wiki community has major projects with major investment which are almost unknown for lack of journalism. (…)This is wiki's own newspaper of record and if it has problems then I wish we could explore options to support volunteers in maintaining it.

Aschmidt suggested that Signpost could be made a blog, or even a journal, with James Heilman, known for his work on the Medicine project responding with 'Sort of like the Wiki Journal of Medicine? It is a fair bit of work. But could be good.' Stating that other related projects are '...experiencing parallel attenuation (...) Better to have fewer issues with excellent content than to fake along for the sake of hitting a weekly deadline' , Carrite makes a poignant reflection.

From August 2017 that weekly deadline became monthly; now in its thirteenth year, the most recent issue was published on 20 February with a note that the next one would be due out on 27 February (a week later?). We now have 27 March. Kudpung กุดผึ้ง (talk) 02:46, 27 March 2018 (UTC)

An indpeendent competing effort, The Citation, appears to have died out as well. Wikipediocracy hasn't had any front-page articles since December. The bread-and-butter article topics of ARBCOM cases, RfAs, etc. occur a lot less frequently than in the past. And personally, I suspect the topics I would be interested in writing about would be viewed by somebody as inappropriate canvassing. power~enwiki (π, ν) 03:39, 27 March 2018 (UTC)

Perhaps, but if you look at RfCs and such, there are now so many — and some of dubious quality or necessity — that it seems honestly hard to keep up with, beyond the specific interests one chooses at WP:FRS. There are so many discussions happening at once, it's a lot to juggle. ~ Amory (u • t • c) 11:07, 27 March 2018 (UTC)

Could part of the issue be the continued success of more focused newletters (tech, admin, etc.)? ~ Amory (u • t • c) 11:02, 27 March 2018 (UTC)

There has obviously been a problem getting workers for a long time, but unfortunately there is also one with readership. The first "News and Notes" of this year has only had 1800-odd views, which doesn't seem a lot. I think the quality remains high - it's a pity more people don't read it. Johnbod (talk) 15:07, 27 March 2018 (UTC)

+450 views through the single-page presentation. Cabayi (talk) 15:28, 27 March 2018 (UTC)

At its bare bones the Signal could be reimagined as a Portal which aggregated the recent featured articles, staffing changes at the Foundation, highest page traffic etc. But that would lack the editorial commentary which is what makes Signpost worth reading, and the release cycle which makes splits it into issues rather than it just being a stream (trickle?). Cabayi (talk) 16:15, 27 March 2018 (UTC)

Possibly newsletters are partly to blame, but certainly not wholly; those newsletters only inform a fraction of the news and action that is (or used to be) reported in Signpost. There are people who work for and on behalf of Wikipedia who have never or rarely edited it and haven't a clue of what's going on and then claim that even major new developments have been carried out in secret. Signpost does have big messaging and mailing lists as well as social media, so it reaches a larger and much broader spectrum of people. Kudpung กุดผึ้ง (talk) 16:26, 27 March 2018 (UTC)

From a production perspective, I think the key issue is the degree of co-ordination and commitment required from multiple contributors. For a period of time I edited a project newsletter, and I found most submitters were motivated by deadlines. So personally I think setting target release dates is still desirable. Perhaps there can be regular issues and supplementary ones: regular columns like the traffic report would continue to be in all issues, but feature articles and op-eds would appear on a less frequent basis. isaacl (talk) 17:35, 27 March 2018 (UTC)

• Fund The Signpost with a WMF grant for a paid administrator I posted a proposal at meta:Grants:Project/bluerasberry/fund a Signpost publisher.

The WMF should not fund Wiki content creation and editorial control - everyone agrees on this. I do think that the WMF should fund the tedious tasks which no volunteer finds enjoyable, but which when completed, amplify volunteer engagement. For various reasons, including 1990s software, the need for secretarial documentation and maintenance of a calendar, and demand for adherence to community values which are excessively time intensive for the niche purpose of running a newspaper, being the publisher of The Signpost is a lot of work. We can get a volunteer chief editor, and writers, and all the roles which are "journalism", but managing the very strange back end of publishing in Mediawiki software is tedious beyond anyone's willingness to volunteer. The least expensive way to manage administration is with payment to someone who will stay out of editorial decisions but facilitate what editors and writers submit.

The reason why we should maintain The Signpost is because it has been uniquely responsible for being the communication channel for resolving community discussions which have allocated millions of US$dollars of WMF funds in ways that would not have happened without community engagement in the community newspaper. Here are some options in front of us:

1. Let The Signpost falter. If we do this, the WMF will invest US$millions in marketing research and strategic planning to come to conclusions which would have arisen spontaneously from volunteer engagement in The Signpost. The Signpost has already proven itself to be an amazing forum for reaching broad consensus in the English and international Wikimedia communities. It has some value and merits some amount of investment for this reason. It has already earned its funding by resolving problems which otherwise are unfathomably complicated, stressful, and high risk to resolve in any other way.
2. Pay US$300,000 to a software developer to make The Signpost easier to publish. These software changes would still be a pain and go obsolete in 3 years because that is how Mediawiki development goes. Editing a newspaper is unlike publishing The Signpost. There is a bottleneck of ability to publish The Signpost and also the administrative support necessary to communicate in the normal way that any contemporary newspaper would operate is not available, because Mediawiki is not set up for this. Lots of people say "just fix the software, do not pay someone to be publisher", but it is crazy hard and crazy expensive to improve software as opposed to just paying someone outright to do the boring parts.
3. Pay ~US$100 per issue to an individual for administering The Signpost. This solves the problem, is cheap, and the money can go to a Wikimedia chapter which needs to be developed. India and Bangladesh would be my first choices because those countries, for whatever reason, have a history of attracting journalists as Wikimedia editors. Also in those economies the money would go further, and the WMF already has plans to spend $1000s to recruit volunteers who will contribute labor that could be purchased outright for $100s. I know that the Wiki community places a taboo on buying labor, but for some tasks, paying someone outreach is a lot cheaper than funding the recruitment campaign that will identify and groom the volunteer who would do the task. Administering The Signpost is esoteric and provides no job training or relevance to actually doing journalism, and the fault is in Mediawiki and the Wiki community's overriding need to publish in Mediawiki.

I advocate for paying an individual to publish as the most practical, cheapest, and most likely path to success for getting The Signpost out. We have content submissions, excellent editorial oversight, and readership. It is annoying that the bottleneck is in administration of adapting weird obsolete software to journalism.

Anyone with ideas might also try to form a The Signpost user group - meta:Wikimedia user groups. This would establish a board to oversee The Signpost, appoint a chief editor, and protect the values of the publication. Blue Rasberry (talk) 21:14, 27 March 2018 (UTC)

I moved this post to Wikipedia_talk:Wikipedia_Signpost/2018-03-29/Op-ed. I do not mean to fork the conversation or dismiss what others say, but the wiki threaded converation system makes it challenging to present a statement in more than one place. I am watching both conversations, but for context, the one that seems more developed and more permanent to me is in the newspaper. Blue Rasberry (talk) 15:53, 30 March 2018 (UTC)

One possible reason for the overall decline is that the Wikimedia blog is taking up some of what the Signpost used to do, particularly in terms of research reports and Wikipedia/WMF activities. Don't know how much energy this has bled off from the Signpost, but The ed17 and Jayen466 might have input there. I wonder if the Signpost could incorporate blog links to add to regular features such as the traffic report... I don't know. Montanabw^(talk) 21:23, 27 March 2018 (UTC)

The WMF blog is not run by the community, rather it's corporate communication. It is up to the community to decide whether it will have a voice of its own. That's what the fall of Signpost is all about in the end.--Aschmidt (talk) 21:49, 27 March 2018 (UTC)

• Replace it with something short, snappy, informative and weekly. The Administrators' newsletter could be a nucleus, obviously with a wider topic range and a spot for an opinion piece (limited as to word count). One featured picture is enough: Noyster (talk), 16:22, 28 March 2018 (UTC)

  Well, the Administrators' newsletter already exists, so we would not have to duplicate it, would we? – BTW, thanks for the hint, I didn't even know it even exists, I've just subscribed to it) – Another example for a brief format might be the French fr:Wikipédia:Wikimag. A showcase for a much more lively concept would be, of course, the German de:Wikipedia:Kurier which is, in fact, a multi-author blog that everyone who wants can contribute to. It has become a bit of a nuisance that the German-language Wikimedia chapters have come to use it as a channel for their corporate communication with the community, too, but by and large it still is run by Wikipedians from all projects and colours. Its main advantage over the old Signpost is that you can publish a post whenever it's suitable. There is no weekly, by-weekly, etc. format, and there is no staff that decides what comes in and what stays out. It's a community blog, not a journalists' project.--Aschmidt (talk) 22:57, 28 March 2018 (UTC)

I guess I stopped taking The Signpost seriously when it went from providing a succinct overview of what was going on, and moved to letting editors grind their personal axes in an attempt to stir controversy and get page views. Given the continued moribund nature of the project and low readership figures, perhaps it is best to just let it die. Certainly I don't think we can seriously argue that it is the vital communications channel that it was in the past. Lankiveil ^{(speak to me)} 01:17, 31 March 2018 (UTC).

As much as I loved the signpost at one time.. I cannot disagree with your position. —TheDJ (talk • contribs) 08:44, 5 April 2018 (UTC)

It went through an unfortunate patch, but that is hopefully over, and the role of the Signpost and the need for it remains. I suggest that we try and recruit sufficient volunteers to get at least a minimal signpost regularly circulated. Like that initial creation of a stub article, once it is in being it can attract people who wish to improve it. The problem in my view is in trying to keep such a large publication that it can't achieve its publication schedule. ϢereSpielChequers 10:06, 5 April 2018 (UTC)

Respectfully, if it were a "need" for the Signpost, we wouldn't be having this discussion because people would be writing and publishing it. The community seems to have been getting along just fine without it. Lankiveil ^{(speak to me)} 04:34, 9 April 2018 (UTC).

• Well, just pick a date say the 20th of every month publish whatever is ready - that assumes there are people interested in being editors/coordinators/creators of the thing - but if there are not, there are not. It's WP:Sofixit, the do it yourself way, which is generally how anything gets done on WP. Just one has to decide to do it, and hopefully they have the skills to inspire (and deal with) others joining in -- and the foresight to meet the needs of whatever readers they wish to serve. (Note: Many of the past and future likely articles/features are compendia of what is elsewhere on the pedia, gathering together and highlighting things, which is fine and which means all one needs is someone(s) willing to do that) -- Alanscottwalker (talk) 11:08, 5 April 2018 (UTC)

Once per month, or it's over

If we can't find any editors willing to update the Signpost 'at least' once a month? then the whole thing is doomed. BTW: the title "Signpost", should be changed to "Wikipedia News", for a more accurate description. GoodDay (talk) 16:55, 6 April 2018 (UTC)

If Signpost is having its thunder stolen by more focused newsletters, why not just aggregate content from those newsletters once a month? bd2412 T 17:25, 6 April 2018 (UTC)

@GoodDay and BD2412: I write for the publication and I am just one person with an opinion, but my view is that the publication has always had lots of writers, editors, researchers, journalists, etc. The bottleneck is in recruiting a publisher to facilitate the actual publishing of the submitted content in a very weird publishing system. Wiki is 1990s software and not designed for either journal publishing or the kind of communication required to publish a journal. If writers and editors could be without the burden of doing the publishing then there would be more volunteer engagement. As a volunteer activity publishing itself is devoid of fun. The journalism side of The Signpost is fun for lots of people when there is a publisher. Publishing is a technical process unrelated to journalism. Blue Rasberry (talk) 20:36, 9 April 2018 (UTC)

I'm willing to do one or two "publisher" cycles to keep it running, but not every month (and certainly not every week). Do you have an IRC channel to coordinate things? power~enwiki (π, ν) 20:48, 9 April 2018 (UTC)

How about every 3 months? We could change the name from Signpost to Wikipedia Quarterly Report. GoodDay (talk) 21:33, 9 April 2018 (UTC)

Net neutrality

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The Senate is headed for a vote on a Congressional Review Act (CRA) resolution to overturn the FCC’s repeal of net neutrality, but we still need at least one more Republican vote to win. According to FightForTheFuture, pressure from local businesses in lawmakers’ own districts is perhaps the single most effective strategy for convincing hard-to-get lawmakers to buck partisan politics and side with the overwhelming majority of voters to speak out for the open Internet.

Could we perhaps link to https://www.businessesfornetneutrality.com/ in a banner at the top of all pages? --Gryllida (talk) 00:12, 25 March 2018 (UTC)

• Oppose power~enwiki (π, ν) 00:15, 25 March 2018 (UTC)
• No political action please. -- Ajraddatz (talk) 00:39, 25 March 2018 (UTC)
• I strongly support net neutrality and I even tend to rant about it from time to time, but I think it might be good for Wikipedia to be politically neutral. If Wikipedia takes a political stand on just about anything, a certain percentage of users, editors, admins, and etc. will be alienated. Bob Webster (talk) 02:08, 25 March 2018 (UTC)
• I don't think we can. Back when the FCC was going to vote, there was a suggestion to have WP have some similar message to get the word out. I know I supported it, but there's a very strong vocal dismissal of anything that appears to be politically motivated or similar call to action; I doubt that has dissipated since last fall. --Masem (t) 02:20, 25 March 2018 (UTC)
• There is no "we" here with a monolithic political viewpoint. So no. MB 05:04, 25 March 2018 (UTC)
• Oppose in strongest sense. -Wikipedia's neutrality is what we should strive for, it is wha makes Wikipedia great and unassailable.–Ammarpad (talk) 06:21, 25 March 2018 (UTC)
• Comment. It is my view that the Wikimedia Foundation, in consultation with it's communities, is obligated to take any and all action necessarily to protect it's communities' ability to progress towards their goals. This action may at times suffer from a paradox of neutrality (similar to the paradox of tolerance), and this conflict can only be resolved by carefully balancing the threat's effect on our goals and the action's effect on our goals. In the case of the 2012 Wikipedia blackout, a decision was made that the threat presented an overwhelming danger to our continued operation and severe action was taken. My view is there is no blanket prohibition on potentially political action, but that such action needs to be supported by an extensive risk assessment. If you believe that this particular issue deserves such treatment, you are welcome to make your case, however I suspect we have already exhausted our ability to express our view on net neutrality at this time. TheDragonFire (talk) 08:32, 25 March 2018 (UTC)
• Different support This organization knows nothing about free content, open licensing, etc. They need Wiki support, but advertising and named partnerships will neither help them or wiki because their strategic plan actually is ignorant of the basics of a free and open Internet. Instead of asking for the wiki side to do all the work, contact them and ask them for the following:
  • They produce educational inforgraphics, explanatory texts about net neutrality, and a suite of other educational resources. Tell them to apply open licenses to this content and post it to Commons.
  • They have in-house experts helping them design lobbying campaigns and recruit activists. Tell them that Wikipedia is the most consulted source of information for every topic in their field of expertise. Show them the traffic metrics and bring them into a conversation in which you have them compare Wikipedia's traffic with the audience they are reaching in other social media. They should understand that ~100% of activists, journalists, and anyone researching the basics of social issues will review the wiki articles as they orient themselves to the topic and bring themselves up to date. In their network they ought to be able to send someone to edit wiki, and maybe you can organize training and support for them on the wiki side.
  • They organize lots of in-person protests and events. Tell them to train their community organizers to upload good photosets to commons with proper cataloging and documentation.

A partnership with the Wikimedia community cannot be the wiki side giving everything without the other side even understanding the value and significance of it. I know this organization. I appreciate the conversation they are trying to have. I want to draw them and experts on the opposing side to present their best in Wiki's media collection. Blue Rasberry (talk) 11:58, 25 March 2018 (UTC)

• I would support this iff it can be shown that this is an existential threat to Wikipedia. I have yet to see that argument convincingly made. Tazerdadog (talk) 21:31, 25 March 2018 (UTC)
• Oppose we as a movement don't want net neutrality, see Wikipedia Zero. While that program's being winded down, I'm sure the WMF will come up at some point within the next year or so with some idea where it would serve our mission if net neutrality wasn't a thing. When you are the 5th largest website on the planet, net neutrality has the possibility to hurt rather than help. TonyBallioni (talk) 21:51, 25 March 2018 (UTC)
• Oppose We don't need no stinkin' Net Neutrality. GenQuest ^{"Talk to Me"} 22:16, 25 March 2018 (UTC)
• Oppose any activism on the part of Wikipedia, we need to strive to remain politically neutral, regardless of how much I might personally feel about this particular issue. — Insertcleverphrasehere ^{(or here)} 22:18, 25 March 2018 (UTC)
• Oppose: The Internet is not broken, and does not need to be "fixed" by giving the US government more control over the internet. The recently repealed Obama-era net neutrality rules adopted a vague but sweeping "general conduct" standard that gave the FCC the power to crack down on perceived bad behavior by internet providers without providing clear guidance about what would trigger enforcement. --Guy Macon (talk) 22:29, 25 March 2018 (UTC)
• Comment - this is all gibberish to me. Systemic bias or what? The US-based contributors might understand what is going on but I suspect most of the rest of the world, unless IT-savvy, do not. - Sitush (talk) 23:31, 25 March 2018 (UTC)

@Sitush: Your country India organized the biggest protest for net neutrality in the world at Free_Basics#Net_neutrality_criticism_in_India. It brought popular support and politicians speaking out. May be not everyone gets all the details but lots of people have opinions about colonization and can see neocolonialism regardless of IT skills. Blue Rasberry (talk) 23:52, 25 March 2018 (UTC)

Do what? India? I'm in the UK. - Sitush (talk) 23:53, 25 March 2018 (UTC)

Another sort of bias; assuming a country from a username. I get a variation of that a lot. Although I was raised by a family from London speaking the Queen's English (I learned the Americanisms in school), people keep assuming from my name that I am French. That being said, why should the United States Federal Communication Commission In Washington be allowed to have control over the Internet? Why not some government agency in Whitehall? Or Brussels? Or African Union#Headquarters#Addis Ababa? --Guy Macon (talk) 02:14, 26 March 2018 (UTC)

Oh, indeed, I have no idea why the US should control anything and generally would much rather that country stopped trying to represent the world/throw its weight about etc ... but I also have no real idea what this proposal is referencing. I know, vaguely, of the net neutrality paradigm but that is it. And, contrary to popular opinion among people who take me to ANI, I am not an idiot :) - Sitush (talk) 02:18, 26 March 2018 (UTC)

@Sitush: Sorry to presume if there is any reason to object. We have developed India-related articles for years and I imagined that your interest in the place made India your own. Blue Rasberry (talk) 02:29, 26 March 2018 (UTC)

• Oppose. Iazyges Consermonor Opus meum 15:50, 26 March 2018 (UTC)
• Oppose. Stop trying to involve wikipedia in politics. Natureium (talk) 16:18, 26 March 2018 (UTC)
• Oppose - WMF as a whole should not get involved with any of this ..... I personally feel NN should never have been thought of but it has and here we are (coming from a UK bloke) ... Point is we IMHO should not involve ourselves with this. –Davey2010^Talk 16:37, 27 March 2018 (UTC)
• Oppose - I don't volunteer to be part of a political movement, I volunteer to build an encyclopedia. Anything that is not directly related to that, I will always oppose. Dennis Brown - 2¢ 15:50, 28 March 2018 (UTC)
• Oppose - Please don't bring politics into this encyclopedia. Do it elsewhere. Not here. Javert2113 (talk) 22:53, 28 March 2018 (UTC)
• Support- We already have enough people here trying out extremely long edit summaries at the village pump, so we can't hand this out to the vandels and trolls of Wikipedia.--Adam Song (talk) 19:29, 30 March 2018 (UTC)

  You've probably commented under a wrong topic. MT Train^Talk 10:19, 31 March 2018 (UTC)

  Oops... Adam Song (talk) 16:53, 3 April 2018 (UTC)

• Oppose- We don't need to bring politics in Wikipedia. MT Train^Talk 10:19, 31 March 2018 (UTC)
• Comment People are so afraid of politicizing Wikipedia in a time where they are so politically divided (esp. in america), that they are not willing to engage in defending the ideals that allowed Wikipedia to be built. I'd look elsewhere for support. Oh and cancel your AT&T and Verizon. They are the sole reason we even need to think about this. —TheDJ (talk • contribs) 12:01, 31 March 2018 (UTC)
  • Rebuttal: The above assumes without evidence that having the US government control the Internet in some vague way "defends the ideals that allowed Wikipedia to be built" Sorry, but Wikipedia was built on internet freedom, not government regulations. Also, the Internet is not broken and does not need fixing. --Guy Macon (talk) 16:10, 31 March 2018 (UTC)
    • Our Internet freedom existed only until the time that the Internet started to matter to those in power. I don't want the US to control the Internet, I want the US to protect the Internet from the US. The US has its priorities as: itself, capitalism, freedom. This is reshaping the Internet as we knew it and it is bleeding into the rest of the world at an alarming rate. We need to wind that back a bit, to when the first two didn't dominate how the Internet worked. To say that the US has not significantly changed the dynamics of the Internet over the past 15 years is simply turning a blind eye to the USAs shifted priorities. The CLOUD Act is only the latest evidence. I have little hope however of stopping this. It will be fine for a while as we slowly turn 1984 and then it will be chaos. —TheDJ (talk • contribs) 12:25, 5 April 2018 (UTC)
• While this will barely affects Wikipedia given the size of our articles, it will have a huge effect on streaming media/videos and so could affect commons - and if wikipedia gets round to incorporating more free media in articles, ENWP as well. The reason for net neutrality being removed is so the few monopolising companies in the US can charge content providers to prioritise their traffic. Since I doubt the WMF (even with its warchest) will be able or willing to pay Comcast etc to keep its traffic in the fast lane, this will result in a slowdown and delivery of WMF-hosted content to end-users. This isnt some sort of paranoia, I dont think anyone realistically expects the WMF will be a company able to pay the amounts that are needed. The *entire* purpose of rolling back net neutrality is to extract money from heavy-traffic companies because they are limited in what they can charge their customers. So all those opposing and live in the US: You are shooting yourself in the foot long term. Those opposing outside the US: Its in our interest to not have the rolling back of net neutrality be seen as a corporate success in the US, lest our own governments and corporations decide they want to advocate for it here. Only in death does duty end (talk) 16:37, 31 March 2018 (UTC)
  • I strongly disagree. At the very least, could you at least acknowledge the arguments made by those who don't want the US government to micromanage the Internet instead of simply parroting pro-net-neutrality arguments? See [1][2][3][4] --Guy Macon (talk) 19:36, 31 March 2018 (UTC)
    • Not really no :) There really is no argument that net neutrality being repealed is to allow different internet traffic to be given unequal weight. That is the entire point of it. So if you genuinely believe the WMF's traffic is going to end up in the fast lane, sure there is no issue. But that aint gonna happen. The reason why governments have to 'micromanage' is because left to themselves private corporations would be completely unethical in their pursuit of cash. As I am not an American and live in a country that does actually believe in public services being available without restriction - which the internet clearly falls under - I am more than happy for government oversight to ensure that it is done fairly. I would prefer if the US government had *less* actual influence over it, given its currently being run by someone ruling by proclamation influenced by what he read on twitter, but since thats unlikely anytime soon I will settle for all the traffic being treated equally. Only in death does duty end (talk) 19:46, 31 March 2018 (UTC)
      • So by your own admission you won't even consider the opposing arguments. I won't bother trying to convince you then. Forgive me if I am misremembering, but you are in the UK, right? And above you claim that "I live in a country that does actually believe in public services being available without restriction". Care to explain this restriction of a public service?[5] It sure looks to me like some households are in the hosepipe slow lane stadiums used for national and international sports are in the hosepipe fast lane. I look forward to your spirited defense of water neutrality in the UK. (And if I did misremember your home country, I have examples for India, Australia, etc.) Oh, by the way, your claim that "While this will barely affects Wikipedia" is factually incorrect. See [6] and the WMF's recent caving in to political pressure from people like you who won't even consider the opposing arguments and cancelling Wikipedia Zero. --Guy Macon (talk) 20:28, 31 March 2018 (UTC)
        • Having a green lawn is a not a right much as my fellow brits would disagree I am sure. Granted if they told me I could only shower every other day or only boil the kettle twice we might have a problem. Oh and I support Wikipedia Zero in theory, it was just in practice it didnt work. I also worked for Vodafone about ten years ago who routinely zero-rated their own content like many other mobile carriers (it didnt cost anything to use their own music service for example vs other streaming services) and for mobile carriers there are technical reasons it was (to a lesser extent now) an issue. Wikipedia Zero wasnt scuppered solely because of net neutrality issues, it was scuppered because a)it didnt make the WMF money, b)it didnt make the mobile carriers money, c)it was being used to share huge amounts of pirated media costing the carriers money. But there is a marked difference between providing free internet access to information to people who do not have it (which is what Wikipedia Zero attempted to do) and asking people to pay more for the same service they already do have. Although in the case of net neutrality 'asking' is a bit of a nice way to describe what companies will be doing. 'Pay us or else' would be more accurate. Only in death does duty end (talk) 23:27, 31 March 2018 (UTC)
  • Oppose-The less politics the betterAdam Song (talk) 16:56, 3 April 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Remove from watchlist

Perhaps this has been proposed before, or perhaps I'm missing something, but I'd like to have a way to remove an article from the watchlist directly on the watchlist, without having to go to the article to remove it. Save a click, maybe. Peter Flass (talk) 18:14, 9 April 2018 (UTC)

@Peter Flass: "Add direct unwatch/watch links to watchlist entries (JavaScript required for toggle functionality)" in Special:Preferences#mw-prefsection-watchlist. --Izno (talk) 19:00, 9 April 2018 (UTC)

Also Special:EditWatchlist allows you to edit without going to the pages, and allows for bulk removals if desired. — xaosflux ^Talk 19:01, 9 April 2018 (UTC)

Thanks, that did it. Peter Flass (talk) 23:18, 9 April 2018 (UTC)

There's even a big button on the watchlist named "Edit your list of watched pages" :) —TheDJ (talk • contribs) 08:26, 10 April 2018 (UTC)

Move discussion related to proper use of the Template namespace

A move discussion is being held at Wikipedia talk:Did you know#Requested move 10 April 2018 which may be of interest to editors following this page. It relates to the Wikipedia:Did you know nomination process and the Wikipedia:Template namespace guideline. -- Netoholic @ 19:59, 10 April 2018 (UTC)

violation of neutrality

Trade route from the Varangians to the Greeks

Categories: Economy of the Byzantine Empire Economic history of Russia Trade routes Portages History of Kievan Rus' Varangians Medieval economics

and

Russkaya Pravda

Categories: East Slavic manuscripts Kievan Rus society Medieval legal codes Legal history of Russia Cyrillic manuscripts 13th-century manuscripts

it is enough to read history of Ukraine to see usefulness of addition of the categories connected with Ukraine. [[7]]

That is why not professionally to write down objects of Kievan Rus' only as Russians

To add category "the history of Ukraine and other categories across Ukraine In categories Ukraine is thrown out. — Preceding unsigned comment added by Bohdan Bondar (talk • contribs) 08:44, 11 April 2018 (UTC)

Entirely the wrong venue (if I understand the issue correctly from the above pile o' hay). Take it to the relevant talk pages. --Elmidae (talk · contribs) 10:51, 11 April 2018 (UTC)

Removing or replacing Template:A-ha singles

This template has apparently been merged into "Template A-ha". It's now serving simply as a redirect to the latter. Now check with What links here and find that double occurences of template A-ha occurs in several articles. Who will confirm my observations and make a bot job to remove the "singles template"? -- TorSch (talk) 07:12, 11 April 2018 (UTC)

 Done manually.--John Cline (talk) 14:28, 11 April 2018 (UTC)

Page previews - request for feedback

After positive results from our most recent A/B tests on Page Previews on German and English Wikipedias, the Readers web team are planning the next steps of feature rollout for the first half of April 2018. We have requested feedback and there's a discussion happening over on Wikipedia:Village pump (miscellaneous). Yours, OVasileva (WMF) (talk) 21:07, 6 April 2018 (UTC)

Next Steps - Thanks for your participation in the discussion. Since we haven’t heard any comments in the last few days, we've posted next steps for deployment based on the feedback we received so far. Let us know if you would like more time for discussion. Thanks! OVasileva (WMF) (talk) 14:44, 12 April 2018 (UTC)

List of sources owned by editors

I would like to see, for want of a better term, an editors library. That is to say, a collection of sources owned by editors which can be searched by other users for the purpose of checking sources or clarifying ambiguous sentences. I think this would be particularly useful for reviewers spotchecking sources at WP:FAC or WP:GAN, see this discussion [[8]], but would also be of value in cases such as this [[9]] where an editor had synthesised or misinterpreted the source.

The library would be searchable by source and by editor thus entering the source in the search box would bring up a list of every editor with access to it, while entering a user name would bring up a list of sources that that editor has. If it was suspected that content had been added with a fake reference or not truly representative of the source, an editor could search for a list of all editors who own the book and ask one or more of those editors to corroborate the content. I imagine quoting the source verbatim would have some copyright issues, although a private email might solve that problem, but In most cases I imagine a simple "Yes, that's okay" or "No, that's not what the source says" would suffice. Searching for a specific editor might be desirable if they are known to have a particular interest in a subject or perhaps are more readily available because they operate in the same time-zone or are simply more active. Another reason one might want to see an editor's library is when trying to fix an ambiguous sentence: After seeing which editors have access to the source, one might want to see whether a particular editor has more books which might clear things up. See the question about HMS Pallas and the French frigate Minerve, and whose guns did what, here [[10]], as an example.

Only sources owned by the editor would be listed so not library books they once borrowed or internet sources which are freely available, although listing any subscription-only sources one had access to would be appropriate. Editors need not catalogue everything and might, for example, only want to include things they are particularly interested in. Entering one's library into the database would indicate one's willingness to check references but there could also be a userbox expressing that the user is happy to help and incorporating a link to his/her library page.

I don't know how much work is involved in setting it up or even if it's something other editors want, so happy to here any comments or suggestions.--Ykraps (talk) 10:14, 8 April 2018 (UTC)

Well, it's probably worth consulting with WP:RX. I like the idea. Technically, if there's a set of subpages by editor, an ISBN search should be easy (along the lines of the archive search over at WP:ANI. ∰Bellezzasolo✡ Discuss 10:24, 8 April 2018 (UTC)

Unfortunately, this idea would probably violate all sorts of copyright laws. Most nations have laws which limit scanning published works, and making them available to others on line. Blueboar (talk) 11:43, 8 April 2018 (UTC)

@Blueboar: actually Ykraps is not suggesting scanning, if you look, only that the editor would be able to check a reference and say whether it is properly employed or not. Peter coxhead (talk) 12:17, 8 April 2018 (UTC)

But to discover whether a source is properly employed (or not) one needs to actually obtain a copy of the source, and READ it. I am now confused as to what is being suggested. Blueboar (talk) 12:59, 8 April 2018 (UTC)

@Blueboar:, User:Peter coxhead is correct. All you will see is a list of books. You are asking the person with the book to get it from his bookshelf, read the appropriate page and tell you whether it supports the paragraph in the article. Yes, there is an element of WP:AGF in that you are trusting the book owner to interpret the source faithfully, but that is no different to how it stands now with citations. The advantage is when there are multiple editors with the same book, who can jointly confirm the text is fully supported. In this case above [[11]], User:Slatersteven would've been able to go to the database and see that both I and User:Wiki-Ed own Ferguson's book. He could then ping us. If we hadn't had the article on our watchlists, we would never have known about the issue. This system overcomes all that.--Ykraps (talk) 15:26, 8 April 2018 (UTC)

Ah... ok. Thanks for clarifying. Blueboar (talk) 15:36, 8 April 2018 (UTC)

Seems a fair proposal. As long as that is all it is a list. Not sure it is worth all the work though.Slatersteven (talk) 15:30, 8 April 2018 (UTC)

I'm not saying this is a bad idea, but frankly it does appear to me as a rather inefficient undertaking. Because, what's the point in telling people that Joe has 200 books at home, if Jane has access to a big reasearch library with millions of volumes? If you have just one person frequenting such a library and who is ready to help others check sources - which I think is what WP:RX is about -, the value of all these documentation efforts by individual users is diminished enormously. Not only for reasons of quantity, but also because of a “specialization mismatch”: Joe's books that are of interest to many people will very likely also be available from the library. But Joe's super-specialized books - the ones that even most people with library access might struggle to obtain -, well, how likely is it that there's another Wikipedia editor interested in such a book (and who additionally knows that such a directory actually exists)? This makes me somewhat skeptical, cost-benefit wise. (By the way, Wikipedia:WikiProject Resource Exchange/Shared Resources and de:Wikipedia:Bibliothek pursue a similar goal to that suggested here, though these are lists. Both are also fairly deserted, judging from the version histories.) — Pajz (talk) 16:14, 8 April 2018 (UTC)

Quite high I would say, given the breadth of users it is more than likely that even then most specialized subject has multiple edss with access to the sources. What is not available is a way of tying that up with the edds who have the sources. The only issue I have is the ABF inherent, one edd claiming to have access to a source is not enough, we want people to check it. — Preceding unsigned comment added by Slatersteven (talk • contribs) 16:21, 8 April 2018 (UTC)

Pajz This is not about telling someone where to find references for their article, this is about putting an editor in touch with another editor who can very quickly determine whether a sentence in an article is faithful to the supporting citation. I don't see how any of projects mentioned could help with the example scenarios I've given (although I may have underestimated the scope of those projects). If I wanted to know whether Winfield's book (see below) contains an entry for a 74-gun ship called Pearl, I don't want to be told there is a copy of the book in a library thirty miles away, I want to be told whether it does or it doesn't. As regards the amount of work, not being a computer programmer, I don't know what's involved but I would've thought that a searchable set of sub-pages within Wikipedia would a reasonably straightforward thing to set up, for someone with the know-how. I am anticipating that editors who want to take part in the scheme will enter their own data.--Ykraps (talk) 11:49, 9 April 2018 (UTC)

• @Ykraps: Check out inventaire.io/, which is a Wikidata front-end in which people can list the books they have and make them available to loan to other people. There are lots of web platforms like this, but this one is unusual for using and contributing to Wikidata's catalog of books. You might want to check this out because they have modeled what you are describing, and their service might be ready now to do what you want. I know it is off wiki but before any such project could ever be part of Wikipedia projects, it has get an off-wiki demo and then go through multiple steps to get closer. Blue Rasberry (talk) 16:59, 8 April 2018 (UTC)

I fear we may be at cross-purposes, what I'm suggesting is a set of sub-pages within Wikipedia which are searchable. The idea being that you can find a fellow editor who can very quickly corroborate an off-line source without lots of searching, having to visit a library or wait for someone to send them the book in the post. As an example: A user creates an aricle entitled HMS Pearl (1767) which says it's a 74-gun third-rate ship of the line and references the article with Winfield, Rif (2007). British Warships in the Age of Sail 1714–1792: Design, Construction, Careers and Fates. Seaforth Publishing. p. 195. ISBN 978-1-84415-700-6. {{cite book}}: Cite has empty unknown parameter: |titlelink1= (help). Under my proposal, anyone (including ips) can search for the source, which will bring up something like this with a list of Wikipedia editors who own the book. Any or all of those editors will be able to tell you that there is no such ship and that p.195 contains an entry for HMS Pearl (1762), a 32-gun frigate. Can anything you're suggesting help in a case like this?--Ykraps (talk) 17:27, 8 April 2018 (UTC)

@Ykraps: No one actually has to ship the books. Some people made wiki-based software imagining that the wiki community would want to mail books, but try to imagine that if when you found someone who had the book you wanted, you asked them to check something instead of mailing you the book. I know it is not the same, but this is as close as you are going to find for already-existing software based on Wikimedia projects. Can you imagine yourself joining their project and ask them to add a button that says, "do not mail, just check a page"?

Instead of searching Wikipedia subpages, this project has a Wikidata-based book catalog which is searchable. Does that not sound better to you than a plain text search system on Wikipedia pages? This project produces lists like that example book page you created. Blue Rasberry (talk) 12:04, 9 April 2018 (UTC)

@Blue Rasberry: Yes, I see how that could work. I guess the advantage of having something within Wikipedia is that Wikipedians are more likely to be interested in maintaining Wikipedia articles, and are almost certainly going to have the sort of specialist books needed for some of the obscure subjects. Added to which, there is already a method of communication, the talk pages, that means there is no need to divulge your email and because it is visible to all, might attract the attention of additional editors. However, there does not seem to be a lot of support for this proposal so may be I need to rethink things.--Ykraps (talk) 05:56, 10 April 2018 (UTC)

@Ykraps: I would call inventaire a Wikimedia project because of all the Wikidata integration and Wikimedia culture it already uses. No one ever gets access to do weird experiments at Wikipedia.org, and even access to tools.wmflabs.org can be more trouble than developers want. Check the credits at the bottom of inventaire - they obviously care about Wikimedia projects and went to a lot of trouble to integrate these tools with that. These kinds of experiments happen continuously and 1 in 100 actually comes into Wikimedia projects. When the WMF does decide to commit their own staff to software development often it is based on someone else first doing an experiment. I know this inventaire project is not perfect but it is a working demonstration. Things like Wikimedia account integration are just additional features which a developer could install depending on how much funding they have, which depends on how much interest other people have.

I was not showing you this to make you think you have no support for your proposal, and I think you are interpreting this the wrong way. I hoped that when you looked at this you would see that someone cared so much that they coordinated labor worth US$50,000+ to build a demo of your idea. From an optimistic perspective, you could say that your idea has already recruited a massive donation of labor, development, publicity, and community building which resulted in a working demo. Blue Rasberry (talk) 12:02, 10 April 2018 (UTC)

Sorry, when I said there was little interest, I didn't mean from those that have commented here. I was merely noting that many people have visited this page to comment elsewhere but didn't care sufficiently to contribute to this discussion (which is absolutely fine. I have no problem with that either). It is difficult for me to get a handle on what Inventaire does or is capable of, because I am required to create an account in order to access it and this is something I am uncomfortable doing. I don't think I'm alone in my reluctance to sign up to strange things on the internet either and this is another advantage to running the project in-house; we all already have global accounts.--Ykraps (talk) 11:47, 11 April 2018 (UTC)

• We have one of these for the video game domain. --Izno (talk) 22:45, 8 April 2018 (UTC)

Wikipedia:WikiProject Resource Exchange/Resource Request list many books they can access by posting at Wikipedia:WikiProject Bibliographies and Wikipedia:WikiProject Academic Journals.....that makes lists Wikipedia:List of bibliographies.--Moxy (talk) 12:12, 10 April 2018 (UTC)

• I love the idea in principle. I think publicising which editors have access to which specialist publications, and are willing to check and supply reference details for the project, would be absolutely wonderful. When I worked in the GLAM sector, we had access to an amazing array of resources, and I still do within my own specialist areas of UK botany and Alpine mountaineering. I probably see this working best at the WikiProject level, but maybe with a standard format encouraged across Projects. In fact, I posted a selected set of resources I held for alpine mountaineering back in 2015, with the suggestion it could be worth expanding (See here). An issue to consider is removing content listed by an editor when that individual ceases to contribute here. Boy, the number of times I've thrown out (ie sent to charity shops/eBay) specialist books which I've used to enhance an article, or didn't feel I'd ever be likely to want to use again myself. By way of example, some colleagues who adminster my local World Heritage Site recently threw out a number of very detailed reference books they'd been given by other WHS projects around the world - which I saved from the bin. I used one to enhance this article, and thought about offering to post it to someone who might like to access the rest of the amazing detailed inscription details. The cost implication of posting put me off, but keeping it to access on someone else's behalf would have provided me the perfect excuse to retain it! Sadly, I think it went down the paper recycling route in the end. Regards from the UK, Nick Moyes (talk) 20:57, 10 April 2018 (UTC)

  Nick Moyes, I guess I was thinking that at its most basic, the scheme could be administered/managed/publicised by a Wikiproject, either a new one or an existing one such as WP:RX. With regards to editors leaving, I thought probably a computer programme could take care of that. On joining, the editor would create his/her own library page - something like this. The programme would then create a page for each book, similar to this and add your user name along with any subsequent users who had that same book in their library. When someone retire, they wipe their library page and the programme removes their name from each book page. Again, I'm not a programmer so I don't know what's possible.--Ykraps (talk) 12:14, 11 April 2018 (UTC)

  I've got a library page that I've been maintaining for years, with an offer to check anything people want verified. I haven't had a single request, ever (I don't offer this too widely, however, as I don't want to be bugged too often). The principle sounds good, but in practice there isn't an easy way for someone to go through every list of editors' books and find those with a copy of a certain title, unless the library was based on a template with some kind of global search function, i.e. a bot scans all libraries that follow a certain format and catalogues all titles so that they can be searched and editors identified. Whether that's even possible with the Wiki software is the question. Having editors keep their lists updated with the right title, author, publisher, year, ISBN, etc is a huge task that can result in lots of errors. — Marcus^(talk) 16:25, 13 April 2018 (UTC)

  @MarcusBritish: Maybe the reason you haven't had a request is that your library hasn't been widely publicised. There have been three occassions I can think of when I would have asked you to check a source for me, had I been aware that you had access to those books. It's an impressive list by the way and I will try to remember it for the future. In return, I will create a similar page. Although, as you say, what is needed is a programme that can collate these lists and a search engine. Perhaps I am over-complicating things and all that's really needed is for each Wikiproject to list it's members sources on a project page.--Ykraps (talk) 09:18, 14 April 2018 (UTC)

RfC: Ending the system of portals alternatively

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should portals be merged into their respective Wikiprojects? This may mean that the Wikiprojects' main page should be adapted for navigation, but all useless parts removed. --Railfan01 (talk) 20:18, 14 April 2018 (UTC)

Survey

• Support I think that Portals, now seeming useless as aforementioned in another RfC on this page, shall be merged into Wikiprojects, or the other way round, both being useless alone --Railfan01 (talk) 20:18, 14 April 2018 (UTC)
  • I don't know why you have decided WikiProjects are useless, but they definitely aren't (this should be less controversial than the portal issue). Master of Time (talk) 20:53, 14 April 2018 (UTC)
• Would this query make sense as part of the Portals RfC? I can see the advantages of concentrating all topic-specific Wiki-things under one system rather than having Portals for readers and WikiProjects for editors and thus splitting editors' attention between two systems. Jo-Jo Eumerus (talk, contributions) 20:24, 14 April 2018 (UTC)
  • Isn't the other portals RfC finished yet? I think there was no consensus. It is sort of an opportunity to reopen the dicussion --Railfan01 (talk) 20:47, 14 April 2018 (UTC)
    • No, it isn't, and you should wait for it to finish and for an admin to identify a consensus, if any. Also, the other RfC was strongly criticized for not notifying the portals. If you wish to go through with this, you should be the one to notify them, and also the affected WikiProjects. But I think that you should terminate this right away because it is only going to be confusing and disruptive. RockMagnetist(talk) 20:52, 14 April 2018 (UTC)
• Comment – Why would we move portals to WikiProjects which are in the project namespace? That namespace is largely used by editors for Wikipedia maintenance. Portal namespace is targeted at readers. Master of Time (talk) 20:53, 14 April 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Ending the system of portals

Moved to Wikipedia:Village pump (proposals)/RfC: Ending the system of portals

 – Hi everybody. Because this discussion has become so lengthy (400,000+ bytes), I have moved it to a subpage of the village pump so that the village pump is more accessible. I apologize if any confusion has been caused by this. Mz7 (talk) 01:59, 18 April 2018 (UTC)

Automated article assessment

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

This is to propose that a bot be developed (I may be able to figure out how to do it, with a bit of help) that automatically assesses new articles, and periodically re-assesses these articles, until a real editor steps in and overrides the assessment. The approach would be:

Projects	The bot adds a project template to the article talk page for each project that AlexNewArtBot identifies with a score over 100, or for the project AlexNewArtBot scores highest. The template includes a new |autoassess=auto parameter. This: adds text like "This assessment was done mechanically by AutoAssessBot" to the template (linking to an explanation) and puts the talk page into Category:Automatically assessed articles/auto.
Quality	The bot calls on mw:ORES#Assessment scale support to assess quality for each project. This is machine-learning software that does a good job of making assessments similar to those made by humans based on analysis of various properties of the article – although it may make mistakes.
Importance	The bot assesses importance based on number of inbound links from articles: Up to 10 = Low; 11–99 = Medium; 100 or more = High.

This method will often give identical or similar results to those of a typical drive-by assessor. The benefits are:

• The bot will reduce the workload, since assessors now only have to tweak assessments they think are wrong, then change to|autoassess=noto show that the bot has been overridden.
• An editor may show they have reviewed and agreed with an automatic assessment by changing to |autoassess=ok. This will take the article out of Category:Automatically assessed articles/auto (which need review) and put it into Category:Automatically assessed articles/ok (reviewed).
• Newbies will not be upset when they see a bot has assessed quality based on an algorithm, where they might be upset if a human had decided their work was junk
• The bot will run periodically until a human overrides it, so will update its assessments. Human assessors typically do not review and adjust their initial assessment
• The bot's algorithm can be steadily refined, for example to consider results of Flesch–Kincaid readability tests, with the goal of steadily reducing the number of human interventions needed.

Again, as soon as a human editor changes to |autoassess=no the bot stops re-assessing. Real editors remain fully in control. Aymatth2 (talk) 18:58, 4 April 2018 (UTC)

Comments on automated article assessment?

Quality assessments: How do the WMF devs plan to implement ORES article quality assessments? If they are working toward integrating it with the Mediawiki software itself, then we should probably not develop a hackish bot that does the same thing but worse. Native integration is what they already went for with ORES New filters for edit review. You asked them but didn't get a reply. You should definitely hear from them before us.

Importance assessments: My hunch is that it will be far easier to come up with working solutions for quality than importance (case in point: ORES does quality but not importance). Your proposal doesn't seek to answer the following: unlike quality assessments, importance assessments are supposed to be different for different projects. For instance, "Nightswimming" (Awake), on the Main Page a few days ago, is Top importance for WP:AWAKE, and Low importance for WP:TV and WP:USA; an episode is obviously more important to a project that focuses solely on that series than for one that has as its scope the total history of a broadcasting medium or an entire country. Your bot would crank up the importance of this article for WP:TV and WP:USA, into High and downgrade it for the only directly relevant project. There are so many problems with gauging importance from incoming links that entertaining them is not worth the effort. – Finnusertop (talk ⋅ contribs) 13:51, 5 April 2018 (UTC)

To the first point, ORES seems designed as a generic machine learning tool that can be trained for this and various other tasks. The write-up implies that use on a given language wiki is up to that wiki. Obviously feedback from the ORES people would be welcome. If they are planning to build it into the Mediawiki software so it can do what is proposed, that would be great. The idea here is to get agreement from the people here that it would be a good idea, and then the best implementation approach can be worked out. Aymatth2 (talk) 21:37, 5 April 2018 (UTC)

There are about 20 inbound links to Nightswimming (Awake), which the bot would rate as mid importance. That typically means something like "Subject is only notable within its particular field or subject and has achieved notability in a particular place or area", the default definition used by WP:Wikiproject Television and WP:Wikiproject United States. The article meets that criterion. AlexNewArtBot does not support Wikipedia:WikiProject Awake, so it would take a human to assess importance for that project. A guess based on number of inbound links is just a guess, as is the ORES assessment, but if they get it right much of the time, it is worth recording the guess. Then a human can review and correct if needed. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)

The purpose of quality assessments is to help project members prioritise work. This could involve upgrading the quality of important but low-quality articles, or pushing up high-quality articles to GA or FA status. If ORES says an article seems poor quality, and the number of inbound links suggests it is important, that is probably useful even if a strict reading of the criteria would say quality is a bit higher and importance a bit lower. See Wikipedia:WikiProject assessment#Statistics: there is a backlog of over 570,000 articles to be assessed, about 10% of the total, up from 552,983 in May 2017 per Wikipedia:Assessing articles#Statistical analysis. A rough assessment that can be refined by a human any time is better than no assessment at all. Aymatth2 (talk) 15:35, 5 April 2018 (UTC)

This idea sounds great. Have you seen User:Nettrom's work on m:Research:Screening WikiProject Medicine articles for quality? I found that it sometimes slightly over-rated articles that had long lists of refs, or long bulleted lists, but its stub ratings were spot-on, and if it had a gap of two classes or more, then the current assessment was always wrong.

There's more that I'd like to see a bot doing with assessments. For example, at Category:Unassessed medicine articles, every single article about a person and organization needs not just the quality rating, but also |importance=Low and |society=yes. Even if the bot could tag only stubs about people this way, it could halve the amount of work that needs to be done manually. WhatamIdoing (talk) 04:42, 8 April 2018 (UTC)

I did not know about User:Nettrom's work. It does not surprise me that many assessments were wrong. Partly that is from drive-by assessors who think: "1-2 paras = Stub/low, else = Start/low", partly from failure to reassess after improvements are made. Once the bot gets settled down there may be a lot of refinements both to the scoring algorithm and to adding more data. Project-specific rules like "individuals and hospitals default to Low for WikiProject Medicine" could be added. I would like to start simple though. Aymatth2 (talk) 14:22, 8 April 2018 (UTC)

This is a really interesting proposal, Aymatth2! Thanks to WhatamIdoing for pinging me in this discussion, otherwise I would probably not have noticed it. The proposal is right up my alley and describes a setup that I'm fond of, having a bot propose some low-cost changes that a human can review. WhatamIdoing already pointed to the pilot study we did with WPMED on reassessing stubs, where we learned a few important lessons about how to set things up so it finds a good selection of candidate articles.

I thought I'd also mention a couple of related things. First is SuggestBot, which I run. When the bot posts suggestions it also adds info on page views and article quality (both predicted and currently assessed) so that editors can prioritize their work in the way that best suits them, and reassess the article if it's needed. One of the comments that sometimes comes up is "Why did it recommend this to me, it's not a stub?", which is an example of the challenge of keeping assessments up to date.

Secondly, I did a project with Aaron Halfaker a year ago, where we worked on building a model for predicting article importance. There's more information available on the project's research page on meta. During that work, we ran into the challenge that Finnusertop mentions: importance is WikiProject-specific. We therefore ended up training a model for each WikiProject so that it learns their preferences. We again collaborated with WPMED during that project and also incorporated a set of rules that cover their specific preferences on importance ratings for certain types of articles. Using Wikidata to identify the type of entity an article is about, we could then automatically rate all articles about people to Low-importance, for example. The results of that project were promising and suggested that article importance predictions could be useful when they're given as candidates to a human reviewer.

Again, really interesting proposal, it's precisely the type of thing that the wp10 model in ORES was built to help out with. Hope some of this info is helpful, let me know if there are questions about any of this! Cheers, Nettrom (talk) 15:53, 9 April 2018 (UTC)

@Nettrom: I had no idea how much had been done already. It seems that maybe it would not be too hard to clone and tweak SuggestBot to become a first version of ArtAssBot AutoAssessBot. (?) Aymatth2 (talk) 17:49, 9 April 2018 (UTC)

How is ORES trained? I suspect a lot of assessors rate quality based on length rather than value to readers, and importance on gut feel rather than project criteria. If we train ORES using these dud assessments, it will learn wrong. Ditto with stale assessments. I started Marcel Lucet the other day with a fairly basic first version, which was assessed as Stub. I expanded it, but it is still Stub and likely to stay that way. We don't want to teach ORES that is what a stub is like. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)

Length matters, and is a fairly good predictor overall. But I think Nettrom's work is looking at multiple criteria, such as the number of refs and maybe section headings. WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)

A Start-class article "Provides some meaningful content, but most readers will need more", while a C-class article is "Useful to a casual reader". Start may also be weaker than C on citations, style, etc.. For simple topics the casual reader will often be satisfied with a short, readable and accurate article. I agree that length and quality often go together, but would prefer that ORES did not give length excessive weight. Aymatth2 (talk) 02:26, 10 April 2018 (UTC)

We can always improve the training-set for ORES' article quality model. If you are interested in doing the work to check the set of assessments used to train ORES, we can improve ORES' prediction quality. We have a system called m:Wiki labels that makes manually assessing random samples for training ORES as easy as possible. I'm thinking we can get decent fitness with 150 observations for each quality class (150 * 6 = 900). We can start by sampling article versions from the labels (WikiProject assessments) we already have in Nettrom's original dataset. It would be a lot of work, but it would be a great way to validate the model.

Alternatively, you could just test out what we have already. It seems to work very well in practice (based on years of feedback). We can always come back to re-train it when/if you identify consistent problems. --EpochFail (talk • contribs) 14:55, 10 April 2018 (UTC)

Fair enough. If the assessments are usually good, that is what is needed. There will always be cases where it gets it wrong, but those can be fixed by a reviewer. Maybe after the AutoAssessBot has been running for a while it would be useful to look for patterns in articles where the ORES assessment has been manually overridden. Aymatth2 (talk) 16:12, 10 April 2018 (UTC)

The auto-classification of importance research results are a bit discouraging. I felt that if ArtAssBot AutoAssessBot only assigned an article to a project when AlexNewArtBot gave it a high score for the project, number of inbound links would be a reasonable proxy for importance. This would avoid the problem of giving Winston Churchill Top importance on WikiProject Architecture (he built garden walls as a hobby). Maybe that aspect of the bot has to wait for development of a better importance prediction model. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)

Assuming ArtAssBot AutoAssessBot was built and settled in, I would like to let it rip on the 570,000 unassessed articles. After that, it could run through all articles adding |autoassess=ok where it came up with the same result as the existing quality/importance assessment for a project. But I have no idea how to deal with the remaining millions of articles with dud or stale assessments. Aymatth2 (talk) 17:49, 9 April 2018 (UTC)

You might want to consider a less potentially offensive name for your bot. ;-) WhatamIdoing (talk) 23:37, 9 April 2018 (UTC)

Oops. AutoAssessBot, it should be. (As an ex-Brit I tend to think of "ass" just as a useful beast of burden.) Aymatth2 (talk) 01:45, 10 April 2018 (UTC)

I'm already doing something similar to this at AFC. It would be fairly trivial to set something up to use the wp10 model to auto-assess talkpages. SQL^{Query me!} 19:49, 10 April 2018 (UTC)

I ran wp10 over CAT:FA, results were interesting. SQL^{Query me!} 22:17, 10 April 2018 (UTC)

That is very encouraging. The results seem excellent. Aymatth2 (talk) 13:53, 11 April 2018 (UTC)

AutoAssessBot recap

There seems to be general support for this proposal, since it is very much in line with other work on auto-assessment using ORES. To recap how the bot would work after adjusting for feedback above:

• AutoAssessBot checks articles in two different modes:
  • Soon after an article has been created, and soon after significant changes have been made. "Soon after" allows for a flurry of edits where the final result is checked
  • Scan through all articles (possibly first all that have never been assessed, then all others)
• For each article it determines relevant projects using the AlexNewArtBot algorithm. Some experiment may be needed to find the best threshold for deciding an article is relevant to a project
• If the article does not have a talk page it creates one, with templates for the selected projects
• If the article does have a talk page, it adds templates for selected projects that are not yet on the talk page, and checks existing project templates to see if they should be updated
• A new project template parameter |autoassess= is used to control bot assessment
  • When the bot adds a project template, it sets |autoassess=auto, meaning the assessment has not yet been checked.
  • A reviewer may approve the project assessment by changing the parameter to |autoassess=ok.
  • A reviewer may change the project assessment and change the parameter to |autoassess=no, meaning the bot has been overridden.
  • A reviewer may change the parameter to |autoassess=skip, meaning despite the high AlexNewArtBot score this article is irrelevant to this project
  • The talk page is placed in a category for each project / autoassess value. Thus |autoassess=ok for WikiProject Biography would put it in Category:Autoassess ok biography articles.
• When the bot checks an existing project template, it skips it if |autoassess=no or |autoassess=skip, otherwise it refreshes the assessment if changed
• The bot creates or refreshes the quality rating on a project template using the result supplied by ORES
• At this point, the bot leaves the importance rating blank (or unchanged). More experiment is needed to find an algorithm that would give good enough results
• |autoassess=auto or |autoassess=ok add a note on the template saying, e.g., "This assessment was done mechanically by AutoAssessBot"

This is a tentative outline to be refined in the next step. Aymatth2 (talk) 13:53, 11 April 2018 (UTC)

AutoAssessBot next steps

@Finnusertop:, @WhatamIdoing:, @Nettrom:, @EpochFail:, @SQL:

I do not feel well-qualified to implement the bot, having never done one in the Wikipedia environment before. I assume there would be some sort of project set-up and standard steps to define specs, activities, acceptance criteria, testing, implementation. Any input on the next steps? Any volunteers? Aymatth2 (talk) 13:54, 11 April 2018 (UTC)

Aymatth2, I recommend you put all of the details of a WP:BAG proposal together in a sandbox page. Please include a meaty description of how it will behave and what you expect the outputs to look like. If we don't find a taker by the Wikimedia Hackathon (May 18th), I can pitch it to technical contributors there. It would be great if you would be interested in doing some work as a bot-maintainer. Do you have any background in python/pywikibot? Either way, by putting the BAG proposal together, you'll be saving someone some time spec'ing it out and helping them understand what type of work they are signing on for when picking up this project. --EpochFail (talk • contribs) 14:12, 11 April 2018 (UTC)

Thanks - I have started Wikipedia:Bot Approvals Group/nominations/AutoAssessBot. If anyone wants to add / improve it, feel free. Aymatth2 (talk) 17:42, 11 April 2018 (UTC)

Moved to Wikipedia:Bot requests/AutoAssessBot since it is not a WP:BAG nomination. — JJMC89 (T·C) 03:31, 12 April 2018 (UTC)

If it helps - here's the code I use to pull ores (and the query to grab the appropriate pages): User:SQL/FA-Ores/getOres. IIRC, ORES is limited to ~2 requests / second, but each request takes on average ~1.1s to complete. SQL^{Query me!} 15:32, 11 April 2018 (UTC)

I did not even know SQL had a LIKE operator. Shows how much use I would be! Aymatth2 (talk) 17:42, 11 April 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RFC to dissolve Wikiproject Stub Sorting

There is a clear consensus against dissolving Wikipedia:WikiProject Stub sorting.

Cunard (talk) 04:26, 6 May 2018 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Wikipedia:WikiProject Stub sorting (edit | talk | history | links | watch | logs)

Wikipedia:WikiProject Stub sorting/Proposals (edit | talk | history | links | watch | logs)

Wikipedia:WikiProject Stub sorting/Criteria (edit | talk | history | links | watch | logs)

Wikipedia:WikiProject Stub sorting/Naming conventions (edit | talk | history | links | watch | logs)

Wikipedia:WikiProject Stub sorting/Discoveries (edit | talk | history | links | watch | logs) - used to point out BOLD editors who choose to apply IAR to the WSS process

Wikipedia:WikiProject Stub sorting/Stub types (edit | talk | history | links | watch | logs) - move to Wikipedia:Template messages/Stubs

Template:Stubsort (edit | talk | history | links | watch | logs) - used to bug people who use the generic Template:Stub

Template:Stub sort (edit | talk | history | links | watch | logs) - same as stubsort

Template:WPSS-cat (edit | talk | history | links | watch | logs)

Template:WPSS-new (edit | talk | history | links | watch | logs)

redundant over-specific templates - {{underpopulated stub category}}, {{very large stub category}}, {{deprecated stub}}

Do we really need all this bureaucracy for stub templates? I don't think so. You want to create a new stub template? You have to go through WSS first. What's that, you've decided to just be bold and create the template? Too bad; it's going to TFD, where the 5 active TFDers will ignore it, causing it to be automaticallly deleted. I propose that WSS be shut down and the stub template process be made much less process-y, per the Esperanza precedent. (This was originally on MFD, but I was told to go here, despite MFD being where the dissolution of Esperanza was discussed.) Lojbanist ^{remove cattle from stage} 01:15, 6 April 2018 (UTC)

WP:WSS is for coordination. Amongst other things, it is used to ensure that we don't get two stub templates (or two stub categories) created to do the same job; it ensures that template and category names are harmonised and consistent; it ensures that the category tree has a logical structure. The WP:WSS/P process is there to discourage the proliferation of stub templates (or stub cats) that have little potential for use. --Redrose64 🌹 (talk) 10:04, 6 April 2018 (UTC)

• I agree with Redrose64. WPSS serves a valid purpose and less "process-y" will likely result is more duplicates and non-maintained categories. It's like proposing to dissolve WP:WPMOS because some people don't like following the MOS and they feel like it's too bureaucratic to have so many rules on how articles look like. The nominator also fails to mention that WikiProjects to organize certain aspects of the project are common (see Wikipedia:WikiProject Council/Directory/Wikipedia#Maintenance). Regards SoWhy 11:07, 6 April 2018 (UTC)

• I do agree that if the system continues to exist, there needs to be coordination or it'll become a mess. But TBH I've never understood why there's a system of stub sorting - it all seems very redundant to wikiproject ratings and categories there (though it does provide more specificity, I dunno how much it is actually helpful)

Giving some actual and specific examples of the "bad" that they do would help (e.g a link to specific TfDs etc) Galobtter (pingó mió) 11:30, 6 April 2018 (UTC)

They're much easier to navigate than WikiProject banners. It's how I first got involved with my early modern conclave project. TonyBallioni (talk) 12:01, 6 April 2018 (UTC)

• ICYMI, details of the "Esperanza" project mentioned by nom can be found here. Pegship (talk) 13:52, 6 April 2018 (UTC)

• To add, here's the MfD (which I closed) where this was initially raised. ~ Amory (u • t • c) 18:43, 6 April 2018 (UTC)

• Stub templates and categories do not affect the content of Wikipedia, but rather its organization, and both the project and its output are easily ignored by users and editors, who are welcome to go on their merry ways. The pages listed here for comment could certainly use some review and possibly some cleanup; some of them are long-abandoned or have already been redirected to more appropriate pages. (Template:Stubsort (edit | talk | history | links | watch | logs) and Template:Stub sort (edit | talk | history | links | watch | logs) have not been implemented since 2011 and aren't used on any article pages; Wikipedia:Template messages/Stubs already redirects to Wikipedia:WikiProject Stub sorting/Stub types (edit | talk | history | links | watch | logs); Wikipedia:WikiProject Stub sorting/Criteria (edit | talk | history | links | watch | logs) consists of an explanation as to why the page was discontinued and where to find the current discussions.) tl;dr: WPSS serves a purpose used and valued by many editors; if deleted or "shut down", I would like to know the form and procedure that would be implemented to serve its function. Pegship (talk) 23:31, 6 April 2018 (UTC)
• I have not seen an issue with this WikiProject's modus operandi and therefor oppose this proposal.--John Cline (talk) 04:00, 7 April 2018 (UTC)
• I don't know enough about this WikiProject to have an opinion about whether it should be dissolved, but I hope someone who does will respond to Lojbanist's concern about new stub-related templates being sent to TFD, ignored and automatically deleted. If this is actually happening, perhaps some kind of tweak in the process is in order.—Anne Delong (talk) 12:20, 7 April 2018 (UTC)
  • As a long-time member of WPSS, I can tell you that it's not our practice to arbitrarily delete or nominate for deletion a stub template or category that was created in good faith (and sometimes not so good faith). Believe me, we're sticklers for consensus. If there has been an issue such as those referred to by nom, I'm unaware of it, and I'd appreciate someone bringing it to the attention of me or any other stub sorter. I have looked into nom's past contributions and comments (under both usernames) and can't find any reference to stub-related issues. Pegship (talk) 18:17, 7 April 2018 (UTC)
• WSS has been around since 2004, and a lot of its processes date from when the project and Wikipedia as a whole was more active. Perhaps if it is to stick around, it should be optimized to operate with fewer people required to approve things. --Rschen7754 18:38, 7 April 2018 (UTC)
• Oppose the specific motivation cited (that stub templates not approved by this group are often deleted at TfD) isn't helped by dissolving the group, and I see no good reasons to get rid of this system. There must be some place to discuss stub templates. power~enwiki (π, ν) 18:19, 8 April 2018 (UTC)
• Oppose While some parts of the project may be outdated/inactive, the project as a whole goes on. -- Iazyges Consermonor Opus meum 13:37, 9 April 2018 (UTC)
• Oppose I find stub sorting to be helpful in editing and improving articles. Any issues that are a "downside" to the process can be improved or otherwise handled rather than obliterating the entire system.--Paul McDonald (talk) 14:45, 11 April 2018 (UTC)
• Oppose Stub sorters may be steadfast in their demands that NPPs stubsort instead of just mark as a stub even though that isn't their job, but stub sorting is helpful. L3X1 ◊distænt write◊ 14:55, 11 April 2018 (UTC)

Note: As the templates that "demand" sorting above have been unused for 8+ years, I'll be nominating them for deletion once this discussion is closed. Thanks for your positive comment. Pegship (talk) 16:51, 11 April 2018 (UTC)

Pegship If that was supposed to be sarcastic and mean something else, it went over my head. L3X1 ◊distænt write◊ 21:53, 11 April 2018 (UTC)

L3X1 - No sarcasm or meanness meant! I'm mildly chagrined that those templates still exist, and my comment on your positive note was meant in good faith. (I tend to avoid use of the word "support/ive" in these discussions unless I'm presenting my own POV.) Cheers, Pegship (talk) 22:45, 11 April 2018 (UTC)

• Keep the WikiProject. That said, if there are some specific parts of stub sorting that you feel should change, feel free to discuss that, but eliminating the entire wikiproject is simply bat-shit crazy. Oiyarbepsy (talk) 12:55, 18 April 2018 (UTC)
• Oppose and speedy close per WP:SNOW. Kudos for trying to reduce WP's bureaucracy, but I don't think this is the best way to do it. — pythoncoder  (talk | contribs) 20:34, 18 April 2018 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: Ending the system of portals

Moved to Wikipedia:Village pump (proposals)/RfC: Ending the system of portals

 – Hi everybody. Because this discussion has become so lengthy (400,000+ bytes), I have moved it to a subpage of the village pump so that the village pump is more accessible. I apologize if any confusion has been caused by this. Mz7 (talk) 01:59, 18 April 2018 (UTC)

2018 FIFA World Cup Cities Regions

Dear colleagues!
Wikimedia Russia (WMRU) is a co-organizer of Discover Russia. 2018 FIFA World Cup Cities & Regions Wiki-Marathon (March 14 - July 15). Targeted CentralNotice banner campaign is initiated to inform Wikipedia, Wikivoyage & Wikimedia Commons visitors from among residents & guests of the Russian Federation about this opportunity.

• Draft Banner (EN)

Discover Russia. 2018 FIFA World Cup Cities & Regions

Write articles, upload images and win prizes!

• Terms: 20 May - 4 June 2018
• Audience: Anonymous visitors
• Wikipedia editions: en-ru-tt and possibly others, who will have local language landing page (though we mainly concentrate on Wikipedias in the languages of Russia)
• Weight & impression: low, TBD by CN-admins, preferably no more than 3-4 impressions per week (Limit traffic 3% like WMDE Spring 2018?).
  

We invite you to express your opinion, voice your proposals about improving the banner or its settings, here or (better) at banner request page in the language of this notification. We will be grateful if you can help us to create or improve the banner and the project landing page in Your language.
On behalf of WMRU Banner Program, respectfully--Frhdkazan (talk) 20:51, 20 April 2018 (UTC)

Wikimedia CEE Spring 2018 Russia

Dear colleagues!
Wikimedia Russia (WMRU) is a local organizer of the IVth Annual International Wiki-Marathon CEE Spring 2018 (March 21 - May 31), run by Wikimedia movement affiliates from Central and Eastern European countries. Targeted CentralNotice banner campaign is initiated to inform Wikipedia visitors from among residents & guests of the Russian Federation about the project.

• Banner (EN)

CEE Spring 2018 is from March 21st until May 31st.
Write articles and win prizes!

• Terms: 5-19 May 2018
• Audience: Anonymous visitors, as well as relatively active registered users of Wikipedia (<50 edits/month)
• Wikipedia editions: en-kk-myv-ru-tt and possibly others, who have local landing page (though we mainly concentrate on Wikipedias in the languages of Russia)
• Weight & impression: low, TBD by CN-admins (Limit traffic 3% like WMDE Spring 2018?).
  

We invite you to express your opinion, voice your proposals about improving the banner or its settings, here or (better) at banner request page in the language of this notification. We will be grateful if you can help us to create or improve the banner and the project landing page in Your language.
On behalf of WMRU Banner Program, respectfully --Frhdkazan (talk) 23:25, 20 April 2018 (UTC)

Locations in fiction, fictional locations, and settings

I want a pace to find about fictional locales for literature....

Like a meta-wikia.....

How can this not exist please help me make it a thing?? — Preceding unsigned comment added by 82.132.245.224 (talk) 13:19, 23 April 2018

We already have categories with titles such as "Fictional places in the United Kingdom" and "Fictional places in Europe". If you want an article rather than a category to cover such places, then why not start one? Vorbee (talk) 16:50, 23 April 2018 (UTC)

@Vorbee: We already have articles such as List_of_fictional_countries, List_of_fictional_city-states_in_literature, and List_of_fictional_towns_and_villages. Can you clarify what you are looking for? RudolfRed (talk) 03:05, 24 April 2018 (UTC)

We also have several categories by setting, under Category:Works by setting. Although several of them are underpopulated. Dimadick (talk) 06:23, 24 April 2018 (UTC)

A publicly viewable, tiered system of grading editors

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Currently Wikipedia grades articles but not individual editors. If we add a link next to each editor's name, viewable in article edit history and on that editor's userpage, of that editor's reliability (grade), it will be much easier for other editors to spot vandalism. This will also reward editors for good behavior. Each editor's reliability (grade) is based on a variety of factors, including past edit wars, quality of past edits, support from administrators, education, and age of the user account. I already use all these factors to assess an editor's credibility. Brian Everlasting (talk) 21:51, 26 April 2018 (UTC)

There's lots of evidence algorithmic scoring of people is a net negative. Algorithms are not infallible, opaque, can lead to distortions by gaming the system, create unfair inequalities. It puts huge power in the hands of the algorithm makers - imagine the battles over that turf, and the games users will play to manipulate their scores. See Weapons of Math Destruction. There are barnstars, FA stars, banners showing time on project etc.. voluntary disclosures to help others judge reliability of a user. -- GreenC 22:24, 26 April 2018 (UTC)

As one of the people who would come near the top of whatever scheme someone comes up with for something like this, a big no to this. This will greatly contribute to WP:VESTED mentalities. My contributions are no more special than anyone else's. The only thing I need so my edits aren't spotted as vandalism is to not vandalise. For the RC/NP patrols, that's what autoconfirm/extended confirm are for. Headbomb {t · c · p · b} 23:00, 26 April 2018 (UTC)

• The basic concept for this re: vandalism already exists as meta:User:Krinkle/Scripts/CVNSimpleOverlay. Just add it to your global .js. Agree with headbomb on creating any new ranking system, which I would oppose for the same reasons he does. TonyBallioni (talk) 23:04, 26 April 2018 (UTC)
• See Clay Shirky's talk, "A Group is its Own Worst Enemy", for a discussion of what a social community needs to succeed, including a way to recognize reputation. However he says that providing a way to invest in an identity is sufficient; the human brain will do the appropriate weightings. Sure, relevant data could be made available, but each editor can figure out how to take into consideration. isaacl (talk) 23:49, 26 April 2018 (UTC)
• We already have this, it's called edit count! Sarcasm aside, I don't wish to pile-on, so I'll just say that if you already use all these factors to assess an editor's credibility then, well, there's no need is there. The system works! ~ Amory (u • t • c) 01:00, 27 April 2018 (UTC)
• Agree with User: GreenC that we already have barnstars, so in a sense, we already have this. At the other end of the extreme, if a user has been responsible for lots of vandalism, could the user be blocked?Vorbee (talk) 08:20, 27 April 2018 (UTC)
  • Yes, we block vandals, we usually give them up to four warnings, but it doesn't take a lot of vandalism before we block an account. ϢereSpielChequers 18:24, 27 April 2018 (UTC)
• No. This seems like a terrible idea; automated grading systems would be subject to gaming in both directions (i.e. trolls can destroy the reputation rating of good users, terrible people could give the illusion they are good people by playing with the algorithm, etc.) --Jayron32 13:16, 27 April 2018 (UTC)
• Yeah, this just isn't methodologically feasible. There's much too much to take into account, a lot of which is off wiki for many users, and it's insurmountably subjective overall. GMG^talk 13:22, 27 April 2018 (UTC)
• I don't think this would work well. It's subjective: if you like diligent gnomes, I'm a ★ Good Editor; if you want a content creator I'm not. We'd also be implicitly rating a lot of people as Not Good Editors, which can be offputting, especially if they're newish users who simply haven't had a chance to prove themselves yet. Certes (talk) 14:57, 27 April 2018 (UTC)
• This is impossible to do well, and harmful if done poorly. So we shouldn't do it. Also, in most topic areas, most editors that aren't straight-up vandals are good editors. power~enwiki (π, ν) 18:17, 27 April 2018 (UTC)
• Absolutely not. We don't need to turn Wikipedia into a proto-Black Mirror dystopia, thanks. It'd be useless anyway as people would find ways to game the system. Richard⁰⁶¹² 19:14, 27 April 2018 (UTC)
• Oh God No. I can hardly wait to see the gaming that will ensue. Actually, I can wait. --SarekOfVulcan (talk) 19:16, 27 April 2018 (UTC)
• Sounds like a great plan. Give me a week and I'll work my way to the top 5% of the list. Legacypac (talk) 21:36, 27 April 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC on notability of compilation albums

I've started an RFC at WT:NMUSIC about the notability of individual compilation albums from large series, such as Now That's What I Call Music!. Your opinions and !votes are requested. power~enwiki (π, ν) 20:22, 7 May 2018 (UTC)

I've closed this as SNOW oppose. power~enwiki (π, ν) 16:20, 9 May 2018 (UTC)

Automatic welcome messages for new IP editors and new Registered editors

I propose that a Wikipedia bot should automatically welcome all new IP editors and new Registered Users at their talk pages. At present, there is no such welcome system. Instead, we have a very unevenly distributed system of individual editors attempting to welcome some, but not all, new users and IPs. Brian Everlasting (talk) 03:35, 26 April 2018 (UTC)

You may wish to review Wikipedia:Perennial proposals#Use a bot to welcome new users. Anomie⚔ 11:41, 26 April 2018 (UTC)

@Brian Everlasting: User:HostBot invites new users to the Teahouse RudolfRed (talk) 21:30, 26 April 2018 (UTC)

IPs by their nature need an uneven system. Some IPs are stable over long periods of time, years even, others are reset in hours. There is no point sending a welcome to a goodfaith IP editor unless their address seems stable, and that requires human judgement. ϢereSpielChequers 11:00, 29 April 2018 (UTC)

Community de-adminship processes

Considering the community has the power to appoint admins, it is only fair that we have a procedure at hand to hold our admins accountable but every community de-adminship proposal has failed, some because the discussion is heavily derailed by a few editors, others due to no consensus. I simply think that this is a necessary process for the validation of WP:ADMINACCT. Sure ArbCom can, but that process takes months at end and sometimes doesn't even have an ideal outcome, they're not the community afterall. A lot of admins are concerned with the fact that they make enemies while their tenure here and that will severely skew the results in such a process, but then the reverse can be true as well, essentially making it a fallacious argument. I don't want such a process to lead the witch hunt against admins who might've made a few errors in judgement but a process to hold the ones accountable who have gamed the system in one or more ways and repetitively abused the trust of the community under the radar. Effectively, a process to be made without the ArbCom cogs to take forever. I'd like to hear more thoughts on this matter. --QEDK (後 ☕ 桜) 07:21, 15 April 2018 (UTC)

The thread at ANI which required me to ask: link. This thread is to elicit new opinions on the matter just, and see if anything has changed from the status quo and if we have the cause to make a new proposal. --QEDK (後 ☕ 桜) 07:25, 15 April 2018 (UTC)

Another navel-gazing discussion would not be helpful. It is obvious that admins who actively work to repel unhelpful editors get a lot of enemies, and such admins would get a lot of heat from socks whom we would have to pretend were good faith editors raising issues of concern. I would prefer that the admins spend their time repelling unhelpful editors rather than spend time arguing with their friends. No one has shown a discussion involving an admin which failed to get the correct outcome within a reasonable time. Arbcom would desysop an admin in under an hour if it were really necessary (they would discuss whether the emergency desysop was warranted). Johnuniq (talk) 07:43, 15 April 2018 (UTC)

You seem to suggest a "deep state" network of socks would mysteriously arise and we will assume they are here in good-faith when simply they have no credibility for such. I'm sure the state of the community is not so dire and you're exaggerating. ArbCom doesn't make emergency desysops, it's still at the behest of stewards/office@WMF. ArbCom's functioning is the essential defining factor of a bureaucracy, no one's saying they can't do their job, but are they doing it well, not as much as we would want, such is the description of the job. --QEDK (後 ☕ 桜) 07:58, 15 April 2018 (UTC)

That would be somewhat resolved by limiting desysop discussions to an WP:ECP-locked page (I'd say just autoconfirmed, that's really not a hurdle). IP editors and newer accounts could still make arguments and present evidence on the talk page, and if they have any pretense of validity then someone who can edit the ECP-locked page will carry them over. If the talk page gets flooded with "get rid of him!" spam, it could go into pending changes (with the understanding that any good-faith comment, no matter its position, should be approved). No comment one way or another on the original topic, just something that'd prevent pretty much any reasonable claims of sock influence without completely silencing grievances by newer or anonymous users. Ian.thomson (talk) 17:00, 15 April 2018 (UTC)

Personally I suppose putting the same system of RfA sounds about right, the idea of accountability. The bottom line is, some people are malicious, things will happen, but in the course of time, it will not even reflect in the process. --QEDK (後 ☕ 桜) 19:01, 15 April 2018 (UTC)

[ec] Two of the things we would have to consider:

• We do not need kangaroo courts. How would these be prevented?
• How do we deal with inappropriate requests? Indefinite blocks? Who decides? · · · Peter (Southwood) ^(talk): 08:01, 15 April 2018 (UTC)

Admins ARE kangaroo courts. HiLo48 (talk) 21:50, 17 April 2018 (UTC)

If you have a plausibly workable idea, describe it somewhere and provide a link, then we can have a discussion about an actual proposal. · · · Peter (Southwood) ^(talk): 08:01, 15 April 2018 (UTC)

That's not happening, most opposes are simply based on "we do not want such a process" primarily, so having a proposal without addressing why not would be pointless. There have been workable ideas time and again but it's hard to change beliefs when they are based on assumed ideas. --QEDK (後 ☕ 桜) 09:25, 15 April 2018 (UTC)

Re your above comment about desysops, the procedures for an Arbcom emergency desysop are here. Of course it involves an arb contacting a steward to perform the operation. Re "workable ideas", if starting a discussion it might be worth linking to a couple of such workable ideas, preferably with a mention of how they would avoid adminship becoming a beauty contest where admins who don't spend most of their time charming their voters get replaced by those who do. Johnuniq (talk) 09:46, 15 April 2018 (UTC)

Johnuniq, I get your point, more than a fair number of these proposals have arose and all of them have gone down, with some actually being pretty good, or some close to consensus even. But, with the community (+ admins) not ready to even accept the idea, making a proposal at any point is useless, considering the same group will shoot down the idea even if it had any merit (since in the end, it's about opinions, isn't it). --QEDK (後 ☕ 桜) 18:56, 15 April 2018 (UTC)

This is a perennial proposal. As the initiator of the thread at that link, I knew from the start that it was a non-binding measure. It was designed to bring attention to an issue, knowing that it wasn't the forum couldn't actually remove admin rights, but useful to see if others agreed that something wasn't working out and to incubate some sort of solution. The situation resolved itself, and I think the project is better for it, but I don't think there is ever going to be agreement for a ground-up community-initiated removal process exactly because admins do tend to perform actions which people could hold grudges against. There may be hope for a peer-level process where other admins can initiate it. -- Netoholic @ 10:17, 15 April 2018 (UTC)

That's my point. If a few editors who hold grudges could skew results, it could well happen at the RfA stage and why are we being so protective in the case of de-adminship, when it's the community vs. a few editors with grudges. --QEDK (後 ☕ 桜) 16:48, 15 April 2018 (UTC)

The "what about the editors with grudges" argument holds no water whatsoever. Stewards are confirmed on a yearly basis and it has never been a problem - even if it were, you can have a system with safeguards to prevent that sort of abuse. A community-based desysop procedure makes sense. The community elects admins, and it should have the power to remove them. If enwiki were to seriously consider this, I would offer up a system similar to that used on Commons and Wikidata: 1) an ANI/AN thread regarding the misuse of sysop tools gets consensus to initiate a confirmation RFA, then 2) a confirmation RFA is held, requiring a simple majority to remove sysop access. There's no need for some heavily bureaucratic system like those proposed in the past. And if you want more safeguards, replace the simple majority requirement with consensus to remove at the confirmation RFA as well. -- Ajraddatz (talk) 17:06, 15 April 2018 (UTC)

Yeah, even if there are grudges, they can be enough to sink an rfa, dragging it down from say 75% to 60% etc, but a majority/supermajority voting to remove can't be from grudges, considering especially that usually there are 150+ people !voting. Galobtter (pingó mió) 17:16, 15 April 2018 (UTC)

Exactly my opinion. Every argument along the line seems like the very definition of exaggeration to me. With a community to back, I'd say unless you've blatantly abused the right, it's harder to lose than gain the rights, considering everyone wants good admins to stick around and with the dwindling numbers of RfAs, they'd be less inclined to vote for the sake of it, without evaluating merit and joining the sides of the few editors who hold grudges. I think the fact that (some) admins think the community will give in to that is a wrong thought in itself, considering they're the ones who picked you in the first place. --QEDK (後 ☕ 桜) 18:56, 15 April 2018 (UTC)

Ajraddatz, as much as I respect you, your comparison is not at all similar. The majority of participants at steward confirmations are individuals from projects that have admins and/or ‘crats, which means stewards have next to nothing controversial to do on the home projects of probably a super-majority of those participating in the discussion. Compared to example, en.wiki, where enforcing our text copyright policy has suddenly become controversial. TonyBallioni (talk) 22:00, 15 April 2018 (UTC)

Maybe, but you can still look at the community desysop proceedings on other Wikimedia wikis to see the same effect. On Wikidata, we've had one de-RFA and no abuse of the process. On Commons, almost all of their de-RFAs have been in-process and legitimate. The sort of abuse that people fear just doesn't happen in practice, at least to the extent of being able to change the outcome. -- Ajraddatz (talk) 22:29, 15 April 2018 (UTC)

The de.wiki process the 2015 RfC was based upon gives bad enough numbers to show that the concerns are not exaggerated, and I think that project is probably a better comparison to en.wiki than many of the others used. There is this theory that the reason the community has set higher standards at RfA is because of how difficult a desysop is, and that if we only make it easier to desysop, the RfA standards will become lower.

I don't think that is the case. I think what we would have would be a lot more people resigning the tools under a cloud rather than go through a process that may very well end in their favour and that the RfA process would still have ridiculously high standards. The net result here would be a project that is already struggling to get more admins to replace the attrition of inactive ones still not getting more people at RfA, and also losing more people who would rather resign than go through what is sure to be an unpleasant experience. I think any admin who has lost the trust of the community should resign, and that when there is a valid question as to if they do have community trust, ArbCom should desysop: I brought a case based on this principle. I just also believe that the already established community desysop procedure (which is what ArbCom is) works fine and has less negatives than any alternative that has been proposed. To paraphrase Churchill, it's the worst form of desysop except all the others. TonyBallioni (talk) 22:49, 15 April 2018 (UTC)

Yeah, but Tony, isn't the question - why you believe so? If an admin were to fear and resign, they would do so in every case, any kind of process - if an admin were to fear and resign, they already know their mistakes will get them desysoped. Community evaluation is faster, and gauges opinions better than ArbCom can, it holds admins accountable where we want them, rather than wait for Arbs to churn out the results after extensive off-wiki conversations. The RfA standards now have nothing to do with this, personally I dislike that the numbers have fallen to this dismal count, but if you want to fix that, this thread won't help. And attrition in admin numbers can only be fixed when we get more RfAs with a community more willing to accept them, not by keeping the few admins who might get de-sysoped due to a community referendum. --QEDK (後 ☕ 桜) 04:34, 16 April 2018 (UTC)

No, it would just mean that someone doesn't feel like going through an abbreviated show trial at an ANI-meets-RfA and that they have better things to do with their life than go through the hell that would be. ArbCom is slow and not fun, but at the very least, every party tends to be treated with respect. The idea I strongly get from your statement is that you are talking about a system where guilt would be assumed and the burden would be on the person up for review to prove they should retain advanced permissions rather those wanting to retain them to prove otherwise (it may not be your intent, but that is how it does come off.) That would be a radical departure from the current system, and one that I could not support. Additionally, I'll raise the point that any system such as this would make the unblockables phenomenon much worse than it already is. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)

That's an unpleasant idea. I would not entertain such an idea, I am only arguing for a community-deadminship process and assumed guilt is quite far from it. Why do you keep saying it like the community will lead the witch hunt against innocent admins who might've made mistakes, there's almost a nil chance that an innocent user will get caught up in community-based processes. I see that you support the ArbCom's take on sanctions but there's a certain group of people who undoubtedly are not, no system is perfect, but this certainly has to be more perfect that the process ArbCom is. The point is, an admin will not have to prove anything if they are innocent, it's the duty of the community to evaluate. --QEDK (後 ☕ 桜) 16:24, 16 April 2018 (UTC)

• I would support an amendment to policy where a thread can be opened at AN to request an involuntary RfA for current admins. If that thread is closed with a consensus for an RfA, then one is opened by a crat, without the accouterments of accepting the involuntary nomination. The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat. If the consensus is to oppose their adminship, then the bit will be removed by the closing crat. But opening one would require a consensus at AN, and an involuntary RfA for community confirmation cannot be opened by any one individual. GMG^talk 19:16, 15 April 2018 (UTC)

I would grant broad leeway within crat discretion for the timing of the RfA, which could be reasonably delayed if needed to accommodate the asking and answering of community questions by the nominated admin, and require that the AN thread be closed by a crat, as the person who is charged with then opening the broader community discussion at RfA. GMG^talk 19:26, 15 April 2018 (UTC) 

For further clarification, I've been thinking a lot about this exact issue lately. There is a central problem that we have essentially a type of landed aristocracy or peerage, at some level disconnected from the functional pragmatic use of the level of user access. Many of these are seasoned admins who were elected early on, and who have grown to be among our most valued community leadership, but we also have some current admins who absolutely would not pass an RfA in 2018 or even be considered for nomination for one. We have others who conduct themselves occasionally with general disregard for community norms, because the standard is whether you have passed an RfA ever, and not whether you can pass an RfA now.

The standard for desysop at ArbCom is spectacular disaster, and not consistent faithful use of the tools in accordance with community norms. So we reinforce a notion that so long as any admin who happens to be a disaster, can maintain the tools so long as that disaster does not become spectacular. That's a problem and it's one that fundamentally erodes trust in the corps and faith in the community. This would be an overall high bar for a re-RfA, where most comers would be turned away at AN, and most who proceed to a re-RfA would likely have already risen to the level of losing community trust, and would have their access removed. It answers the issue of individual grudges by requiring consensus for a discussion to even happen and at the same time, if that discussion does happen, it holds current admins to exactly the same expectations for conduct and competency as we do new admin candidates. GMG^talk 19:50, 15 April 2018 (UTC)

I like it, with the exception of the the role you give 'crats in starting the confirmation RFA. I think that the confirmation RFA should be started by someone who wants the admin in question to be desysopped, so they can present their reasons, rather than a bureaucrat creating the request as a procedural action. Plus, that also gives people some time to reflect after the AN thread is closed on whether a desysop discussion is really necessary. Of course, I would prefer this to the status quo. -- Ajraddatz (talk) 21:08, 15 April 2018 (UTC)

For additional context, you may wish to review Wikipedia:Administrators/RfC for binding administrator recall, the last broadly-held RfC on this topic. Its proposal is similar to yours. (Wikipedia:Requests for de-adminship has a whole slew of other proposals.) isaacl (talk) 21:25, 15 April 2018 (UTC)

There are some key differences - namely that the proposed dewiki model has an ongoing quorum requirement, whereas this model would move forward from existing community practices (review of actions at AN/ANI). They also require a new RFA with the same passing standard, which is different from this. -- Ajraddatz (talk) 21:46, 15 April 2018 (UTC)

Sure, that's why I said similar... Like I said, the idea was to see what has been done before and thus learn from it (you can see from the objections that safeguards like a quorum is a concern). (Regarding RfA passing standard, this proposal says "The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat.") isaacl (talk) 22:20, 15 April 2018 (UTC)

• The current process works fine and also has the advantage that the actions of all parties are examined: this has been cited by one person in the past as a reason why they are hesitant to file a desysop case request because they were afraid their actions would be examined. That means it is doing its job: preventing frivolous requests that can be resolved short of a desysop by making people assess how they have behaved in the situation, and possibly getting people to just calm down, which is usually the ideal.
  I’d also like to point out that while it is popular to complain about not having a desysop process short of ArbCom, a large part of the reason we don’t have one is that no one has proposed one that is actually better. That speaks volumes, IMO. This is a grass is always greener issue, and I say this as one of the limited number of people who has brought a successful desysop case before the committee as a filing party. Yes, the case request process sucks, but I’d much rather have it and know that the admin under discussion is getting full hearing than have an AN/ANI mini-trial or RFCU. There is also the factor that some of these cases, such as the MisterWiki case and some other recent admin issues, do involve private information, which the community is not equipped to deal with. The arbitration process is slow and takes a lot of effort, but it works. There is no need to replace something that works, especially when every alternative that has been proposed brings with it other issues. TonyBallioni (talk) 21:50, 15 April 2018 (UTC)

Sorry Tony, I consider you a friend, as much as people who've never met can be. But the current system is not working. You and I were chatting on IRC at the time, and you only beat me to that ArbCom case because I was actively drafting the request in my sandbox at the time and you beat me to it. Spectacular disaster should not be the standard. The community should be the standard. We're not a country where people live with the choices of their government. We're volunteers, who simply leave when the administration isn't accountable to that community in a meaningful way. If the community is the ultimate authority for making our administration, then the community should be the ultimate authority for breaking it when appropriate. I don't want to end the world; but I would very much like to see the standard for desysop moved from spectacular disaster to simply disaster. My concern is not spectacular disasters that ArbCom doesn't act on; my concern is that admins who realize they can operate at the level of simply disaster with no oversight, are free to do so. GMG^talk 00:28, 16 April 2018 (UTC)

Sure, but I'm not convinced that there is a better method out there, or at least not one that wouldn't be equally as flawed. My standard for any reform proposal of anything is that it should be an improvement, not just a lateral move that solves some issues while creating others that have the same level of severity. Using the statistics from de.wiki the last time this was formally discussed on en.wiki, ~42% of admins subject to their procedure basically said screw it, and resigned or didn't respond at all. Now, I am of the belief that all admins who have lost the trust of the community should resign, and that when they don't, ArbCom should make that choice for them (that was my basic argument in the MisterWiki case.)

At the same time, given that their actual removal rate by vote was only 13% and their retention rate as a whole was 44%, I suspect that many of those who chose to forgo the process on de.wiki would likely have been retained, but they just decided it wasn't worth it. That has the potential to have a real impact on the number of active sysops simply quitting, which I think we also need to take into account when looking at this. What some people also forget is that admins are also volunteers too, and while we have obligations to the community, if given the choice between their bit and an ANI-meets-RfA style sysop review process, there will be a lot of volunteers who decide it just isn't worth it, even if they shouldn't have anything to worry about. TonyBallioni (talk) 00:46, 16 April 2018 (UTC)

At the same time, we fret about inactive NPP reviewers skewing our numbers, when if dewiki is anything like enwiki, half of our admin corps is barely active anyway, and half of those are practically mummified, and so of course they wont stand for a confirmation, because the user right is a dusty artifact. Losing an inactive admin isn't an actual loss; it's the status quo with one less user right involved. Any active admin in good standing should pass with flying colors. That many don't would be a feature, and not a bug. GMG^talk 01:29, 16 April 2018 (UTC)

ArbCom cases can take months—generally in complex cases, where there are multiple issues and multiple parties and where it is not immediately and clearly obvious what the community consensus is with respect to how an issue should be handled. The cases that ArbCom handles slowly and not to the satisfaction of all editors are the cases that the community hands to ArbCom because the community is unable to come to a consensus, and must resort to an independent arbiter because we have no other way to resolve an impasse.

In instances where desysopping is clearly the correct course – and when I say 'clearly', I mean 'clearly to uninvolved parties and not just local partisans' – the ArbCom can and does desysop by motion, and can do so over a few days. (In clear emergencies featuring ongoing misuse of tools or egregious abuses of trust, ArbCom has (and has used) procedures to suspend admin privileges in minutes.) Administrators and the community at large are aware of this, and it is not uncommon for an 'under a cloud' resignation to be tendered as soon as a widely-affirmed concern is presented at AN(/I), or immediately after a well-posed complaint is opened at ArbCom. In the recent Gryffindor case, for instance, a concern was raised at AN/I on 11 April; the weight of opinion in favor of an ArbCom request was established fairly rapidly; Gryffindor read the writing on the wall and resigned on 13 April. That was significantly faster and less wasteful of community time and resources than any new (albeit perennially proposed) process could be. TenOfAllTrades(talk) 00:14, 16 April 2018 (UTC)

Any de-adminship process would probably have had the same effect on Gryffindor, they had the mindset for it. What you're saying in support of the ArbCom model is pure speculation. But what GMG has said is more true than false. The bars for a de-adminship at AC is spectacular disaster. And that's not a good bar. I'm not rejecting the idea that the ArbCom is inefficient, but with a procedure designed to increase bureaucracy in the system, you can see where things start going wrong. Emergency requests procedures of AC are redundant, Stewards have a full reign over who to desysop or not, even a crat can inform them, AC just makes a binding request (which means that the process can take more time rather than lesser). --QEDK (後 ☕ 桜) 04:27, 16 April 2018 (UTC)

Responding at the bottom rather than in-line because there are a few points I want to address. First, the dewiki system isn't a model I would recommend following. The petitions are stressful for admins, the bar to keep adminship is too high, and the results cited by Tony above prove that it just drives admins away. Clearly that isn't what we're looking for. But that's not the only system, nor is it the most widely used, and Wikidata/Commons use a system which has better results. That said, I don't often pull out my soapbox for this issue because the ArbCom process does work - I just think that, from a philosophical perspective, it is wrong. The community should decide who admins are, and be able to remove them. I think that there might be some room for a proven, simple system with safeguards against abuse here, but any proposal for it would be an uphill battle that probably isn't worth the time. Especially when I could be complaining about RfA standards instead :-) -- Ajraddatz (talk) 00:59, 16 April 2018 (UTC)

Yes, but I have and will continue to argue that the problem with the barrier to entry is the barrier to exit. GMG^talk 01:34, 16 April 2018 (UTC)

• I'll add my 2c here. While I think the current system is stable in people's minds, with a difficult barrier to entry and a quite difficult barrier to exit as well, it isn't exactly ideal given that we are failing to be able to elect a stable admin base (decreasing numbers consistently). There is an issue that an oppose !vote counts for around three times as much as a support !vote. However, I don't think this system is going to change without an increased accountability check on admins, as the difficulty to de-sysop makes a difficult barrier to entry essential in many people's eyes (not unreasonable). If we were to put forth a proposal to simultaneously somewhat lower the barrier to entry as well as lower the bar for de-sysop, that might be feasible. But doing either by itself would I think be very unsatisfactory to many people. What the exact elements of such a proposal would look like, I have no idea, but the current system is generally unsustainable. — Insertcleverphrasehere ^{(or here)} 04:38, 16 April 2018 (UTC)

  I concur with Insertcleverphrasehere on the analysis above. Another possible modification to the current system that might ease matters is a probationary period for admins. Not every admin has experience as an admin on a similar system, so there will often be a learning period with the new tools and responsibilities. If a probationary period of say 6 months and a reasonable number ot tool uses was the standard for a new admin, with a confirmation at the end of it, the bar to getting there might be lowered to a series of two easier bars. If they cock it up in a big way while in the probationary period, they will not make it through confirmation. If no blunders are made, the confirmation should be relatively painless, possibly even boring, if confirmation is the default when no serious complaints are raised. Or we could just wait until there are not enough admins to run the site, then go into panic mode and change the system in desperation to another one which may be just as bad. Some people just need the tools to do what they want to do. I don't need them at present, so there would be no point in RfA, as I have been able to get all the tools I find useful juat by asking for them. If I needed an admin restricted tool I would RfA, but not before, there is too much drama for my tastes. I needed some of the admin tools on other Wikis and got them without drama, but I don't need them here. I prefer the pen to the mop. · · · Peter (Southwood) ^(talk): 06:37, 16 April 2018 (UTC)

  A probationary period would lower the RfA rate to non-existent (who wants to go through RfA twice?). I also don't think lowering the pass rate any lower is a good idea: we want admins to have broad support in the community and trust. We already have the discretionary range at 65%, which is basically what it takes to pass any other discussion. I also reject the idea that somehow lowering the exit barrier will have an equal effect on lowering the entrance barrier. I don't think it will have any impact at all: the RfA-standards genie is already out of the bottle. This is a prediction that is brought up all the time but it doesn't take into account the fact that when people collectively raise standards, they rarely lower them. If anything, any proposal on this would decrease the number of successful RfAs because no one would want to have to deal with the constant threat of ANI for a desysop. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)

• My tenure here or experience with such discussions is limited, so my opinion may as well be worthless, but here goes...

So far, the discussion has pointed to a two step procedure:

1. An AN/ANI thread to discuss the abuse/misuse of tools by an admin and consensus on whether reconfirmation RfA is needed. A 'crat closes the thread and assesses the consensus.
2. If the consensus is in support of a reconfirmation RfA, it is followed by regular procedures of a RfA (watchlist, time frame, etc.), though forced, where the votes are counted. As stated above, people who hold grudges can't sink a majority-vote-based RfA.

However, this raises a few more questions:

• What is the formality of such an AN/ANI thread? Say, an editor finds three page deletions of an admin problematic and asks for review from other users. That is, the thread is about the deletions and not whether the person's adminship needs reconsidering. If the page deletion is identified as a long term issue, would a comment like "we should really look into the ability of this admin to handle his tools" be considered the "start" of step 1? Or should someone start a new thread (or a sub-section) with a specific title to document the entire consensus building formally so that comments stay on topic? The reason I say this is because a thread that talks about three page deletions would gain much less traction and a few editors might agree with the green highlighted comment I just stated above. Would that mean there is truly a consensus to conduct the reconfirmation RfA? In comparison, a thread titled "Considering reconfirmation RfA for XYZ" would probably catch more eyes. (That is just how I feel; that may not be true with how things work at AN/ANI since I don't frequent there enough).
• Can any editor start such a thread? Even one quick to call 'Admin abuse!'? Or should there be a proper "case" before step 1 can be started (I've discussed this more in the next point). Keeping with the example I gave, if the 'long term issue' is falsely identified by the editor starting the new thread, people would start commenting that thread was spuriously created and that it's a time sink. Which leads me to next point...
• How long should the thread last? Can it be snow-closed by a 'crat as a "time sink"? Or should there be a time-frame so that consensus building is given a fair shot?
  • If snow-closes are allowed - the process would be fairly informal providing greater leeway to the closing 'crat and could lead to limited participation. There won't be a lack of participation at the RfA, but there might be at the AN/ANI which is the first step. Since RfA has raised its standard over the years, it would be unfair for admins to be put in the spot so easily and questioned in a re-RfA after an informal-process-led AN/ANI. It could also potentially promote people to start spurious threads, knowing that they can be snow-closed (although, hopefully, a boomerang would follow in such cases).
  • If a time-frame is kept - a barrier would have to be created to ensure there is a proper "case" so that it is not truly a time sink. That would add a third step of assessment of the "case" and complicate things. But, the entire process would be fair. There would be enough time to view the actions of the thread initiator as well as hear the voices of the community. At the same time, there would also need to be a "gap" introduced between reports for a particular admin so they don't get targeted.

This is not like an AfD where both time-frame and snow-closes can be allowed freely since most snow-closes are strongly policy based. Admin conduct is largely subjective since we're assessing the actions of a person. If snow-closes are allowed, they would need to be for particular cases. Say, the idea is implemented with a time frame and someone starts another thread just a few days after the previous closes for an admin. It can then be reasoned that consensus wouldn't have changed (unless the admin royally messes up in those few days) and snow-close the thread. That would be the "gap" I was talking about earlier.

With all this formality, time-frame and "case" stuff, it seems to be getting closer and closer to how ArbCom works. I truly believe that the ins and outs of the process have to be worked out first. Just my views though, I'd love to hear what others have to say! Jiten ^talk _contribs 09:24, 16 April 2018 (UTC)

The AN thread acts as the "stop-gap" for futile requests. That's not the idea but something we can probably think about, is all. When you have crats closing it, it has to be a responsible close and I doubt there's the leeway you talk of. Set up a minimum time-frame for reach and maximum time-frame for consensus and I'm sure crats can effectively deduce consensus. --QEDK (後 ☕ 桜) 10:55, 16 April 2018 (UTC)

(edit conflict) Hmm...My general feeling is that any editor should be able to open such a thread, yes. This is no different than any other behavioral dispute that arises at AN or ANI where things might spiral out of control for a little while in a general purpose thread, and we end up with someone who's been following developments who decides they think they have a solution by proposing a block or a ban. I don't think you really need to set additional limits on the normal consensus building process. Some discussions will probably be a clear cut consensus one way or the other, and can be easily closed, even by a non-admin (I'm sympathetic to dropping the bit about crat closes). Others may be highly contentious and need a team of experienced admins to close. This is again perfectly in line with our normal consensus building process governed mostly by common sense. The discussion would be closed in accordance with normal procedure, summarizing the consensus and the concerns of the community, and that close would be the rationale for the re-RfA, in place of nominations and the three standard questions.

I think it's also important to point out that this is actually more lenient than what is possible under current policy, since it's simply a consensus for whether a re-RfA should happen, and not deciding to directly take away the mop. It may be perfectly reasonable for someone who thinks a user should retain the mop, to still support a re-RfA in order to solidify the conesnsus for retention, and put down unwarranted pitchforks.

The alternative under current policy and what I fully intend to start proposing at places like AN and ANI given the opportunity if something else doesn't come of this discussion, is to start TBANNING admins from taking any administrative action whatsoever until they appeal to the community to lift the TBAN. This type of administrator probation is as far as I can tell, and I've looked pretty hard, perfectly allowed under current policy. But that type of action is actually less accountable to the broader community, and more likely to be beholden to the types of people who frequent AN and ANI, in disregard for those who don't. GMG^talk 11:04, 16 April 2018 (UTC)

And before someone calls this a solution in search of a problem, remember that at this moment ArbCom can barely agree whether to even issue a warning to an admin for edit warring, when, if you count page protection as an edit, they were already at 4RR, and would have been blocked were they a regular editor. Besides that, I'll bet someone like...oh...WBoG can probably think off the top of their head of at least one example where a current admin has mostly not yet been dragged to ArbCom because of the onerous bureaucracy, even though a case request is almost certain to be successful. GMG^talk 11:39, 16 April 2018 (UTC)

As I recall, a community-imposed ban on performing administrative actions has been discussed and recognized as an effective removal of administrative privileges, and thus only within the scope of the Arbitration Committee to put in place. I'm not certain, but I think bans on specific categories of administrative actions have been passed, though it is rare. Usually people feel administrators an editor should either be trusted with the entire range of administrative tools, or none of them. isaacl (talk) 13:45, 16 April 2018 (UTC)

TBANs on use of specific tools are allowed, yes. There is also the Arthur Rubin example where the community passed a community ban against him pending the ArbCom case and then removed it when he returned. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)

Yes, that was brought up at my talk page a little while ago. If the community can CBAN someone, then I don't see any reason why they can't enact a TBAN which is in every way a less extreme sanction. It wouldn't be removal of the bit, it would be suspension of the bit, pending a consensus that they have regained community trust. Honestly, I'd welcome ArbCom to try to unilaterally overturn such a TBAN, because there would be no clearer demonstration that they cannot in this one area fulfill their duties as a body to the satisfaction of the community, and we need to formulate another option.

To my mind, a re-RfA, with all the accouterments of a set time table, wider audience, and opportunity for Q&A is the closest thing out there to a compromise between a bureaucratic nightmare on one hand, and outright mob rule at AN or ANI on the other. GMG^talk 14:04, 16 April 2018 (UTC)

I would support forcing resignation before a reRfA, which would solve the issue people have of them being easy to game. I argued this in either January or December (whenever the last one was). That was shot down as not being something worth writing down. My preferred system here is that admins who have lost community trust, or where that trust has been called into question, resign without the need for a case and if they still want the tools run again. If they refuse to do that, then ArbCom steps in. I think that's where we are in most cases right now. I am disappointed in some of the Arbs over the current motion, but it seems likely to pass and regardless of my views of re: involved full protection, I doubt a community desysop process would have achieved much different. TonyBallioni (talk) 14:44, 16 April 2018 (UTC)

So in essence, something like what GMG and Ajr suggested but without step 2 (ie, the reRfA)? If I understand correctly, you mean: as soon as there is consensus in an AN/ANI thread that an admin has lost the trust of the community, they must resign. If not, the case would be taken to ArbCom. If they want to bit back after the resignation/forced resignation, they must run a regular RfA just like other editors. Is that correct? I think the main concern here is still that community's say should be final. If an admin loses our trust, they clearly don't deserve the admin tools and ArbCom shouldn't be able to say otherwise. Even if ArbCom is very much in line with community's thoughts, the whole procedure takes time and effort. A forced re-RfA on the other hand, as GMG suggested, is quicker and more accessible to the community. Just from personal feelings and the very little time I've spent reading ArbCom cases, there's more participation at an RfA than a case and the final ruling is determined by the community (which, imo, seems philosophically correct as the community is the one that voted for the admin). I didn't understand the "game" part though. My initial comment only addressed the AN/ANI thread; I hadn't even though about the actual re-RfA! Jiten ^talk _contribs 15:11, 16 April 2018 (UTC)

Well, my main concern is that 1) a direct desysop has already been rejected more times than anyone remembers, and functionally 2) AN and ANI have a tendency to be volatile and vitriolic, with people rushing to sanctions because they lack the creativity or time to find any other solution (exactly why we just passed a 24 hour minimum to CBAN discussions). So you take away the sanction as an option really and instead make them !vote on whether we have a discussion. Also in comparison, RfAs tend to be more well thought out, and bring out a much wider audience including a lot of our quiet content creators and gnomes who'd rather have a root canal than watchlist a noticeboard. GMG^talk 15:23, 16 April 2018 (UTC)

Jiten D: Yes, that is roughly my position. I think that once it is clear an admin has lost the trust of the community, or at the very least there is a valid question of community support because of a major breach of trust, they should either resign or ArbCom should desysop. This is the process that we just saw work here and that also worked at Wikipedia:Arbitration/Requests/Case/Conduct of Mister Wiki editors. It works and no one has suggested a process that would work any better given the political realities of en.wiki (again, see the de.wiki numbers. I highly suspect that if a Commons/Wikidata like process were to be followed here, we would see similar attrition, which is not a good thing.) Its also important to note that all ArbCom does in terms of desysop is remove and mandate a reRfA if someone wants the tools again (assuming no other sanctions.) We don't have a perma-RfA-running-ban short of a full site ban.

I also dispute the idea that the ArbCom based desysop process is not a community-based desysop process: they are elected by the community, they take case requests when it is raised by the community, every step of the arbitration process has ample opportunity for community comment. All of the previous desysop reform attempts can fall into two camps: direct desysoping by the community (which I would call forced reRfA an example of). This is rejected because we want protections for admins who make tough calls, and the confidence in ANI at resolving disputes is slightly lower than the popularity of Congress and ArbCom. (See Wikipedia:Administrators/RfC for binding administrator recall. Any version of reRfA or direct desysop will face similar objections, and would likely fail.) The other proposal is to designate a group of trusted editors from the community to review requests for desysop when it is clear that there is community demand for it, so that the community can remove adminship when it feels that an admin no longer has its trust, this is the idea behind proposals such as WP:BARC. The issue there is that ArbCom is already that body: it is elected by the community every year to handle, among other things, desysop requests at the request of the community and with community comment. TonyBallioni (talk) 15:49, 16 April 2018 (UTC)

Tony, the attrition isn't related at all whether we have a community-desysop process or not, but simply because our RfA standards have increased year-on-year. The solution isn't to make barrier to exit harder but the barrier to entry easier - you're going very roundabout with your argument. There is no consistent evidence across community desysop processes to suggest that it's been the triggering factor in attrition. You keep saying that ArbCom is elected by the community for the purposes of desysoping, but that's not only it, if you've read GMG's comment, the ArbCom's stance on desysop's way too soft, stuff that one crat would probably do if we had the policy to allow that. Instead, we wove in the right with the most complex and busy legal court in all of Wikipedia. You dispute the point, fair, but your point is essentially, "No, this is okay" after citing an example where the admin resigned. Gryffindor would resign under the threat of any such process as well, you just need the mindset to resign. And for the last time, ArbCom is not the community, they're people appointed by us, entrusted with the right to deal with issues in a fair and unbiased manner, while they are certainly good at deliberating, I disagree that admins appointed by the community should be left to desysop at the behest of a group of people who are certainly not the community. --QEDK (後 ☕ 桜) 16:16, 16 April 2018 (UTC)

Tony you can't accept the limitations of the dewiki process and ignore the success of the other community review procedures. Look for yourself at Commons (successful and unsuccessful) to see the lack of frivolous requests. And you're also wrong about the steward confirmations - most of steward work is taking global actions, not acting as a local admin on a project without them. Stewards can thus get grudge users from both homewiki activities (seen this year on ptwiki stewards' confirmations) and for controversial actions they've taken (I once took issue with someone editing my comment on Meta and they came back to oppose my confirmation the next year). The simple fact is a) this doesn't discourage stewards from staying on unless they've really messed up and b) safeguards prevent those grudge users from derailing the process. I also disagree that arbcom desysop is community desysop - arbcom doesn't appoint admins in the first place, the community does through RfA. And a general point regarding the AN/ANI thread requirement - there should be no fixed bureaucratic rule for this, because the intent is to use existing procedures. Admins can already be taken to AN/ANI over bad actions. My proposed system would just allow for a substantive follow up to those discussions. -- Ajraddatz (talk) 16:32, 16 April 2018 (UTC)

Just as a general comment, I am reminded of a recent RfA on Commons, where the rationale was essentially I want to do this particular cleanup task and when I'm done I'll give the mop back. It ended up getting derailed for reasons other than the rationale, but I have to say it was refreshing to have a rationale that was so pragmatic and 100% I want to do this task with 0% I want to be a community leader of sorts. I wish we could move more toward that on enwiki, and the only way I see for doing it is reforming the back end, because that's what people are thinking about when they cast a !vote at RfA. The barrier to exit is what sets the standard of how bad a mistake at RfA is going to be if one is made. GMG^talk 16:46, 16 April 2018 (UTC)

Ajr: While I respect the work that stewards do, and think I have pretty good relationships with a good number of you, I disagree with you that there is any equivalency to steward confirmations in this discussion: steward actions are by the very nature of the role supposed to be uncontroversial. A steward who is behaving controversially *should* be removed, which is why the process there works well. Re: Commons, it has a very different culture from en.wiki, and I don't think it would work as well here.

QEDK: I was providing recent examples of the current process working. Thus far, in any of the desysop reform discussions that have taken place over the years, no one has actually demonstrated that the process doesn't work or that there are a huge amount of actually filed case requests where the community would have desysoped but ArbCom didn't (or even one). It does. My basic argument is that while the current process has flaws (i.e. it is slow, which is the only one that has ever had consensus) all of the other possibilities that have been discussed also have flaws that are as bad or worse (I think it would increase attrition and also decrease recruitment, among other things). I'm a pragmatist who doesn't believe in changing something that works for something else that may or may not work and would likely be just as flawed. I also disagree with GMG that lowering the barrier to exit will lower the barrier to entry: the barrier will remain just as high and we will lose plenty of good user who simply don't want to go through public humiliation because of a grudge. TonyBallioni (talk) 16:56, 16 April 2018 (UTC)

I've been a local admin in a variety of places on Wikimedia and Wikia since 2009. Some of the most controversial actions I've taken are as a steward, because outside of permissions management, we deal with a large number of controversial issues that can draw attention. And I've also found that, regardless of the project, the culture and general function of a wiki are pretty well the same no matter where you go. That is just my experience though, and I can't measure it in any objective way. All of this said, I do understand your core argument that the arbcom process works and ensures that admins are empowered to take controversial actions. -- Ajraddatz (talk) 17:18, 16 April 2018 (UTC)

I'm unclear why requiring a re-confirmation RfA after a consensus would cause English Wikipedia to "lose plenty of good user who simply don't want to go through public humiliation because of a grudge", but having the same consensus trigger a resignation or an arbitration case wouldn't. I suspect going through an arbitration case would be just as likely to result in someone leaving. isaacl (talk) 17:53, 16 April 2018 (UTC)

@GreenMeansGo:, regarding why the community doesn't have the ability to remove administrative privileges: as I understand it, originally Jimmy Wales appointed and removed administrators. He then shifted the responsibility for appointing administrators to the bureaucrats as part of the request for administrative privileges process, and the responsibility for removing administrative privileges to the arbitration committee. To change this would require a change to the Administrators policy. There is no effective difference between removing administrative privileges or dictating that an editor cannot use them.

In the end, the basic problems are that consensus doesn't scale up as a community increases in number, there are structural problems with online decision-making (including the limited, self-selected sampling of voices heard), and English Wikipedia's decision-making tradition isn't conducive to determine real consensus. As a result, any attempt to make major decisions by a large community discussion generally gets deadlocked. isaacl (talk) 17:53, 16 April 2018 (UTC)

Well, regarding TBANS there is a difference between removing access and suspending the use of it. Namely, it takes crats and ArbCom initially out of the loop all together. If an admin on probation decided to flout the TBAN, any passing admin can basically unilaterally hand out a block, and then take them to ArbCom if they unblock themselves (the lenient route). Or we take them directly to ArbCom, because we've created a situation where use of the tools at all is by definition abuse and directly contravening community consensus. Then if ArbCom decides to override consensus...I dunno...I guess we'd just have a wiki-constitutional-crises. Normally a TBANNED administrator (as in, TBANNED from US Politics or something) would be nearly up for the chopping block just by virtue of needing to be TBANNED in the first place.

In a nutshell, it's attempting to set up ArbCom to be in a situation where either their hand is forced, or alternatively they do something totally bonkers and everyone flips their lid, in the hopes that they'll prefer having their hand forced to gratuitous lid flipping. GMG^talk 18:14, 16 April 2018 (UTC)

To clarify, there is no effective theoretical difference in the community saying administrative privileges shall be removed and an editor shall not use administrative privileges. Accordingly, by policy, the community does not have the scope to enact these restrictions, and the administrator in question would not feel bound by them. There is of course a practical difference today between the community making either of these statements and the Arbitration Committee ruling that administrative privileges shall be removed: the bureaucrats will only act on a statement from the Arbitration Committee. isaacl (talk) 18:22, 16 April 2018 (UTC)

I doubt that, if such a discussion were to be held in a proper manner, even though the policy doesn't exist, consensus can be reached. Nothing is stopping anyone from reporting the discussion to the stewards directly, and considering that local policy doesn't bind them, they can exercise their right to desysop considering the admin has effectively lost the confidence of community. The community has full scope in every scenario. --QEDK (後 ☕ 桜) 18:50, 16 April 2018 (UTC)

Sorry, I'm not sure if you're responding to me? If so, are you saying that you doubt that consensus can be reached? And then are you subsequently saying that if consensus were reached, the community could appeal to the stewards? isaacl (talk) 18:56, 16 April 2018 (UTC)

There may not be a practical difference but there is a policy difference, and there is nothing in policy that forbids it. It's already been shown that a current admin can be CBANNED while still retaining the rights, and it's already been shown that the community can restrict the use of the tools using a TBAN (see here). The difference is only one of scope, and possible gratuitous lid flipping by having ArbCom directly override community consensus.

But no, the community doesn't decide everything. There are some things that are decided by the WMF. We cannot, for example, eliminate ArbCom all together. Their existence is mandated by the foundation. We cannot reach a consensus to disregard WP:COPYVIO. We cannot override office actions. And if a steward ever showed up on enwiki and unilaterally removed the admin rights under those circumstances, lids would be violently flipped in every direction. GMG^talk 18:58, 16 April 2018 (UTC)

Ofc not, I simply meant to say, if the community needs to take action, it will. Unilaterally using rights isn't a question or an idea. @isaacl, I was responding to you, yes. If consensus is reached for the removal of rights, the Stewards are bound to take action even though the local policy is something else, their task is to execute community consensus. I do not mean appealing to the stewards, but requesting for the implementation. --QEDK (後 ☕ 桜) 19:05, 16 April 2018 (UTC)

Note that stewards will not take actions that could be performed by local bureaucrats except in emergency, and loss-of-confidence isn't an emergency situation by itself. See m:Stewards policy#Don't promote users on projects with existing bureaucrats. -- Ajraddatz (talk) 19:08, 16 April 2018 (UTC)

I would guess that loss-of-confidence is immediately an emergency situation. I know you're the steward ofc, but if we're getting technical, it says promote and allows you to exercise disretion elsewhere and furthermore, the primary "...task is to implement valid community consensus within the bounds of the Foundation's goals", and not implementing such a consensus would be directly against the reason why you were elected. But that's just what I think. I'd say you need to be in such a situation first to evaluate an outcome so speculating possibilities isn't exactly it. --QEDK (後 ☕ 桜) 06:59, 17 April 2018 (UTC)

Sorry, poor choice of words: I did not mean "appeal" in the legal sense, but simply "request". I still don't understand your first sentence, but I understand your line of argument regarding the stewards; thanks for the clarification. isaacl (talk) 19:33, 16 April 2018 (UTC)

Removing privileges is the tool to enforce the restriction; there is no policy difference in telling someone they can't do X versus telling them they can't do X and no longer have the technical ability to do X. isaacl (talk) 19:40, 16 April 2018 (UTC)

There is a problem with mis-actions by admins, and lack of accountability of admins. But putting putting the death penalty of desyopping under the random clan & mob mentality that pervades other areas of Wikipedia is not the answer. One component of a fix would be to get rid of the ridiculous system where anybody with the tool belt is considered qualified to act as judge, jury and executioner on behavioral questions on established editors, and or deciding/closing even the most complex and contentious situations. This needs needs to be a second tier above admin; people who are proven to also be wise, careful, thorough, impartial, never hot-headed, with good judgement, analysis and decision-making process capabilities.....the "Yoda" level. And, just like the fix for the broken RFA process, discussions to award this need to be findings on an established framework of the qualities required, not the current random stuff that we have at RFA. Second, there needs to be a process to sanction mis-behaving admins with lighter penalties than desysopping that doesn't require the giant artillery of an arbcom case. Maybe a panel of 3 "Yodas" who could dish out findings on admin behavior and admonishments. And until we have Yodas, a community based process for findings and admonishments but not desysopping. North8000 (talk) 18:26, 16 April 2018 (UTC)

Binding arbitration on content disputes has been suggested by others and me as a way to give final rulings on content disagreements. Today there's no final stop in the process; people can periodically bring up issues (hoping consensus has changed), and whoever lasts the longest may well succeed, so editors have incentive to be contentious. I appreciate there are pitfalls with binding arbitration to be wary of (for instance, consensus actually can change, and sometimes there are cliques that need to be counteracted). The largest barrier, though, is that people would have to give up their veto right to block changes (one person alone can hold up a change for an astonishingly long time; a few people can do so indefinitely). Until something more drastic happens to Wikipedia's editing environment, I don't foresee binding arbitration being introduced. isaacl (talk) 18:39, 16 April 2018 (UTC)

I really don't think the answer to fixing a bureaucracy is more bureaucracy. The 3 Yodas will never ideally represent the view of the community and there's nothing to say they can remain completely unbiased. The key to removing bias from a system is to have multitude of opinions, as eventually, bias cannot skew the opinions to one side or the other. Your argument, along with Tony's, is based on the key principle of the community not being able to take care of our decisions, like there's a huge mismanagement that occurs anytime it's upon the community to decide, but that has never been the case. If anything we need to involve the community as a whole more, not less. --QEDK (後 ☕ 桜) 18:46, 16 April 2018 (UTC)

Agreed 100% with QEDK. If the community can be trusted with making admins they can be trusted with removing them. And the three Yodas model falls to the same reason why BARC was rejected - it's just another ARBCOM-like process. As an aside, I don't think that the community does an excellent job of making new admins. But they certainly wouldn't do a worse job of removing them. -- Ajraddatz (talk) 18:52, 16 April 2018 (UTC)

I didn't say anything about 3 Yodas and I'm not sure if I favour that specific proposal, but in general: consensus doesn't scale up. All of our experience with communities in the real world demonstrates that managing interpersonal interactions requires some form of hierarchy. We can do our best to keep it as grounded as possible with the community at large, but it's just not possible to hold an effective conversation with hundreds of people: it demands too much time and attention. isaacl (talk) 19:27, 16 April 2018 (UTC)

I mean we do a half decent job of it half the time. There's currently a discussion ongoing at WP:ACREQ where more than 200 people have weighted in so far. GMG^talk 19:48, 16 April 2018 (UTC)

That conversation is pretty civil, which is good, but it has a lot of redundancy, with people repeating points, because almost no one is going to read over 200 statements (I read many of the opposes and some of the supports at the start of the RfC, but haven't kept up). Due to the traditional structure of discussions on English Wikipedia, people spend a lot of time arguing with individuals over their viewpoints, instead of consolidating discussion around each argument for and against. (I've written about these issues before.) And that discussion isn't related to behavioural issues, or even a content dispute. It's also isn't that evenly split, so it's more a lot of people agreeing with each other, rather than a conversation. That being said, there are a lot of conversations that can (and often do) proceed smoothly. But the contentious ones are hard to resolve without some kind of structure to manage them and provide incentive for collaborative behaviour. isaacl (talk) 20:06, 16 April 2018 (UTC)

• WP:BARC was an idea of mine for a new policy that failed to gain traction. Lauched together with Worm That Turned during a period when community desysoping was once again a current topic, it was an experiment in community opinion more than anything else. On the lines of, 'let's try something and see what they say', it's nevertheless interesting reading and IMO is still a fundamental basis for new ideas. 100+ supports was not an insignificant turnout by today's RfC standards and was in fact numerically (115/75) the majority. Mdann52's closure made a very fair assessment that on the strength of the arguments there was no consensus. My main concerns at the time were to find a system that would protect any community desysoping process from an overspill of votes from aggrieved users who fail to understand that some admins do make tough calls - there is clearly a lot of schadenfreude in such participartion. Serious cases of privilege misuse (or serial poor judgement ) are in fact quite rare considering the number of admin actions that are carried out, and the (low) number of truly active admins who do the brunt of the work.

BARC was nearly 3 years ago. With the apparent reduced workload on ArbCom, and a marked drop in coordinated attacks on adminship in general, I question whether today a 'community' desysop system is required - TonyBallioni makes a salient point in clarifying that as elected officials, the Committee mebers are nevertheless members of the community. Whether we are happy or not with the work of each individual who occupies one of those those seats (some do occasionally vote at odds with the other members), at this moment in time I am personally satisfied that the work they do in this area reaches the right conclusions. It's the structure of the ArbCom system that needs streamlining, IMO its own mess of bureucacy is what makes it so slow and ungainly.

Nowadays, although it still suffers from the ocasional disingenous opose votes and what are probaly a lot of drive-by supports, even if it's still not attracting a plethora of contenders, RfA does what it says on the can - most of serious candidacies pass and there is a significant reduction in failed bids for the bit. Like community desysoping however, no one has ever come up with new a idea for it that pleases everyone. Kudpung กุดผึ้ง (talk) 01:09, 17 April 2018 (UTC)

• If the community can grant adminship, the community should be allowed to take it away. RfA activity remains extremely low, in part because adminship really has become a big deal. I am fairly certain that the community will not take any major steps until the number of admins drops so much that a crisis is created, and by that time it will probably be too late. Lepricavark (talk) 15:04, 17 April 2018 (UTC)

• I can think of two practical ways to create a functioning de-sysop procedure which bypasses Arbcom, protects admins from frivolous complaints and does not add another layer of bureaucracy.
  1. As a show of good faith and in recognition that a significant portion of the community thinks there should be some community process which does not involve ArbCom even if there is little agreement on what that process should be; All administrators post their own recall criteria. The only two requirements is that the criteria be binding and can not be changed while there is active discussion to perform a recall. This allows individual admins the flexibility to be bound by procedures they feel comfortable. I would suggest that it should be possible to challenge an admin's chosen procedures if they do not reflect the spirit of the intended purpose ie "Recall me by taking me to ArbCom" or if there is no reasonable way for the condition to be fulfilled.
     • A 'sub-option' is this could, rather than being voluntary, it could be forced via RfC.
  2. Simply use an AN/ANI thread which meets three conditions 1) It is opened or has a sub-thread which is expressly for the purpose of recall. 2) The thread runs for some minimum time, say 3-5 days. 3) The thread is closed by three experienced editors: An administrator; A non-admin editor who has experience closing contentions threads; An editor or administrator selected by the admin whose community confidence is being questioned. The close is a simple Sustained/No-confidence.
     • This could also be implemented in combination with #1 as a universally agreed recall condition.
     A No-confidence could be implemented either through voluntary resignation 'under-a-cloud' or using the TBAN idea GreenMeansGo has suggested previously. (I also think that the extra care of the three conditions would give weight to a TBAN decision if even if the process had not been agreed upon via prior discussion or could act a a method of 'creating policy through practice',)

These options use the tools we have and #1, in my opinion, has the added benefit of the admin corps, by voluntarily recognizing the concerns of a significant population of editors and being responsive to those concerns, collectively showing ongoing faith and trust in the community. Just as the community shows faith and trust in them. Jbh ^Talk 01:21, 18 April 2018 (UTC) Last edited: 01:31, 18 April 2018 (UTC)

The grudges

The main counter-argument for a community-initiated desysop process seems to be the "grudges" - users who have been blocked/warned/offended by an admin at some point, who show up at the desysop proceedings to oppose the admin under review without seriously considering the situation and pattern of overall behaviour displayed by the admin. I've been arguing throughout this thread that this is nothing more than a myth that would not actually derail a community desysop process - let's look at this in more detail.

• Starting with cross-jurisdictional comparisons: do grudge users control the community-initiated desysop processes on other wikis? No, though some (like the dewiki model) can potentially drive off admins who don't want to go through the process. More on this below. But if you look through the archives at Meta, Commons (successful and unsuccessful), steward confirmations and Wikidata you will see a distinct lack of frivilous requests or requests being derailed by "enemies" of the admin under review. This isn't to say that it doesn't happen - but it doesn't happen in large enough numbers to derail the process. I picked those processes because I am the most familiar with them - if anyone else wants to add some analysis of others please do so.
• Now let's look at enwiki, because I know everyone is going to have "those projects aren't enwiki, enwiki is different and special" on repeat in their brains while reading the above point. Enwiki doesn't have a community-initiated desysop process, but it does have AN/ANI and ArbCom where the community can complain about sysop actions. Some AN/ANI threads can even lead to ArbCom cases for desysopping, so it's a surprisingly similar system to those proposed above, just without any decision-making power for the community. So let's look at how these "grudge" users derail the existing processes. There is a current case request before ArbCom right now about desysopping (found here), without any evidence that the "grudge" users are dominating the discussion. I see maybe one or two comments of questionable value, with most comments being appropriate reflections on the conduct of the user in question. Looking to the ANI thread on the same topic (here), again, I'm not seeing much in terms of users with grudges showing up to derail the process. Does anyone have any actual examples of an AN/ANI thread being filled up with users with grudges trying to get back at a specific admin? And again, I don't mean one or two - one or two people with grudges will show up anywhere, be it RfA or a request for desysopping. I mean enough users to derail the process or to wrongfully desysop an admin who was just taking a necessary but controversial action, or enough to form a consensus that a de-RfA should be initiated.

There's another argument here that deserves some attention. Tony expresses it above, saying that a community-initiated process will cause admins to just quit rather than go through a confirmation RfA. That's a very good point to make when looking at the dewiki system, but it doesn't apply to Meta/Commons/Wikidata/steward confirmations and I doubt it would here. Admins can already be dragged to AN/ANI or ArbCom for their conduct here, and ArbCom proceedings are possibly more stressful than a re-RfA given the timeframe and private nature of the decision. Changing the step after AN/ANI from ArbCom to community process isn't going to cause mass resignations. Admins here already self-select which controversial actions they take to avoid community uproar; this will be no different with or without community-initiated desysopping processes.

The biggest argument I see against a community-initiated process like the one I outlined above is that it would likely have the exact same outcomes as the current ArbCom-led system, and thus the change would only be symbolic. I think this is a fair enough argument to dissuade me from proposing anything on this topic. But I always like to push back against the nebulous claims of possible abuse that could happen whenever something new happens, because whether it's this or IPBE liberalization, it just doesn't pan out that way. Sorry for the long post. -- Ajraddatz (talk) 02:19, 17 April 2018 (UTC)

Well thought out, as always, but the big counter argument is that the structure of an ArbCom case actively discourages the grudges. There is also the flip side that arguably ArbCom can hold popular admins to account in ways that ANI won’t (and we have plenty of examples of people having their friends stop by ANI). So I think a better counter is: ArbCom works fine, it is arguably more effective than a community process would be for politically popular admins, it provides protection against potential witch hunts in that the actions of all parties are examined, and no one has actually put forward a provsss that would work better. Like Kudpung hinted at above, if anything, the thing that needs work currently is streamlining the process for obvious cases, which the committee has already started to do on its own without some massive reform RfC that would likely end with only minor tweaks to procedure. TonyBallioni (talk) 03:08, 17 April 2018 (UTC)

No, Tony. ArbCom has already said that ANI cannot delay with admins, and any attempt to do so will be met with a curt "ArbCom is thataway". It's also said that it will not deal with popular admins. One once even blocked a member of ArbCom for comments made during a deliberation, and ArbCom supinely backed down, unwilling to further antagonise. And ArbCom is yet to reinstate even one admin that it has desysopped. That's how dysfunctional it is. Hawkeye7 (discuss) 08:37, 17 April 2018 (UTC)

I dunno, can we assume that people are willing to tolerate frivolous opposition if it does not derail their (re)confirmations? "Grudge-based votes don't matter in the end" has been offered as an argument at all past discussions on this topic and yet no consensus for a community-based desysoping process has ever arisen, so maybe a lot of people are not willing. Jo-Jo Eumerus (talk, contributions) 08:43, 17 April 2018 (UTC)

That is exactly the reason why I opened this thread. The rationales aren't logical but based on a system at this point and that shouldn't be the way for things to move forward. I agree with Hawkeye7, AC processes are' dysfunctional, the fact that Tony and few others see it as a perfectly operating committee doesn't even occur to the majority of the community. The only reason AC exists as it is, is because the community still sees a need for a panel to deal with the issues, but nevertheless cannot fix the internal problems which arise from each of its outcome. That doesn't automatically imply that the community is fine with the ArbCom as-is. --QEDK (後 ☕ 桜) 08:01, 19 April 2018 (UTC)

In my view, I agree with "if it ain't broke don't fix it". However, RfA is broken. You only need to look at the most recent Admin newsletters to see the issue. Despite having a whole two (!) RfAs last month, we're losing Admins faster than we gain them. Yes, superficially, that's a direct result of community-endorsed processes to desysop inactive admins, but an inactive admin isn't any use to the project - I think we can all agree that we need a sizable number of active admins. We all know about RfA inflation, and there seems to be some form of consensus in the above posts that the reason for our loss of admins is the high bar to entry. The dispute here is whether we need to lower the bar to exit to lower the bar to entry, or would that be counterproductive. Ultimately, the only way to lower the entry bar is to convince RfA !voters to be more lenient. If it was easier to sanction misbehaving administrators, I expect more people would get the mop. Personally, I would suggest something similar to WP:ACTRIAL, but for a community sanction process (it probably should be limited in scope to admins appointed in the period in question). It would be interesting to see if RfA standards decreased if a desysop process existed, and whether that would lead to a corresponding increase in applications. Regarding sanctions available to the community, I note that ArbCom is capable of handing out temporary desysops - Wikipedia:Requests for arbitration/Pedophilia userbox wheel war. Much like escalating blocks, if the community is able to impose escalating desysops (perhaps leave permanent to ArbCom). I'm not certain myself, but we've got a wide range of options available. I'm sure there is some solution that exists that will achieve consensus, we just need to find it. I strongly believe, however, that we cannot just do nothing. ∰Bellezzasolo✡ Discuss 09:44, 17 April 2018 (UTC)

@Bellezzasolo: We could start by changing the current system where oppose !votes count three times as much as support !votes at RfA, by moving the discretionary range down to 50% and leaving it up to the 'crats. But yeah, RfA inflation is a problem, and the problem is us. — Insertcleverphrasehere ^{(or here)} 10:36, 17 April 2018 (UTC)

Admin activity at enwiki causes massive resentment from long term abusers down to POV pushers and editors who feel wronged, for example, by an unfavorable outcome at WP:AN3. Inclusionists passionately hate admins who delete pages, and deletionists passionately hate admins who reject speedy delete requests. Enwiki is the number one website for anyone wanting to spread their good news to the world; it's also the best place for spam and trolling and lots of other bad things. The best admins at enwiki spend serious time imposing sanctions and it is absurd to compare their activity with what stewards do, or with what happens at meta/commons/wikidata. The point about a community reconfirmation process is that it would boil down to a vote. People could argue that certain votes should be discounted because no good reason was provided or because the voter had only a handful of edits, but in the end a reconfirmation would be a count of votes. It might be possible to devise a system of voter eligibility requiring that the voter had never been sanctioned by the admin, and had never argued the opposite of a position taken by the admin in a dispute, and had 2000 edits and 12 months experience with 500 edits in the last six months. However, that approach would be rejected due to the overwhelming bureaucracy required. Johnuniq (talk) 10:10, 17 April 2018 (UTC)

Agreed 100% TonyBallioni (talk) 14:01, 17 April 2018 (UTC)

I think there is some value in comparing what other wikis do, at least hopefully to the point of not being "absurd". They might have less users, but there is no reason to believe that they would have proportionally less problematic users. That is especially true given that a lot of enwiki-banned users go over to Meta or Commons and have to be dealt with again there. So even though they have less users needing sanctions, they have less admins to give those sanctions, and thus the editors with grudges still exist and could still derail the process (but, again, don't). Anyway, I agree that ArbCom streamlining their process would be a positive here and would require less work that any community-initiated process. -- Ajraddatz (talk) 14:48, 17 April 2018 (UTC)

The fact that Commons is a haven for the people we show the door is precisely one of the many reasons we should not look to them for anything except copyright. TonyBallioni (talk) 14:57, 17 April 2018 (UTC)

Your point is that the POV pushers and axe-grinders are explicitly given free reign at RfA. And the solution is to restrict the editors who have access to the process. Which is, in fact, what we are already doing by giving the desysop function to ArbCom. Hawkeye7 (discuss) 21:44, 17 April 2018 (UTC)

I don't see why you would need to bear grudges against people who've moved on to other communities, your logic is simply a fallacy at this point. Sometimes it's best to take your own argument with a pinch of salt instead of apparently irrefutably stating that admins are fallible to socks/LTAs and we must do our best to protect them. Admins aren't at risk without exhibiting abuse and this is a step further in that direction as well. --QEDK (後 ☕ 桜) 08:01, 19 April 2018 (UTC)

• I guess this is starting to get a bit broader in scope. But I would agree without qualification that any move which helps simplify ArbCom is one in the right direction. One of my biggest problems with both AC/DS and ArbCom itself is that both are so ungodly complicated that they essentially don't exist as a form of dispute resolution that's available as a remedy for use by new and moderately experienced users. GMG^talk 14:13, 17 April 2018 (UTC)

I get the feeling, from TB and Kudpung, that the ArbCom process is actually likely to be sufficiently streamlined in its current form. However, I don't think that the actuality of that matters. There's a fairly wide perception of anything branded "ArbCom" as highly bureaucratic (which it of course is by necessity), and also slow and unwieldly. Furthermore, the result is a perception of Administrators as semi-untouchable. Hence the high standards at RfA. I doubt that a community process is necessary - it's likely to result in the same outcome as an ArbCom case would. However, I dare say there are users who would be happier handing out the bit if they felt more empowered to remove it. I also note the above discussion questioning the wiki-legality of TBAN'ing an admin from their tools. However, if we are able to TBAN an admin from certain tools (established), and CBAN admins, I'm pretty confident of the ability to TBAN the entire suite of tools. Of course, that differs from the technical ability to desysop - just like there's not technical enforcement of normal TBANs. I think that making this clear as an option - after all, the community is generally the ultimate seat of authority on non-legal issues, short of a Jimbovention. Of course, an admin could violate such a TBAN, but an ArbCom case would likely result. Perhaps an RfC and consultation with the Arbs on this is justified. I expect that, should a proposal as such pass, the community would feel empowered, without much changing (ArbCom can of course overrule such a TBAN, on an individual basis). ∰Bellezzasolo✡ Discuss 15:49, 17 April 2018 (UTC)

I don't think the TBAN would need consultation or an RfC. I think it would need to be tested. In other words, you would have to make the constitutional crisis in order to solve it. If the actions of an admin were really bad enough that there would be strong consensus for it, I doubt ArbCom would intervene to override it. Whether they would desysop someone for violating it may be a different story. It would be even more politically complicated if ArbCom actually declined a desysop, and then the community responded with a TBAN. If that ever happened all bets are off and I have no idea at all how it would work out. GMG^talk 16:08, 17 April 2018 (UTC)

(edit conflict) I found what I was looking for - User:Widefox/editors. In particular, this graph highlights the problem facing the community:

By 2030, I expect about 350 active admins and 400 semi-active, if current trends continue. ∰Bellezzasolo✡ Discuss 16:10, 17 April 2018 (UTC)

Actually, I think that would be a sufficient number. There are no substantial admin backlogs, and no indication that there would be any if we had half the present number.But Ido agree that the standard at RfA is sometimes absurdly high--however, the same people who make the standard so absurdly high would also be the ones who would try to desysop too readily. The system of ANI is rather often a system based on trying to do rapid prejudiced actions before the other side has a chance to protest. In contrast, my experience is that arb com is too slow and far too legalistic--more so than anyone who has not been an arb can realize, because the worst of the legalism tends to be in our internal discussions. It might perhaps be good if we had some sort of intermediary process, but I do not suggest adding to the complexity. We need instead to have arbs who are prepared to judge by the actual merits, not the technicalities (and this can be accomplished if more anti-bureaucratic people would be willing to take their share of the work); we also need to have some time delays built into ANB/ANI to decrease mobbing. Such proposals have been in the past rejected, but I think this needs to be reconsidered. DGG ( talk ) 23:51, 17 April 2018 (UTC)

DGG hits the nail on the head here in multiple ways. The easiest solution to ArbCom reform (and therefore, desysop reform) is not creating new systems (which we would have to do for any desysop process), it is electing individual arbitrators that will take community concerns seriously and be fine with a less bureaucratic process in the case system. On the flip side, the case request system has built in a delay that prevents the mobbing that we see at ANI. I think in clearcut cases, the committee should expedite the decision (which we saw relatively recently) and do an abbreviated case schedule. This can also be done by electing the people as arbitrators who are willing to hear things more quickly and on the merits, while also still respecting the process. Those are difficult things to balance, but I think it is the best way forward. TonyBallioni (talk) 23:59, 17 April 2018 (UTC)

Have all matters heard by a panel of 5 (3 is majority) (a clerk pulls names out of a hat at every filing, with a rotation procedure); elect 19 (so you have the possibility of 3 panels of 5 and spares left over for people who need time off/recusal/substitutions) - that should cut down on delays and behind the scene discussion (you can have rare fail-safe full ctte process after a panel happens to go really squirrelly). Alanscottwalker (talk) 00:27, 18 April 2018 (UTC)

We got rid of the subcommittees, because based my understanding, they weren't really working/it was basically whomever decided to show up. I suppose they could start a new subcommittee call it the review subcommittee or something like that, but I'm not sure how much of an appetite there would be for that. I think something that could be done without any additional structures would be to actually follow the procedures that say a case is accepted when four net arb votes are cast, and set the timetables to be 3 weeks instead of 6 for cases involving the conduct of one particular user (with the parties being able to ask for the full 2 weeks for evidence if they want). It'd build in the delay from the mob mentality that we fear, while also trying to streamline what is usually a 2 month saga between case request and end of decision. TonyBallioni (talk) 00:45, 18 April 2018 (UTC)

Well, no sub ctte in my suggestion, they are random panels, and you are assigned at each case, - they are smaller in number and should already be committed to be available (or already said they are unavailable). Alanscottwalker (talk) 00:58, 18 April 2018 (UTC)

• I know it's a popular theory (because it makes it easy to explain away the ills of the system), but I've never actually seen or heard any hard evidence that occasional ridiculously high standards are putting potential candidates off. It seems to me that such votes are made by people who don't have a clue what RfA and adminship is all about, they are not regular RfA participants, and they would probably not stand a chance of becoming an admin themselves.

Nor have I personally noticed any indication that the reasons for such high standards link to a perceived notion that it's too hard to remove the bit - again, such voters have such a shallow understanding of the process that they probably don't even think that far. More damage is done to RfA by people who serially make ridiculous oppose votes on the flimsiest of grounds, and who are also determined that even an RfA that is clearly going to pass doesn't get away without at least one vote in the oppose section. WP:RFA2011/VOTING is still the only in-depth research that was made into RfA voters and their trends and most of it continues to be largely accurate today, though an update to the stats would be interesting, .

I believe there is a growing apathy for maintenance work in general. I'm aware of TonyBallioni's view of WP:ORCP but while I think it's not such a bad initiative, it's also not used as often as it was. IMO, lowering the bar to adminship is absolutely not the way to go, but imposing a threshold for voting there almost is certainly worth considering, but an up to date WP:RFA2011/VOTING-style research would be needed to establish the criteria. What would be appropriate right now are a few T-bans for those who turn up to vote with the sole intention of creating more heat than light. If we lower the bar, we'll almost certainly risk have an increase in admins who do not really have the skill set for the job - and then we will need a fast track desysoping system. What we should be looking at are ways of reducing the bureaucracy, not creating more of it. Kudpung กุดผึ้ง (talk) 01:44, 18 April 2018 (UTC)

• The idea that the low rate of people becoming new admins is down to the lack of a community desysop process doesn't add up. The number of successful RfAs went from a peak of 408 in 2007 to 28 in 2012 and has remained at that kind of figure since. If that decline was due to admins being perceived as "untouchable", why weren't they perceived that way in 2007? The procedures for desysopping didn't change much between 2007 and 2012. If anything I think we are now a bit harsher on admins who screw up than we used to be. Doubtless there are several factors behind the decline in the numbers of successful RfAs, including standards inflation (standards have certainly gone up), reduced activity in the project generally (there is less admin work than there used to be) and possibly some decline of interest in maintenance tasks as Kudpung suggests. But I find it hard to believe that desysop procedures are much of a factor. On the other hand a community desysop process would mean more RfAs, or at least more of an RfA-like process. If RfA is broken then that's not a decision we want to make. Hut 8.5 20:11, 20 April 2018 (UTC)

  While there was a drop in raw edit levels from 2007 to 2014, before the 2015 rally, we still don't know whether the loss of edits due to the edit filters and the use of huggle etc to revert and block vandals faster means that there is more or less actual activity now than at the supposed peak in 2007. In any event the changes in level of activity on the site are minor when compared to the change in activity at RFA, especially as in a maturing community you would expect a growing proportion of editors to be admins rather than a declining proportion. But we should also remember that RFA has changed out of all recognition since 2007, in particular the biggest RFA reform, the unbundling of Rollback in early 2008, ended the era when "good vandalfighter" was sufficient qualification to pass RFA. There are now nearly five times as many Rollbackers as admins........ ϢereSpielChequers 21:14, 27 April 2018 (UTC)

  Actually, I did the back-of-the-envelope math a few weeks ago on the larger Wikipedia projects by active users, pulling numbers from here, and the ratio is fairly steady IIRC at about 0.5% to 1.5% of the total active population. Seems a lot like the top ~1% of most-admin-like (however you define that) users is pretty much the standard, and the changes in the community only affect what the top 1% most-admin-like users are defined as, and not what the ratio is. However, the changes in that definition are substantial, especially on comparatively tiny projects. RfAs on Commons make RfAs on enwiki seem like grotesque affairs, and it's still pretty big. Even more so for RfAs on something like Wikiquote or Simple, which don't even get as much participation as a standard RfC on enwiki.  GMG^talk 21:33, 27 April 2018 (UTC)

  Ratios may be currently similar across wikis, but that doesn't mean they are static. Or that editors making 5 or more edits a month is a relevant figure for the potential admin pool. If you take editors who make 100 or more mainspace edits a month, then the numbers for EN Wiki in 2018 are slightly higher than for 2012, but the number of admins has fallen steeply in the last 6 years. ϢereSpielChequers 06:18, 29 April 2018 (UTC)

Seeking consensus

As one of those who has regularly opposed having a second, parallel, community desysop process I suspect the onus is on me to explain why I, and I suspect many others, don't see the need for a parallel system in addition to ARBCOM.

1. On this wiki we have an ARBCOM, elected by the community and with the power to have admins desysopped or otherwise censured. Models of deadminship on wikis that don't have an ARBCOM equivalent are not really relevant to the discussion unless their proponents make a case as to why they think this rival system is better than ARBCOM. Assertions that admins are untouchable or that we don't have a community deadminship system I generally ignore unless they give examples of admin behaviour that ARBCOM won't sanction.
2. While I don't follow every question and thread in Arbcom elections every year, and it is several years since I've written a voting guide, I don't see the ARBCOM elections being dominated by discussion of types of "bad admin" that candidates want to be less tolerant of, or that the voters want candidates to be less tolerant of. ARBCOM elections involve far more participants than these perennial proposals to supplement ARBCOM, if there was community consensus to be stricter on say deletionist Admins who stretch the criteria of speedy deletion beyond consensus or Admins who don't reply to every query on their talkpage then I'd expect that to surface in the ARBCOM elections and to result in an ARBCOM that was less tolerant of that sort of admin misbehaviour. Instead we have proposals like this with abstract talk of "bad admins" who are "untouchable" as if ARBCOM didn't exist or never used its powers to desysop.
3. Then there is the issue of speed and timing and the related issue of privacy, ARBCOM has a proven record of desysopping people very very quickly when it is merited, and also having things take an extraordinary amount of time when people wanted to desysop someone who was not available to volunteer time here due to real life events. Remember the timing of an RFA is entirely up to the candidate, and since we are all volunteers it is or should be entirely acceptable for a controversial admin to email the Arbs, and say they don't want to out themselves, but they are on tour, sitting an exam, 8.75 months pregnant etc etc and unavailable for the next few weeks. Of course people are entitled to get miffed if an admin does that and then blithely edits multiple hours per day, but I'm not seeing ARBCOM being that gullible.
4. Since we already have one community based system to desysop people having a second parallel one is at best bureaucratic (some proposals have been incredibly bureaucratic), and at worst brings in the potential double jeopardy issues of what happens if someone is cleared by one process and then taken before the other.
5. As ARBCOM is elected by the community it has all the systemic advantages that indirect democracy has over direct democracy. In particular if we have a year when ARBCOM appears to have made some unsatisfactory decisions the electorate can, and in the past has, voted the incumbents out.

I think those are the main pitfalls that I and others have pointed out in a supplementary, parallel desysop system. My apologies if I've missed an important one. I hope this gives those who want two separate community deadminship systems some issues to ponder and points to cover if they want to pursue this further. ϢereSpielChequers 12:07, 29 April 2018 (UTC)

Add a notification for the the Signpost to the watchlist notice

Hello all, a discussion about using the watchlist notice to provide notification to users of new issues of The Signpost is open at MediaWiki_talk:Watchlist-messages#Signpost - your input is welcome at that discussion. Thank you, — xaosflux ^Talk 21:15, 29 April 2018 (UTC)

• As I have stated before, I support this idea because the Signpost serves as an important tool for the en.Wiki community to get informed about and discusd all kinds of topics. While these functions are important, it is currently in a crisis of readership (with the numbers steadily decreasing for the last years) resulting in a crisis of volunteers. A watchlist notification could be a first step out of this crisis. Zarasophos (talk) 21:38, 29 April 2018 (UTC)

@Zarasophos: This is not a vote. Xaosflux is just letting watchers of this page know about the other discussion. Chris Troutman (talk) 21:57, 29 April 2018 (UTC)

True enough, I guess I shouldn't do tired Wikipedia. Zarasophos (talk) 21:58, 29 April 2018 (UTC)

Commons deletion notification bot

Further information: meta:Community Tech/Commons deletion notification bot

This bot was proposed via the community wishlist in 2017. It is currently being build and should be done in a couple of months. The bot is going to be "opt in" and will place a notification on the talk pages of article when an image used within that article is put up for deletion on commons. Further details here. One eventual hope is to have the article alerts pages include these items. Wikipedia:WikiProject Medicine/Article alerts Peoples thoughts? Doc James (talk · contribs · email) 11:37, 27 April 2018 (UTC)

• I like it. Since the opt-in is going to be on a per wiki basis, It follows that an RfC should be started pretty soon. Am I correct?--John Cline (talk) 11:55, 27 April 2018 (UTC)
  • If there is strong support a formal RfC may not be needed, but we could definitely have one. Was hoping to start with a simple discussion to clarify any concerns. Doc James (talk · contribs · email) 13:40, 27 April 2018 (UTC)
• Sure. TonyBallioni (talk) 13:45, 27 April 2018 (UTC)
• Umm...whatever happens, it should be on a delay. Like a 24 hour delay. Take for instance an image like this one, that's unprotected on Commons, but used in 53k pages globally. We don't want someone nominating it for deletion just to spam 53k pages with notices before the frivolous nomination is reverted. GMG^talk 13:54, 27 April 2018 (UTC)

  There is a delay: 60 minutes for DR, 15 minutes for speedy. The planned implementation only notifies up to 10 pages per project. — JJMC89 (T·C) 03:54, 28 April 2018 (UTC)

  How does it decide? Useless if an image is "heavily" used but the notices are to pages that are rarely watched. — xaosflux ^Talk 04:41, 28 April 2018 (UTC)

  The current plan is to pick the 10 with the most watchers. — JJMC89 (T·C) 06:20, 28 April 2018 (UTC)

  @JJMC89: I hope that is throttled as well, what happens for example if I nominate commons:File:Yes check.svg - will it really pull watcher utilization from every single page? — xaosflux ^Talk 04:16, 30 April 2018 (UTC)

  I hope so too. The watchers part hasn't been coded (or at least not published), so I don't know yet.​ — JJMC89 (T·C) 03:34, 3 May 2018 (UTC)

  Eh. I would still prefer 24 hours...enwiki is like New Jersey, lots and lots of people in an itty bitty space. Commons is like Wyoming, big freaking place, but mostly empty. You know, 50 million files verses five million articles. That's a lot to watch out for. GMG^talk 11:24, 29 April 2018 (UTC)

  We could try a time period and than adjust if problems are seen. Doc James (talk · contribs · email) 22:45, 29 April 2018 (UTC)

• The bot would also need a WP:BRFA, but I don't see this being particularly problematic. Headbomb {t · c · p · b} 13:54, 27 April 2018 (UTC)
• Agree. The earlier notifications are made, the less likely deletions will be made prematurely. In fact, I rather thing that delaying telling folks that a deletion might occur is contrary to the intent of Wikipedia and Commons to retain as many images as possible, rather than to make deletion easier which occurs when folks are not notified. I have not found Commons to be excessively deletionist, nor would I wish it to become so. The Wishlist survey appears to be convincing here in its position. Collect (talk) 11:31, 29 April 2018 (UTC)
• Do people think we need a formal RfC? Or is the support here and during the proposal process for the creation of this tool sufficient? Doc James (talk · contribs · email) 03:30, 4 May 2018 (UTC)
  • When a change occurs that people were not expecting, there is often a backlash. If there is a RfC first, there is usuaally more acceptance, even if sometimes grudging. · · · Peter (Southwood) ^(talk): 07:56, 4 May 2018 (UTC)

Delhi Project Tiger Edit-a-Thon

Brief

An Edit-a-Thon with Workshop has been scheduled on below given dates. This is an initiative taken for Delhi-NCR Wikimedians/Wikipedians to support the PROJECT TIGER WRITING CONTEST. New editors will be introduced to Wikipedia and educated about the system. They would be trained to get engaged with Wikipedia by contributing their works.

All editors of Delhi-NCR are requested to attain the edit-a-thon with new contributors without any language barrier.

Bottom Line

• Adding up New Contributors
• New Contributors Orientation
• Workshop on Editing by Introduction of WMF, Wikipedia
• Training on language translation & Developing skills
• Educating about Wikimedia protocols, tools & system

Date

Day 1: Saturday, 2018 May 19, 10:00 AM IST
Day 2: Sunday, 2018 May 20, 10:00 AM IST

Venue

USO International Center
USO House, USO Road,
6, Special Institutional Area,
New Delhi - 110067

Link to Event Page

https://en.m.wikipedia.org/wiki/Wikipedia:Delhi_Project_Tiger_Edit-a-thon

Organizer & Ambassador

Raavi Mohanty 07:10, 5 May 2018 (UTC) Raavi Mohanty

The mess of actors by medium

I tried to start a CfD on this issue. It can be reached if you go to Category:Film actors and follow the lead. So far, it has very little participation, and one long winded, mean spirited objection. This despite the fact I literally went through 100 articles in preparation for the nomination, and demonstrated that in over 90% of those television actress articles there was overlap with other mediums. I also pointed out multiple cases, such as Star Trek, where the same actors played the same roles in both TV and film. This is about the only case where someone woould be so rude in response to someone having literally posted 79 categories to the nomination. Then there was a complaint about not posting to projects. Well, I tried to post to projects, but the guidelines on CfD in no way make it obvious how to post to projects. I tried to post to individual editors too, but the posting heading provided was just not working. This needs a wide discussion, but the general response exemplified by some commentators at CfD to just be rude to those who do not do the impossible of posting a proposal onto thousands of categories is troublesome. With the rise of categories like Category:American web series actors do we really want to categorize actors by how the creatin they were in was distributed. What are made for TV film actors? What about films first released on netflix? Where are the lines?John Pack Lambert (talk) 18:34, 5 May 2018 (UTC) I put this both here and in policy, I really do not know where to put it, I just want to start a true discussion. We need to avoid being hung up on the present way things are done.John Pack Lambert (talk) 18:36, 5 May 2018 (UTC)

Courtesy link: Wikipedia:Categories_for_discussion/Log/2018_April_28#Category:Actors_by_medium

Category tagging for article sections

Might it be useful to be able to list article sections in a given Category, where the main article topic is not suitable? For example the article on the Supermarine Spitfire prototype K5054 has a section on Replicas, while the de Havilland DH.88 Comet article has one on Airworthy reproductions and replicas. It would be useful to include these sections in Category:Replica aircraft. For example one might be able to add a template or a modified category tag to the section, for the sake of argument something like:

==Replicas==
[[Category:Replica aircraft|sortkey=Supermarine|section]]

which would list the section as:

• Supermarine Spitfire prototype K5054 § Replicas

Would such a system find much use? — Cheers, Steelpillow (Talk) 13:15, 5 May 2018 (UTC)

Probably, but I'm guessing this is significant work for no great amount of benefit. --Izno (talk) 13:56, 5 May 2018 (UTC)

• I think the normal practice so far has been to apply this categorisation to a representative redirect to that section. See Wikipedia:Categorizing redirects#Subtopic categorization. – Uanfala (talk) 20:21, 5 May 2018 (UTC)

  Thanks, that does it OK. — Cheers, Steelpillow (Talk) 07:41, 6 May 2018 (UTC)

Discussion about including video summaries of diseases

• Wikipedia_talk:WikiProject_Medicine#Video_reboot

Doc James (talk · contribs · email) 13:31, 8 May 2018 (UTC)

RfC: Ending the system of portals

Moved to Wikipedia:Village pump (proposals)/RfC: Ending the system of portals

 – Hi everybody. Because this discussion has become so lengthy (400,000+ bytes), I have moved it to a subpage of the village pump so that the village pump is more accessible. I apologize if any confusion has been caused by this. Mz7 (talk) 01:59, 18 April 2018 (UTC)

This entry got archived by a bot twice so far. I'm reposting it, because the discussion is live. 30 days will be up on the 8th.    — The Transhumanist   02:22, 28 April 2018 (UTC)

• I have notified admins on Requests for Closure for a verdict. Kirbanzo (talk) 19:00, 8 May 2018 (UTC)

Topical discussion, centralized

Propose discussion area organized around the most intuitive of principles, namely topics, so that for example Topic:Science would be too general but would lead to Topic:Science/Physics, Topic:Science/Health, Topic:Science/Mathematics, Topic:Science/Chemistry, Topic:Science/Materials. And so forth. -Inowen (talk) 07:46, 9 May 2018 (UTC)

Change "nationality" parameter to "country of citizenship" in infoboxes.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Many infoboxes have a parameter for "nationality", which frequently misleads editors to add links to disambiguation pages like Swedish, French, Russian, Chinese, Indian, Japanese, Italian, Brazilian, and so forth. These account for a steady proportion of disambiguation errors introduced on a daily basis. I believe that if the parameter was changed to something like "country of citizenship", it would reduce the incidence of people erroneously adding an ambiguous adjective when a place name is what is called for. bd2412 T 20:56, 9 May 2018 (UTC)

• Comment. Generally plausible, but a couple of things need to be thought about. First, not everyone with a nationality is actually a citizen (for example, American Samoans are US nationals but not US citizens). This is admittedly an uncommon case but it should at least be pointed out. Similarly, "country" is a slightly slippery term, especially in the case of the UK. --Trovatore (talk) 21:16, 9 May 2018 (UTC)
  • I thought about proposing "nation of citizenship", but I thought there might be some ambiguity with Native American tribes, which refer to themselves as "nations". I'm not terribly picky about it, actually. I just think "nationality" leads to errors. bd2412 T 22:24, 9 May 2018 (UTC)
    • So that addresses the "country" point but not the "citizen" one (American Samoans, as far as I know, are not citizens of anything, but are also not stateless, because they have a nationality). I agree it's not going to come up all that often, but I thought it should be pointed out. --Trovatore (talk) 05:13, 10 May 2018 (UTC)
      • I don't have exact details at hand, but it is my impression that some repressive regimes keep large numbers of people subservient by denying them citizenship. (Of course, if the regimes succeed in repressing these people, none of them will ever become notable enough to have a Wikipedia article, and we won't have to worry about it.) Also remember that these repressive regimes may be either in existence today, or could be historical regimes, such as the Roman Empire. Jc3s5h (talk) 11:14, 10 May 2018 (UTC)
• Comment: I agree with Trovatore. Furthermore, how does one classify the stateless? And, nolens volens, one must consider the legal issues surrounding citizenship, which often are arcane and convoluted enough such that one should hesitate before making such a change haphazardly. Semantic differences, after all, between citizen and subject aren't simply semantics: there were formerly British subjects who lacked citizenship in the United Kingdom. So, I would give this suggestion a great deal of thought. — Javert2113 (talk; please ping me in your reply on this page) 21:56, 9 May 2018 (UTC)
  • I would invoke the principle of least harm. The number of cases where the current wording causes an error to be made is likely much higher than the number of cases where an alternate wording would cause an error to be made. For "stateless" people, what do we currently put for "nationality"? I would guess most people put "None", which would remain the same, although there are also necessarily variations to that. bd2412 T 22:24, 9 May 2018 (UTC)
    • Do you have evidence that the current wording causes errors? Links to disambiguation pages are not errors, they are merely imperfections, forcing readers to click through an additional page. Labelling somebody as Scottish, English, British against their self-identification is an error. Divided postwar Germany causes lots of possible errors (and complications) labelling people, and whether there were two German citizenships depends on your political point of view. Pre-1871 Germany is significantly more complicated, and pre-1806 Germany is a nightmare. —Kusma (t·c) 09:27, 10 May 2018 (UTC)
      • Yes, I do have evidence. I have been one of the most active disambiguation fixers for the past ten years, and I have routinely come across new disambiguation links generated in this specific parameter, very frequently with the examples linked above. Links to disambiguation pages are defined by the project as errors needing to be fixed, since the disambiguation page will often just confuse the reader more than a correct answer. Constant accretion of new disambiguation links also gets in the way of the project identifying and fixing older and more egregious errors. bd2412 T 10:33, 10 May 2018 (UTC)

Oppose concepts like citizenship, nationality, ethnicity, and numerous others overlap but are not synonyms. --Jayron32 23:37, 9 May 2018 (UTC)

Oppose Technically we have to distinguish between the parameters title, how it is rendered on the screen and its intentional contents. We have enough difficulty explaining the difference between administrative county and ceremonial county. I imagine that the folk in Jerusalem, who see their city occupied and becoming the capital of a neighbouring state would have difficulty with that one- and closer to home the nationality dispute in Ireland has gone on for four centuries. ClemRutter (talk) 00:33, 10 May 2018 (UTC)

Good analogies Clem, and I agree, but conversly that puts me in a personal dilemma: Am I English, or do I have British nationality, or am I a citizen of the United Kingdom of Great Britain and Northern Ireland? I do resent the rest of the world using England/English as a default term for the UK - especially as, strangely, England is the only one of the constituent countries of the UK not to have its own national (or state) assembly - a situation people in federal countries (e.g. Australia, USA, Germany) may have even more difficulty getting their heads around. Kudpung กุดผึ้ง (talk) 06:34, 10 May 2018 (UTC)

Oppose. Solution looking for a problem. It would also open a can of worms in cases where people have dual nationality and/or dual citizenship. The terms are not necessarily synonymous and I think we should stick with what we have been doing without a ruble for years. For one thing, and really a side issue here, the whole concept of infoboxes in biographies is a highly contentious topic. Kudpung กุดผึ้ง (talk) 06:38, 10 May 2018 (UTC)

• In that case, we should just remove the parameter altogether. It is generating errors, and frankly, often no useful information, since more accurate and descriptive explanations of a person's origin are usually found in the text of the article. bd2412 T 10:36, 10 May 2018 (UTC)

• Oppose, but note that {{infobox person}} already has both "nationality" and "citizenship" parameters. As the concepts are often ambiguous, ill-defined or disputed (especially for historical characters), changing from making "nationality" a standard parameter to making "citizenship" a standard parameter just swaps one problem for another. That people link to ambiguous terms like German is not a problem. Links to dab pages can be easily spotted and fixed, unlike links to the wrong page that are hard to find. —Kusma (t·c) 09:19, 10 May 2018 (UTC)
  • Will you volunteer to take on the task of finding and fixing these errors going forward? bd2412 T 10:34, 10 May 2018 (UTC)
    • Will you volunteer to stop badgering people who happen to think differently than you do? --Jayron32 10:47, 10 May 2018 (UTC)
      • It's one thing if editors think differently; it's quite another (and an alarming one) if editors think disambiguation links are not a problem. bd2412 T 12:15, 10 May 2018 (UTC)
• Oppose - I personally think disambiguation links are much less of a problem than links which simply point to the wrong subject (for example the large number of links meant for New York City which used to point to New York when it was the state article). A reader landing on a dab page may experience some momentary confusion, but can easily enough then click through to the intended article. Plus, links to dab pages are spotted easily and dealt with routinely, through the dedicated efforts of those involved in the project to find them. Whereas incorrect links can only be found by going through them one-by-one. So, while it is of course useful to reduce the workload on those involved in the disambiguation project, to make their work easier, that should not take precedence over reader experience and article content, which is ultimately what the oppose votes in this debate are about. The demonym form is a much more usual way to describe a person than their citizenship, e.g. "Donald Trump is an American politician" vs "Donald Trump is a politician and citizen of the United States".  — Amakuru (talk) 12:51, 10 May 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

WikiProject Watch

I'm making this proposal here because I'm not sure if it means in the category if the WikiProject Council. After encountered a sockpuppet and having a little experience in global blocks, I had the idea of having a sort of watch in some WikiProjects that includes a tab in said projects with a briefing of the sockpuppeteer, their editing pattern and tools to deal with them. This would not be a mandatory feature and I think it's ideal for the largest projects, although if there has been disruptive editing in niche topics it could also be useful. The main projects I recommend that this feature is included in are:

• Biography WikiProject and its taskforces.
• Politics WikiProject and its taskforces.
• WikiProjects under the scope of Arbitration Comittee decisions.
• Other controversial topics.

Benefits of the proposal:

• Quick detection of a suspected sockpuppeteer, before they can disrupt several articles with their edits until they're found.
• Easier access to information of known sockpuppeteers and their behaviour pattern.
• Makes tasks easier in the long run for WikiProjects such as Counter-Vandalism Unit, Update Watch and Contributor clean-up, as well as other editors.

--Jamez42 (talk) 21:31, 10 May 2018 (UTC)

Proposal creating an event coordinator user right

There is currently a proposal at Wikipedia:Requests for comment/Event coordinator proposal about creating a new user right for event coordinators. All are invited to participate. TonyBallioni (talk) —Preceding undated comment added 14:27, 18 April 2018‎ (UTC)

Add a link to the Signpost to the Main Page

Yes, yes, I know, perennial proposals and all, but what about just a small link under Other areas of Wikipedia? The Signpost is definitely useful for getting up to date with what's going on in the community, and there's also a good deal of work going into it. However, it's nearly impossible to find it, and readership has been declining for several years. There have been several crises in the team itself, mainly due to a lack of contributors - which obviously get recruited from readers. Therefore, I think it's both in the interest of Wikipedia and of the Signpost to add a

- The Signpost – Stay informed on what's going on by reading the newspaper for Wikipedia.

to Other areas of Wikipedia. Thoughts? Zarasophos (talk) 08:46, 27 April 2018 (UTC) This proposal has been replaced by the idea of adding a notification to the watchlist as discussed further below. Zarasophos (talk) 21:33, 29 April 2018 (UTC)

This seems like a good idea. It will not take up too much room on the Main Page of Wikipedia to do this. Vorbee (talk) 10:11, 27 April 2018 (UTC)

• Support - why has this never been thought of before? Kudpung กุดผึ้ง (talk) 10:47, 27 April 2018 (UTC)
• Oppose - because the signpost is a bunch of navel gazing bullshit and editorials that almost always do not meet quality to be linked from the main page. Only in death does duty end (talk) 10:53, 27 April 2018 (UTC)
• Strong oppose-Mainly per OED, whilst distancing from the qualifiers:).Signpost is nowhere near to Mainpage-stuff.~ Winged Blades^Godric 11:05, 27 April 2018 (UTC)
• Oppose - navel gazing is enough for me.--John Cline (talk) 11:29, 27 April 2018 (UTC)
• Implemented already, sort of - we already have a link, "Site news". What's on the right? The template box version of the signpost. Plus you get other news sources. ∰Bellezzasolo✡ Discuss 12:23, 27 April 2018 (UTC)
• Add a watchlist notice instead (as I have suggested at various times and places). Add for say 3 days after a new issue is released. Now they will be monthly this should be acceptable. Signpost is most appropriate for regular (and so mostly registered) editors, for whom a watchlist notice is far more visible. Mind you, with a main page link you would benefit from the free attentions of User:The Rambling Man imposing his unique vision of the English language on you, which would make for highly entertaining talk pages. Johnbod (talk) 13:12, 27 April 2018 (UTC)

  Another stunning contribution, laced with personalisation and offensive pinging. Well played Johnbod, you are a shining example and we should all follow your methods. You were already told over at ERRORS just how wrong you were, why you would feel it necessary to bring that up in a completely unrelated topic is beyond me. It's not a good look John, it's not a good look at all. The Rambling Man (talk) 14:23, 27 April 2018 (UTC)

  Actually I wasn't "told" at all, until someone else informed me after the event, as you insist on the editors whose work you attack so freely at ERRORS not being notified (see over there)! And you were wrong. Unlike you I believe in pinging people when their work is being criticized - there is such a thing as unproductive and "offensive non-pinging". Johnbod (talk) 16:08, 27 April 2018 (UTC)

  You're just making yourself look bad here John, really really bad. Continue, by all means, but don't say you weren't warned. Tsk. The Rambling Man (talk) 18:11, 27 April 2018 (UTC)

  Note, on request I gave the signpost a 1 week trial on watchlist last issue, and asked the editors to seek wider consensus if it should be recurring in the WL. (c.f. MediaWiki_talk:Watchlist-messages#Signpost). — xaosflux ^Talk 15:51, 27 April 2018 (UTC)

• Oppose The signpost is primarily written for editors and not for our non-editing readers. --Jayron32 13:14, 27 April 2018 (UTC)
• Moot As Bellezzasolo points out, we already have this. He pointed to the Site News link. Signpost is also prominent in the Community portal which is linked in the sidebar for every page, not just the Main page.Andrew D. (talk) 14:59, 27 April 2018 (UTC)
• Oppose -actually strong oppose if it means anything. Signpost is nothing more than glorified WikiProject newsletter. It is nowhere near the standard of being in the main page. –Ammarpad (talk) 15:16, 27 April 2018 (UTC)
• Support - Signpost builds and indicates community which is what we want to broadcast to readers and editors. The quality is fine, better than fine considering it's volunteer grass roots with 0 budget, like most everything else on WP. Our ethos is open knowledge for all, but many have an attitude that open knowledge about Wikipedia itself is not of public interest. Far from it. -- GreenC 15:58, 27 April 2018 (UTC)
• Oppose for "publicity", posting the Signpost to places like the Teahouse or WP:AN would be better. For the mainpage itself, making the link to Wikipedia:News more prominent would be most helpful. power~enwiki (π, ν) 18:13, 27 April 2018 (UTC)
• Oppose as per above - Do we really think our non-editors would care about "Admin reports board under criticism", " WikiProject Military History" or "ACTRIAL results adopted by landslide" ? ... No ofcourse they wont, The Signpost is more of an editor thing than a reader thing. –Davey2010^Talk 21:32, 29 April 2018 (UTC)

• Before some smart-arse comments on the "Reader" part - When I say Reader I mean Non-editor. –Davey2010^Talk 21:32, 29 April 2018 (UTC)

• Conditional - if it receives recurring watchlist notification, as was trialled with the last edition courtesy of xaosflux, then I don't think it needs Main Page publication (Personally I'd like it, but I see the arguments against). If it isn't going to have the watchlist, then I "vote" support. There is discussion on the recurring bit at MediaWiki_talk:Watchlist-messages#Signpost Nosebagbear (talk) 12:44, 1 May 2018 (UTC)
• Support From my experience with newbies in public wiki workshops, I think a lot of readers will actually find the Signpost informative and a fascinating insight into the community.--Pharos (talk) 04:53, 7 May 2018 (UTC)
• Support -Indy beetle (talk) 22:50, 7 May 2018 (UTC)
• Weak Oppose - I like the idea of the watchlist notice, to involve more editors who might not otherwise be looking, but I don't think the content of the Signpost is appropriate to try to put in front of people who don't understand the context. The Signpost frequently contains editorializing/commentary/humor that, while well and good within the community, would be confusing to someone unfamiliar with Wikipedia process who comes to it through the main page. — Rhododendrites ^talk \\ 04:31, 8 May 2018 (UTC)
• Weak oppose. The Signpost is geared mostly toward editors so I wouldn't place it on the Main Page. However, I'm fine with placing the notice on centralized discussion, or AN, or other place where editors frequently congregate. epicgenius (talk) 18:35, 8 May 2018 (UTC)
• Oppose per Epicgenius; non-editors don't have any reason to see it. Unlike other editing-related things on the Main Page (e.g. the link to WP:CP in the "Other areas of Wikipedia" section), it's not something that's intended to arouse editing interest in non-editors. Nyttend (talk) 23:00, 8 May 2018 (UTC)
• Maaaaayyybe It might help give non-editing readers some insight into how things work, and whether they want to stick a toe into the editing side of things. What they'll think of that, well, who knows. --Trovatore (talk) 00:17, 9 May 2018 (UTC)
• Support - long-running community initiative that deserves an audience and that showcases how Wikipedia works. Amisom (talk) 10:19, 14 May 2018 (UTC)

New version of Template:Restricted use?

I thought that the current template for restricted use looked a bit simple and needed to be more obvious than it currently is.

Templates

Original: Category:Wikipedia restricted images New version: This image is protected from use on certain articles as it has a history of being used for vandalism or is otherwise inappropriate for use on pages other than that which it is specifically allowed. If you have a legitimate, encyclopedic use for this image, either contact an administrator or file a request for it's use by pressing the button below.

^{[Username Needed]} 08:35, 15 May 2018 (UTC)

Getting an alert any time someone edits any file in your user and user talk areas

For the moment you normally do not get an alert when someone edits a file in your user and user talk areas except when they edit your talk page ("leave a message").

Is there a way/an option to get an alert any time someone edits any file in your user area and user talk area including subpages?

If there isn't, would it be possible to easily add that feature, perhaps as an option?

I don't think "just add all those files to your watchlist" would be an answer. There are reasons why you wouldn't want to clutter your watchlist with those files. And since you do get an alert when your talk page is edited even though you could "just add your talk page to your watchlist" I would say that seems to be generally understood.

Thanks.

Basemetal 10:59, 15 May 2018 (UTC)

Have you considered filtering the watchlist result on User space? Alerts should be low-noise and user subpages can generate a lot of edits. Watchlists are for monitoring higher volume pages there are filtering options to remove clutter. -- GreenC 17:03, 15 May 2018 (UTC)

And those filtering options only affect files in user space. How do you do that? I've looked through the Watchlist tab in my Preferences and I could see nothing that does that. Basemetal 17:30, 15 May 2018 (UTC)

You could try making yourself an index of pages you want to monitor, and then subscribing to "related changes" from that page. For example, see Special:RecentChangesLinked/User:Basemetal. You can subscribe to an Atom feed from that page, although I don't know the details of how to set that up. I know that's not exactly what you're looking for but it might suit the purpose. Ivanvector (^Talk/_Edits) 17:12, 15 May 2018 (UTC)

Ok. Thanks. I'll try to understand what you're saying. Basemetal 17:30, 15 May 2018 (UTC)

This is something I've wondered about, too. Userpages in some ways represent that person and/or their work/contributions. If someone vandalizes my userpage and I weren't someone who checks my watchlist regularly, I would want to be notified. Sure, bots/vandal fighters catch a lot of these, but not all of them. — Rhododendrites ^talk \\ 17:26, 15 May 2018 (UTC)

Hear, hear! Basemetal 17:30, 15 May 2018 (UTC)

Related tickets: phab:T3876 and phab:T166924 ~ Amory (u • t • c) 11:30, 16 May 2018 (UTC)

Policy based RfC

An RfC of probable interest is published at Wikipedia talk:Appealing a block#RfC about appealing a block and Wikipedia "standard offer". Thank you and please act accordingly.--John Cline (talk) 17:00, 10 May 2018 (UTC)

• Please place this in Wikipedia:Village pump (policy) if it is about policies, not Wikipedia:Village pump (proposals).

  I placed a courtesy notification both here and at vpp simultaneously when the RfC published. I did that because the RfC is published to two categories: Wikipedia:policies and guidelines and Wikipedia:proposals. The notification, here, is proper. Cheers.--John Cline (talk) 11:33, 16 May 2018 (UTC)

Article orphan clean-up RfC

There is a massive backlog of very old article orphans. I propose that we have a clean-up of these unnecessary articles where the community gets together and clears out as much of the very old orphaned articles as we can. What do you think? ^{[Username Needed]} 08:53, 15 May 2018 (UTC)

orphans ≠ unnecessary at all; that's what I think. Johnbod (talk) 13:49, 15 May 2018 (UTC)

If you mean deorphaning the very old articles than yes I agree. However, being an orphaned article does not mean it is not notable. I have deorphaned multiple articles that are Good Articles, and there are currently a few orphaned Good Articles as well. It just means that there are not links to it. However, you might mean articles that are unnecessarily orphaned? I'm also confused as well based on the other comments and my additional edits to my comments. --MrLinkinPark333 (talk) 16:20, 15 May 2018 (UTC)

Just to clarify, you mean "adding the article as bluelinks to other articles" correct? Because that is how you remove orphan status. If so, I can pitch in and help such a drive. Also, I don't see how you need an RFC to do that. Maybe set up some sort of drive organization page to encourage people to help. That's about it. --Jayron32 16:28, 15 May 2018 (UTC)

Yes, i mean deorphaning. When I say "Clearing out the articles" I meant clearing the orphan backlog. Specifically the feb 2009 backlog. ^{[Username Needed]} 07:58, 16 May 2018 (UTC)

Ok, but your use of "unnecessary articles" was ambiguous. I have seen the idea around that long-term orphans are ripe for deletion, which is often not true at all, as others have said. Some articles are likely to remain orphans, but still be fine. Of course many can be linked to & so cleared. Johnbod (talk) 16:03, 16 May 2018 (UTC)

Glad to hear you want to clear out the oldest backlog. I've participated in a backlog drive for orphaned articles in 2014. Maybe that could be used as a reference. --MrLinkinPark333 (talk) 18:38, 16 May 2018 (UTC)

One thing that certainly needs cleaning-up is the organization and categorization of the clean-up pages. I found a set of pages I'd never seen before with tagged pages by topic, and after doing quite a few yesterday now I can't find it again, after a fairly long search. The "by-date" categories don't encourage good editing by those with knowledge of particular areas. There is a lot of wreckage of long-abandoned initiatives and projects that ought to cleared away, or at least delinked. Johnbod (talk) 19:22, 16 May 2018 (UTC)

@Johnbod: Are you referring to WikiProject Cleanup Listings? Or it could be in one of the cleanup/maintenance categories. --MrLinkinPark333 (talk) 14:40, 17 May 2018 (UTC)

Thanks, it was the "by category" page from that. Very handy. Johnbod (talk) 15:17, 17 May 2018 (UTC)

Proposed Bot for tagging BadSVG files.

Example of reasonable SVG file with embedded raster image.

Which can also be scaled.

Some SVG files are no more than a bitmap file with an SVG "wrapper". When I have found them in the past, I have added {{BadSVG}} to them. There will be plenty of others I have not seen. It is proposed for a new bot to go through the SVG files we have and when it finds the start of a hex code stream (i.e. like xlink:href="data:image/jpeg;base64,), it tags the file with the {{BadSVG}} template. The file names will then be in Category:SVGs for cleanup where interested editors could consider cleaning them up. Once we have examined the existing files, the bot can be adjusted just to examine new uploads. Ronhjones  ^(Talk) 20:01, 8 April 2018 (UTC)

Great idea. Embedding raster graphics in a "scalable" format is pretty pointless and may confuse readers/re-users when they don't scale as expected. -FASTILY 21:51, 8 April 2018 (UTC)

Raster images in an SVG file should scale just like other raster images. Glrx (talk) 22:44, 25 April 2018 (UTC)

We also need a better process for getting rid of these images. Uploading a real SVG is preferable in cases where one exists, but in cases where no real SVG can be found, it is still preferable to replace a "fake" SVG with a real raster image. If it's a non-free image, it's fairly simple to swap it out in the article and then tag it as orphaned, but if it's not, I've had {{Obsolete}} tags removed since the replacement image wasn't the same file type. --Ahecht (TALK
PAGE) 20:48, 13 April 2018 (UTC)

We could do with a new or expanded speedy to cover that. I've done some in the past, taken out the jpg and replaced it in the article. But there is always the risk that someone will swap it out in the 7 days that F5 takes to mature. Maybe expand G6? Ronhjones  ^(Talk) 16:19, 16 April 2018 (UTC)

I built a tool several months ago to download the first 4 KB of every SVG on Commons. And I investigated this, finding three usages of bitmaps:

1. The bitmap off canvas or behind an SVG traces, such as File:649th Military Intelligence Battalion Coat of Arms.svg
2. Mixed use: Small bitmap used for a tiny element, interactive SVGs
3. Full Bitmap in an SVG wrapper, such as File:Pst-geo.svg

I scanned the 1.2 million SVG January Commmons dump and found 2,457 SVGs with 3+ KB base64. — Dispenser 03:06, 25 April 2018 (UTC)

• Oppose. It is inappropriate to automatically label any file with an embedded stream as bad SVG. One application of SVG is to provide a bitmap image with editable text labels. See File:Moon names.svg, which is an image of the moon with text labels in both English and Ukrainian; there are also German, Bulgarian, Chinese, and Spanish versions. A bot could capture six reasonable images and inappropriately label them as bad. Imagine a picture of the thoracic cavity with text labels for lung, heart, and aorta. See File:Blausen 0458 Heart ThoracicCavity.png. Yes, it is a PNG, but there could be an SVG-labeled version. There's been a project to do that for many images. See the SVG text labels in c:File:Defecating into a pit (raster).svg. Admittedly, the pit image is simple enough that it should have been vectorized rather than kept as a bitmap, and the project has lost its way by spawning translated JPEGs rather than translated SVGs. Yes, there are inappropriate SVG files out there, but that does not mean all SVGs with raster data are bad. Glrx (talk) 22:44, 25 April 2018 (UTC)

@Glrx: Maybe the template name is wrong? (not my template!) - Template:Bad SVG - only has the word "bad" in the title. Perhaps it should be more like "SVG with Raster". My view is that, if they were tagged then it would give a list for subsequent review. Ronhjones  ^(Talk) 14:26, 27 April 2018 (UTC)

@Ronhjones: The use of "bad" in the name is an intent to say that the SVG format has been misapplied. The text of the template ("This SVG image contains embedded raster graphics. Such images are liable to produce inferior results when scaled to different sizes.") does not explain the problem. Scaling of continuous tone images (typical photographs) is usually not a problem. Magnify the image enough and you will hit a resolution limit, but that is not a misapplication of a raster. That's why the Moon names raster is reasonable. If small, discrete tone, text characters (or curved shapes or non-Manhattan geometry shapes) are present in a raster image and then magnified, the anti-aliasing will blur the desired character, destroy the discrete tones, and fail to maintain / reconstruct the desired shape. There is nothing inherently wrong with inserting a raster image into an SVG file, so tagging an SVG file with an embedded raster seems like overkill. The problem is when the raster image contains drawn geometrical shapes. Sort of if the raster existed as a PNG, then somebody would come along and tag it with {{Convert to SVG}}. Even if somebody were to just stick such a PNG inside an SVG file, that would be a step in the right direction: maybe somebody will come along and replace the rasterized geometrical shapes with scalable vector shapes and remove the raster. There's not a compelling reason to delete such an SVG file; it might improve. On the other hand, an SVG that is just a continuous tone portrait of Winston Churchill probably has no business being an SVG file; JPEG would serve the purpose. None of these cases are simply detected with a string match. Tagging all of them for review does not seem to have a significant priority. So the SVG is bad/poor/misapplied. Why does it have to be examined/fixed/deleted right now? I blanche when I look at all the defecating-into-a-pit JPEGs. They are wrong in so many ways, but many of the African languages are not accessible, and the images don't need to be fixed today. Glrx (talk) 16:45, 27 April 2018 (UTC)

@Glrx:Oh, OK. I started this thread as I discovered that there were a few (it was about a dozen in a random 400) non-free SVGs which were which were just a photograph (and a high res one at that) - they were all converted back to jpg and scaled to an appropriate non-free size. Looks like it needs more of a manual examination. Ronhjones  ^(Talk) 16:58, 27 April 2018 (UTC)

Good arguments and thanks for your kind words about my moon SVG, Glrx. Another set of SVGs with embedded bitmaps are interactive renditions of GIF animations:

• user:cmglee/Dynamic_SVG_for_Wikimedia_projects#GIF_animation_to_SVG_converter
• http://commons.wikimedia.org/wiki/Category:Interactive_3D_SVG

They could arguably be converted into video clips, but that would lose quality due to recompression. Cheers, cmɢʟee⎆τaʟκ 17:11, 29 April 2018 (UTC)

• needs some work What we need is some reporting tool to tag candidates and which can be told of the apparent few where there is a larger raster which is nonetheless appropriate. Mangoe (talk) 13:50, 26 April 2018 (UTC)

@Mangoe: I can't see why a bot could not work out the percentage of raster and maybe categorise into, say, low / medium / high levels of raster image. Ronhjones  ^(Talk) 14:26, 27 April 2018 (UTC)

Just to add there are 14222 non-free SVGs and 6815 free SVGs in en-wiki Ronhjones  ^(Talk) 14:26, 27 April 2018 (UTC)

I ran the head download script last week. So I have 690 SVGs on the possibly bad list, but haven't time to refine it. A simple method for culling labeled or drawn over SVGs is to count the number of opening tags (<). — Dispenser 03:39, 4 May 2018 (UTC)

From a technical standpoint, I didn't notice any of those SVG files deserving a Bad SVG label. They are predominantly logos that have geometric shapes, so they should be SVG files. On the other hand, many of the images are non-free fair use, e.g., File:American Heart Association Logo.svg, so we may not use high resolution versions of them. That is, converting them to SVG would be a pointless exercise. The files are already tagged for fair use, so I'd just let them be.

For a non-logo example, File:Cauldron.svg is an appropriate use of SVG. It has both bitmap and vector elements; it is using SVG gradient fills. It could have been done with all SVG elements. Glrx (talk) 23:32, 6 May 2018 (UTC)

Try these from the list: File:Ctvhd.svg, File:BetterWorldBooksLogo.svg, File:BSicon box.svg, and File:Akhmat Grozny logo.svg. — Dispenser 04:24, 16 May 2018 (UTC)

@Dispenser: All of those files make sense as SVG files (I reverted one to an earlier non-bitmap). They are simple shapes that can be described with vectors and curves. They fit in the images "that have geometric shapes, so they should be SVG files". In a free world, it would be better if the internal bitmaps were vectorized, but imagine somebody coming along later and running a bitmap-to-vector converter on the images. If the image is non-free, then WP should not have a high-resolution version of it, but that can be achieved by applying a Gaussian blur filter to the SVG so the image looks fuzzy even when enlarged. Glrx (talk) 15:01, 16 May 2018 (UTC)

• Partial oppose As per Ronhjones, I think it shouldn't be called "BadSVG". A different name e.g. "SVG with embedded bitmap" is fine. cmɢʟee⎆τaʟκ 17:11, 29 April 2018 (UTC)

---

346 SVGs which don't use any drawing elements besides <image>. These should be tagged with one of the aforementioned templates. — Dispenser 03:48, 17 May 2018 (UTC)

• Oppose. What template would you use? It's already SVG, so {{Convert to SVG}} doesn't make sense. The images are appropriate for SVG format, so {{Bad SVG}} or its rename isn't appropriate. Yes, they have embedded bitmaps, but they are non-free logos. Most of the files are in the same limbo-land hell of File:Liga Elitelor U17 logo.svg. A {{Bad SVG}} tag is saying the file has a raster image so it is probably poor quality and should be vectorized, and another tag is saying it is a non-free image and the quality should be reduced because it is a smidgen over 100k pixels. Don't add more images to the schizo soup. Glrx (talk) 05:51, 17 May 2018 (UTC)

Don't even get me started on {{non-free reduce}}. 0.1 megapixel is just a suggestion -- it's rediculous that we're tagging anything under 0.15 megapixels (or even 0.2). --Ahecht (TALK
PAGE) 14:27, 17 May 2018 (UTC)

• I think the better solution is to write a bot to pop out the raster data, upload it as a new file, update links to the file to use the raster image, and then tag the SVG for deletion (ideally under CSD F1 since, despite having a different file extension, the underlying data is in the same file format, but it could also be a mass FFD). --Ahecht (TALK
  PAGE) 14:27, 17 May 2018 (UTC)

  I don't think it is worthwhile to invest time and resources in massaging/improving/dressing-up non-free files. Turning SVG versions into PNG versions is make-work. Why make another copy of a crappy file? Why waste the effort of relinking and deleting the resulting orphan? The SVG will serve. Let sleeping dogs lie. Glrx (talk) 14:59, 17 May 2018 (UTC)

  In the past I have found non-free svg files with a big sharp raster image inside, and I have extracted the image out and saved as a jpg - after changing the article, the svg then naturally got deleted as orphaned (these were not logos, they were proper pictures). Thanks to Dispenser for the list of image-only svg. That list will be saved - I will have a manual review and see if any do need to be extracted. I think the overall opinion is not for a bot for adding "BadSVG". Ronhjones  ^(Talk) 17:40, 17 May 2018 (UTC)

Proposal to remove the village pump

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

As a United citizen of the Australia, I have a propose to remove the village pump. Why, do you ask? Because villag pump does not work. Time after time, coming from an experience Wikipedier as myself, the Village pump fails to provide any resolution or support. I propose it will be replaced with a place called the Discussion section. Milchsnuck (talk) 02:45, 19 May 2018 (UTC)

I'm relatively new here, but in my experience the Village Pump works fine. What will be different about this Discussion section? TeraTIX 03:11, 19 May 2018 (UTC)

Hmm, strange that a user with two edits decides to make both of them a proposal to remove the village pump. I really wouldn't take this seriously. Master of Time (talk) 03:16, 19 May 2018 (UTC)

Hmm indeed.TeraTIX 03:18, 19 May 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

should there be a Wipedian High Council

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think a group of 10 people to govern all of Wikipedia what are your thoughts — Preceding unsigned comment added by Government Man (talk • contribs)

No. doktorb _words^deeds 18:11, 21 May 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.