Wikipedia:Requests for comment/2019 Resysop Criteria (2)

In October 2019 the first part of a two part Request for Comment was closed with a community consensus in favour of developing a stricter criteria for restoration of administrator status after a desysop for inactivity.

The first RfC stipulated that if it closed with a consensus for a stricter criteria there would be a second RfC. This RfC will follow the endorsement of statements model, with users being able to put forward multiple proposals to be considered by the community. TonyBallioni (talk) 00:18, 6 October 2019 (UTC)

Statements

Summary of Statements

1. Y Before restoring the administrator flag a bureaucrat should be reasonably convinced that the user has returned to activity or intends to return to activity as an editor
2. N Before restoring the administrator flag a bureaucrat should be reasonably convinced that the user retains the trust of the community to serve as an administrator.
3. Y Should there be doubt concerning the suitability for restoration of Admin permissions, the restoration shall be delayed until sufficient discussion has occurred and a consensus established through a Crat Chat.
4. N As part of the request for resysop, the returning administrator should indicate what actions they intend to do with the permissions. Bureaucrats shall be empowered to consider the assertion and any previous assertions.
5. N Adminship will not be restored after 5 years for those who resigned without a new RfA. (this is in addition to the 3 year inactivity rule).
6. Closed
7. Y Change second bullet of WP:RESYSOP to Over two years with no edits. If an editor has had at least two years of uninterrupted inactivity (no edits) between the removal of the admin tools and the re-request, regardless of the reason for removal, the editor will need to instead request through the WP:RFA process. In the case of an administrator desysopped due to a year of inactivity, only one year of continued uninterrupted inactivity (no edits) from the removal due to inactivity is required before a new WP:RFA is necessary.
8. N Any former admin who has been inactive for more than two years will be re-sysopped on request after a period of normal editing proportional to their length of inactivity. If N years have passed since desysopping, the former admin should edit for N months, making 50 non-stupid (i.e., constructive edits that are not clearly made to inflate edit count only) edits each month. After the N months have passed, they will be re-granted admin status by request on WP:BN (subject to the normal exclusions).
9. N Users requesting restoration of sysop flag after being desysoped for inactivity will be requested to state the frequncy of admin actions which they intend to take if the tools are restored to them. If the stated anticipated level is not significant, or if the Bureaucrats do not find the statement credible in view of past history, they may decline the request. Ihe request is declined a user may repeat the request after a period of editing, or may seek appointment via a new RfA.
10. Withdrawn
11. Withdrawn
12. N Admins making clearly minimal edits to keep their advanced permissions and Users that have been desysopped through lack of activity and have their permissions returned uder the conditions of WP:RESYSOP by the WP:CRATS and then continue to have no or minimal activity can be subject to a community discussion and removal of those permissions if such a consensus arises. If removal occurs any further request for resysop would require a WP:RFA. Any Admin supported in the discussion would restart the clock as far as WP:RESYSOP is concerned.
13. N Instead of trying to find ways of restricting people from keeping the sysop bit, the focus should be on figuring out how to get more (competent) people to apply for and pass RfAs.
14. YGiven that non-admin users, including some of the community's most respected, voted 39-8 that our resysopping policy needs tightening, we recognize the RfC results represent an actual problem the community needs to find consensus to address.
15. N Wikipedia should not be in the business of writing processes to avoid the stupid thing Bob did once. Any proposed solution must first require credible evidence of both a problem that it would have fixed, and the absence of any simpler or more efficient way of fixing that problem.
16. Withdrawn
17. Withdrawn
18. N Proposals that receive some form of net support in this RfC should be taken to a workshop/dedicated stage to refine details and consensus.

Implementation

Statements #1 and #3 have been added to both WP:ADMIN and WP:RESYSOP.[1][2] In addition, the inactivity threshold has been amended from three years to two years, according to Statement #7.[3][4] — JFG ^talk 22:30, 5 November 2019 (UTC)

Statement 1 by TonyBallioni

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Before restoring the administrator flag a bureaucrat should be reasonably convinced that the user has returned to activity or intends to return to activity as an editor.

Users who endorse statement 1

1. This seemed to be the direction the first RfC was heading in the discussion section, and I like it. It gives bureaucrats the discretion to turn down some of the most ridiculous resysop requests, while also incentivizing users who have been gone for extended periods to return to activity before requesting, or even after they have been turned down initially. It would not put a hard stop of someone from returning based on arbitrary numbers, and I think we could trust our 'crats to use their judgement as to what is a reasonable standard to hold people to here. TonyBallioni (talk) 00:03, 6 October 2019 (UTC)
2. – John M Wolfson (talk • contribs) 00:55, 6 October 2019 (UTC)
3. – bradv🍁 01:32, 6 October 2019 (UTC)
4. * Pppery * _{it has begun...} 01:33, 6 October 2019 (UTC)
5. SQL^{Query me!} 01:33, 6 October 2019 (UTC)
6. Tentatively endorse the statements, but I have a couple of questions regarding the nitty-gritty of the policy that I'm going to go raise in the comments section. creffett (talk) 01:35, 6 October 2019 (UTC) (edit: re-endorse following TonyBallioni's "has returned or intends to return" change creffett (talk) 03:21, 6 October 2019 (UTC))
7. ST47 (talk) 01:44, 6 October 2019 (UTC)
8. CThomas³ (talk) 01:53, 6 October 2019 (UTC)
9. Giving crats a little bit of discretion over resysops is sensible (that's why they're appointed, after all). I prefer this approach to setting hard-and-fast rules. – Joe (talk) 11:19, 6 October 2019 (UTC)
10. This makes complete sense. If a crat doesn't think the editor actually is going to EDIT -- that is, they just want to keep their flag just because -- then OF COURSE they shouldn't keep it. Honestly if the first edit someone has made in three years is the request for the flag, it immediately makes me wonder. If the reason they've kept the flag at all was because they log in to make a couple edits every time they get a desysop warning and oops, this time they forgot to do so, then no, they shouldn't be resysopped. It's absurd. --valereee (talk) 13:06, 6 October 2019 (UTC)
11. I've seen many absent admins just making one edit in time to retain their bit. Being an admin is no big deal and not being an admin is no big deal - unless it's something to brag about in the schoolyard or in the office. Kudpung กุดผึ้ง (talk) 17:26, 6 October 2019 (UTC)
12. This strikes me as being the clearly intended spirit of the resysop process. Thryduulf (talk) 17:50, 6 October 2019 (UTC)
13. Yes. This should be a minimum. Jbh ^Talk 07:07, 7 October 2019 (UTC)
14. There's no reason why editors should regain the tools if they are not intending to be active. Crats should be able to use their judgement to determine how to apply this.-gadfium 08:37, 7 October 2019 (UTC)
15. Lukewarm endorse. I generally don't think the system is broken as it is, but see the rationale for insisting return to admin should require engagement as an editor. I'd be willing to support a modest bright-line activity requirement (e.g. active for a month), so also willing to support bureaucratic discretion in this direction. Martinp (talk) 17:06, 7 October 2019 (UTC)
16. Let's clean out the "fake" administrative accounts who only do token edits to retain tools. Do the job or stand aside. Don't pretend to come back to relaunch a "fake" administrative account. Carrite (talk) 19:49, 7 October 2019 (UTC)
17. This should be obvious, but it does need to be paid out in text to be enforceable. I endorse this as an absolute bare minimum of a change. — Jkudlick ⚓ t ⚓ c ⚓ s 03:26, 8 October 2019 (UTC)
18. Why else would you benefit from the tools? feminist (talk) 04:28, 8 October 2019 (UTC)
19. Encourages editor participation. The additional activity from editors who would be motivated by this requirement is likely to outweigh any lost activity from inactive administrators who would not. — Newslinger talk 10:44, 8 October 2019 (UTC)
20. I'm not hugely weakly in favor of this, but I think it's a net positive. It would give bureaucrats a little more discretion and leeway, and would likely lead to some more discussion amongst themselves. I'd worry it will turn into an opportunity for the community to ask a number of (possibly aggressive) questions of the returning sysop, thus turning things away from no big deal, but the reality is probably closer that folks reading this as a requirement will self-select or wait until somewhat more active before submitting a request. ~ Amory (u • t • c) 10:11, 10 October 2019 (UTC)
21. FASTILY 23:28, 11 October 2019 (UTC)
22. Pharaoh of the Wizards (talk) 23:40, 11 October 2019 (UTC)
23. Conditional support - only if proposal 3 gains consensus. In most cases this new clause does nothing (e.g. the sysops who stepped down because of FRAM would not be impacted by this in the least). But at the edge I would prefer the crats to act as a body rather than individuals in these resysops. That said some feel free doesn't actually change anything and so this with 3 hopefully makes clear what has changed. Best, Barkeep49 (talk) 13:57, 12 October 2019 (UTC)
24. I'm joining the gang of "this would be be non-ideal, vague, but a net-positive". If nothing else, I think it would encourage returning admins to take more effort, and those who aren't really returning just yet (but are holding on "in case" (not for a negative reason)), not to request it. It's worth noting that a rejection under this wouldn't prohibit a new request, say, 2 months later. Nosebagbear (talk) 17:37, 12 October 2019 (UTC)
25. This proposal would give BN crats a mandate to politely refuse requests from apparent hat collectors. Returning admins should demonstrate a need for use of the tools, so at least those with no obvious need could be discreetly weeded out by crats without consuming community effort. Obviously, a former admin rejected at BN is free to apply for an RfA, and should be treated just the same as other applicants. — JFG ^talk 00:05, 14 October 2019 (UTC)
26. I think this is a good balance to strike. It keeps people from keeping the flag indefinitely but otherwise remaining inactive, but also doesn't discourage former admins who genuinely want to return to the project. We all have real lives, and sometimes that means we take a break from Wikipedia with every intent to return, but there's nothing wrong with asking someone to be back around for a bit before we hand them the keys again. Seraphimblade ^{Talk to me} 03:43, 14 October 2019 (UTC)
27. Yup, per Thryduulf. Happy days, Lindsay^Hello 08:02, 14 October 2019 (UTC)
28. ~ ToBeFree (talk) 13:27, 14 October 2019 (UTC)
29. Thought I signed this earlier. —Cryptic 21:15, 14 October 2019 (UTC)
30. -- œ^™ 05:05, 16 October 2019 (UTC)
31. Agreed. We should have empowered our bureaucrats to use their best judgment in regranting the flag from the start. OhKayeSierra (talk) 07:25, 16 October 2019 (UTC)
32. Agree. In general, I support less overall bureaucracy where not needed. People who passed RFA shouldn't need additional scrutiny, and we specifically select bureaucrats to be people we trust to have the discernment to make these decisions. --Jayron32 17:58, 16 October 2019 (UTC)
33. Pawnkingthree (talk) 20:24, 17 October 2019 (UTC)
34. Support both this and the one below it, but merge them into a single sentence to not be redundant.  — AReaderOutThataway ^t/_c 06:41, 22 October 2019 (UTC)
35. Support A simple and reasonable balance. The crats can judge this without need for numerical rules. We trust them , and rightly so, for resolving the most disputed AfDs; we can certainly trustthem for something as straightforward as this. DGG ( talk ) 17:28, 22 October 2019 (UTC)
36. Agree This should be a minimum starting point.--Cube lurker (talk) 17:14, 31 October 2019 (UTC)
37. We don't want hat collectors in the town. -- CptViraj (📧) 03:39, 4 November 2019 (UTC)

Users who oppose statement 1

1. Oppose, a misguided and unnecessary proposal. First, there is no evidence that the current process is being abused. Where are any examples of the "most ridiculous resysop requests" that the proposer mentions? Second, the proposed standard "a bureaucrat should be reasonably convinced that the user intends to return to activity as a sysop" is impossibly vague, arbitrary and subjective. A crat does not have a crystal ball, and in general there is no way to make predictions about the level of future activity for someone who is just returning from a period of inactivity. There are also various potentially problematic privacy issues here. Inactivity, by admins and regular users, is often caused by complicated real life issues, such as medical, family, job and other personal problems. We should not be placing extra pressure on returning admins in explaining and disclosing such personal issues. Worse yet, it is unclear what level of expected future activity is supposed to be sufficient here. The proposed change is just an invitation to endless drama, wikilawyering, infinitely long contenious threads, etc. We have enough of that in the RfAs and turning WP:BN into a perpetual drama fest would be a major step backwards. If people really want stricter resusop standards, introducing some formal well-defined limitations would be much better (such as limiting the number of times someone can be resysopped after being desysopped for inactivity, and/or limiting the period of time after which one can request a resysop after an inactivity desysop). Nsk92 (talk) 00:56, 6 October 2019 (UTC)

   Nsk92, then it would be helpful for you to propose what you think reasonable objective criteria are. The community already has expressed its opinion that the current process is broken in the first part of this RfC linked to above. The format of this part is intentionally designed to allow people propose multiple criteria. I believe a subjective one is better than an objective on in this case as it allows people to return to activity and request a resysop even if they've previously been turned down. I'm sure there are other criteria that I'd also support, but having a more subjective one seemed to have some support in the last RfC. TonyBallioni (talk) 01:01, 6 October 2019 (UTC)

2. Oppose, People wanting to regain sysop should have a plan in place for what they intend to do admin wise if re-opped. Burecrats should look at the previous history to see if previous plans were adhered to. Hasteur (talk) 01:56, 6 October 2019 (UTC)

   Uh, that's what this is saying... TonyBallioni (talk) 02:00, 6 October 2019 (UTC)

   @TonyBallioni: modified to indicate that we want to know what they're going to do with those permissions so we can evaluate the the effictiveness of the re-grant. Hasteur (talk) 02:04, 6 October 2019 (UTC)

   Quite frankly, I don't think such a strict statement could get consensus, and my policy is always to propose things that I think can gain consensus. Also, just a comment to the format of this RfC: I chose the older statements method to encourage people to think about solutions rather than binaries. I think your proposal might be worth making on its own, but based on what you are saying, I don't think it's a good reason to oppose this as it goes a lot of the way to what you want. As for this proposal, I think if someone hasn't edited in 2.5 years and their last admin action was 4.5 years ago, crats would naturally ask the questions you are suggesting. TonyBallioni (talk) 02:09, 6 October 2019 (UTC)

3. I agree with Nsk that asking a person to be "reasonably convinced" of another person's intention to do something in the future is pointless: the standard is impossibly vague, arbitrary and subjective. How convinced is "reasonably convinced", and what if a crat is easily convinced? Then they'd have a lower standard than the next crat. How does a crat determine the admin's intention? Peering into the soul? A thorough investigation? What are we asking of crats here, exactly? And even if the crat is thoroughly convinced that the admin intends to be active, so what? Life can change that at any minute. I don't think this particular addition would fix anything; it would just give crats an excuse for not returning the bit ("not convinced they intend to be active"). – Levivich 03:29, 6 October 2019 (UTC)

   It's a reasonable person standard. The standard that is used in every court in the English-speaking world. TonyBallioni (talk) 03:38, 6 October 2019 (UTC)

   I'm not trying to be a smart-ass - but, WP:NOTCOURT is the first thing that comes to mind. — Ched (talk) 04:12, 6 October 2019 (UTC)

   Sure, but that wasn't my point that 'crats are judges, they aren't: it's more of that we regularly accept "reasonable" as a judgmental standard in real life for when people have to make judgement calls. It just means it can't be a faint hope of eventually being active, and on the flip side, it can't be beyond all shadow of a doubt like your comment below seems to read it as. It just needs to be reasonable. What that means depends on the judgement of the people we've trusted to make these decisions. TonyBallioni (talk) 04:30, 6 October 2019 (UTC)

4. Oppose There is no possible way for one editor (crat or not) to determine intent of another user. We don't have crystal balls. — Ched (talk) 03:30, 6 October 2019 (UTC)

   Perhaps not, but one certainly can observe a return to activity over a trial period. That would be proof enough of intent for me. One situation I would prefer to avoid is the case where a former admin comes back and immediately asks for the bit, only to make a couple of edits and then go inactive again. CThomas³ (talk) 05:02, 6 October 2019 (UTC)

   If we want to institute minimum activity levels before a resysop, we should just institute minimum activity levels (like with specific numbers), rather than ask crats to do it for us, basically. This isn't a situation where we want to go case-by-case. We want crats to measure activity (maybe), but not to make a value judgment about whether someone is active "enough" to indicate that they'll keep being active "enough" (whatever "enough" may mean). – Levivich 05:30, 6 October 2019 (UTC)

   I would be happy with something like that, but I also don't want perfect to be the enemy of good. This is a step in the right direction, for sure, and it doesn't exclude adding activity minimums at some point in the future. CThomas³ (talk) 17:45, 7 October 2019 (UTC)

5. Oppose the request, or intention to accept is enough of an intention to use it again in the future. A hardly used sysop bit is still a welcome hand, and a not-used sysop bit does not make the encyclopedia worse (though arguably also not better). Unless there is reason to believe that the sysop bit will cause harm to Wikipedia there is no reason not to give the bit even if it one knows it is going to be unused. --Dirk Beetstra ^{T C} 08:29, 6 October 2019 (UTC)
6. Oppose It's hard to judge exactly what someone intends. The best way of finding out is by re-sysopping and seeing what happens. Κσυπ Cyp   09:42, 6 October 2019 (UTC)
7. oppose, too hard to judge intent. If we want activity before resysop, that should be clearly stated and not bureaucrat discretion. —Kusma (t·c) 13:04, 6 October 2019 (UTC)
8. Oppose as pointless per others above and below. · · · Peter Southwood ^(talk): 14:09, 6 October 2019 (UTC)
9. Oppose Too Vague, too much discretion. Besides, the point isn't the intent to edit, the point is the credible intent to make use of the tools, that is to perform admin actions. An active editor who doesn't use the tools doesn't need them. DES ^(talk)_{DESiegel Contribs} 16:48, 6 October 2019 (UTC)
10. Oppose This would greatly change the Crats mission, which as I understand it is to be clear and cool interpreters of policy. — Preceding unsigned comment added by Govindaharihari (talk • contribs) 15:09, 7 October 2019 (UTC)
11. Oppose highly subjective. Also goes contra to WP:AGF. Cas Liber (talk · contribs) 01:21, 8 October 2019 (UTC)
12. Oppose - seems like a solution in search of a problem. I haven't seen any evidence that former admins are frequently requesting their admin bit back without the intention to do anything with it. ‑Scottywong| [squeal] || 22:17, 8 October 2019 (UTC)

    Oppose - don't want the Crats doing that. Govindaharihari (talk) 23:55, 8 October 2019 (UTC)

    @Govindaharihari: It looks like you already opposed this statement in #10. — Newslinger talk 00:16, 9 October 2019 (UTC)

    Omg yes , sorry, please let me rmove one Govindaharihari (talk) 00:24, 9 October 2019 (UTC)

    No problem. I've indented this. — Newslinger talk 00:47, 9 October 2019 (UTC)

13. Oppose. This actually reduces 'crats' existing discretion to refuse resysop, and adds process to fix a problem whose existence is not clearly demonstrated. Guy (help!) 21:36, 9 October 2019 (UTC)

    JzG, can you give an example of where the crats exercised discretion in this area which this proposal would prevent? What I'm aware of suggests to me that crats don't have discretion and so I would be interested in a counter example. Best, Barkeep49 (talk) 00:46, 10 October 2019 (UTC)

14. Oppose per Guy. Buffs (talk) 16:05, 10 October 2019 (UTC)
15. Oppose - Haven't seen enough evidence as a problem caused by resysopping that isn't caused by existing admins (i.e. to the extent there's a problem, afaict, it's about the difficulty deadminning, not specific to readminning). — Rhododendrites ^talk \\ 17:00, 10 October 2019 (UTC)
16. Oppose per Nsk92's impossibly vague, arbitrary and subjective —comrade waddie96 ★ (talk) 13:43, 12 October 2019 (UTC)
17. I agree with the ″vague, arbitrary, subjective″ argument above. Rather than endlessly apply bandaids to an already needlessly complex policy, just raise the bar to 10 edits or logged actions per year. Or 50. And please don't empower the endless bureaucratic naval gazing that happens at BN already. -- Ajraddatz (talk) 13:50, 16 October 2019 (UTC)
18. Oppose - bureaucrats ought not to base decisions on subjective criteria. Either an inactive administrator meets the objective criteria for resysop, or they do not. Ivanvector (^Talk/_Edits) 15:19, 16 October 2019 (UTC)

Discussion of statement 1

I wholeheartedly disagree with the wording as written. It should say, "...return to activity as an editor." Adminship is not a big deal, and we shouldn't judge peoples' trustworthiness by how often they plan on pushing the block or delete buttons. Even an admin who only makes one "admin action" per month is still reducing the overall admin workload by 12 actions per year. Reaper Eternal (talk) 00:50, 6 October 2019 (UTC)

Reaper Eternal, changed with your suggestion. Agreed with your statement above. TonyBallioni (talk) 00:52, 6 October 2019 (UTC)

A couple of things I'd like to hear thoughts on (they don't necessarily need to be written into this change):

• What recourse does a former admin have if a bureaucrat declines under this policy? Is the expectation that they will have to go through RfA to regain their bit? My concern here is that the existing criteria to decline are pretty objective (time without edits, time since last tool use are completely objective, "under a cloud" is pretty clearly spelled out, "concerns about security of account" probably wouldn't be solved by a new RfA). In contrast, "I don't believe they're going to return to active editing" strikes me as a rather subjective judgment call.
• a bureaucrat should be reasonably convinced - what if there's a disagreement among bureaucrats? Are we expecting consensus among them (cratsensus?), or is convincing one sufficient?

I'm not really expecting either of these to be huge issues if this change is implemented, but I'd like to think these things through before the policy is changed. creffett (talk) 01:48, 6 October 2019 (UTC)

• • I think I answered this in part below (sorry for responding to others first!) but I worded it this way intentionally as to allow people to request it back after returning for a while if they were told no the first time. The recourse is just to return to editing. As for the second, I think they de facto do many crat chats now, but one of the other proposals addresses this quite nicely, I think. TonyBallioni (talk) 03:26, 6 October 2019 (UTC)

I'd like to see some kind of requirement for demonstrated activity (say 30 days or so) rather than simply "convinced" but I'm okay with giving the 'crats discretion here. CThomas³ (talk) 01:53, 6 October 2019 (UTC)

Like Cthomas3, I'm in favor of demonstrated activity. The "intends to return to activity as an editor" statement is fine as a statement of principle, but I can't support putting that into policy as-is - it jumps all the way from the current model where there's no leeway for bureaucratic evaluation at all, to giving them complete discretion to force a new RFA on a vague feeling with no evidence one way or the other. —Cryptic 02:36, 6 October 2019 (UTC)

It actually wouldn't force a new RfA. I intentionally phrased it that way so someone who was turned away could come back after a month or two of activity, since my assumption is that a reasonable crat would call that good. TonyBallioni (talk) 03:00, 6 October 2019 (UTC)

Then say what you mean, perhaps "...that the user has returned to activity, or intends to." That would also be better guidance for the returning admin: it emphasizes to them that their first priority should be to edit, rather than to convince the bureaucrats. Especially with the calls for a cratchat in statement 3 below, I can very easily see the current version of this statement becoming a practice where your example returnee's second request would be met with "we just had a huge discussion a month ago about this", if not from the crats themselves then at least from the peanut gallery. —Cryptic 03:10, 6 October 2019 (UTC)

I don't see that as a material change, so I'll go ahead and tweak it if you think it adds clarity. To me, if someone has already returned to activity it shows that it's something they intend to do in the future. TonyBallioni (talk) 03:15, 6 October 2019 (UTC)

pings to @John M Wolfson, Bradv, Pppery, SQL, Creffett, ST47, and Cthomas3: TonyBallioni (talk) 03:18, 6 October 2019 (UTC)

I agree that editors should return to editing first, and then ask for the bit back. Having said that, I don't think resysoping should be that big a deal and I believe it should be fairly "automatic" once some consistency in new activity is achieved (in the absence of a cloud, of course). I acknowledge that I'm being rather vague here myself, but those are my two cents. – John M Wolfson (talk • contribs) 03:57, 6 October 2019 (UTC)

I agree, unless some serious competence or other issue arises during the trial period. CThomas³ (talk) 05:04, 6 October 2019 (UTC)

• This is in the right ballpark but misses the pitch. First, it requires a bit of mind reading on the part of crats that is at some level probably incompatible with AGF. They essentially have to call someone a liar in order to not return the bit.

Second, intent, even genuine intent need not correspond to action. I have genuinely intended to clean out my basement for the past several months, but that doesn’t mean I’ve managed to make time for it or have concrete plans to do so in the immediate future. At the end of the day I have other obligations and intents that have wound up higher on my priority list.

Overall, the issue isn’t necessarily that returning admins get desysoped for cause, or don’t make productive contributors in due time. The issue is that they as often as not bungle about for six to ten weeks not understanding basic policy (often with their sense of self-importance unaffected), and only then do they get up-to-speed after being a bother to a lot of people for no real reason.

We ought not ground our policy in hopes and dreams and intentions. What we need to require is that returning admins reasonably reengage with the project prior to requesting the tools, let them bungle about for a while and let them get it out of the way, and once they catch up, then they can get the bit back. If you can’t be bothered to reengage now, then you don’t need the tools returned now anyway. (And no, we ought not allow for 30 days, 413.5 edits, and a partridge in a pear tree. “Reasonable reengagement” subject to the discretion of crats is perfectly acceptable and unlikely to be gamed.) GMG^talk 06:20, 6 October 2019 (UTC)

• If an admin has made one edit in each of the past six years and this year made zero edits and is now requesting their flag back, I think a bureaucrat can probably reasonably judge their intent. --valereee (talk) 13:09, 6 October 2019 (UTC)

  It probably is "keep admin bit for the short term so I can use it at an unspecified time in the future", and I'm not sure I understand why that is seen as so problematic. I don't think there are many people who try to keep the admin bit while intending to never return to editing. From my own experience, I have intended to become more active than I was for about half of the last ten years, but haven't always succeeded. I can easily imagine people editing less than I did while still hoping to return to productive editing / adminning when circumstances change. —Kusma (t·c) 15:14, 6 October 2019 (UTC)

Nsk92, see the resysop request I linked to in statement ten for an example of a most ridiculous request. The user had been absent for ten years, with fewer than 25 edits during that period. They'd been completely absent for the past three years, made one edit in July, and ten minutes later requested resysop. They've made two edits since. This was one of the reasons for the original RfA on this issue. --valereee (talk) 09:20, 9 October 2019 (UTC)

• If we have this, I think bureaucrats should have three options to answer a resysop request: yes (resysop after 24 hours), no (you must go through RfA) and not now (come back when you have convinced us you are indeed returning to editing). —Kusma (t·c) 11:02, 10 October 2019 (UTC)

  That third option makes sense, and that's how I'd expect crats to react to good-faith requests in which the former admin has very little recent activity. — JFG ^talk 00:05, 14 October 2019 (UTC)

• There have been comments that this is to subjective. But a proper judgment of something like this needs to be subjective; it's likely to be more rational than a numerical standard, even if we could get agreement on any one numerical standard. DGG ( talk ) 17:33, 22 October 2019 (UTC)

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

Statement 2 by Bradv

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Before restoring the administrator flag a bureaucrat should be reasonably convinced that the user retains the trust of the community to serve as an administrator.

Users who endorse statement 2

1. Per my comments in the previous RfC, bureaucrats are occasionally asked to give returning users a level of access that does not match the level of trust that the community has in them. This change would allow bureaucrats to exercise their discretion and take a wider variety of factors into account when deciding whether to restore the bit. – bradv🍁 01:28, 6 October 2019 (UTC)
2. I'm fine with this as well, and I don't see it as being in opposition to the one I proposed above. I think both could gain consensus. TonyBallioni (talk) 01:31, 6 October 2019 (UTC)
3. SQL^{Query me!} 01:33, 6 October 2019 (UTC)
4. Support both. – John M Wolfson (talk • contribs) 01:36, 6 October 2019 (UTC)
5. Support this as well as #1. CThomas³ (talk) 01:56, 6 October 2019 (UTC)
6. Heartily Endorse as this is critical for what I have observed in some of the marginal resysops. Hasteur (talk) 02:06, 6 October 2019 (UTC)
7. Works well with statement 1. – Joe (talk) 11:20, 6 October 2019 (UTC)
8. --valereee (talk) 12:59, 6 October 2019 (UTC)
9. I don't see much difference between this and Statement 1. Kudpung กุดผึ้ง (talk) 17:28, 6 October 2019 (UTC)
10. I cannot see any downsides to this. In the event the crats decline to resysop someone against the wishes of the community they should have no trouble at all passing an RFA. Thryduulf (talk) 17:52, 6 October 2019 (UTC)
11. Yes, although I would like to see something that both explicitly directs the bureaucrats to direct the cases to a new RfA and states a bias for not restoring the bit if there is any 'reasonable' cause to suspect that there may have been a loss of community trust. Jbh ^Talk 07:10, 7 October 2019 (UTC)
12. This seems to go without saying, which is why we should say it. Carrite (talk) 19:50, 7 October 2019 (UTC)
13. Again, this should be obvious but needs to be spelled out. — Jkudlick ⚓ t ⚓ c ⚓ s 03:31, 8 October 2019 (UTC)
14. Per Thryduulf. feminist (talk) 04:29, 8 October 2019 (UTC)
15. Allows bureaucrats to make a thoughtful assessment when there are valid concerns, instead of having to rubber-stamp the request. — Newslinger talk 10:51, 8 October 2019 (UTC)
16. FASTILY 23:28, 11 October 2019 (UTC)
17. Support discretion should be utilised when restoring admin flag. —comrade waddie96 ★ (talk) 13:44, 12 October 2019 (UTC)
18. ~ ToBeFree (talk) 22:13, 14 October 2019 (UTC)
19. Not in contradiction with Statement 1, and seems to be almost self-evident. Happy days, Lindsay^Hello 12:34, 15 October 2019 (UTC)
20. -- œ^™ 05:05, 16 October 2019 (UTC)
21. Agreed. Coincides well with Statement 1. As I stated in my support of Statement 1, we should have empowered our crats to use their best judgment in regranting the flag from the start. OhKayeSierra (talk) 07:27, 16 October 2019 (UTC)
22. Agree. In general, I support less overall bureaucracy where not needed. People who passed RFA shouldn't need additional scrutiny, and we specifically select bureaucrats to be people we trust to have the discernment to make these decisions. --Jayron32 17:59, 16 October 2019 (UTC)
23. Support both this and the one above it, but merge them into a single sentence to not be redundant.  — AReaderOutThataway ^t/_c 06:40, 22 October 2019 (UTC)
24. Support. their judgment as humans is better than any arbitrary number. We have chosen to use their discetion at afds in a middle range of support rather then have a sharp cutoff. I think that's kept us from mistakes, in both directions. Almost all ofthese won't b eparticularly controversial the way the inconclusive AfDs are. DGG ( talk ) 17:40, 22 October 2019 (UTC)
25. As I also support statement 1.-- P-K3 (talk) 19:16, 25 October 2019 (UTC)
26. Support --Cube lurker (talk) 17:16, 31 October 2019 (UTC)

Users who oppose statement 2

1. Oppose non-starter. We already have a venue for determining trust of the community. What you're asking for here is a Wikipedia:Requests for adminship. — Ched (talk) 03:35, 6 October 2019 (UTC)

   There's already a consensus that we need to tighten our resysop criteria, and one of the concerns was that they may not retain the trust of the community. Are you proposing they all go through RfA? I think that would be excessive, but you're welcome to propose it. – bradv🍁 04:38, 6 October 2019 (UTC)

2. Same problems as Statement 1: how convinced is "reasonably convinced", and how does a crat determine whether an admin "retains the trust of the community"? Does the crat conduct a survey? Tea leaves? If we want to make sure someone has the trust of the community, we have an RfA. If we want admin to re-run for RfA, that would be a different proposal. But we can't ask a crat to basically decide if a theoretical RfA would be successful. Crats are wise, but not psychic. – Levivich 03:37, 6 October 2019 (UTC)

   We choose our crats quite carefully. They are more qualified than anyone else to gauge the trust of the community. I highly doubt any of them would resort to reading tea leaves. – bradv🍁 03:41, 6 October 2019 (UTC)

   See above. The reasonable person has long been the established standard for anything requiring judgement. All this says is that the crats should use the judgement of the average active Wikipedia editor in determining whether to resysop according to the ADMIN policy. TonyBallioni (talk) 03:46, 6 October 2019 (UTC)

   I appreciate the effort you're making to bring this issue through an orderly community consensus process; sorry I'm opposing most of the statements so far. Personally, I'm waiting for the phase where we discuss desysop criteria; I just don't think there's a problem in general with the way we handle resysops. In the year I've been here, I'm not aware of there being a problem with a resysoped admin, and almost every resysoped admin I've encountered has been awesome. – Levivich 05:19, 6 October 2019 (UTC)

3. I basically thought that that was the reason for the 24-hour waiting period in the first place. --Dirk Beetstra ^{T C} 08:31, 6 October 2019 (UTC) (actually switching to oppose, too bureaucratic beyond the 24 hour waiting period --Dirk Beetstra ^{T C} 08:41, 6 October 2019 (UTC))
4. Oppose Ambiguous. If the having the level of trust just means not having reason to believe they're about to go rogue and delete the main page, it's reasonable. If it means whether they would pass an RfA circus, then it's not. Κσυπ Cyp   09:42, 6 October 2019 (UTC)
5. Oppose, too hard to judge. We also do not have "trust" standards for people who have already been admins, and RfAs after desysops have been so messy that I'm not sure we can develop any. I could support some extension of "not resigned to under a cloud", requiring fairly clean weather since the desysop. —Kusma (t·c) 13:10, 6 October 2019 (UTC)
6. Oppose as not reasonably practicable. · · · Peter Southwood ^(talk): 14:11, 6 October 2019 (UTC)
7. Oppose. This is too vague, with no good way to measure "trust". DES ^(talk)_{DESiegel Contribs} 16:52, 6 October 2019 (UTC)
8. Oppose.The Crats have no good way to measure the communities "trust", that is best left to the community at WP:RFA in my opinion. Govindaharihari (talk) 15:12, 7 October 2019 (UTC)
9. It is vague and time-demanding to require admins to become "reasonably convinced" in the affirmative. It could be reasonable to allow them greater discretion in interpreting the negative, i.e. not giving back the bit if "under a cloud" more loosely defined than now. Martinp (talk) 17:09, 7 October 2019 (UTC)
10. Oppose vague. Open to misuse. what happens if the 'crat talk page is peppered with a few unhappy editors the admin doesn't get along with and no-one else comments? Cas Liber (talk · contribs) 01:23, 8 October 2019 (UTC)
11. Oppose - I'm not sure how we expect a crat to gauge the community's level of trust in an editor. Besides, this is all common sense. If someone asks to be resysopped and had obvious, blatant issues with community trust, I don't think the crat would agree to it. ‑Scottywong| [express] || 22:20, 8 October 2019 (UTC)
12. Oppose. This sounds like an attempt to crowbar in some kind of recall provision through the back door. I'm sure that's not the intent, but 'crats already have the discretion to refuse a resysop if they think an admin vanished under a cloud or something. Guy (help!) 21:39, 9 October 2019 (UTC)
13. Oppose Resysop should not turn into some kind of mini-RfA. There's no reason to think that the people at BN are representative of the community as a whole so five people saying that a potential resysop is trouble doesn't reflect much in the community beyond five people thinking something. I trust the crats judgement but don't trust the incentives this creates. Best, Barkeep49 (talk) 00:44, 10 October 2019 (UTC)
14. Oppose same as #1 Buffs (talk) 16:06, 10 October 2019 (UTC)
15. Oppose - There's no process outside of arbcom to determine whether an active admin has the trust of the community, either, so this seems like a half-measure applied in a place where there isn't clear evidence of a concentration of damage done. — Rhododendrites ^talk \\ 17:02, 10 October 2019 (UTC)
16. The proposal states that a bureaucrat should be reasonably convinced that the user retains the trust of the community before restoring the bit. By definition, in order to assess "the trust of the community", we need a community discussion, so that would be RfA time. Ergo, this proposal solves nothing. — JFG ^talk 23:56, 13 October 2019 (UTC)
17. Oppose, too vague and wrong venue. We elect arbitrators, not crats, to determine if an admin has lost the trust of the community. Seraphimblade ^{Talk to me} 03:47, 14 October 2019 (UTC)
18. Oppose as too vague, could be construed as requiring a too high level of support (the point is not to make WP:BN into WP:RFA) ST47 (talk) 06:27, 16 October 2019 (UTC)
19. Oppose per my comment under statement #1. Ivanvector (^Talk/_Edits) 15:20, 16 October 2019 (UTC)
20. I don't see any way for this to become either objective or predictable. We already have too many groups that can desysop based on a flimsy rationalization and have that permanently stick at re-RFA attempts. (Everyking is the lone exception that proves the rule.) With this, crats would become another, and one of the ones we have no way to vote out of office. —Cryptic 21:37, 16 October 2019 (UTC)

Discussion of statement 2

This is too vague to be written into policy. Can't support without some clear statement of how 'crats should make that evaluation. ST47 (talk) 01:39, 6 October 2019 (UTC)

To me this is how we avoid the situations that we've had in the past where the 'crats have said "I am uncomfortable with this but my hands are tied." I trust our 'crats to apply their common sense and bring it to others if they are unsure. Proposal #3 below is a very good one to include here as well. CThomas³ (talk) 01:56, 6 October 2019 (UTC)

Cthomas3, Specifically one situation where at least one crat expressed being uncomfortable resysopping: Wikipedia:Bureaucrats'_noticeboard/Archive_40#Resysop_request_(Master_Jay). SQL^{Query me!} 22:27, 8 October 2019 (UTC)

I supported this above, but I'm starting to think that this should be fairly implied by the lack of a cloud when the desysop happened (unless, of course, that was under a cloud). – John M Wolfson (talk • contribs) 03:58, 6 October 2019 (UTC)

We’ve has some resysops of users who had the tools removed in clear weather, but originally granted in the halcyon days with only a handful of users in attendance, some with only minimal activity in the intervening time period. So in these cases, it was unclear, sometimes even unlikely, whether they still held the trust of the community. –xeno^talk 08:46, 6 October 2019 (UTC)

Huh, sounds fair enough. – John M Wolfson (talk • contribs) 19:48, 6 October 2019 (UTC)

There is an asymmetry if bureaucrats are empowered to examine if an administrator who has relinquished their privileges has retained the trust of the community, but are not empowered to make this determination for administrators who continue to hold their privileges. The net effect is to discourage administrators from giving up their privileges when not in use, as they would face extra scrutiny in return for following best security practices. isaacl (talk) 17:23, 17 October 2019 (UTC)

The crats already decide in AfDs in a discretionary range show the confidence of the community, They do it pretty well. Based on what they have done in the past, I doubt they would bevery harsh here. The atempt to find formal rules for something inherently a matter of judgment and discretion is unlikely to be helpful.even if we did agreeo n thoserules. ``

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

Statement 3 by Hasteur

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

---

The following statement should be added in WP:RESYSOP concerning restoration of permissions procedure after point 4 To allow time for requests to be checked thoroughly...:

Should there be doubt concerning the suitability for restoration of Admin permissions, the restoration shall be delayed until sufficient discussion has occurred and a consensus established through a Crat Chat.

Users who endorse statement 3

1. Hasteur (talk) 01:47, 6 October 2019 (UTC)
2. Also in addition to the above. TonyBallioni (talk) 01:51, 6 October 2019 (UTC)
3. This works well with both statements 1 & 2. – bradv🍁 01:52, 6 October 2019 (UTC)
4. Support this one as well. I think 1, 2, and 3 all work well together. CThomas³ (talk) 01:59, 6 October 2019 (UTC)
5. Due to multiple instances where crat after crat stated they were uncomfortable resysopping but that policy wouldn't let them refuse outright, and the returnee getting resysopped by a minority anyway. We should stop requiring unanimity against action and require consensus for it, just like just about everywhere else on-wiki. —Cryptic 02:55, 6 October 2019 (UTC), updated 21:27, 16 October 2019 (UTC)
6. creffett (talk) 03:22, 6 October 2019 (UTC)
7. I don't see this as indicating any objection - from anyone, no matter how insubstantial would require a crat chat, but if that's a concern maybe a small tweak would fix it for Joe. --valereee (talk) 12:58, 6 October 2019 (UTC)
8. Support as reasonable. Probably what happens already. · · · Peter Southwood ^(talk): 14:15, 6 October 2019 (UTC)
9. Kudpung กุดผึ้ง (talk) 17:30, 6 October 2019 (UTC)
10. Seems very sensible in conjunction with 1 and 2 - if it's not clear whether someone should be resysopped, don't resysop them until it is. Thryduulf (talk) 17:54, 6 October 2019 (UTC)
11. Yes, especially in tandem with the above 'maintains trust of community' Jbh ^Talk 07:11, 7 October 2019 (UTC)
12. This would do well with the first two proposals. SQL^{Query me!} 17:34, 7 October 2019 (UTC)
13. Why are there opposes based on "this is what happens already"??? Let's put actual best practice into writing... Carrite (talk) 19:47, 7 October 2019 (UTC)
14. Combined with #1 and #2, this is, at the very least, an excellent start. All three work well in conjunction with each other. Will the admin return as an active editor, and do they retain the community's trust? If unsure, gain consensus amongst the crats. — Jkudlick ⚓ t ⚓ c ⚓ s 03:34, 8 October 2019 (UTC)
15. Let's formalize it. feminist (talk) 04:30, 8 October 2019 (UTC)
16. Helps ensure that the bureaucrats' evaluation of the request is serious, and not superficial. — Newslinger talk 11:01, 8 October 2019 (UTC)
17. I'm not sure why this has to be codified, but it makes sense. Are crats technically not allowed to have a chat today? ‑Scottywong| [comment] || 22:21, 8 October 2019 (UTC)

    Scottywong, currently the crats' hands are tied by policy. Any reysop request by any admin, no matter how long since they've edited, is automatically is granted unless they were desysopped for cause or resigned under a cloud. Crats have no discretion in this, which has meant the resysopping of one user with 1600 edits total, fewer than 25 edits over the past ten years, and no edits for the past three years until July, when a single edit was made, followed a few minutes later by a resysop request, which was granted per current policy. That user has made 2 edits since. --valereee (talk) 12:11, 9 October 2019 (UTC)

    Crats do have a pocket veto, but haven't used it. —Kusma (t·c) 13:01, 9 October 2019 (UTC)

18. I don't think I can quite get behind 1 or 2 (still thinking) but per my comments at 11 I think a crat chat in cases where there is doubt concerning the suitability for restoration of Admin permissions. I don't think crats are going to be intimidated by a few angry people but nor do I think that concerns about a returning sysop who barely ever edited Wikipedia and is now asking for sysop back (and might then barely ever edit after getting it back) need be ignored either. Best, Barkeep49 (talk) 00:37, 10 October 2019 (UTC)
19. FASTILY 23:28, 11 October 2019 (UTC)
20. Pharaoh of the Wizards (talk) 23:47, 11 October 2019 (UTC)
21. Support in addition to statement 2 above. —comrade waddie96 ★ (talk) 13:45, 12 October 2019 (UTC)
22. I think there is a reasonable case to argue that if any Crat has concerns, it should go to a full Crat Chat - it doesn't much delay the process (whether the current one or modified from proposals below) Nosebagbear (talk) 17:39, 12 October 2019 (UTC)
23. Reasonable requirement. If it is done regularly already, formalize it; if it isn't, it should be. ~ ToBeFree (talk) 13:25, 14 October 2019 (UTC)
24. -- œ^™ 05:07, 16 October 2019 (UTC)
25. Support ST47 (talk) 06:35, 16 October 2019 (UTC)
26. Agreed with all of the above. OhKayeSierra (talk) 07:28, 16 October 2019 (UTC)
27. Pawnkingthree (talk) 14:19, 18 October 2019 (UTC)
28. Support. Seems pretty common-sensical to me.  — AReaderOutThataway ^t/_c 06:41, 22 October 2019 (UTC)
29. Support seems obvious. DGG ( talk ) 17:42, 22 October 2019 (UTC)
30. Support in concept Though crats should also listen to the community, not just discuss among themselves--Cube lurker (talk) 17:21, 31 October 2019 (UTC)

Users who oppose statement 3

1. not really needed, we already have the mandatory 24 hour waiting period (which can be lengthened as needed, mine was longer without apparent 'need'), but fine. --Dirk Beetstra ^{T C} 08:33, 6 October 2019 (UTC) (making it an oppose, we are not a bureaucracy --Dirk Beetstra ^{T C} 08:39, 6 October 2019 (UTC))
2. Weak oppose Delaying 24 hours is reasonable. Κσυπ Cyp   09:42, 6 October 2019 (UTC)
3. It doesn't need to be spelled out that if there's disagreement amongst the crats, they should try to reach a consensus. That's what we do everywhere. Additionally, this (slightly awkward) wording could be taken as meaning that if there are any objections—from anyone, no matter how insubstantial—there has to be a full "crat chat". That's overly bureaucratic. – Joe (talk) 11:22, 6 October 2019 (UTC)
4. Per Joe. – Levivich 15:35, 6 October 2019 (UTC)
5. Agree with Joe, this is what crats do. ~ Amory (u • t • c) 10:29, 7 October 2019 (UTC)
6. This seems like what the Crats do already. The Crats have a simple method of operation, they follow exactly what is written in policy, the only question that arises is, was this under a cloud, yes or no, the time limits are all there in policy for them to follow.Govindaharihari (talk) 15:14, 7 October 2019 (UTC)
7. As others have said, we already have 24 hrs for a discussion to happen, involving bureaucrats and the community more broadly. Beyond that, a "crat chat" can always be started, formally or informally, by a bureaucrat feeling they aren't sure how to read consensus, but I am very leery of forcing crat chats. More heads are not necessarily better than one. Martinp (talk) 17:12, 7 October 2019 (UTC)
8. unnecessary. takes place already without issue or extra parameters needed. Cas Liber (talk · contribs) 01:24, 8 October 2019 (UTC)
9. How would you validate it? This is process to fix a problem whose existence is not demonstrated. Guy (help!) 21:40, 9 October 2019 (UTC)
10. "Should there be doubt..." We've literally had this phrasing in our courts in the US and it proved to be disastrous. It should be a reasonable doubt, not "any doubt". I can come up with a thousand things that someone COULD conceivably do as an admin that would be disruptive and, as such, it's possible and a slim doubt exists. Buffs (talk) 16:11, 10 October 2019 (UTC)
11. Far too vague, and per my comment below entirely changes the role of 'crats from gauging consensus to forming it for themselves. Beeblebrox (talk) 19:37, 13 October 2019 (UTC)
12. If crats have reasonable "doubt concerning the suitability for restoration of Admin permissions", the case should be referred to the community, so it's RfA time. — JFG ^talk 23:51, 13 October 2019 (UTC)
13. Too vague. It's the decision of the community at RfA whether or not someone should be an admin, and for a former admin, that's already been answered affirmatively. It's not up to crats to override that determination. If someone needs their sysop flag involuntarily removed or denied, there's a way to do that. (Besides, in a truly extraordinary situation, there would simply be no crat who was actually willing to be the one to flip the bit, but that should be only for an extreme outlier case, not just where there's some question raised.) Seraphimblade ^{Talk to me} 03:49, 14 October 2019 (UTC)
14. Without some kind of firming up of what "doubt concerning the suitability for restoration of Admin permissions" means. Sam Walton (talk) 11:56, 15 October 2019 (UTC)
15. Oppose without clear conditions for when access would be regranted or denied. -- Ajraddatz (talk) 13:44, 16 October 2019 (UTC)
16. Oppose basically per Ajraddatz. If the criteria are properly objective, no discussion should be necessary, which is what we should be going for. Ivanvector (^Talk/_Edits) 15:21, 16 October 2019 (UTC)
17. Oppose I am not opposed to "chatting it over" informally, but in general I think that if any bureaucrat is not comfortable restoring the bit, for any reason, he should kick the decision to the community for further discussion. --Jayron32 18:00, 16 October 2019 (UTC)

Discussion of statement 3

Seeking only to explicitly codify that a Resysop is put on hold until the request has been discussed and the Crats have established if a consensus exists to resysop. Hasteur (talk) 01:47, 6 October 2019 (UTC)

• I’d prefer to reserve the term “cratchat” to refer to those specific discussions that occur during an RfA closing. –xeno^talk 02:50, 6 October 2019 (UTC)
• I think that's already the case. — Ched (talk) 03:37, 6 October 2019 (UTC)

  True; This time may be lengthened at a bureaucrat's discretion, if new information arises. If there are concerns, a bureaucrat can ask for the timeline to be extended. –xeno^talk 08:18, 6 October 2019 (UTC)

• I agree with Xeno that the term "cratchat" is and should be pretty narrowly limited to discussion after an RfX. I would endorse this statement if the wording were changed to the restoration shall be delayed until sufficient discussion has occurred on the Bureaucrats Noticeboard to establish that there is consensus to restore and a consensus established through a Crat Chat.. This has some precedent too: in 2018 there was an "informal crat chat" on the BN before Ymblanter's bit was restored and I think a similar process would be appropriate for future edge cases. As the statement currently reads, it's not clear if crats in this "Crat Chat" are discussing whether there is community consesus to restore or if they are deciding whether there is consensus among crats to restore. If the former, that's more similar to the Ymblanter situation than an actual Crat Chat; if the latter, that's not a crat chat but an RfA in which only crats can participate (which is something I'd be very opposed to). Wug·a·po·des​ 04:35, 6 October 2019 (UTC)
  • I'm not sure this is needed, since it seems to be what happens already anyway. Has any crat ever wondered whether they should have discussion at BN and come to consensus before acting in an inactivity edge case? – Levivich 05:06, 6 October 2019 (UTC)
    • I'd agree it's not particularly needed, but if we're going to add anything, I'd rather it be what happens already. Wug·a·po·des​ 22:44, 6 October 2019 (UTC)

With respect to the xeno (Wugapodes—Levivich) I am trying to explicitly codify what is an informal unwritten policy that has been both invoked to great benefit and to which I think I recall a few cases in which the promoting bureaucrat was repeatedly poked to promote when there was outstanding concerns that were not yet resolved. I invision this as 2 seperate but linked discussion: A actual debate/discussion on the merits of the proposed resysop and if need be a discussion by burecrats as to if either side has sufficently sustatined their side has sustained the argument. Hasteur (talk) 14:20, 6 October 2019 (UTC)

• This may codify an existing practice, but doesn't really address any problem. It doesn't grant any additional discretion to the 'crats. I also would prefer the tetm "discussion" to the jargon "cratchat" which adds nothing useful here. DES ^(talk)_{DESiegel Contribs} 16:55, 6 October 2019 (UTC)

• I think some of these proposals, whether this was intended or not, would fundamentally change the role of the 'crats. Generally, it is the role of the crats to gauge consensus and/or follow policy and act accordingly. If instead they are forming consensus that is different. When there is an RFA in the discretionary zone the purpose of the 'crat chat is not for the 'crats to break the tie by casting their own votes but rather for them to interpret the the arguments set out over the previous week and attempt to find a consensus. Beeblebrox (talk) 17:33, 6 October 2019 (UTC)

  Right. If the bureaucrats are just deciding the consensus among those who show up to comment on the BN request, we’ve just got a mini-Re-RfA every time. If the bureaucrats are using their own judgment and discretion, on what do they base their decision? –xeno^talk 17:50, 6 October 2019 (UTC)

• I don't understand the opposes saying "this is what already happens." If this is what were already happening, why do crats feel their hands are tied by policy when an absurd resysop request comes up? Is this a disagreement over what constitutes "suitability for restoration"? --valereee (talk) 12:16, 9 October 2019 (UTC)
  • Speaking only for myself, I don't feel it adds anything. By itself Should there be doubt concerning the suitability for restoration of Admin permissions doesn't do much because the criteria for restoration are fairly clear-cut, and, as with elsewhere on the wiki, if there is disagreement because it is not clear-cut (possible cloud, etc.) the bureaucrats already discuss it. Crats may feel their hands are tied by policy when an absurd resysop but this doesn't change the suitability of a given resysop. If one of the other vague proposals here is agreed-upon so that there is discretion or room for doubt, then perhaps this would be warranted, but it's also already done and implied by current policies. The main difference is expanding the use of the term "Crat Chat." ~ Amory (u • t • c) 15:18, 9 October 2019 (UTC)
  • why do crats feel their hands are tied by policy when an absurd resysop request comes up? I don't like this question. The "hands are tied" part implies the bureaucrat(s) doesn't want to do something but is required to and the "absurd resysop" part is completely subjective. Feels like a loaded question. Useight (talk) 16:35, 9 October 2019 (UTC)
    • Useight Hi. Great to see a WP:Crat comment. It is clear that currently Crats are tied by policy as I understand it, if this is not correct please expand, regards Govindaharihari (talk) 17:23, 9 October 2019 (UTC)
      • The bureaucrats follow policy, yes, but to say our "hands are tied" by the policy is to imply that we disagree with the policy but must follow it anyway. Some bureaucrats may disagree with the policy and some may not. I was merely pointing out that the question posed didn't feel neutral, but instead assumed that the bureaucrats (in whole or in part) didn't like the policy but had to follow it, when this may or may not be the case. Useight (talk) 18:40, 9 October 2019 (UTC)

        Useight, do you think a user with 1600 edits, including 30 edits since 2008, should be resysopped? That's what I was calling an absurd resysop request, and it was approved because the crats have no discretion -- the use didn't leave under a cloud, there's been no evidence of inappropriate behavior over the past eleven years during which they made those 30 edits. So I characterized that as a resysop due to the crats' hands being tied by our current policy. Any crat should have been able to question whether that person should at minimum have been required to get themselves up to speed before requesting the tools back. --valereee (talk) 18:24, 21 October 2019 (UTC)

        Valereee, I respectfully disagree with your characterization of that resysop request as absurd. Useight (talk) 00:18, 22 October 2019 (UTC)

        Useight, no worries, we can agree to disagree, but I am interested in hearing what to you would be an absurd resysop, if that one wasn't enough to at minimum make you go 'hmm...' --valereee (talk) 12:19, 22 October 2019 (UTC)

        Valereee, I am of the school of thought that there shouldn't be inactivity desysops in the first place. Adminship is no big deal. Any user who edits for six months or so and gets enough experience in the right places (which will probably only take a couple thousand edits) and is a civil person, should get the bit. I wrote my RFA Standards page over a decade ago and I still stand by it today. And then the bit should only be lost after evidence of incivility, incompetence, compromised account, etc. We're all volunteers and all (hopefully) doing our best. There is not a duration of inactivity (in length or edit count) that would make me go "hmm." However, I should note that I had a period of five years of inactivity, so take that as you will. Useight (talk) 15:02, 22 October 2019 (UTC)

        Useight, if you're willing to continue discussing, I am, but if I'm being tedious, feel free to ignore me. If you look at the resysop stats way down below, you'll see that many long-inactive admins re-requested, were regranted, and resumed useful editing, or at least resumed reasonably/minimally/sporadically useful editing, and I'd never want us to refuse to resysop just for a period of inactivity, even one of several years. If someone really wants to come back and is willing to get up to speed first, bully. And I agree completely that adminiship should be no big deal. I'd support giving the tools to basically anyone who is temperamentally fit. But the reality is that we don't, and it demoralizes many of those to whom you and I would probably give the tools when someone who has been absent for eleven years requests, and then after resysopping, basically just wanders back out. It can feel like we've set up a little club for ourselves here, with RfA voters as the gatekeeprs, and by gosh we got in and we don't want to risk ever having to get past those gatekeepers again so we'll just set up the rules to make that not a possibility. Please let me be clear that I am not accusing you or anyone else here of consciously or subconsciously doing this or wanting to do this. I'm just saying it's what it feels like to at least some non-admins, including some of our most respected and valued contributors. --valereee (talk) 15:32, 22 October 2019 (UTC)

        @Useight: for the sake of this discussion, let's say the being a sysop is no big deal. Just because it's not a big deal doesn't mean it's no deal at all. I have a hard time saying that someone who edits for six months and has a few thousand edits 10 years ago has the same competency as someone who has edited for six months and a few thousand edits during calendar year 2019. Standards change. Skills erode. I think we should find a way to welcome the user of 10 years ago back into the community. Doing so as sysop feels like at least a little bit of a deal and so even if it's not a big deal doesn't mean there's nothing to see or do about it. Best, Barkeep49 (talk) 15:39, 22 October 2019 (UTC)

        Valereee, Barkeep49, Sorry, but as a rule I don't wax philosophical. It's not you, it's me. If you really want to keep talking about it, I can, but I'd rather not carry on here on this page. I am more than willing to discuss further on my talk page, though, so feel free to cross-post there. Useight (talk) 16:50, 22 October 2019 (UTC)

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

Statement 4 by Hasteur

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

As part of the request for resysop, the returning administrator should indicate what actions they intend to do with the permissions. Bureaucrats shall be empowered to consider the assertion and any previous assertions.

Users who endorse statement 4

1. Hasteur (talk) 02:20, 6 October 2019 (UTC)
2. I'm happy to accept 'doing the same stuff I did before' as an answer, but yes, I do want to know what someone who has been inactive for a long period is planning to work on, as if that area has undergone some change, an admin who has been inactive might need to be made aware of those changes. --valereee (talk) 12:52, 6 October 2019 (UTC)
3. weak support We ask similar questions of prospective Admins at RfA, so this doesn't seem unreasonable. But it also doesn't have any teeth, if a person asking for a re-sysop says they plan to close AfD's and then never touches one, we are stuck unless we change policy to make that a reason for a de-sysop. DES ^(talk)_{DESiegel Contribs} 22:27, 7 October 2019 (UTC)
4. Support A returning admin should be able to explain what they intend to do with the tools, and if they cannot or if that claim is not consistent with reality, then there is no reason for the tools to be returned. The "teeth" that this has are over multiple returns - If an admin reactivates in 2020, says they're going to close AfDs, closes like three AfDs and then goes inactive again, then this allows 'crats to weigh that factor when considering subsequent requests. ST47 (talk) 06:38, 16 October 2019 (UTC)

Users who oppose statement 4

1. We don't require editors to declare what they intend to edit. There's simply too many variables to expect admins. to be able to declare this. — Ched (talk) 03:40, 6 October 2019 (UTC)

   We do precisely that at RFA question #1. --Izno (talk) 18:21, 6 October 2019 (UTC)

2. Ditto. – Levivich 04:24, 6 October 2019 (UTC)
3. 'I intend to do content creation and AfDs, oh sorry, I am using it to combat spam'. Not needed, I don't have a crystal ball to look into my future either. The assumption that the editor will continue with what they did before losing the bit is enough. --Dirk Beetstra ^{T C} 08:35, 6 October 2019 (UTC)
4. Oppose Doesn't matter what, as long as it helps Wikipedia. Κσυπ Cyp   09:42, 6 October 2019 (UTC)
5. Oppose as pointless and unenforceable. Predicting what one will do is an inexact science. What do we do about it if it doesn't happen? · · · Peter Southwood ^(talk): 14:18, 6 October 2019 (UTC)
6. Oppose. Return of admin bit should be about trust, or the absence of it, not about intended activity. Martinp (talk) 17:13, 7 October 2019 (UTC)
7. no point - one can ask but not enforceable nor predictable. Cas Liber (talk · contribs) 01:45, 8 October 2019 (UTC)
8. Oppose - Pointless. Even if someone gives an answer to this question, they're under no obligation to actually follow through on it. ‑Scottywong| [gossip] || 22:22, 8 October 2019 (UTC)
9. Oppose' as needless processcruft. We should assume they will do whatever it was they did before they went away. Guy (help!) 21:41, 9 October 2019 (UTC)
10. Oppose Guy said it first. Buffs (talk) 16:08, 10 October 2019 (UTC)
11. Oppose - per guy — Rhododendrites ^talk \\ 17:03, 10 October 2019 (UTC)
12. Oppose per Chad above. —comrade waddie96 ★ (talk) 13:45, 12 October 2019 (UTC)
13. Statements of intent are too vague to assess and too easy to game. This proposal would only create more drama. — JFG ^talk 14:03, 13 October 2019 (UTC)
14. Unenforcable. Beeblebrox (talk) 19:34, 13 October 2019 (UTC)
15. Unenforceable and ultimately pointless. I've never been a fan of "doesn't need the tools" anyway. If someone only makes ten admin actions a year, but they were all good actions supported by policy, that still helps the project. It's not like we have a limited number of slots. Seraphimblade ^{Talk to me} 03:51, 14 October 2019 (UTC)
16. Oppose. Won't fix anything. —pythoncoder (talk | contribs) 19:12, 15 October 2019 (UTC)
17. No per Guy and JFG. OhKayeSierra (talk) 07:30, 16 October 2019 (UTC)
18. Oppose: Nope, not our business, and certainly not the business of the bureaucrats. — Javert2113 (Siarad.|¤) 14:38, 16 October 2019 (UTC)
19. Oppose - they intend to admin. We don't need more details than that. Ivanvector (^Talk/_Edits) 15:24, 16 October 2019 (UTC)
20. Oppose The threshold for adminship should always be "would not misuse the tools" not "has use for them". Everyone has use for them. Our only assurance should be that they know how to use them correctly. --Jayron32 18:01, 16 October 2019 (UTC)
21. Oppose. That's not even an official RfA thing, though it's a common RfA question. Even so, we do not hold people to it. Many admins end up focusing on something else than what first attracted them to the mop.  — AReaderOutThataway ^t/_c 06:43, 22 October 2019 (UTC)
22. This is RfA thing. -- CptViraj (📧) 03:45, 4 November 2019 (UTC)

Discussion of statement 4

• After being sugested above by Tony, I'm breaking this out to a separate proposal Hasteur (talk) 02:20, 6 October 2019 (UTC)

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

Statement 5 by Pharaoh of the Wizards

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Adminship will not be restored after 5 years for those who resigned without a new RfA. (this is in addition to the 3 year inactivity rule) .(To clarify "For someone who has resigned five or more years ago, adminship can only be reinstated through a new RfA.)

Users who endorse statement 5

1. Pharaoh of the Wizards (talk) 05:00, 6 October 2019 (UTC)
2. This doesn't seem like a bad idea to have "on the books", but I'm not sure it addresses a real problem. All of the returned sysops I can think of +sysoped within five years of -sysoping. – Levivich 05:13, 6 October 2019 (UTC)
3. I don't know that this would need to be invoked very often, but it seems obvious that any admin who has been inactive for that long can't possibly have kept up with policy. --valereee (talk) 12:49, 6 October 2019 (UTC)
4. I guess we have to start somewhere but I would like to see the time cut down considerably. Two to three years is enough time for much to change both in policy and culture. Jbh ^Talk 07:14, 7 October 2019 (UTC)
5. An easier way to accomplish something similar is to adjust the last bullet point of WP:ADMIN § Restoration of adminship to "Over five years since administrative tools were last used. For any former administrator who does not have a logged administrator action in five years, bureaucrats should not restore administrator access upon request." I agree with Jbhunley in that a 2–3 year time frame would be more effective for keeping administrators aware of new policy and guideline changes. — Newslinger talk 11:14, 8 October 2019 (UTC)
6. Weaker support, I don't think this goes far enough - but it's something. — xaosflux ^Talk 13:35, 12 October 2019 (UTC)
7. A long absence should require a refresh on policy and acceptable norms of behaviour. An RfA is a good way for the community to ask relevant questions, and to assess that the former admin is back up to speed. — JFG ^talk 23:41, 13 October 2019 (UTC)
8. I thought this was already basically the standard practice, but if not, it should be codified. A former admin who has been away for so long should demonstrate they still hold the confidence of the community, and the only way we have to do that is RfA. Ivanvector (^Talk/_Edits) 15:26, 16 October 2019 (UTC)
9. I can support this as tightening but it won't address the stated concerns imo. Five years is a long time, on the internet it is like half an eternity.Govindaharihari (talk) 19:40, 17 October 2019 (UTC)
10. Support. Our policies and procedures change too much for someone who's been gone that long to be competent in many cases, and if they are they'll have no trouble passing a second, re-confirmation, RfA. If they do have trouble passing one, then there are community trust issues that Crats shouldn't override/ignore anyway. :-)  — AReaderOutThataway ^t/_c 06:44, 22 October 2019 (UTC)

Users who oppose statement 5

1. If an editor is active during those 5 years and is in good standing then they should still be free to request. The current 24-hour waiting period should provide enough time for discussion if there are serious concerns upon which 'çrats can decide differently. --Dirk Beetstra ^{T C} 08:38, 6 October 2019 (UTC)
2. Oppose Adding more activity rules seems to be going in the wrong direction. Κσυπ Cyp   09:42, 6 October 2019 (UTC)
3. Oppose. I understand and appreciate the intent behind this, but it should be decided based on activity and how well (or otherwise) they've kept abreast of changes rather than an arbitary cut-off. Thryduulf (talk) 17:57, 6 October 2019 (UTC)
4. Mild oppose as having minimal impact. Martinp (talk) 17:19, 7 October 2019 (UTC)
5. weak oppose as I don't think this is the issue, and will have no impact, and will be more bureaucratic. I trust the 'crats to make a call on this as things stand. I can understand and sympathise with the intent behind this, however. Cas Liber (talk · contribs) 01:49, 8 October 2019 (UTC)
6. I support the concept, but I'm opposed to the ambiguous and unclear wording of this statemnent. When does the 5-year counter start from? The time when their adminship was revoked? The time that they last used an admin tool? The time that they last edited? This needs to be defined explicitly and exactly for this rule to work. Also, the addition of the 3-year inactivity rule just makes this statement even more difficult to understand. Clear up the wording and I'd support it. ‑Scottywong| [comment] || 22:25, 8 October 2019 (UTC)
7. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:47, 9 October 2019 (UTC)
8. Weak Oppose if you haven't used the tools in 5 years, you're probably out of date on policy and community consensus for your adminship needs to be reassessed. Buffs (talk) 16:14, 10 October 2019 (UTC) Too many double negatives make this option atrocious to enforce. Buffs (talk) 04:55, 14 October 2019 (UTC)
9. Weak oppose as crat discretion should be used but I do believe we need some sort of specific time limit after which a new RfA is required. —comrade waddie96 ★ (talk) 13:47, 12 October 2019 (UTC)
10. Oppose mostly per Beetstra. ST47 (talk) 06:39, 16 October 2019 (UTC)
11. Oppose We should be encouraging prior sysops to want to come back and get involved again. I think that too many hurdles to regaining the bit will have a deleterious effect on sysops willing to ask for the bit. OhKayeSierra (talk) 07:33, 16 October 2019 (UTC)
12. Oppose Seems arbitrary and an excessive hurdle. --Jayron32 18:02, 16 October 2019 (UTC)
13. We need more admins, not fewer. Stifle (talk) 09:37, 17 October 2019 (UTC)

Discussion of statement 5

• Admins have resigned right since Jan 2004 now anyone who resigned in good standing at any time can request back his tools then a user like Stephen Gilbert who resigned in 2004 can come back and ask back for there tools.Pharaoh of the Wizards (talk) 05:00, 6 October 2019 (UTC)
• I assume this means back to RfA after 5 years? · · · Peter Southwood ^(talk): 14:20, 6 October 2019 (UTC)
• This should be edited to say the tools should not be restored without a new RfA, as written it seems to deny the possibility of a new RfA. DES ^(talk)_{DESiegel Contribs} 16:58, 6 October 2019 (UTC)
• Edited as per above to make it clear.Pharaoh of the Wizards (talk) 17:02, 6 October 2019 (UTC)
• What does it mean to "resign without a new RfA"? I realize that was probably not how this was intended to be parsed but this ambiguous wording doesn't help make these proposed rules easy to understand. —David Eppstein (talk) 06:50, 8 October 2019 (UTC)
• @Scottywong: ,@David Eppstein: To be Precise it is 5 years form the day they resigned that they need to ask back there tools (A user who resigned his tools on January 1, 2014 now he could have asked back his tools till Jannuary 1, 2019 that is 5 years from the date of resignation ) Now those who they have not gone without an edit or logged action for three consecutive years are consdiered long term inactive this rule is addition to that.Please let me know how to tweak the words.Pharaoh of the Wizards (talk) 06:32, 9 October 2019 (UTC)

Perhaps you missed my point. There are four pieces of information in the sentence: "will not be restored", "after 5 years", "resigned", and "without a new RfA". This ordering means you can group them ((will not) (5 years)) (resigned without a new RfA): "If an admin resigns and that resignation did not involve a new RfA, then five years later they will be non-restored". But it's not possible to group them the way I think you intended, (will not be restored without a new RfA) (5 years after resignation), because English doesn't group that way: the things that go together should be spoken together, not separated by something else. And your new rewording only muddies the waters by making it seem like there is a five-year waiting period before requesting the tools back. So I think it would be better to rewrite this statement as something more like "For someone who has resigned five or more years ago, adminship can only be reinstated through a new RfA." to put the ideas that go with each other next to each other. Or am I misunderstanding what you really mean, still? —David Eppstein (talk) 06:50, 9 October 2019 (UTC)

Also, there are multiple ways to lose adminship, resignation is only one of them. What if someone's adminship is revoked due to inactivity? Are we still counting 5 years from the date that their adminship was revoked? Rather than basing this rule on the day that an admin "resigned", I think it would be better to adjust the language so that's based on the day that the admin bit was removed from their account, for whatever reason. Whatever it ends up being, a rule like this needs crystal clear language that leaves nothing in doubt. ‑Scottywong| [verbalize] || 17:42, 9 October 2019 (UTC)

• @Buffs: It seems to me that you mean to support this statement, but were confused by the initial wording. Please check the clarification above. — JFG ^talk 23:45, 13 October 2019 (UTC)
  • Too many double negatives. Buffs (talk) 04:53, 14 October 2019 (UTC)
• I'm sorry, even after rewording it's still unclear what this changes. Does this just make it so that someone who resigned many, many years ago but has remained continuously active as an editor (so that WP:RESYSOP #5 doesn't apply) needs a new RFA? Or has WP:RESYSOP #5 been read to never apply to resignations? —Cryptic 22:10, 16 October 2019 (UTC)

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

Statement 6 by GZWDer

Closed per WP:SNOW
The following discussion has been closed. Please do not modify it.
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows. There is unanimous opposition to this proposal. Closing per WP:SNOW. --qedk (t 桜 c) 14:06, 18 October 2019 (UTC) The following statement should be added to WP:ADMIN in the section concerning restoration of permissions: Users requesting restoration of sysop flag after being desysoped by inactivity or more than one year after resignation are only grant temporary adminship for one year. After one year a confirmation should be started if they want to keep adminship. A confirmation is similar to an RFA, with the difference that the snowball clause is applied both side (successful and unsuccessful). Once the confirmation is passed, adminship will be extended indefinitely. Users who endorse statement 6 This will defer the concern of suitability for restoration of Admin permissions.--GZWDer (talk) 13:21, 6 October 2019 (UTC) Users who oppose statement 6 Oppose. As written as it's very confusing, but even if it were clarified a confirmation process should gain consensus and be established first before making it mandatory. Thryduulf (talk) 17:58, 6 October 2019 (UTC) No reason to put a time limit on adminship for exactly these cases. Being a good admin might actually make RFA harder to pass, not easier. —Kusma (t·c) 18:04, 6 October 2019 (UTC) I totally get the motivation, but I feel like this is creating an admin whose primary goal is not to piss anyone off. --valereee (talk) 00:35, 7 October 2019 (UTC) Needlessly complex, and would incentivize popularity-seeking behaviour. Martinp (talk) 17:20, 7 October 2019 (UTC) Oppose. People have suggested periodic reconfirmation before, there are good reasons ehy it ahs never gained consensus. This will simply cause people on 'probation" not to do anything that offends anyone. It also creates a twotoiered admin group, which i think undesirable. DES (talk)DESiegel Contribs 22:30, 7 October 2019 (UTC) Oppose, I disagree with adding a weak second RfA requirement. Actually, I wouldn't mind seeing something like this for low-support RfAs, but that's a different conversation. creffett (talk) 00:14, 8 October 2019 (UTC) Oppose as cumbersome. I also like this idea for borderline RfAs Cas Liber (talk · contribs) 01:51, 8 October 2019 (UTC) Oppose Why give adminship back at all if there is enough doubt to require a reconfirmation? ‑Scottywong| [communicate] || 22:26, 8 October 2019 (UTC) Oppose per scotty. What's the point? Buffs (talk) 16:12, 10 October 2019 (UTC) Too complex. — JFG talk 14:01, 13 October 2019 (UTC) Oppose as too time-consuming for the community. —pythoncoder (talk | contribs) 19:15, 15 October 2019 (UTC) Oppose not interested in a "temporary adminship" system. ST47 (talk) 06:42, 16 October 2019 (UTC) No. I don't like the idea of a temporary adminship system. If the community can't trust a sysop to have the flag indefinitely, then they shouldn't have the flag at all. Full stop. OhKayeSierra (talk) 07:35, 16 October 2019 (UTC) Oppose: Per OhKayeSierra. Temporary adminship would not go over well. — Javert2113 (Siarad.|¤) 14:39, 16 October 2019 (UTC) Oppose - no temporary admins. It's just a bad idea (c.f. Pandora's box). Ivanvector (Talk/Edits) 15:28, 16 October 2019 (UTC) Oppose per above. No temporary adminship. If you have the trust of the community to manage the tools for a year, then there's no reason to take it away. Trust is gained before the tools, not after. --Jayron32 18:03, 16 October 2019 (UTC) The above discussion is preserved as an archive of the debate. Please do not modify it. No further edits should be made to this discussion.

Statement 7 by Amorymeltzer

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

---

In the second bullet of the Restoration of adminship section of WP:ADMIN, change three years (1+2) to two years (1+1), such that the item would thus read:

• Over two years with no edits. If an editor has had at least two years of uninterrupted inactivity (no edits) between the removal of the admin tools and the re-request, regardless of the reason for removal, the editor will need to instead request through the WP:RFA process. In the case of an administrator desysopped due to a year of inactivity, only one year of continued uninterrupted inactivity (no edits) from the removal due to inactivity is required before a new WP:RFA is necessary.

Users who endorse statement 7

1. I like this idea. It is the only idea so far presented that is an actual strengthening of the policy. Govindaharihari (talk) 15:53, 6 October 2019 (UTC)
2. Support as and for the same reasons as written. Thryduulf (talk) 17:59, 6 October 2019 (UTC)
3. Prefer 1 and 2, but this would be a step in the right direction. TonyBallioni (talk) 18:07, 6 October 2019 (UTC)
4. Pharaoh of the Wizards (talk) 18:45, 6 October 2019 (UTC)
5. Not as strict as I would like, but a step in the right direction. Lepricavark (talk) 20:06, 6 October 2019 (UTC)
6. Wug·a·po·des​ 22:51, 6 October 2019 (UTC)
7. Support. CThomas³ (talk) 06:53, 7 October 2019 (UTC)
8. Support. As I said above, two years is enough time for policy and culture to change enough that even a previously good admin will face an unfamiliar environment. Many editors will be unfamiliar with the returning admin and it is very hard in that situation to be able to reasonably claim the community still trusts the returning admin... how can they? Jbh ^Talk 07:19, 7 October 2019 (UTC)
9. Prefer #11 just for simplicity, but this would help. --valereee (talk) 11:45, 7 October 2019 (UTC)
10. This is a step in the right direction. I personally would like to see something done about the dozens of gameplayers grandfathered from the No Big Deal period who only make token edits each year to hold their tools. Carrite (talk) 19:45, 7 October 2019 (UTC)
11. Support in conjunction with some other proposals. As Amory points out this proposal and one or more others could gain consensus. Best, Barkeep49 (talk) 22:01, 7 October 2019 (UTC)
12. Yes, I can see the rationale for this. Cas Liber (talk · contribs) 01:52, 8 October 2019 (UTC)
13. Encourages participation and helps ensure that administrators are up-to-date with policy and guideline changes. — Newslinger talk 11:22, 8 October 2019 (UTC)
14. It at least does something, and there is some precedent for this: m:AAR. --Rschen7754 04:07, 10 October 2019 (UTC)
15. As proposer. This essentially aligns with my support in the first RfC, namely no matter what else it wouldn't hurt to tighten the return procedures. This is a simple, clear tightening per consensus in the RfC, moving from 3 to 2. ~ Amory (u • t • c) 10:05, 10 October 2019 (UTC)
16. A step in the right direction. feminist (talk) 15:31, 10 October 2019 (UTC)
17. Support in principle, but the phrasing is clunky. Change for the sake of clarity/removal of double negatives: "If an editor has had at least two years of uninterrupted inactivity (no edits)..." to "If an editor has gone two or more years with no edits..."
18. FASTILY 23:28, 11 October 2019 (UTC)
19. Seems reasonable, like this one better than 5. — xaosflux ^Talk 13:37, 12 October 2019 (UTC)
20. Support I like this stricter time. —comrade waddie96 ★ (talk) 13:48, 12 October 2019 (UTC)
21. Weak support - it's a minor improvement, but doesn't really resolve any key issue, but mitigates the current negatives Nosebagbear (talk) 17:42, 12 October 2019 (UTC)
22. It's something, and it's quite simple and would be easy to immediately implement. Beeblebrox (talk) 19:33, 13 October 2019 (UTC)
23. A quick and easy improvement, regardless of the outcome of other proposals. — JFG ^talk 23:48, 13 October 2019 (UTC)
24. Definitely a quick, easy step in the right direction, as many others say. Happy days, Lindsay^Hello 08:01, 14 October 2019 (UTC)
25. ~ ToBeFree (talk) 19:38, 14 October 2019 (UTC)
26. Seems like a reasonable way to strengthen the policy. OhKayeSierra (talk) 07:36, 16 October 2019 (UTC)
27. Sensible. Ivanvector (^Talk/_Edits) 15:29, 16 October 2019 (UTC)
28. Seems reasonable. Two years of absolutely no activity is long enough to lose grasp of the evolving culture of Wikipedia, and the threshold of making one pro-forma edit per year is not too much. --Jayron32 18:05, 16 October 2019 (UTC)
29. Support . Makes sense. Kudpung กุดผึ้ง (talk) 20:07, 17 October 2019 (UTC)
30. Support for the same reason I support #5 above. 06:45, 22 October 2019 (UTC)
31. Support seems reasonable and makes sense. Puddleglum2.0👌(talk) 00:18, 4 November 2019 (UTC)

Users who oppose statement 7

1. Mild oppose. This feels like tightening for the sake of tightening. If the issue we're trying to solve is returning admins disassociated from the community, let's require them to re-engage (via for instance an activity requirement before returning the bit) rather than tweaking the rules. As an old-timer here, I feel the "policies and culture change" argument is a bit of a red herring: of course they evolve, but not that much/that fast that 3yrs vs 2 yrs would make a meaningful difference. Specifically on policies, a good admin will refresh themselves before (re)entering an area they have not been very active in, and a not so good one will step on landmines even if they've been using their bit in other ways on an ongoing basis. Martinp (talk) 17:26, 7 October 2019 (UTC)
2. Not seeing how this will decrease public outcry about sysops who log in and edit every other year to have their bit restored. Also, two years is not a very long time in terms of what can happen in someone's life. —Kusma (t·c) 20:35, 7 October 2019 (UTC)

   We don't need to pick just one, more than one of these can find consensus if they work together. Something like this and your proposal below don't conflict at all, for example; indeed, your proposal sort of implies this one would be the case anyway. ~ Amory (u • t • c) 21:05, 7 October 2019 (UTC)

3. Oppose, seems to be going the wrong way. Also oppose the other proposals that keep popping up by default, looks like RfCs ad nauseam. Κσυπ Cyp   08:12, 8 October 2019 (UTC)
4. I think two years is too short for this. – Levivich 21:39, 9 October 2019 (UTC)
5. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:48, 9 October 2019 (UTC)

   There was consensus for stricter requirements, this is a purely stricter requirement. It is solving the problem of people who wish to abide by apparent community consensus. I figure that even if you opposed the outcome of the first RfC, this is the very least of where you should end up, as a straightforward tightening per consensus. ~ Amory (u • t • c) 10:05, 10 October 2019 (UTC)

6. Oppose - We don't need barriers to good admins that had something come up in their lives which preventing them from being active for a while. Again, it's a bandage for a broken desysopping process. We're throwing out potentially good admins because we're afraid we won't be able to desysop bad admins. — Rhododendrites ^talk \\ 17:06, 10 October 2019 (UTC)
7. Oppose Three years isn't that long a time, behavioral judgments (such as props 1, 3, 4) are more useful IMO than time-based ones. ST47 (talk) 06:45, 16 October 2019 (UTC)

Discussion of statement 7

The RfC closed in favo(u)r of a stricter requirement, so here's a simple tightening of one of the criteria. Would clearly supersede the currently-referenced 2012 consensus, namely Wikipedia_talk:Administrators/Archive_13#1.2B2 and Wikipedia_talk:Administrators/Archive_13#3_years_of_inactivity. Implies a corresponding change to item #5 of WP:RESYSOP. ~ Amory (u • t • c) 15:44, 6 October 2019 (UTC)

• I'm not following the difference between the two situations? --valereee (talk) 00:34, 7 October 2019 (UTC)
  • The section at WP:ADMIN is a little confusing since it's trying to cover all cases, but basically it's saying that the rule is three and that can include the year of inactivity leading to the desysop. Right now, if I stop editing this month, I'll have my sysop tools removed November 2020 for inactivity (1). If I never edit again, then starting November 2022, I will need to do an RfA to get the tools back (2). That's 1+2 for a total of three years with no edits. On the other hand, let's say I keep active for a while but voluntarily resign the tools next November. If I subsequently go three full years with no edits (3), I'll need to do an RfA for the bits in November 2023. That's also a total of three years with no edits. This proposal is to change the three to two (1+2 becomes 1+1, and 3 becomes 2), so RfA would be required in November 2021 or November 2022 in my above scenarios. Likewise, if my perms are removed for inactivity but I subsequently make a few edits here and there, this change would mean waiting for two years of no edits rather than three before requiring RfA. ~ Amory (u • t • c) 10:58, 7 October 2019 (UTC)
• Kusma just because it won't solve all problems doesn't mean it won't help alleviate some. --valereee (talk) 20:54, 7 October 2019 (UTC)

  Valereee and Amorymeltzer, sure. I should have based my opposition less on the lack of perfection and more on the other problem that I actually think people should be allowed to leave for two or three years and then come back to all of their old userrights without the hazing ritual of RfA. (None of this discussion should really happen: we just should fix RfA not to be a hazing ritual, but it is a lot easier to change the resysop criteria than to fix RfA, so here we are...) —Kusma (t·c) 21:30, 7 October 2019 (UTC)

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

Statement 7.5 by DESiegel (formerly Procedure)

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

---

Multiple proposals may gain consensus, provided that they are not essentially incompatible.

No proposal in this RfC shall be considered to have gained consensus unless it has a clear consensus among all those editors who have commented on this RfC in any way, including those who only commented on a single proposal.

Discussion of statement 7.5

Thread retitled from "Discussion of Procedure".

• The RfC as originally posted allowed for multiple proposals, but said nothing about how to judge which ones did or did not have consensus. This is a potentially major change, and should have clear consensus to be implemented. Therefore I am adding this section. DES ^(talk)_{DESiegel Contribs} 16:45, 6 October 2019 (UTC)
  • Wow, way to torpedo any hope of consensus-building in two misleadingly-unsigned sentences. —Cryptic 05:47, 7 October 2019 (UTC)
  • Likewise, I've got to disagree with the adding of this section, in particular the first sentence. I'd argue that your imposition of that criterion is itself a potentially major change, and should have clear consensus to be implemented. ~ Amory (u • t • c) 10:16, 7 October 2019 (UTC)
  • I don't even know what this means...are you saying that if someone doesn't !vote on a particular proposal, that person must be considered to have !voted against it? I wouldn't support adding that. People wander off. --valereee (talk) 12:08, 7 October 2019 (UTC)
  • I agree with Valereee - not everybody who !voted early on will even know that some later proposals exist. Even among those who do, not everybody will have a strong opinion about every proposal - for example I neither support nor oppose proposal 4 so I have not !voted for or against it, the absence of my name should not be taken as opposition. Thryduulf (talk) 17:08, 7 October 2019 (UTC)
  • I strongly disagree. Each proposal stands or falls based on those who endorse or oppose that statement. If we end up with mutually exclusive proposals with majority support, there will have to be a run-off of some sort.-gadfium 17:35, 7 October 2019 (UTC)
• That is not how it should work. While we are talking about the structure and rules: We should have probably done some proper discussion of proposals to improve their text before everybody started voting. But we didn't, so we have something fairly messy, with voting more concentrated on the first couple of sections (and Proposal 15, which will be the perfect compromise everybody can get behind, will be overlooked). —Kusma (t·c) 20:32, 7 October 2019 (UTC)

  Kusma, maybe we'll need a third RfC. :::sigh::: Some people are opposing things because they don't go far enough. They appear to be unwilling to consider anything other than the perfect solution for all problems rather than being willing to accept a partial solution to some. --valereee (talk) 20:59, 7 October 2019 (UTC)

• My intent here was not to say that everyone who does not support proposal NN shoul be treated as having opposed it. Rather, the total number of people commenting in the RfC should be used to help establish the quorum for a proposal to be enacted. Last time i looked, one of the proposals had three supports and one oppose. A 3-to-1 ratio is usually enough for consensus,if it is, say 30-to-10, but I don't think a proposal with only three supporters, even if no one opposes it, can be said to have project-wide consensus. If a sizable proportion of those who comment here support a particular proposal, and significantly more support it than oppose it, that is one thing. If only say a tenth of those who comment on the rfC support a particular proposal, that is another. DES ^(talk)_{DESiegel Contribs} 22:20, 7 October 2019 (UTC)

  Thank you for your clarification.-gadfium 07:49, 8 October 2019 (UTC)

  Thanks for the explanation, DES, but I still oppose. People wander off. A great later proposal that gets enthusiastic support from everyone still paddling away here might be a winner. I wouldn't want to ignore something that got 100% support just because it didn't get votes from most of the people who commented somewhere here, and that's what this seems to be calling for. Whoever closes this will no doubt take those kinds of things into account, but I wouldn't want them to take them more into account than on any other RfC. --valereee (talk) 11:46, 8 October 2019 (UTC)

  Once again I agree with Valereee. A good RfC closer will take all these factors into consideration in the same way they always do without their hands being unnecessarily tied by good-faith but misguided rules like this one. A proposal that gets almost five supports and one oppose while others have several tens of votes in both columns might be closed as consensus in favour or no consensus either way depending on the nature of the proposal and the arguments made for and against it. If it's proposing a major change then no way will it be considered to have consensus but if it's just a minor technical point and the only oppose has been fully refuted by the support votes then there is no reason why it shouldn't pass just because few people have an opinion about it. Thryduulf (talk) 14:43, 8 October 2019 (UTC)

• I've converted this into a basic statement, inserted chronologically. –xeno^talk 14:41, 9 October 2019 (UTC)
• I support this, but I also support other proposals, so I don't know what that means. --Rschen7754 04:08, 10 October 2019 (UTC)
• Alternate - I've added proposal 18 which I think is a much less controversial addition than this, but should resolve the issues raised - a 30 second glance would be appreciated Nosebagbear (talk) 15:36, 16 October 2019 (UTC)
• Oppose in favor of #18, and that only if it seems absolutely necessary.  — AReaderOutThataway ^t/_c 06:48, 22 October 2019 (UTC)

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

Statement 8 by Kusma

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

---

I am not convinced we need any change at all, but if we must change something, I think the change should address the unease that some people feel when long-term inactive admins ask for the bit back with their first edit after desysopping

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Any former admin who has been inactive for more than two years will be re-sysopped on request after a period of normal editing proportional to their length of inactivity. If N years have passed since desysopping, the former admin should edit for N months, making 50 non-stupid (i.e., constructive edits that are not clearly made to inflate edit count only) edits each month. After the N months have passed, they will be re-granted admin status by request on WP:BN (subject to the normal exclusions).

Users who endorse statement 8

1. If we need a change, something like this seems more useful than just tweaking numbers or asking bureaucrats to use a crystal ball. —Kusma (t·c) 17:14, 6 October 2019 (UTC)
2. I've added a similar proposal below, but I'd support this. My only concern is for editors like DES who when they're active are very active for a short period of time, and when they're inactive they're completely inactive. I'd hate to see a useful contributor like that required to spend the entire period they're available just proving they're committed. --valereee (talk) 00:28, 7 October 2019 (UTC)
3. Support. My major problem with resysops is that many returning admins either a) don't really return at all, or b) return and jump right into admin activity without spending time to re-familiarize themselves with the community and its norms. Things do change. There is no deadline to restore the bit. Prove to the community that you are fully re-committed to the project and retain its trust. CThomas³ (talk) 06:56, 7 October 2019 (UTC)
4. Moral support. If we must do something (and I'm still not convinced we do...), then requiring a modest activity (editing) requirement prior to asking bit reinstatement seems like the most sensible way to do it. But I would make it simpler than this: something like "one month of activity" (reasonably defined) or "X edits over Y days" without trying to link it to length of absence. The issue is not "how much has an admin forgotten" or "how much has changed", but whether the person is demonstrating that they are re-engaging with the community in a thoughtful fashion. If yes, I trust them to not screw up if they were trusted once. Martinp (talk) 17:29, 7 October 2019 (UTC)
5. I like this. It's troubling when former admins want to go straight from several years of total inactivity to blocking and deletin again without giving themselves a chance to get up to speed on changes to policy. It provably has led to problems in the past. Beeblebrox (talk) 19:31, 13 October 2019 (UTC)
6. Bad wording ("non-stupid"), arbitrary "N" definition, but the general idea of requiring editor activity before re-granting adminship is helpful. ~ ToBeFree (talk) 22:23, 14 October 2019 (UTC)

   ToBeFree, sure :) I'd say "feel free to improve", but we unfortunately started voting on this RfC before we had time to make well-written proposals. —Kusma (t·c) 09:36, 16 October 2019 (UTC)

7. Moral support. There's an idea here, but this is poorly worded and not very clearly formulated. Try to simplify.  — AReaderOutThataway ^t/_c 06:50, 22 October 2019 (UTC)

Users who oppose statement 8

1. Oppose arbitrary time periods and edit counts, especially when they don't actually fix the problems identified in the first RfC. Thryduulf (talk) 18:01, 6 October 2019 (UTC)

   Thryduulf, I'm trying to solve all the actual problems that I am aware of. Which problems does this not solve? —Kusma (t·c) 18:10, 6 October 2019 (UTC)

   Maybe we should rather be asking which problems it does solve. Unless we can identify at least one problem that it does solve, we don't need it. Of course this goes equally for all the other proposals. · · · Peter Southwood ^(talk): 09:26, 7 October 2019 (UTC)

   I am trying to solve the actual "resysoppings of previously inactive admins that haven't made a single edit other than requesting restoration of the bit at WP:BN tends to annoy a lot of people" problem and the potential "resysopped users do not have enough recent experience to properly use the tools" problem. While I personally believe that resysoppings should be relatively routine, I also think there should be a strong community consensus behind the practice, and I'm not seeing that at the moment. —Kusma (t·c) 12:00, 7 October 2019 (UTC)

2. Oppose weakly. I appreciate the intent but can see issues with evaluating "substantive/constructive edits" Cas Liber (talk · contribs) 01:56, 8 October 2019 (UTC)

   If you have a better formulation, please suggest it. I don't really care what the edits are as long as there is engagement over a period of time and not obvious idiocy. I'd be happy with 50 stub sorts, but not with 50 self-reverts of test edits in a sandbox. —Kusma (t·c) 09:13, 8 October 2019 (UTC)

3. Oppose arbitrary editing requirements. ‑Scottywong| [chat] || 17:44, 9 October 2019 (UTC)
4. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:50, 9 October 2019 (UTC)

   @JzG: This isn't solving any problem with returning sysops, because no such problem exists (most problems we have with out-of-touch sysops are with people who were never desysopped). My question is how we can solve the issue that people are unhappy about some resysoppings. I think requesting a minimal amount of activity (clearly my numbers are made up and not based on science) between returning and requesting the admin bit back would have made people less angry. —Kusma (t·c) 04:10, 10 October 2019 (UTC)

5. Oppose Too vague. What's "N"? Some might consider 1 month to be too short. I think everyone thinks 10000 months is too long. Buffs (talk) 16:19, 10 October 2019 (UTC)

   Buffs, N is the number of years since desysop. —Kusma (t·c) 20:06, 15 October 2019 (UTC)

   So... gone for 4 years = 4 months of 30 "non-stupid" edits? This seems like an arbitrary solution to a problem that doesn't exist due to these reasons. Additionally "non-stupid" is hardly enforceable, clear, or kind. Buffs (talk) 20:41, 15 October 2019 (UTC)

6. Oppose - As elsewhere, it's unclear what evidence there is that there is a problem specific to admins desysopped for inactivity that doesn't apply to any other admins who managed to keep the bit. Also unclear that this would necessarily address those issues aside from demonstrating commitment (in which case, I oppose erecting barriers to good faith admins becoming active again). — Rhododendrites ^talk \\ 17:48, 10 October 2019 (UTC)
7. Oppose Arbitrary time periods ST47 (talk) 06:52, 16 October 2019 (UTC)
8. per everyone above. OhKayeSierra (talk) 07:37, 16 October 2019 (UTC)
9. Oppose - again, this calls on bureaucrats to judge what is a "non-stupid" edit, which creates a process which is not impartial. Ivanvector (^Talk/_Edits) 15:46, 16 October 2019 (UTC)
10. Oppose Hypothetically, this would make the threshold for getting the tools back longer than it was to get them in the first place. No. --Jayron32 18:06, 16 October 2019 (UTC)
11. Oppose as stated because too vague. But asking the admins to first stick around for a while to demonstrate they will be active is probably not totally unreasonable. Kudpung กุดผึ้ง (talk) 20:05, 17 October 2019 (UTC)
12. Oppose too vague: one edit can be anywhere from the complete re-writing of an article to a minor typo fix. Sounds like proposal revolving around editcountitis to me. From AnUnnamedUser ^{(open talk page)} 18:44, 1 November 2019 (UTC)
13. Not a good idea, they are former admins not vandals. -- CptViraj (📧) 03:51, 4 November 2019 (UTC)

Discussion of statement 8

If long-term inactive admins are out of touch, this should help them reconnect with the community, hopefully avoiding the assumptions of bad faith that we sometimes see at WP:BN. —Kusma (t·c) 16:48, 6 October 2019 (UTC)

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

Statement 9 by DESiegel

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Users requesting restoration of sysop flag after being desysoped for inactivity will be requested to state the frequncy of admin actions which they intend to take if the tools are restored to them. If the stated anticipated level is not significant, or if the Bureaucrats do not find the statement credible in view of past history, they may decline the request. Ihe request is declined a user may repeat the request after a period of editing, or may seek appointment via a new RfA.

Users who endorse statement 9

1. As proposer. DES ^(talk)_{DESiegel Contribs} 19:21, 6 October 2019 (UTC)
2. Allows crats to say, "No, dude, that's what you said last time" the next time. --valereee (talk) 23:24, 6 October 2019 (UTC)
3. Supprt the idea but would prefer the community to make the decision. Govindaharihari (talk) 16:40, 7 October 2019 (UTC)
4. Ineffective? It at least requires people to lie if they plan to game the system. ~ ToBeFree (talk) 22:25, 14 October 2019 (UTC)

Users who oppose statement 9

1. Oppose this and similar ideas. Adminship is trust to not break the wiki, not a promise/commitment to use the bit. Martinp (talk) 17:31, 7 October 2019 (UTC)
2. No, subjective and vague. Good intent but hard to police. Cas Liber (talk · contribs) 01:54, 8 October 2019 (UTC)
3. Oppose Ineffective. The admin has no obligation to follow through on any promises they make before the bit is restored. ‑Scottywong| [confess] || 17:45, 9 October 2019 (UTC)
4. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:50, 9 October 2019 (UTC)
5. Oppose - As elsewhere, I oppose erecting barriers to good faith admins who want to become active again, and don't see sufficient evidence that there has been damage done by resysopped admins distinct to that group, as opposed to problems among some admins generally. — Rhododendrites ^talk \\ 17:50, 10 October 2019 (UTC)
6. Oppose per JzG above—comrade waddie96 ★ (talk) 13:49, 12 October 2019 (UTC)
7. Statements of intent are too vague to assess and too easy to game. — JFG ^talk 14:11, 13 October 2019 (UTC)
8. Way too open to gaming and abuse. Beeblebrox (talk) 19:27, 13 October 2019 (UTC)
9. Oppose per JFG and Casliber. —pythoncoder (talk | contribs) 19:20, 15 October 2019 (UTC)
10. Oppose I don't think that most users would be able to accurately predict their edit-count or admin-action-count at the start of any given year. ST47 (talk) 06:54, 16 October 2019 (UTC)
11. per Martinp and JzG. OhKayeSierra (talk) 07:38, 16 October 2019 (UTC)
12. Oppose: Again, not our business. — Javert2113 (Siarad.|¤) 14:41, 16 October 2019 (UTC)
13. Oppose per whichever other comments I've made about bureaucrats making subjective observations. Ivanvector (^Talk/_Edits) 15:47, 16 October 2019 (UTC)
14. Oppose per hat I said about the similar entry up there somewhere. Admins should not have to demonstrate need, only ability to use correctly. --Jayron32 18:07, 16 October 2019 (UTC)
15. Oppose . The suggestion makes sense on the surface, but volunteers cannot be forced to commit to a minimum work schedule. Kudpung กุดผึ้ง (talk) 19:59, 17 October 2019 (UTC)
16. Oppose. This isn't even something one would normally ask during the vicious roasting over hot coals I mean RfA.  — AReaderOutThataway ^t/_c 06:51, 22 October 2019 (UTC)
17. Oppose. There's no obligation to use the tools. Gaelan 💬✏️ 23:46, 27 October 2019 (UTC)
18. This is more like a criminal thing. -- CptViraj (📧) 03:56, 4 November 2019 (UTC)

Discussion of statement 9

• As a major concern is, it seems, hat-collecting by admins who will not actively use the tools, this would require users asking to be re-sysoped to affirm that they intend to make active use, and allow the 'crats to asses such statements for plausibility. DES ^(talk)_{DESiegel Contribs} 19:23, 6 October 2019 (UTC)
• Regarding users clearly doing the bare minimum of contributions to keep their advanced permissions it would be good for a method for a user to nominate the account for community discussion to discuss removal of said permissions. https://en.wikipedia.org/wiki/Special:Log/Srikeit this user was notified on 1 may of pending removal and three hours later made four edits in five mins clearly looking at the accounts contributions it seems apparent the reason for those edits was just to keep his advanced permissions. I chose that account randomly but there are multiple other accounts acting in a similar way. Govindaharihari (talk) 16:27, 7 October 2019 (UTC)
• This statement is incompatible with its proposer's objection to statement 1. It's no less vague or discretionary, and still allows resysopping via a period of editing. The only practical difference I see is that this version does less to encourage the prospective resysoppee from going through that period of editing before asking the bureaucrats instead of after they demand it. —Cryptic 21:40, 14 October 2019 (UTC)

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

Statement 10 by Valereee

Withdrawn by OP — JFG talk 14:13, 13 October 2019 (UTC)

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions: Users requesting restoration of sysop flag after being desysoped for inactivity who have had fewer than 50 edits per year for each of the past three years will be required to make 50 edits per month for six months before resysopping. Users who endorse statement 10 As proposer. Will help cull those who are doing literally nothing for the encyclopedia except responding to desysop warnings with an edit. 50 edits per month for six months is a pretty low bar for proving you're actually interested in contributing. --valereee (talk) 23:33, 6 October 2019 (UTC) Case in point: this user made a request for resysop in July. They've made a total of 1600 edits since 2003 and have made 2 since the request for resysop. This is not someone who is interested in editing at all, much less in using the tools. --valereee (talk) 00:07, 7 October 2019 (UTC) Withdrawing this, as I'm persuaded that arbitrary counts are probably counterproductive. --valereee (talk) 11:37, 7 October 2019 (UTC) Users who oppose statement 10 I agree with the intent, but arbitrary edit counts are at least as likely to be counterproductive as they are to solve the problem. I'd much rather see an admin make 5 quality edits a month than 100 pointless ones (and I speak as someone who makes mostly minor edits to content pages). Thryduulf (talk) 00:12, 7 October 2019 (UTC) Per Thryduulf. Does not actually solve a problem. Any activity criteria should require and measure relevant activity. · · · Peter Southwood (talk): 08:02, 7 October 2019 (UTC) Discussion of statement 10 I like the principle... anything to get rid of 'squatter' admins. Jbh Talk 07:21, 7 October 2019 (UTC) I like the principle here too and am sorry Valeree withdrew it. Best, Barkeep49 (talk) 21:45, 7 October 2019 (UTC)

Statement 11 by Wugapodes

Withdrawn Wug·a·po·des​ 03:13, 19 October 2019 (UTC)
The following discussion has been closed. Please do not modify it.
The following statement should replace the current text of WP:RESYSOP: Requests for restoration of administrator privileges should generally be made at requests for adminship. If an editor voluntarily resigned adminship, they may request restoration of privileges at WP:BN unless they resigned "under a cloud". If there were serious questions about the appropriateness of the former admin's status at the time of resignation, requests for re-adminship at BN will be referred to WP:RFA. In cases where it is not clear whether adminship was resigned under a cloud, any bureaucrat may refer the request to WP:RFA. Users who endorse statement 11 Wug·a·po·des​ 23:50, 6 October 2019 (UTC) Yes. Seems to essentially be a restatement of several of the earlier proposals all wrapped into one. Whether this is adopted as written or something similar grows out of the implementation I think the idea that the default for long inactive admins should be RfA is the direction WP policy should be headed. Jbh Talk 07:25, 7 October 2019 (UTC) I like this best of all the current proposals. It encourages people to become active in editing for a period of time in order to show the community that they're both getting themselves up to speed on changes and are willing to actually become active. The fact they were trusted before becomes a positive factor in their RfA, as there would be no reason to believe they couldn't be trusted again. I suspect even former admins who've been completely inactive for years could get themselves to that point in a few months, and if someone isn't willing to make that much of a commitment, they probably aren't actually interested in building the project. In the case of editors like DES, who show a pattern of high activity followed by periods of none at all, a successful RfA could probably be run immediately. --valereee (talk) 11:29, 7 October 2019 (UTC) Yes combined with 7. Could be that a benefit would also be to change the time limits to actual use of the tools rather than just time limits, users not using the advanced permissions for two years clearly don't need them. Govindaharihari (talk) 15:23, 7 October 2019 (UTC) Govindaharihari You should be aware that there are (or have been at least) editors who use admin right primarily to examine deleted pages in order to properly fix attributions and other gnomish but useful tasks. Thsi requires admin rights but is not a logged admin action. There may be other similar cases. DES (talk)DESiegel Contribs 23:54, 7 October 2019 (UTC) DESiegel Thanks, after reading the opposes, your comments especially I am withdrawing my suppport for this proposal. Govindaharihari (talk) 00:02, 8 October 2019 (UTC) Extreme but useful approach: RfA is for requesting adminship. Returning ex-administrators should have to use it like everyone else. Perhaps we shouldn't need to re-sysop users at any other venue. ~ ToBeFree (talk) 22:30, 14 October 2019 (UTC) Users who oppose statement 11 I support the part which would give bureaucrats more leeway to consider the situation at time of (voluntary) resignation, and therefore tighten the hatches on resignations until controversy dies down. However, it seems like this proposal also channels all re-admins after inactivity to RFA, and I disagree with that. We can debate the precise criteria, but for security reasons it is reasonable to have procedural deadminning, with readmin on demand, happen after a much more modest level of inactivity than "you need to go through RFA"-level inactivity. Martinp (talk) 17:42, 7 October 2019 (UTC) We have over the last 10 months seen a variety of circumstances where one crat feels free to go rogue with something. I have seen too many crats, in actions I both support and don't, fail to be conservative with their discretion. The crats as a body, however, retain my confidence and so if the decision was invested with them as a group than any individual crat I could probably get behind it. Bigger picture, I can support the general principle here that only uncontroversial candidates should be able to resysop in our current manner. But I have no reason to think that the crowd that hangs out at BN is reflective of the community as a whole - just as we recently saw that the crowd which hangs out at ACN/proposed decisions is different than the community as a whole. While again I would trust the crats as a body to weigh all these factors I have no confidence that an individual crat wouldn't see 5 people trying to make a point - against policy - and say "off to RfA you go" where the person is then confirmed by some clear percentage. Best, Barkeep49 (talk) 22:00, 7 October 2019 (UTC) Strong Oppose. As Written this seems not to handle the case of admins with the flag removed for inactivity, which is, i gaher, the prime case that people want handled. It seems entirely directed to those who resigned, and since is says it is a replacement, not an addition, this is a fatal flaw. Furthermore, the statement of purpose, to allow restoration at BN only for the very clearest possible cases, requiring an RfA for everyone else, seems likely to have the effect of excluding some returning admins who would do positive work, but will not go through a new RfA. I'm not sure that I would be willing to go through a new RfA. DES (talk)DESiegel Contribs 22:47, 7 October 2019 (UTC) It does cover re-requests after inactivity; as written such editors would be required to request adminship at requests for adminship. The first sentence of the statement gives a general rule, the rest is to state an exception to that rule. Any of these proposals, due to them all being related to strengthening resysop criteria, would likely exclude some returning admins who would do positive work. If a returning admin feels they would not pass an RfA, we should ask why they think they would not pass. In what situations should an editor who would not pass an RfA be unilaterally resysoped at BN? Wug·a·po·des​ 23:27, 7 October 2019 (UTC) Wugapodes, In that case I oppose yet more strongly. An RfA today is a major effort, requiring lots of work and near total focus by the candidate before and during the discussion. I think I would pass if I had to reconfirm, but I also would quite likely not be willing to bother going through that again. This proposal seems likely to cost the project more than it gains. DES (talk)DESiegel Contribs 23:49, 7 October 2019 (UTC) DESiegel, RfA has changed a lot, actually. It's not nearly as bad as it was even a few years ago. Someone with your history might get a question like the one I asked when you requested, but probably not even that if you just explained up front. Maybe what we need is for resysop candidates to explain any concerns someone might have rather than simply popping into BN and flatly asking. I honestly wonder if part of the concern among non-sysops is that it just feels so entitled. Oh, hello, old boy. Locked m'self out, let me back in, there's a good chap. --valereee (talk) 11:38, 8 October 2019 (UTC) Oppose requiring another RfA for admins that simply went inactive for a time. There should be some limit on inactivity, after which an RfA should be required, but it should be rather long. If someone is only inactive for a year and their bit is taken away, and then they return the next month, they shouldn't have to go through another RfA. Otherwise, this proposal looks ok. ‑Scottywong| [squeal] || 17:51, 9 October 2019 (UTC) Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:51, 9 October 2019 (UTC) Too far. No policy for bits removed for inactivity seems counter-productive, and other proposals (like #1 and #7) are likely to work in concert to be a more effective means of managing resysops. ~ Amory (u • t • c) 21:46, 13 October 2019 (UTC) This doesn't seem to fix the primary issue, and doesn't go far enough to fix things that it is bringing up. — xaosflux Talk 22:56, 13 October 2019 (UTC) Oppose inactivity desysops should not require RFA. ST47 (talk) 06:56, 16 October 2019 (UTC) Oppose per ST47. OhKayeSierra (talk) 07:39, 16 October 2019 (UTC) Oppose: per ST47. — Javert2113 (Siarad.|¤) 14:43, 16 October 2019 (UTC) Oppose - automatically makes inactivity desysops equivalent to desysops for misconduct. Hard no. Ivanvector (Talk/Edits) 15:49, 16 October 2019 (UTC) Oppose I find this confusing, it makes it unclear as to which should require RFA and which require BN. Also mirror the above, admins who lost the bit in good standing, either through good-faith resignation in good standing or inactivity should be considered to still be approved by the community for the bit, and should get to keep it. --Jayron32 18:09, 16 October 2019 (UTC) Oppose per Jayron32 really Cas Liber (talk · contribs) 09:44, 17 October 2019 (UTC) Oppose per Scottywong. Kudpung กุดผึ้ง (talk) 19:57, 17 October 2019 (UTC) Discussion of statement 11 Many editors seem to want stricter criteria, but cannot agree on what arbitrary metrics to use. Inspired by Xaosflux's comment at the first RFC (which is what convinced me to switch from status-quo to stricter), I'm suggesting we close the loopholes and only resysop at BN in the most unambiguous cases. It should be no big deal to use Wikipedia:Requests for adminship to request adminship, and if an editor has been inactive long enough to be desysoped, 7 more days of waiting is a drop in the bucket. Xaosflux suggested a 1 year time limit for re-requests at BN, but I wanted to avoid arbitrary time limits and thresholds in this statement. Anyone who thinks that is a good idea may add it as an additional statement. Wug·a·po·des​ 23:50, 6 October 2019 (UTC) I haven't formulated a statement for this yet, but it is also possible that multiple changes get passed here, and they would not need to be mutually exclusive. — xaosflux Talk 00:39, 7 October 2019 (UTC) I can imagine Amory's statement in 2.7 fitting in well with this proposal. It would essentially just be a limit on the time that an admin who resigns voluntarily could make a request at BN. Wug·a·po·des​ 17:05, 7 October 2019 (UTC) * I would support this in theory. I wouldn't like to see running an RfA as a barrier in the case of former good admins who had made a lot of difficult decisions and possibly made enemies as a result. This might need input from admins who might face this situation. --valereee (talk) 00:24, 7 October 2019 (UTC) Persuaded by Wug below --valereee (talk) 20:18, 7 October 2019 (UTC) I agree, but I trust our bureaucrats to understand the context in those situations and discount vendetta opposes. We've had three former admins run RfAs this year and one went to Crat Chat (Floquenbeam 2). Though I opposed in that RfA, I think the crats did a good job of weighing consensus, and in a number of cases stated that they were aware reconfirmation RfAs are likely to attract vendetta opposes. Dweller quotes Maxim in a 2014 crat chat as saying "traditionally, some leniency has been given, especially percentage-wise, as a former admin may attract opposition that is nowhere near objective in their reasoning". So while I think more input is beneficial, given how crats have understood reconfirmation RfAs I don't think old beefs are a huge concern. Wug·a·po·des​ 20:02, 7 October 2019 (UTC) Are sure this is sufficient to replace the entirety of the text WP:RESYSOP? Might there be some stuff that needs to be carried over? Lepricavark (talk) 14:20, 7 October 2019 (UTC) No, not sure at all, I'd be very open to others suggesting things they believe should be carried over. I just think it may be more efficient to start from the narrowest criteria and widen it than starting from the currently wide criteria and narrowing them. Wug·a·po·des​ 17:05, 7 October 2019 (UTC) Are Admins that resign still affected by the inactivity time limits, if not I would like to see that changed, I now see that seven sorts the resign situation by including the words 'regardless of the reason for removal' then a combination of seven and 11 would create a possible solution to concerns. Govindaharihari (talk) 14:39, 7 October 2019 (UTC) Govindaharihari, the language you like in proposal 7 is the exact and current language already in use at Wikipedia:Administrators#Lengthy inactivity. ~ Amory (u • t • c) 15:11, 7 October 2019 (UTC) Thanks. Good to know that is already there. It is the reduction in time limits change that is the improvement provided in 2'7 then, regards. Govindaharihari (talk) 15:28, 7 October 2019 (UTC) Martinp what do you consider to be "you need to go through RfA" inactivity? --valereee (talk) 20:13, 7 October 2019 (UTC) Is this basically "if you want to become inactive, please resign your admin bit, then you can maybe have it back later, but if you just become inactive without telling us, you'll have to go through RFA?" —Kusma (t·c) 09:48, 9 October 2019 (UTC) That's what it sounds like to me, which seems far stricter than folks would want. ~ Amory (u • t • c) 21:33, 13 October 2019 (UTC)

Statement 12 by Govindaharihari

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

---

The following statement should be added to WP:ADMIN in the section concerning restoration of permissions:

Admins making clearly minimal edits to keep their advanced permissions and Users that have been desysopped through lack of activity and have their permissions returned under the conditions of WP:RESYSOP by the WP:CRATS and then continue to have no or minimal activity can be subject to a community discussion and removal of those permissions if such a consensus arises. If removal occurs any further request for resysop would require a WP:RFA. Any Admin supported in the discussion would restart the clock as far as WP:RESYSOP is concerned.

Users who endorse statement 12

1. This could solve one of the concerns expressed regarding administrative accounts who only do token edits to retain tools Govindaharihari (talk) 21:41, 7 October 2019 (UTC)
2. This seems to actually address the percived problem. But to be imple,mented, we will need lots' of detail on the "community discussion" process. Who may start it, how is it to be started, who judges consensus and by what standard, and so on. DES ^(talk)_{DESiegel Contribs} 22:52, 7 October 2019 (UTC)
3. Support per Govindaharihari. —comrade waddie96 ★ (talk) 13:50, 12 October 2019 (UTC)
4. Moral support – I agree with the intent, but the process looks complex to enforce, and likely to stir drama. Might as well give some leeway to the crats per proposal #1. — JFG ^talk 00:13, 14 October 2019 (UTC)
5. Good, important laws can be vague. At least it is not possible to game this system; it nicely deprecates all the various attempts to game the system. ~ ToBeFree (talk) 19:37, 14 October 2019 (UTC)
6. Support, but clarify the wording. If there is every an opportunity to shut down any avenue for WP:GAMING, do it. It needs to be more concrete, though, per some of the opposes below that don't seem to object in principle just to the vague wording.  — AReaderOutThataway ^t/_c 06:53, 22 October 2019 (UTC)

Users who oppose statement 12

1. Oppose - Far too vague. What constitutes "clearly minimal edits", and how do we judge whether these edits are only being made with the intention "to keep their advanced permissions"? This leaves far too much open to interpretation. ‑Scottywong| [confer] || 17:53, 9 October 2019 (UTC)

   Hi. Those concerns would be for the community to judge through comments and consensus. I fully trust the community to assess your concerns, What constitutes "clearly minimal edits", and how do we judge whether these edits are only being made with the intention "to keep their advanced permissions" I accept this idea would need tightening. Govindaharihari (talk) 19:17, 9 October 2019 (UTC)

2. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:51, 9 October 2019 (UTC)

   Hi. The problem has been identified in the previous RFC. This follow up RFC is an effective and transparant way of resolving the communities concerns. Unless the concern is resolved here and or in more discussions the communities concern will quite quickly occur again. Govindaharihari (talk) 22:23, 9 October 2019 (UTC)

3. Oppose - This gets at more of the issue than most of the other proposals, but I see no reason why this should be the only case in which a community discussion can result in desysopping. — Rhododendrites ^talk \\ 17:53, 10 October 2019 (UTC)
4. Oppose This essentially creates a recall "vote", which I don't support and which is out of scope for this discussion, which is about resysop criteria. ST47 (talk) 07:00, 16 October 2019 (UTC)
5. Oppose Recall votes are outside of the scope for this RfC. OhKayeSierra (talk) 07:40, 16 October 2019 (UTC)
6. Oppose because I don't really understand what is being proposed, but it feels like back-door recall. Ivanvector (^Talk/_Edits) 15:53, 16 October 2019 (UTC)
7. Oppose unless and until a workable community de-sysop system is put in place, this sort of proposal is a nonstarter. --Jayron32 18:10, 16 October 2019 (UTC)
8. Oppose vague and subjective (though I do think the intent is commendable) - will lead to arguments. Cas Liber (talk · contribs) 09:45, 17 October 2019 (UTC)

Discussion of statement 12

Agree with User:DESiegel that who may start it, how is it to be started, who judges consensus and by what standard are all points to be resolved. I also think that if a clause like this was added it would make the users in question actually ask themselves, am I going to use and do I really need the permissions. It would also allow for very experienced admins sitting on their hands that are supported by the community, I would not expect these users to be challenged, to be differentiated from accounts whose lack of edits would cause more concerns to users. Govindaharihari (talk) 23:06, 7 October 2019 (UTC)

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

Statement 13 by Cyp

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

---

Instead of trying to find ways of restricting people from keeping the sysop bit, the focus should be on figuring out how to get more (competent) people to apply for and pass RfAs.

Text here

Users who endorse statement 13

1. This one sounds like a good idea. Κσυπ Cyp   08:19, 8 October 2019 (UTC)
2. We certainly should encourage more people to become admins, no matter what we do about people who have been admins in the past. —Kusma (t·c) 09:11, 8 October 2019 (UTC)
3. Yes please. -- Ajraddatz (talk) 13:45, 16 October 2019 (UTC)
4. This is not unreasonable, although a tad trivial. Stifle (talk) 09:39, 17 October 2019 (UTC)

Users who oppose statement 13

1. This appears to be a loaded statement, since many supporters of the above proposals cited other rationales instead of "restricting people from keeping the sysop bit". I agree that higher RfA participation from qualified candidates is a good thing. — Newslinger talk 11:38, 8 October 2019 (UTC)
2. Per Newslinger and Valereee. There's an important difference between what to do with someone who no longer has the admin bit and someone who still has the admin bit. I don't understand why we would encourage editors who have never been admins to go through RfA, but for editors who left for long periods and lost the bit, not encourage them to also go through RfA. It is not and should not be a hazing process; it's a permissions request. If we're going to advocate editors go through RfA to get the bit, we should encourage all editors to go through RfA to get the bit except in the most clear cases. Wug·a·po·des​ 20:16, 8 October 2019 (UTC)
3. Oppose unless you can show me at least two instances where this would have solved a problem, and would have been the most effective and transparent way of solving it. Guy (help!) 21:52, 9 October 2019 (UTC)
4. No. --Rschen7754 18:31, 10 October 2019 (UTC)
5. The hypocrisy is real -FASTILY 23:28, 11 October 2019 (UTC)
6. Part one RfC already settled if the primary direction of this RfC should be followed up on. Feel free to pursue retention efforts elsewhere. — xaosflux ^Talk 13:40, 12 October 2019 (UTC)
7. Valid concern, but does not address this particular discussion. — JFG ^talk 13:55, 13 October 2019 (UTC)
8. False dichotomy. Beeblebrox (talk) 19:25, 13 October 2019 (UTC)
9. oppose "against all other statements" statement ~ ToBeFree (talk) 22:33, 14 October 2019 (UTC)
10. False dichotomy. Though I get where the nominator is coming from. Cas Liber (talk · contribs) 09:46, 17 October 2019 (UTC)
11. Out of scope for this RfC. Kudpung กุดผึ้ง (talk) 19:52, 17 October 2019 (UTC)
12. Objection, with trout on the side. It is out-of-scope, a false dichotomy, content-free (if you have a real proposal, then write one somewhere), and also unconstructive whining, obstructionism, and what-if'ing.  — AReaderOutThataway ^t/_c 07:02, 22 October 2019 (UTC)

Discussion of statement 13

• Cyp, you realize that non-sysops voted like 39-8 to say the resysopping on request process was a problem and should be tightened? This is an important issue to people who aren't sysops. I feel like this proposal is saying, "We heard your concerns, but we don't think what you think is a problem is actually a problem." And I agree with Newslinger, the statement is loaded. I agree with you that the RfA process needs to be fixed too, but this proposal doesn't address what has been identified by non-sysops as a problem. --valereee (talk) 12:01, 8 October 2019 (UTC)

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

Statement 14 by Valereee

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

---

Given that non-admin users, including some of the community's most respected, voted 39-8 that our resysopping policy needs tightening, we recognize the RfC results represent an actual problem the community needs to find consensus to address.

Users who endorse statement 14

1. As proposer --valereee (talk) 13:07, 8 October 2019 (UTC)
2. As a sysop. Thryduulf (talk) 16:49, 8 October 2019 (UTC)
3. Support for the symbolism and recommitment of the first RfC. Ultimately we should be figuring out how to tighten but reaffirming that we remain committed to tightening remains important for any potential closer when considering what weight to give to comments and discussion here. Best, Barkeep49 (talk) 16:55, 8 October 2019 (UTC)
4. Wug·a·po·des​ 20:19, 8 October 2019 (UTC)
5. Govindaharihari (talk) 20:32, 8 October 2019 (UTC)
6. — Newslinger talk 06:23, 9 October 2019 (UTC)
7. The re-sysop procedures (whatever they are) need to have wide community consensus behind them. Our current procedures don't. I'm not sure this RfC is going to fix this, but we should find a way to make the process appear fair (plus we should also fix practical issues, almost all of which are actually related to retention of sysop privileges as much as to resysopping). —Kusma (t·c) 09:36, 9 October 2019 (UTC)
8. As a sysop. SQL^{Query me!} 17:26, 9 October 2019 (UTC)
9. feminist (talk) 12:29, 10 October 2019 (UTC)
10. Support. I don't even have to have been on the "winning" side of that RfC to recognize the result. Buffs (talk)
11. Pharaoh of the Wizards (talk) 11:37, 12 October 2019 (UTC)
12. The first part of the RfC has identified a real concern, so there is a community mandate to tighten resysop terms. — JFG ^talk 13:57, 13 October 2019 (UTC)
13. Yeah, this shouldn't be a place to re-litigate what has already been decided. There is a real problem. Beeblebrox (talk) 19:25, 13 October 2019 (UTC)
14. OK. The "actual problem" may be as simple as 'we want a new standard', but that was part 1. — xaosflux ^Talk 22:57, 13 October 2019 (UTC)
15. ~ ToBeFree (talk) 19:31, 14 October 2019 (UTC)
16. per Barkeep49. OhKayeSierra (talk) 07:43, 16 October 2019 (UTC)
17. A straw poll of 47 editors can hardly be expected to demonstrate a widespread consensus, but the weight of that poll merits further attention. Ivanvector (^Talk/_Edits) 15:58, 16 October 2019 (UTC)

    It was 96 editors, not 47. 47 was just the non-admins. —Cryptic 21:53, 16 October 2019 (UTC)

    Fair point, but if the premise of the proposal is based on the proportion of non-admins who commented, then my observation is valid. Or what was the weight among admins who commented? Was it significantly different? Ivanvector (^Talk/_Edits) 23:58, 18 October 2019 (UTC)

18. Neutral leaning support, which is why I put this here. Generally, more people who dislike the status quo show up to comment on discussions where the status quo is being questioned, so I doubt the utility of such a small poll anyways. Basically, only the people with something to complain about show up to vote anyways, so I always take such polls with a grain of salt. That being said, it's not nothing, so it merits further study. But don't grant such a vote as having more meaning than it does. --Jayron32 18:13, 16 October 2019 (UTC)
19. Errr.....ok? I get where you're coming from but not sure what the desired outcome is here. Does it mean we accept the top recommendations even if they don't pass? Or.... I think my view would be that the first RfC suggests rather strongly (but does not prove as such) a need to change things. Hence I (personally) would be happy to take on board any of these proposals that actually pass. And if it is none, then it is none. Cas Liber (talk · contribs) 09:50, 17 October 2019 (UTC)
20. Pawnkingthree (talk) 20:21, 17 October 2019 (UTC)
21. Endorse. While consensus is not a vote, when it's that much of a landslide it cannot be ignored.  — AReaderOutThataway ^t/_c 07:04, 22 October 2019 (UTC)

Users who oppose statement 14

• Oppose, as a non-admin. The July RfC was poorly advertised, and the timing, smack in the middle of Framgate, was really bad. I don't believe the RfC was ever advertised at WT:RFA, in particular. At least I could not find any threads at WT:RFA regarding that RfC. Notably, the number of participants in the RfC seems to have been lower that in a typical RfA. That's not how significant policy changes should be handled. A great many people have the WT:RFA page watchlisted, but relatively few have WP:Administrators watchlisted, where the RfC was held. A somewhat larger number of people have WP:BN watchlisted (where there was in fact a notice given about that RfC), but still, far fewer than those who watchlist WT:RFA. Moreover, the July RfC came right in the middle of the Fram Affair, and the people's attention was mostly preoccupied by that at the time. Most posts at WP:BN in July are related to Framgate-induced admin resignations and then resysop requests. The RfC notice was easily lost among all that Framgate traffic. I am sure that a great many people interested in the RfA process did not know that that the RfC was going on (I myself had no idea; I basically tuned out WP:BN at the time, to avoid the Framgate related drama fest.) If the same RfC was held today, with a notice given at WT:RfA, I am sure that the number of participants would have been significantly larger and the results are likely to have been different as well. Nsk92 (talk) 07:06, 9 October 2019 (UTC)

Nsk92 We're talking about an RfC that was open for months and just closed, well after the Fram thing was over? Plenty of people got there, including some of the more thoughtful people in the community, and a lower than normal absolute number doesn't change the fact that there's a very deep divide over this issue between admins and non-admins who did show up. What makes you think those percentages would have changed if there were twice as many attendees? Are you saying the RfC was invalid and proposing that it should not be taken as a valid RfC? Because if that's what you're proposing, you should put up a statement, but I have to say that it kind of feels not right to say we should have to hold it again before you'll believe the results. --valereee (talk) 09:29, 9 October 2019 (UTC)

I'm a bit confused Nsk92 how you wish the first RfC had been better advertised. It was advertised on the Bureaucrats noticeboard, Administrators noticeboard, Village Pump, and at Centralized discussions. Obviously some topics attract more editors to participate than others but it feels like this was advertised pretty widely. Best, Barkeep49 (talk) 00:30, 10 October 2019 (UTC)

• 38-8 represents under 0.04% of active editors. Guy (help!) 21:54, 9 October 2019 (UTC)

What is considered a quorum?--WaltCip (talk) 12:25, 10 October 2019 (UTC)

• I disagree that because 39 people feel a change needs to be made, therefore it's "an actual problem the community needs to find consensus to address". Specifically, I disagree that the community "needs" to address it. Rather, I think it's the reverse: if 39 people feel a change needs to be made, it's up to them to propose a solution that the community gets on board with. It's not up to the community to find a way to make the 39 happy. – Levivich 18:02, 10 October 2019 (UTC)
  • And just to add: this is exactly like, if you ask 100 people if taxes should be lower, you'll get 100 people saying yes. Ask them which taxes should be cut – and which programs should be eliminated due to lack of funding – and all of a sudden, you can't get agreement about lowering taxes anymore. This happens all the time in the real world, and I think it's what's happening here. "The devil is in the details." – Levivich 18:05, 10 October 2019 (UTC)

    Levivich, I'm sorry, but you're arguing that this is just 39 people's point of view so it doesn't mean anything? It's ~80% of non-admin !voters, and the overall vote represents ~2/3 overall !voters in an RfC's point of view. Are you saying we need to poll all however-many-thousand currently active editors there are to make sure they agree with a particular !vote before we can make a policy change? I'm flummoxed. --valereee (talk) 10:10, 11 October 2019 (UTC)

    Valereee (FWIW I didn't think "wtf" was snippy, I think it's a perfectly acceptable expression of exasperation or shock.) Closer to 3/5 than 2/3 overall, but I see your point about 4-out-of-5 non-admin not-voters (heh). If any of these statements got 39-8 support, of course I'd think that was sufficiently-clear consensus to implement the policy change. What I'm saying is, the 39-8 outcome doesn't mean we must do something. It's not surprising to me that 39-8 say "stricter", but when it comes to "how, exactly", nobody can agree on that. Note, not all of the 39 have come here and !voted. This shows to me that it doesn't piss them off that much. Think of how many editors posted at Framgate–hundreds–that's a "something must be done" situation. Admittedly, 3,000 is an exaggeration, but 300, or 100, is not. – Levivich 17:40, 11 October 2019 (UTC)

    Levivich, but nothing we do here is set in stone just from this RfC, either. Someone can propose a statement that the three most-popular solutions be workshopped, or proposed in a new RfC that is advertised on the watchlist, or both, or whatever other way anyone wants to propose that would allow them to reassure themselves that this indeed is what the community wants. And even then nothing's ever set in stone. Tweaks to policy happen all the time. And thank you for assuming good faith, much appreciated. --valereee (talk) 11:27, 12 October 2019 (UTC)

• I see no point objecting to the numbers themselves. Our decision-making processes fall apart if we say "yeah there was a clear consensus among participants in that discussion, but there were only 40 people there". What I'm opposing is the implication here that we must change our processes regarding resysopping based on that RfC. Yes, there was a problem identified, but like I originally wrote in the discussion below, that there are problems associated with resysopping doesn't mean that the cause of those problems can/should be addressed by changing resysopping policies. — Rhododendrites ^talk \\ 15:01, 12 October 2019 (UTC)
• Not clear what this proposal is intended to accomplish. ST47 (talk) 07:01, 16 October 2019 (UTC)

  ST47, it's intended to gain agreement on whether what multiple commenters on other threads/proposals are saying: that even though the RfC consensus said there was a problem, there's not actually a problem. I believe the first RfC should be taken as evidence that there is indeed a problem, and this proposal is intended to get agreement on that. --valereee (talk) 19:13, 16 October 2019 (UTC)

Discussion of statement 14

• A quick look at the RFA shows a deep divide between admins and non-admins on this issue. Non-admins, who voted nearly 80%-20% for tighter policy, include some of our most respected users and three who, in the weeks since, have become admins themselves. These are people who do a lot of the heavy lifting around here and have proven their commitment to the project. If they think there's a problem, it shouldn't be dismissed as 'a solution looking for a problem' or 'not broke, don't fix it' by admins. --valereee (talk) 13:07, 8 October 2019 (UTC)
• The RfC identified a symptom of a problem. The symptom needs addressing not by trying to layer process onto the symptom, but by fixing the underlying cause. It identified that it's unclear what we should do with incompetent, inactive, or otherwise unfit users who were admins and request it back, and that perhaps something should be done about that. The cause is that we don't have a reasonable way for the community to take away admin privileges in general, not that we need lots more barriers erected when someone, regardless of whether they've demonstrated unfitness for adminship, asks for the bit back. — Rhododendrites ^talk \\ 17:58, 10 October 2019 (UTC)
  • I buy your underlying point, but this is another false dichotomy. If your tooth has a giant hole in it and gets infected, and you can't get a dental appointment until next month, then you damned well take an antibiotic even if you have to go to an urgent care clinic to get one. It's perfectly valid to treat a symptom in the absence of a complete cure. And when it comes to adminship-anything a complete cure is never, ever going to happen. We've had 18 years to get it right, and nothing arouses more controversy than trying to adjust the adminship "system" (more like clusterfuck) in any way at all, no matter how common-sensical any given proposal is. The fact that this set of proposals has come this far verges on miraculous-looking, but really reflects the fact that the community (the vast majority of which are not admins, and a substantial majority of which have been burned by incorrect/inappropriate admin behavior one or more times, with no practicable recourse) are nearing the fed-up limit and finally pulling in the reins. If admins in particular are opposed to this, I would have to think we'd expect that. Those with power rarely go along with that power being restricted more tomorrow than it was today.  — AReaderOutThataway ^t/_c 07:11, 22 October 2019 (UTC)

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

Statement 15 by JzG

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

---

Wikipedia should not be in the business of writing processes to avoid the stupid thing Bob did once. Any proposed solution must first require credible evidence of both a problem that it would have fixed, and the absence of any simpler or more efficient way of fixing that problem. Guy (help!) 22:00, 9 October 2019 (UTC)

Users who endorse statement 15

1. As proposer Guy (help!) 22:00, 9 October 2019 (UTC)
2. Take anything whatsoever and call it X; the way we handle X, probably pisses off 39 people. If we did it differently, another 39 people would then become pissed off. "39 people are pissed off" is just not a basis for change, in my opinion. If it was 3,000, I'd feel differently. – Levivich 17:59, 10 October 2019 (UTC)

   If it was three thousand that would be totally unheard of here, two hundred comments is a rare occasion and only happens as I am aware in a few RFA, Even arbcom elections don't get anywhere near 3000 votes. There is a community concern here and setting totally unrealistic levels of comment to make you accept that is excessive beyond belief imho. This is not a all user arbcom election it is a simple policy RFC discussion. Govindaharihari (talk) 18:18, 10 October 2019 (UTC)

3. This should be obvious. DES ^(talk)_{DESiegel Contribs} 02:51, 13 October 2019 (UTC)
4. Support, though I think that hard cases make bad law should have been cited instead of written the way it was above, I get the drift here and support the sentiment. --Jayron32 18:14, 16 October 2019 (UTC)
5. Careful, Guy, you're applying a dangerous amount of common sense here. Stifle (talk) 09:36, 17 October 2019 (UTC)
6. Support in principle....though unsure of how this works in practice Cas Liber (talk · contribs) 09:48, 17 October 2019 (UTC)
7. Support (at the very least in principle) per Cas and Jayron. I'd also say that if this were real life (as opposed to Wikipedia), they I'd support per DESiegel and common sense. Still, this is wiki, and for some reason, people like to change anything they can here. — Ched (talk) 05:30, 19 October 2019 (UTC)

Users who oppose statement 15

1. It is easy to oppose this as it doesn't appear to accept the communities concerns at all. Govindaharihari (talk) 18:24, 10 October 2019 (UTC)
2. Superfluous straightjacket. The community can find consensus for or against various proposals without having to prove a negative: the absence of any simpler or more efficient way of fixing that problem. — JFG ^talk 00:17, 14 October 2019 (UTC)
3. Unhelpful to the discussion, see statement 14 instead. ~ ToBeFree (talk) 19:29, 14 October 2019 (UTC)
4. per JFG. OhKayeSierra (talk) 07:44, 16 October 2019 (UTC)
5. Don't see any needs for a restriction of proposed solutions. Lepricavark (talk) 15:11, 16 October 2019 (UTC)
6. Failing to acknowledge community concerns over weaknesses in processes (or actively suppressing those concerns) is not a good starting point for reviewing and developing policy. Besides, did you see what Bob did? We need fewer Bobs. Ivanvector (^Talk/_Edits) 16:01, 16 October 2019 (UTC)
7. Re: "and the absence of any simpler or more efficient way of fixing that problem" – if a viable proposal is presented, the burden of proof falls on the opposers of the proposal to show that better alternatives exist. — Newslinger talk 00:19, 18 October 2019 (UTC)
8. Per Newslinger. feminist (talk) 03:00, 18 October 2019 (UTC)
9. Per JfG. Thryduulf (talk) 02:14, 19 October 2019 (UTC)

Discussion of statement 15

Guy, of course WP shouldn't be in the business of writing processes to fix the stupid thing Bob did once. But that's not what this is in my opinion, so I can't vote either way. And of course any solution must first require credible evidence of a problem that it would have fixed. But in my opinion the credible evidence of a problem is the fact non-admins voted nearly 5-1 that they believe there's a problem, so again I can't vote either way. And if you have a simpler or more efficient way of solving this problem, I'd love to vote for it, but without a suggestion I again can't vote either way. --valereee (talk) 17:33, 10 October 2019 (UTC)

• Levivich, can you show me a single RfC, or any discussion anywhere on-wiki that's had 3,000 supports? SQL^{Query me!} 18:06, 10 October 2019 (UTC)

  Sure: Arbcom elections. To be fair, it's 1,000 "supports", but 3,000 votes overall. – Levivich 18:12, 10 October 2019 (UTC)

  Wrong Levivich, totally wrong. Arbcom elections are neither a debate nor a discussion. They are a straight, secret poll. Coloured by pre-election political campaign style questions, comments, and 'user guides', which are more mischief than meritable. Kudpung กุดผึ้ง (talk) 19:41, 17 October 2019 (UTC)

  Plus a loaded election system that you won't find pretty much anywhere else in the world for anything: You get to vote for who you like, and have a vested interest in voting oppose against all others, even if you don't have an actual issue with them, just simply because they're not your top pick. It's dirt stupid, and has several times resulted in arbs being elected who had less support than other candidates but more anti-votes by people trying to exclude everyone but their favorites. Totally farcical.  — AReaderOutThataway ^t/_c 07:17, 22 October 2019 (UTC)

1. Support the basic principle in general, but it isn't really applicable to this matter.. We already have an essay on this concept, at WP:Asshole John rule, and WP:CREEP is also relevant more broadly. However, the overwhelming confirmation by previous RfC respondents (a landslide majority, especially among non-admins) that there is a real problem and what that problem is and roughly how to fix it makes #15 here a moot point.  — AReaderOutThataway ^t/_c 07:17, 22 October 2019 (UTC)

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

Statement 16 by Wugapodes

Spun out to Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedure –Wug·a·po·des​ 00:30, 18 October 2019 (UTC)
The following discussion has been closed. Please do not modify it.
There should be a binding community desysop procedure. Users who endorse statement 16 feminist (talk) 12:24, 10 October 2019 (UTC) Sure, but I brought it up below rather than adding a proposal myself because I see it as an alternative to all of these proposals -- addressing the underlying issues that reach beyond resysopping. — Rhododendrites talk \\ 14:22, 10 October 2019 (UTC) This is it. Govindaharihari (talk) 15:08, 10 October 2019 (UTC) – Levivich 18:06, 10 October 2019 (UTC) Absolutely! Buffs (talk) 22:20, 10 October 2019 (UTC) I've been arguing for this for a long time. GMGtalk 20:32, 11 October 2019 (UTC) FASTILY 23:28, 11 October 2019 (UTC) —comrade waddie96 ★ (talk) 13:51, 12 October 2019 (UTC) I have supported that position for years. DES (talk)DESiegel Contribs 02:53, 13 October 2019 (UTC) More general, there should be a binding desysop procedure (more effective than the present ArbCom litigation), community or not. Incnis Mrsi (talk) 18:49, 13 October 2019 (UTC) That's a blind spot, and a root cause for inefficiency. Hammering out a fair process will obviously require a third RfC, informed by a prior discussion of potential formats. — JFG talk 00:52, 14 October 2019 (UTC) Please do not only have a look at Wikimedia Commons when evaluating this. Such a procedure exists on the German Wikipedia since 2009, with 227 recalls resulting in 46 voluntary resignations, 48 desysops for not starting an RfA, 55 failed RfAs and 78 successful RfAs.[p] Any procedure will be either ineffective or abusable, but unnecessary recalls (resulting in a confirmation of trust by the larger community at RfA) are a necessary evil. Adminship is justified by community trust, and the community needs to have a standardized, binding way of dealing with a loss of adminship justification. ~ ToBeFree (talk) 13:38, 14 October 2019 (UTC) Community consensus is required to promote an administrator, I don't see why it shouldn't be able to remove one. Vermont (talk) 04:07, 15 October 2019 (UTC) Calidum 03:06, 16 October 2019 (UTC) Yes please! -- Ajraddatz (talk) 13:46, 16 October 2019 (UTC) Almost all of the opposition is based on the scope of this RfC and not on the idea conveyed within this statement. Interesting. Lepricavark (talk) 15:05, 16 October 2019 (UTC) Without a binding procedure, the "informal process" described in Wikipedia:Administrators open to recall is just a form of virtue signalling. A separate RfC on this proposal would be welcome. — Newslinger talk 00:24, 18 October 2019 (UTC) Users who oppose statement 16 Out of the scope of this RfC, which has nothing to do with a recalls. If you want to have this discussion, start a new RfC that is advertised as such. The political climate on en.wiki makes the idea of recall toxic and no one has ever presented an iota of evidence that ArbCom is not able to handle this. If anything, ArbCom has likely been more willing than the community would have been to desysop admins who should be desysoped and sanction them if sanctions are needed. This discussion is about a different issue, and I promise you if people started a different RfC on a binding desysop process and advertised it as such, it would be closed as no consensus at best. Other communities have different processes, and anyone who is involved xwiki will tell you that each has its flaws. I personally believe the ArbCom process is the least flawed of them all. TonyBallioni (talk) 04:11, 15 October 2019 (UTC) Agree with Tony, this is clearly out of scope of both part 1 and part 2 of this RfC. We are discussing resysop criteria here, not desysop criteria. I personally welcome a desysop criteria/procedure RfC, but this shouldn't be it. CThomas3 (talk) 04:21, 15 October 2019 (UTC) While I'm not opposed to this in principle, this RFC is not the place for it. It was widely advertised as "implementing the community consensus for a stricter resysop policy" and "Stricter resysop criteria". People who don't care about inactivity policy minutiae aren't going to see this. Announce an RFC with a title that's some permutation of "community desysop process", and a consensus there will have legitimacy. —Cryptic 05:17, 15 October 2019 (UTC) There are numerous problems with the idea and an RfC about resysop criteria is not the place to have this discussion as this won't get the broad input it needs. Hut 8.5 06:59, 16 October 2019 (UTC) Oppose I do not support a recall "vote", and in any event, it is out of scope for this discussion, which is about resysop criteria. ST47 (talk) 07:03, 16 October 2019 (UTC) Oppose Agree with TonyB. Trying to shoehorn an admin de-sysop approach into an admin re-sysop RfC is really not something that should be done. I do of course trust it's with the best of intentions, I just think it is incorrect thinking and an improper approach. — Ched (talk) 07:16, 16 October 2019 (UTC) Oppose per everyone above. Out of scope. Not opposed to revisiting this in a separate RfC, but let's not muddle this current RfC with a perennial debate on de-adminship. OhKayeSierra (talk) 07:23, 16 October 2019 (UTC) Oppose - as well as the scope point, I'm generally concerned that a one size fits all recall setup is both vulnerable to being a bit blunt and has a number of issues. It also shouldn't be discussed without consideration for reducing the RfA difficulty (i.e. it can be tough to get in because it's tough to lose it, but if one is changed, so should the other). Nosebagbear (talk) 08:51, 16 October 2019 (UTC) Oppose as out of scope. Community-based desysop is an issue that needs its own, widely-advertised, discussion, not introduced as "Statement 16" in a discussion about resysop criteria. Boing! said Zebedee (talk) 09:28, 16 October 2019 (UTC) Oppose - as per Boing. GiantSnowman 10:10, 16 October 2019 (UTC) Believe me, I fully believe that there should be such a process in place. This, however, is neither the place nor the time to bring it up; it's out of this RfC's scope, and so I must decline (to agree). — Javert2113 (Siarad.|¤) 14:45, 16 October 2019 (UTC) Oppose not because of scope nor because I disagree with the idea, but given the many problems we have had lately with mob mentality and brigading, such a process really needs to be very well thought out before being discussed and implemented, not just an off-the-cuff "we should do this thing" kind of thing. Moral support, I suppose. Ivanvector (Talk/Edits) 16:04, 16 October 2019 (UTC) Oppose on two grounds. The first is technical; this matter should not be handled as a rider on another RFC, but as its own discussion with more explicit and better advertising and participation. The second is that the proposal is too vague to get my support. This is a "devil is in the details" issue, and I'd like to see a concrete proposal on how to enact a community de-sysop process which does not open itself to mob-based hit-jobs against sysops who gain a reputation for fighting the hard cases. Unlike me, who won't wade in to the deep end of any of the really bad stuff, we need sysops who are willing to stop disruption in the highly disputed areas, and any community desysop process needs to be able to protect admins from a bunch of friends ganging up on an admin they don't like because one of their buddies got blocked. This proposal is so vague as to be meaningless. --Jayron32 16:34, 16 October 2019 (UTC) Oppose. Should there be a community based desysop procedure? Absolutely, if a methodology that can gain consensus can be found. Is this the place to start that discussion? Nope. Black Kite (talk) 17:40, 16 October 2019 (UTC) The last thing we need is another outlet for baying lynch mobs. Even if we did need it, this would not be the place to discuss it. Stifle (talk) 09:35, 17 October 2019 (UTC) Procedural oppose - like others said, outside scope of RfC. Receptive to idea as the issue crops up from time to time. Cas Liber (talk · contribs) 09:51, 17 October 2019 (UTC) Sympathy Oppose. While I do agree there should be there should be one, trying to backdoor a community desysop procedure in a RFC about resysopping is 100% not germane to the topic. Proposer is invited to create a new RFC (and taking into account the many previous proposals) instead of trying to backddoor this. Hasteur (talk) 18:24, 17 October 2019 (UTC) Oppose - totally out of scope. Having commented on 100s of major RfC and started many of them myself, I never cease to be amazed how some people will come along sooner or later and side-track the debate. I even have a Terms & Conditions clause in the preamble of my RfCs but they still do it. I'm sure they do it in good faith, but all it does is waste time. That said however, there is a lot of support for a community desysop procedure, broadly construed - and suggesting one idea for a solution (together with Worm That Turned) was another of my RfCs . It fell short of a consensus on strength of argument (115 supports, 77 opposes) but despite attempts at side-tracking (this time on gender issues) it clearly demonstrated that the way to go is to keep proposing ideas until one sticks. Kudpung กุดผึ้ง (talk) 19:34, 17 October 2019 (UTC) Oppose Needs a separate RfC.-- Pawnkingthree (talk) 20:19, 17 October 2019 (UTC) Discussion of statement 16 Honestly, I don't know how I feel about this, but it seems to be gaining traction in the discussion below. I think a straw poll would be useful to see where the community currently stands on this issue and whether it would be worth exploring further. Since editors interested in developing sysop criteria are here already and this isn't a bureaucracy, it seems as good a place as any to get that feedback. Wug·a·po·des​ 03:51, 10 October 2019 (UTC) I'd be hesitant to rely on the result of this, since it's a question about desysops being shoehorned into an RfC about resysops; a separate discussion might be better. Once upon a time I did work on a community de-sysop procedure, but it wouldn't address the "barely active" as written and at the time I was persuaded that it wasn't necessary for the usecases (because arbcom) and potentially counter-productive (because unpleasant) so it was never brought forward. –xenotalk 12:49, 10 October 2019 (UTC) I'm of mixed feelings about binding recall. On the one hand I think it is healthy for the community as a whole if we don't divide ourselves into sysops and non-sysops with the sysops being permanently entrenched as such. So having a community route to desysop would be healthy for the community health in that regard. However, I have a hard time thinking that any individual recall discussion would be healthy for the community as a whole and so if it were used at some level of frequency (which I don't know) it could be a net negative. I do think it's a very distinct issue from resysopping inactive admins. Best, Barkeep49 (talk) 19:48, 10 October 2019 (UTC) Thanks for the links Xeno they're a lot to chew on. The point on viewing ArbCom as a community process is interesting, and I want to think about that more. I feel some of the points rely on an understanding of RFC/U that I don't have (it was shut down a year before I started editing). I agree this statement shouldn't be taken as binding, and is definitely shoehorned in, but I think issues around resysoping are really covertly issues about desysopping. To use the terms from your link, we don't have a lightweight way to desysop admins. The closest community controlled process (Risker's arbcom point notwithstanding) is inactivity requirements, but those are easily circumvented and even when enforced can be undone by request at BN without much community input. Since it's the only lightweight desysop method, and other desysop measures are usually non-starters, narrowing resysop policies becomes a proxy for widening desysop policies. That's why I thought adding this statement would be useful. Even if non-binding and flawed, I think it could give us some insight into how much disagreement here is actually because people are using this as a proxy fight for some other policy that is desired. It's hard to resolve community tension if we can't pin down what the conflict even is (which is, I think, part of the point Peter Southwood and others have been making in various places). I think I have a similar evaluation as Barkeep49, that the harm from the individual recalls would probably outweigh the benefits of a community desysop procedure. I commented elsewhere on how discussions about people can eat up a lot of resources and quickly degrade into unhealthy conflict. I think that's rightly a common fear, but I also wonder how accurate it is since we've never really tried a binding procedure. At least given some of the comments here, I think part of the desire isn't to use this process on abusive admins (ArbCom may in fact be the best process we have for those instances) but rather to have a more nuanced evaluation of what admins are still engaged enough in the community that their access to the tools is a benefit. Admins who log in once a year to make an edit so that they keep the tools clearly aren't here to build the encyclopedia, and that's fine. People and interests change. I think a process by which the community can tell a squatting admin "thanks for all you've done for the community, but you've clearly moved on and we'd like to let you move on" could actually be healthy. No prejudice against rejoining the community or regaining the tools once its clear the editor has returned and gained trust of the current community. The editor gets to leave, the community doesn't need to get into fights at BN over resysops, and the community can handle the merits of de- and re- sysops on a case-by-case basis. If there's one thing that has consensus in this discussion, it's that arbitrary thresholds aren't very productive because they capture stuff we want and don't capture stuff we don't want. I think that's the problem with current inactivity thresholds and why we're focused on an c2:AntiPattern of new arbitrary thresholds for resysoping. A lot to think about and I've already typed a novel. Wug·a·po·des​ 05:36, 11 October 2019 (UTC) I don't know that I see this as a separate issue rather than the underlying issue. If there were a reasonable community recall process, I don't know that we would be fretting over resysops in the first place. The core problem with resysop criteria is that we have no reasonable process for taking away access from someone who is merely unqualified, or who exhibits chronic behavior that does not rise to the acute level of a case request. For example, someone who has made all of 50 edits in the last ten years is fairly objectively unqualified, and would probably not be considered a suitable candidate for rollback or file mover, much less sysop. However, ArbCom does not consider gross unqualification as a valid rationale for a case, and without a binding community recall process, there is no other route other than resysop through which to address the issue that ArbCom runs counter to the community in this regard. If we want evidence of real-world application of this, we need look no further than c:Commons:Administrators/Archive. Binding recall has been used less than 30 times in the entire history of the project. In at least three of these instances (Russavia, INeverCry, and INC sock Daphne Lantier) the users were WMF banned, and so the behavior was sufficiently egregious that a binding recall probably would not have been necessary on a project with an ArbCom. It has, contrary to popular opinion on the English Wikipedia, not been used to railroad otherwise good administrators through mob justice, and in about half of cases that achieved consensus for a recall discussion, the administrator was in fact retained by the community. GMGtalk 13:20, 13 October 2019 (UTC) On Commons, I can believe it. It has a smaller user community and they are more focused on a single thing. Wikipedia is ground zero for every conflict in the world, and any admin who dares to try to police contentious areas would be at serious risk. Guy (help!) 09:21, 15 October 2019 (UTC) Commons is smaller yes, but has about 30k active users to en.wiki's 130k. So it's hardly as if we are comparing the Catalan Wikisource with all of their 18 users. This is besides the fact that out of hundreds of active projects, exactly eleven have any ArbCom whatsoever. Most of them, like the German Wikipedia, still use community desysop anyway. Meanwhile the French Wikipedia suspended their ArbCom entirely only a couple of weeks ago. The perennial tired argument that community review simply cannot work, as often and confidently as it is dusted off and dragged out, simply has no supporting evidence whatsoever, while ignoring the fact that en.wiki is very much an outlier in this regard and growing ever lonelier. If we truly have a cadre of users who have been so thoroughly toxic in their contributions to contentious areas that the only thing saving them is a procedural footnote...I mean...yeah. They probably should be concerned. That's not collateral damage; that's the intended target. If we truly have a cadre of users who feel it is simply impossible to contribute to certain topics without being a toxic jerk, then they should find somewhere else to contribute. GMGtalk 11:49, 15 October 2019 (UTC) This has been created in an objectionable mode, but that’s a deep and chronic problem – a virtually lifetime appointment of the sysop privilege. Procedural nuances of resysopping after a break are not a problem perceived as notable by most Wikipedians. Incnis Mrsi (talk) 18:49, 13 October 2019 (UTC) The German case is quite informative about the likely impact of a recall process on a large content-rich wiki. I would recommend getting inspired by their history over 10 years. — JFG talk 20:22, 15 October 2019 (UTC) @TonyBallioni, Cthomas3, and Cryptic: I would recommend you read the discussion above in the context of WP:NOTBURO. You have raised only procedural objections, and unlike every other statement proposed in this request for comment, no one has raised a substantive objection (Cthomas and Cryptic, you both have in fact voiced substantive support for the statement). Editors who have raised substantial objections to other statements, such as Rhododendrites and DESiegel, have agreed that this statement articulates the underlying problems that other statements in this RfC have not addressed. If you have concerns about the substance of this statement, I'd be interested in discussing them just as I have with Xeno and Barkeep who have expressed concerns and refrained from supporting this statement. But simply opposing a statement because it's not what you want to discuss right now isn't helpful for developing consensus on how the community should handle sysop permissions. Wug·a·po·des​ 20:56, 15 October 2019 (UTC) Wugapodes, I don't believe this is a case of bureaucracy for bureaucracy's sake. In my mind the point is to ensure we stay focused on the issue at hand, resysop criteria, and find a workable solution for it. Binding desysop procedures is an admittedly related, but fundamentally different discussion. I agree in principle we need something like this but what I want to avoid at all costs is to distract the community by trying to solve all the Wikipedia's problems in a single discussion and ultimately get nowhere with any of them. Wouldn't you agree that resysop criteria is a large enough issue on its own for one RFC without adding binding desysop procedures to the mix? CThomas3 (talk) 21:46, 15 October 2019 (UTC) As I said above, I think the resysop criteria is a proxy discussion for desysop criteria, and others agree with that evaluation. Can you point me to a resysop proposal that has developed any consensus? Wug·a·po·des​ 21:50, 15 October 2019 (UTC) There are two different types of administrative privileges removal: temporary, corresponding to a suspension of administrative privileges until the editor meets certain criteria to have them restored, and permanent, where the editor must go through the request for administrative privileges process again in order to regain them. This RfC has been focused on restoring suspended administrative privileges, while your proposal calls for a "binding community desysop procedure", which usually refers to a permanent removal of privileges. Scope does matter for these discussions, in order to gain a broad consensus. isaacl (talk) 04:29, 16 October 2019 (UTC) It isn’t anywhere near “all the Wikipedia's problems”. It is essentially the same problem: which conditions must meet a user to play an administrator legitimately. No surprise if checks effected for borderline resysop and desysop for a mild abuse will form a large overlap. Incnis Mrsi (talk) 21:59, 15 October 2019 (UTC) The issue is that if you were to advertise it as a community desysop process, you’d have 50/50 split at best for it. Certainly not 13/3. A proposal that hasn’t been advertised as such on a page about something completely different is only going to attract people who want it to pass. Any close of this discussion in the affirmative would all but be guaranteed to be overturned at AN since you’d literally be putting through the single biggest change in the Administrator policy in this history of the project while telling no one about it. This isn’t a valid proposal. TonyBallioni (talk) 03:04, 16 October 2019 (UTC) Tony's point makes sense, but it's remarkable that a statement of need for a recall process emerged spontaneously and gathered quasi-unanimous support. Certainly it's non-binding because of the locus of the discussion, but it nevertheless indicates a local agreement. The closer should not simply ignore this for procedural reasons, and s/he could add a note that "Most respondents opined that we should have a binding admin recall process, so that this matter warrants a new discussion that should be properly structured and advertised." — JFG talk 03:31, 16 October 2019 (UTC) Yeah, and I do think it'd be a valid RfC elsewhere, but the last thing I want is a pseudo-consensus because no one read down far enough. I asked more views on it at AN, because I think it's a big enough deal. I do think it is a valid discussion that could be had elsewhere, and would like to participate in it if it occurs (I'd oppose, but I respect different views.) TonyBallioni (talk) 03:40, 16 October 2019 (UTC) The reasons for opposing are kind of frustrating (putting aside that most of the opposition has come from admins following a link placed on the admin noticeboard -- I suppose I would be alarmed too if I thought anybody really thought this was a binding proposal to implement desysopping without being widely advertised as such). This was only intended to be a discussion of whether all of the energy focused on resysopping right now would be better channeled to rethinking a desysopping procedure to address the very same issues (and more). Perhaps the proposal should be worded "Would it be better to pursue a desysopping procedure to tackle the issues raised on this page, rather than changing (or before changing) resysopping procedures?" so as not to appear to be intended as some binding proposal. I do see that some people are talking about temporary restrictions more specific to resysopping, but the vast majority of issues raised and/or solutions to fix them seem to be (a) not the sole domain of admins that had a period of inactivity, and (b) an indirect reaction to not having a desperately needed community desysopping procedure. — Rhododendrites talk \\ 14:56, 16 October 2019 (UTC) re: Should there be some sort of recall system? I'm not opposed to researching possible options, but I'd hesitate to give a blanket "Support" to such a broad question. Some sort of recall system? I'd be willing to listen. — Ched (talk) 16:05, 16 October 2019 (UTC) Original discussion Moved from #Is it worth revisiting a universal recall system?  – Wug·a·po·des​ 05:54, 11 October 2019 (UTC) Prior discussion that led to formulating statement #16 — JFG talk 20:24, 15 October 2019 (UTC) I didn't see/participate in the original RfC. To me, it seems the issues aren't about resysopping, they're about desysopping. Concerns about formerly inactive admins not getting up to speed or being inactive or hat collecting? What about active admins who aren't up to speed, or barely active admins, or successful hat collectors? Personally, I only care about the first one (when admins don't know current policies/guidelines/conventions), but I appreciate that the rest are concerns. But they're concerns regarding admins, regardless of when/how they received that flag. It seems like it may be worth redirecting the attention this is currently receiving to revisiting universal recall procedures or some other means of removing the bit without going to ArbCom. — Rhododendrites talk \\ 22:38, 8 October 2019 (UTC) Rhododentrites, are you thinking something like a proposal that “admins may be proposed for recall by (any extended autoconfirmed user, perhaps?) who believes the admin is not sufficiently familiar with current policy, guidelines, and community conventions”? That could in theory be used to correct the types of resysops that started this whole thing, but could also be used in the other cases you’re talking about. I don’t know how many admins would object to something like that, but it certainly would represent a solution. An absurd resysop request could be addressed by a community discussion if the request is followed by zero editing or bad editing. But active admins who have simply made enemies because they’re willing to make hard decisions within policy wouldn’t qualify for recall under this, so there wouldn’t be that concern. --valereee (talk) 11:28, 9 October 2019 (UTC) This comes much closer to the sort of thing we should be considering, if the consensus is that something needs to be done. And exactly why I urged Tony to withdraw this RFC and reconsider the scope and purpose of the exercise. The current RFC is so narrowly focused, that people will expend all sorts of energy on it, believe they've achieved something tangible by the end of it, but in fact fail to address the actual issue of inactive admins. I would welcome any steps to make this a comprehensive process.  — Amakuru (talk) 11:44, 9 October 2019 (UTC) Yes, I think we should revisit recall. I think the risk of bad faith recall attempts is low, as the community can deal with editors who, e.g., file repeated revenge recalls. I encourage all admins to add themselves to the recall category, which can be done right now, costs nothing, and because it’s voluntary, risks nothing. Let’s make it a "real thing". At the same time, we can explore an involuntary recall system, but I think admin adding themselves to the current voluntary recall system will demonstrate there is "buy-in" among the admin corps for the idea of community based desysoping. – Levivich 13:24, 9 October 2019 (UTC) I like this also. I could support some kind of community recall procedure. Govindaharihari (talk) 13:55, 9 October 2019 (UTC) Surely this is outside the scope for this RFC to consider; the RFC is looking at the process for reinstating former admins, not removing admin rights from those who already possess them.--WaltCip (talk) 14:02, 9 October 2019 (UTC) That's sort of the point. The underlying issues are better resolved by figuring out a desysopping procedure. All of the concerns raised regarding resysopping can also apply to admins that never lost the bit, and in both cases are only a real problem because there's no practical way to desysop. All of this momentum around doing something regarding the latter would be best redirected, IMO, to that cause instead. — Rhododendrites talk \\ 14:10, 9 October 2019 (UTC) Well, it would strengthen the process by giving the community an ability to challenge the reinstating - there are also vocalised concerns that there is a problem with a minority of admins avoiding removal by making in some cases absolutely the minimal contributions to keep the advanced tools without any apparent benefit to the wikipedia. Govindaharihari (talk) 14:16, 9 October 2019 (UTC) Right, but I don't see how a universal recall procedure would fail to address the same concerns. My presumption is that there's just a worry that such a proposal wouldn't pass, and I don't know if that's true these days. — Rhododendrites talk \\ 14:50, 9 October 2019 (UTC) IMO the recall process on Commons works just fine. Must be prior discussion with a consensus for a recall discussion, and any recall opened without such a consensus can be unceremoniously closed by a crat. If anyone can point to a COM:DEADMIN discussion where a user without a long-term pattern of drama-mongering, incivility, and/or questionable decision making was railroaded for "doing the right thing" then I'd be interested to read the discussion because I haven't seen it. Part of this entire mess is that we simply don't have any method of desysoping someone for being a run-of-the-mill buffoon or a chronic jerk. GMGtalk 19:35, 9 October 2019 (UTC) Hi. I can find little room to support your comments.Part of this entire mess it's not a mess at all, there are concerns good faith concerns only with the current process, also I don't think your concerns about desysoping someone for being a run-of-the-mill buffoon or a chronic jerk are even under discussion here. Govindaharihari (talk) 19:51, 9 October 2019 (UTC) Wut? GMGtalk 22:03, 9 October 2019 (UTC) Surprised at your comments here considering your contributions, wut is not a comment for progress, my comments above are quite clear, please don't disrupt the discussion with such replies. Govindaharihari (talk) 22:11, 9 October 2019 (UTC) We do have a mechanism for desysoping "run-of-the-mill buffoons" and "chronic jerks", it's called Arbcom. The issue this RFC, and talk of admin recall, seeks to address is not people who've done anything wrong per se, but simply people who aren't active enough to be familiar with use of the tools in 2019. These people are neither buffoons nor jerks, and no doubt participated extensively in the past in order to get their bit. It's all AGF, but per comments above there are some non-admins who still feel like it's unfair for such people to retain the bit, when they don't really contribute meaningfully. Perhaps to thank them for their service, and not make them feel like they've been fired, we should inaugurate an "emeritus admin" status which recognises that they passed an RFA, and haven't been desysopped for cause, but prevents them actually wield the tools until they pass a reconfirmation process?!  — Amakuru (talk) 10:50, 10 October 2019 (UTC) Arbcom being the only way to remove admins regardless of reason has long been a point of disagreement. Many have argued that a reason it's so hard to become an admin is because people have realized it's a for-life position that's incredibly difficult to remove someone from. If it were not incredibly difficult -- if going to arbcom weren't required -- then that would address people who have been too inactive, people who are buffoons or jerks, and any other conceivable reason. In other words, a step towards restoring the mythical "adminship is not a big deal". — Rhododendrites talk \\ 14:21, 10 October 2019 (UTC) Basically exactly what User:Rhododendrites said. For those who want to see the barrier-to-entry lowered for adminship, the problem is that the barrier-to-exit is basically nothing short of murder. The issue is that ArbCom simply doesn't act in cases of run-of-the-mill buffoons or chronic jerks. They are useful only in acute and egregious cases. You can be a productive admin for years, wheel war once, and get deadmined. You can be a below-average admin for years, while being a generic jerk, or rejoin the project while having no clue what you are doing, and ArbCom will decline the case for lack of acute egregiousness. (I can surely offer examples of these, if we really want to break our gentlemen's agreement not to call individual editors out in these types of discussions.) If I'm being totally honest, part of the problem is the perverse incentive that effectively only admins can be elected to ArbCom, and so we have only admins deciding on the fate of admins, who must naturally see their own decisions possibly reflecting on themselves when they have a "bad day" and tell someone to go eff themselves. (That's also why I've long advocated for an Arb of the plebs, requiring that at least one member of ArbCom be a user without advanced permissions. GMGtalk 20:43, 11 October 2019 (UTC)  GreenMeansGo: While there isn’t a prior example of non-admin ascension to the committee proper, a non-admin applicant was successful in their candidacy for the Audit Subcomittee, so I would not completely write off the idea of a non-admin arbitrator, if the right candidate were to present themselves. –xenotalk 13:41, 14 October 2019 (UTC) Unfortunately @Xeno:, for the purposes of determining the trajectory of our organizational culture, "technically possible eventuality" doesn't actually factor in very much at all. And I'm not really assuming any bad faith there. I don't think ArbCom are self-interestedly plotting raise the bar for desysop. I also don't think that (with possible outliers) most admins operate consciously with the understanding that they can perpetually live in an unhelpful grey area of being a net-negative but not acutely enough to warrant a case. I do however assume that people are generally ... mostly rationale actors ... at some level ... who operate based on incentives as they understand it. I do think there is a measurable, even if mostly unconscious difference in approach on projects where those with advanced rights hold those rights at the continual behest of the community. It is a continual mandate to maintain the public trust, and not merely to achieve it at some point where a !vote happened several years ago. GMGtalk 14:25, 14 October 2019 (UTC) Given the sentiments here, I've added a 16th statement to gauge support for the general principle of recall. Wug·a·po·des​ 03:56, 10 October 2019 (UTC)

Statement 17 by JFG

Withdrawn by OP — JFG talk 00:07, 17 October 2019 (UTC)

Add to WP:RESYSOP conditions that: Returning admins should demonstrate a current need for the tools. Whether the need for tools is established would be left to the discretion of the BN crats, per proposal #1. Users who endorse statement 17 Admin tools are not a trophy. Returning admins should convince crats at BN that not only they want the tools back, but they need them now. If they can't convince a crat, they'll need to convince the community via RfA. — JFG talk 00:43, 14 October 2019 (UTC) Users who oppose statement 17 "No need for tools" isn't in my view a very convincing oppose rationale at RfA, and it shouldn't be a reason not to re-grant tools at BN. Do I "need" the admin tools? I have more options for volunteering with the tools (and they are convenient), and I do use them to mop up this or that. But I'm not sure that this is well characterised as "need". —Kusma (t·c) 19:42, 14 October 2019 (UTC) "Need for the tools" is backwards. No editor actually needs the tools, but all editors actually need admin. – Levivich 02:15, 15 October 2019 (UTC) I've never been a big fan of requiring people to demonstrate "need" for the tools. The question we should be asking, both at RfA and for a resysop, is whether or not we (still) trust that user with them. CThomas3 (talk) 04:25, 15 October 2019 (UTC) I'll never understand the point of people saying "there's no need for the tools." Does anyone ever really know when they're going to need to use tools at all? No, but they're useful to have. I have an entire stagecraft workshop full of tools at work, the majority of which are tools that I barely need to use to build a set aside from a few key tools. But, when I do need to use the rare tool like a wire stripper, soldering iron, or a gel cutter, I'm damn glad to have it on-hand and ready to go. A better question that we as a community should be asking is "Can this user still be trusted with the tools?" and "Does this user demonstrate sound judgement?" OhKayeSierra (talk) 07:19, 16 October 2019 (UTC) There's nonzero risk associated with every account with +sysop - maybe its password is hello123, or it's controlled by a paid editing ring, or it's the good-hand account of a long-term abuser who's just waiting for an opportunity to display goatse on every enwiki pageview in some way that's time-consuming to track down and reverse. The idea behind "there's no need for a tools" - one I don't agree with either, btw - is that there has to be enough of a demonstrable net positive of flipping the bit that it outweighs those possibilities. —Cryptic 08:53, 16 October 2019 (UTC) We already (well, some of us) tend to require administrators to demonstrate need at their original RfAs. Let's not burden them too much, eh? — Javert2113 (Siarad.|¤) 14:47, 16 October 2019 (UTC) Per all my other comments about bureaucrats and subjective criteria. Ivanvector (Talk/Edits) 16:05, 16 October 2019 (UTC) Oppose This is the third time that a similar proposal has been made, and I oppose it for the same reasons as above. Need is not a requirement. Need is demonstrated because need exists: there are admin tasks that can be done, so there is a need for another admin. What needs to be demonstrated is not need, but ability and temperament. Will the person use the tools correctly or not, either through misunderstanding or malice? If the answer is "no", give them the tools. --Jayron32 18:16, 16 October 2019 (UTC) Nobody ever has any *need* for admin tools. Boing! said Zebedee (talk) 19:02, 16 October 2019 (UTC) I see no substantive difference from statements 4 or 9. Quibbles with the wording should be addressed in the discussion sections, not by tacking on another vote. —Cryptic 21:59, 16 October 2019 (UTC) Discussion of statement 17 Admin tools are not a trophy, but any active editor has a need for them. Without admin tools you can't move a page over a redirect with non-trivial history. You can't clean up a copyvio properly. You can't semi-protect a page when you see it drawing IP vandalism. You can't undelete a stale AFC draft to see if there was anything there worth saving. Inactive people don't need admin tools. But any active editor has a use for them. Guettarda (talk) 13:34, 14 October 2019 (UTC) Obviously this is distinct from some of the roles we require of admins, like judging consensus on an AFD, or closing an RFC, or not abusing their ability to block or see deleted content. But let's be honest - there are plenty of non-admins who can judge consensus better than many admins, but we trust admins to close discussions because they have shown that they have the trust of the community (or did at some point in the last 18 years). You don't need admin tools for that. Guettarda (talk) 13:40, 14 October 2019 (UTC) We've never required a person to be an admin to close an RFC or other similar discussions so I am not sure where you got that (there's a small point of contention on xFD specifically, but other discussions not so much). In general, we have always allowed any experienced and trusted editor to close a discussion as needed. Admin powers only extend to the use of the admin toolset specifically (block, protect, delete and related powers such as editing through protection, etc.) and activities that don't require those tools don't require the bit. Wikipedia:Closing discussions#Closure procedure specifically states "Most discussions don't need closure at all, but when they do, any uninvolved editor may close most of them – not just admins." Furthermore, admins cannot unilaterally undo a closure merely because the closer was not an admin. This discussion here re-affirmed the equal standing that admins and non-admins have in closing discussions. --Jayron32 18:24, 16 October 2019 (UTC) Hi there. Jayron32 Can't admins also see all deleted content that has not been oversighted? Why would any long term not active admin need to be able to do that, also have you any explanation as to why basically retired editors and there are quite a few of them that are not closing any discussions at all or doing anything at all have the need to do that and of what benefit it is to the project? Govindaharihari (talk) 18:50, 16 October 2019 (UTC)

Statement 18 by Nosebagbear

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

---

The following statement is a proposal regarding the mechanism of this RfC, rather than a specific suggested addition to WP:ADMIN

Proposals that receive some form of net support in this RfC should be taken to a workshop/dedicated stage (where they will be the only proposals being considered) to refine details and consensus, unless they already possess clarity, don't contradicti other proposals, and have a clear consensus for straight implementation.

Currently, after the strong consensus in favour of altering the rules, we've split a dozen+ ways, which is making demonstrating consensus tough. We also have contradicting methods, and proposals currently lacking clarity (or firm agreement that they should lack clarity).

If, when these are closed, we take the 5 or 6 with at least some net support (but not enough to show clear consensus) to a dedicated discussion, hopefully we can get better community agreement and iron out some of the issues.

Obviously it makes things a bit more bureaucratic and slower, but it should be less problematic than the current one and avoid an issue of a firm consensus for something but with nothing agreed being done. Nosebagbear (talk) 15:33, 16 October 2019 (UTC)

Users who endorse statement 18

1. As a method of clearing out and letting the community actually agree on the better ideas Nosebagbear (talk) 15:33, 16 October 2019 (UTC)
2. I think we're doing this a bit backwards (we should have workshopped the proposals before we started voting, then we wouldn't have stupid wording like in my proposal) but doing this as the next step is better than not doing this at all. —Kusma (t·c) 15:54, 16 October 2019 (UTC)
3. Support if necessary, but I'm keeping my fingers crossed it won't be. Maybe we leave this one open until we know which others look like they'll definitely pass; then people can decide if they want the remaining statements workshopped. --valereee (talk) 14:17, 18 October 2019 (UTC)
4. allows for refinement, and better assesment of true consensus, and dealign wiht any contradictory proposals. DES ^(talk)_{DESiegel Contribs} 07:31, 4 November 2019 (UTC)

Users who oppose statement 18

1. This is hopefully not going to be an on and on thing, it's not hard, really, just see the community concerns and address them Govindaharihari (talk) 22:03, 16 October 2019 (UTC)
2. Unnecessary - it does not look like contradictory statements will both have enough support to rule out consensus and necessitate a further RfC. Best, Barkeep49 (talk) 01:12, 17 October 2019 (UTC)
3. I think this will drag things on interminably Cas Liber (talk · contribs) 09:52, 17 October 2019 (UTC)
4. While slow and deliberative is sometimes the best way to do things, I think this process has already been slow and deliberative so there's no need to make it more so. If there are conflicts, either do alternative proposals or hold an RfC later. —pythoncoder (talk | contribs) 21:04, 23 October 2019 (UTC)

Discussion of statement 18

• Ummm..well I think that some of the proposals that don't pass but have net support may be useful to spin off, but I don't think that any proposal that is supported should be required to spin off - it is possible that with a strong support certain proposals could be moved directly to implementation. — xaosflux ^Talk 18:43, 16 October 2019 (UTC)
• This is a good point. Nosebagbear, maybe tweak it to 'any proposals that have net support but no clear consensus and do not conflict with a passing proposal will be' or something? --valereee (talk) 19:18, 16 October 2019 (UTC)

@Valereee, Xaosflux, and Kusma: - I've redefined slightly in line with the above. I've assumed that it's clear that for those that do meet the three requirements just pass normally, but that can be clarified if viewed necessary. Nosebagbear (talk) 21:14, 16 October 2019 (UTC)

• Do we really have contradictory proposals that appear like they'll both get consensus? I really think trying to avoid a third part to this RfC would be ideal. Best, Barkeep49 (talk) 21:55, 16 October 2019 (UTC)

  So I just double checked and I think every proposal with a majority (which doesn't impute consensus, but as a rough starting point) can work together. For instance 1 & 2 could become Before restoring the administrator flag a bureaucrat should be reasonably convinced that the user has returned to activity or intends to return to activity as an editor and retains the trust of the community to serve as an administrator. I trust, in the same way that we're able to close ACERFC that we'll be able to close this one OK without a third RfC. Best, Barkeep49 (talk) 22:10, 16 October 2019 (UTC)

  @Barkeep49: The contradictory aspect was only one part of the proposal, it's more designed to focus discussion on a) those with net support but non-clear on consensus and would benefit from more focus and b) those that aren't especially clear on what implementation might involve (but should) Nosebagbear (talk) 09:50, 17 October 2019 (UTC)

• Neutral/meh. I support this iff it it seen as necessary, but this should not be invoked unless there's a lot of controvery about what did and did not pass in this round of the process (which hopefully would be the last round).  — AReaderOutThataway ^t/_c 06:48, 22 October 2019 (UTC)

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

General discussion

• I am still not seeing any of these as fixing something that is broken. · · · Peter Southwood ^(talk): 14:31, 6 October 2019 (UTC)
  • I think this is more about strengthening than fixing. Govindaharihari (talk) 16:04, 6 October 2019 (UTC)
    • Strengthening a process is useful when you have established a specific weakness. This does not do that. Adding buttresses does not help if the structure is built on mud. · · · Peter Southwood ^(talk): 08:13, 7 October 2019 (UTC)
  • There are many users (not me) who believe resysopping is broken. But if we had a more universally accepted policy, maybe WP:BN could be less of a drama zone? —Kusma (t·c) 17:07, 6 October 2019 (UTC)
  • Sure, but the community has already decided the process is broken. The purpose of this RfC is to try to find a proposal that people can broadly accept that will strengthen the requirements. TonyBallioni (talk) 18:09, 6 October 2019 (UTC)
• Having just now become aware of this RFC, I also agree with Peter in that I'm not sure anything needs to change. WaltCip (talk) 18:57, 6 October 2019 (UTC)

  It is clear that a significant number of people think there is a problem and the process need to be improved, but it remains unclear what is actually broken. I cannot help with suggestions to fix it as in the absence of sufficient relevant evidence, I don't know what the real problem is. First analyse the situation to identify the root problem(s), then look for solutions to those problems. Patching the damage is less effective than improving the design. · · · Peter Southwood ^(talk): 08:29, 7 October 2019 (UTC)

• The first RfC made it clear that quite a few editors think the current system is broken, but did not have many indications of what they problems were thoguht to be, and fewer with any cited examples or evidence of those problems. If we don't know what we are trying to fix, we are not likely to succeed in fixing it, or in improving the process. DES ^(talk)_{DESiegel Contribs} 19:26, 6 October 2019 (UTC)

  My point exactly. The previous RfC asked whether the cart or the horse should go in front, and got a result that the cart should go in front. Now we are having to work out how to make an unworkable proposal work. Consensus is no guarantee that the community makes a sensible choice, particularly when the question leads in limited directions, or fails to establish the underlying problem. · · · Peter Southwood ^(talk): 08:05, 7 October 2019 (UTC)

  Agreed. Like other areas of Wikipedia (see WP:RfA) this seems to be somewhere where the community broadly agrees there's a problem but can't clearly state what those problems are. The logical follow up to the previous RfC would have been a discussion on what exactly the problems are we want to solve. Is there a problem with inactive administrators holding on to the admin bit for a long time by making very few edits? Do inactive admins obscure our activity levels? Do we have admins returning without the trust of the wider community? Do returning admins not have an easy way to get back up to speed with community norms? If we could define the problem(s) it would be much easier to talk about the best solution(s). It's very hard to judge the above proposals when the problem we're trying to solve hasn't been defined beyond "there is a problem". Sam Walton (talk) 10:03, 7 October 2019 (UTC)

  @Pbsouthwood and Samwalton9: I think this concern sort of misses the mark. Maybe its place would have been in the first RfC, but that discussion was to determine consensus on one particular option, namely to make the resysop criteria tighter. If I may reference myself, it's possible to be disagree that doing so would be the solution, would be a solution, or that there's even a problem, but this isn't a "what are all the problems" RfC. As established in the first RfC, there is consensus to make the resysop criteria more strict. As such, we are here at this page to figure out how to make the resysop criteria more strict. I think your comments, Samwalton9, are worth thinking about as we weigh what suggestions would have the most impact, but in the end what matters is our definition of "strict" and how strict the community wants to go. ~ Amory (u • t • c) 10:26, 7 October 2019 (UTC)

  @Amorymeltzer: My point is that there are a myriad different ways we could make the resysop criteria stricter and without an overarching understanding the problem, any decision made will be largely arbitrary. If we want to come to a sensible conclusion on which proposal will be most effective (i.e. which ones we should support) we need to understand why we want to make the criteria stricter. Otherwise there's no coherent way for us to go about making this decision or later evaluating whether it solved any problems. Sam Walton (talk) 10:35, 7 October 2019 (UTC)

  If I remember correctly, I did bring up this point in the first RfC. The concerns listed below by Valeree do not appear to be based on a history of significant problems, so still not seeing a broken thing to be fixed. Clearly some people do, but the evidence that they are right seems to be a bit thin on the ground. If we really collectively feel that we need more hoops to be jumped through, this RfC will have that effect, but I don't see that actually fixing anything that has a history of being a real problem. · · · Peter Southwood ^(talk): 12:04, 7 October 2019 (UTC)

  Also agree with Sam Walton about evaluating the effect. · · · Peter Southwood ^(talk): 12:08, 7 October 2019 (UTC)

  Pbsouthwood, you don't see even #5 as being a problem? I think it's demoralizing to productive contributors to see things like that, and I think that's a problem. We may have disagreement about whether a hat collector is an actual problem, or an admin who fumbles for months relearning policy is a problem, or whether bureaucrats having no discretion is a problem, but surely we can agree that something that demoralizes productive contributors is a problem? --valereee (talk) 12:26, 7 October 2019 (UTC)

  Valeree, I do see RfA as a problem, but to some extent if you succeed in an RfA and plan to do some kinds of work you are setting yourself up for a lot of strife anyway. Getting an extra bit does not stop the people who disagree with your admin actions from making their disagreement known. Would it be less demoralising to get the bit and then the hassles that go with it? Also I see this as a problem that cannot be solved by making requests for return of the bit need more arbitrary hoop jumping, so it is not that I don't appreciate that #5 is a problem, it is more that I don't see any of the possible alternatives within the scope of this RfC as possible likely solutions to that problem. · · · Peter Southwood ^(talk): 12:46, 7 October 2019 (UTC)

  Pbsouthwood, proposal #11 solves it. If the community doesn't think someone who hasn't made 25 edits in 10 years should be an admin, they have the opportunity to contribute to the resysop decision. --valereee (talk) 13:06, 7 October 2019 (UTC)

  I think that #11 has potential, but needs more work. I also don't think that 25 edits in 10 years is enough to justify holding the permissions unless most of those edits were really valuable ones requiring those permissions. I doubt that ever happens, but who knows? An RfA would allow this exception to be made public. · · · Peter Southwood ^(talk): 14:30, 7 October 2019 (UTC)

@Pbsouthwood: The main problem that we actually have in this area is that there is a substantial and growing group of admins who can be characterized as follows:

• Make occasional, casual edits to topics of interest to them
• Have not been involved in Wikipedia (beyond these casual edits) for multiple years
• Realize that admin bits are valuable and will not willingly give theirs up
• Do not reply to talk page messages or emails

Some of these editors -- around 5% a year I would guess under present policy -- will go on to pose problems for the project:

• Mild misuse of admin tools in a topic area of interest, particularly undeletion of material that is not notable.
• Controversial, high-profile actions that lack community support or that do not follow community processes. A recent example involves unilaterally undeleting an article recently deleted at AFD and reviewed at WP:RFU.
• POV pushing. Admins are given more leeway by other editors even though that isn't our policy. A recent example involves a former bureaucrat.
• Monetizing their tools. There are no confirmed cases of people selling their accounts, but there are at least two examples of admins who were involved in paid editing in violation of policy, and who used their status as an admin to further their clients' interests.
• Account compromise.
• Erratic edits and actions resulting from a change in mental health, personality, or cognitive ability.

Most of this population makes enough edits that they never meet the inactivity threshold, and I think that's where attention should be focused. Nonetheless, tweaking the resysop criteria is a good start. UninvitedCompany 20:02, 25 October 2019 (UTC)

Where are the problems identified?

• Where is the list of problems identified in the first RfC that we are trying to solve here? · · · Peter Southwood ^(talk): 09:31, 7 October 2019 (UTC)

From a read of the support column of the RFC, the problems seem to be

1. How to ensure that a request for resysop represents an admin who wants to be active rather than one who simply wants to retain that hat, as right now we neither know nor appear to care
2. How to ensure that a request for resysop represents an admin who will get themselves up to speed on changes, as right now we do nothing
3. How to encourage reactivators to actually become active, as right now we don't do anything other than giving the mop back to encourage its actual productive use
4. How to provide crats some level of discretion to refuse the resysop of someone who doesn't appear likely to get themselves up to speed or become active, as right now their hands are tied
5. Or, as an alternative to the above, how to prevent pissing people off when someone just waltzes in and asks for the tools after ten years of nearly-zero editing, and after 24 hours we say, "Welcome back," when there are likely thousands of productive contributors who would like to have the tools but don't want to face RfA. --valereee (talk) 10:54, 7 October 2019 (UTC)

Thanks Valereee. I don't really see 1, 2, and 3 as problems serious enough to need fixing, or there would be a lot more evidence. 4 may have some value, but how much discretion do we want to burden the 'crats with? Is it part of their job description? Will this extra discretion lead to more people hassling the 'crats for exceeding their remit? 5 is more a problem with RfA and those users who don't feel up to the hazing. In some cases that is what they would be setting themselves up for if they became an admin. If they intend to do only work where they don't tread on people's toes occasionally, and have a history of being nice to co-workers, they may well have a relatively stress free RfA. A more robust system of RfAR may be far more useful for this and a large number of other problems. Cheers, · · · Peter Southwood ^(talk): 12:30, 7 October 2019 (UTC)

Thanks for providing some clarification, but it seems that this proposal ought to be considered as part of a wider "admin activity" discussion, not just handled in isolation. There are a number of admins who log in just a few times a year to do the necessary activity to keep their account open, and others who do some content creation here and there but don't do admin stuff, so aren't up to speed with latest admin developments. If the goal is simply to eliminate hat collectors who just keep the bit for the status, but without any actual identified problems, then it seems like it should encompass all lapsed admins, not just those who lose the bit and then request it back again. At present I'm inclined to say there is no actual problem occurring as a result of this, other than a bit of occasional drama at WP:BN, and that no action is necessary.  — Amakuru (talk) 12:40, 7 October 2019 (UTC)

Amakuru and Pb, surely we can agree it's a problem if our policies are causing anger among productive contributors for literally no reason other than 'that's how we've always done it, and our hands are tied'? --valereee (talk) 12:44, 7 October 2019 (UTC)

No, because the anger is not well-founded, as Pb says, it's putting the cart before the horse. If you want to make adminship time-limited, or subject to renewal, then go ahead and make proposals to do that. But don't waste time targeting a tiny minority of people who aren't causing anyone any harm.  — Amakuru (talk) 12:47, 7 October 2019 (UTC)

I'd argue it is irrelevant whether the anger is well-founded (though I'd also argue that it isn't unfounded to be angry at something that is inherently unfair). If it demoralizes productive contributors, it inevitably makes them less likely to want to continue as productive contributors. Perception of fairness is profoundly important when dealing with volunteers. Like it or not, want it or not, deny it or not, adminship carries an element of recognition. Bestowing it on people who don't deserve it is inherently unfair and demoralizing to others. --valereee (talk) 12:58, 7 October 2019 (UTC)

I think this is getting closer to the real point. I would argue that the perception is largely misguided, but it certainly can happen, and I agree that perception of fairness can be critically important to volunteers. The Fram fiasco is recent evidence of that. If we want to be seen to be fair, it is probably easier and less likely to cause knock on problems if we actually come up with a fair remedy. This means transparently fair to everyone, which requires that we identify the problem as well as coming up with a logical and reasonable solution. I don't think we are on that path at the moment. · · · Peter Southwood ^(talk): 13:53, 7 October 2019 (UTC)

1-3 are not problems we need to fix, and 4 is already the case. Guy (help!) 22:02, 9 October 2019 (UTC)

• @Valereee: is bang on with her summing up of the problems (be helpful at the top of the page), much better than I could have clarified it. I think quite a few of them depend on the arbitrary/judgement point that I'm going to try to get an answer on below.

Counterproposal

Abandon this effort to find solutions until it is clear what the real problem is. The proliferation of proposals above are a strong indication that there is no consensus on what we are actually trying to fix. · · · Peter Southwood ^(talk): 08:39, 7 October 2019 (UTC)

Agreed. @TonyBallioni: please could you withdraw this RFC and we can discuss what the actual problems are, with specific examples of what's gone wrong in the past, before we set about trying to fix them? Thanks  — Amakuru (talk) 12:45, 7 October 2019 (UTC)

The community has already decided that the resysop criteria are too lenient and are a problem in itself. That was the consensus in the first RfC. We’ve already had that discussion and the “no problems” side was not the side consensus was on. The purpose of this RfC is to find a workable solution to implement the consensus that there is a problem that needs to be fixed. TonyBallioni (talk) 12:53, 7 October 2019 (UTC)

@TonyBallioni: In your personal opinion, what exactly is the problem that needs to be fixed? —Kusma (t·c) 12:57, 7 October 2019 (UTC)

Kusma, I think what you got at in #8 above is the heart of the problem. People who aren't admins feel it's unfair, and honestly, none of us who are admins should be criticizing them for feeling that way. We need them to feel their contributions are valued, and when someone comes along with fewer than 25 edits in ten years, requests the bit with their first edit in two years, and walks away with the bit and a 'welcome back,' it feels like cronyism. --valereee (talk) 13:15, 7 October 2019 (UTC)

One can argue that the person was trusted at the time of their RFA, and their RfA was a valid process. One can also argue that times, processes, people and policies change, and that the trust is no longer necessarily there, nor necessarily still justified. These are things that cannot be arbitrarily prescribed while retaining the trust and respect of the participants. As times change and the community changes, some of the customs and processes may have to change to keep up with others, and it is often difficult to make changes in this community. The time may have come for some changes, but we should try to ensure that they are changes for the better. To do this it will be helpful to identify what needs to be changed, and why it needs to be changed, so that the changes can be chosen on the basis of the expected outcome, and we can see if they actually produce the intended outcome. · · · Peter Southwood ^(talk): 14:48, 7 October 2019 (UTC)

• Support this counter proposal as per Amakuru. While I woiulll continue to discuss individual proposals here, this process was not well thought out, nor was there any preliminary discussion on the format of this RfC. Above all, the first RfC developed a shared feeling that "the process is broken" among many, but with no clear definition of what the problem is, and little to no supporting evidence oif an actual problem that can be solved. This is better withdrawn for now. DES ^(talk)_{DESiegel Contribs} 17:12, 7 October 2019 (UTC)

• DESiegel, this whole thing was predicated by the resysopping I linked to above, a former admin with 1600 edits, including fewer than 25 in the past ten years, whose first edit in nearly three years was followed minutes later by a resysop request, who was resysopped in July and since then has made two edits. It angered many non-admins because it was so clearly problematic that someone who hadn't meaningfully contributed in that long was just automatically sysopped because the crats had no choice; it was within policy. It was seen as inherently unfair. That is a problem. That is what is broken. --valereee (talk) 17:51, 7 October 2019 (UTC)
  • Valereee did that admin subsequently misuse or carelessly use the admin tools, or in general do anything to harm the project, as opposed to simply doing nothing to help? If not, I must admit I cannot see this as a serious problem. But if that is the problem to be addressed, it seems to me that it cannot be done by adding required numbers of edits unless the numbers are made so high that they will also exclude returning admins who make small bu6t significantly positive contributions. I am not worried on my own account. My suggestion of asking a returning admin to certify an intended activity level with the tools seems to me better adapted to handle that specific case than some of the other proposals. I had rather assumed the problem was an actual occurance of or a fear of improper admin actions via unawareness of changed policies. That would require a different solution. DES ^(talk)_{DESiegel Contribs} 19:46, 7 October 2019 (UTC)
    • DESiegel You aren't alone. To many admins, this doesn't seem like a serious problem. To many non-admins, it's evidence of unfairness in our policies regarding sysopping/resyssoping. It isn't so mcuh that some admins have low activity, though that irks people too, but generally not to the point of infuriation. It's that a former admin can be resysopped in the above situation with just a request while long-term productive contributors must go through RfA. It's not that most people are concerned about bad actors. It's that it's infuriating that someone who has made zero contributions in a decade doesn't have to do ANYTHING but ask, and other sysops will go, "Yeah, that seems fair." It's not fair, and it's demoralizing for people who aren't admins. It feels like cronyism. --valereee (talk) 19:59, 7 October 2019 (UTC)
      • Valereee I understand that feeling, and if the community wants to prevent that sort of action, it can surely do so, and I will comply with any community consensus. I do feel that the views you express above are fundamentally misguided. The rule has always been that the key thing an admin had to have was trust - trust not to mis use the tools, trust to be cool and faitr when using admin authority to try to intervene in a dispute, such as an edit war, trust not to act as some sort of "higher being" but as a "janitor" one who has agreed to clean up messes and fix problems. The second requirement is competence -- an admin should know enough about the various processes to implement them properly, or at least know which ones s/he should stay away from; an admin should know Wikipedia policy and guidelines, and generally uphold them, not violate them out of ignorance. Competence depends, in part, on experience -- if one hasn't worked with these systems, one is not likely to really understand how they work. All the people you are speaking of once convinced the community that they were worthy of trust. For all but the very earliest, this was in an RfA. While RfA has changed over time, and while the experience and to some extent the competence requirements are higher than they were, the trust requirement and how it is measured hasn't changed that much. DES ^(talk)_{DESiegel Contribs} 22:01, 7 October 2019 (UTC)

Inactive admins are desysop'd automatically not because they have become less trustworthy, or less competent, but because an unused account is likely to be an unwatched account, more vulnerable to being compromised by a malicious actor. Several such accounts were so compromised, and the current rule was put in place to make that less likely going forward, just as admins are urged to have strong passwords and good security practices. That an andmin was inactive for a year, or even teo, does not imply that the admin was less trustworthy than s/he was when an RfA was passed. If there is good reason to think that an admin is less trustworthy, then an individual de-admin process should be used to remove the tools. DES ^(talk)_{DESiegel Contribs} 22:01, 7 October 2019 (UTC)

An admin who is inactive and asks for the tools back isn't engaging in cronyism, that person is saying "See, my account was not compromised, I'm the same person you agreed to trust before." The non-admin has never been granted that trust.

It is my view that there should be a somewhat simpler and easier way to remove the tools from an admin no longer trusted. This in turn would make RfA less of an ordeal: Since the appointment is now for life, in effect, people tend to be very careful and very picky about who gets the mop. There have been a number of proposals along those lines, none has ever obtained wide consensus. Energy might be better spent in finding an improved process to de-admin those who are no longer trusted.

An inactive admin might be out of daate on policy changes, and therefore less competent. Some of the proposals here try to address that. But that does not seem to be your concern, nor are there many (if any) examples of such situations. If the problem is hat-collecting, we should focus on proposals which deal with hat-collecting. By the way, i don't think it really is cronyism, and I think most active or even irregularly active admins have no more liking for hat collectors than you do, but the 'crats restore their access to the tools because they follow policy, and that is what the policy says. My view is that policies should be to prevent harm to the project, and encourage beneficial actions, and that policies which do neithr are not good ideas, as per WP:CREEP. DES ^(talk)_{DESiegel Contribs} 22:01, 7 October 2019 (UTC)

DES the sysop being out of date on policy changes is my big concern with automatic resysops for long inactive editors and it's why I supported a tighter standard in the original RfC. To me a long dormant sysop coming back and doing nothing is fairly benign. A long dormant sysop coming back and immediately do a lot can be highly disruptive. A long dormant sysop coming back and becoming dormant again is, also, a security risk in that we're not getting any benefit from their possession of permissions while the downside risk of a compromised account remain. Best, Barkeep49 (talk) 22:06, 7 October 2019 (UTC)

Barkeep49, You hit the nail on the head here. I came back from long-term inactivity myself. I stumbled a bit with updated processes when I came back. SQL^{Query me!} 22:48, 7 October 2019 (UTC)

Barkeep49, that is a different problem than the "cronyism" problem, and needs a different solution. We really needed to have a clearer statement of the nproblem or problems we are tryin to solve here, if we are to have a chance of gettign good solutions. DES ^(talk)_{DESiegel Contribs} 23:07, 7 October 2019 (UTC)

DESiegel, well that's whats going to shake out here - is there enough consensus about what the issues are and how to solve them to do something. The fact that there's a clear consensus that they should be stricter is not something which was easily come by - as shown by a few attempting to re-litigate it here. In theory I could see the value of a intermediary RfC where we form consensus about what the problem is that we're trying to solve with a stricter set of requirements but in reality I think we'd burn out participants before we got to the third, solutions, RfC. And thus here we are. Best, Barkeep49 (talk) 00:04, 8 October 2019 (UTC)

DES, Re: whether it's a problem, I guess we'll have to agree to disagree. It pisses people off because it feels like cronyism. That's demoralizing for the non-admin editor. For me that's a problem, but I'm clearly not going to convince you that what non-admins feel about this is damaging to the project. --valereee (talk) 22:25, 7 October 2019 (UTC)

Valereee you are mistaken if you think I don't accept that what non-admins feel about this is relevant or may need addressing. Reed the discussion of the "perception of unfairness " in Process is Important which of which is still as i drafted it. If there is, in fact, a widespread belief, correct or not, that the current process is unfair and an example of cronyism, then that absolutely does need to be addressed. That is why i made one proposal above, and have endorsed soem others. I would prefer that the current RfC be withdrawn, and a more focused one be started, because I think we will get better solutions and not be distracted by solutions to non-problems. But i am not relentlessly oppoed to any action here, nor to treating the views of non-admins as equal in weight to the views of admins. I do caution that you may be overgeneralizing. Are you even reasonably sure that all or most non-admins feel as you do on this issue? If not, you should not claim mto speak for them. DES ^(talk)_{DESiegel Contribs} 23:07, 7 October 2019 (UTC)

Yes, but this problem can also occur with admins who've ticked on over the years doing a bit of editing here and there and done the necessary re keeping the bit, but not really contributing. But then they suddenly decide to dive into an admin area where more thought and policy clue is needed. I've a feeling just such a case landed before ArbCom earlier this year. If that issue is the reason for this RFC, then deal with it properly by workshopping a system to ensure people stay up to date or else lose the bit. But don't sit here slamming unfair penalties on one small group of users whose adminship lapsed through inactivity but decide they want to return, while their colleagues who make 2 deliberate edits per year sit over there gaming the system. Tackle the whole problem or don't tackle it at all, rather than this unfair draconian punishment on people who didn't game the system.  — Amakuru (talk) 22:29, 7 October 2019 (UTC)

Amakuru, you think it's a draconian punishment for someone who hasn't made 25 edtis in ten years to have to run an RfA? To me that just seems logical. They can't possibly have any idea what's going on with WP in 2019. Why is that a punishment? --valereee (talk) 22:37, 7 October 2019 (UTC)

DESiegel You asked I do caution that you may be overgeneralizing. Are you even reasonably sure that all or most non-admins feel as you do on this issue? If not, you should not claim to speak for them. DES, I can show you easily that I'm not overgeneralizing. Read the RfC linked at the top of this page. Non-admins voted 39-8 that we need to tighten up our rules for resysopping. And if you look at the "tighten" votes, you'll see it's a virtual who's who of respected non-admins and includes THREE that since that RfC have become admins. This is not me speaking for them. It's me arguing that they've already told us this is a problem

Contrast that to the "Status quo" vote, by the way, in which there were 35 votes, 27 of them sysops, who made comments like, "Not broke, don't fix it" and "problem looking for a solution." Sysops are about evenly divided between status quo and tighten the requirements. This is an issue in which there is a very deep divide between sysops and non-sysops. If they feel there is a problem, we need to respect their feeling rather than telling them they're wrong to feel that way. --valereee (talk) 11:09, 8 October 2019 (UTC)

• This. Guy (help!) 22:03, 9 October 2019 (UTC)

Arbitrary or Discretionary Judgement?

• The hoard of suggested options, along with the supports and opposes, seem to indicate that those of us who want strengthening are breaking into two main methods: those who want some (harder and/or new) arbitrary requirements in place of the current ones and those who want to give some rough guidance and leave it to a consensus decision, generally by the 'Crats or the community as a whole, possibly with some rough guidance.

Valereee has written an excellent summary of the issues just above.

Thus I think it would be helpful if people can say in a more general sense if they'd prefer various arbitrary requirements, written to cover the concerns, or indicating areas that 'Crats need to consider and make a more discretionary judgement or some mix of the two Nosebagbear (talk) 12:44, 7 October 2019 (UTC)

I am not sure that we should be dropping this responsibility on the 'crats. Appointing admins is the responsibility of the whole community, or at least those in good standing at the time. 'Crats just assess the consensus, which is enough of a responsibility by itself in some cases. Desysopping has been the responsibility of Arbcom, and until there is a change in that policy, that is where it will stay, but that policy could be changed if the community wants it to change. I would guess the 'crats would not welcome too much discretion, as it would be a damned if you do, damned if you don't situation much of the time. Arbcom are elected to deal with this kind of problem, and my personal opinion is that is where it should stay, or a community option for admin recall could be drawn up. As I am one of the admins open to recall, I would support a reasonable procedure for recall with reasonable protection against misuse. I also appreciate that there are a number of admins who feel that this would make it difficult to do their work effectively, and they may be right. The devil would be in the details.
Arbitrary hoop-jumping exercises all seem likely to solve nothing, except possibly as a placebo. Inactive admins may be a security risk, but otherwise they do not appear to do any harm at all by inactivity. If they get active again either they do no harm, or they get stopped from doing harm, which is the minority case, hence my lack of concern about that a problem exists. · · · Peter Southwood ^(talk): 13:16, 7 October 2019 (UTC)

What might be useful would be if the 'crats see a problem they could hand it over to Arbcom, on the understanding that Arbcom would take the case. Arbcom might not like the extra work, or not being able to decline, but that is a separate issue. It would be within their remit, whether they like it or not. [ec extension] Advertise a request for resysop on the watchlist notice, allow 24 or 48 hours for objections, 'crats assess whether there are any substantial problems, and if so refer to arbcom, otherwise return the bit as currently done in most cases. I have no objections to requiring a returning admin to do some constructive work before requesting the bit back, as our purpose is to build an encyclopedia, and any work in that direction is welcome, but do not see it as particularly meaningful other than getting a bit of useful work out of the person, a thing that any Wikipedian would agree is of some positive value. · · · Peter Southwood ^(talk): 13:21, 7 October 2019 (UTC)

I agree that an inactive admin does no harm by simply being inactive. The harm is caused when a former admin who has been desysopped for inactivity requests the bit back. That's when they harm the project because they point out just how unfair our sysopping policy is. To become a sysop, you need to go through RfA. Unless the reason you aren't a sysop is because you've done absolutely nothing -- not even responding to your desysop warnings -- for a long time. If that's the case, other sysops think you should be automatically resysopped because, well...er...that's the way we've always done it, and from the point of view of sysops, it doesn't feel unfair, and if non-sysops think it's unfair, they're wrong. --valereee (talk) 13:30, 7 October 2019 (UTC)

To fix this problem we need to change our sysopping policy in a way that makes it fair. Minor hoop-jumping is not going to make it substantially more fair. The way it is done now was decided by consensus if I remember correctly. Consensus can be misguided, and it can change, but it should be changed for logically valid reasons that are expected to improve the situation in a measurable way, not as an arbitrary substitute for fairness. · · · Peter Southwood ^(talk): 13:45, 7 October 2019 (UTC)

Pbsouthwood, I like your ec extension proposal above and would support it as a move in the right direction, but how does requiring a RfA for someone who has been completely inactive -- so inactive they haven't even bothered to respond to desysop warnings -- for at minimum years constitute an 'arbitrary substitute' for fairness? --valereee (talk) 13:55, 7 October 2019 (UTC)

Unless the problem is defined, and the reasoning behind the proposed remedy is clear, the proposals remain arbitrary to anyone who does not know the reasoning and the problem. · · · Peter Southwood ^(talk): 14:16, 7 October 2019 (UTC)

Sort of related to the above-described split, but if those opposing stricter requirements in RfC 1 oppose here while those supporting stricter requirements divide their support amongst the various proposals, it will be very hard for one to get consensus. ~ Amory (u • t • c) 14:21, 7 October 2019 (UTC)

I agree, and I hope people will support any proposal they feel would be a step in the right direction, even if their preference is for something stronger. --valereee (talk) 14:46, 7 October 2019 (UTC)

Amorymeltzer, you might want to vote for your own proposal, for ease of counting :) --valereee (talk) 15:02, 7 October 2019 (UTC)

Question: have any 'crats weighed in on their preference among those choices? I'd rather not hand them a loose set of requirements and say "we trust your judgment" if they would rather have strict and clear requirements (or vice-versa). creffett (talk) 00:18, 8 October 2019 (UTC)

No, I don't believe any bureaucrats have supported or opposed any of these proposals. Useight (talk) 15:20, 8 October 2019 (UTC)

Is it worth revisiting a universal recall system?

Moved to #Discussion of statement 16

 – Wug·a·po·des​ 05:54, 11 October 2019 (UTC)

Crat Discussion

There is a current bureaucrat discussion behind had about how the crats interpret current policy, particularly around the scenario where a sysop resigns without a cloud and then later does actions that would create a cloud. This ties into some of the proposals here and thus might be of interest to participants of this RfC. Best, Barkeep49 (talk) 16:34, 17 October 2019 (UTC)

Post de-sysop Cloud Discussion

In line with the above link by Barkeep, the 'Crats are generally agreeing that in the case of an Administrator resigning not under a cloud, and then acting poorly "a new cloud", they do not have discretion to deny re-sysopping. Without regard to the specific re-sysopping that caused the discussion, I think this needs to be discussed in general. We don't want to make it too broad, but there must be some bright lines that we can give to 'Crats that if an individual has had certain sanctions placed on them, they would be counted as being under a cloud and require an RfA. This is substantively different from all proposals above, which are activity/purpose driven (and could be met while still being of community concerns).

Some potential thoughts are any sitebans and blocks above a certain length (whatever that might be) Nosebagbear (talk) 22:43, 19 October 2019 (UTC)

How common is it for admins to be blocked or site banned at all? Unless this is more common than I think, any valid block or ban after resignation should be a sensible bright line for referral to RfA. Wug·a·po·des​ 05:22, 21 October 2019 (UTC)

Informality

Under the heading "Review and removal of adminship, don't you think calling Jimmy Wales "Jimbo" is a bit too informal for a wikipedia policy page? --Ghinga7 (talk) 19:17, 26 October 2019 (UTC)

@Ghinga7: - strictly speaking, as his actual account name Jimbo Wales, it's probably more appropriate, as all the authorities are associated with that account. Nosebagbear (talk) 16:27, 29 October 2019 (UTC)

Ghinga7: This edit may resolve the perceived informality. –xeno^talk 16:59, 29 October 2019 (UTC)

Resysops

I'm out of town with ridiculously bad internet currently and can't edit more than a few seconds at a time, so since I can't do any useful editing... This is as far as I can tell the resysops-on-request after desysopping for inactivity since January 2017, leaving out a few that were too recent, to give us all an idea of how frequently resysops after lengthy inactivity do result in useful editors who will edit enough to at least regain/maintain understanding of changes. Of 18 resysops, several have returned to consistent editing, several are maintaining what I'd call at least minimum activity, and 9 probably want to keep the hat but don't really have time/inclination to actually contribute (reasons for that conclusion bolded). I didn't include usernames because I don't think this should be some sort of shaming exercise, but if someone wants to check my work I'm happy to email you the original. Note that this only includes those with a note "previously inactive" at Wikipedia:List of resysopped users; many entries from 2016 and earlier have no note and may be appropriate for inclusion here.

1. Sysopped February 2008. 33 edits between December 2012 and December 2016. Desysopped 2 January 2017 for inactivity. Resysopped 4 January 2017. Made 208 edits January-February 2017, 6 edits since.
2. Sysopped 2003. 13 edits from 2013 thru 2016. Desysopped 2 December 2016 for inactivity. Resysopped 11 February 2017. 241 edits February and March 2017, similar pattern each February/March since plus a few other sporadic edits, for a total of about 650 edits since resysop.
3. Sysopped 23 June 2008. Desysopped 1 March 2017 for inactivity. Resysopped 5 April 2017. Approximately 225 edits April-June 2017, 36 edits since.
4. sysopped 27 July 2012. Desysopped 1 March 2017 for inactivity. Resysopped 6 April 2017. Consistently editing at significant levels (>5000 edits each year) since.
5. Sysopped 30 November 2007. Desysopped for inactivity 1 June 2015. Resysopped 19 April 2017. Consistently editing at significant levels (>12000 edits each year) since.
6. Sysopped 24 November 2006. Desysopped 2 December 2016 for inactivity. Resysopped 1 May 2017. 29 edits in May 2017, 19 edits since. Desysopped 1 July 2019 for inactivity. Currently not a sysop.
7. Sysopped 16 July 2008. Desysopped 1 March 2015 for inactivity. Resysopped 22 June 2017. Consistently maintaining a very low level of activity (currently averaging 3 edits per month) since.
8. Sysopped 1 August 2005. Almost zero activity between 2010 and 2017. Desysopped 1 April 2017 for inactivity. Resysopped 8 October 2017. Sporadic activity since, but high levels when editing, (many months 0 edits, but 7300 edits November 2018 for instance), primarily to user talk.
9. Sysoppoed 26 February 2007. Desysopped 1 October 2016. Resysopped 24 December 2017. 19 edits since.
10. Sysopped 2 December 2006. Desysopped 6 March 2018 for inactivity. Resysopped 27 June 2018. Consistently active July – October 2018. 119 edits since, 5 since February 2019.
11. Sysopp date unknown. Desysopped 1 June 2018 for inactivity. Resysopped 12 July 2018. 30 edits since.
12. Sysopped 6 August 2015. Desysopped 1 August 2018 for inactivity. Resysopped 25 October 2018. Consistently editing at significant levels since (>18000 edits in 2019), primarily to user and user talk (deleted) speedy nominations accompanied by Twinkle edits to user and user talk spaces.changed by —Kusma (t·c) 12:35, 11 October 2019 (UTC)
13. Sysopped 24 March 2009. Desysopped for inactivity 1 May 2018. Resysopped November 19, 2018. Consistently editing at significant levels (>5000 edits in 2019) since.
14. Sysopped 28 December 2005. Desysopped December 1, 2018. Resysopped 21 January 2019. Consistently editing (20-100 edits per month) since.
15. Sysopped 16 April 2006. Desysopped for inactivity 11 June 2014. Resysopped 25 November 2014. Desysopped for inactivity February 1, 2019. Resysopped February 19, 2019. 9 edits since March 2019. 46 edits since 2011.
16. Sysopped 28 July 2011. Desysopped 1 February 2019 for inactivity. Resysopped 13 March 2019. Consistently editing (50-600 edits per month) since.
17. Sysopped 29 July 2009. Desysopped 1 May 2017. Resysopped 19 March 2019. 12 edits since. 60 edits since 2016.
18. Sysopped 23 November 2005. Desysopped 1 October 2017 for inactivity. Resysopped 20 July 2019. 2 edits since. 30 edits since 2008. 1700 total global edits

ETA: (3 very recent resysops intentionally left off this list, as it didn't seem fair/reasonable to assess after such a short time.)

--valereee (talk) 18:05, 10 October 2019 (UTC)

Valereee, this is super helpful. Would it be possible for you to give some number of edits for those consistently editing at significant levels? This might help to figure if there's a line that divides the those 6 from the other 9 (or 12). Best, Barkeep49 (talk) 19:42, 10 October 2019 (UTC)

Barkeep49, totally, I can (with luck, still at the place with crap wifi) likely add it tomorrow morning. If not, the next place may have better wifi. --valereee (talk) 01:25, 11 October 2019 (UTC)

Thanks for putting this together valereee. Does "editing" include logged actions? I wonder how many are using the tools and how frequently. – Levivich 02:07, 11 October 2019 (UTC)

Levivich, I didn't look at logged actions, but if you want to I can send you the original. I figure some adminny things don't get logged, and some adminny things require WAY more time to prepare for 1 admin action than others, so I kind of think logged actions can be misleading. I actually think overall edit counts is a reasonable rule of thumb. Someone who is making 5000 edits per year is inevitably going to run across vandalism or something else needing admin attention, even if they don't go out looking for those things. Plus I'm not sure that's what this is about; that's a different problem, probably. Admins who haven't made a logged action in the past five years are a concern, but those folks are a lot less visible than the ones who ask for resysop. :) --valereee (talk) 09:55, 11 October 2019 (UTC)

Kusma, sorry, I didn't think of how that could be misinterpreted, thanks for the clarification. A ton of edits on user/user talk or various other spaces often means a lot of the same kind of admin or other helpful work. I wasn't intending to indicate this was heavy socializing :) --valereee (talk) 11:49, 12 October 2019 (UTC)

Valereee, it just made me curious what was going on, so I thought I'd go and check and give some more context :) I have seen people draw the wrong conclusions from namespace percentages or numbers of deleted edits or similar at RfA too many times. I like your table very much, also how it doesn't mention names yet makes it easy for the curious to find them. —Kusma (t·c) 14:45, 12 October 2019 (UTC)

• I recently learned that Commons has a slightly different inactivity policy than we do. They do the same notification and logged action requirement, but add that "if the admin responds to the notice as required but then fails to make five admin actions within the period of six months starting at the time of the notice, the rights will be removed without further notice." Would some variation on this be useful? Wug·a·po·des​ 05:27, 21 October 2019 (UTC)
• Thanks for doing this. That's far more permanently barely active admins than I had expected. OK it is possible that some of these inactives have been deleting lots of expired prods and pages already tagged for speedy deletion, but if you do a lot of that well you should wind up with some actual edits from declining incorrect deletion tags. Can anyone see a flaw in moving to a more activity based process, something like auto retiring any admin who drops below 100 actions (edits or logged actions) in the last 12 months, but requiring any returning admin to be active for a fortnight in the last 12 months for each year of absence, with active defined as 50 edits in a fortnight. That solves the fairness issue - we would be open for returning active admins, as for gaming, at least anyone "gaming" the system would be doing something useful in order to regain and retain the mop. At the same time it would make things easier for genuine returns to activity. ϢereSpielChequers 20:52, 29 July 2020 (UTC)

  WereSpielChequers, I think that's what King of Hearts is suggesting? —valereee (talk) 23:24, 29 July 2020 (UTC)

  Yes, it's a little similar to my plan to require 500 edits/actions, of which 100 are admin-related, every 5 years. There are some details to iron out, e.g. how to handle the transition period (regardless of their ultimate opinion on grandfathering, all but a minority believe that we handled this one poorly), what counts as an admin action, what frequency to do the activity checks, etc. One key point is that if you are desysopped for inactivity, you cannot get it back on request. This eliminates the risk that someone gets desysopped thinking they can get it back under certain rules, but then the rules change on them without them noticing. -- King of ♥ ♦ ♣ ♠ 23:34, 29 July 2020 (UTC)

  There's a similarity if your focus is on desysopping the semi active. My focus is on maximising the number of admins who return to activity, and I see our proposals as very different in that regard. As for unfairness and grandfathering, I doubt that my proposal would be seen as offputting or unfair to returnees. Welcome back, four years is it? Spend a couple of months getting reacquainted with the site and then we'll flip the bit back is a much more welcoming message than Welcome back, sorry the rules have changed and you can't have adminship back without a fresh RFA. Also I'm not greatly bothered how active an admin was as an admin, partly because the fewer admins we have, the more adminwork comes straight to you, and I'm not so keen on admins who only do admin stuff. I want admins who are mostly doing non admin stuff - those should be extra buttons, not alternative ones, so I'm OK with a simpler system that either ignores logged actions or counts them as equal to edits. ϢereSpielChequers 08:49, 30 July 2020 (UTC)

  By the way, there is no evidence that desysopping after one year has ever prevented any compromise of admin accounts. So I think desysops should only be for principles, not as an account security precaution. That is why we can make the desysop permanent immediately. -- King of ♥ ♦ ♣ ♠ 23:42, 29 July 2020 (UTC)

  I can remember one incident where an inactive admin account was compromised and then misused by a different person, so it is at least as real a risk as a former admin coming back and bungling with tools they had forgotten how to use. The bigger problem is with admins applying outdated policies or using admin tools with personal policies that differ from any community norm, and if we are honest with ourselves, the solution to that is to take such people to ARBCOM if they are active, not to worry about the inactives. ϢereSpielChequers 08:49, 30 July 2020 (UTC)

Half-measures

I've been following this discussion pretty much since the start, and I wanted to share some thoughts I had on admin (in)activity in general. If these belong in a more appropriate section, I have no issue with it being moved.

• Our existing procedure on admin (in)activity are a big mess of half-measures. Specifically, we have a very low bar for qualifying activity, and then there's an equally low bar for restoration of rights. Personally, I try to avoid being involvement in the bureaucrat end of things because it has always come across to me as a useless exercise in flipping bits.
• I feel that the root cause of these half-measures is an attempt to compromise between editors who don't agree with having admin activity standards and editors who want something with more teeth.
• Speaking strictly anecdotally/in general terms, we have more issues with active admins doing dumb stuff than with admins who edit a few times a year.
• Valereee's section on resysops paints a slightly skewed picture. The list captures largely inactive admins who have been desysoped for inactivity and later resysoped. There are way more admins with those kinds of activity stats who haven't gone a year without edits/logged actions who aren't captured in that list. It's not difficult to find admins whose last 50 edits go >5 years or 500 edits in the past 10 years! As slight aside, I believe there is a demographic reason for this edit pattern. A lot of our legacy admins are young men, who eventually went to university, got a job, and got married (or married all but on paper as is common_{-law, so punny} now), which all reduces time (or interest) in contributing as actively as they did 10+ years ago.
• A drawback of our adminship system is that it is very difficult to get the tools and very difficult to lose them. Consequently, a lot of actions (or lack thereof!) that would be a fasttrack to a WP:SNOW close at RfA are not reasons for losing tools. (In fact I recall making a comment at WP:BN in the past along the lines of "would-be admins fail RfA because they're assholes but we don't desysop/fail to resysop admins because they're assholes.")
• We seem to have 1–2 of these "tighten up activity standards" discussion per year, and invariably, there is never a significant change that comes out of them.
• I'm not sure the right question is being debated here. I think it may be more fruitful to debate the broader picture of what our admin corps should be like. If we want more of a semi-professional group of admins (e.g. checks or edits most days, spends probably >10 or >20 hours editing a week, enough activity to pass RfA in its current state, and so on), then we need to seriously consider a radically different approach to not only (in)activity, but I think RfA in general. Or, if we take WP as a volunteer project where you can edit a little or edit a lot, we may have to accept that the half measures of the present admin (in)activity system are going to yield an outcome where some admins' last 50 edits date back to 2012. Maxim_(talk) 13:41, 11 October 2019 (UTC)

Agreed. And I can vouch for the demographic description described in bullet point number four. I would also like to add something. I'm hesitant and uncomfortable even adding it, because it's really not in my nature to get involved in stuff like this, so I'm just going to say my piece and then peace out. But I saw a lot of discussion above about things being "fair" or not. As a long time editor, I've seen RFA morph over the years. I think we can all agree that the requirements to passing RFA are stricter now than they were ten years ago. Why is that? The common reason I see is "Wikipedia is bigger and more important now, so becoming an admin should be stricter." But I think that's just the reason people give to avoid the real, underlying reason. And that reason is "fairness." People, perhaps subconsciously, want things to be "fair." So, in terms of RFA, that results in the following: if Person A in Year X needed 2,000 edits to pass RFA, then it isn't "fair" to Person A in the future if Person B in Year X+1 comes along and passes RFA with fewer than 2,000 edits. So in Year X+1, Person B will need more than 2,000 edits, say 3,000. Then this process repeats, with each successive person needing to at least match the previous person or else it wouldn't be "fair" to the previous person. Obviously it isn't going to happen exactly in line with every single RFA, but instead an overarching trend. Hence it has become tougher over the years to pass RFA. I've literally seen people's RFA criteria pages saying, effectively, "You need to have better stats than me." And there was some talk that passing RexxS would not be "fair" to Jbhunley. That sort of thing. The same concept happens with resysopping as it does with first-time sysopping: "It isn't fair if Person A doesn't have it at least as difficult as Person B." It results in a lot of emotion and a lot of drama and detracts from why we're here - to improve the encyclopedia. Useight (talk) 16:51, 11 October 2019 (UTC)

Agreed, this seems like one of the main problems with modern RfAs. Not sure how to fix it, but it needs fixing. Κσυπ Cyp   18:45, 11 October 2019 (UTC)

While I can't tell what unspoken motivations editors may have, I think a more straightforward explanation is when a community is small, it can rely on its personal knowledge of given individuals to determine the level of trust to place in them. As it grows, everyone no longer knows each other, and metrics take on a greater significance. As the amount of personalized knowledge shrinks, editors try to compensate with rising numeric standards for their favourite metrics. isaacl (talk) 20:27, 11 October 2019 (UTC)

That, too, could be the (or another) reason. It's hard to say. And that's the trouble - if the root of the problem can't be determined, then we're just addressing symptoms, which is much less effective. Useight (talk) 23:57, 11 October 2019 (UTC)

I think it's more than one problem, but I think community-based desysop might be the answer to (1) not enough admins and the problems with RfA, (2) our disagreements about inactivity desysop and resysop procedure, and (3) the pressure put on Arbcom. – Levivich 00:08, 12 October 2019 (UTC)

I agree with looking at what type of administrator we want to have, and figure out what criteria would screen for this best. If we have determined an editor is diligent and takes considered action and so trust them not to take any administrator actions without understanding current community norms, I believe this trust remains earned over the years, regardless of activity levels. However I do appreciate the community likes administrators to be "one of us", and activity levels is one way to measure this. Re-evaluating the criteria for suspending administrative privileges and reinstating them is one aspect, and if it's an easy win to improve matters, sure, we can change them accordingly. In terms of payoff versus effort, though, I support a broader examination of how the process should be designed to provide positive incentives for the behaviour we desire from administrators (a theme I've discussed elsewhere). isaacl (talk) 20:39, October 11, 2019 (UTC)

Pretty much everything arrived at by anything like a legislative/parliamentary process, including WP policy and procedures, are partial measures by definition and even design. See also WP:CREEP and WP:BUREACRACY. We should only implement restrictions, on anything, to resolve an actual issue. And we're free to rejigger them as needed for better functioning later (just like legal systems, company policies, etc., in the off-WP world). That said, I appreciate the analysis. It's a pretty good overview of some of the issues and meta-issues, even if "it's a half-measure" isn't really a substantial objection in and of itself. And you did a better job that the empty "Statement 13 by Cyp" up there, even if both are motivated by the same concern.  — AReaderOutThataway ^t/_c 07:22, 22 October 2019 (UTC)