Wikipedia:Village pump (proposals)/Archive 147

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

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

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

  WP:RX. With regards to editors leaving, I thought probably a computer programme could take care of that. On joining, the editor would create his/her own library page - something like this. The programme would then create a page for each book, similar to this and add your user name along with any subsequent users who had that same book in their library. When someone retire, they wipe their library page and the programme removes their name from each book page. Again, I'm not a programmer so I don't know what's possible.--Ykraps (talk

  ) 12:14, 11 April 2018 (UTC)

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

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

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)

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)

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

• Draft Banner (EN)

Discover Russia. 2018 FIFA World Cup Cities & Regions

Write articles, upload images and win prizes!

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

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

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

• Banner (EN)

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

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

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

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

Like a meta-wikia.....

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

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

@

List_of_fictional_towns_and_villages. Can you clarify what you are looking for? RudolfRed (talk

) 03:05, 24 April 2018 (UTC)

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

I've started an RFC at

I've closed this as SNOW oppose.

π, ν

) 16:20, 9 May 2018 (UTC)

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

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

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

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

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

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

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

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

That would be somewhat resolved by limiting desysop discussions to an

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

) 17:00, 15 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

the unblockables phenomenon much worse than it already is. TonyBallioni (talk

) 13:52, 16 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

However, this raises a few more questions:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

WP:BARC. The issue there is that ArbCom is already that body: it is elected by the community every year to handle, among other things, desysop requests at the request of the community and with community comment. TonyBallioni (talk

) 15:49, 16 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But no, the community doesn't decide everything. There are some things that are decided by the WMF. We cannot, for example, eliminate ArbCom all together. Their existence is mandated by the foundation. We cannot reach a consensus to disregard

office actions. And if a steward ever showed up on enwiki and unilaterally removed the admin rights under those circumstances, lids would be violently flipped in every direction. GMG^talk

18:58, 16 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

I mean we do a half decent job of it half the time. There's currently a discussion ongoing at

WP:ACREQ where more than 200 people have weighted in so far. GMG^talk

19:48, 16 April 2018 (UTC)

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

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

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

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

• If the community can grant adminship, the community should be allowed to take it away. RfA activity remains extremely low, in part because adminship really has become a
  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

@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

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

) 10:10, 17 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nor have I personally noticed any indication that the reasons for such high standards link to a perceived notion that it's too hard to remove the bit - again, such voters have such a shallow understanding of the process that they probably don't even think that far. More damage is done to RfA by people who serially make ridiculous oppose votes on the flimsiest of grounds, and who are also determined that even an RfA that is clearly going to pass doesn't get away without at least one vote in the oppose section.

WP:RFA2011/VOTING

is still the only in-depth research that was made into RfA voters and their trends and most of it continues to be largely accurate today, though an update to the stats would be interesting, .

I believe there is a growing apathy for maintenance work in general. I'm aware of

WP:RFA2011/VOTING-style research would be needed to establish the criteria. What would be appropriate right now are a few T-bans for those who turn up to vote with the sole intention of creating more heat than light. If we lower the bar, we'll almost certainly risk have an increase in admins who do not really have the skill set for the job - and then we will need a fast track desysoping system. What we should be looking at are ways of reducing the bureaucracy, not creating more of it. Kudpung กุดผึ้ง (talk

) 01:44, 18 April 2018 (UTC)

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

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

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

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

Seeking consensus

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Brief

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

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

Bottom Line

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

Date

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

Venue

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

Link to Event Page

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

Organizer & Ambassador

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

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

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

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

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

which would list the section as:

• Supermarine Spitfire prototype K5054 § Replicas

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

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

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

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

• Wikipedia_talk:WikiProject_Medicine#Video_reboot

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

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

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

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

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

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

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

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

Benefits of the proposal:

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

--

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Templates

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

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

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

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

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

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

Thanks.

Basemetal 10:59, 15 May 2018 (UTC)

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

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

You could try making yourself an index of pages you want to monitor, and then subscribing to "related changes" from that page. For example, see

Atom feed from that page, although I don't know the details of how to set that up. I know that's not exactly what you're looking for but it might suit the purpose. Ivanvector (^Talk/_Edits

) 17:12, 15 May 2018 (UTC)

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

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

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

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

An RfC of probable interest is published at

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

  I placed a courtesy notification both here and at vpp simultaneously when the RfC published. I did that because the RfC is published to two categories:

  John Cline (talk

  ) 11:33, 16 May 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

@

Template:Bad SVG - only has the word "bad" in the title. Perhaps it should be more like "SVG with Raster". My view is that, if they were tagged then it would give a list for subsequent review. Ronhjones  ^(Talk)

14:26, 27 April 2018 (UTC)

@

Convert to SVG}}. Even if somebody were to just stick such a PNG inside an SVG file, that would be a step in the right direction: maybe somebody will come along and replace the rasterized geometrical shapes with scalable vector shapes and remove the raster. There's not a compelling reason to delete such an SVG file; it might improve. On the other hand, an SVG that is just a continuous tone portrait of Winston Churchill probably has no business being an SVG file; JPEG would serve the purpose. None of these cases are simply detected with a string match. Tagging all of them for review does not seem to have a significant priority. So the SVG is bad/poor/misapplied. Why does it have to be examined/fixed/deleted right now? I blanche when I look at all the defecating-into-a-pit JPEGs. They are wrong in so many ways, but many of the African languages are not accessible, and the images don't need to be fixed today. Glrx (talk

) 16:45, 27 April 2018 (UTC)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Oppose. What template would you use? It's already SVG, so {{
  Bad SVG}} tag is saying the file has a raster image so it is probably poor quality and should be vectorized, and another tag is saying it is a non-free image and the quality should be reduced because it is a smidgen over 100k pixels. Don't add more images to the schizo soup. Glrx (talk
  ) 05:51, 17 May 2018 (UTC)

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

• I think the better solution is to write a bot to pop out the raster data, upload it as a new file, update links to the file to use the raster image, and then tag the SVG for deletion (ideally under
  FFD). --Ahecht (TALK
  PAGE
  ) 14:27, 17 May 2018 (UTC)

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

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