Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia
  Policy   Technical   Proposals   Idea lab   Miscellaneous  

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147

Automated article assessment

Further discussion continued at Wikipedia:Bot requests/AutoAssessBot Aymatth2 (talk) 12:22, 18 April 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.

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 (talkcontribs) 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 (talkcontribs) 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. SQLQuery me! 19:49, 10 April 2018 (UTC)
I ran wp10 over CAT:FA, results were interesting. SQLQuery 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 (talkcontribs) 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. SQLQuery 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

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 (utc) 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)

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)

Proposed Bot for tagging BadSVG files.

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)
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)

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/[email protected] 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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:

Wp.en.admin-numbers2.svg

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)

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)

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)
  • 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)
  • 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??

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)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=837892231"
This content was retrieved from Wikipedia : http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)
This page is based on the copyrighted Wikipedia article "Wikipedia:Village pump (proposals)"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA