Statusas of 07:31 (UTC), Friday, 15 November 2024 (update time)
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.
This discussion forms part of a debate on adopting a community-based process for the involuntary removal of administrator rights, administrator recall. This topic was most recently addressed at the 2024 Requests for adminship review; more background information may be found in a section below. The question of this request for comments was whether the result reached during that discussion immediately assumes force of policy, or whether it requires further ratification.
Due to the unusual nature of an RfC to clarify the outcome of a previous RfC, participants at times addressed somewhat different matters in their comments, and some cast bolded support or oppose votes on slightly varying questions. In this closure, I shall focus on the key question as identified above, that is, whether we in principle now have a policy on administrator recall, or not.
On the English Wikipedia, there are no formal requirements for policy changes; that is, there is no specific process that must be followed. The relevant policy Wikipedia:Policies and guidelines § Content changes only specifies that "Major changes should also be publicized to the community in general; announcements may be appropriate." This, to me, means that this RfC is a valid way of figuring out where we want to set the threshold for this particular policy amendment; there is no unequivocal policy argument to either adopt the Phase II result as policy or not. The RfA review was also publicized through several standard channels used for important discussions, fulfilling that requirement.
Proceeding to the discussion at hand, it appears at first sight that the bold yes votes significantly outnumber the noes. However, as mentioned above, in this discussion, bold words can deceive. Furthermore, some editors commented on the contents of the Phase II result rather than on whether it carries the force of policy. I have deemed such arguments irrelevant to this discussion. While weighing this is not entirely quantifiable, and I will therefore not state exact numbers, I consider those in favour of the procedure already being adopted to have a clear numerical superiority.
Some of those who opposed pointed out certain discrepancies in the information provided in the RfC statement, in the Phase II closures, and at Wikipedia:Administrator recall. As of the time of closing, many of these concerns have been resolved, see for example the note at the end of this closing statement. Some things remain undecided; in particular, how the 30 day limit should apply when an administrator elects to re-request through administrator elections. While some editors stated that unresolved questions impede the adoption as policy, most thought that any outstanding issues may be resolved through normal editing. Some editors also opined that, while there may be consensus for the individual conclusions of the review, the policy page written on the basis of these will need to be the subject of a separate RfC to adopt or not. Again, I see a majority of editors being of the opinion that the conclusions may be accepted as policy now, with any further issues resolved by normal editing.
In summary, this RfC has resulted in consensus to adopt administrator recall, according to the Phase II result, as policy. Now, the following should happen.
Any further issues regarding the administrator recall policy will be resolved through normal editing.
Please note the following discrepancies between the present RfC statement and the result of the Phase II RfC. The consensus at Phase II was that reconfirmation via administrator elections shall be subject to a fixed 55% threshold. The 25 editors supporting a recall petition must be extended-confirmed users. The result of this discussion concerns the existing consensus as documented at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall, not the summary in the RfC statement. -- Maddy from Celeste (WAVEDASH)15:38, 26 October 2024 (UTC)[reply]
Is there consensus to have administrator recall based on the consensus reached during Wikipedia:Requests for adminship/2024 review? 03:11, 22 September 2024 (UTC)
The consensus reached there established recall with the following process:
Petition
Cannot be launched until 12 months have passed since the user has successfully requested adminship or bureaucratship, re-requested adminship, or become an arbitrator.
25 editors must support the petition to trigger the re-request for adminship process.
The format allows for discussion and reasoning to be explained.
To support a petition, you must meet the criteria to participate in a request for adminship. You must not support more than 5 open petitions. There is no limitation on how often someone can initiate a petition.
If a petition for a given admin fails to gain the required support, another petition for that admin cannot be launched for six months.
Support statements can be stricken based on the same criteria as for requests for adminship.
Re-request process
A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats.
The re-request can also take the form of participating in an admin election. (Not clear what the consensus is regarding the need for the election to fall within the 30-day window).
For either a re-request or an election, the following thresholds apply:
During phase 1 of WP:RFA2024Joe Roe closed two proposals for recall with the following close (in part with emphasis in the original):
Considering § Proposal 16: Allow the community to initiate recall RfAs, § Proposal 16c: Community recall process based on dewiki, § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.
When the second phase began the process was, after 3 days, structured in a way that took Proposal 16c and offered alternative options for certain criteria. This was done in good faith by Soni who had originally proposed 16c. Some editors objected to this structuring at the time and/or suggested that a 3rd RfC would be needed to confirm consensus; Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. Post-close discussion among editors has failed to achieve any kind of consensus (including whether there needs to be an RfC like this). As an editor uninvolved in the current discussions about Admin recall until now, it seemed to me that the clearest way to figure out if this recall process has consensus or not is to ask the community here rather than have this discussion in parallel with an attempt to recall someone. Barkeep49 (talk) 03:11, 22 September 2024 (UTC)[reply]
(involved) The question here is simple: did a two-phase discussion that reached consensus in both phases also achieve an overall consensus to implement? The answer is equally simple: yes, it did. The current strongest argument against this idea seems to be that Phase II's formatting didn't give enough leeway for someone to propose a recall system distinct from the dewiki process (while still using that as a starting point). But there was an open discussion, and I don't recall seeing a different idea gain any significant amount of traction. If we really need to go through an entirely new RfC to double-confirm a proposal we've already accepted in principle and fine-tuned, fine, let's do it, but it seems like a waste of community time to me. theleekycauldron (talk • she/her) 11:10, 22 September 2024 (UTC)[reply]
Despite this, people added additional proposals, and additional options to existing proposals, and nobody complained about the open discussion section being closed, for months thereafter. Levivich (talk) 18:24, 24 September 2024 (UTC)[reply]
(uninvolved) Yes consensus was reached. Naturally new tweaks/discussions will come along. Let's have specific RfCs on those. ~ 🦝 Shushugah (he/him • talk) 11:38, 22 September 2024 (UTC)[reply]
Yes there is a consensus (uninvolved). A legitimate objection is that the process of managing the second RfC may have stymied other possible outcomes beyond a de wiki style process, and this may have been the case. However, RfCs with perceived flaws tend to generate lots of comments pointing this out (as we can already see below) and I'm just not seeing that that in the 2nd phase RfC. The 1st phase confirmed that the community wanted a recall process, the 2nd phase asked for proposals to be developed for implementation and there was a consensus found within that discussion for a specific variant. In the interest of not letting the perfect being the enemy of the good, I believe there is sufficient support for the admin policy to be updated based in this outcome, with further adjustments being made as required (or indeed removing it entirely should a subsequent consensus determine that it should). Scribolt (talk) 15:42, 22 September 2024 (UTC)[reply]
Strangely-worded question. No, there isn't currently a consensus for this proposal; but yes, I think we should reach consensus for it at this RfC.—S MarshallT/C16:45, 22 September 2024 (UTC)[reply]
A key challenge in trying to reach agreement by consensus is that interest tends to wane as discussion moves from higher-level concepts to more fine details. One way to address this is to get consensus for a general initiative, obtain consensus for key aspects to incorporate, then work on implementation details. For this specific situation, I think the phase 2 discussion did a sufficient job at taking the support shown during phase 1 and working out agreement on the broad-stroke steps for a recall process. As always, because it's hard to get people to pay enough attention to reconcile specific wording, part of working out the implementation means finding a working procedure that is the central object illuminated from different directions by people's statements. I feel the phase 2 results reveals enough scaffolding to proceed with implementation. isaacl (talk) 17:00, 22 September 2024 (UTC)[reply]
(involved) Yes. There is consensus per my comments in the post-close discussion, as well as per leeky and Scribolt above. Those editors raising objections to the idea of admin recall or the proposals that gained consensus, but who did not participate in the earlier RfCs, should have participated; phases I and II were both widely advertised (I remember them being posted at T:CENT, VPP, AN, AN/I, etc.). I worry that a third RfC will fatigue the community and disproportionately draw the most vocal opponents to the process, resulting in a small group of people overriding a consensus already twice-determined by the community. voorts (talk/contributions) 20:51, 22 September 2024 (UTC)[reply]
I participated in both Phase I and Phase II. I believe the results of Phase II achieved consensus and should be implemented. I do not see how this contradicts the results of Phase I. As others have pointed out, an actual policy page is still being drafted and might have to go through yet another RfC. Having an RfC on the validity of each step seems like a waste of time. Toadspike[Talk]07:34, 23 September 2024 (UTC)[reply]
I think your question answers itself. "Was there consensus for the consensus"? The answer is obviously yes. Now, if you want to ask a different question, open a different RFC. --130.111.220.19 (talk) 18:14, 23 September 2024 (UTC)[reply]
No, there isn't consensus for the recall process proposed at Wikipedia:Administrator recall. I'll reiterate a comment I made on the Phase II talk page: taking the mini-consensuses from that phase, then using them to cobble together a process, doesn't translate into a solid policy with broad community consensus. The fact that various aspects of the proposal, even now, are up in the air disproves the notion that "the consensus already exists". Those who are advocating for Wikipedia:Administrator recall need to finalise that page, then present it for a simple yes/no RfC, so that the consensus (or lack thereof) on the policy as a whole is beyond question. SuperMarioMan (Talk) 20:55, 23 September 2024 (UTC)[reply]
No, there is no consensus for this, and I've explained why on the pages where the proposal is being developed. But I think it's unfair to ask this question now, because the editors who support the proposal are still working on it. I therefore think this RfC should be closed as premature. --Tryptofish (talk) 21:51, 23 September 2024 (UTC)[reply]
I had hoped that this RfC would be withdrawn, but it appears that it won't, so I feel the need to say why this RfC cannot establish consensus for the policy change.
First, Barkeep49 gets the facts wrong in the statement of this RfC. He says: Joe Roe would later clarify well after the process was underway that the Phase 2 structure did not, in his opinion as closer, reflect the consensus of Phase 1. In fact, he said more than that: I'm really sorry to say this, but reading it all through now, I think Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall has trainwrecked... I just cannot see how a genuine consensus can be said to come from a process like this... The only way I can see of salvaging this is to take whatever precise version of 16C got the most support and present it as a straight support/oppose RfC.[1]. Barkeep49 goes on to quote Voorts as having determined that phase 2 established consensus: Others, including Voorts who closed most of Admin recall phase 2, suggest that there was adequate consensus to implement the process described above. But in fact, Voorts drew a clear distinction between his close of individual sections, as an uninvolved closer, and his personal opinions about overall consensus, which were separate from the close: [2], [3].
And the bullet-list summary differs in some substantive ways from what appears to be the proposed policy. 25 editors must support the petition. Isn't it 25 extended confirmed editors? Who closes the petition? In fact, this is still being discussed: [4].
Since when are policy pages simply a bullet-list? Are we being asked to establish the bullet-list as a policy page, or are we being asked about Wikipedia:Administrator recall? The latter is beyond any question a work-in-progress. So if it needs to be changed as the editing process there continues, are we establishing consensus for the current version, or for some indeterminate version that will emerge in the future? And if the real purpose of this RfC is to establish consensus against, is that a fair process?
Phase 1 established consensus for some form of process. Phase 2 established consensus for some particular forms of the process, but did not establish whether those forms are actually to be implemented as policy, or whether those forms are the best version to be submitted as a policy proposal. This RfC muddles two different questions: whether the process so far has already established consensus, or whether the proposal summarized in bullet points should now be adopted as policy. And some editors here have been answering the first question, whereas others have been answering the second.
No one has answered the question of what is inadequate with the status quo, with ArbCom handling desysop requests.
The bullet-list proposal would be a disaster for Wikipedia if enacted here. It can't even be launched within the first year after the successful RfA? What happens if an admin does objectional things before then? More importantly, we are in a time when many members of the community are deeply concerned that we do not have enough new admins emerging from RfA, and that we are starting to see backlogs. Many members of the community regard RfA as being unattractive to well-qualified candidates, too stressful, not worth the aggravation. So if any random group of 25 users can force a recall, and just a few can start the petition process, how will that affect administrator morale? Will even more qualified RfA candidates decide against applying? Will current admins become too fearful of angering 25 disruptive editors, and hold back from dealing with contentious tasks, such as AE?
At least we should have a fully-developed proposal for the community to evaluate. Given that there are editors who are working on just that, it seems foolish to demand an up-or-down RfC now, before they have finished, on the theory that this would save them the trouble of working on something that will fail. Plenty of editors want the proposal to succeed, so they are not being imposed upon by giving them the time to finish. And the proposal here isn't ready for prime time. --Tryptofish (talk) 22:56, 25 September 2024 (UTC)[reply]
Yes (uninvolved) - There is a super clear consensus to have an administrator recall. Still work to be done om the actual policy page. But to the question of this RFC, Is there consensus to have administrator recall based on the consensus reached during the last review? Yes clearly, otherwise the right next step would be to challenge that close. This is not the place to relitigate the RFC or how the policy page is being created. PackMecEng (talk) 13:13, 24 September 2024 (UTC)[reply]
No IMO the question is unclear but I think interpreted as "was it decided that the deWiki version be adopted?". In shorthand, the main close was a general consensus that there should be a recall process, with the related verbiage in essence implicitly saying that it needed to be developed and then approved. The close on adopting the deWiki version was that there was insufficient participation (in this context) to consider it to be a decision either way. So the next step is to develop a proposal that can get wide support and get it approved. While keeping in mind that the first close says that it's already decided that "we want something like this" and so that question should not be revisited, and "There should not be any such recall process" is not a valid argument at this point. North8000 (talk) 13:54, 24 September 2024 (UTC)[reply]
Yes. If this discussion is "Should Wikipedia:Administrator recall be implemented?", my answer is yes. That is effectively what the list of points above effectively are. If this question is "Is there consensus already to implement Wikipedia:Administrator recall?" then my answer is also Yes. I think there was consensus via Phase II to do this. If people believe there isn't, then I strongly prefer resolving the first question right now instead of bunting this entire thing to a second RFC further down the line. I also personally would have preferred a week while editors already discussing the matter at Wikipedia talk:Administrator recall could resolve this. But the cat's out of the bag, and nobody seems to actually close this as premature. So I would prefer going through with this RFC instead of alternatives that draw this out for everyone. Soni (talk) 05:06, 25 September 2024 (UTC)[reply]
Regarding Soni's first question, my answer is unreservedly Yes. Regarding Soni's second question, my answer is a Very Weak Yes. Also, this RfC is a premature mess. Tazerdadog (talk) 18:30, 25 September 2024 (UTC)[reply]
Yes. We do not need an RfC to answer the question "Did the previous discussion, with a consensus close, actually close with a consensus?" Just get it done. Details will, as usual, be refined as we go along. If the entire thing turns out, after post-implementation experience, to be a bad idea, then it can be undone later. PS: If there is doubt whether a close of an RfC or other discussion actually reached the consensus claimed by the closer, the place to hash that out is WP:AN (unless it's subject to a more specific review process like WP:MRV for move disputes, and WP:DRV for deletion ones). — SMcCandlish☏¢ 😼 13:08, 27 September 2024 (UTC)[reply]
No. The partial trainwreck of the discussion that happened at the Phase II RfC meant that consensus for several critical aspects of the recall proposal did not gain sufficient consensus to enact such a significant change to a core policy (WP:ADMIN). And for my own part I failed to see a consensus on some matters at all, though I suppose reasonable minds can disagree on the matter. JavaHurricane10:31, 29 September 2024 (UTC)[reply]
I don't think the question here is whether there is consensus for some future version, in which the details will have been finalized. It's whether there is consensus for what it says at the top of this RfC. --Tryptofish (talk) 22:50, 29 September 2024 (UTC)[reply]
Right. And my position is that there is (or at least it should be established here) consensus for the form of recall described in the 14 bullet points listed above. Some people in this discussion have queried the precise interpretation of some of the points, so another round of workshopping precise language would not be amiss, but the proposal should continue to move forward on this basis without "going back to the drawing board" because of concerns about a previous RFC. Eluchil404 (talk) 23:43, 29 September 2024 (UTC)[reply]
Yes, there is consensus to adopt an administrator recall process that includes the characteristics that achieved consensus in RFA2024 Phase II. To my eye, the proposal here successfully reflects that consensus. ModernDayTrilobite (talk • contribs) 14:41, 30 September 2024 (UTC)[reply]
"25 editors" is much too vague. Could be 25 IPs? Only logged in editors with some experience should be allowed, and the simplest way is to require EC. Zerotalk02:47, 3 October 2024 (UTC)[reply]
Already done. The suffrage requirements for recall petitions are "same as RFA". That was one of the Phase 2 consensuses (consensi?). Phase 1 consensus set RFA suffrage to EC. Levivich (talk) 03:33, 3 October 2024 (UTC)[reply]
Yes, confirm consensus. The weight of community involvement and the clear consensus close are sufficient to grant this process the effect of policy immediately. I will say this: I am absolutely shocked that the second phase of the discussion was not better advertised; given the long-anticipated nature of this process and the importance to community functions moving forward, it should have been better attended. And yet, the dozens of editors that did participate came to reasonable and clear consensus conclusions on various facets of the process. Beyond that, we are years deep into repeated derailing of the creation of this function, despite clear community support for some sort of process. There is absolutely no reason why further discussion to clarify, alter, or amend any provision of the process cannot take place after the process is codified in its namespace. But the time has come for the process to exist, and there is nothing egregiously problematic in what was decided upon in the foregoing discussion. With the caveat that, no matter what the community decided upon for the initial procedure, there are bound to be things we can only think to address and adjust after the first community RRfA discussions take place. SnowRise let's rap10:33, 3 October 2024 (UTC)[reply]
Well, fair enough, if it was posted on CD, which is arguably the single best thing you can do to promote an issue. But I do think spaces like VP are a vastly more reasonable place for posting a notice intended to draw in general community input about the recall of admins, compared to AN, with it's limited traffic mostly constrained to admin activity (or at least as much constrained as any open space on the project). In fact, some may argue (though I'm certain it was lack of forethought rather than intent) that the only noticeboard to receive a notice of the discussion being the one noticeboard with the highest admin-to-non-admin activity ratio is maybe the least optimal way to advertise a discussion that would seek to create the community's first direct means for recalling admins. The CD link seems to have been the only notice well-calculated to reach an average community member: the mass mailer, the discussion link in the closure of phase I, and the watchlist notice, all of those were only ever going to reach those who participated in Phase I. Which is good, but again, probably a lot less than this discussion warranted. SnowRise let's rap17:35, 4 October 2024 (UTC)[reply]
Yes there appears to be community consensus to implement an Administrator Recall process as described. I think some of the concerns raised are genuine, especially the potential for abuse... But I doubt the community would look kindly on editors who chose to WP:GAME this new system. Horse Eye's Back (talk) 20:06, 4 October 2024 (UTC)[reply]
Yes (involved). The existence of the pre-voting "open discussion" section, as well as the widespread "find a consensus" sentiment was enough for the consensus found to be valid. Mach6114:10, 7 October 2024 (UTC)[reply]
Yes (involved). From the get-go, the purpose of WP:RFA2024 was to reach consensus -- not to workshop a proposal for later ratification, but to workshop proposals and approve/deny them in the same RFA2024 process. In Phase I, Proposals 16 and 16c, the overall proposal for a community-based recall system (#16) reached consensus. On the numbers, 65 editors voted, and it was 43-22. On the proposal for a specific dewiki-like system (#16c), 34 editors voted, it was a 25-9 majority, but this was determined to not be consensus because of the (relatively) lower participation.
We went on to Phase II, where specific proposals for details of the recall system were made. The purpose of Phase II was, clearly, to iron the details from Phase I #16c, not to draft a proposal for submission to the community, but to decide the details, in Phase II. This is evidenced by the many "find a consensus" votes in Phase II (the phrase appears 27 times on the page, in addition to which there are various variations on the theme), which were editors expressly saying they'd rather have a recall system in place with any of the proposed details, than have the proposal for recall fail due to disagreement about some of its details. It was clear that the participants wanted Phase II to end with a consensus for an actual system, not a proposal for a third round of RFC. 93 editors participated in Phase II [5], which is even more than in Phase I.
Both Phase I and II were widely advertised, tagged with the RFC template, advertised on watchlists, and posted on WP:CENT -- they more than complied with WP:PGCHANGE. They had broad participation, and the fact that Phase II ended with a system very similar to dewiki only confirms the budding consensus from Phase I. The fact that the "open discussion" section of Phase II was closed after a few days does not undermine the consensus-forming process in my view; discussion continued, new proposals continued to be made, and some voted against the entire idea of recall. Nevertheless, consensus was formed on various proposals, leading to the system that is now well-documented at WP:RECALL.
So, yes, this months-long process confirmed what we all already knew was global consensus (to have a community-decided involuntary recall system, and to have it be modeled on dewiki's successful system); this RFC will be the third time in a single year that this global consensus will be confirmed. When this RFC is closed as "yes," as I believe it will be, we should put the policy template on WP:RECALL and that should dispel any and all doubts as to whether WP:RECALL has consensus. 100+ editors in 3 rounds of voting is more than enough to establish global consensus. Levivich (talk) 17:47, 7 October 2024 (UTC)[reply]
Yes and No. It appears that Wikipedia:Administrator recall is still being developed and that these dot points are the basis for that development. There is a consensus for a recall policy according to these dot points but as has been pointed out above these dot points are not a policy in and of themselves so cannot be adopted immediately. When there is consensus for a barebones policy (the dot points) it is then developed into an actual policy page before a final RfC to adopt it. That's the normal process and should be followed here. So, yes there is a consensus to have a recall process along the lines of the dot points and that is correctly being developed into a policy before final adoption so, no, there is not yet a consensus to turn the wordy version at Wikipedia:Administrator recall into policy. Callanecc (talk • contribs • logs) 01:49, 8 October 2024 (UTC)[reply]
Sounds like it's ready for an RfC for formal adoption as a policy then? I don't think it's appropriate to merge this RfC into that given that the proposal here is a series of dot points that is different to what's at Wikipedia:Administrator recall. For example, I wouldn't support 25 editors as listed in this proposal but would support 25 extended confirmed editors. Other questions have been raised above (for example what if there's a concurrent ArbCom case) and I would encourage editors who have raised those concerns here to take them to Wikipedia talk:Administrator recall for a further discussion and whether or not they should be incorporated into that proposal before it is put forward for adoption. Callanecc (talk • contribs • logs) 00:26, 9 October 2024 (UTC)[reply]
While I have expressed agreement with this sentiment before, I am also a firm believer of not putting everyone through additional WP:BURO after this. So I'd rather User: Barkeep49 or someone else add a link to WP:Administrator recall to the topic above instead of trying to wrangle a 4th RFC. I'd phrased my !vote above to answer the question I think we should be asking anyway. Soni (talk) 06:30, 9 October 2024 (UTC)[reply]
Agreed: Callanecc and Dilettante's points are accurate and well taken, but this really does come down to a more direct call on community will and BURO. I think the obvious emerging consensus here is that if a version of the policy language has already been rendered which includes all of the consensus elements agreed to for the process, without any glaring contraventions or other issues, then as soon as this discussion closes with a consensus in the affirmative, that version of the guideline becomes policy immediately. Repeating the process yet again for purely pro forma reasons is not necessary, appropriate, or a reasonable use of community time. Let's remember that any version validated can thereafter be reasonably expected to be subject to discussion and further tweaking, particularly in its first months. EDIT: Though I do think one reasonable thing that could be done thereafter would be to advertise every major disputed discussion on the guideline talk page at VPP for the next six months (and having a tendency to do so thereafter, really). It is, after all, a new process that has non-trivial consequence to our administrative operations, so continuing to have heavy community input in its initial evolution here can only be regarded as a good thing. SnowRise let's rap03:18, 13 October 2024 (UTC)[reply]
Adding on to the pile that says that we've already gone through so much bureaucracy at this point that any more after this would be really out of the norm. If there's consensus here, mark it as policy and work out fine details as they are brought up. If there's not consensus, let's find out right now, and not after more formal RFC cycles. Tazerdadog (talk) 18:12, 15 October 2024 (UTC)[reply]
Yes on principle, but some points still need to be workshopped. How does 50–60%: Bureaucrats evaluate consensus work for an election? Is it split in the middle? This kind of details should've been made clear before putting the proposal up to a vote. (Edit: looking at the comments below, this appears to have already been discussed) Chaotic Enby (talk · contribs) 06:15, 9 October 2024 (UTC)[reply]
Close as the proposal is still being developed. A draft of a full proposal is being discussed at WP:Administrator recall that refines and adds clarification to the closes at WP:RFA2024. All editors are welcome to participate in the discussion. I do anticipate that this proposal will come back for community discussion. --Enos733 (talk) 03:35, 22 September 2024 (UTC)[reply]
As noted when this was raised on my talk page, the work there appears procedural. There is no agreement even there about whether or not this is already policy or not. Having editors spend time developing something in detail when the core policy doesn't have consensus is a poor use of time in my opinion. If it does have consensus the details can be worked out and will be made to happen. We have seen that happen with Admin elections coming out of the RFA2024 process. Best, Barkeep49 (talk) 03:49, 22 September 2024 (UTC)[reply]
I understand where you are coming from, but the detailed efforts identified a couple challenges with how to implement the close, and I wouldn't suggest that the policy described above is the exact proposal coming from those efforts (although it is in harmony with the closes in WP:RFA2024). While every policy could be further refined, I am of the belief that our community is best served by bringing forward a more complete proposal for community discussion. - Enos733 (talk) 04:28, 22 September 2024 (UTC)[reply]
This should be closed. For most people, whether they support admin recall depends very much on the details of the proposed mechanism. For a sensible RfC, the mechanism has to be spelled out (as above) but must not change for 30 days. That does not match reality at the moment. Johnuniq (talk) 04:48, 22 September 2024 (UTC)[reply]
Barkeep49, I oppose the proposal, but I think you should withdraw this RfC for now. What people still need (or at least should be entitled to) is to see a full proposal, a proposed policy page, not the bullet list summary you posted here, and to see a rationale for adopting the proposal, prepared by its supporters. And editors are working on those things now. --Tryptofish (talk) 21:59, 23 September 2024 (UTC)[reply]
I long ago tuned this out as a TL;DR waste of my time. But curious, is there a consensus that the current Arbitration Committee-led "recall procedure" is not up to the task, and should be discontinued? Or, rather, is there a consensus that both procedures may be used. Can an admin be subject to both an Arbcom case *and* a "community recall procedure" at the same time? Is there a consensus for that? To be clear, I oppose the possibility of simultaneous, competing recall procedures. wbm1058 (talk) 09:53, 22 September 2024 (UTC)[reply]
@Wbm1058 Nothing in this above would prevent someone from becoming a party to an arbcom case, or from arbcom issuing any remedy. How would you like a blocking condition to work? Perhaps a prohibition on community recall rrfa launching while the admin is a party to an arbcom case? — xaosfluxTalk10:42, 22 September 2024 (UTC)[reply]
If stripping the Arbitration Committee of the power to desysop isn't part of the package, this whole "recall procedure" strikes me as highly problematic. Imagine an Admin suffering through a month-long Arbitration Commmittee proceeding, ending with an "admonishment" to the administrator, followed hours later by the opening of a "community recall procedure". – wbm1058 (talk) 10:52, 22 September 2024 (UTC)[reply]
Should be consensus for 55%. Option C stated the midpoint of whatever passed in the other discussion. Option C won there, which was 50-60%, so the midpoint is 55% which is explicitly called out in the first discussion. Pinging @Voorts: in case I'm completely misreading something here. Tazerdadog (talk) 18:51, 22 September 2024 (UTC)[reply]
Leaving aside everything else, this part is confusing: A bureaucrat will start a re-request for adminship by default. The admin can request a delay of up to 30 days. If the re-request does not start by then, the admin can have their privileges removed at the discretion of the bureaucrats. Is this implying that if the admin requests a delay then the admin is responsible for creating it? Why not have the 'crat create it after the delay, same as they would for no-delay? Anomie⚔14:39, 22 September 2024 (UTC)[reply]
I don't like that part at all. I'd rather see the admin start their own RRFA within some short deadline (7 days - with possibly the option for asking for the 30 day extension) -- and if they don't start it anyone can ask at BN to process the desysop. Crats never have to edit, so requiring the crats to create a pageto move the process forward gives them a pocket veto. — xaosfluxTalk14:46, 22 September 2024 (UTC)[reply]
I disagree with this RFC's summary of that part of the proposal. As I read it, an admin chooses whether to start an RFA (or stand for election), which must be done within 30 days, and if it's not done within 30 days, crats desysop with discretion ("discretion" such as taking into account whether the petition was entirely signed by obvious sock puppets or had the requisite number of qualified signatories, or to extend the period to 32 or 33 days instead of 30 due to the admin's RL schedule, things of that nature). Levivich (talk) 15:06, 22 September 2024 (UTC)[reply]
Option E there is where it says the 'crat should open create the discussion. The other options had the admin being required to say "come attack me" within a certain period of time. The combination of E+A is where we got the confusion here, since E didn't explicitly say what should happen if a delay is requested. Anomie⚔15:11, 22 September 2024 (UTC)[reply]
OTOH, looks like only 9 of those 30+ voted after E was added. That part, at least, seems like it could use further discussion by people who care. Anomie⚔15:23, 22 September 2024 (UTC)[reply]
I don't think it would ever happen, but in theory the crats could just wait 30 days and then decide to revoke privileges without any community input, which seems like a flaw, that part should be reworded to clarify who is responsible for starting the process in each situation. ASUKITE17:08, 3 October 2024 (UTC)[reply]
Close as premature. The page is a mess right now, as several people have posted above. It isn't anywhere near finalized so of course there will be holes and parts where it doesn't judge consensus. When I said "What we need is an RFC to decide whether or not we need another RFC", I didn't expect anyone to actually do it.Sincerely, Dilettante15:48, 22 September 2024 (UTC)[reply]
I'm a little confused as to what is being asked here: is this a request for approval of a process? Or are we judging whether consensus was previously formed for it? The latter does not seem to me a good question to ask, as it is sending us further into the weeds of a proposal that has already gotten out of hand with respect to creation and approval procedure. But that's how I read my colleagues' !votes above. Vanamonde93 (talk) 16:16, 22 September 2024 (UTC)[reply]
Do we really need another bureaucratic mess that is another RfC? I think the last one had enough consensus. Ping me if there's anything in particular we're trying to work out and I'm not getting the point of this. I'm trying to take a step back from the more complicated aspects of the project right now but this is important. Clovermoss🍀(talk)16:20, 22 September 2024 (UTC)[reply]
Close as a confusing, duplicative mess. The specific question in this RFC, as far as I can make out, is asking whether the previous discussion had consensus to implement something following discussion, or whether the outcome of that further discussion needs to be subject to an RFC. I don't think it's sensible to even ask that until that further discussion is complete and we can see the differences between it and the consensus outcome. However, above there appears to be discussion of things other than that question, and no clear agreement about what the consensus of the last RFC was (with the consensus as determined by the closer having changed at least once since the initial close) - other than more discussion of the details was needed (which seems to be happening in two places). I don't think it's possible for this discussion to be useful in any way so it should be closed before it creates even more confusion. Thryduulf (talk) 21:04, 22 September 2024 (UTC)[reply]
@Thryduulf: I think there might be some confusion about what this discussion is for – it would definitely be silly if it was trying to ask people to assess the consensus of the post-close discussion on talk. This RfC asks the same question the post-close discussion has been focused on: did the Phase I and Phase II RfCs result in a consensus to implement? That, I think, is worth discussing. theleekycauldron (talk • she/her) 23:23, 22 September 2024 (UTC)[reply]
The "25 editors" figure in the initial proposal was qualified as being extended confirmed. Definitely not supporting a process whereby any 25 editors, over the course of a full month, can start this process. — Rhododendritestalk \\ 13:13, 24 September 2024 (UTC)[reply]
I don't think there's a consensus ... but whether there is or isn't, "There is no limitation on how often someone can initiate a petition." needs to be clarified. You can't support more than five open petitions, but then the next sentence says you can initiate a petition without limit. Those two statements need to be harmonized. --B (talk) 13:34, 24 September 2024 (UTC)[reply]
I don't think "There is no limitation on how often someone can initiate a petition" is entirely accurate. There are limitations on how often someone can initiate a petition (there are cooling off periods, plus the 5-petitions-at-once limit), limitations that were decided in Phase II and are specified at WP:Administrator recall § Petition. Levivich (talk) 18:20, 24 September 2024 (UTC)[reply]
Re:Close as premature comments, I said my piece above and on my talk page about why I thought (and think) it appropriate. I also don't think I hold any particular status other than being UNINVOLVED in this process. So if some other UNINVOLVED editor wants to close this as premature, I'm certainly not going to push back. Best, Barkeep49 (talk) 20:18, 25 September 2024 (UTC)[reply]
For further background, see wp:Administrators_open_to_recall and the associated categories and pages. (including pages related to some actual recalls) When we came up with this back in the Jurassic Era, we intended it to be voluntary. It's interesting to see that there appears to be consensus that some kind of mandatory process be implemented. ++Lar: t/c15:53, 9 October 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Discussion about refining the implementation details of proposals from Phase I of WP:RFA2024 for community-based recall of administrators. --19:29, 15 May 2024 (UTC)
Welcome! Following the passage of proposals 16 and 16c, we have consensus for a community-based recall of administrators. This subpage is for Phase II, so we can refine the implementation details.
The discussion close by Joe Roe is reprinted here:
Proposal 16 suggested that a RRFA could be initiated by consensus following a discussion at the Wikipedia:Administrators' Noticeboard (AN). I don't see a consensus for this specific procedure, since a significant proportion of both those against and those in support the proposal were against it. The original suggestion that ANI and/or XRV could also be used to initiate an RRFA was rejected outright.
Proposal 16d offered a more fleshed-out version of an RRFA initiated at AN, but it did not find consensus and was withdrawn.
Proposal 16c suggested adopting the German Wikipedia's admin reelection process, which obliges an admin to make an RRFA if 25 editors with Extended Confirmed rights vote for it within the last 1 month [or] if 50 editors with Extended Confirmed rights vote for it within the last 1 year. There was a solid numerical majority in favour of this procedure, with supporters pointing to the advantages of using a process that has already been shown to work on another project. However, considering the relatively low participation in this sub-discussion compared to the level of opposition to RRFAs in general expressed elsewhere, this is not necessarily a sign of broad consensus.
Amongst those who opposed this proposal entirely (i.e. not just specific implementation details), their main reasons were that desysopping is already satisfactorily handled by the Arbitration Committee, that it would discourage administrators from making unpopular but correct decisions, or that it could be open to abuse. The primary counter-arguments given to these were that other projects have community desysop procedures (dewiki, commons) without issue and that on enwiki the community can already impose harsher sanctions (i.e. site bans) by consensus alone. I cannot see any policy-based reason to weigh one set of arguments more than the other, so the substantial numerical majority in support (43–22 for 16; 25–9 for 16c) will have to speak for itself.
As written, the original 16C proposal was:
WP:Admin Reconfirmation will be created, where any subpages can be created for individual admins. Editors may sign on those subpages to vote for a reconfirmation.
The reconfirmation is initiated if 25 editors with Extended Confirmed rights vote for it within the last 1 month. Or if 50 editors with Extended Confirmed rights vote for it within the last 1 year.
Once a reconfirmation is started, the admin in question must run for a "Reconfirmation RFA" (RRFA) within the next 30 days. Otherwise a bureaucrat can remove their admin rights.
A RRFA will be identical to any RFA, but with lower thresholds. Instead of 75% "generally passing", it'll be 66%. And the discretionary range for Bureaucrats will be 55% to 66% instead of 65% to 75%. Any admins who fail a RRFA will have their admin rights revoked.
Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.
Admins who have successfully run for an RFA, RFB, RRFA, or Arbcom elections in the last 1 year are not eligible for a community initiated Reconfirmation. Any votes for reconfirmation in the 1 year after an admin succeeds any of these will be struck.