Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- Consider developing your proposal at Village pump (idea lab).
- Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
- Proposed policy changes belong at Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
RfC: Ending the system of portals
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)
Bumping thread for 30 days. Mz7 (talk) 06:51, 28 April 2018 (UTC)
Proposed Bot for tagging BadSVG files.
Some SVG files are no more than a bitmap file with an SVG "wrapper". When I have found them in the past, I have added {{BadSVG}} to them. There will be plenty of others I have not seen. It is proposed for a new bot to go through the SVG files we have and when it finds the start of a hex code stream (i.e. like xlink:href="data:image/jpeg;base64,), it tags the file with the {{BadSVG}} template. The file names will then be in Category:SVGs for cleanup where interested editors could consider cleaning them up. Once we have examined the existing files, the bot can be adjusted just to examine new uploads. Ronhjones (Talk) 20:01, 8 April 2018 (UTC)
- Great idea. Embedding raster graphics in a "scalable" format is pretty pointless and may confuse readers/re-users when they don't scale as expected. -FASTILY 21:51, 8 April 2018 (UTC)
- We also need a better process for getting rid of these images. Uploading a real SVG is preferable in cases where one exists, but in cases where no real SVG can be found, it is still preferable to replace a "fake" SVG with a real raster image. If it's a non-free image, it's fairly simple to swap it out in the article and then tag it as orphaned, but if it's not, I've had {{Obsolete}} tags removed since the replacement image wasn't the same file type. --Ahecht (TALK
PAGE) 20:48, 13 April 2018 (UTC) - 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:
- The bitmap off canvas or behind an SVG traces, such as File:649th Military Intelligence Battalion Coat of Arms.svg
- Mixed use: Small bitmap used for a tiny element, interactive SVGs
- Full Bitmap in an SVG wrapper, such as File:Pst-geo.svg
- I scanned the 1.2 million SVG January Commmons dump and found 2,457 SVGs with 3+ KB base64. — Dispenser 03:06, 25 April 2018 (UTC)
- Oppose. It is inappropriate to automatically label any file with an embedded stream as bad SVG. One application of SVG is to provide a bitmap image with editable text labels. See File:Moon names.svg, which is an image of the moon with text labels in both English and Ukrainian; there are also German, Bulgarian, Chinese, and Spanish versions. A bot could capture six reasonable images and inappropriately label them as bad. Imagine a picture of the thoracic cavity with text labels for lung, heart, and aorta. See File:Blausen 0458 Heart ThoracicCavity.png. Yes, it is a PNG, but there could be an SVG-labeled version. There's been a project to do that for many images. See the SVG text labels in c:File:Defecating into a pit (raster).svg. Admittedly, the pit image is simple enough that it should have been vectorized rather than kept as a bitmap, and the project has lost its way by spawning translated JPEGs rather than translated SVGs. Yes, there are inappropriate SVG files out there, but that does not mean all SVGs with raster data are bad. Glrx (talk) 22:44, 25 April 2018 (UTC)
- @Glrx: Maybe the template name is wrong? (not my template!) - Template:Bad SVG - only has the word "bad" in the title. Perhaps it should be more like "SVG with Raster". My view is that, if they were tagged then it would give a list for subsequent review. Ronhjones (Talk) 14:26, 27 April 2018 (UTC)
- @Ronhjones: The use of "bad" in the name is an intent to say that the SVG format has been misapplied. The text of the template ("This SVG image contains embedded raster graphics. Such images are liable to produce inferior results when scaled to different sizes.") does not explain the problem. Scaling of continuous tone images (typical photographs) is usually not a problem. Magnify the image enough and you will hit a resolution limit, but that is not a misapplication of a raster. That's why the Moon names raster is reasonable. If small, discrete tone, text characters (or curved shapes or non-Manhattan geometry shapes) are present in a raster image and then magnified, the anti-aliasing will blur the desired character, destroy the discrete tones, and fail to maintain / reconstruct the desired shape. There is nothing inherently wrong with inserting a raster image into an SVG file, so tagging an SVG file with an embedded raster seems like overkill. The problem is when the raster image contains drawn geometrical shapes. Sort of if the raster existed as a PNG, then somebody would come along and tag it with {{Convert to SVG}}. Even if somebody were to just stick such a PNG inside an SVG file, that would be a step in the right direction: maybe somebody will come along and replace the rasterized geometrical shapes with scalable vector shapes and remove the raster. There's not a compelling reason to delete such an SVG file; it might improve. On the other hand, an SVG that is just a continuous tone portrait of Winston Churchill probably has no business being an SVG file; JPEG would serve the purpose. None of these cases are simply detected with a string match. Tagging all of them for review does not seem to have a significant priority. So the SVG is bad/poor/misapplied. Why does it have to be examined/fixed/deleted right now? I blanche when I look at all the defecating-into-a-pit JPEGs. They are wrong in so many ways, but many of the African languages are not accessible, and the images don't need to be fixed today. Glrx (talk) 16:45, 27 April 2018 (UTC)
- @Glrx:Oh, OK. I started this thread as I discovered that there were a few (it was about a dozen in a random 400) non-free SVGs which were which were just a photograph (and a high res one at that) - they were all converted back to jpg and scaled to an appropriate non-free size. Looks like it needs more of a manual examination. Ronhjones (Talk) 16:58, 27 April 2018 (UTC)
- @Ronhjones: The use of "bad" in the name is an intent to say that the SVG format has been misapplied. The text of the template ("This SVG image contains embedded raster graphics. Such images are liable to produce inferior results when scaled to different sizes.") does not explain the problem. Scaling of continuous tone images (typical photographs) is usually not a problem. Magnify the image enough and you will hit a resolution limit, but that is not a misapplication of a raster. That's why the Moon names raster is reasonable. If small, discrete tone, text characters (or curved shapes or non-Manhattan geometry shapes) are present in a raster image and then magnified, the anti-aliasing will blur the desired character, destroy the discrete tones, and fail to maintain / reconstruct the desired shape. There is nothing inherently wrong with inserting a raster image into an SVG file, so tagging an SVG file with an embedded raster seems like overkill. The problem is when the raster image contains drawn geometrical shapes. Sort of if the raster existed as a PNG, then somebody would come along and tag it with {{Convert to SVG}}. Even if somebody were to just stick such a PNG inside an SVG file, that would be a step in the right direction: maybe somebody will come along and replace the rasterized geometrical shapes with scalable vector shapes and remove the raster. There's not a compelling reason to delete such an SVG file; it might improve. On the other hand, an SVG that is just a continuous tone portrait of Winston Churchill probably has no business being an SVG file; JPEG would serve the purpose. None of these cases are simply detected with a string match. Tagging all of them for review does not seem to have a significant priority. So the SVG is bad/poor/misapplied. Why does it have to be examined/fixed/deleted right now? I blanche when I look at all the defecating-into-a-pit JPEGs. They are wrong in so many ways, but many of the African languages are not accessible, and the images don't need to be fixed today. Glrx (talk) 16:45, 27 April 2018 (UTC)
- 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:
- 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)
- @Glrx: Maybe the template name is wrong? (not my template!) - Template:Bad SVG - only has the word "bad" in the title. Perhaps it should be more like "SVG with Raster". My view is that, if they were tagged then it would give a list for subsequent review. Ronhjones (Talk) 14:26, 27 April 2018 (UTC)
- 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)
- 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)
- 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 (
- 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)
Community de-adminship processes
Considering the community has the power to appoint admins, it is only fair that we have a procedure at hand to hold our admins accountable but every community de-adminship proposal has failed, some because the discussion is heavily derailed by a few editors, others due to no consensus. I simply think that this is a necessary process for the validation of WP:ADMINACCT. Sure ArbCom can, but that process takes months at end and sometimes doesn't even have an ideal outcome, they're not the community afterall. A lot of admins are concerned with the fact that they make enemies while their tenure here and that will severely skew the results in such a process, but then the reverse can be true as well, essentially making it a fallacious argument. I don't want such a process to lead the witch hunt against admins who might've made a few errors in judgement but a process to hold the ones accountable who have gamed the system in one or more ways and repetitively abused the trust of the community under the radar. Effectively, a process to be made without the ArbCom cogs to take forever. I'd like to hear more thoughts on this matter. --QEDK (後 ☕ 桜) 07:21, 15 April 2018 (UTC)
- The thread at ANI which required me to ask: link. This thread is to elicit new opinions on the matter just, and see if anything has changed from the status quo and if we have the cause to make a new proposal. --QEDK (後 ☕ 桜) 07:25, 15 April 2018 (UTC)
- Another navel-gazing discussion would not be helpful. It is obvious that admins who actively work to repel unhelpful editors get a lot of enemies, and such admins would get a lot of heat from socks whom we would have to pretend were good faith editors raising issues of concern. I would prefer that the admins spend their time repelling unhelpful editors rather than spend time arguing with their friends. No one has shown a discussion involving an admin which failed to get the correct outcome within a reasonable time. Arbcom would desysop an admin in under an hour if it were really necessary (they would discuss whether the emergency desysop was warranted). Johnuniq (talk) 07:43, 15 April 2018 (UTC)
- You seem to suggest a "deep state" network of socks would mysteriously arise and we will assume they are here in good-faith when simply they have no credibility for such. I'm sure the state of the community is not so dire and you're exaggerating. ArbCom doesn't make emergency desysops, it's still at the behest of stewards/office@WMF. ArbCom's functioning is the essential defining factor of a bureaucracy, no one's saying they can't do their job, but are they doing it well, not as much as we would want, such is the description of the job. --QEDK (後 ☕ 桜) 07:58, 15 April 2018 (UTC)
- That would be somewhat resolved by limiting desysop discussions to an WP:ECP-locked page (I'd say just autoconfirmed, that's really not a hurdle). IP editors and newer accounts could still make arguments and present evidence on the talk page, and if they have any pretense of validity then someone who can edit the ECP-locked page will carry them over. If the talk page gets flooded with "get rid of him!" spam, it could go into pending changes (with the understanding that any good-faith comment, no matter its position, should be approved). No comment one way or another on the original topic, just something that'd prevent pretty much any reasonable claims of sock influence without completely silencing grievances by newer or anonymous users. Ian.thomson (talk) 17:00, 15 April 2018 (UTC)
- [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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- I would support an amendment to policy where a thread can be opened at AN to request an involuntary RfA for current admins. If that thread is closed with a consensus for an RfA, then one is opened by a crat, without the accouterments of accepting the involuntary nomination. The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat. If the consensus is to oppose their adminship, then the bit will be removed by the closing crat. But opening one would require a consensus at AN, and an involuntary RfA for community confirmation cannot be opened by any one individual. GMGtalk 19:16, 15 April 2018 (UTC)
- I would grant broad leeway within crat discretion for the timing of the RfA, which could be reasonably delayed if needed to accommodate the asking and answering of community questions by the nominated admin, and require that the AN thread be closed by a crat, as the person who is charged with then opening the broader community discussion at RfA. GMGtalk 19:26, 15 April 2018 (UTC)
- For further clarification, I've been thinking a lot about this exact issue lately. There is a central problem that we have essentially a type of landed aristocracy or peerage, at some level disconnected from the functional pragmatic use of the level of user access. Many of these are seasoned admins who were elected early on, and who have grown to be among our most valued community leadership, but we also have some current admins who absolutely would not pass an RfA in 2018 or even be considered for nomination for one. We have others who conduct themselves occasionally with general disregard for community norms, because the standard is whether you have passed an RfA ever, and not whether you can pass an RfA now.
- The standard for desysop at ArbCom is spectacular disaster, and not consistent faithful use of the tools in accordance with community norms. So we reinforce a notion that so long as any admin who happens to be a disaster, can maintain the tools so long as that disaster does not become spectacular. That's a problem and it's one that fundamentally erodes trust in the corps and faith in the community. This would be an overall high bar for a re-RfA, where most comers would be turned away at AN, and most who proceed to a re-RfA would likely have already risen to the level of losing community trust, and would have their access removed. It answers the issue of individual grudges by requiring consensus for a discussion to even happen and at the same time, if that discussion does happen, it holds current admins to exactly the same expectations for conduct and competency as we do new admin candidates. GMGtalk 19:50, 15 April 2018 (UTC)
- I like it, with the exception of the the role you give 'crats in starting the confirmation RFA. I think that the confirmation RFA should be started by someone who wants the admin in question to be desysopped, so they can present their reasons, rather than a bureaucrat creating the request as a procedural action. Plus, that also gives people some time to reflect after the AN thread is closed on whether a desysop discussion is really necessary. Of course, I would prefer this to the status quo. -- Ajraddatz (talk) 21:08, 15 April 2018 (UTC)
- For additional context, you may wish to review Wikipedia:Administrators/RfC for binding administrator recall, the last broadly-held RfC on this topic. Its proposal is similar to yours. (Wikipedia:Requests for de-adminship has a whole slew of other proposals.) isaacl (talk) 21:25, 15 April 2018 (UTC)
- There are some key differences - namely that the proposed dewiki model has an ongoing quorum requirement, whereas this model would move forward from existing community practices (review of actions at AN/ANI). They also require a new RFA with the same passing standard, which is different from this. -- Ajraddatz (talk) 21:46, 15 April 2018 (UTC)
- Sure, that's why I said similar... Like I said, the idea was to see what has been done before and thus learn from it (you can see from the objections that safeguards like a quorum is a concern). (Regarding RfA passing standard, this proposal says "The format and duration of the RfA proceeds (including watchlist notifications) as a normal RfA and is closed as normal by a crat, including the discretionary zone and possible crat chat.") isaacl (talk) 22:20, 15 April 2018 (UTC)
- 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)
- The current process works fine and also has the advantage that the actions of all parties are examined: this has been cited by one person in the past as a reason why they are hesitant to file a desysop case request because they were afraid their actions would be examined. That means it is doing its job: preventing frivolous requests that can be resolved short of a desysop by making people assess how they have behaved in the situation, and possibly getting people to just calm down, which is usually the ideal.I’d also like to point out that while it is popular to complain about not having a desysop process short of ArbCom, a large part of the reason we don’t have one is that no one has proposed one that is actually better. That speaks volumes, IMO. This is a grass is always greener issue, and I say this as one of the limited number of people who has brought a successful desysop case before the committee as a filing party. Yes, the case request process sucks, but I’d much rather have it and know that the admin under discussion is getting full hearing than have an AN/ANI mini-trial or RFCU. There is also the factor that some of these cases, such as the MisterWiki case and some other recent admin issues, do involve private information, which the community is not equipped to deal with. The arbitration process is slow and takes a lot of effort, but it works. There is no need to replace something that works, especially when every alternative that has been proposed brings with it other issues. TonyBallioni (talk) 21:50, 15 April 2018 (UTC)
- Sorry Tony, I consider you a friend, as much as people who've never met can be. But the current system is not working. You and I were chatting on IRC at the time, and you only beat me to that ArbCom case because I was actively drafting the request in my sandbox at the time and you beat me to it. Spectacular disaster should not be the standard. The community should be the standard. We're not a country where people live with the choices of their government. We're volunteers, who simply leave when the administration isn't accountable to that community in a meaningful way. If the community is the ultimate authority for making our administration, then the community should be the ultimate authority for breaking it when appropriate. I don't want to end the world; but I would very much like to see the standard for desysop moved from spectacular disaster to simply disaster. My concern is not spectacular disasters that ArbCom doesn't act on; my concern is that admins who realize they can operate at the level of simply disaster with no oversight, are free to do so. GMGtalk 00:28, 16 April 2018 (UTC)
- Sure, but I'm not convinced that there is a better method out there, or at least not one that wouldn't be equally as flawed. My standard for any reform proposal of anything is that it should be an improvement, not just a lateral move that solves some issues while creating others that have the same level of severity. Using the statistics from de.wiki the last time this was formally discussed on en.wiki, ~42% of admins subject to their procedure basically said screw it, and resigned or didn't respond at all. Now, I am of the belief that all admins who have lost the trust of the community should resign, and that when they don't, ArbCom should make that choice for them (that was my basic argument in the MisterWiki case.)At the same time, given that their actual removal rate by vote was only 13% and their retention rate as a whole was 44%, I suspect that many of those who chose to forgo the process on de.wiki would likely have been retained, but they just decided it wasn't worth it. That has the potential to have a real impact on the number of active sysops simply quitting, which I think we also need to take into account when looking at this. What some people also forget is that admins are also volunteers too, and while we have obligations to the community, if given the choice between their bit and an ANI-meets-RfA style sysop review process, there will be a lot of volunteers who decide it just isn't worth it, even if they shouldn't have anything to worry about. TonyBallioni (talk) 00:46, 16 April 2018 (UTC)
- At the same time, we fret about inactive NPP reviewers skewing our numbers, when if dewiki is anything like enwiki, half of our admin corps is barely active anyway, and half of those are practically mummified, and so of course they wont stand for a confirmation, because the user right is a dusty artifact. Losing an inactive admin isn't an actual loss; it's the status quo with one less user right involved. Any active admin in good standing should pass with flying colors. That many don't would be a feature, and not a bug. GMGtalk 01:29, 16 April 2018 (UTC)
- 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)
- Sorry Tony, I consider you a friend, as much as people who've never met can be. But the current system is not working. You and I were chatting on IRC at the time, and you only beat me to that ArbCom case because I was actively drafting the request in my sandbox at the time and you beat me to it. Spectacular disaster should not be the standard. The community should be the standard. We're not a country where people live with the choices of their government. We're volunteers, who simply leave when the administration isn't accountable to that community in a meaningful way. If the community is the ultimate authority for making our administration, then the community should be the ultimate authority for breaking it when appropriate. I don't want to end the world; but I would very much like to see the standard for desysop moved from spectacular disaster to simply disaster. My concern is not spectacular disasters that ArbCom doesn't act on; my concern is that admins who realize they can operate at the level of simply disaster with no oversight, are free to do so. GMGtalk 00:28, 16 April 2018 (UTC)
- 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)
- 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)
- 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)
- 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:
- 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.
- If the consensus is in support of a reconfirmation RfA, it is followed by regular procedures of a RfA (watchlist, time frame, etc.), though forced, where the votes are counted. As stated above, people who hold grudges can't sink a majority-vote-based RfA.
- However, this raises a few more questions:
- What is the formality of such an AN/ANI thread? Say, an editor finds three page deletions of an admin problematic and asks for review from other users. That is, the thread is about the deletions and not whether the person's adminship needs reconsidering. If the page deletion is identified as a long term issue, would a comment like "we should really look into the ability of this admin to handle his tools" be considered the "start" of step 1? Or should someone start a new thread (or a sub-section) with a specific title to document the entire consensus building formally so that comments stay on topic? The reason I say this is because a thread that talks about three page deletions would gain much less traction and a few editors might agree with the green highlighted comment I just stated above. Would that mean there is truly a consensus to conduct the reconfirmation RfA? In comparison, a thread titled "Considering reconfirmation RfA for XYZ" would probably catch more eyes. (That is just how I feel; that may not be true with how things work at AN/ANI since I don't frequent there enough).
- Can any editor start such a thread? Even one quick to call 'Admin abuse!'? Or should there be a proper "case" before step 1 can be started (I've discussed this more in the next point). Keeping with the example I gave, if the 'long term issue' is falsely identified by the editor starting the new thread, people would start commenting that thread was spuriously created and that it's a time sink. Which leads me to next point...
- How long should the thread last? Can it be snow-closed by a 'crat as a "time sink"? Or should there be a time-frame so that consensus building is given a fair shot?
- If snow-closes are allowed - the process would be fairly informal providing greater leeway to the closing 'crat and could lead to limited participation. There won't be a lack of participation at the RfA, but there might be at the AN/ANI which is the first step. Since RfA has raised its standard over the years, it would be unfair for admins to be put in the spot so easily and questioned in a re-RfA after an informal-process-led AN/ANI. It could also potentially promote people to start spurious threads, knowing that they can be snow-closed (although, hopefully, a boomerang would follow in such cases).
- If a time-frame is kept - a barrier would have to be created to ensure there is a proper "case" so that it is not truly a time sink. That would add a third step of assessment of the "case" and complicate things. But, the entire process would be fair. There would be enough time to view the actions of the thread initiator as well as hear the voices of the community. At the same time, there would also need to be a "gap" introduced between reports for a particular admin so they don't get targeted.
- This is not like an AfD where both time-frame and snow-closes can be allowed freely since most snow-closes are strongly policy based. Admin conduct is largely subjective since we're assessing the actions of a person. If snow-closes are allowed, they would need to be for particular cases. Say, the idea is implemented with a time frame and someone starts another thread just a few days after the previous closes for an admin. It can then be reasoned that consensus wouldn't have changed (unless the admin royally messes up in those few days) and snow-close the thread. That would be the "gap" I was talking about earlier.
- With all this formality, time-frame and "case" stuff, it seems to be getting closer and closer to how ArbCom works. I truly believe that the ins and outs of the process have to be worked out first. Just my views though, I'd love to hear what others have to say! Jiten talk contribs 09:24, 16 April 2018 (UTC)
- The AN thread acts as the "stop-gap" for futile requests. That's not the idea but something we can probably think about, is all. When you have crats closing it, it has to be a responsible close and I doubt there's the leeway you talk of. Set up a minimum time-frame for reach and maximum time-frame for consensus and I'm sure crats can effectively deduce consensus. --QEDK (後 ☕ 桜) 10:55, 16 April 2018 (UTC)
- (edit conflict) Hmm...My general feeling is that any editor should be able to open such a thread, yes. This is no different than any other behavioral dispute that arises at AN or ANI where things might spiral out of control for a little while in a general purpose thread, and we end up with someone who's been following developments who decides they think they have a solution by proposing a block or a ban. I don't think you really need to set additional limits on the normal consensus building process. Some discussions will probably be a clear cut consensus one way or the other, and can be easily closed, even by a non-admin (I'm sympathetic to dropping the bit about crat closes). Others may be highly contentious and need a team of experienced admins to close. This is again perfectly in line with our normal consensus building process governed mostly by common sense. The discussion would be closed in accordance with normal procedure, summarizing the consensus and the concerns of the community, and that close would be the rationale for the re-RfA, in place of nominations and the three standard questions.
- I think it's also important to point out that this is actually more lenient than what is possible under current policy, since it's simply a consensus for whether a re-RfA should happen, and not deciding to directly take away the mop. It may be perfectly reasonable for someone who thinks a user should retain the mop, to still support a re-RfA in order to solidify the conesnsus for retention, and put down unwarranted pitchforks.
- The alternative under current policy and what I fully intend to start proposing at places like AN and ANI given the opportunity if something else doesn't come of this discussion, is to start TBANNING admins from taking any administrative action whatsoever until they appeal to the community to lift the TBAN. This type of administrator probation is as far as I can tell, and I've looked pretty hard, perfectly allowed under current policy. But that type of action is actually less accountable to the broader community, and more likely to be beholden to the types of people who frequent AN and ANI, in disregard for those who don't. GMGtalk 11:04, 16 April 2018 (UTC)
- And before someone calls this a solution in search of a problem, remember that at this moment ArbCom can barely agree whether to even issue a warning to an admin for edit warring, when, if you count page protection as an edit, they were already at 4RR, and would have been blocked were they a regular editor. Besides that, I'll bet someone like...oh...WBoG can probably think off the top of their head of at least one example where a current admin has mostly not yet been dragged to ArbCom because of the onerous bureaucracy, even though a case request is almost certain to be successful. GMGtalk 11:39, 16 April 2018 (UTC)
- As I recall, a community-imposed ban on performing administrative actions has been discussed and recognized as an effective removal of administrative privileges, and thus only within the scope of the Arbitration Committee to put in place. I'm not certain, but I think bans on specific categories of administrative actions have been passed, though it is rare. Usually people feel
administratorsan editor should either be trusted with the entire range of administrative tools, or none of them. isaacl (talk) 13:45, 16 April 2018 (UTC) - TBANs on use of specific tools are allowed, yes. There is also the Arthur Rubin example where the community passed a community ban against him pending the ArbCom case and then removed it when he returned. TonyBallioni (talk) 13:52, 16 April 2018 (UTC)
- Yes, that was brought up at my talk page a little while ago. If the community can CBAN someone, then I don't see any reason why they can't enact a TBAN which is in every way a less extreme sanction. It wouldn't be removal of the bit, it would be suspension of the bit, pending a consensus that they have regained community trust. Honestly, I'd welcome ArbCom to try to unilaterally overturn such a TBAN, because there would be no clearer demonstration that they cannot in this one area fulfill their duties as a body to the satisfaction of the community, and we need to formulate another option.
- To my mind, a re-RfA, with all the accouterments of a set time table, wider audience, and opportunity for Q&A is the closest thing out there to a compromise between a bureaucratic nightmare on one hand, and outright mob rule at AN or ANI on the other. GMGtalk 14:04, 16 April 2018 (UTC)
- I would support forcing resignation before a reRfA, which would solve the issue people have of them being easy to game. I argued this in either January or December (whenever the last one was). That was shot down as not being something worth writing down. My preferred system here is that admins who have lost community trust, or where that trust has been called into question, resign without the need for a case and if they still want the tools run again. If they refuse to do that, then ArbCom steps in. I think that's where we are in most cases right now. I am disappointed in some of the Arbs over the current motion, but it seems likely to pass and regardless of my views of re: involved full protection, I doubt a community desysop process would have achieved much different. TonyBallioni (talk) 14:44, 16 April 2018 (UTC)
- So in essence, something like what GMG and Ajr suggested but without step 2 (ie, the reRfA)? If I understand correctly, you mean: as soon as there is consensus in an AN/ANI thread that an admin has lost the trust of the community, they must resign. If not, the case would be taken to ArbCom. If they want to bit back after the resignation/forced resignation, they must run a regular RfA just like other editors. Is that correct? I think the main concern here is still that community's say should be final. If an admin loses our trust, they clearly don't deserve the admin tools and ArbCom shouldn't be able to say otherwise. Even if ArbCom is very much in line with community's thoughts, the whole procedure takes time and effort. A forced re-RfA on the other hand, as GMG suggested, is quicker and more accessible to the community. Just from personal feelings and the very little time I've spent reading ArbCom cases, there's more participation at an RfA than a case and the final ruling is determined by the community (which, imo, seems philosophically correct as the community is the one that voted for the admin). I didn't understand the "game" part though. My initial comment only addressed the AN/ANI thread; I hadn't even though about the actual re-RfA! Jiten talk contribs 15:11, 16 April 2018 (UTC)
- Well, my main concern is that 1) a direct desysop has already been rejected more times than anyone remembers, and functionally 2) AN and ANI have a tendency to be volatile and vitriolic, with people rushing to sanctions because they lack the creativity or time to find any other solution (exactly why we just passed a 24 hour minimum to CBAN discussions). So you take away the sanction as an option really and instead make them !vote on whether we have a discussion. Also in comparison, RfAs tend to be more well thought out, and bring out a much wider audience including a lot of our quiet content creators and gnomes who'd rather have a root canal than watchlist a noticeboard. GMGtalk 15:23, 16 April 2018 (UTC)
- Jiten D: Yes, that is roughly my position. I think that once it is clear an admin has lost the trust of the community, or at the very least there is a valid question of community support because of a major breach of trust, they should either resign or ArbCom should desysop. This is the process that we just saw work here and that also worked at Wikipedia:Arbitration/Requests/Case/Conduct of Mister Wiki editors. It works and no one has suggested a process that would work any better given the political realities of en.wiki (again, see the de.wiki numbers. I highly suspect that if a Commons/Wikidata like process were to be followed here, we would see similar attrition, which is not a good thing.) Its also important to note that all ArbCom does in terms of desysop is remove and mandate a reRfA if someone wants the tools again (assuming no other sanctions.) We don't have a perma-RfA-running-ban short of a full site ban.I also dispute the idea that the ArbCom based desysop process is not a community-based desysop process: they are elected by the community, they take case requests when it is raised by the community, every step of the arbitration process has ample opportunity for community comment. All of the previous desysop reform attempts can fall into two camps: direct desysoping by the community (which I would call forced reRfA an example of). This is rejected because we want protections for admins who make tough calls, and the confidence in ANI at resolving disputes is slightly lower than the popularity of Congress and ArbCom. (See Wikipedia:Administrators/RfC for binding administrator recall. Any version of reRfA or direct desysop will face similar objections, and would likely fail.) The other proposal is to designate a group of trusted editors from the community to review requests for desysop when it is clear that there is community demand for it, so that the community can remove adminship when it feels that an admin no longer has its trust, this is the idea behind proposals such as WP:BARC. The issue there is that ArbCom is already that body: it is elected by the community every year to handle, among other things, desysop requests at the request of the community and with community comment. TonyBallioni (talk) 15:49, 16 April 2018 (UTC)
- Tony, the attrition isn't related at all whether we have a community-desysop process or not, but simply because our RfA standards have increased year-on-year. The solution isn't to make barrier to exit harder but the barrier to entry easier - you're going very roundabout with your argument. There is no consistent evidence across community desysop processes to suggest that it's been the triggering factor in attrition. You keep saying that ArbCom is elected by the community for the purposes of desysoping, but that's not only it, if you've read GMG's comment, the ArbCom's stance on desysop's way too soft, stuff that one crat would probably do if we had the policy to allow that. Instead, we wove in the right with the most complex and busy legal court in all of Wikipedia. You dispute the point, fair, but your point is essentially, "No, this is okay" after citing an example where the admin resigned. Gryffindor would resign under the threat of any such process as well, you just need the mindset to resign. And for the last time, ArbCom is not the community, they're people appointed by us, entrusted with the right to deal with issues in a fair and unbiased manner, while they are certainly good at deliberating, I disagree that admins appointed by the community should be left to desysop at the behest of a group of people who are certainly not the community. --QEDK (後 ☕ 桜) 16:16, 16 April 2018 (UTC)
- Tony you can't accept the limitations of the dewiki process and ignore the success of the other community review procedures. Look for yourself at Commons (successful and unsuccessful) to see the lack of frivolous requests. And you're also wrong about the steward confirmations - most of steward work is taking global actions, not acting as a local admin on a project without them. Stewards can thus get grudge users from both homewiki activities (seen this year on ptwiki stewards' confirmations) and for controversial actions they've taken (I once took issue with someone editing my comment on Meta and they came back to oppose my confirmation the next year). The simple fact is a) this doesn't discourage stewards from staying on unless they've really messed up and b) safeguards prevent those grudge users from derailing the process. I also disagree that arbcom desysop is community desysop - arbcom doesn't appoint admins in the first place, the community does through RfA. And a general point regarding the AN/ANI thread requirement - there should be no fixed bureaucratic rule for this, because the intent is to use existing procedures. Admins can already be taken to AN/ANI over bad actions. My proposed system would just allow for a substantive follow up to those discussions. -- Ajraddatz (talk) 16:32, 16 April 2018 (UTC)
- Just as a general comment, I am reminded of a recent RfA on Commons, where the rationale was essentially
I want to do this particular cleanup task and when I'm done I'll give the mop back.
It ended up getting derailed for reasons other than the rationale, but I have to say it was refreshing to have a rationale that was so pragmatic and 100%I want to do this task
with 0%I want to be a community leader of sorts
. I wish we could move more toward that on enwiki, and the only way I see for doing it is reforming the back end, because that's what people are thinking about when they cast a !vote at RfA. The barrier to exit is what sets the standard of how bad a mistake at RfA is going to be if one is made. GMGtalk 16:46, 16 April 2018 (UTC)
- Just as a general comment, I am reminded of a recent RfA on Commons, where the rationale was essentially
- 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)
- 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)
Ajr: While I respect the work that stewards do, and think I have pretty good relationships with a good number of you, I disagree with you that there is any equivalency to steward confirmations in this discussion: steward actions are by the very nature of the role supposed to be uncontroversial. A steward who is behaving controversially *should* be removed, which is why the process there works well. Re: Commons, it has a very different culture from en.wiki, and I don't think it would work as well here.
QEDK: I was providing recent examples of the current process working. Thus far, in any of the desysop reform discussions that have taken place over the years, no one has actually demonstrated that the process doesn't work or that there are a huge amount of actually filed case requests where the community would have desysoped but ArbCom didn't (or even one). It does. My basic argument is that while the current process has flaws (i.e. it is slow, which is the only one that has ever had consensus) all of the other possibilities that have been discussed also have flaws that are as bad or worse (I think it would increase attrition and also decrease recruitment, among other things). I'm a pragmatist who doesn't believe in changing something that works for something else that may or may not work and would likely be just as flawed. I also disagree with GMG that lowering the barrier to exit will lower the barrier to entry: the barrier will remain just as high and we will lose plenty of good user who simply don't want to go through public humiliation because of a grudge. TonyBallioni (talk) 16:56, 16 April 2018 (UTC)
- I've been a local admin in a variety of places on Wikimedia and Wikia since 2009. Some of the most controversial actions I've taken are as a steward, because outside of permissions management, we deal with a large number of controversial issues that can draw attention. And I've also found that, regardless of the project, the culture and general function of a wiki are pretty well the same no matter where you go. That is just my experience though, and I can't measure it in any objective way. All of this said, I do understand your core argument that the arbcom process works and ensures that admins are empowered to take controversial actions. -- Ajraddatz (talk) 17:18, 16 April 2018 (UTC)
- I'm unclear why requiring a re-confirmation RfA after a consensus would cause English Wikipedia to "lose plenty of good user who simply don't want to go through public humiliation because of a grudge", but having the same consensus trigger a resignation or an arbitration case wouldn't. I suspect going through an arbitration case would be just as likely to result in someone leaving. isaacl (talk) 17:53, 16 April 2018 (UTC)
@GreenMeansGo:, regarding why the community doesn't have the ability to remove administrative privileges: as I understand it, originally Jimmy Wales appointed and removed administrators. He then shifted the responsibility for appointing administrators to the bureaucrats as part of the request for administrative privileges process, and the responsibility for removing administrative privileges to the arbitration committee. To change this would require a change to the Administrators policy. There is no effective difference between removing administrative privileges or dictating that an editor cannot use them.
In the end, the basic problems are that consensus doesn't scale up as a community increases in number, there are structural problems with online decision-making (including the limited, self-selected sampling of voices heard), and English Wikipedia's decision-making tradition isn't conducive to determine real consensus. As a result, any attempt to make major decisions by a large community discussion generally gets deadlocked. isaacl (talk) 17:53, 16 April 2018 (UTC)
- Well, regarding TBANS there is a difference between removing access and suspending the use of it. Namely, it takes crats and ArbCom initially out of the loop all together. If an admin on probation decided to flout the TBAN, any passing admin can basically unilaterally hand out a block, and then take them to ArbCom if they unblock themselves (the lenient route). Or we take them directly to ArbCom, because we've created a situation where use of the tools at all is by definition abuse and directly contravening community consensus. Then if ArbCom decides to override consensus...I dunno...I guess we'd just have a wiki-constitutional-crises. Normally a TBANNED administrator (as in, TBANNED from US Politics or something) would be nearly up for the chopping block just by virtue of needing to be TBANNED in the first place.
- In a nutshell, it's attempting to set up ArbCom to be in a situation where either their hand is forced, or alternatively they do something totally bonkers and everyone flips their lid, in the hopes that they'll prefer having their hand forced to gratuitous lid flipping. GMGtalk 18:14, 16 April 2018 (UTC)
- To clarify, there is no effective theoretical difference in the community saying administrative privileges shall be removed and an editor shall not use administrative privileges. Accordingly, by policy, the community does not have the scope to enact these restrictions, and the administrator in question would not feel bound by them. There is of course a practical difference today between the community making either of these statements and the Arbitration Committee ruling that administrative privileges shall be removed: the bureaucrats will only act on a statement from the Arbitration Committee. isaacl (talk) 18:22, 16 April 2018 (UTC)
- I doubt that, if such a discussion were to be held in a proper manner, even though the policy doesn't exist, consensus can be reached. Nothing is stopping anyone from reporting the discussion to the stewards directly, and considering that local policy doesn't bind them, they can exercise their right to desysop considering the admin has effectively lost the confidence of community. The community has full scope in every scenario. --QEDK (後 ☕ 桜) 18:50, 16 April 2018 (UTC)
- Sorry, I'm not sure if you're responding to me? If so, are you saying that you doubt that consensus can be reached? And then are you subsequently saying that if consensus were reached, the community could appeal to the stewards? isaacl (talk) 18:56, 16 April 2018 (UTC)
- There may not be a practical difference but there is a policy difference, and there is nothing in policy that forbids it. It's already been shown that a current admin can be CBANNED while still retaining the rights, and it's already been shown that the community can restrict the use of the tools using a TBAN (see here). The difference is only one of scope, and possible gratuitous lid flipping by having ArbCom directly override community consensus.
- But no, the community doesn't decide everything. There are some things that are decided by the WMF. We cannot, for example, eliminate ArbCom all together. Their existence is mandated by the foundation. We cannot reach a consensus to disregard WP:COPYVIO. We cannot override office actions. And if a steward ever showed up on enwiki and unilaterally removed the admin rights under those circumstances, lids would be violently flipped in every direction. GMGtalk 18:58, 16 April 2018 (UTC)
- Ofc not, I simply meant to say, if the community needs to take action, it will. Unilaterally using rights isn't a question or an idea. @isaacl, I was responding to you, yes. If consensus is reached for the removal of rights, the Stewards are bound to take action even though the local policy is something else, their task is to execute community consensus. I do not mean appealing to the stewards, but requesting for the implementation. --QEDK (後 ☕ 桜) 19:05, 16 April 2018 (UTC)
- Note that stewards will not take actions that could be performed by local bureaucrats except in emergency, and loss-of-confidence isn't an emergency situation by itself. See m:Stewards policy#Don't promote users on projects with existing bureaucrats. -- Ajraddatz (talk) 19:08, 16 April 2018 (UTC)
- I would guess that loss-of-confidence is immediately an emergency situation. I know you're the steward ofc, but if we're getting technical, it says promote and allows you to exercise disretion elsewhere and furthermore, the primary "...task is to implement valid community consensus within the bounds of the Foundation's goals", and not implementing such a consensus would be directly against the reason why you were elected. But that's just what I think. I'd say you need to be in such a situation first to evaluate an outcome so speculating possibilities isn't exactly it. --QEDK (後 ☕ 桜) 06:59, 17 April 2018 (UTC)
- Sorry, poor choice of words: I did not mean "appeal" in the legal sense, but simply "request". I still don't understand your first sentence, but I understand your line of argument regarding the stewards; thanks for the clarification. isaacl (talk) 19:33, 16 April 2018 (UTC)
- 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)
- 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)
- 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)
- 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)
- 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)
There is a problem with mis-actions by admins, and lack of accountability of admins. But putting putting the death penalty of desyopping under the random clan & mob mentality that pervades other areas of Wikipedia is not the answer. One component of a fix would be to get rid of the ridiculous system where anybody with the tool belt is considered qualified to act as judge, jury and executioner on behavioral questions on established editors, and or deciding/closing even the most complex and contentious situations. This needs needs to be a second tier above admin; people who are proven to also be wise, careful, thorough, impartial, never hot-headed, with good judgement, analysis and decision-making process capabilities.....the "Yoda" level. And, just like the fix for the broken RFA process, discussions to award this need to be findings on an established framework of the qualities required, not the current random stuff that we have at RFA. Second, there needs to be a process to sanction mis-behaving admins with lighter penalties than desysopping that doesn't require the giant artillery of an arbcom case. Maybe a panel of 3 "Yodas" who could dish out findings on admin behavior and admonishments. And until we have Yodas, a community based process for findings and admonishments but not desysopping. North8000 (talk) 18:26, 16 April 2018 (UTC)
- Binding arbitration on content disputes has been suggested by others and me as a way to give final rulings on content disagreements. Today there's no final stop in the process; people can periodically bring up issues (hoping consensus has changed), and whoever lasts the longest may well succeed, so editors have incentive to be contentious. I appreciate there are pitfalls with binding arbitration to be wary of (for instance, consensus actually can change, and sometimes there are cliques that need to be counteracted). The largest barrier, though, is that people would have to give up their veto right to block changes (one person alone can hold up a change for an astonishingly long time; a few people can do so indefinitely). Until something more drastic happens to Wikipedia's editing environment, I don't foresee binding arbitration being introduced. isaacl (talk) 18:39, 16 April 2018 (UTC)
- I really don't think the answer to fixing a bureaucracy is more bureaucracy. The 3 Yodas will never ideally represent the view of the community and there's nothing to say they can remain completely unbiased. The key to removing bias from a system is to have multitude of opinions, as eventually, bias cannot skew the opinions to one side or the other. Your argument, along with Tony's, is based on the key principle of the community not being able to take care of our decisions, like there's a huge mismanagement that occurs anytime it's upon the community to decide, but that has never been the case. If anything we need to involve the community as a whole more, not less. --QEDK (後 ☕ 桜) 18:46, 16 April 2018 (UTC)
- Agreed 100% with QEDK. If the community can be trusted with making admins they can be trusted with removing them. And the three Yodas model falls to the same reason why BARC was rejected - it's just another ARBCOM-like process. As an aside, I don't think that the community does an excellent job of making new admins. But they certainly wouldn't do a worse job of removing them. -- Ajraddatz (talk) 18:52, 16 April 2018 (UTC)
- I didn't say anything about 3 Yodas and I'm not sure if I favour that specific proposal, but in general: consensus doesn't scale up. All of our experience with communities in the real world demonstrates that managing interpersonal interactions requires some form of hierarchy. We can do our best to keep it as grounded as possible with the community at large, but it's just not possible to hold an effective conversation with hundreds of people: it demands too much time and attention. isaacl (talk) 19:27, 16 April 2018 (UTC)
- I mean we do a half decent job of it half the time. There's currently a discussion ongoing at WP:ACREQ where more than 200 people have weighted in so far. GMGtalk 19:48, 16 April 2018 (UTC)
- That conversation is pretty civil, which is good, but it has a lot of redundancy, with people repeating points, because almost no one is going to read over 200 statements (I read many of the opposes and some of the supports at the start of the RfC, but haven't kept up). Due to the traditional structure of discussions on English Wikipedia, people spend a lot of time arguing with individuals over their viewpoints, instead of consolidating discussion around each argument for and against. (I've written about these issues before.) And that discussion isn't related to behavioural issues, or even a content dispute. It's also isn't that evenly split, so it's more a lot of people agreeing with each other, rather than a conversation. That being said, there are a lot of conversations that can (and often do) proceed smoothly. But the contentious ones are hard to resolve without some kind of structure to manage them and provide incentive for collaborative behaviour. isaacl (talk) 20:06, 16 April 2018 (UTC)
- I mean we do a half decent job of it half the time. There's currently a discussion ongoing at WP:ACREQ where more than 200 people have weighted in so far. GMGtalk 19:48, 16 April 2018 (UTC)
- 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)
- WP:BARC was an idea of mine for a new policy that failed to gain traction. Lauched together with Worm That Turned during a period when community desysoping was once again a current topic, it was an experiment in community opinion more than anything else. On the lines of, 'let's try something and see what they say', it's nevertheless interesting reading and IMO is still a fundamental basis for new ideas. 100+ supports was not an insignificant turnout by today's RfC standards and was in fact numerically (115/75) the majority. Mdann52's closure made a very fair assessment that on the strength of the arguments there was no consensus. My main concerns at the time were to find a system that would protect any community desysoping process from an overspill of votes from aggrieved users who fail to understand that some admins do make tough calls - there is clearly a lot of schadenfreude in such participartion. Serious cases of privilege misuse (or serial poor judgement ) are in fact quite rare considering the number of admin actions that are carried out, and the (low) number of truly active admins who do the brunt of the work.
- BARC was nearly 3 years ago. With the apparent reduced workload on ArbCom, and a marked drop in coordinated attacks on adminship in general, I question whether today a 'community' desysop system is required - TonyBallioni makes a salient point in clarifying that as elected officials, the Committee mebers are nevertheless members of the community. Whether we are happy or not with the work of each individual who occupies one of those those seats (some do occasionally vote at odds with the other members), at this moment in time I am personally satisfied that the work they do in this area reaches the right conclusions. It's the structure of the ArbCom system that needs streamlining, IMO its own mess of bureucacy is what makes it so slow and ungainly.
- Nowadays, although it still suffers from the ocasional disingenous opose votes and what are probaly a lot of drive-by supports, even if it's still not attracting a plethora of contenders, RfA does what it says on the can - most of serious candidacies pass and there is a significant reduction in failed bids for the bit. Like community desysoping however, no one has ever come up with new a idea for it that pleases everyone. Kudpung กุดผึ้ง (talk) 01:09, 17 April 2018 (UTC)
- If the community can grant adminship, the community should be allowed to take it away. RfA activity remains extremely low, in part because adminship really has become a big deal. I am fairly certain that the community will not take any major steps until the number of admins drops so much that a crisis is created, and by that time it will probably be too late. Lepricavark (talk) 15:04, 17 April 2018 (UTC)
- I can think of two practical ways to create a functioning de-sysop procedure which bypasses Arbcom, protects admins from frivolous complaints and does not add another layer of bureaucracy.
- 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.
- Simply use an AN/ANI thread which meets three conditions 1) It is opened or has a sub-thread which is expressly for the purpose of recall. 2) The thread runs for some minimum time, say 3-5 days. 3) The thread is closed by three experienced editors: An administrator; A non-admin editor who has experience closing contentions threads; An editor or administrator selected by the admin whose community confidence is being questioned. The close is a simple Sustained/No-confidence. • This could also be implemented in combination with #1 as a universally agreed recall condition. A No-confidence could be implemented either through voluntary resignation 'under-a-cloud' or using the TBAN idea GreenMeansGo has suggested previously. (I also think that the extra care of the three conditions would give weight to a TBAN decision if even if the process had not been agreed upon via prior discussion or could act a a method of 'creating policy through practice',)
- These options use the tools we have and #1, in my opinion, has the added benefit of the admin corps, by voluntarily recognizing the concerns of a significant population of editors and being responsive to those concerns, collectively showing ongoing faith and trust in the community. Just as the community shows faith and trust in them. Jbh Talk 01:21, 18 April 2018 (UTC) Last edited: 01:31, 18 April 2018 (UTC)
The grudges
The main counter-argument for a community-initiated desysop process seems to be the "grudges" - users who have been blocked/warned/offended by an admin at some point, who show up at the desysop proceedings to oppose the admin under review without seriously considering the situation and pattern of overall behaviour displayed by the admin. I've been arguing throughout this thread that this is nothing more than a myth that would not actually derail a community desysop process - let's look at this in more detail.
- Starting with cross-jurisdictional comparisons: do grudge users control the community-initiated desysop processes on other wikis? No, though some (like the dewiki model) can potentially drive off admins who don't want to go through the process. More on this below. But if you look through the archives at Meta, Commons (successful and unsuccessful), steward confirmations and Wikidata you will see a distinct lack of frivilous requests or requests being derailed by "enemies" of the admin under review. This isn't to say that it doesn't happen - but it doesn't happen in large enough numbers to derail the process. I picked those processes because I am the most familiar with them - if anyone else wants to add some analysis of others please do so.
- Now let's look at enwiki, because I know everyone is going to have "those projects aren't enwiki, enwiki is different and special" on repeat in their brains while reading the above point. Enwiki doesn't have a community-initiated desysop process, but it does have AN/ANI and ArbCom where the community can complain about sysop actions. Some AN/ANI threads can even lead to ArbCom cases for desysopping, so it's a surprisingly similar system to those proposed above, just without any decision-making power for the community. So let's look at how these "grudge" users derail the existing processes. There is a current case request before ArbCom right now about desysopping (found here), without any evidence that the "grudge" users are dominating the discussion. I see maybe one or two comments of questionable value, with most comments being appropriate reflections on the conduct of the user in question. Looking to the ANI thread on the same topic (here), again, I'm not seeing much in terms of users with grudges showing up to derail the process. Does anyone have any actual examples of an AN/ANI thread being filled up with users with grudges trying to get back at a specific admin? And again, I don't mean one or two - one or two people with grudges will show up anywhere, be it RfA or a request for desysopping. I mean enough users to derail the process or to wrongfully desysop an admin who was just taking a necessary but controversial action, or enough to form a consensus that a de-RfA should be initiated.
There's another argument here that deserves some attention. Tony expresses it above, saying that a community-initiated process will cause admins to just quit rather than go through a confirmation RfA. That's a very good point to make when looking at the dewiki system, but it doesn't apply to Meta/Commons/Wikidata/steward confirmations and I doubt it would here. Admins can already be dragged to AN/ANI or ArbCom for their conduct here, and ArbCom proceedings are possibly more stressful than a re-RfA given the timeframe and private nature of the decision. Changing the step after AN/ANI from ArbCom to community process isn't going to cause mass resignations. Admins here already self-select which controversial actions they take to avoid community uproar; this will be no different with or without community-initiated desysopping processes.
The biggest argument I see against a community-initiated process like the one I outlined above is that it would likely have the exact same outcomes as the current ArbCom-led system, and thus the change would only be symbolic. I think this is a fair enough argument to dissuade me from proposing anything on this topic. But I always like to push back against the nebulous claims of possible abuse that could happen whenever something new happens, because whether it's this or IPBE liberalization, it just doesn't pan out that way. Sorry for the long post. -- Ajraddatz (talk) 02:19, 17 April 2018 (UTC)
- Well thought out, as always, but the big counter argument is that the structure of an ArbCom case actively discourages the grudges. There is also the flip side that arguably ArbCom can hold popular admins to account in ways that ANI won’t (and we have plenty of examples of people having their friends stop by ANI). So I think a better counter is: ArbCom works fine, it is arguably more effective than a community process would be for politically popular admins, it provides protection against potential witch hunts in that the actions of all parties are examined, and no one has actually put forward a provsss that would work better. Like Kudpung hinted at above, if anything, the thing that needs work currently is streamlining the process for obvious cases, which the committee has already started to do on its own without some massive reform RfC that would likely end with only minor tweaks to procedure. TonyBallioni (talk) 03:08, 17 April 2018 (UTC)
- No, Tony. ArbCom has already said that ANI cannot delay with admins, and any attempt to do so will be met with a curt "ArbCom is thataway". It's also said that it will not deal with popular admins. One once even blocked a member of ArbCom for comments made during a deliberation, and ArbCom supinely backed down, unwilling to further antagonise. And ArbCom is yet to reinstate even one admin that it has desysopped. That's how dysfunctional it is. Hawkeye7 (discuss) 08:37, 17 April 2018 (UTC)
- I dunno, can we assume that people are willing to tolerate frivolous opposition if it does not derail their (re)confirmations? "Grudge-based votes don't matter in the end" has been offered as an argument at all past discussions on this topic and yet no consensus for a community-based desysoping process has ever arisen, so maybe a lot of people are not willing. Jo-Jo Eumerus (talk, contributions) 08:43, 17 April 2018 (UTC)
- That is exactly the reason why I opened this thread. The rationales aren't logical but based on a system at this point and that shouldn't be the way for things to move forward. I agree with Hawkeye7, AC processes are' dysfunctional, the fact that Tony and few others see it as a perfectly operating committee doesn't even occur to the majority of the community. The only reason AC exists as it is, is because the community still sees a need for a panel to deal with the issues, but nevertheless cannot fix the internal problems which arise from each of its outcome. That doesn't automatically imply that the community is fine with the ArbCom as-is. --QEDK (後 ☕ 桜) 08:01, 19 April 2018 (UTC)
In my view, I agree with "if it ain't broke don't fix it". However, RfA is broken. You only need to look at the most recent Admin newsletters to see the issue. Despite having a whole two (!) RfAs last month, we're losing Admins faster than we gain them. Yes, superficially, that's a direct result of community-endorsed processes to desysop inactive admins, but an inactive admin isn't any use to the project - I think we can all agree that we need a sizable number of active admins. We all know about RfA inflation, and there seems to be some form of consensus in the above posts that the reason for our loss of admins is the high bar to entry. The dispute here is whether we need to lower the bar to exit to lower the bar to entry, or would that be counterproductive. Ultimately, the only way to lower the entry bar is to convince RfA !voters to be more lenient. If it was easier to sanction misbehaving administrators, I expect more people would get the mop. Personally, I would suggest something similar to WP:ACTRIAL, but for a community sanction process (it probably should be limited in scope to admins appointed in the period in question). It would be interesting to see if RfA standards decreased if a desysop process existed, and whether that would lead to a corresponding increase in applications. Regarding sanctions available to the community, I note that ArbCom is capable of handing out temporary desysops - Wikipedia:Requests for arbitration/Pedophilia userbox wheel war. Much like escalating blocks, if the community is able to impose escalating desysops (perhaps leave permanent to ArbCom). I'm not certain myself, but we've got a wide range of options available. I'm sure there is some solution that exists that will achieve consensus, we just need to find it. I strongly believe, however, that we cannot just do nothing. ∰Bellezzasolo✡ Discuss 09:44, 17 April 2018 (UTC)
- @Bellezzasolo: We could start by changing the current system where oppose !votes count three times as much as support !votes at RfA, by moving the discretionary range down to 50% and leaving it up to the 'crats. But yeah, RfA inflation is a problem, and the problem is us. — Insertcleverphrasehere (or here) 10:36, 17 April 2018 (UTC)
- Admin activity at enwiki causes massive resentment from long term abusers down to POV pushers and editors who feel wronged, for example, by an unfavorable outcome at WP:AN3. Inclusionists passionately hate admins who delete pages, and deletionists passionately hate admins who reject speedy delete requests. Enwiki is the number one website for anyone wanting to spread their good news to the world; it's also the best place for spam and trolling and lots of other bad things. The best admins at enwiki spend serious time imposing sanctions and it is absurd to compare their activity with what stewards do, or with what happens at meta/commons/wikidata. The point about a community reconfirmation process is that it would boil down to a vote. People could argue that certain votes should be discounted because no good reason was provided or because the voter had only a handful of edits, but in the end a reconfirmation would be a count of votes. It might be possible to devise a system of voter eligibility requiring that the voter had never been sanctioned by the admin, and had never argued the opposite of a position taken by the admin in a dispute, and had 2000 edits and 12 months experience with 500 edits in the last six months. However, that approach would be rejected due to the overwhelming bureaucracy required. Johnuniq (talk) 10:10, 17 April 2018 (UTC)
- Agreed 100% TonyBallioni (talk) 14:01, 17 April 2018 (UTC)
- I think there is some value in comparing what other wikis do, at least hopefully to the point of not being "absurd". They might have less users, but there is no reason to believe that they would have proportionally less problematic users. That is especially true given that a lot of enwiki-banned users go over to Meta or Commons and have to be dealt with again there. So even though they have less users needing sanctions, they have less admins to give those sanctions, and thus the editors with grudges still exist and could still derail the process (but, again, don't). Anyway, I agree that ArbCom streamlining their process would be a positive here and would require less work that any community-initiated process. -- Ajraddatz (talk) 14:48, 17 April 2018 (UTC)
- The fact that Commons is a haven for the people we show the door is precisely one of the many reasons we should not look to them for anything except copyright. TonyBallioni (talk) 14:57, 17 April 2018 (UTC)
- Your point is that the POV pushers and axe-grinders are explicitly given free reign at RfA. And the solution is to restrict the editors who have access to the process. Which is, in fact, what we are already doing by giving the desysop function to ArbCom. Hawkeye7 (discuss) 21:44, 17 April 2018 (UTC)
- I don't see why you would need to bear grudges against people who've moved on to other communities, your logic is simply a fallacy at this point. Sometimes it's best to take your own argument with a pinch of salt instead of apparently irrefutably stating that admins are fallible to socks/LTAs and we must do our best to protect them. Admins aren't at risk without exhibiting abuse and this is a step further in that direction as well. --QEDK (後 ☕ 桜) 08:01, 19 April 2018 (UTC)
- 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)
- 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)
- Agreed 100% TonyBallioni (talk) 14:01, 17 April 2018 (UTC)
- I guess this is starting to get a bit broader in scope. But I would agree without qualification that any move which helps simplify ArbCom is one in the right direction. One of my biggest problems with both AC/DS and ArbCom itself is that both are so ungodly complicated that they essentially don't exist as a form of dispute resolution that's available as a remedy for use by new and moderately experienced users. GMGtalk 14:13, 17 April 2018 (UTC)
- I get the feeling, from TB and Kudpung, that the ArbCom process is actually likely to be sufficiently streamlined in its current form. However, I don't think that the actuality of that matters. There's a fairly wide perception of anything branded "ArbCom" as highly bureaucratic (which it of course is by necessity), and also slow and unwieldly. Furthermore, the result is a perception of Administrators as semi-untouchable. Hence the high standards at RfA. I doubt that a community process is necessary - it's likely to result in the same outcome as an ArbCom case would. However, I dare say there are users who would be happier handing out the bit if they felt more empowered to remove it. I also note the above discussion questioning the wiki-legality of TBAN'ing an admin from their tools. However, if we are able to TBAN an admin from certain tools (established), and CBAN admins, I'm pretty confident of the ability to TBAN the entire suite of tools. Of course, that differs from the technical ability to desysop - just like there's not technical enforcement of normal TBANs. I think that making this clear as an option - after all, the community is generally the ultimate seat of authority on non-legal issues, short of a Jimbovention. Of course, an admin could violate such a TBAN, but an ArbCom case would likely result. Perhaps an RfC and consultation with the Arbs on this is justified. I expect that, should a proposal as such pass, the community would feel empowered, without much changing (ArbCom can of course overrule such a TBAN, on an individual basis). ∰Bellezzasolo✡ Discuss 15:49, 17 April 2018 (UTC)
- I don't think the TBAN would need consultation or an RfC. I think it would need to be tested. In other words, you would have to make the constitutional crisis in order to solve it. If the actions of an admin were really bad enough that there would be strong consensus for it, I doubt ArbCom would intervene to override it. Whether they would desysop someone for violating it may be a different story. It would be even more politically complicated if ArbCom actually declined a desysop, and then the community responded with a TBAN. If that ever happened all bets are off and I have no idea at all how it would work out. GMGtalk 16:08, 17 April 2018 (UTC)
- 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)
- (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)
- 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)
- 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)
- 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)
- I know it's a popular theory (because it makes it easy to explain away the ills of the system), but I've never actually seen or heard any hard evidence that occasional ridiculously high standards are putting potential candidates off. It seems to me that such votes are made by people who don't have a clue what RfA and adminship is all about, they are not regular RfA participants, and they would probably not stand a chance of becoming an admin themselves.
- Nor have I personally noticed any indication that the reasons for such high standards link to a perceived notion that it's too hard to remove the bit - again, such voters have such a shallow understanding of the process that they probably don't even think that far. More damage is done to RfA by people who serially make ridiculous oppose votes on the flimsiest of grounds, and who are also determined that even an RfA that is clearly going to pass doesn't get away without at least one vote in the oppose section. WP:RFA2011/VOTING is still the only in-depth research that was made into RfA voters and their trends and most of it continues to be largely accurate today, though an update to the stats would be interesting, .
- I believe there is a growing apathy for maintenance work in general. I'm aware of TonyBallioni's view of WP:ORCP but while I think it's not such a bad initiative, it's also not used as often as it was. IMO, lowering the bar to adminship is absolutely not the way to go, but imposing a threshold for voting there almost is certainly worth considering, but an up to date WP:RFA2011/VOTING-style research would be needed to establish the criteria. What would be appropriate right now are a few T-bans for those who turn up to vote with the sole intention of creating more heat than light. If we lower the bar, we'll almost certainly risk have an increase in admins who do not really have the skill set for the job - and then we will need a fast track desysoping system. What we should be looking at are ways of reducing the bureaucracy, not creating more of it. Kudpung กุดผึ้ง (talk) 01:44, 18 April 2018 (UTC)
- The idea that the low rate of people becoming new admins is down to the lack of a community desysop process doesn't add up. The number of successful RfAs went from a peak of 408 in 2007 to 28 in 2012 and has remained at that kind of figure since. If that decline was due to admins being perceived as "untouchable", why weren't they perceived that way in 2007? The procedures for desysopping didn't change much between 2007 and 2012. If anything I think we are now a bit harsher on admins who screw up than we used to be. Doubtless there are several factors behind the decline in the numbers of successful RfAs, including standards inflation (standards have certainly gone up), reduced activity in the project generally (there is less admin work than there used to be) and possibly some decline of interest in maintenance tasks as Kudpung suggests. But I find it hard to believe that desysop procedures are much of a factor. On the other hand a community desysop process would mean more RfAs, or at least more of an RfA-like process. If RfA is broken then that's not a decision we want to make. Hut 8.5 20:11, 20 April 2018 (UTC)
- While there was a drop in raw edit levels from 2007 to 2014, before the 2015 rally, we still don't know whether the loss of edits due to the edit filters and the use of huggle etc to revert and block vandals faster means that there is more or less actual activity now than at the supposed peak in 2007. In any event the changes in level of activity on the site are minor when compared to the change in activity at RFA, especially as in a maturing community you would expect a growing proportion of editors to be admins rather than a declining proportion. But we should also remember that RFA has changed out of all recognition since 2007, in particular the biggest RFA reform, the unbundling of Rollback in early 2008, ended the era when "good vandalfighter" was sufficient qualification to pass RFA. There are now nearly five times as many Rollbackers as admins........ ϢereSpielChequers 21:14, 27 April 2018 (UTC)
- Actually, I did the back-of-the-envelope math a few weeks ago on the larger Wikipedia projects by active users, pulling numbers from here, and the ratio is fairly steady IIRC at about 0.5% to 1.5% of the total active population. Seems a lot like the top ~1% of most-admin-like (however you define that) users is pretty much the standard, and the changes in the community only affect what the top 1% most-admin-like users are defined as, and not what the ratio is. However, the changes in that definition are substantial, especially on comparatively tiny projects. RfAs on Commons make RfAs on enwiki seem like grotesque affairs, and it's still pretty big. Even more so for RfAs on something like Wikiquote or Simple, which don't even get as much participation as a standard RfC on enwiki. GMGtalk 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)
- 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. GMGtalk 21:33, 27 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)
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.
- 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.
- 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.
- 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.
- 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.
- 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)
Proposal creating an event coordinator user right
There is currently a proposal at Wikipedia:Requests for comment/Event coordinator proposal about creating a new user right for event coordinators. All are invited to participate. TonyBallioni (talk)
Automatic welcome messages for new IP editors and new Registered editors
I propose that a Wikipedia bot should automatically welcome all new IP editors and new Registered Users at their talk pages. At present, there is no such welcome system. Instead, we have a very unevenly distributed system of individual editors attempting to welcome some, but not all, new users and IPs. Brian Everlasting (talk) 03:35, 26 April 2018 (UTC)
- You may wish to review Wikipedia:Perennial proposals#Use a bot to welcome new users. Anomie⚔ 11:41, 26 April 2018 (UTC)
- @Brian Everlasting: User:HostBot invites new users to the Teahouse RudolfRed (talk) 21:30, 26 April 2018 (UTC)
- IPs by their nature need an uneven system. Some IPs are stable over long periods of time, years even, others are reset in hours. There is no point sending a welcome to a goodfaith IP editor unless their address seems stable, and that requires human judgement. ϢereSpielChequers 11:00, 29 April 2018 (UTC)
Add a link to the Signpost to the Main Page
Yes, yes, I know, perennial proposals and all, but what about just a small link under Other areas of Wikipedia? The Signpost is definitely useful for getting up to date with what's going on in the community, and there's also a good deal of work going into it. However, it's nearly impossible to find it, and readership has been declining for several years. There have been several crises in the team itself, mainly due to a lack of contributors - which obviously get recruited from readers. Therefore, I think it's both in the interest of Wikipedia and of the Signpost to add a
- The Signpost – Stay informed on what's going on by reading the newspaper for Wikipedia.
to Other areas of Wikipedia. Thoughts? Zarasophos (talk) 08:46, 27 April 2018 (UTC) This proposal has been replaced by the idea of adding a notification to the watchlist as discussed further below. Zarasophos (talk) 21:33, 29 April 2018 (UTC)
This seems like a good idea. It will not take up too much room on the Main Page of Wikipedia to do this. Vorbee (talk) 10:11, 27 April 2018 (UTC)
- Support - why has this never been thought of before? Kudpung กุดผึ้ง (talk) 10:47, 27 April 2018 (UTC)
- Oppose - because the signpost is a bunch of navel gazing bullshit and editorials that almost always do not meet quality to be linked from the main page. Only in death does duty end (talk) 10:53, 27 April 2018 (UTC)
- Strong oppose-Mainly per OED, whilst distancing from the qualifiers:).Signpost is nowhere near to Mainpage-stuff.~ Winged BladesGodric 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)
- 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)
- 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)
- 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)
- Oppose The signpost is primarily written for editors and not for our non-editing readers. --Jayron32 13:14, 27 April 2018 (UTC)
- Moot As Bellezzasolo points out, we already have this. He pointed to the Site News link. Signpost is also prominent in the Community portal which is linked in the sidebar for every page, not just the Main page.Andrew D. (talk) 14:59, 27 April 2018 (UTC)
- Oppose -actually strong oppose if it means anything. Signpost is nothing more than glorified WikiProject newsletter. It is nowhere near the standard of being in the main page. –Ammarpad (talk) 15:16, 27 April 2018 (UTC)
- Support - Signpost builds and indicates community which is what we want to broadcast to readers and editors. The quality is fine, better than fine considering it's volunteer grass roots with 0 budget, like most everything else on WP. Our ethos is open knowledge for all, but many have an attitude that open knowledge about Wikipedia itself is not of public interest. Far from it. -- GreenC 15:58, 27 April 2018 (UTC)
- Oppose for "publicity", posting the Signpost to places like the Teahouse or WP:AN would be better. For the mainpage itself, making the link to Wikipedia:News more prominent would be most helpful. power~enwiki (π, ν) 18:13, 27 April 2018 (UTC)
- Oppose as per above - Do we really think our non-editors would care about "Admin reports board under criticism", " WikiProject Military History" or "ACTRIAL results adopted by landslide" ? ... No ofcourse they wont, The Signpost is more of an editor thing than a reader thing. –Davey2010Talk 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)
Commons deletion notification bot
This bot was proposed via the community wishlist in 2017. It is currently being build and should be done in a couple of months. The bot is going to be "opt in" and will place a notification on the talk pages of article when an image used within that article is put up for deletion on commons. Further details here. One eventual hope is to have the article alerts pages include these items. Wikipedia:WikiProject Medicine/Article alerts Peoples thoughts? Doc James (talk · contribs · email) 11:37, 27 April 2018 (UTC)
- I like it. Since the opt-in is going to be on a per wiki basis, It follows that an RfC should be started pretty soon. Am I correct?--John Cline (talk) 11:55, 27 April 2018 (UTC)
- 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. GMGtalk 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)
- 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. GMGtalk 11:24, 29 April 2018 (UTC)
- The current plan is to pick the 10 with the most watchers. — JJMC89 (T·C) 06:20, 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)
- 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)
- The bot would also need a WP:BRFA, but I don't see this being particularly problematic. Headbomb {t · c · p · b} 13:54, 27 April 2018 (UTC)
- Agree. The earlier notifications are made, the less likely deletions will be made prematurely. In fact, I rather thing that delaying telling folks that a deletion might occur is contrary to the intent of Wikipedia and Commons to retain as many images as possible, rather than to make deletion easier which occurs when folks are not notified. I have not found Commons to be excessively deletionist, nor would I wish it to become so. The Wishlist survey appears to be convincing here in its position. Collect (talk) 11:31, 29 April 2018 (UTC)
- Do people think we need a formal RfC? Or is the support here and during the proposal process for the creation of this tool sufficient? Doc James (talk · contribs · email) 03:30, 4 May 2018 (UTC)
- When a change occurs that people were not expecting, there is often a backlash. If there is a RfC first, there is usuaally more acceptance, even if sometimes grudging. · · · Peter (Southwood) (talk): 07:56, 4 May 2018 (UTC)
Add a notification for the the Signpost to the watchlist notice
Hello all, a discussion about using the watchlist notice to provide notification to users of new issues of The Signpost is open at MediaWiki_talk:Watchlist-messages#Signpost - your input is welcome at that discussion. Thank you, — xaosflux Talk 21:15, 29 April 2018 (UTC)
- As I have stated before, I support this idea because the Signpost serves as an important tool for the en.Wiki community to get informed about and discusd all kinds of topics. While these functions are important, it is currently in a crisis of readership (with the numbers steadily decreasing for the last years) resulting in a crisis of volunteers. A watchlist notification could be a first step out of this crisis. Zarasophos (talk) 21:38, 29 April 2018 (UTC)
- @Zarasophos: This is not a vote. Xaosflux is just letting watchers of this page know about the other discussion. Chris Troutman (talk) 21:57, 29 April 2018 (UTC)
- True enough, I guess I shouldn't do tired Wikipedia. Zarasophos (talk) 21:58, 29 April 2018 (UTC)
- @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)
New article template
When someone starts a new article, there is a template with useful links above the editing box, one that starts with "Before creating an article, please read Wikipedia:Your first article". The last line says "You can also start your new article at Special:Mypage/Article. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready".
What about adding a link to Draft/Article as well? The text may mention that it would be preferred for drafts that would be worked by several users (at least, that's the idea), and that the userspace is more suited for personal projects. Cambalachero (talk) 01:23, 5 May 2018 (UTC)
Delhi Project Tiger Edit-a-Thon
- Brief
An Edit-a-Thon with Workshop has been scheduled on below given dates. This is an initiative taken for Delhi-NCR Wikimedians/Wikipedians to support the PROJECT TIGER WRITING CONTEST. New editors will be introduced to Wikipedia and educated about the system. They would be trained to get engaged with Wikipedia by contributing their works.
All editors of Delhi-NCR are requested to attain the edit-a-thon with new contributors without any language barrier.
- Bottom Line
- Adding up New Contributors
- New Contributors Orientation
- Workshop on Editing by Introduction of WMF, Wikipedia
- Training on language translation & Developing skills
- Educating about Wikimedia protocols, tools & system
- Date
Day 1: Saturday, 2018 May 19, 10:00 AM IST
Day 2: Sunday, 2018 May 20, 10:00 AM IST
- Venue
USO International Center
USO House, USO Road,
6, Special Institutional Area,
New Delhi - 110067
- Link to Event Page
https://en.m.wikipedia.org/wiki/Wikipedia:Delhi_Project_Tiger_Edit-a-thon
- Organizer & Ambassador
Raavi Mohanty 07:10, 5 May 2018 (UTC) Raavi Mohanty
Category tagging for article sections
Might it be useful to be able to list article sections in a given Category, where the main article topic is not suitable? For example the article on the Supermarine Spitfire prototype K5054 has a section on Replicas, while the de Havilland DH.88 Comet article has one on Airworthy reproductions and replicas. It would be useful to include these sections in Category:Replica aircraft. For example one might be able to add a template or a modified category tag to the section, for the sake of argument something like:
==Replicas== [[Category:Replica aircraft|sortkey=Supermarine|section]]
which would list the section as:
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)
The mess of actors by medium
I tried to start a CfD on this issue. It can be reached if you go to Category:Film actors and follow the lead. So far, it has very little participation, and one long winded, mean spirited objection. This despite the fact I literally went through 100 articles in preparation for the nomination, and demonstrated that in over 90% of those television actress articles there was overlap with other mediums. I also pointed out multiple cases, such as Star Trek, where the same actors played the same roles in both TV and film. This is about the only case where someone woould be so rude in response to someone having literally posted 79 categories to the nomination. Then there was a complaint about not posting to projects. Well, I tried to post to projects, but the guidelines on CfD in no way make it obvious how to post to projects. I tried to post to individual editors too, but the posting heading provided was just not working. This needs a wide discussion, but the general response exemplified by some commentators at CfD to just be rude to those who do not do the impossible of posting a proposal onto thousands of categories is troublesome. With the rise of categories like Category:American web series actors do we really want to categorize actors by how the creatin they were in was distributed. What are made for TV film actors? What about films first released on netflix? Where are the lines?John Pack Lambert (talk) 18:34, 5 May 2018 (UTC) I put this both here and in policy, I really do not know where to put it, I just want to start a true discussion. We need to avoid being hung up on the present way things are done.John Pack Lambert (talk) 18:36, 5 May 2018 (UTC)
“What links here”
When I’m expanding an existing Wikipedia article, one way to find good info to add is by using the “What links here” button. But this is ruined if the article that I want to expand is in a template that’s used in a ton of articles. For example, consider Picket Lake, Minnesota. If you go to that article and click on “what links here” you get a ton of useless search results that are listed merely because they each use a template that happens to include a link to Picket Lake, Minnesota and it’s impossible to tell which of the search results will actually provide further substantive info about Picket Lake. So, I suggest that the “what links here” button should exclude search results that merely have templates mentioning the article in question, although the template itself would be a valid search result that would not cause any difficulties. Or else the search results should indicate which ones result merely from a template. Anythingyouwant (talk) 03:49, 6 May 2018 (UTC)
- This is a question that probably needs to be added WP:PERENNIAL. The answer is, yes, it could be so-modified, but no, it probably won't happen, because it is marginal utility for some probably-large amount of software work to make the search and WLH functions work inconsistent with expectation. --Izno (talk) 13:40, 6 May 2018 (UTC)
Proposal: A US-only CentralNotice in support of Net Neutrality.
Proposal: A US-only CentralNotice in support of Net Neutrality.
Net Neutrality is the principle that service providers should treat all Internet traffic as equal, and not discriminate on the basis of origin, destination, or type of data. Net Neutrality protects people's access to knowledge by prohibiting internet service providers from blocking, slowing, or prioritizing data traffic for a fee.
The Wikimedia Foundation and several US Wikimedia affiliates have come out in support of Net Neutrality in the United States, as well as the efforts in Congress to keep the Open Internet rules in place. Just as the Foundation considers Net Neutrality as essential for access to knowledge, the Wikimedia community should realize that equal access to knowledge is important to our mission and knowledge equity and act accordingly. The concern is that if access to Wikipedia and/or its sources is slowed, or allowed only as part of a paid premium, this could gravely harm our fundamental mission to provide free access to knowledge for all. Any restricted access could reduce the quality of articles and reduce the diversity of contributors who create and maintain Wikipedia’s content. If access is limited in a way that restricts access to sources we use to create Wikipedia articles, that hinders our mission of delivering free knowledge.
This proposal is to gauge the community's interest in presenting a banner to US-based viewers of the English Wikipedia, which would show the importance of Net Neutrality to Wikipedia's mission and encourage further reading and action. A landing page with more details has been produced here. A proposed banner with expandable information is previewable here, with a preview of its unexpanded form as follows:
Free knowledge depends on net neutrality.
We are asking for your support.
The reason this proposal is being brought up now is that on May 9, a petition will be filed in the U.S. Senate to force a vote on a bill to block the FCC's December repeal of net neutrality rules. The bill currently has bipartisan support from half the Senators, and only one more vote is needed for the bill to pass in the Senate.
In general, Wikipedia should remain non-partisan and non-political; however, Wikipedia's own mission of free and open knowledge for all is a political one, and the community must support public policy when that policy is vital to protecting its mission. Just this week the German Wikipedia ran a banner to support European Union copyright reform; in the past, banners were run in South Africa in support of freedom of panorama, and banners were run in Australia to support fair use. This proposed Net Neutrality geo-targeted banner would be in line with previous community efforts to support policies in the best interest of Wikimedia.
Some may remember SOPA and PIPA, two other laws that would have radically altered how the internet is used in the United States in a way that negatively impacted our mission. A Wikipedia blackout and banner was instrumental in turning public and legislative opinion against these detrimental bills. We're not going for a blackout this time, but hope that a US-focused banner can direct attention to the issue and preserve Net Neutrality by promoting a grassroots effort to convince Congress to act.
Thank you.
Further reading:
- Wikimedia Foundation: "Net neutrality is essential for access to knowledge"
- Fight for the Future: Battle for the Net
- Public Knowledge: "Tell Congress to Use the CRA to Save Net Neutrality"
- Wikipedia articles: w:Net neutrality, w:Net neutrality in the United States
Discussion
- Support Gamaliel (talk) 19:00, 6 May 2018 (UTC)
- Support Blervis (talk) 19:10, 6 May 2018 (UTC)
- Support as co-writer. ~SuperHamster Talk Contribs 19:10, 6 May 2018 (UTC)
- Oppose net neutrality is not in the interest of the global Wikimedia movement (see Wikipedia Zero, which is bring wound down, but is the exact opposite of net neutrality.) Even with Wikipedia Zero being done away with, the Foundation will likely gave future projects that would benefit from net neutrality not existing, and that would serve our readership in the US and around the world. We should not be promoting political concepts that hurt the global movement. TonyBallioni (talk) 19:15, 6 May 2018 (UTC)
- I'm puzzled by the assertion that "net neutrality is not in the interest of the global Wikimedia movement". Wikipedia Zero was a necessary step in countries where the situation is not ideal and net neutrality is not in place, but I doubt anyone participating in that would trade real net neutrality for a workaround like WZ. The Foundation (was in charge of WZ) has publicly come out strongly in favor of NN, so they seem to think it *is* in the best interest of our global movement, as do many in the Wikimedia volunteer community. Gamaliel (talk) 19:21, 6 May 2018 (UTC)
- Whether it's the problematic grammar or the confusing line of thought, I don't understand your point. I'm not trying to be argumentative – I honestly don't understand it. Care to clarify? -- Fuzheado | Talk 19:24, 6 May 2018 (UTC)
- Support - This is an important enough issue not just in the US, but globally, and one where the community should have a voice of conscience. The modest proposal is not an extreme one like the SOPA blackout – it is a nondisruptive awareness campaign to highlight a troubling trend that could affect more than just daily traffic to Wikimedia projects but everything from multimedia uploads to bulk data contributions to GLAM collaboration – all the types of things have gotten Wikimedia to where we are today. -- Fuzheado | Talk 19:20, 6 May 2018 (UTC)
- Support Richard0612 19:24, 6 May 2018 (UTC)
- Support. Also show to users with IPs from Canada and Mexico, as some ISPs near the borders serve both sides. Lojbanist remove cattle from stage 19:27, 6 May 2018 (UTC)
- Support. --Rosiestep (talk) 19:39, 6 May 2018 (UTC)