Hi WTT, I'd be concerned that the community would grow tired of these constant polls quickly if they had to run in large numbers for over a year to bootstrap them. How to fix that -- maybe something more radical: actual "voting"; perhaps quarterly until the backlog is gone, then annually. We could use secure poll with some basic automatic voter filters. Dump large lists of candidates with a single question: either "Should administrator x be retained?" or "Should administrator x be recalled" - no Q&A period; (YES/NO/SKIP voting options). Ones that "pass" are good for 10 more years, ones that fail can go in to a reconfirmation RfA system like you are describing? Just an idea, I'm glad you are workshopping this first though! — xaosfluxTalk 10:43, 2 March 2021 (UTC)[reply]
Xaosflux, I'm limited workshopping! I've grabbed about half a dozen names who I've seen express an interest (or dis-interest) in the idea, from a variety of backgrounds - but if you think there's anyone else who might be interested in helping work on the proposal, do feel free to ping them.
It is expected that the community will not participate in bulk on many of these polls - I'm not expecting 200 votes on each - I'm expecting something akin to RfA's of old. I did consider the secure poll option, which is a definite alternative. However, my only experience with secure poll is the arb elections and one CUOS election, and whilst it does feel lightweight for the users, I was under the impression that it does take a bit of work to set up. What's more, there's the concern of sockpuppets / multiple voting - which can be handled much better in the open.
Looking at quarterly secure polls, if we want to implement over 18 months, we'd be looking at 6-7 polls, meaning we'd need to have over 100 admins in each vote (based on the 876 number) - so from a user experience perspective, that's not a great option either. WormTT(talk) 10:54, 2 March 2021 (UTC)[reply]
I think we should remember that these admins are volunteers and like all volunteers entitled to be treated with respect and dignity. A rushed process that doesn't give serious consideration to each individual would risk reconfirming some bad apples with friends and maybe losing people who made the wrong enemies. We should also remember that with any sort of mass reconfirmation process that there will be badsites using this to try and pick off their enemies, gays, women etc.... A simple voting system rather than proper scrutiny would make such off wiki organising by trolls much easier. ϢereSpielChequers 10:58, 2 March 2021 (UTC)[reply]
WereSpielChequers, I've attempted to put in safeguards for that, extended confirmed, not sanctioned by the admin, etc - and other suggestions would be welcomed. WormTT(talk) 11:36, 2 March 2021 (UTC)[reply]
@Worm That Turned: yes the "there's too much to do so just don't do anything" problem is going to come up in debate to move anything forward. SPoll can take a lot to setup. We could also do it like the steward confirmations (meta:Stewards/Confirm/2021) - except it would be a pre-screener; failing would lead to a process more akin to what you are suggesting above. Just spitballing here! — xaosfluxTalk 11:02, 2 March 2021 (UTC)[reply]
Xaosflux, I was definitely basing my idea on the steward confirmation route, with a bit more weight behind it. Also, I recall that for SecurePoll CUOS in 2010 - only one candidate met the threshold. That's a concern if happens here. WormTT(talk) 11:34, 2 March 2021 (UTC)[reply]
@WereSpielChequers: my only point of a "vote" would be to mostly screen out all of the what I'd hope would be easier "keeps" to prevent them from having to go through the coals of q/a; etc. — xaosfluxTalk 11:02, 2 March 2021 (UTC)[reply]
I appreciate that that is your intent. But what happens when someone is rejected by such a vote? The problem of such a vote is partly that some people will feel that they have been rejected without a proper hearing, but also that some people will think that some people are sneaking through without enough scrutiny. I had an unsuccessful first RFA, when I read it again before my second RFA it was very clear why almost all he opposers opposed. With an election we risk having a swathe of rejected former admins who aren't sure why they lost adminship. ϢereSpielChequers 16:19, 2 March 2021 (UTC)[reply]
Thank you for putting together this workshop, WTT. I believe that retaining an RfA format for reconfirmation is important, and would much prefer that over actual "voting"/"polling". To me one of the main points of a reconfirmation RfA would be not just to see if an admin still has the trust of the community, but also to provide every admin a substantial feedback about their admin work and expose them to scrutiny. I think that the pace of reconfirmation RfAs for the existing crop of admins that you suggest is too high. Perhaps in 2007 we could handle 76 RfA requests per month but I doubt we could now. I think the stagger for the existing crop of admins needs to be extended longer, probably much longer, say to something like 6 years. Then there'd be about 3 of these per week, which I think is quite manageable (plus some people probably will choose not to run). Nsk92 (talk) 11:07, 2 March 2021 (UTC)[reply]
Nsk92, there's a balance to be found. Asking all admins to face a full RfA again will sink such a proposal. I agree scrutiny is required, hence my opinion that we should include a discussion. I do, however, accept that the pace may be too high - and if we spread it out over a further 6 months, we'd bring the number per week down to ~10. But since the intent is for a lighter process which can include some scrutiny and review, whilst equally being something that is not to be feared, and I felt that 15 per week would take the pressure off the individual admin, allow scrutiny, and be a manageable number for the community to review. WormTT(talk) 11:33, 2 March 2021 (UTC)[reply]
I doubt that requiring an RfA format will sink the proposal. There will be objections from admins themselves and from users concerned about admins facing vindictive relatialory action in such reconfirmation RfAs from disgruntled "customers". However, we've had a number of reconfirmation RfAs in the past (although they were voluntary) and such fears did not materialize there; those RfAs all passed with 75%+ support, AFAIK. The concern can be allayed somewhat by lowering the passing bar compared with the new RfA. I also think that many people will object to using an "RfA light" format for reconfirmation as not allowing proper scruitiny and review. I'll probably be one of them. If the process is to occur just once every 10 years, I think the standard RfA format should be used. Nsk92 (talk) 11:47, 2 March 2021 (UTC)[reply]
Also, note that questions to the candidates are allowed/used in both ArbCom and Steward elections, both of which are higher profile and arguably higher drama level events. To me disallowing the questions section in a reconfirmation RfA to a large extent defeats the purpose of a reconfirmation RfA, which is to make every admin genuinely accountable to the community. That includes explaining and if necessary defending their admin actions in a reconfirmation RfA. They should have to answer questions there. Nsk92 (talk) 11:59, 2 March 2021 (UTC)[reply]
Nsk92, I don't agree that the "RfA light" option does not give proper scrutiny. Discussion would be available on the talk page for genuine discussion of the confirmation. What's more, those who wish to ask questions could do so at that venue. However, equally, to manage such a large number of reconfirmations, we need to find an alternative system - RfA has a reputation which I am very strongly trying to move away from, so this proposal has a chance of success
Pointing to reconfirmation RfAs is a fallacy - just as point to recall would in a desysop discussion. There is clearly going to be correlation between those willing to subject themselves to such a process and those who are successful. WormTT(talk) 12:38, 2 March 2021 (UTC)[reply]
You may be right that the admins who did run in a reconfirmation RfA voluntarily were likely to be more successful. But still some of them were quite active as admins and definitely performed a large number of admin actions, e.g. Wikipedia:Requests for adminship/HJ Mitchell 3. I don't think that relegating questions to the talk page is sufficient. The candidate is not obligated to respond there and a response may be fragmanted in a large number of pieces and harder to trace. A formal questions section, such as that currently used in RfA, as well as ArbCom and Steward elections is far preferable. If we make ArbCom candidates (including when the run fo re-election) answer questions in a formal questions format, we should do no less with admins who will only face the voters once every 10 years. I believe that people's complaints about the RfA "reputation" are almost entirely misplaced, similar to the abstract misplaced sentiment that "we need a community desysop system" (which is usually not based on a clear and well reasoned justification of why we need such a sustem). In my opinion, the current RfA system is perfectly fine for adminship, as adminship is currently configured. Successful RfAs recently tend to pass by a wide margin, and contentious RfAs are relatively rare. The real problem, again IMO, is that the current configuration of adminship requires too much in terms of knowledge and experience from a candidate; Wikipedia is growing more complicated as a project but the supply of regular experienced editors is stagnating. Nsk92 (talk) 13:10, 2 March 2021 (UTC)[reply]
Nsk92, I'm persuaded that a formal question section is a reasonable thing to include - though I'm not persuaded that it needs to be on the front page. In both Steward and Arbcom elections, questions are on a separate page, so I see no reason that the questions should not be held on the discussion page. As part of the safeguards, I wonder if it is worth putting in a rule that "questions should be tailored to candidates", so you don't get people simply adding questions to every candidate - which would become onerous. Similarly, a maximum number of questions / followups?
For example, in arbcom elections, we used to have an individual who would post a questionnaire for each candidate, leading to lengthy questions sections. I'll note that Steward confirmation (as opposed to election) doesn't include questions. There's an argument that their actions speak for themselves. WormTT(talk) 13:41, 2 March 2021 (UTC)[reply]
Yes, I think moving formal questions to a separate page would be fine. An interesting point regarding Steward confirmations, I didn't realize the procedure there is different. Nsk92 (talk) 13:45, 2 March 2021 (UTC)[reply]
I think this is basically right. Discussion, comments, and optional questions on the talk page lower the heat but allow the valid scrutiny to be aired and discussed and not papered over (we used to do more of this at RfA). Steward confirmations are a good analogy and seem to work well, especially for removal. ~ Amory(u • t • c) 22:04, 2 March 2021 (UTC)[reply]
@Nsk92:, I disagree in the strongest possible terms. The question isn't about scrutiny like at an RfA; it's about confidence. RfA's are pits at their worst and a stressful and difficult process at their very best. Reconfirmation should not resemble an RfA in any way. This is not a proposal that aims to remove obviously misbehaving admins (ArbCom does that), it is one that seeks to make sure there is some level of confidence. A RfA asks: "Does a clear supermajority of the community have faith this person can be trusted as an admin?" This process should instead be asking "Has the community lost faith in the use of the tools by this admin?" It's a different question and there is no reason that the RfA process should be mirrored just because it's community views on admins. A simple majority of reconfirmation votes should be enough to retain the tools. We aren't trying to purge the admin corps, we're trying to keep the committed ones. Eggishorn(talk)(contrib) 21:59, 2 March 2021 (UTC)[reply]
As I said, I see the purpose of a reconfirmation process mainly to get the admins to shape up and and make sure that the community has continued confidence in them. I believe that all the moaning and groaning about the RfA being the pits of hell is based largely on irrational myths and not on what actually happens there. In reality RfA is a perfectly adequate and a largely uncontentious process for granting adminship as adminship is currently configured. In 2020 there were 16 successful RfAs and they all passed pretty easily with 75%+ support, with a single exception (the Money emoji RfA that had 70% support and was closed as successful after a crat chat). There was only one RfA that run to the end and was closed as unsuccessful (with 42% support). There were several quick withdrawals but looking at them more closely it seems that the candidates made the right call to withdraw quickly after significant issues were brought up during the RfAs. The tone of the RfA oppose votes is generally respectful and often apologetic, not the nasty angry mob people make it out to be. The RfA is a perfectly fine and well established process for demonstrating that the community has trust for a particular editor to be an admin. We should utilize this process to the extent possible, so long as the adminship itself remains configured as it currently is. Nsk92 (talk) 00:03, 3 March 2021 (UTC)[reply]
There are a number of problems with term limits, in particular loss of the long tail - admins who may not do enough, or use the tools enough to think they could now pass an RFA. Short term this may not be a problem, collectively this group does quite a bit, but individually they currently do little. Longer term it is much more of an issue, we know that being an admin is a big plus for editor retention, and while we don't have figures for reactivation of admins, logic and experience of other volunteer communities would tell us that people who have kept their account going are much more likely to return to activity - especially after retirement, redundancy, relationship breakdown etc.
Specifically at ten years - this would be seen as way too long for most people who want to cull our admins, but at the same time it would give us a huge overnight change as most of our admin cadre have already served more than ten years as admins. You would likely start with losing over a hundred admins and over a hundred simultaneous admin reconfirmations. If you really want a term limit system, I would suggest a proportional one with flexibility for the admin to time their confirmation. For example, every calender quarter the 5% of admins with the oldest RFAs have to submit a reconfirmation RFA or are deemed to have retired as admins at the end of the quarter. You could exempt anyone whose RFA or reconfirmation RFA was in the last five years, so however many new admins we appointed no one had to reconfirm in under 5 years. You could also count RFBs and successful Arbcom elections as reconfirmations, and given the pass mark, have a new RFB close, unsuccessful RFB but adminship renewed.
An alternative change would be to have a tweak to the inactivity rules. Just add or fewer than 500 edits in the last five years. I think this would address the group that most annoys people who want reform. If you have fewer than 500 edits in the last five years you are unlikely to be sufficiently active to have stayed in touch with community norms, and there are a number of admins who do a trickle of edits that just keeps them out of the current inactivity rules. ϢereSpielChequers 10:48, 2 March 2021 (UTC)[reply]
WereSpielChequers, I'm aware of the long tail. I'm equally aware that we have admins who are doing the bare minimum to simply retain the prestige. Ensuring that both are dealt with correctly (keeping the former, but losing the latter) will be the trick. I'm not keen on doing this through activity rules, as fundamentally I believe "lifetime adminship" is not good for the encyclopedia, especially since the sensibilities of the community have changed massively since the vast majority of the of admins were created over 15 years ago.
I chose 10 years to keep away from making this a way to desysop specific admins, but at the same time gives a good timescale for a project that is 20 years old. I agree it will be a seismic shift and that's why the implementation plan needs to cover that. There are very few individuals who fit into the "RfB or Arbcom" exemption and, honestly, I don't want to suggest giving those folks (i.e. me!) a free pass. WormTT(talk) 11:26, 2 March 2021 (UTC)[reply]
I'll say more below when I have a bit more time, but 10 years is possibly a sweet spot. Any shorter and entirely too much of our bureaucracy becomes maintaining our bureaucracy, any longer and it's not much use. I'm already envisioning a weekly newsletter subscription for every Sunday/Monday with "Here are this week's 5 (or 10) reconfirmation RfA polls!" that seems exhausting. If we lose half the cadre or it turns out to be super simple and smooth, then fine, we can adjust, but 10 is a reasonable starting point. ~ Amory(u • t • c) 22:01, 2 March 2021 (UTC)[reply]
WSC, I think the edit limit is semi-orthogonal to this proposed proposal, but not necessarily a bad one, although I'm pretty sure it's been rejected in the past for all the expected reasons (not all of which are wrong). ~ Amory(u • t • c) 22:01, 2 March 2021 (UTC)[reply]
Hi Amory, I appreciate that it is radically different to this proposal. But I think it is more targeted at precisely the perceived problem that this proposal seeks to address. As for coming up before, I hesitate to say this, but I'm not sure it has. One reason why it might not, or not often, is that it is a relatively new problem that used to be masked by the long inactive. Now that the project is much older, and the people who have completely stopped editing have been desysopped, this group is now more obvious and has begun to attract criticism. I have followed discussions at talk RFA for much of the last dozen years and I could list a score of perennial suggestions. I'm not sure this is one of them. ϢereSpielChequers 12:12, 3 March 2021 (UTC)[reply]
WereSpielChequers, I do agree your alternative suggestion would solve some of the symptoms which this change is looking to improve - indeed it probably solves the most significant ones. However, it doesn't solve the "fundamental" issue that once you've become an admin, you're an admin until you either choose to give up or you take egregious or regular problematic actions.
Indeed, I don't see your inactivity suggestion to be an "alternative" at all, but rather a complementary solution, which would a) significantly reduce the number of polls with "negative" outcome and b) simply reduce the number of polls, making things more manageable. WormTT(talk) 12:57, 3 March 2021 (UTC)[reply]
WP:DESYSOP2019 had some discussion of the concept, mostly in the opposition to statement 8. There was also statement 10, which was withdrawn, possibly too quickly as there was mixed interest. Statement 12 is kind of relevant, but there's not much there as it was largely perceived to be out of scope. But yeah, I don't think it by itself has had the full-blown RfC treatment. ~ Amory(u • t • c) 16:59, 3 March 2021 (UTC)[reply]
WTT, you asked for my input. Be careful what you ask for. You just might get it :)
What problem(s) are solved by this? The proposed problem solved by this is that the community wants a process. Sure, this is a process. But, what problem does it solve? The problem hasn't been identified. There are many problem solving matrices available to inform the discussion. Let's look at the first three listed at Problem_solving#Problem-solving_methods;
GROW model; step 2 is determining the issues and challenges.
The GROW model is perhaps the most relevant to what is here; You've identified "where the client wants to be". The client (the community) wants a community based process to remove administrators. Let's ask some questions to help identify where the problem might exist;
What administrators would stand a chance of being removed that were not removed by ArbCom?
Alternatively, what administrators that were removed by ArbCom would have been removed by this process earlier than ArbCom?
If there is no answer to either of those questions, then where the problem exists has to be identified. These are thorny questions. It would involve actively identifying problematic administrators that exist now, or identifying problematic former administrators and re-opening old wounds. Nevertheless, it has to be done. Otherwise, we are presuming there are active or former admins this process would have solved. To date, nobody has done this homework in any of the processes proposed throughout the lifetime of this project. See Wikipedia:Requests_for_de-adminship#Proposed_processes for previously failed proposals. Wikipedia:De-adminship proposal checklist also makes good reading. I am reminded of the movie Apollo 13 where Gene Kranz says "Let's not make things worse by guessing."
Targets admins we likely need most; As you note, the vast majority of our administrators have been around for 10 years. This is the group of administrators we need most. Yet, this process sets about to go after this group. Of the top ten administrators by deletions who are still active, they have an average time on project of more than 14 years. Between those 10, they've performed 240 thousand deletions. Are we really ready to risk losing those admins?
Doesn't target admins until 10 years; So we have a rogue admin, getting away with misbehavior, but never brought before ArbCom. We have to wait 10 years before we can do something about it?
Net is too wide; Based on this and this, approximately 3.7% of successful RfAs result in an admin being removed for cause. Thus, more than 95% of these reconfirmation RfAs could be targeting administrators for whom there's no need. I'm reminded of the failures of drug testing requirements for people to receive welfare. The cost of the programs vs. the number 'caught' was astronomical. We're asking the community to do an incredible amount of work over a long span of time to catch what is likely a very, very small percentage? That doesn't make sense to me.
RfA is hell - this could be a lot worse; I've long railed against scope issues in ArbCom cases. Many such cases become free-for-alls where people dredge up all sorts of evidence from many years in the past. It's effectively impossible to defend yourself against such onslaughts at ArbCom (a rant for another place). This process makes no attempt at limiting scope at all. In fact, it does the exact opposite and asks contributors to dredge up stuff from ages ago. Quite a few RfAs have tripped and fallen over a single point issue. Rare indeed will be the admin who hasn't made some mistake, some failure, some writing that got misinterpreted over a ten year span. I've had them myself; see 14 June 2011 for one such example. I would never want to relive that, but an admin attempting reconfirmation would have to face such nightmares all over again. This process pretty much demands there be drama and re-opened wounds.
ArbCom is already handling this; As I noted in my oppose to the current RfC, ArbCom has set a very low bar for accepting admin conduct cases. I noted this in the RfAr for the most recent case, in that the bar is effectively non-existent, and ArbCom has voided WP:ADMINABUSE and Wikipedia:Dispute resolution (in so far as it applies to admins). The current situation (only exemplified by the current case, as this has been common practice now for a while) is that if an admin strays but a little, they can be brought before ArbCom because the community supposedly can't handle it (patently false, but this is the ArbCom supported claim now).
That's all I have for right now, only because I've spent two hours on this and need to do other things! :) --Hammersoft (talk) 16:04, 2 March 2021 (UTC)[reply]
Thanks for this. What do you think of my suggestion that we simply add to the auto desysop criteria "or less than 500 edits in the last five years"? That would get rid of a group of admins that Arbcom have no case against, but who are at risk of having drifted away from community norms, and which would include some who are considered by critics of the current system to be "gaming the system" ϢereSpielChequers 16:25, 2 March 2021 (UTC)[reply]
I don't know that such admins generate a problem per se. Even so, if we changed the definition of 'inactive', I don't know that that would address any particular concerns, but what few to whom this would apply. --Hammersoft (talk) 22:17, 2 March 2021 (UTC)[reply]
I fundamentally think that administratorship should not be a lifetime appointment. Heck because this is all virtual there is nothing preventing adminship from being inheritable. Can someone serve us well for a long time? Absolutely. If done right I think a 10 year confirmation would actually be no big deal for most. Best, Barkeep49 (talk) 16:42, 2 March 2021 (UTC)[reply]
Let me address Hammersoft's point number 1. I see this proposal primarily as an accountability proposal rather than a desysop proposal. There are a great many admins (probably in the hundreds) that don't commit sufficiently serious infractions to merit a desysop for cause at Arbcom but who nonetheless often perform either below par or right on edge while performing their admin duties. The proposed system will expose them to periodic, albeit infrequent, scruitiny by the community. I would expect that in most cases a reconfirmation RfA will serve as a kind of a critical community feedback and review forum for a particular admin that will result in a reconfirmation rather than in a denial of a reconfirmation. But providing such feedback is an important goal in and of itself. I believe that many admins, knowing that this process is ahead of them, will become more mindful of their admin actions. There is a potential significant downside that some admins may become gun shy in terms of performing difficult tasks and imposing difficult blocks (e.g. AE). I think it is important to implement sufficient safeguards here. In particular, it should not be a simple vote, and vote eligibility should probably be restricted, maybe significantly. We also have a significant number of admins who are do not actively perform admin tasks. At the moment they are basically useless as admins. Having this reconfirmation procedure in place will give these admins incentive to get involved in using the mop. Nsk92 (talk) 19:30, 2 March 2021 (UTC)[reply]
And there's the presumptions. The presumption that there are several hundred administrators below par performing administrators (for brevity, I'll call these 'bad admins' for the remainder of this post). That's a complete guess, not informed by any data. Build a case based on a guess, and the foundation will crumble.
For the sake of argument, let's say your presumption is correct. In your favor, we can assert 200 as a baseline number (hundredS) of bad admins. Right now, we have 1109 administrators, of whom 502 are active. Again, in your favor, let's presume that the 200 is a portion of total administrators, not active. That means about 18% (200/1109) of the current administrators are bad admins. Now, for some actual known data; of approximately 2175 successful RfAs throughout the history of the project, 81 have been desysopped for cause. That's a rate of 3.7%. If your presumption is correct, there are bad admins at a rate almost 5 times more than we have ever suspected. To me, that seems highly unlikely. But, let's test that hypothesis. I took a look at the last 6 months worth of threads posted at WP:AN. You can verify this yourself if you like; repeatability is the stone foundation on which we should build. I used the (as of yesterday) current WP:AN and archives 324 through 330 inclusive. Across all of that, there were 724 threads. Of those, 314 were closed (43.4%). Of those, there were a total of 5 that concuded with any kind (at all) of disapprobation towards any administrator. I used a very, very loose definition of disapprobation in favor of admin censure, thus this figure favors your position. Over the last six months, we have averaged 507 active administrators. Together, all administrators perform approximately 2430 blocks, deletions, and protections per day (not to mention other admin activities). That's approximately 437 thousand admin actions over the last 6 months. Of those actions, or combined actions to favor you, 5 rose to the level of scrutiny at WP:AN. Let's say with combined actions it's 500 (to wildly favor your argument). Thus, .11% of admin actions over the last 6 months were concerning enough that an administrator suffered disapprobation for their actions at WP:AN. If your figure was correct, it would be more than 150 times as high. We would have seen 150 more threads at WP:AN than we have. Based on actual data, I think it is quite safe to conclude that your presumption of hundreds of bad admins is wholly and completely inaccurate.
So, there you have it. Rather than presumption, if we use actual data to generate real information, we begin to paint a very different picture than one that was presumed. This is the very core of problem solving. You can't just guess. You have to use actual data. If you have a lot of 10,000 parts that you suspect are bad, you can't guess what's wrong. You have to find out what might be wrong and test for that to support it or refute. An enormous amount of people on this project have taken guesses at what is wrong. Virtually nobody has made any effort of any kind to actually put together data. That is why this proposed process is no better than any other of the two dozen other proposed processes that have all failed. This is why Wikipedia:Requests for comment/Desysop Policy (2021) is also a failed proposed process. It's just a guess. We need to stop guessing, most especially when the potential impact of getting this wrong is catastrophic to the project. --Hammersoft (talk) 21:39, 2 March 2021 (UTC)[reply]
I think Barkeep (as usual) gets to the heart of this: it shouldn't be a lifetime appointment. We can have removal for cause (ArbCom, WP:DESYSOP2019), and we can have removal for WP:INACTIVITY, but none of that changes the fact that it shouldn't be forever. ~ Amory(u • t • c) 22:08, 2 March 2021 (UTC)[reply]
Hammersoft (and indeed everyone here), thank you for your time, I wanted a good cross section of individuals who would be interested in actually discussing the matter and I'm really please to see the feedback that has been received. Regarding your points in particular - Point 1) is key and I think many of your points fall by the wayside based on the answer to this. It is not designed as a "community desysop" option to deal with problematic admins - the term length is too long for one, if you have a problem with an admin can you imagine being told "They'll be up for confirmation in 9 years, you can raise your issues then". The problem as I see it is "lifetime adminship" - the idea that once elected, you remain an admin, no matter what changes in policy that you have not followed, no matter what standards for administrators have changed. All you need to do is stay above a minimum threshold. Understanding the problem - this leads to the following plausible issues, which may or may not be true (I understand they are debateable).
Administrators who may not be as familiar with policies, or community feeling, and appear from nowhere to take actions that would be acceptable 10 years ago but are not now.
The long tail tip of administrators who only meet the minimum requirements, and provide very little benefit to the encyclopedia
A misleading idea of how many admnistrators are available to work on administrative backlogs.
Higher standards for administrators knowing that they are appointed for life.
More stressful RfAs based on the "prestige for life" outcome.
I do appreciate that data matters - and I am currently working on producing a list of all administrators, with some information attached to each which will hopefully provide some context to this discussion. Regarding your other points 2) This proposal "goes after" all administrators or none depending on your perspective - it treats everyone equally by expecting them to retain the confidence of the community. 3) This is not intended as a Community Desysop, and not designed to target "rogue admins", but instead intends to ensure that they hold confidence of the community at a general level 4) This is not intended as a Community Desysop and not designed to target "for cause" admins. I would hope that those who do get removed after this process would be able to pass a subsequent RfA, while "for cause" removals have not yet been able to. 5) I'll come back to. 6) Arbcom is not handling four of my five plausible concerns. They are handling the first (unacceptable actions that were previously acceptable), reactively in extreme situations (i.e. where the admin doubles down). This would take a more pro-active approach, nipping such issues in the bud.
No, to your point 5 - I do want more on this. I don't want this process to be hell - I don't want admins to have stuff thrown at them from a decade ago and I understand that this will be a major sticking point for those who might support the proposal. What I'd like to see is safeguards against that. I've focussed on reducing the voice of non-extended confirmed users and those who have been sanctioned by the administrator. I would like to hear of any other ideas that would improve such safeguards. However, I'm also aware that there should be a way to include older information if relevant. WormTT(talk) 10:38, 3 March 2021 (UTC)[reply]
Limiting as you suggest would limit to some degree, but I don't think it would prevent it from being hellish. I don't know how we can include information without including information :) About the only thing I could suggest is that any supposed wrong action that was brought to a noticeboard and where the admin was found not at fault can not be mentioned at the reconfirm. But, that will be difficult. I know you're not intending this as a community desysop, but I think this is how it will be viewed. It's a perspective issue. --Hammersoft (talk) 14:55, 3 March 2021 (UTC)[reply]
Hammersoft, there's a bit of a catch-22! People will view it as something it's not, and it will fail because it's not good enough to do what it's not meant to do! WormTT(talk) 15:04, 3 March 2021 (UTC)[reply]
Looking at it - this is largely my fault. When I started writing, I had one thing in mind, and by the time I finished, I had another - especially since talking to individuals on this page. I've re-written my opening blurb to take the focus away from community desysop and more to what is actually being aimed for. WormTT(talk) 15:12, 3 March 2021 (UTC)[reply]
I've been skeptical in the past about term lengths simply because of the sheer numbers involved, but 10 years is a longer number than I've usually seen bandied about, which helps quite a bit. 1100 sysops total is about nine a month, which is pretty reasonable! As an upper-range, nine is reasonable and would go a long way toward reducing the threshold for acceptance (and overall unenjoyment) at RfA in general. I still think there are some concerns around that, as while nine a month may be 2011/2012-era rate, we don't have any evidence the RfA community can go back to handling that kind of load (of note: this means watchlist notices will be no more).That being said, almost by definition current sysops are guaranteed to have at one point been qualified to be sysops. That survivorship bias means the success rate of these RfAs is likely to be higher than the historical average; 2011 may have handled 140 requests, but 45 (32%) of those were SNOW or NOTNOW closures. That probably means less work for all participants than the current average RfA, but it does mean a change in what WP:RFA looks like. Probably for the better.An 18 month lead-in is good, but that means jumping into a sustained rate of 60/month right off the bat. Maybe spreading that initial group out over two years would be better, or even longer, so as not to overwhelm the system at the start? Further, it needs a way to incorporate that initial batch into the system after their first poll, otherwise there's a big, long surge every cycle. If that initial initial batch is spread over five years (instead of 18 months) for the first go-round, we can then take half of those to be nine-year appointments rather than ten, and then we're done. Complicates the math, but not hard for a bot.Some language suggestions and questions:
Adminship on wikipedia should not be a lifetime status and should be reviewed at fixed intervals. reword to Adminship on Wikipedia is not a lifetime status and is reviewed at a fixed interval.
After a period of 10 years, administrators should either submit a "Poll to retain adminship" to confirm that they retain the confidence of the community, or request removal of their administrator user-right. reword to something like After a period of 10 years following the closing of their last successful request, administrators must either submit a "Poll to retain adminship" to confirm they retain the confidence of the community, or request removal of their administrator user-right.
The administrator will require 60-65% support in the poll to retain their user-right, subject to the discretion of bureaucrats. I'm not certain what "subject to the discretion of bureaucrats" means. I think you're suggesting:
<60: 'Crats must close as unsuccessful
60-65: 'Crats use their God-given consensus-determining skills
>65: 'Crats must close as successful
Likewise, I think Polls will be moderated by the bureaucrats needs a different word than "moderated" since that's not really a term we use here. I've long been an advocate for a somewhat stronger/quicker clerking touch by the crats at RfA, but are you suggesting something beyond that? There will need to be if discussion is left off, since long vote comments may need to be trimmed.
a very short statement and questions / discussion limited I think should be ...statement with questions...
Editors who have not achieved "extended confirmed" status Just say "Non extended confirmed editors" or "Editors who are not extended confirmed"
considered as giving up their user-rights voluntarily and may subsequently submit a poll when they are ready This is the RfA-lite poll or another RfA? I think you're saying "this process until/unless they reach inactivity requiring a new RfA" is that right?
Sorry if all this is a rambling brain-dump, just what jumps out at me at first while prepping dinner. ~ Amory(u • t • c) 22:24, 2 March 2021 (UTC)[reply]
Thank you Amory, I'll use the copy editing presently. I've never been the best writer, so this is very helpful. To your other points - 1100 admins over 10 years may be equivalent to nine per month, if the appointments had been spread evenly over the past 10 years. However, they have been spread over a longer period, with a heavy weighting to the 2005-2008 (see WP:RFA by month) so we're going to have to spread these out.
Even spread out, if all these reconfirmations were standard RfAs, I agree that the community would not have capacity for them. Hence the need for the "RfA lite" process, in a separate area of the RfA page. RfA is already well watched and therefore makes sense to be included but these polls should not be considered RfAs. Firstly, the individuals has already past an RfA, and secondly, they have been doing the job for 10 years. Their actions should speak in part for them - so hypothetical questions are less necessary.
I chose 18 months spread as I felt 15 "lite" polls per week would be manageable, while giving a reasonable psychological end date - "end of next year". I think that 2 years could work too, but I am concerned that spreading it much further (say 5 years) will be discouraging. It's difficult to plan 5 years in the future, and I believe that putting in a plan that covers the period to 2025 will be met with much disagreement. What's more, I believe there is an element of "safety in numbers", and a larger flight of candidates will reduce the focus on individual reconfirmations, in effect it's an additional safeguard.
The surge cycle will be less of a problem than it first appears. For one, this policy shift will reduce the admin corps - many in the "inactive" category will chose not to run. So we may find a reduction by up to half. We're spreading the remaining admins across 75 weeks. 10 years down the line, many of the administrators who have passed their reconfirmation will have left the project - natural attrition will have reduced the number. So any remaining surge in 10 years time will be manageable.
Regarding the numbers, I meant to mirror the RfA percentages (i.e. most pass, most fail) rather than "must pass, must fail", giving the 'crats leeway to manage apparent votestacking or late vote changes based on the talk page. If you have a better way of writing that, I'd be interested.
My intention was that a "short statement" could be made, with a link to talk page, and 'crats would enforce that. I'll again put together an example poll to hopefully help explain. WormTT(talk) 11:09, 3 March 2021 (UTC)[reply]
Yeah, I don't really disagree with all that, just trying to see potential pitfalls. I really have no idea what to expect in dropoff, but I suppose a hundred or so from not running plus some removals is reasonable. One other thought — is it worth having a minimum length? I don't really think so. I think the edits you made re "clerking" and support ranges are fine and good, more discretion is a boon, especially to encourage the "light" RfA style. I like the example! ~ Amory(u • t • c) 12:08, 4 March 2021 (UTC)[reply]
Amorymeltzer, minimum length? As in - shortest period between polls? I don't think so - indeed, I would personally be putting myself up for reconfirmation on 5 yearly cycles (and hope others would too) - it would be good if admins could chose their own reconfirmation period, up to the maximum of 10 years. Indeed, if this goes well, I could see fresh RfAs having a reconfirmation after a short period (say 1 or 2 years), before their 10 year cycle begins, which I think will alleviate a lot of hesitance at RfA - but that's all ideas for the future. WormTT(talk) 12:53, 4 March 2021 (UTC)[reply]
Same — I think it'd be good across the board. Was brainstorming a theoretical: if someone at the, say, 9-year mark knew they'd be going inactive for a bit might be incentivized to go up then rather than go at 10, and whether we'd want to discourage that. I think we've seen from the current community proposal that having flexibility in when such things get put up is a positive, and, more to the point, wouldn't want someone unnecessarily antagonized on a strict schedule for no reason. ~ Amory(u • t • c) 20:08, 4 March 2021 (UTC)[reply]
@Worm That Turned: this is currently running 20/59/3. It's been open long enough to add to the watchlist notice, which will likely result in more participants. Do you envision this closing early such that WL should be skipped? — xaosfluxTalk 01:02, 13 March 2021 (UTC)[reply]
Xaosflux, I'm less familiar with the requirements for a watchlist notice, however I don't really see the need for it. I believe there is still good and useful discussion at the RfC so do not intend to withdraw it at present, but I do think the basic question has been answered WormTT(talk) 09:09, 13 March 2021 (UTC)[reply]
@Worm That Turned: there was a request to list it as we listed the other admin RfC (MediaWiki_talk:Watchlist-messages#ADMIN_terms_and_polls) from @ProcrastinatingReader:. Generally, policy changes that can have an impact on a large number of editors are included on the WLN to ensure that the proposal has been widely advertised (with the hope that it will also be widely attended and participated). I deferred the request to make sure this wasn't going to WP:SNOW first, and while I don't think it is in a snowball closing state, respectfully, I don't think it has much of a chance of passing from a numeric standpoint. Discussion could still lead to useful ideas, even if this specific proposal doesn't pass, so there is no requirement to shut it down. So what does this distill to: if you think this could still pass in some form, we should list it, else skipping is fine to avoid banner fatigue in other editors. Best regards, — xaosfluxTalk 10:41, 13 March 2021 (UTC)[reply]
Xaosflux, I don't expect it to pass, and see no need to list it. WormTT(talk) 16:26, 13 March 2021 (UTC)[reply]
