Wikipedia talk:Administrators

From Wikipedia, the free encyclopedia
Jump to navigation Jump to search
Wikipedia Help Project (Rated NA-class, Top-importance)
WikiProject iconThis page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
 NA  This page does not require a rating on the project's quality scale.
 Top  This page has been rated as Top-importance on the project's importance scale.


Resysop criteria: RfC on principles[edit]

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.
The arguments between O1 and O2 basically boil down to "it's not broke" / "it's broke". With nearly 2/3 of the opinions in favour of Option 2, it looks like we'll be putting forth a second RfC to try and figure out the specifics of a stricter policy. Primefac (talk) 20:02, 5 October 2019 (UTC)

One of the biggest issues with any RfC about activity requirements is that they fail because no one likes specific proposals. To try to deal with that issue, I'm starting the first of what is a potential two part RfC with the following options:

  1. Option 1: The status quo – the resysop criteria for inactivity should remain the same.
  2. Option 2: Stricter – the resysop criteria for inactivity should be made stricter in some way.
  3. Option 3: Looser – the resysop criteria for inactivity should be made less strict.

Ideally, if option 2 or 3 gain consensus, a second RfC focusing on specific proposals based on the principle that achieves consensus would take place. The goal here is to see what the community consensus on the status of the current policy is, not to discuss specific proposals. TonyBallioni (talk) 03:25, 20 July 2019 (UTC)

Option 1[edit]

  1. As an example, El C returned in 2017 after being mostly away for 8 years.[1] His work is just as valuable and competent as it ever was. Jehochman Talk 03:43, 20 July 2019 (UTC)
    El_C is indeed very good, but even in that case, I think it took some time for them to get back up to speed. In any case, one specific example doesn't really prove the general case, and (at this point) we have no idea if the re-sysopping criteria are tightened up, if El_C would have qualified or not, mostly because we don't know what they are yet. Beyond My Ken (talk) 05:21, 20 July 2019 (UTC)
    Just pointing out that the last time El C was desysopped for inactivity was in 2013, and he was resysopped within the month at his request. To my knowledge, there has been no serious discussion of concerns about his adminship since that time. Therefore, I return to my key point: resysop criteria aren't the issue here, it's just code for "change the retention criteria". Risker (talk) 00:25, 23 July 2019 (UTC)
    El_C is an outstanding administrator; he has both the courage to stand up for what he believes is right, and the patience to engage with others who may be having a rough time finding their place in our community. Wikipedia is much better off with him having the tools. Stricter resysop criteria might have prevented his return, and that would have been a clear net negative. Kurtis (talk) 07:22, 23 July 2019 (UTC)
  2. Adminship is really about the person behind the account. And as long as the person is the same, I'm happy for people to regain access. I also think we're going up the wrong tree here. The reason people are concerned about people who might not be perfect or are outdated regaining admin status is because removing that status when problems do occur is insanely hard. I think fixing that is a much more worthwhile (albeit more difficult) problem to solve. Legoktm (talk) 03:55, 20 July 2019 (UTC)
    Not fixing Problem A because the vaguely-related Problem B also exists is not good logic, especially when Problem B has been a spectacularly hard one to solve after many years of attempts to do so. Beyond My Ken (talk) 05:21, 20 July 2019 (UTC)
    • Moved to Option 2. Wug·a·po·des​ 05:32, 23 July 2019 (UTC)The bit is a set of tools. If someone still finds use for them, even limited use, it's a net negative to the encyclopedia to remove them as long as the editor isn't causing problems. Recent changes to the software which prevent admins unblocking themselves limits the potential damage from compromised accounts, so security arguments hold less sway for me than they would have a few months ago. That said, I do appreciate the concerns about security and could live with some minor tightening to something like "make one logged administrator action every so often" to show that the editor actually has a use for the tools. In general though, if an editor was competent enough 3 years ago to use the mop, I trust that they're competent enough to read the fucking manual before doing things they know could cause problems. Wug·a·po·des​ 05:24, 20 July 2019 (UTC)
  3. Admins have been selected as they are responsible and will not do things beyond their competence. Some of use that have been admins for a long time have probably found a niche for actions, and returning to that area should not have issues. when going to unfamiliar territory, I would expect them to find out the rules for that. There was no evidence supplied of problems, so the rules have no reason to be amended. Graeme Bartlett (talk) 05:32, 20 July 2019 (UTC)
  4. If it ain't broke, don't fix it. We may regain a useful, productive administrator. We may regain an administrator who uses their tools appropriately but infrequently. Both of those options are good for the project, although obviously the first is the best. Or, we may welcome back a rogue administrator. We have plenty of tools to deal with that, and the scanty record of that specific adminstrator would be a major factor in any discussion about their conduct. In conclusion, we need more administrators rather than fewer. Do not brush off our early administrators who did not resign under a cloud. Welcome them back, while encouraging them to familiarize themselves with our current norms, and to be cautious. Cullen328 Let's discuss it 06:13, 20 July 2019 (UTC)
    If it ain't broke, don't fix it. It's broke. Fix it. —/Mendaliv//Δ's/ 06:18, 20 July 2019 (UTC)
    Mendaliv, please present convincing evidence here that the current process is broken. I readily admit that I am an old guy who does not follow the recent trends closely. I want to see rock solid evidence that this is an ongoing problem. Thanks. Cullen328 Let's discuss it 06:25, 20 July 2019 (UTC)
    Cullen328, personally I think any policy that winds up with someone saying "I'm uncomfortable with this but my hands are tied" is a policy that at the very least needs a review. I'm definitely not advocating that we force all inactive admins through RfA, but I think there is a middle ground between that and a full, immediate, automatic re-sysop. CThomas3 (talk) 20:58, 20 July 2019 (UTC)
  5. I'm going to plant my flag here for a couple of reasons - firstly, I think the activity criteria are absurd, easily gamed and even for active administrators who do a couple of logged actions every few months, they can pick the easy, non controversial, can't-go-wrong actions to carry out. They can close an obvious XfD as 'delete' and then delete the page/file, they can CSD a very obviously spammy/promotional page, they can CSD a clear cut copyright violation, or they can block a slam-dunk vandal. It's largely what I do, to be honest, because I lack the time to review and potentially place sanctions on users involved in complex situations. It means that getting back up to speed with current trends and thinking on complex situations, on things like current discretionary sanctions and the like takes some work and time. In short, despite being a permanent presence here since passing my RfA 12+ years ago, I feel I could easily make the same problematic administrator actions as are being discussed in the section below (though I would like to think, being self-aware in this respect will stop me from doing this). I don't think it's a unique enough problem to pick on the old, gone away for several year types of administrators. My second reason is much more simple - we need different ideas, we need some (more) of the old-guard to come back and give us the benefit of their experiences with Wikipedia, particularly useful, I think, are those who haven't really seen the site and culture much in a lengthy period and can give us a more disconnected, dispassionate assessment of what we're doing right and wrong. Nick (talk) 06:51, 20 July 2019 (UTC)
  6. Agree with Nick. in general, but do not see the harm in what has been described as gaming the system, which does indicate that the person is still alive and paying some attention. · · · Peter Southwood (talk): 07:11, 20 July 2019 (UTC)
    I am going to stick with this option on the grounds that the question is wrong. I do not see this as a place where "stricter" or "looser" requirements for resysopping are meaningful options. What we need to identify are the problems, and the causes of the problems, and then consider actions which adress the problems and the causes of the problems. Changing the criteria without an understanding of the actual problem is poking it with a stick in the dark. · · · Peter Southwood (talk): 09:33, 25 July 2019 (UTC)
  7. Another, "it ain't broke, so don't fix it" !vote. We get is approximately right: if someone's inactive for some time, we suspend their bit but give it back, with a gentle reminder (direct or indirect, just by having to ask) to reflect on how the environment may have changed. If someone is truly completely absent for a Really Long Time, we pull the plug. If someone comes back and mops poorly, we can help them come up to speed, or if there's a deeper problem (unwillingness to adapt), we'll deal with the problem (up to possible desysop) then. But overall, we have much more of a challenge with a) admin retention, b) admin tunnel vision from what they go through in the trenches, c) proliferation of rules, and rules-based thinking as opposed to clue, than with admins breaking the wiki after returning from inactivity. Martinp (talk) 12:10, 20 July 2019 (UTC)
  8. Per Cullen328. GABgab 14:48, 20 July 2019 (UTC)
  9. Unless there's a way to de-sysop some of the very old-time admins who haven't been active for a decade, I don't think changing the current re-sysop rule solves any problems. power~enwiki (π, ν) 15:56, 20 July 2019 (UTC)
    Erm, they're automatically desysopped after a year of inactivity? What's being discussed here is under whether they should be allowed to come back automatically, and if not then under what terms. ‑ Iridescent 16:11, 20 July 2019 (UTC)
    I mean, the problem I see isn't the lack of recent activity, it's the comparatively lax standards for adminship historically, combined with the 2-edit-per-year activity for ten years. I'm not opposed to a token amount of re-engagement with the project for re-adminship (maybe 10 edits to article space). power~enwiki (π, ν) 16:52, 20 July 2019 (UTC)
    power~enwiki, if you're not opposed to token amount of re-engagement with the project for re-adminship, I'm curious why you're here. There are no proposals for specific requirements now. All this RfC is asking is whether or not the community wants any change at all to the resysop policy. If you look at the comments below, most of them would likely be fine with a requirement for token re-engagement as something better than what we have now. TonyBallioni (talk) 17:01, 20 July 2019 (UTC)
    I do see a difference, though you may not. An activity guideline doesn't change who is eligible for re-adminship, it just means they have to jump through some hoops first. I'm fine with hoops, I oppose a change to who is eligible to go through those hoops. power~enwiki (π, ν) 21:11, 20 July 2019 (UTC)
  10. I'm with Cullen328 on this. People have been routinely complaining when old admins request their bits back, citing fears of out-of-touchness and the like but so far, I cannot remember any instance of such a resysop actually causing problems like that. Section 2 is full of comments like "Far too many controversial resysops", "obviously" and "aren't fit to return immediately" but can anyone actually provide examples of that? We don't block before a user has done something wrong. We don't protect articles before something happened. Why should we require returning admins to go through hoops (RFA or similar) if there is no evidence whatsoever to support it? This sounds like process for the sake of process... Regards SoWhy 16:55, 20 July 2019 (UTC)
  11. I personally think that the current criteria is appropriate. For me, the main concern with resysop after a long period of inactivity is that the risk that the account may have been compromised and is no longer under the control of the original user. As long as that issue, which I believe is rare, has been protected against then I don't see the real need to make the process any tougher on returning admins. Michepman (talk) 18:21, 20 July 2019 (UTC)
  12. If we want to end "adminship is for life", we should end that, not fiddle with the re-sysop procedures. Making RFA expire after 10 years would make more sense. —Kusma (t·c) 18:46, 20 July 2019 (UTC)
  13. If I recall correctly, the initial impetus behind introducing activity criteria for admins was one of security of admin accounts, there had, I think, been a hijacking of inactive admin accounts. This has since been countered by the introduction of activity criteria for admins, the requirement for stronger passwords for those with advanced permissions and the introduction of 2FA.
    This RFC makes no mention of securing admin accounts, rather it seems to seem to be about ‘I don’t like it’ when admins request their bits back after a lengthy period of inactivity. No evidence has been provided that the current activity criteria are problematic in any way. For these two reasons - that this RFC is not concerned with the security of admin accounts and no evidence has been provided that there is a problem with the current activity criteria - any proposal for changes to the current activity criteria should fail. Malcolmxl5 (talk) 00:56, 21 July 2019 (UTC)
  14. This would just create more instruction creep for what is already an extremely difficult to comprehend policy. Remember when being a sysop was no big deal? —pythoncoder (talk | contribs) 16:38, 21 July 2019 (UTC)
    I’m curious how an RfC with no actual instructions or proposal can lead to instruction creep? If anything, any change would simplify the complex timelines. TonyBallioni (talk) 17:39, 21 July 2019 (UTC)
    TonyBallioni, option 2 says "the resysop criteria for inactivity should be made stricter in some way". That includes silly things like "must have at least 5 edits to WP:ANI in the last 5 years, at least 12 blocks during the last 1500 days, and at least 50 edits and 3 other log entries in the past 327 days". I don't see anything in the proposal that makes me expect it will become less complex than it is now. —Kusma (t·c) 18:15, 21 July 2019 (UTC)
    That’s a strawman argument about proposals that have never been made, would never be made, and if made would get voted down in a heartbeat. The two lines that are getting the most traction below are adding some discretion or lowering the time to request resysop. Both of those would likely be easier than the current 3/5 calculation, but, again, this isn’t even about specifics, it’s about if the community is satisfied with the current language of the policy. TonyBallioni (talk) 18:22, 21 July 2019 (UTC)
    (edit conflict)Why would that necessarily be “instruction creep”? It’s a simple rule as it is. Refinement and improvement of a rule isn’t instruction creep. —/Mendaliv//Δ's/ 18:23, 21 July 2019 (UTC)
    If we're concerned about the RESYSOP policy being too complicated, we could always do away with it entirely. Then every resysopping would have to be by consensus at RfA. Perhaps that should be one of the options in the upcoming RfC (if Option 2 wins) for those concerned about instruction creep. – bradv🍁 18:34, 21 July 2019 (UTC)
  15. I am in the "not broke/don't fix" camp and endorse the comments of User:Malcolmxl5. --kingboyk (talk) 00:14, 22 July 2019 (UTC)
    LOL @Kingboyk: [2] ——SerialNumber54129 14:10, 22 July 2019 (UTC)
    Do you have a point to make or are you just having a laugh at my expense? --kingboyk (talk) 17:02, 22 July 2019 (UTC)
  16. Essentially, I'm with Martinp here. What use is it to make returning a tad more difficult, when the real problem might be a compromised account? Lectonar (talk) 07:44, 22 July 2019 (UTC)
  17. Show me some examples of long-term absent admins returning where they screwed everything up and/or went on an insane rampage - enough to outweigh the many examples of long-term absent admins returning and doing so successfully - and I'll change my mind. I am tired of saying we need to make the climb to admin status less steep, not steeper. Fish+Karate 12:57, 22 July 2019 (UTC)
    Perhaps the unfortunate Andrevan case would sway your opinion? That heap of WP:RGW drama wasted a lot of editor and admin time, starting at AN and ending at ArbCom. Granted, Andrevan had not lost the tools due to global inactivity, but he was making little use of them until he went ballistic on editors he perceived as "paid Russian/GOP/NRA advocacy agents". The recent desysop of Rama is also a case of tool abuse to right great wrongs by an otherwise rather passive admin. — JFG talk 13:01, 23 July 2019 (UTC)
    @JFG: Thanks for the examples, I agree these were serious issues but I don't think either Andrevan or Rama were resysopped before their escapades? Fish+Karate 15:16, 23 July 2019 (UTC)
    That is correct; however they are representative examples of the "I'm infallible" mentality of certain early-days admins who have made no significant use of their tools in several years, and suddenly wield them in disruptive ways. A lack of use of admin tools should in my opinion lead to automatic removal after a couple years, under the "no big deal" philosophy; I do realize that's probably for a different discussion about the inactivity threshold. — JFG talk 15:28, 23 July 2019 (UTC)
    As someone who strongly argued in favor of Rama's desysop, I certainly understand where you are coming from. However, those cases also demonstrate that the established processes can handle such admins if and when they decide to start a RGW-crusade, To be fair, I will admit that my view on this is probably influenced by the fact that I might have been one of the "victims" of such a stricter rule during my real life induced 2012-2016 stretch of low activity. Regards SoWhy 15:43, 23 July 2019 (UTC)
  18. Per SoWhy. Useight's Public Sock (talk) 14:34, 22 July 2019 (UTC)
  19. The request misses the point. It's not the resysop requirements that are at issue. It's the retention requirements that are problematic. I have yet to see any evidence from anyone that there has been a problem with inappropriate admin actions of resysopped admins and, absent that evidence, this is a solution looking for a problem. Now, if you were going to propose that we change the retention criteria, I'd look at things a lot differently. Risker (talk) 00:20, 23 July 2019 (UTC)
  20. I largely agree with Cullen328 and SoWhy. There's no evidence that resysopped administrators have caused any problems, so why prevent old hands from returning? Most administrators are competent enough to get themselves up to speed before doing anything reckless. Kurtis (talk) 07:34, 23 July 2019 (UTC)
    I should add, however, that I like the suggestions of Mendaliv and Cryptic in the Option 2 column. Kurtis (talk) 07:41, 23 July 2019 (UTC)
  21. Although it certainly can be gamed, I think the most important criteria for restoring admin status isn't edit counts but Over five years since administrative tools were last used. If a former admin hasn't performed any admin activity in over 5 years, they should have to go through an RfA. So much can change over 5+ years. As this is the current policy, I guess I'm supporting keeping things the way things are. Liz Read! Talk! 00:24, 24 July 2019 (UTC)
  22. I am honestly failing to see the point of this? The main complaint about the RfA process, as far as I ever recall is the that fact that it is (typically) an awful process, one where anyone you’ve ever pissed off (and their mates) will scrutinize minute details of edits to make you look like the worst candidate ever. That issue cannot be resolved by making the process “easier” or more difficult. Further, in terms of inactive admins — who cares? I was effectively MIA between 2010-2015 and even then not really doing a huge amount of admin tasks again until May of this year. I was busy. Life happens. That’s the point of volunteer work. Unless you prove yourself incapable why the hell are people so worked up to ensure admins are “in the loop” with all the Wiki-drama they may have missed? Hell, many admins stay out of the drama and stick to doing “admin work” and effectively are active but out of the loop. It’s a ridiculous concept. When I returned from a long period of inactivity Wikipedia didn’t burn down (and let’s be honest the basics around admin tasks have largely unchanged over the years). Anyhow, none of these proposals, in my opinion, addresses how to make the RfA process “better”. There are fundamental issues to address, which, in my opinion, behaviour of groups of people against others is a major one that feeds into the RfA issue as well. This is a deeper issue and not something that can be fixed by amending a procedural process. N.J.A. | talk 01:51, 24 July 2019 (UTC)
    As someone who, in 105 consecutive months had exactly five months with more than 20 edits (July 2010 to April 2019), I'm really not surprised you don't see the problem. —/Mendaliv//Δ's/ 01:59, 24 July 2019 (UTC)
    Do tell. What do you believe the issue is that I have missed due to a random number you’ve cited? Specific examples are ideal, e.g. something I missed during the period of inactivity along with examples of how, upon my return, I clearly demonstrated an ineptitude due to said inactivity and further what you propose would resolve such issues moving forward? N.J.A. | talk 10:02, 24 July 2019 (UTC)
  23. Being one that was away for a while at times, then coming back I'll say this: People are elected to RfA because the community trusts them to use common sense in how they act. That doesn't change over time. If someone comes back and makes a mistake, that's fine, and we show them what's new. If someone comes back and screws up a lot - then they shouldn't have been an admin. in the first place. (and they get desysoped) If there were a flood of returning admins being brought to wp:rfar then I could see changes being made. Trying to fix a problem that doesn't exist usually creates tangent problems. (edited 8/3/2019) — Ched :  ?  — 12:39, 26 July 2019 (UTC)
  24. I've seen that most admins have enough sense to get themselves up to speed on what's changed after an extended absence. No sense in attempting to reinvent the wheel IMHO. OhKayeSierra (talk) 01:16, 29 July 2019 (UTC)
  25. Largely a solution in search of a problem. Neutralitytalk 18:37, 3 August 2019 (UTC)
  26. I worry about minimum requirements exacerbating burnout / stress in existing admins. I'd rather an admin that was in a period of stress took then time they needed without the added stress of worrying about hitting some arbitrary limit of activity. Such policies have to be consider in terms of who they might impact. I worry making the requirements any stricter will slightly increase the chances that admins facing burnout may suffer a breakdown which is bad for the project as well. Without stronger evidence of the harm of allowing admins to return I can't support strengthening the requirements. PaleAqua (talk) 21:03, 3 August 2019 (UTC)
  27. We need more good admins. Keeping it relatively easy for former admins to return may help. Jonathunder (talk) 04:27, 4 August 2019 (UTC)
  28. If the user has not done anything to show that s/he can't be trusted with the tools, then why not? --rogerd (talk) 04:46, 4 August 2019 (UTC)
  29. We're doing fine. No change is needed here. -- œ 05:20, 4 August 2019 (UTC)
  30. Three reasons. One, Per u:Risker, the problem is not in being to easy to (re)become an admin, the problem is that it is too hard to remove one that is causing trouble; Two, per u:Nick, low activity admins are not a problem (I think, I do only a few easy actions when I have the time, so that the ones that are more involved may focus on harder tasks, am I hurting anything?); Three, all mine, I know it may be hard to get consensus, but I rather dislike a RfC process of slicing out opposition, this RfC may be approved by 60% then some stricter rule (out of a set of only stricter rules) be approved by 60% and bingo! a "consensus" of 36% is born. - Nabla (talk) 10:48, 4 August 2019 (UTC)
  31. The system works fine as it is. Mjroots (talk) 11:50, 5 August 2019 (UTC)
  32. Solution looking for a problem. Stifle (talk) 15:26, 6 August 2019 (UTC)
  33. Per Fish+Karate. I think the drama and stress created by extra RfAs would surpass the drama and stress caused by extra desysoppings. DaßWölf 03:26, 7 August 2019 (UTC)
  34. Solution looking for a problem, if it ain't broke don't fix it . Note: I had trouble doing admin tasks from an Iphone when my computer died.. Got another computer and now it becomes easier. I just want an automatic way to avoid someone finding the username and password of an inactive, incapacitated or dead admin and coming to do mischief, or even selling it on the dark web.. A long period of time with no activity leading to deadmin satisfies my concerns. If an admin spends some time in military service, recovering from illness, doing a dissertation, or launching a startup and wants to come back I would welcome them. Edison (talk) 21:33, 7 August 2019 (UTC)
  35. I've read all the Option 2 votes and discussions below, and did not find a single example of a (real, not potential) problem arising from the current policy. Vanjagenije (talk) 14:52, 23 August 2019 (UTC)

Option 2[edit]

  1. There have been multiple controversial resysops within the past year. While I do not personally think having an extremely strict resysop criteria is ideal, 1 logged action 5 years before an inactivity desysop and a logged in edit or action within 3 years is a bit ridiculous. Even in the 3 years since I have become active on the project, the culture and policy applications have changed. I can't imagine coming back after 2 years and 364 days and being familiar with everything that was going on. Having some higher standard is needed. I don't know what that standard is yet, but moving in that direction and recognizing we need to move there is important. TonyBallioni (talk) 03:25, 20 July 2019 (UTC)
    But the wiki is pretty big, so you (and any other admin) is not familiar with everything going on whether your last action/edit was 5 secs ago or 2 y + 364 days. If we decided years ago we trusted someone to have enough Clue at some point to not break stuff, why can't we by default trust them to get informed before acting in either case? Not trying to pick on you specifically, but I'd wish we'd harness the energy behind these periodic community outbursts of "Must Man the Ramparts Against Dangerous Returning Admins" into "let's help admins at any level of activity stay on top of changes in policy and its application." Martinp (talk) 12:27, 20 July 2019 (UTC)
    Admins are expected to participate in the project if they're supposed to be admins for it, and given that it's a dynamic project, one should be expected to at least try to keep up with changes. This proposal is in fact exactly "let's help admins at any level of activity stay on top of changes in policy and its application". No one who doesn't participate on the project can be helped so that is the first step.--Jasper Deng (talk) 17:42, 20 July 2019 (UTC)
    As far as I can tell, the "controversy" was pretty much at BN, caused by people who don't like the current system but are unwilling or unable to provide any evidence that it's not working; the rules were followed, generally speaking, and I have yet to see any evidence that any of the resysops resulted in any problematic administrator activities by the resysopped admins. Risker (talk) 00:40, 23 July 2019 (UTC)
  2. While I'm pleased that we have an automatic desysop criteria, which we didn't have before, I agree that the resysopping criteria is much too lenient. While many people say that we need more admins, in actuality what we need is more active admins, not hat collectors. The criteria should help ensure that if resysopped, the admin wants to be, and will be, more active. Beyond My Ken (talk) 03:35, 20 July 2019 (UTC)
  3. Support: Honestly this is the opportunity to begin trying out some continuing education mechanism. Conditioning restoration of admin rights for people who have been out of the loop for more than a year on taking some kind of continuing education gives us a great testbed for this, frankly, which should be a requirement for all admins. —/Mendaliv//Δ's/ 03:39, 20 July 2019 (UTC)
    I agree. Beyond My Ken (talk) 05:15, 20 July 2019 (UTC)
    In principle, an interesting and possibly useful suggestion. Take it further. · · · Peter Southwood (talk): 07:17, 20 July 2019 (UTC)
  4. Long term we need to draw back in formerly active project members. But that doesn't mean an easy reentry to sysop is the right way to do so. There are several ways I can think of that I would support as drawing a better balance between competing priorities. Best, Barkeep49 (talk) 03:44, 20 July 2019 (UTC)
  5. Sadly probably symbolic because long-term inactive admins will suddenly reappear and oppose this proposal. But I support this. --Rschen7754 03:49, 20 July 2019 (UTC)
  6. As an admin who returned after many years away. If nothing else, I'd expect a reasonable amount of activity before being resysopped, the same way I'd expect an inactive but not-actually-desysopped user to spend some time reacquainting themselves with the project before diving right back into administrative tasks. —Cryptic 03:56, 20 July 2019 (UTC)
    I've put myself in Option 1 above (since I really don't think there's a problem worth fixing by more Rules here). But I wouldn't oppose a modest editing activity requirement before re-adminning, like "edit (outside own talk page) for at least [5] days in the last month", something that encourages ongoing re-engagement with the community for a while, not something that just encourages going and doing a mass of mindless edits in one evening. Martinp (talk) 12:33, 20 July 2019 (UTC)
  7. Support per above. Far too many controversial resysops for my liking. If people aren't going to use the mop and bucket, then they don't need access to them. Adminship is not a trophy. -FASTILY 05:27, 20 July 2019 (UTC)
  8. I think Cryptic has an excellent idea here. It’s not that I oppose re-sysopping of long-inactive admins, because I don’t, but why are we doing so immediately upon their return? There is plenty to do as a normal user, and we should be requiring at least some demonstration of sustained activity and ongoing commitment to the project prior to a re-sysop. We expect no less of our new admins. A review of this activity wouldn’t require a RFA, but could essentially skip straight to the ‘crat chat. CThomas3 (talk) 05:31, 20 July 2019 (UTC)
    A very reasonable condition. · · · Peter Southwood (talk): 07:17, 20 July 2019 (UTC)
  9. Support I've never been a fan of those who play the system and make a token edit once every 12 months to hold onto the tools. I guess though, by default, they're not admins, as they're not here to do any admin-esque work. Maybe a cull of the most repeat offenders would be the solution. If they feel strongly about retaining the tools, then an RfA would suffice post-desyopping. Lugnuts Fire Walk with Me 05:43, 20 July 2019 (UTC)
    I guess though, by default, they're not admins, as they're not here to do any admin-esque work. One of the differences, though, is that these folks still have access to deleted materials. People who are not current on the standards for administrator conduct shouldn't have access to deleted materials, which are often sensitive for reasons that don't meet the oversight standards (or which have simply escaped notice by oversighters). —/Mendaliv//Δ's/ 06:13, 20 July 2019 (UTC)
  10. Obviously, yes, the current requirements are far too loose. Boing! said Zebedee (talk) 05:47, 20 July 2019 (UTC)
  11. Obviously. We don't need a complicated set of timescales; all we'd need is the addition of a single line along the limes of "if the applicant was desysopped more than (six months? twelve months?) before requesting the restoration of permissions, the restoration will not be automatic but instead will be subject to a vote among the current bureaucrats". Since this discussion has already been personalised I'll take the same example; if El_C is such a fantastic asset to the project, he presumably would have had no problem demonstrating that to the 'crats and convincing them that giving him the admin bit would be a positive. ‑ Iridescent 06:22, 20 July 2019 (UTC)
    So you would add a rule "crats should restore adminship if they believe this is a positive thing"? That sounds like a quasi-RFA in which only crats participate and that basically overwrites the RFA consensus that granted the sysop in the first place. What if crats believe someone should not be resysoped because they were a controversial admin back when they were active even if they were never formally admonished? Crats are tasked with interpreting consensus and this would give them the ability to not only establish consensus but replace community consensus with their own. That seems problematic. And yes, I would probably trust the current roster of crats to make the right decisions in such cases. Regards SoWhy 17:07, 20 July 2019 (UTC)
    If I were Dictator of Wikipedia I'd either make adminship auto-expire after three (maybe five) years of activity or one year of inactivity, with anyone wanting to continue as an admin having to re-sit RFA, or go with the de-wiki model of cumulative complaints forcing a reconfirmation once they reach a certain level—either would simultaneously purge Wikipedia of those who'd lost public trust, and bring back "no big deal" as a concept since the RFA voters couldn't be too picky unless they wanted to wreck the project altogether. However, I don't believe there's sufficient appetite for such a radical change, so the best we can do at present is prune away the most egregious elements of "adminship is a lifetime position" and then see where we stand once the "I will give up my admin bit when you pry it from my cold dead fingers" contingent have realized that the change has occurred and the sky has not fallen in. ‑ Iridescent 18:58, 20 July 2019 (UTC)
    On the basis of this comment alone, Iridescent, you have my !vote whenever you decide to open your RfDoW. Happy days, LindsayHello 22:26, 20 July 2019 (UTC)
  12. Support automatic reysop for historic users is an unnecessarily loose position to hold, the tools and trust levels are very different in modern times and as such are given less freely than they were in the early days. Can I have my advanced permissions back please when there is no evidence at all that they will or have the experiance to actually use them for the benefit of the project seems much less beneficial than offering the tools to really currently active experianced contributors that would actually use them. Govindaharihari (talk) 07:01, 20 July 2019 (UTC)
  13. Support per supporters; suggest that!voting on this RfC, parts one and two, is restricted to editors with over e.g. 25 edits over the last calender month. ——SerialNumber54129 07:09, 20 July 2019 (UTC)
  14. Support If we are discussing ideas, the idea of voting before a resysop sounds okay to me, there's the popular notion of people coming who have an axe to grind but there are literally tons of wikis with proper measures in place and none of them have been set on fire yet. I suggest voting is restricted to editors with more than 100 edits in the last year (i.e. date of voting). --qedk (tc) 07:44, 20 July 2019 (UTC)
  15. Support. Stricter resysop criteria would encourage participation from administrators, and help ensure that admins are up-to-date with changes to policies and guidelines. Tightening the criteria would be a net positive if the resulting increased participation outweighs the few edits/actions a year we would lose from admins who wouldn't meet (and wouldn't be motivated by) the new requirements. The only way to determine the effects of these changes is to conduct a trial, which I recommend. — Newslinger talk 08:33, 20 July 2019 (UTC)
    Additionally, changes in policy don't necessarily need a perceived "problem" (although others have made the case that the status quo is problematic). Changes can be justified if they encourage positive behavior, including participation. — Newslinger talk 21:43, 21 July 2019 (UTC)
  16. Support. Maybe give them all the other tools and ask them to work on tough areas for a month; and crats take a vote, maybe admins as well, or some other criterion of inclusion for very active very experienced editors. Maybe ask them to edit actively for three months and go through an RfA with strict criteria for eligibility of the cast vote. Anything but the current norm of getting it immediately by asking without anything to show that they mean business and not just trophy collecting. Usedtobecool ✉️  08:57, 20 July 2019 (UTC)
  17. Support. I'm concerned whenever someone who earned the role a decade ago comes back with a few sporadic edits during the interim and is returned the role with effectively no questions asked. I'd be hard-pressed to give someone rollback if their last major spree of editing was during the sites infancy. Make it two years and a required amount of edits and maybe it'll be more understandable. Taking a break for a few months is fine. Taking ten years off is fine too, but one shouldn't expect to come back to the site's most powerful buttons. Anarchyte (talk | work) 09:22, 20 July 2019 (UTC)
    @Anarchyte: this, but it also includes abusefilter, template editor, interface editing, etc etc etc. — xaosflux Talk 13:56, 20 July 2019 (UTC)
    @Xaosflux and Anarchyte: I agree with this. I don't see why other advanced permissions shouldn't be treated similarly. CThomas3 (talk) 20:53, 20 July 2019 (UTC)
  18. Support people who were active a very long time ago but haven't been very active since often do not make good administrators if they return to activity, because they aren't familiar with accepted norms. If they do attempt to perform significant admin actions they often do inappropriate things. The current standard is ridiculously generous. Hut 8.5 10:34, 20 July 2019 (UTC)
  19. Support since wp:competence is required and things have changed fast. Not just admining, but everything starting from how content is created etc. --Pudeo (talk) 10:57, 20 July 2019 (UTC)
  20. Support But mainly only if it is a subjective criteria rather than an objective one. Something like "legitimate issues are raised by the community during the course of the waiting period, and there is a consensus among crats that the user's level of activity is well below that which would normally qualify a candidate to stand for RfA". (Note: stand for RfA, not pass an RfA.) Different objective criteria will only lead to different gaming, and we can't anticipate every situation. We give crats limited discretion in RfA and I don't see why they should have zero equivalent discretion in resysops. We definitely shouldn't rope ourselves into a situation like this where we have crats saying essentially "I'm not comfortable with this but our hands our tied", and people like me trying to carve out the most niche possible crevice in policy to try to justify the concerns of the community (in this case, "are you active enough to give literally any answer whatsoever to issues raised under ADMINACT"). GMGtalk 11:31, 20 July 2019 (UTC)
  21. Support Unequivocally - as I have always maintained at every opportunity. Leaky caldron (talk) 11:47, 20 July 2019 (UTC)
  22. Support . I think this is really a no brainer. The policy needs tightening up but we should wait for the outcome of this RfC before discussing specifics. Kudpung กุดผึ้ง (talk) 11:51, 20 July 2019 (UTC)
  23. Support - The policy does need tightening up, I've never agreed with resysops for those who make 1 logged action every 5 years or a logged in edit or action within 3 years but never opposed them as technically policy currently allows it... so I certainly support tightening the policy up. –Davey2010Talk 12:20, 20 July 2019 (UTC)
  24. Support - it definitely is insanely low. (Some of) the status quo/lower !voters seem to consider that we'd require project wide knowledge to regain the mop, which is clearly insanely high, but the current level would let a returning admin be out of touch with everything since they'd last handled it. Nosebagbear (talk) 12:38, 20 July 2019 (UTC)
  25. Support for all of the "it's no big deal" champions - then make RfA no big deal if you use it again. I'm not sure what I think the best "activity" threshold is, but as far as resysoping I'd like to see a "1 year rule" - If you stop sysoping and it's been a year, go to RfA - leaves plenty of time for temporary leaves of absence. — xaosflux Talk 12:56, 20 July 2019 (UTC)
  26. Support per Fastily. Admins away for years, especially those that hadn't been using tools, aren't fit to return immediately to adminny work. Most just wield the banhammer as a status symbol and for convenience. Chris Troutman (talk) 13:12, 20 July 2019 (UTC)
  27. Support I think there should be some level of renewed editing activity before resysop. The ideas below for continuing/refresher ed below sound promising as well. Schazjmd (talk) 14:04, 20 July 2019 (UTC)
  28. Id actually be in favor of desysopping a number of legacy admins (the ones promoted either without an RFA or when RFA was literally oh he or she has not vandalized in the 100 edits he or she has made so +sysop plz), and these bright line rules lead to things like an admin making a token edit every year for a decade to retain the bit. If RFA is making it too difficult to promote new, qualified, admins then RFA needs to be fixed. That should not mean resyssoping should be as trivial as it is. nableezy - 16:09, 20 July 2019 (UTC)
  29. Support. Having recently returned from an extended wikibreak myself as a non-admin I found myself tripping up in wiki processes more than a few times (things like leaving out bits of expected formatting in article creation). Obviously, for an admin, the problem areas can be much more numerous and potentially more serious. Since people tend to agree that there's a need to get back up to speed after long periods of inactivity, I think it's fine to expect that some evidence be shown that this has happened before handing back the mop. —Nizolan (talk · c.) 16:27, 20 July 2019 (UTC)
  30. Support This wiki has one of the most lenient policies of all Wikimedia projects on this subject and it appears from above that there is a problem caused by this (i.e. "if it ain't broke, don't fix it" does not apply).Jasper Deng (talk) 17:39, 20 July 2019 (UTC)
    Could you maybe point out which problem that is exactly? I see a lot of people claiming there is a problem but none actually specifying what it is or providing examples. I'm happy to be convinced if there demonstrably exists a problem and not just a feeling of a problem. Regards SoWhy 18:40, 20 July 2019 (UTC)
    dormant antique accounts with advanced permissions that they would likely not be granted today with continued access to restricted content? Govindaharihari (talk) 19:24, 20 July 2019 (UTC)
    How is that different from semi-active antique accounts with advanced permissions that they would likely not be granted today? Regards SoWhy 20:01, 20 July 2019 (UTC)
    I would class an account only completing the edits so as to qualify for the continued advanced permissions as basically dormant, there is little difference in benefit to the project for either user to continue to hold access to restricted content. Govindaharihari (talk) 20:32, 20 July 2019 (UTC)
    They're different problems. This RfC is not intended to address the "semi-active antique accounts" problem. —/Mendaliv//Δ's/ 18:30, 21 July 2019 (UTC)
  31. Support My views are similar to Xaosflux above. -- Dolotta (talk) 18:34, 20 July 2019 (UTC)
  32. Support – our resysop policy is supposed to give the crats a very clear line on which users are likely to retain the trust of the community. I am as excited as anyone else when someone returns to the project, but the level of access that the crats give these returning users often does not match the level of trust that the community has in them. It's difficult to give specific examples without appearing to criticize individual admins, but I am convinced that we need to tighten our resysop criteria. – bradv🍁 19:05, 20 July 2019 (UTC)
  33. Support It's all been said above as far as the direction of travel is concerned. Johnbod (talk) 02:42, 21 July 2019 (UTC)
  34. Per Xaosflux and TonyBallioni above. Vanamonde (Talk) 04:55, 21 July 2019 (UTC)
  35. Support Removing the rights is just security theatre if they are returned without any reconfirmation. Andrew D. (talk) 09:12, 21 July 2019 (UTC)
  36. Support As between the three choices this is the sensible place to be: status quo could only mean there is no reason for further discussion in hopes of reaching consensus, which is not the case; looser, is where we've been before and there is no reason for going back. So, here am I, waiting for the details, where they say the devils lay. (Please when you do go to the next step, remind everyone what admins have access to and what they could and can do with it, and how our systems/processes/people know they are who they say are.) Alanscottwalker (talk) 09:32, 21 July 2019 (UTC)
  37. Support. Administrators should be currently engaged with the community and familiar with current policies. The present criteria do not reliably guarantee this is the case. Thryduulf (talk) 09:59, 21 July 2019 (UTC)
    Achieving that would probably also require desysopping at least half of users on the Wikipedia:List of administrators/Semi-active and Wikipedia:List of administrators/Inactive lists, wouldn't it? Regards SoWhy 17:41, 21 July 2019 (UTC)
  38. Support. I hesitated before deciding to support, because there certainly is a very good case to be made that we need to be getting as many active admins as we can. But I end up feeling that there is something essentially illogical in saying that, on the one hand, present-day community norms for new RfAs (whether too high or not) are what they are, but on the other hand, criteria for re-sysopping "legacy" admins should reflect "legacy" standards. And this RfC does not commit us to anything, just to have further discussion and further examination of options if this gets consensus – and I see a clear net positive to opening the door to further consideration instead of shutting the door. --Tryptofish (talk) 16:20, 21 July 2019 (UTC)
  39. Support per Xaosflux and TonyBallioni above .Note most of those who are Wikipedia:Former administrators/reason/inactive have had there RFA between 2003 to 2009 .That is over 10 years ago Pharaoh of the Wizards (talk) 20:06, 21 July 2019 (UTC)
    Over 80% of successful RFAs were in that era, so it should not surprise us that most of the inactives are from then. The bigger problem is that over 95% of successful RFAs were more than five years ago - hence our unhealthy reliance on keeping as many as possible of our long established admins. ϢereSpielChequers 15:56, 27 August 2019 (UTC)
  40. Support 100% - The status quo that was meant to abolish lifetime appointments is still easily gamed. For an example, see Pakaran, an admin and bureaucrat with <10k edits, who was appointed by 13 people with no discussion, has not made a single edit since February 2018, has no 'crat "activity" since December 2016 (that was a single comment at BN), has no logged 'crat actions since February 2015, and has not been active since 2006 (save for a few months in 2010). Another one, Yelyos, a user with 1700 edits, no edits since September 2016, no admin actions since February 2015 (a single deletion), has also not been active since 2005 (2006 if we're being generous). Not meaning to attack these users personally, but it's hard not to see the problem. We need to be able to prevent these situations. ~Swarm~ {sting} 20:33, 21 July 2019 (UTC)
    Swarm, it is easy to see potential problems, but it is hard to see serious actual problems (who exactly is doing something bad with their admin tools?). It isn't a "problem" if Yelyos is an admin, it is just amazingly unfair that RFA was so much more gentle 15 years ago. Probably nothing other than asking all of us old (ex-)sysops to go through RFA again is going to create inter-wikigenerational fairness. —Kusma (t·c) 21:08, 21 July 2019 (UTC)
    If you don't think it is a problem that users who objectively don't meet current standards for these positions are able to retain them by virtue of gaming the low activity requirements, as opposed to actually remaining active, then we'll have to agree to disagree, Kusma. I really don't even feel like it's worth my time arguing whether a user with 1k edits and 15 years of inactivity should be an admin. ~Swarm~ {sting} 00:54, 22 July 2019 (UTC)
    Swarm, as long as no real activity is needed to stay an admin, I just don't see what a change to the resysop rules accomplishes (other than annoying people who have a real life for a while). People who became sysops in the old days were trusted to have clue and not break the wiki. People who became sysops a bit later had jumped through a few hoops and were trusted to have clue and not break the wiki. Only a couple handful of people were made sysops in the last couple of years. People in all three groups have been desysopped for showing a lack of clue and/or breaking the wiki. I just don't see the evidence that our new standards have accomplished much so I don't see not meeting the standards as an obvious problem. But if it is such a problem, we should go away from "adminship is for life if you never become inactive" instead of worrying about what the precise amount of inactivity is that we wish to allow. —Kusma (t·c) 06:07, 22 July 2019 (UTC)
    Can you point me to a discussion where the consensus was that the intent of the status quo is to abolish lifetime appointments? As far as I recall, we are at where we are now for reasons of security, and security alone. --kingboyk (talk) 00:12, 22 July 2019 (UTC)
    I'm not sure what you're even getting at. "Lifetime appointment" is not and never has been a formalized concept. It was simply the reality of how things used to be. At some point the community abolished this reality when it implemented the "5-year rule" which required a re-RfA due to inactivity. This replaced the "lifetime appointment" status quo with an activity requirement. In other words, the community mandate from an RfA is no longer indefinite, but is presumed to expire after 5 years of inactivity. I'm not interpreting anything in terms of "intent". This is literally the current rule. If you're curious what the intent was, you can dig up that discussion yourself, I have no idea where it is. ~Swarm~ {sting} 00:54, 22 July 2019 (UTC)
    The RfC establishing 5 year rule is here. The current activity policy is based on the fact that adminship was basically something thrown together when this was a hobby website of Friends of Jimmy® who never thought it would be where it was today, and who knew if it would reach 10 years much less 20. The de facto appointment for life thing is something we inherited because we never bothered to set a policy around it until it was pretty late in the game. Most other projects have significantly stricter resysop policies. While I do not want to go as strict as some of the others, I do think that our current policy on restoration of rights may as well not exist because it is so lenient, and to be honest, if I weren't in "Option 2" I'd be in "Option 3" because the status quo is a joke. TonyBallioni (talk) 01:14, 22 July 2019 (UTC)
  41. I echo Xaosflux and TonyBallioni here. This needs to be done. Nihlus 21:32, 21 July 2019 (UTC)
  42. Somewhat preliminary, as I may or may not support any specific measure. But asking some questions to admins seeking return on WP:BN seems like a reasonable move. Jo-Jo Eumerus (talk, contributions) 08:37, 22 July 2019 (UTC)
  43. Xaosflux's "no big deal" point is excellent. ~ ToBeFree (talk) 01:52, 23 July 2019 (UTC)
  44. I've seen some WP:BN resysops where the ex-admin could not even acknowledge that they needed to do some work to update themselves before using the tools, so I support a mild strengthening of requirements. Johnuniq (talk) 02:08, 23 July 2019 (UTC)
  45. Per xaosflux mostly. I wasn't too thrilled with option 1 to start with, but my main reason was that even if the returning admins don't do much, what little they do would be better than nothing. The gain from that would probably not be significant, so whether that's delayed 7 days for an RfA wouldn't make much of a difference. And at least this way we know the community supports them. So I don't see much reason to oppose tightening them. Wug·a·po·des​ 05:43, 23 July 2019 (UTC)
  46. Wikipedia standards have evolved, so that long-absent admins should both demonstrate a current need for the tools and an awareness of what is expected of them today. Going through a full-blown RfA again may not be the appropriate process, because there would in most cases not be enough recent editing history to pass judgment, so that would be mostly a popularity contest. In the spirit of "tools are not a big deal", I would rather advocate for a probation period of 6 months, within which the returning admin should be able to demonstrate their competence. What to do after 6 months should be up to a hopefully lightweight community discussion, format to be discussed in followup to this RfC. — JFG talk 11:58, 23 July 2019 (UTC)
  47. SUPPORT - All you have to do is observe the absolute reaming that even pretty good editors receive at WP:RFA (it's a dragon's den - I wouldn't pass - but that's another topic) whilst trying to become admins to realise just how unfair it is that people can waltz back into adminship with relative ease. No, you go back through WP:RFA along with everyone else, and have to show there that you can do the job. FOARP (talk) 15:20, 23 July 2019 (UTC)
    EDIT: I would also like to see a time-out period (3-6 months) before re-sysoping where the de-sysoping was for cause or for non-activity. The editor in question should have to show they are a good citizen, and are up to speed on current policy, before reapplying. FOARP (talk) 08:51, 29 July 2019 (UTC)
  48. Support, mostly per Iridescent. Note that we've had a couple of particularly egregious examples of dubious resysop'ing lately that really do seem to be in the "it's a trophy" category - if they want a trophy, edit some articles or whatever and perhaps someone will present a barnstar. - Sitush (talk) 13:14, 26 July 2019 (UTC)
  49. Support: tightening the activity requirements makes sense at this point. --K.e.coffman (talk) 00:02, 27 July 2019 (UTC)
  50. Support Our resysop criteria are really a joke. Returning admins should have to demonstrate at least some engagement with the community. Pawnkingthree (talk) 12:09, 27 July 2019 (UTC)
  51. Support Honestly, I can't think of any reason why all resysops shouldn't just go to RFA. It would put an end to puerile protest resignations and to the question of trophy holding, whilst also ensuring that the WP:RFA maintains a level of realism about adminship candidates. Xaosflux and Iridescent have good ideas that are worth serious discussion at a later stage. Promethean (talk) 09:30, 1 August 2019 (UTC)
    @Promethean, I personally wouldn't support all resysops going through RFA. There are some short-term desysop/resysop cycles that genuinely do fall under routine maintenance ("I'm spending the next three months at sea and know I won't have internet access, please temporarily remove the admin bit in case my account is hacked while I'm away and unable to do anything about it", "I am working in North Korea for the next month and am uncomfortable potentially giving the authorities there access to my checkuser permissions", "I'm on medication which has documented psychoactive side-effects, please temporarily remove the admin bit until the course of treatment is complete so I don't end up blocking or deleting something during a paranoid episode"…). Making all resysops have to go through a full week-long RFA every time would likely have a counter-productive effect by discouraging people from temporarily giving up advanced permissions in circumstance when they really should. ‑ Iridescent 08:44, 2 August 2019 (UTC)
    Right, this is reasonable. Not all resysops should go through RfA, but I think most if not all that are properly characterized as resignations and retirements should. But as you say, there are legitimate reasons to ask for the advanced permissions to be temporarily removed. —/Mendaliv//Δ's/ 08:52, 2 August 2019 (UTC)
  52. Support {{u|waddie96}} {talk} 06:51, 4 August 2019 (UTC)
  53. Support I'm awfully late to this discussion, and I don't know if we're going to have that second RfC. But in case we do, I'd like to note that, according to my rough count, approximately 80% of the editors favoring Option 1 are admins. While admins certainly have as much right to weigh-in as non-admins, it seems that admins are a little more likely to weigh in if the discussion is held on this page. If broader input was sought from the entire community, perhaps via a watchlist notice, it would be very informative to see how many non-admins would support Option 1. As for myself, I support tightening the requirements. Lepricavark (talk) 14:53, 13 August 2019 (UTC)
  54. Support I would recommend having a requirement for a certain number of edits, say 25 or 50, during the 30 days prior to their resysop request. This would indicate that they are coming back to the project in earnest. -- Dolotta (talk) 21:32, 13 August 2019 (UTC)
  55. Support People will always game the system, whatever it is, but a stricter system would have better results. Enigmamsg 23:27, 24 August 2019 (UTC)
  56. Support Long overdue. There is an observable trend of a small minority of admins who clearly are gaming the current requirements despite clearly having no real engagement with the project. That's exactly the mentality we don't need in an administrator and I support anything aimed at curbing it. Beeblebrox (talk) 19:56, 26 August 2019 (UTC)
  57. Support. Long overdue, in fact, and that is probably because no one likes specific proposals, just as the OP (TonyBallioni) says above. This way of setting up the RfC will hopefully overcome that problem, and I want to compliment Tony for coming up with it. Bishonen | talk 20:09, 26 August 2019 (UTC).
  58. I basically agree with Risker (who favors Option 1) and am likewise largely unconvinced that the resysop requirements... are at issue; it is indeed mostly the retention requirements that are problematic. Still, I don't think it'd be bad to tighten them up a bit (especially as concerns longer-term absences) so I'm here weakly. ~ Amory (utc) 11:51, 2 September 2019 (UTC)
  59. Support. Since this is still open, I might as well add my support for stricter resysop requirements, for multiple reasons stated multiple times above. (I also support stricter desysop rules as well, but one thing at a time.) --RL0919 (talk) 23:04, 6 September 2019 (UTC)

Option 3[edit]

  1. Getting the mop is supposed to be no big deal, with the same level of power and prestige as being a janitor or garbage collector. It should be available to anyone that wouldn't misuse it. Of course, if returning admins were forced to work on all admin-related roles without being allowed to re-read recent policy first, something could then go wrong. But (unless there's some recent policy I'm missing) noone is (yet?) forced to work in any specific areas they don't know about. I don't really think there should be any limit to how long someone can be inactive and still get the mop back.
    However, as I see it, the main problem is that RFAs have ballooned from a sanity check that the user warrants basic trust to a marathon of checking that the user fulfills 101 mutually exclusive subjective criteria, has refrained from contributing to any controvertial topics and can recite all areas of Wikipedia policy in Latin by heart. Even if all old mop-holders got the mop back, there still wouldn't be enough mop-holders, with almost no way of squeezing new ones through RFAs, let alone getting them to even apply.
    A random idea (which unfortunately probably won't get implemented) would be to add a "This person should be an admin" button next to the "Thank" button — and if some threshold of people press it, the person is notified that they should perhaps apply (with a note that if they're not interested in power or prestige, they should definitely apply). Or actually, the "Thank" button itself could do that — no need for an extra button. Κσυπ Cyp   10:05, 20 July 2019 (UTC)
    Says the admin whose last 50 non-minor mainspace edits go back to 2008, and hasn't made a talkpage comment of any kind since 2017… ‑ Iridescent 13:21, 20 July 2019 (UTC)
    Except for the Wikipedia talk and User talk kinds of talkpage. Κσυπ Cyp   14:08, 20 July 2019 (UTC)
    Support Option 1 now (unless Option 3 comes back), since Option 3 turned into a comment section. Option 3 came back. Κσυπ Cyp   11:49, 20 July 2019 (UTC)
    @Cyp: I do think yours was an interesting case. I recently read about it, and if I recall correctly, there was a great deal of pushback. Are you of the opinion that if the activity policy were stricter that you would not be an admin right now? –MJLTalk 00:17, 21 July 2019 (UTC)
    @MJL: Yes, if it were stricter by any non-trivial amount, then I probably wouldn't be. I was astonished at the amount of discussion, given that it was supposed to be possible to come back after any amount of time. I'm not sure what happened. Maybe some people felt RFA was a bit of a deal, and gave some people had slightly hard RFAs, leading them to find it a bit bigger deal, making the next RFAs even scarier, eventually leading from NOBIGDEAL to REALLYHUGEDEAL, and then mainly just people who like really huge deals applying, which might not be the only set of people suitable for adminship. Κσυπ Cyp   05:13, 21 July 2019 (UTC)
    @Cyp: [Thank you for the ping] Well, you are an admin, so why not go nominate some experienced users for RFA? If RFAs weren't so rare, then you'd see that attitudes on adminship change imo. ¯\_(ツ)_/¯MJLTalk 05:53, 21 July 2019 (UTC)
    Ladies and gentlemen, an example of the problem. ~Swarm~ {sting} 04:20, 22 July 2019 (UTC)
    Indeed, good example. For those in the Option 1 group who have troubles seeing the problem, would you please summarize a few of the problems that this particular example has caused? Κσυπ Cyp   08:03, 22 July 2019 (UTC)
    @Swarm: Ah, but what sort of adverse effects have come about as a result of resysopping him? I've not seen any controversial actions on Cyp's part since he came back. Kurtis (talk) 07:51, 23 July 2019 (UTC)
    The fact that a very small number of users continue to be "relic administrators" with no community mandate and no notable involvement with the project, by virtue of meeting extremely low activity requirements, as opposed to actually contributing to the project, even though we've had fairly consistent and high standards for adminship for about 15 years, is the problem. How many untold thousands of hours have people contributed to this project, only for it to not be good enough at RfA? We have standards, users like Cyp do not meet those standards. Like I said above, it's not a personal attack, it's a statement of fact. It's a problem in itself, Cyp, without making any commentary about your integrity, and you should be able to understand that. But the fact that you're condescendingly asking for examples of a problem, which I can find in 2 seconds of looking at your logs, just shows how hilariously out of touch you actually are. Your block log is fucking atrocious. Apparently you never got the memo that we notify users we block? Hard blocking users with no edits? Revoking email and tpa without cause? Issuing blocks without log entries? Blocking users who have not been sufficiently warned? It's literally deja vu from the recent Enigmaman desysop, but at least he was an active admin who seems to have just stopped caring over the years. You're an actual admin with no RfA, requested the mop because you were "curious", have no notable activity since 2004, have less than 4k edits, you clearly are painfully out of touch with our norms and standards, and on top of that you're so arrogant that you don't even know you're out of touch, and deign to dare others to find faults with your adminship, even though such faults are consistent and obvious. You'd think an admin who never actually had to be vetted by the community would be a little more humble, but I guess your attitude is just another thing we can chalk up as a problem that would have been screened out by any modern RfA. I'll put to you a simple proposal: if you're really so confident that you're a good admin who deserves the mop, just run an RfA. If you don't want the community to actually vet you, as 100% of us have been vetted for the past 15 years, then you shouldn't be an admin. ~Swarm~ {sting} 04:56, 26 July 2019 (UTC)
    Yes, looking at my block logs, I do see some examples of that, for example, I blocked Wikipedians have a below average penjs size and If you community ban me i will cruise more without TPA despite them not having edited, without any warning or notifying them, and without even giving a reason in the block log. Unfortunately, it was some time ago, and I since I didn't write a reason in the block log, I don't remember anymore why I blocked them. And I'm afraid there are many other comparable examples. This doesn't apply to all my blocks, at least. I have though given warnings and/or block notices for some users, especially for the users who could plausibly both be human and not already have accumulated 400+ warnings and 100+ block notices. I don't think I've yet gotten any complaints about specific actions, except for one about having deleted a page as non-notable instead of as vandalism (or something like that), and some complaints about having forgotten to revoke TPA when blocking an LTA. I certainly may be out of touch, and tend to stay away from what I feel most out of touch with. As for RFAs, I certainly see a difference between how RFAs were back then, compared to now. Rather than me running a reRFA by recent standards, I think a better solution would be adjusting new RFAs so they match the older standards better. I get the impression that the RFA process now screens out most non-extroverts before they even get to the stage of applying, and that might not neccessarily be ideal. Κσυπ Cyp   11:56, 26 July 2019 (UTC)
    With regards to those two editors: though I cannot discern what you were thinking at the time with any more certainty than you can, I would hazard a guess that it had something to do with their usernames... Kurtis (talk) 12:14, 26 July 2019 (UTC)
    Your bad blocking practices are a consistent and unwavering pattern, not "two users a long time ago". The fact that you can breach norms and standard practices and engage in abusive practices just because no one screening your logs, and then blame your incompetence on the fact that no one was supervising you, is a sign that you should not be an admin. No one should have to supervise an admin on the assumption that they don't know what they're doing. We simply shouldn't have to be worried about this. That's why we have RfA, and that's why admins without RfAs should subject themselves to the community for vetting. Regarding your position on RfA, there's another problem: what you describe as "older standards" really means "no standards", and "recent standards" is actually just "standards", standards that have been fairly stable for nearly 15 years. If you think it's realistic to call for the community to drop their longstanding standards for adminship, and run a NOBIGDEAL RfA on your own merits, then go for it. Put that theory to the test. I will argue that your logs are evidence that there's a reason we should have standards, but it is the community that can weigh our opposing arguments. The community governs this project, not your opinion that you deserve to be an admin because there should be no standards for adminship. It's a pretty bad argument, IMO, especially coupled with actual incompetence. ~Swarm~ {sting} 03:58, 28 July 2019 (UTC)
    (edit conflict) @Swarm: I stand corrected. To tell you the honest truth, I based my comment more on the fact that I haven't seen any drama arising from his resumed adminship. Despite my sporadic activity, I do keep myself updated on Wikipedia's latest developments, though it's possible I missed something. If what you say is true – chiefly, his heavy-handed approach to blocking – then there is a serious question as to whether Cyp is currently fit to remain an administrator. I've seen problems with what you describe as "relic administrators" before, and I think that they should have their tools revoked if they're repeatedly misusing them. On the other hand, there are plenty of other relic administrators who continue to display the competence necessary to at least get themselves up to speed before taking action. I believe it is best handled on a case-by-case basis; administrators who are demonstrably out of touch should lose their sysop tools, whereas administrators who have not caused any issues thus far should be allowed to keep them. As far as potential future problems are concerned, we can cross those bridges when we get to them. Kurtis (talk) 12:06, 26 July 2019 (UTC)
    May I please add that it is very important that administrators who are not using the tools correctly get proper feedback about it in a timely fashion, otherwise they end up in a situation which we recently have seen with Enigmaman.--Ymblanter (talk) 14:29, 26 July 2019 (UTC)
    Agreed. I was under the impression that after my re-mopping, that there were going to be 100 people carefully going through each action I do, and immediately lynching and/or giving proper feedback the second I did anything at all questionable. And that no feedback was therefore positive feedback. Κσυπ Cyp   17:30, 26 July 2019 (UTC)
    I agree wholeheartedly. It was not my intention to imply that misuse should result in a quick desysop. A demonstrated inability to learn is more what I had in mind. Kurtis (talk) 22:18, 26 July 2019 (UTC)
    Uh, I don't know what the hell you're talking about, but Enigma was not desysopped because he made good faith mistakes that no one corrected him on, he was literally desysopped after abusively blocking an inactive account that had insulted him a decade prior. He knew it was abusive, he just did not think that he would be caught, and he only was caught because that user was still around under a different account. I subsequently investigated his edits and found that there was an extensive pattern of willfully abusive conduct. It's a bit bizarre that you're blaming "lack of feedback" as being responsible for straightforward admin abuse. ~Swarm~ {sting} 04:08, 28 July 2019 (UTC)
    Without speculating on whether he did or did not think he would be caught, if this block were an isolated accident it would probably not result in a desysop. The thing was that when this block was uncovered at ANI, users started to look at his administrative actions and found a number of actions which were really not ok but nobody discovered them before. Assuming good faith (and the ArbCom proceedings did not show any evidence which would push me in this case to stop assuming good faith), it was just a behavioral creep - he started with something which was marginally ok, and then did something which was not almost ok but not exactly ok, and assumed it is ok, and then did something which we would think clearly not ok, and so on. If anybody would talk to him in the middle of the process and tell him that what he was doing was not ok he would likely stop doing it. We all know that there are many greyish areas in the admin activity (what is involved? what is pure vandalism listed as an exception for 3RR? etc) which can lead to the behavioral creep pushing an admin into a zone where the actions are clearly not ok. Feedback in the middle of this creep would certainly help.--Ymblanter (talk) 11:27, 28 July 2019 (UTC)
    I disagree with your first point. It was a willfully abusive block, out of spite. There was no "oops, here's my excuse", nor was there an "I fucked up, I'm sorry, it won't happen again". I can think of no more egregious act of abuse that would result in a desysopping if I tried. I actually think it's a bit bizarre that you'd even suggest that we wouldn't desysop admins for malicious revenge blocks just because it was a first offense. Your argument strikes me as akin to someone being convicted of murder, and saying "if only someone had warned him against being a jerk". ~Swarm~ {sting} 02:10, 4 August 2019 (UTC)
    I unblocked the account myself and apologized. There's nothing else I can do. I would also note that while it was a bad block, no one was harmed because of it. Enigmamsg 23:25, 24 August 2019 (UTC)
  2. Inactivity isn't usually a bid deal unless there's concerns about the user's conduct which is far more likely to be an issue with an active admin than an inactive one. Crouch, Swale (talk) 21:23, 3 August 2019 (UTC)


A few points:

  • Performing lots of sysop actions does not necessarily make one competent to be a sysop. If a person is perceptive, logical and cautious they will do a good job now or five years from now. Good judgement means they will look around and familiarize themselves with community norms when they need to.
  • Presumably people were made sysops because they have enough clue to read the manual when they need to.
  • It's often not evident if somebody has been lurking or IP editing or working on a sister project. There are also sysop actions that aren't logged, such as reviewing deleted diffs. Edit counts and log counts aren't everything.

Before I'd support any tightening of the criteria, I'd like to see evidence that the lenient criteria currently in effect was causing a problem. To my mind we need to avoid solving non-existent problems. Jehochman Talk 03:40, 20 July 2019 (UTC)

Jehochman, you used the example of El C, who is one of my favourite colleagues. He has not been desysoped for inactivity in 6 years, and there is nothing here that would suggest he should have been desysoped sooner. In fact, this RfC has nothing to do with the deysop criteria. This is only about whether or not our current 3/5 resysop criteria (3 years inactive/5 years logged actions when desysoped) should be made stricter. Nothing more. There are not even specific proposals here, just the question of if what the community thinks of the current resysop policy. TonyBallioni (talk) 03:48, 20 July 2019 (UTC)
Continuing with that example, he logged in once in a while and avoid being desysoped. Had he not done that, I'd still want to be sure we would have welcomed him back without a new RfA. Jehochman Talk 03:52, 20 July 2019 (UTC)
I understand it's not nice to talk about people. Can you indicate, perhaps anonymously, whether we are resysoping people who proceed to cause disruptions? Lately it seems like that role has been taken on by WMF. Jehochman Talk 03:54, 20 July 2019 (UTC)
  • As I said above, there really need to be continuing education requirements for adminship in general, and I think this is the perfect vehicle to start requiring it as a condition of reentry. For those unfamiliar, continuing education is a requirement in many if not most licensed professions. This not only includes doctors and lawyers, but also barbers and interior designers. The way this is structured varies a lot between professions. For lawyers, you usually have to take courses or lectures, but you can also get credits for teaching courses or writing articles. For doctors, a portion is satisfied just by doing research of some kind on patients' cases, but you also need to submit to some form of accredited continuing education (which may include providing such education). And, commonly, when someone has been inactive or is disciplined, the licensing authority may require some form of continuing education as a condition for reentry. I have long thought that administrators on Wikipedia should be brought up to speed periodically on what it means to be an admin, on changing professionalism requirements, etc. For instance, the case that was discussed on WP:BN that led to this RfC was for an admin who passed RfA before we even had rules against paid editing.
    I admit that there needs to be continuing education content for this sort of thing to work, and at present there is none. That said, I think there's a way to achieve this. Like I said, if this can be implemented fully for all admins, we'll have our active admins creating content for new and returning admins. Similarly, we can work with the WMF and chapters to develop training materials. Imagine the following lectures: "Identifying and Responding to Incivility", "Calculating Rangeblocks for IPv6 Addresses", "The RfA Process in the 2010s", "Speedy Deletion in the 2010s", "Arbitration Enforcement: Practice and Procedure", "Determining Consensus and Closing Discussions at Noticeboards", "Revision Deletion", "Copyrighted Text Detection and Deletion", "Fair Use on Wikipedia", "Writing Proper Block Log Entries", "Including Permalinks in Edit Summaries and Log Entries". These are all things admins should know about and should keep current on even if their areas of interest aren't all-encompassing.
    Anyway, my point is that this is something we should be moving towards in the next couple of years, and the problem of low-activity admins is as good an opportunity as any to start addressing it. —/Mendaliv//Δ's/ 05:17, 20 July 2019 (UTC)
    I like the idea, and would like to see such training being available for all Wikipedians. There could be a suggestion of which would be most useful for particular applications, and requiring a disruptive editor to participate and pass a relevant course could help with some of the recurring dramaboard participants. If you go further developing this idea, please ping me as I would like to contribute where I can. I have a little experience with Moodle, which could be a suitable platform. · · · Peter Southwood (talk): 07:28, 20 July 2019 (UTC)
    Yep, that's a very good point, that continuing education could be used as an alternative to bans, and could also provide a way for sanctioned editors to demonstrate that they're ready to move on from their sanctions. I can think of a case that controversially closed on AN just the other day that would probably have been avoided if there were materials available on things like "avoiding close paraphrasing" and similar. —/Mendaliv//Δ's/ 07:59, 20 July 2019 (UTC)
    Sufficient potential for solving long standing problems that it is worth going further. One way to start is to list the skills that should or could be trained, then for each one list the questions that should be answered correctly to indicate understanding of the policy. Then write a set of multiple choice questions with a good set of correct answers and incorrect answers, complete with instructive feedback where possible for incorrect responses. Seting up the assessments on Moodle is the easy part. · · · Peter Southwood (talk): 10:47, 20 July 2019 (UTC)
    It could also help with RfAs as a person who had done all the training could reasonably be assumed to know most of the important stuff. · · · Peter Southwood (talk): 14:45, 20 July 2019 (UTC)
    Continuing education is really hard work. I know of at least one effort to track the evolution of guideline and policy that ended because the user doing the work came to the (correct?) conclusion that it wasn't worth it (that was Tony1 and the MOS). Now, it's possible that the guidelines in question were under much more-rapid evolution at the time than those we have today, and maybe e.g. the admin newsletter will help give us a monthly overview of deltas, but even then someone needs to put the training together, etc. And they will need to do it over both a longer timeframe (years) while simultaneously needing to support different lengths of inactivity (2012 to 2016, or 2007 to 2017, etc.). None of this leads to much in the way of productivity (which might generously include keeping admins up on the Joneses). I'm not trying to say this is impossible (I'd love to do a year over year diff against each of our PAGs, as a research project I know I don't have time for), but the person (or people) who contribute into this will have quite a bit of work cut out for them, and we all know this is a volunteer project with enough backlogs as it stands.... --Izno (talk) 06:07, 26 July 2019 (UTC)
  • Iridescent, I don't want this to get too into specific proposals since I think that's part of the reason we haven't been able to solve this yet, but yes, even something as simple as before restoring the administrator flag a bureaucrat should be reasonably convinced that the user intends to return to activity would be an improvement, and a line like that would not preclude someone from coming back, getting turned down, editing for 3 months and showing they aren't an idiot, and requesting at BN again without an RfA. Something like that likely wouldn't be as strict as some want, but it would certainly be an improvement from what we have now. TonyBallioni (talk) 06:32, 20 July 2019 (UTC)
@TonyBallioni: "One of [your] favorite colleagues" has just all but ceased communication with anonymous contributors...indefinitely. ——SerialNumber54129 07:18, 20 July 2019 (UTC)
Indefinite doesn't mean infinite. It just means I'm not telling the abuser the exact length of the protection. El_C 07:31, 20 July 2019 (UTC)
In a world where "persistent sockpuppetry" means one edit, yeah. ——SerialNumber54129 08:24, 20 July 2019 (UTC)
"B.S." is not a particularly civil edit summary, nor does it assume good faith. Any reason for that? Anyway, that sock had iterations in the double digits today: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14. El_C 08:33, 20 July 2019 (UTC)
Apologies, El C, I should've found a more polite expression to convey the meaning! ——SerialNumber54129 08:48, 20 July 2019 (UTC)
  • Serial Number 54129, would that not require an RFC0 to establish? The criteria to decide who gets to vote in these RFCs, I mean. Usedtobecool ✉️  09:04, 20 July 2019 (UTC)
  • While I don't think there's much point expelling old admins, I think the main problem is getting new ones. One random idea is to piggy-back on the Thank button — if someone is getting a decent quota of Thanks from enough different users, then they could perhaps be encouraged to apply, especially if they're the type of person that wouldn't normally feel qualified for adminship. (Summary of comment in option-3 vote.) Κσυπ Cyp   12:27, 20 July 2019 (UTC)
That's an excellent idea Cyp, although it will probably lead someone to demand a concomitant "Do not adminate" button! :) glad you got your posts all sorted out now, sorry for any confusion. ——SerialNumber54129 12:30, 20 July 2019 (UTC)
That's fine, I get confused easily, anyway. Κσυπ Cyp   18:13, 20 July 2019 (UTC)
  • Sorry if this is a bit confusing — my viewpoint on a lot of the discussions on this page related to these 3 items, which are problems if true:
A) In the early days, getting the admin bit was too hard. (currently false)
B) The difficulty of getting the admin bit in the early days is not the same as getting the admin bit now. Or A ≠ C. (currently true)
C) Getting the admin bit is too hard now. (currently true)
Current situation is ¬A ∧ B ∧ C, and the goal should be ¬A ∧ ¬B ∧ ¬C. Commonly proposed solution: Fix B by retroactively making it harder to get the admin bit in the early days (with the side effect of retroactively making A true), and worry about fixing C later, resulting in A ∧ ¬B ∧ C. What I'd prefer: Fix C (with the side effect of fixing B, and letting A remain in the fixed state), resulting in ¬A ∧ ¬B ∧ ¬C. Κσυπ Cyp   18:13, 20 July 2019 (UTC)
Have you any actual evidence for Getting the admin bit is too hard now, or are you just making shit up to try to support your case? The two RFAs this month got 231 supports and 167 supports, a level of support which back in the old days was so unusual we had a special page to list the occasions when it occurred. The "RFA is impossible to pass nowadays" thing is something a lot of people like to say, but they tend to fall silent when anyone suggests they might want to provide some evidence. ‑ Iridescent 20:41, 20 July 2019 (UTC)
It's my impression that almost noone applies. At least, 2 in a month sounds low to me, for a site that's now this size. I'd guess there are lots of qualified people who wouldn't dare apply (and may or may not pass if they applied anyway), but I don't really have any specific evidence for it myself, sorry. Κσυπ Cyp   22:01, 20 July 2019 (UTC)
Looking at this, it seems as if the mean number of successful RfAs per month has been fairly flat since 2012. Certainly the current situation is nothing like the heady days of 2003 to 2009, but one does have to realize that since adminship is a more-or-less permanent appointment, all of those hundreds of newly-minted admins from that period -- less those who have retired or been desysopped for various reasons -- remain on duty. It would be unreasonable to expect that level of successful RfAs to have continued forever: more editors means more people interested in who is and isn't an admin, means fewer admins getting the bit with minimal input from the community-at-large. Some further statistical investigation would be nice, such as how many participants there were in each RfA (successful and unsuccessful) over the years, compared to how many active Wikipedia editors there were at the time; how the margin of success and failure has changed, etc. In short, I don't think that the evidence is there yet to make such broad generalizations, beyond saying that (obviously) fewer admins are minted these days than 10-15 years ago. Beyond My Ken (talk) 23:51, 20 July 2019 (UTC)
  • To be quite frank, I doubt any of this is going to have much impact on the project. Short of a complete overhaul of the whole add subtract abilities I don't think adding a month or year to various wording is going change much. Those that want to disrupt will find a way. Those that accidentally disrupt will quickly be brought into some acceptable situation. (we do have provisions for emergency desysop.) I suspect that you're going to find more change coming from whatever the WMF/T&S have in mind moving toward 2030, how Arbcom are going to liaison, and how much the community will change due to different circumstances in the future. I just can't imagine that anything here is going to have any substantial affect to what we have presently. — Ched :  ?  — 02:46, 21 July 2019 (UTC)
    To be quite frank, I doubt any of this is going to have much impact on the project. I agree. It will probably be an uncommon situation, but in my view that's actually a factor in favor of implementing some change as a prelude to an overall revision to the adminship process. As I've discussed above, the idea of continuing education as a general requirement (that is, not merely as a special requirement for returning admins) has a lot of merit. If such a system is implemented, it should lead to a softening of the unreasonable standards at RfA. I suspect that you're going to find more change coming from whatever the WMF/T&S have in mind moving toward 2030, how Arbcom are going to liaison, and how much the community will change due to different circumstances in the future. Again, when seeking to make changes and improvements, especially to core community processes, we should seek to make incremental changes, rather than revolutionary changes. There is not only nothing inherently wrong with baby steps, but I would argue that such steps should be preferred to sweeping changes. —/Mendaliv//Δ's/ 12:02, 21 July 2019 (UTC)
    With baby steps there is less chance to break things, and you can change direction in mid stride if it becomes necessary. · · · Peter Southwood (talk): 15:45, 23 July 2019 (UTC)
Probably a bad idea, never mind.
The following discussion has been closed. Please do not modify it.

Another random wild idea for trying to get more new admins through RFA — give anyone who could ever plausibly become admin someday the apprentice bit, which should let them perform admin actions which are carried out as soon as being reviewed by an admin (or not carried out, if disapproved). If someone does too many useful admin actions with no recent serious mistakes and the admins get tired of reviewing everything, change their apprentice bit to an admin bit or send them to a RFA where people can already see the track record of a candidate admin as an admin. This of course has the downside that it needs to be coded, although even an incomplete implementation (allowing some admin activities but not others) might be better than nothing. Κσυπ Cyp   18:13, 20 July 2019 (UTC)

  • Wikipedia:Perennial proposals#Hierarchical structures. Regards SoWhy 20:22, 20 July 2019 (UTC)
    Also, Legal requires anyone getting access to the admin tools in any way to have gone through some kind of RFA-like process (cf. WP:PEREN#Automatically grant adminship to users with a certain number of edits or time editing) and if we had to choose "apprentices" through such a process, we can just make them full admins as well and save us the bother. Regards SoWhy 20:25, 20 July 2019 (UTC)
    What I mean is slightly different, I think. The "apprentices" should have a safe toy version of the complete admin tools (except Legal stuff like viewing deleted revisions, I guess), except any use of them would require case-by-case approval. I think this is different than a hierarchical structure, since it's the whole set of admin tools (once the implementation is complete). Since they wouldn't actually be able to do anything at all with the admin tools without each action being approved by an actual admin, I'd expect that to pass by Legal. And an apprentice having a track record of proposing sensible admin actions via their toy admin interface might then pass though a RFA easier without having to explain hypothetical examples of how they might be as an admin, since everyone can see non-hypothetical examples in their log. Basically, almost anyone should be given the "apprentice" bit, which would let them use-by-proxy the admin tools without having the admin tools, and (hopefully) make it easier to get the real admin tools later. Κσυπ Cyp   21:06, 20 July 2019 (UTC)
    I mean, that kinda just sounds like building a "Thank"-like tool that you use instead of tagging pages for CSD/AfD, or reporting users to AIV, or doing NACs of discussions. I think it just kind of kicks the problem down the road. —/Mendaliv//Δ's/ 21:11, 20 July 2019 (UTC)
    Cyp, there isn't any point in pretend-blocking a vandal or pretend-deleting an attack page. Most other admin actions are slightly less time-critical, but can't stand on their own: the admin action is usually accompanied by some edits. You can't wait for approval of the admin action without time-delaying the accompanying edits as well, which isn't going to work for blocks and posting on ANI. If you want, we already have "deletion apprentices" in the form of WP:NAC of debates, some of them even leading to speedy deletions based on their NACs. —Kusma (t·c) 21:15, 20 July 2019 (UTC)
    Pretend-blocking a vandal might get them real-blocked sooner, if admins are looking at a list of actions to approve. But I can't think of a solution to actions that don't stand on their own, so I guess my idea wouldn't really work well for many (most?) things. Oh well, never mind. Κσυπ Cyp   22:01, 20 July 2019 (UTC)
  • Just throwing out a few thoughts.
    I might be what some call a "legacy admin" -- I got the bit back in September 2003 thru one of the first RfA votes, & all it took was 3 yes votes to do it. And I've rarely pushed the mop, so many might think I'm not qualified to be one now. Yet I've followed most of the conflicts & developments on en.wikipedia over the years, so if I had the chance to be more involved I could easy ramp up & assume more of the burden. (Work, commuting, & the demands of a family are the reasons I haven't been very active over the last 6-8 months. And the more recent Foundation misdeeds are not making me eager to try to squeeze out time for Wikipedia as I have done in the past.) On the other hand, an admin who lost the bit due to inactivity, & who moreover was not that active to begin with, is someone who never had an idea what the job & duties truly are. Are we that desperate for janitors to accept people who either aren't going to do the work, or not do the work properly? -- llywrch (talk) 07:17, 21 July 2019 (UTC)
  • If we want to change sysop activity criteria, they should apply to "active" and inactive admins alike. A sysop who doesn't do anything except sending a "happy birthday" post to another user once per year for five years is no more likely to be engaged with the community than a user who has been away for three years, possibly even less. If we want to make sure make sure someone is engaged with the community and keeping up with what is going on we should expect "regular editing" for at least a couple of weeks per year, but I don't have a good way to measure that. Anyway, if we want to do something about the regular angst when a long-term inactive admin returns, finds the message on their talk page that says they can go to WP:BN and request resysop, then asks for resysop, my suggestion would be to either encourage people to edit for a few weeks before requesting resysop or to require people to edit for a few weeks before they are allowed to request resysop. All that is now needed is a better way of measuring "regular editing for a couple of weeks" than "I know it when I see it". Or we need to decline to measure it and leave it up to a bureaucrat vote. (That might work better, actually). —Kusma (t·c) 18:37, 21 July 2019 (UTC)
That's literally the whole damn point. One edit per year should not make you "active". So, why does it? ~Swarm~ {sting} 04:32, 22 July 2019 (UTC)
A not unreasonable opinion, so what should make one "active"? · · · Peter Southwood (talk): 05:44, 22 July 2019 (UTC)
Many projecys require more than one edit per year for an admin to keep the flag. Out of my memory, Wikidata requires five actions in 180 days, Commons as well. When I was still active in the Russian Wikipedia, the was a requirement smth like 30 admin actions and 30 edits per year, otherwise the desysop case goes to ArbCom. None of these projects have resysopping without RfA.--Ymblanter (talk) 19:36, 22 July 2019 (UTC)
Swarm, that is a damn good point, but not the point of this RfC. —Kusma (t·c) 12:13, 23 July 2019 (UTC)
It does seem relevant to the problem this RfC is intended to address. · · · Peter Southwood (talk): 15:38, 23 July 2019 (UTC)
  • Perhaps stricter and looser are not the best choice of words here. There seems a fair amount of support for having more meaningful resysop criteria, but whether they would usefully be described as stricter is not clear and may be putting people at cross purposes. I don't think there is a magic bullet solution, but there may be some common ground in resysop criteria, RfA problems, The T&S fiasco and the problems of maintaining quality while providing an acceptable working environment. · · · Peter Southwood (talk): 07:54, 22 July 2019 (UTC)
  • I think you might be missing a key criterion. As long as the criteria for retention of sysop permissions are so low, it really doesn't matter what the resysop criteria are. In fact, what seems to happen is that there is a big kerfuffle periodically at a resysop request, usually with whining that so-and-so shouldn't be resysopped because they haven't been active enough....and then...what? Do we have any evidence that resysopped admins are performing admin tasks inappropriately? That they're showing evidence of taking action based on antiquated understanding of policy? Frankly, our problems are more often seen in administrators who have never been desysopped. I understand where this RFC is coming from, but it's missing the point. You don't have to worry too much about resysop requirements if you have adequate retention requirements. Risker (talk) 00:18, 23 July 2019 (UTC)
    +1. See my discussion above with Fish and Karate about Andrevan and Rama. — JFG talk 15:31, 23 July 2019 (UTC)
    I agree it makes more sense to keep the criteria for regaining administrative privileges in synch with the criteria for retaining administrative privileges, and if desired, tighten both together. isaacl (talk) 15:34, 23 July 2019 (UTC)
    @Risker, there are problems. We had a recent arbitration case where an inactive admin showed up and unilaterally undeleted a page. We had a less-recent arbitration case where an largely inactive administrator deliberately pushed the limits of appropriate engagement during an arbcom election to make a point. So far, the statistics show that around 15% of all administrators ultimately end up resigning under a cloud or losing their tools involuntarily. I have gone through the contribution history of some long-term marginally active administrators and have found some really questionable actions, admins using undeletion and page protection to defend articles they wrote and so on. The psychosocial problem is that these individuals are no longer afraid of the community and are willing to "cash in" their adminship to prove a point or push their POV. I have tried a strategy of engaging one-on-one with some of these admins, and except in rare (5%) cases they don't respond in any way to a friendly note left on their talk page and emailed. They're disengaged, and have moved on, but still want their bit for the trophy case. UninvitedCompany 18:14, 23 July 2019 (UTC)
    UninvitedCompany, neither of the administrators to whom you refer above were desysopped admins who requested readminship. Both were semi- or fully active editors (also a low standard) and had not been desysopped for inactivity prior to their encounters with Arbcom. This RFC is about standards for re-sysopping, and would not be applicable in any case to either of those administrators. They were never resysopped so any standard that is developed for resysopping would not apply to them. I believe what you want (and in fact what many people are mis-using this RFC to discuss) is to change the standard for retention of sysop permissions. I'm going to be undiplomatic here and note that you yourself barely remained active enough to retain your own sysop and 'crat bits for many years, and it's ironic that now that you've returned, you have repeatedly denigrated the low retention standards that allowed you to keep your bits through all those years. If people want an RFC on retention of bits, then we should have that RFC. This is not that RFC. Risker (talk) 19:56, 23 July 2019 (UTC)
     ::shrug:: I'm back, I try to contribute, others are also. It would not have been the end of the world if I had gone through a sensible level of review before returning to active administrative work. We have this automatic re-adminship policy because it was what we had to adopt to get consensus on the inactivity policy back in the day. I've looked through the history of people who have asked for their bit back and with a few rare exceptions they don't contribute. At a minimum I'd like to see us require a return to active editing and ongoing participation for a month or two before we return the tools. And yes, I believe that the overall handling of inactive contributors should be tightened, including the re-adminship portion of the policy we're discussing now. UninvitedCompany 21:26, 23 July 2019 (UTC)
    UninvitedCompany, you say the statistics show that around 15% of all administrators ultimately end up resigning under a cloud or losing their tools involuntarily. What types of "losing their tools involuntarily" are you including here? On what basis have you arrived at that statistic? I'd like to see some details here, because that's a pretty audacious statement to make. I think you're also applying some pop psychology to adminship that isn't really validated by statistical information, either. Do you have anything to illustrate your statements? I really have a problem with people throwing around statistics without linking to their data and analysis. Risker (talk) 06:02, 26 July 2019 (UTC)
  • While this says "for inactivity" - we have basically the same situation for "resign then become virtual inactive" that shouldn't have a "loophole" either if this goes forward - can be explored if there is a part 2. — xaosflux Talk 20:32, 23 July 2019 (UTC)
  • A pointer to the repository of continuing education for Admins might be helpful to some legacy Admins. Otherwise someone might give it a shot, then be told they missed the IMPORTANT new things Admins should know. Edison (talk) 21:48, 7 August 2019 (UTC)
  • Note I have requested closure it is over 32 days now.Pharaoh of the Wizards (talk) 10:16, 21 August 2019 (UTC)

Option 4?[edit]

Per Boing! "Let's stick to addressing resysop requirements, and save inactive desysop requirements for a separate discussion at another time". ——SerialNumber54129 08:03, 25 July 2019 (UTC)
The following discussion has been closed. Please do not modify it.

It seems to me that a lot of the discussion above is not about "the criteria you need to fulfil when you request resysop should be stricter" but about "the criteria for when you are classified as an active admin who retains their bit should be stricter". There is evidence of tool misuse among people who have never been desysopped, but not so much among people who have been resysopped under our lax criteria. Should we add something like the following? —Kusma (t·c) 21:17, 23 July 2019 (UTC)

  • OPTION 4. The criteria for retaining adminship should be made stricter (currently, one edit or log entry per year is sufficient to retain the bit indefinitely).
  1. Support. This seems very reasonable to me. --Tryptofish (talk) 21:56, 23 July 2019 (UTC)
  2. Support in addition to option 2. —/Mendaliv//Δ's/ 21:59, 23 July 2019 (UTC)
  3. Support alongside option 2. Anarchyte (talk | work) 04:09, 24 July 2019 (UTC)
  4. Oppose at this point. One problem with addressing things like this is that we get multiple proposals all suggesting different things (and I'm sure that's why the original proposal is crafted the way it is), and that pulls us in all directions and we never get a consensus for anything. I think we need to focus and try to achieve one thing rather than diversify and possibly achieve nothing. Please, let's stick to addressing resysop requirements, and save inactive desysop requirements for a separate discussion at another time. Boing! said Zebedee (talk) 08:02, 24 July 2019 (UTC)
    Boing! said Zebedee, the whole point of potentially having this as a separate option is that all of the examples in the discussion above are about people who should have been desysopped, not about people who should not have been resysopped, so the discussion is already happening. Do you have a better suggestion how to focus discussion above on resysop criteria? —Kusma (t·c) 09:24, 24 July 2019 (UTC)
    Yes, I think we should just focus on choosing option 1, 2 or 3 and resolve resysop requirements first, because that's the original proposal and is what the consensus was intended to be judged on. Sure, the discussion section is covering inactive desysop requirements too, and that's fine - but it doesn't mean we need to resolve that in the same RfC right now. A new RfC for inactive desysop requirements can come later, as an offshoot from the current discussion. My real fear is based on my experience of seeing discussions like this expanding in scope, time and time again, to try to fix everything at once rather than picking off one specific thing at a time. (And please be assured that I would support tightening of inactive desysop requirements too, but as a separate RfC later.) Boing! said Zebedee (talk) 09:56, 24 July 2019 (UTC)
    Boing! said Zebedee, as I am one of the people who don't see the problem (I see a perceived problem and the controversy it generates, but I have been unable to identify any problems with the actual outcome of the current policy), I don't think resolving resysop requirements is something that should be done independently from the desysopping/inactivity criteria. (You may change my mind if you can explain to me what the problem is). —Kusma (t·c) 10:13, 24 July 2019 (UTC)
    Well, I'm not actually trying to change your mind ;-) I just think we'd have better chance of success addressing one thing at a time, while you think the two aspects should be addressed together. Such is the way consensus is built. Boing! said Zebedee (talk) 12:09, 24 July 2019 (UTC)
  • Support (along with option 2) I agree with Barkeep49 below that this is really a different question. Schazjmd (talk) 14:45, 24 July 2019 (UTC)
  • Oppose for now per Boing! This is a different discussion. Most of those who know me and have followed the RfCs I have started in the past know that it is my belief that RfCs are only good for documenting pre-existing consensus, and that otherwise they are set up to fail miserably. I do think there is a pre-existing consensus that the resysop criteria are a joke, and even more of a joke than the desysop criteria.
    While this option is getting support now, it also isn't the focus of the RfC, and is a subheader at the bottom that is likely viewed as a side-issue by most participants. If we had a full RfC on this question, I don't think it would achieve consensus (heck, we basically had this a few months ago.) We should focus on the question at hand, and document consensus on that question. If there exists consensus that the resysop criteria should change, then we can go about changing them, and after we set them, we can take another look at the resysop criteria. One step at a time is a good model for change, and this is putting the more difficult policy step to take first. Let's focus on the question at hand. TonyBallioni (talk) 23:07, 24 July 2019 (UTC)

Option 4 Discussion[edit]

While I support this option this feels related and yet distinct in that both this and an option 1-3 could gain consensus. Given the number of editors who had already participated above, and might not revisit this RfC, perhaps it should be its own RfC or at least some real effort made to invite those editors back to weigh in on this, and perhaps notifcations at the noticeboards Tony did in case someone has an opinion about this but not the previous issue? Best, Barkeep49 (talk) 22:56, 23 July 2019 (UTC)

  • I added this option because so many people above seemed to be arguing for it, although it was not one of the questions originally asked in the RfC. It also seems closer to any actual problem (other than generational injustice). —Kusma (t·c) 06:21, 24 July 2019 (UTC)
  • [ec] This seems like a bit of a non-sequitur. I am not against changes to bit-retention or bit-recovery criteria, but I am missing the part of this suggestion that addresses tool misuse by people who have never been desysopped or by people who have been resysopped. In fact I seem to be missing what the point is altogether. What is the problem that Option 4 is intended to fix?
    I think that the terms strict and lax are red herrings in this context. They distract one from the point which is (or should be) quality assurance.
    I assume we would all agree that we need competent, reliable and trusted people to do the admin work. We would probably also accept that these people are volunteers and are not obliged to do any specific parts of the work. Although sysops get all the tools, they may use those they choose to use and not use those they don't choose to use, so great depth of knowledge and skills in using the tools should not be required for all the tools the person has no intention of using. We should analyse the problem, identify places where improvement is needed, and propose actions which could fix those problems. If someone has all the tools and does not use any of them, there is no useful point in keeping them. Is there any significant risk of harm in keeping the tools? If so, what harm? We should be considering ways of mitigating that risk, not expanding rules which do nothing useful. · · · Peter Southwood (talk): 06:38, 24 July 2019 (UTC)
    Pbsouthwood, to be perfectly honest, I think the main problem with the resysop policy as it stands is the amount of controversy that some resysoppings generate (and a more peaceful WP:BN would be nicer). We do not seem to have any examples of a tool misuse problem that would have been prevented by a change to the resysop criteria, but we may have a more general quality assurance problem with legacy sysops. But maybe we just need to make sure we desysop those quickly enough when problems do arise instead of worrying what are the signs that problems might arise. It may be that our processes work fine, but people still feel they don't work fine. If the problem is that RfA is this terrible ordeal, maybe instead of forcing more people to go through it we should make it less of an ordeal? But as we all have tried to change RfA and given up, we tend to go and fiddle with other parts of the process. I think there is more evidence that the retention criteria are flawed than that the resysop criteria are flawed. But you are absolutely right that we should define the problem we're trying to solve so we can then decide whether any proposed solution solves that problem. —Kusma (t·c) 09:39, 24 July 2019 (UTC)
    I think part of the problem is that we have a culture of adversarial debate, where a dispute is generally "won" by the side that can wear their opponents down with walls of shortcut links and diffs, and where the concept of seeking a reasonable compromise or a better solution takes a back seat.
    Would RfA be less adversarial and ad hominem if there were objective measures of competence in the necessary skills for the work that the candidate offers to take on? It is hard to tell, as we don't have any such tests yet. We could try setting up something for one or two of the skills which are most controversial, and see if it makes a difference. · · · Peter Southwood (talk): 15:23, 24 July 2019 (UTC)

The apparently arbitrary closure of the above discussion ignores the point that they are parts of the same problem, and ignoring the causes does not give one a good handle on fixing the effects. · · · Peter Southwood (talk): 09:14, 25 July 2019 (UTC)

I too do not see why this had be overwhelming consensus either way...Lectonar (talk) 09:29, 25 July 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.

RfC: Resysop criteria (part 2)[edit]

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)


Summary of Statements[edit]

  1. 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. 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. 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. 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. 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. 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.
  7. 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. 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. 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. 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. 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. 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.
  15. 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. Proposals that receive some form of net support in this RfC should be taken to a workshop/dedicated stage to refine details and consensus.

Statement 1 by TonyBallioni[edit]

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[edit]
  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 (talkcontribs) 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. SQLQuery 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. CThomas3 (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 (utc) 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, LindsayHello 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)
Users who oppose statement 1[edit]
  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. CThomas3 (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. CThomas3 (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 (talkcontribs) 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[edit]

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. CThomas3 (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 (talkcontribs) 03:57, 6 October 2019 (UTC)
I agree, unless some serious competence or other issue arises during the trial period. CThomas3 (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.) GMGtalk 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)

Statement 2 by Bradv[edit]

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[edit]
  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. SQLQuery me! 01:33, 6 October 2019 (UTC)
  4. Support both.John M Wolfson (talkcontribs) 01:36, 6 October 2019 (UTC)
  5. Support this as well as #1. CThomas3 (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, LindsayHello 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)

Users who oppose statement 2[edit]
  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[edit]
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. CThomas3 (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). SQLQuery 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 (talkcontribs) 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. –xenotalk 08:46, 6 October 2019 (UTC)
Huh, sounds fair enough. – John M Wolfson (talkcontribs) 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)

Statement 3 by Hasteur[edit]

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[edit]
  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. CThomas3 (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. SQLQuery 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)
Users who oppose statement 3[edit]
  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 (utc) 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[edit]

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. –xenotalk 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. –xenotalk 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 (WugapodesLevivich) 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? –xenotalk 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 (utc) 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)

Statement 4 by Hasteur[edit]

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[edit]
  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[edit]
  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)
Discussion of statement 4[edit]
  • After being sugested above by Tony, I'm breaking this out to a separate proposal Hasteur (talk) 02:20, 6 October 2019 (UTC)

Statement 5 by Pharaoh of the Wizards[edit]

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[edit]
  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)
Users who oppose statement 5[edit]
  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[edit]
  • 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)

Statement 6 by GZWDer[edit]

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[edit]
  1. 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[edit]
  1. 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)
  2. 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)
  3. 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)
  4. Needlessly complex, and would incentivize popularity-seeking behaviour. Martinp (talk) 17:20, 7 October 2019 (UTC)
  5. 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)
  6. 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)
  7. Oppose as cumbersome. I also like this idea for borderline RfAs Cas Liber (talk · contribs) 01:51, 8 October 2019 (UTC)
  8. Oppose Why give adminship back at all if there is enough doubt to require a reconfirmation? ‑Scottywong| [communicate] || 22:26, 8 October 2019 (UTC)
  9. Oppose per scotty. What's the point? Buffs (talk) 16:12, 10 October 2019 (UTC)
  10. Too complex. — JFG talk 14:01, 13 October 2019 (UTC)
  11. Oppose as too time-consuming for the community. —pythoncoder (talk | contribs) 19:15, 15 October 2019 (UTC)
  12. Oppose not interested in a "temporary adminship" system. ST47 (talk) 06:42, 16 October 2019 (UTC)
  13. 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)
  14. Oppose: Per OhKayeSierra. Temporary adminship would not go over well. Javert2113 (Siarad.|¤) 14:39, 16 October 2019 (UTC)
  15. Oppose - no temporary admins. It's just a bad idea (c.f. Pandora's box). Ivanvector (Talk/Edits) 15:28, 16 October 2019 (UTC)
  16. 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[edit]

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[edit]
  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. CThomas3 (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 (utc) 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, LindsayHello 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)
Users who oppose statement 7[edit]
  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 (utc) 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 (utc) 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[edit]

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

Statement 7.5 by DESiegel (formerly Procedure)[edit]

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.[disputed ]

Discussion of statement 7.5[edit]
Formerly 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 (utc) 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. –xenotalk 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)

Statement 8 by Kusma[edit]

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[edit]
  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. CThomas3 (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)
Users who oppose statement 8[edit]
  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)
Discussion of statement 8[edit]

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)

Statement 9 by DESiegel[edit]

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[edit]
  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[edit]
  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 abovecomrade 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)
Discussion of statement 9[edit]
  • 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. 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)

Statement 10 by Valereee[edit]

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[edit]
  1. 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[edit]
  1. 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)
  2. 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[edit]

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[edit]

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[edit]
  1. Wug·a·po·des​ 23:50, 6 October 2019 (UTC)
  2. 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)
  3. 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)
  4. 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[edit]
  1. 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)
  2. 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)
  3. 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)
  4. 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)
  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:51, 9 October 2019 (UTC)
  6. 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 (utc) 21:46, 13 October 2019 (UTC)
  7. 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)
  8. Oppose inactivity desysops should not require RFA. ST47 (talk) 06:56, 16 October 2019 (UTC)
  9. Oppose per ST47. OhKayeSierra (talk) 07:39, 16 October 2019 (UTC)
  10. Oppose: per ST47. Javert2113 (Siarad.|¤) 14:43, 16 October 2019 (UTC)
  11. Oppose - automatically makes inactivity desysops equivalent to desysops for misconduct. Hard no. Ivanvector (Talk/Edits) 15:49, 16 October 2019 (UTC)
  12. 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)
  13. Oppose per Jayron32 really Cas Liber (talk · contribs) 09:44, 17 October 2019 (UTC)
  14. Oppose per Scottywong. Kudpung กุดผึ้ง (talk) 19:57, 17 October 2019 (UTC)
Discussion of statement 11[edit]
  • 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 (utc) 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 (utc) 21:33, 13 October 2019 (UTC)

Statement 12 by Govindaharihari[edit]

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[edit]
  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)
Users who oppose statement 12[edit]
  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[edit]

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)

Statement 13 by Cyp[edit]

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[edit]
  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[edit]
  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)
Discussion of statement 13[edit]
  • 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)

Statement 14 by Valereee[edit]

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[edit]
  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. SQLQuery 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)
Users who oppose statement 14[edit]
  • 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[edit]
  • 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)

Statement 15 by JzG[edit]

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[edit]
  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[edit]
  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[edit]

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

Statement 16 by Wugapodes[edit]

Spun out to Wikipedia:Requests for comment/2019 community sentiment on binding desysop procedureWug·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[edit]
  1. feminist (talk) 12:24, 10 October 2019 (UTC)
  2. 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)
  3. This is it. Govindaharihari (talk) 15:08, 10 October 2019 (UTC)
  4. Levivich 18:06, 10 October 2019 (UTC)
  5. Absolutely! Buffs (talk) 22:20, 10 October 2019 (UTC)
  6. I've been arguing for this for a long time. GMGtalk 20:32, 11 October 2019 (UTC)
  7. FASTILY 23:28, 11 October 2019 (UTC)
  8. comrade waddie96 ★ (talk) 13:51, 12 October 2019 (UTC)
  9. I have supported that position for years. DES (talk)DESiegel Contribs 02:53, 13 October 2019 (UTC)
  10. 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)
  11. 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)
  12. 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)
  13. 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)
  14. Calidum 03:06, 16 October 2019 (UTC)
  15. Yes please! -- Ajraddatz (talk) 13:46, 16 October 2019 (UTC)
  16. 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)
  17. 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[edit]
  1. 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 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. 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)
  7. 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)
  8. 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)
  9. 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)
  10. Oppose - as per Boing. GiantSnowman 10:10, 16 October 2019 (UTC)
  11. 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)
  12. 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)
  13. 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)
  14. 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)
  15. 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)
  16. 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)
  17. 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)
  18. 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)
  19. Oppose Needs a separate RfC.-- Pawnkingthree (talk) 20:19, 17 October 2019 (UTC)
Discussion of statement 16[edit]
  • 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'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 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[edit]
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[edit]

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[edit]
  1. 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[edit]
  1. "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)
  2. "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)
  3. 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)
  4. 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)
  5. 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)
  6. Per all my other comments about bureaucrats and subjective criteria. Ivanvector (Talk/Edits) 16:05, 16 October 2019 (UTC)
  7. 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)
  8. Nobody ever has any *need* for admin tools. Boing! said Zebedee (talk) 19:02, 16 October 2019 (UTC)
  9. 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[edit]
  • 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[edit]

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 both clarity, don't contradiction 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[edit]
  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)
Users who oppose statement 18[edit]
  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)
Discussion of statement 18[edit]
  • 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)

General discussion[edit]

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

Where are the problems identified?[edit]

  • 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.


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 c