Status as of 13:11 (UTC), Wednesday, 29 May 2024 (
)
|
Discussion about refining the implementation details of proposals from Phase I of WP:RFA2024 for community-based recall of administrators. --19:31, 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:
Considering Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16: Allow the community to initiate recall RfAs, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16c: Community recall process based on dewiki, Wikipedia:Requests for adminship/2024 review/Phase I § 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.
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.
Which of these conditions should be sufficient to compel an administrator to run an RRfA? Support more than one option if needed
Note - A rolling petition = A petition where anyone can sign, and RRFA can be triggered if there's votes in the last N days. Older signatures are handled as per #Expired signatures on initiation petitions. A non-rolling petition would be started, and then run for N days, after which it will be closed in favour of RRFA/no RRFA.
Note - The word "request" was replaced with petition for consistency with rest of the page. Rolling vs non rolling petitions was clarified further.
As written, it's a rolling window: within the last 1 year.
Should RRFA petition signatures "roll"? For example, in a rolling petition with a length of one month, each signature expires when it is a month old; in a non-rolling petition, the petition itself expires a month after it is opened. theleekycauldron ( talk • she/her) 23:47, 25 May 2024 (UTC)
What percentages of support are necessary for an administrator to pass a reconfirmation RfA?
Note - Option A stated 66.6% for a couple hours. It was altered to 65% per discussion section below.
But almost all of those would like to see a recall mechanism over none.
When is a recall petition not allowed for an admin?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
We could even say something like "Bureaucrats can disallow any RRFA that is found to be repetitive or tendentious via a crat chat. Tazerdadog ( talk) 16:50, 8 May 2024 (UTC)
Just to clarify my thinking on this (and to open myself up to rebuttal, in case people disagree): I do not like C+, because it confers an unnecessarily long period of immunity on an administrator, with no process or discussion (other than a list of signatures, which must be a short list or else the petition would have succeeded). C is a necessary evil to prohibit back-door rolling petitions, but the only other process I can think of with this kind of rerun immunity is WP:PROD, which has numerous important differences that should be obvious to anyone familiar with it (but just in case: articles are not editors, PROD is subordinate to AfD which has no such limitation, CSD is also available for simple cases, etc.). I also feel strongly that, if an admin has multiple recall petitions within a year, and it is not the result of harassment from the people filing the petitions, that fact alone is seriously concerning, and sweeping it under the rug with a blanket prohibition is not going to fix anything. It's merely going to redirect the discussion to other forums like ANI, most of which are less capable of dealing with this sort of discontent (RFAR can deal with it, but eugh, nobody wants to go to RFAR with three paragraphs of " User:Example keeps using their tools slightly wrong and reacting badly to criticism, and we tried talking to them but..."). -- N Y Kevin 02:36, 26 May 2024 (UTC)
When can eligible editors vote for a recall petition?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
Under what circumstance can a vote on a recall petition be stricken or removed? Support more than one option if needed.
Note - This section was titled 'Removing signatures' for a couple hours. It was altered to 'Striking/Removing signatures' (and the question adjusted) per discussion below. "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
Any admin (uninvolved with the user in question and admin the petition is against) may unilateraly topic ban/page block disruptive users from starting or supporting positions. This was meant to import one facet of Contentious topics, without designating all of RRFA as a CT. The idea was that if one person was constatnly opening frivolous requests, or signing in bad faith, they could be blocked from doing so without the trouble of finding consensus at WP:AN. Striking individual signatures wasn't what I was concerned about. So support A only Mach61 17:19, 8 May 2024 (UTC)
Recall petitions cannot be successfully closed without a CheckUser confirmation. Checkusers are not going to check every account (or even a significant proportion) in a recall proposal - that would be fishing, as well as probably also ineffective. If you want a checkuser to just sign off on a recall motion, then that's not going to provide the guarantee it implies, nor add much to what's already out there, IMO. Considering these two aspects it seems to me to be unnecessary to mention checkusers at all here, and there should be reference to standard sock-striking procedures (I guess that's option C). -- zzuuzz (talk) 18:53, 11 May 2024 (UTC)
After a successful Recall petition, when should an admin be desysopped?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
There should be a rule stated here that the clock pauses while the admin being recalled is under scrutiny in an active case or case request at arbcom. Arbcom should be allowed to go first to give the community the maximum amount of information. Tazerdadog ( talk) 16:56, 8 May 2024 (UTC)
I added an Option D. Option C seems ripe for abuse by a well-organized minority. Chetsford ( talk) 23:57, 8 May 2024 (UTC)
Seeing multiple editors agree with
Teratix's suggestion, it should probably be added as an option explicitly to help gauge the consensus. My suggested wording was something like *Option E: (In addition to another option) RRFAs should be started as soon as possible after a successful recall petition
.
I still think it should include some explicit leeway for editors who are around but cannot go through RRFA right away. But someone who supports the Option is better off phrasing it as they best can
Soni (
talk) 03:27, 12 May 2024 (UTC)
Should votes in a Recall petition be limited to signatures? Can they have discussion?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
This type of vetting should be built on consensus and not votes.Per #Initiation procedure, most proposals we have are are using votes. There may be a case for an initiation procedure of something like "if consensus is found after a recall petition discussion", but nobody suggested it yet. Soni ( talk) 00:48, 17 May 2024 (UTC)
I don't see the need to do it differently than we do at any other discussion, e.g. RFA, RFC, AFD, etc. etc.So my reasoning for doing it differently here was because general discussion risks litigating the same matter multiple times at different locations. An admin going through recall may have to potentially respond to AN/ANI threads, recall petition and RRFA; and the same for other editors discussing the concerns. This risks the entire process getting strifed to an exceptional degree, which is the central concern I have been working against.
|
If there's any implementation details not already covered by the previous sections, please add them here.
Can an admin stand for reconfirmation via Administrator Elections?
What would the threshold be? Obviously it can't be whatever we agree on above, since there's no room for bureaucrat discretion in a pure vote. If it's just the same 70% cutoff at WP:AELECT, then there's no need to shoehorn this into the reconfirmation process: the admin should just resign and run at the next election. (In practice this will never happen as long as the reconfirmation threshold is lower.) Extraordinary Writ ( talk) 02:16, 9 May 2024 (UTC)
The summary of consensus from phase one was that the community should be able to compel an administrator to make a re-request for adminship (RRFA) was for a "Re-request for adminship" procedure that could be initiated by the community.
Thus I think the re-request procedure itself should be the same, whether it is done on the administrator's own initiative, or as a result of a petition from the community. This includes the criteria for determining if the re-request has succeeded.
isaacl (
talk) 16:51, 9 May 2024 (UTC)
What percentages of support are necessary for an administrator to pass a reconfirmation admin election?
It took me a while to realize that this isn't the same as #Reconfirmation threshold above, as this deals with Wikipedia:Administrator elections in conjunction with the question above. SWinxy ( talk) 23:11, 10 May 2024 (UTC)
When a petition is created at the Wikipedia:Admin Reconfirmation page, what notifications should be made (beside the admin's talk page)? Choose all that apply.
Other options welcome. Extraordinary Writ ( talk) 20:09, 9 May 2024 (UTC)
If other notifications are precluded with option A, it seems unduly restrictive. If no one knows about a petition, they won't be able to sign on. The decision would be made by a self-selected group of page watchers. It might be more effective to appoint a designated committee in that case. If other notifications are still permissible with option A, then there would be incentive for a "get out the vote" style campaign, which I feel would be unnecessarily divisive. isaacl ( talk) 03:13, 10 May 2024 (UTC)
The question assumes that you have to notify the admin in question. Is that actually codified anywhere, or should we create it as its own question? --
Ahecht (
TALK
PAGE) 13:55, 10 May 2024 (UTC)
If a rolling petition is used, what should be done with signatures that have "expired" because they are older than the longest rolling period (e.g. 1 year for Option A, 1 month for Options B and C, etc.)?
In order to prevent harassment and other nonsense, we should restrict how often someone can participate in initiating one of these.
To be clear, this isn't a limitation on participating in the subsequent discussion, but merely being an "initiator" as laid out in the proposals above.
I think I would prefer there be a minimum period between petitions for a given administrator. (Any serious concerns that arise during this period would have to be handled through an arbitration request.) If someone is starting petitions vexatiously, it can be handled through existing policies on collaborative behaviour. isaacl ( talk) 21:19, 27 May 2024 (UTC)
The original proposal 16c clarified that voters in an RRfA request must be extended confirmed, which is now also a requirement for voting at RfA. However, 16c didn't necessarily get "broad consensus". We might need to add a section to this page to confirm that only extended confirmed editors' votes in an RRfA request count. Toadspike ( talk) 17:04, 8 May 2024 (UTC)
By the time we get to an RRfA, there's been extensive discussion about the issues at hand and the admin has already gone through a full RfA process. Let's get rid of the "questions" process and all the baggage that goes with it. — Rhododendrites talk \\ 17:28, 8 May 2024 (UTC)
The issue at RRFA isn't "did they misuse the tools" (that's what arbcom is for), the issue at RRFA is "do they have the trust to be an admin?"). There is no thing-in-itself of adminship separately from use of the tools. If there is a lack of "trust" in someone's adminship that is somehow unrelated to misuse of the tools, then that lack of trust isn't a valid concern to begin with. Separated from any concerns over actual abuse of admin powers, this proposal aggravates the already dangerous tendency to equate adminship with some kind of social rank or esteem -- while also creating a new mechanism for removing any dissenting voices within this "trusted" group. It's difficult to overstate how disastrous that could be for the project. -- Visviva ( talk) 05:33, 10 May 2024 (UTC)
What happens to the page in the case of non-rolling petitions? Is it deleted, blanked, kept, or is the fate wholly up to the user in question? and does that vary based on whether it meets the threshold? The obvious argument for keeping is that it makes determining suffrage for petitions easier. The obvious argument against is that keeping a list of an admin's detractors is demotivating and easy to abuse. Copied from talk. Sincerely, Dilettante 18:25, 8 May 2024 (UTC)
Editors who are formulating this proposal should give some serious thought to making the case for why such a proposal is needed. After each of the survey points above has been hashed out, there will need to be a community-wide RfC on whether or not to make the proposal a policy. (Arguing that there was a consensus in Phase 1 to create some sort of proposal will be insufficient.) Are there examples of ways in which the status quo is not meeting the community's needs, that the new proposal will address? How will you answer concerns that good admins will be mistreated by the proposed process? -- Tryptofish ( talk) 00:51, 9 May 2024 (UTC)
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 current survey doesn't provide a way to evaluate "if any" procedure should be adopted. If the phase 2 discussion is modified to accommodate disagreement, then I don't feel another discussion is required. In its current form, though, a discussion on a consolidated proposal for the administrator recall process would be needed to determine consensus. isaacl ( talk) 03:07, 9 May 2024 (UTC)
I believe that there are interested parties who aren't raising objections on individual aspects, as they are letting those with strong opinions reach agreementThen those interested parties should raise the objections on the current phase, conditionally or otherwise. This proposal is not in a vacuum, and each section already has interactions with other sections currently. There are multiple supporting editors who reference other sections in their discussions, I see no reason why the same cannot be said for editors who have concerns.
I think it would be a good idea if you stepped back and let less involved parties (theleekycauldron, maybe?) manage the process of building consensusSounds good to me. I may have understood your "starting point for the discussions" comment a bit different than you intended, hence the 'Open discussion' sectioning phrased as it was.
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.There is a clear meaning to the words "if any": that it is at least possible that none of the "specific proposals" will get consensus to be adopted. Therefore, whatever is done in Phase II must include an option not to do the specific thing being proposed at all. And, as also noted above, the questions have all been formulated along the lines of "which of these options will be adopted?", without the option of "none of the above". That's a big problem! One cannot just wish it away, or ignore it.
force one of the offered options [in phase 2] to be adopted. Just because the concept has support doesn't mean that any implementation of that concept has support, as some (though not all) of the implementation points under discussion have been sticking points in the past for adopting a recall process. I don't think another full RfC discussion is needed if a consensus is reached on the individual aspects of the recall process, but I think it would be good to have a checkpoint: describe the complete proposed process in one passage, and allow interested parties to affirm that the overall process is one they can support. As different users may have different dealbreakers, it is possible for each part to have consensus support, while the process as a whole does not. It's probably unlikely, but I feel the process will have a more solid basis behind it with a checkpoint. isaacl ( talk) 02:09, 10 May 2024 (UTC)
Editors here seem to me to be a bit too confident that this proposed recall process will address the overall concern of RfA2024: that we should find more ways to get qualified editors to become administrators, and remove unnecessary obstacles. I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not. On the other hand, I think an argument can be made that qualified candidates might decide that no one in their right mind would want to become an admin if that means being subject to the kind of recall process contemplated here, as soon as they make a tough call. Even if the process might eventually "acquit" them, they would still have to defend themselves. I think that could greatly reduce the number of new RfA candidates.
So – how would editors who support this proposal make the case for need in that regard? -- Tryptofish ( talk) 21:13, 9 May 2024 (UTC)
Re: the question of whether a recall procedure will decrease the number of admins, because fewer candidates will find it attractive to run an RfA, or increase the number, because RfA !voters will feel less reluctant to support, knowing there's a recall procedure, is something we will find out only after the proposal might be implemented, and we see what happens.
The recall procedure will decrease the number of admins, because that's all it can do. The only question is whether the recall procedure causes a small, insignificant decrease, or a larger decrease. It's sure to raise the drama level several more notches; drama surrounding admins is not healthy for RfA. –
wbm1058 (
talk) 00:42, 12 May 2024 (UTC)
I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not
– No one knows if it's really true or not until we try it. We have to try something[s], because the present system is not working well (in multiple ways). The bane of adminship reform for over a decade has been community "the sky is falling" fear-mongering about what some effect might be, based on precisely the same kind of reasonable but highly subjective guessing as those in favor of various changes. The only way to be certain is to actually try things, and keep and improve upon those that work and undo those that make things worse. PS: For what it's wroth, Tryptofish, if this RRFA stuff (in addition to the rest of the RfA overhaul, especially the diff requirement for accusations) gets set up properly, it actually gives me at least a faint incentive to run for RfA for the first time since I was a noob. (That said, I would have to think of something adminstrative I actually want to take on, and my to-do list is already over-long). PPS: It is not possible for RRFA to result in "adminship is no big deal" actually becoming true again (it can't because discretionary sanctions, now folded into
WP:CTOP procedures, provide a "Judge Dredd" operating mode for any admin who wants it, whereby they can punitively issue blocks, topic-bans, and so on, based on their own individual personal judgment not any form of consensus, even among admins). But that doesn't means RRFA has no potential to make adminship less of a big deal. —
SMcCandlish
☏
¢ 😼 02:26, 23 May 2024 (UTC); rev'd. 02:39, 23 May 2024 (UTC)
We have to try something[s]is not true: we don't have to. You believe that
the present system is not working well, such that the present system of ArbCom handling it needs to be supplemented by a new system that will handle the cases ArbCom has been failing to address. I disagree. I'm not seeing ArbCom failing to desysop the admins that have been brought before them, and I'm not seeing problem admins going around with nobody taking them to ArbCom (things that were much different about a decade ago). If anything, community sentiment has been that ArbCom might have become too efficient at removing admins, which doesn't strike me as a reason to create even more ways to remove admins. -- Tryptofish ( talk) 21:32, 23 May 2024 (UTC)
we don't really know whether there is any merit to the argument that if we have a recall procedure, there will be fewer opposes.There is merit to the argument, it's that we've seen it before - Wikipedia:Wikipedia Signpost/2012-10-22/Special report. There is no guarantee this results in fewer opposes, and you are fair to oppose recall. I just do not necessarily agree with your rest of premise. We have receipts of it causing less strife over time. We're just trying our best to emulate enough things so enWiki gets the same results. Soni ( talk) 02:11, 24 May 2024 (UTC)
I'm a little concerned about those working in areas where they inevitably make a lot of enemies. Very long complext discussion, so I apologize if I'm just not seeing this, but has someone proposed how frequently such a petition can be started? What I'm primarily concerned with is a petition failing, and someone opening a new one the next day/week/month. I kind of feel like once a year is sufficient? Valereee ( talk) 17:59, 10 May 2024 (UTC)
I've seen it mentioned a few times that admins sometimes make "unpopular but correct actions" and that recall will affect this. Can someone explain this concept? Since policy is set by global consensus, it seems that any action that is in line with consensus, that is "correct," would also be popular. What is a hypothetical example of a correct (in line with consensus) but unpopular action? Thanks, Levivich ( talk) 20:56, 26 May 2024 (UTC)
This section is intended to help narrow us down in scope first. After a few days, we'll vote for specific proposals. Tweaks to 16CPer the close, 16C is a good starting point to this process. What changes to the current wording would be sufficiently good? Soni ( talk) 15:06, 2 May 2024 (UTC)
Other RFA2024 proposalsHow would an RRFA interact with admin elections or another proposal that passed? Soni ( talk) 15:06, 2 May 2024 (UTC)
Implementation detailsAre there any implementation details an RRFA process should consider Soni ( talk) 02:48, 3 May 2024 (UTC)
ProcessIn a few days, the open discussion section will be closed for more specific votable proposals (probably 7 days or so?). Is there a preferred structure for that? Soni ( talk) 15:06, 2 May 2024 (UTC)
Proposals for other RRFA mechanismsI want to clarify that while I saw a decent amount of support for 16c, and that's why I suggested it as a starting point for this discussion, it didn't gain broad consensus in the first phase. So while tweaking the details of 16c and going with that is certainly an option, it's not the only option. Now that we know the community wants some sort of RRFA, there might be new ideas for how it could be triggered, and I think people should feel free to propose and discuss them here. I also don't see any reason why there can't be more than one triggering mechanism, if multiple proposals find consensus. – Joe ( talk) 13:00, 5 May 2024 (UTC) Voter eligibilitySo only users with Extended Confirmed (30 days + 500 edits) can cast a vote to initiate the RRFA process poll, but then anyone can vote in the actual RRFA? Am I the only one seeing the mismatch in account eligibility between the two steps? OhanaUnited Talk page 14:09, 6 May 2024 (UTC)
General Comments
|
Status as of 13:11 (UTC), Wednesday, 29 May 2024 (
)
|
Discussion about refining the implementation details of proposals from Phase I of WP:RFA2024 for community-based recall of administrators. --19:31, 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:
Considering Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16: Allow the community to initiate recall RfAs, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16c: Community recall process based on dewiki, Wikipedia:Requests for adminship/2024 review/Phase I § 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.
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.
Which of these conditions should be sufficient to compel an administrator to run an RRfA? Support more than one option if needed
Note - A rolling petition = A petition where anyone can sign, and RRFA can be triggered if there's votes in the last N days. Older signatures are handled as per #Expired signatures on initiation petitions. A non-rolling petition would be started, and then run for N days, after which it will be closed in favour of RRFA/no RRFA.
Note - The word "request" was replaced with petition for consistency with rest of the page. Rolling vs non rolling petitions was clarified further.
As written, it's a rolling window: within the last 1 year.
Should RRFA petition signatures "roll"? For example, in a rolling petition with a length of one month, each signature expires when it is a month old; in a non-rolling petition, the petition itself expires a month after it is opened. theleekycauldron ( talk • she/her) 23:47, 25 May 2024 (UTC)
What percentages of support are necessary for an administrator to pass a reconfirmation RfA?
Note - Option A stated 66.6% for a couple hours. It was altered to 65% per discussion section below.
But almost all of those would like to see a recall mechanism over none.
When is a recall petition not allowed for an admin?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
We could even say something like "Bureaucrats can disallow any RRFA that is found to be repetitive or tendentious via a crat chat. Tazerdadog ( talk) 16:50, 8 May 2024 (UTC)
Just to clarify my thinking on this (and to open myself up to rebuttal, in case people disagree): I do not like C+, because it confers an unnecessarily long period of immunity on an administrator, with no process or discussion (other than a list of signatures, which must be a short list or else the petition would have succeeded). C is a necessary evil to prohibit back-door rolling petitions, but the only other process I can think of with this kind of rerun immunity is WP:PROD, which has numerous important differences that should be obvious to anyone familiar with it (but just in case: articles are not editors, PROD is subordinate to AfD which has no such limitation, CSD is also available for simple cases, etc.). I also feel strongly that, if an admin has multiple recall petitions within a year, and it is not the result of harassment from the people filing the petitions, that fact alone is seriously concerning, and sweeping it under the rug with a blanket prohibition is not going to fix anything. It's merely going to redirect the discussion to other forums like ANI, most of which are less capable of dealing with this sort of discontent (RFAR can deal with it, but eugh, nobody wants to go to RFAR with three paragraphs of " User:Example keeps using their tools slightly wrong and reacting badly to criticism, and we tried talking to them but..."). -- N Y Kevin 02:36, 26 May 2024 (UTC)
When can eligible editors vote for a recall petition?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
Under what circumstance can a vote on a recall petition be stricken or removed? Support more than one option if needed.
Note - This section was titled 'Removing signatures' for a couple hours. It was altered to 'Striking/Removing signatures' (and the question adjusted) per discussion below. "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
Any admin (uninvolved with the user in question and admin the petition is against) may unilateraly topic ban/page block disruptive users from starting or supporting positions. This was meant to import one facet of Contentious topics, without designating all of RRFA as a CT. The idea was that if one person was constatnly opening frivolous requests, or signing in bad faith, they could be blocked from doing so without the trouble of finding consensus at WP:AN. Striking individual signatures wasn't what I was concerned about. So support A only Mach61 17:19, 8 May 2024 (UTC)
Recall petitions cannot be successfully closed without a CheckUser confirmation. Checkusers are not going to check every account (or even a significant proportion) in a recall proposal - that would be fishing, as well as probably also ineffective. If you want a checkuser to just sign off on a recall motion, then that's not going to provide the guarantee it implies, nor add much to what's already out there, IMO. Considering these two aspects it seems to me to be unnecessary to mention checkusers at all here, and there should be reference to standard sock-striking procedures (I guess that's option C). -- zzuuzz (talk) 18:53, 11 May 2024 (UTC)
After a successful Recall petition, when should an admin be desysopped?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
There should be a rule stated here that the clock pauses while the admin being recalled is under scrutiny in an active case or case request at arbcom. Arbcom should be allowed to go first to give the community the maximum amount of information. Tazerdadog ( talk) 16:56, 8 May 2024 (UTC)
I added an Option D. Option C seems ripe for abuse by a well-organized minority. Chetsford ( talk) 23:57, 8 May 2024 (UTC)
Seeing multiple editors agree with
Teratix's suggestion, it should probably be added as an option explicitly to help gauge the consensus. My suggested wording was something like *Option E: (In addition to another option) RRFAs should be started as soon as possible after a successful recall petition
.
I still think it should include some explicit leeway for editors who are around but cannot go through RRFA right away. But someone who supports the Option is better off phrasing it as they best can
Soni (
talk) 03:27, 12 May 2024 (UTC)
Should votes in a Recall petition be limited to signatures? Can they have discussion?
Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.
This type of vetting should be built on consensus and not votes.Per #Initiation procedure, most proposals we have are are using votes. There may be a case for an initiation procedure of something like "if consensus is found after a recall petition discussion", but nobody suggested it yet. Soni ( talk) 00:48, 17 May 2024 (UTC)
I don't see the need to do it differently than we do at any other discussion, e.g. RFA, RFC, AFD, etc. etc.So my reasoning for doing it differently here was because general discussion risks litigating the same matter multiple times at different locations. An admin going through recall may have to potentially respond to AN/ANI threads, recall petition and RRFA; and the same for other editors discussing the concerns. This risks the entire process getting strifed to an exceptional degree, which is the central concern I have been working against.
|
If there's any implementation details not already covered by the previous sections, please add them here.
Can an admin stand for reconfirmation via Administrator Elections?
What would the threshold be? Obviously it can't be whatever we agree on above, since there's no room for bureaucrat discretion in a pure vote. If it's just the same 70% cutoff at WP:AELECT, then there's no need to shoehorn this into the reconfirmation process: the admin should just resign and run at the next election. (In practice this will never happen as long as the reconfirmation threshold is lower.) Extraordinary Writ ( talk) 02:16, 9 May 2024 (UTC)
The summary of consensus from phase one was that the community should be able to compel an administrator to make a re-request for adminship (RRFA) was for a "Re-request for adminship" procedure that could be initiated by the community.
Thus I think the re-request procedure itself should be the same, whether it is done on the administrator's own initiative, or as a result of a petition from the community. This includes the criteria for determining if the re-request has succeeded.
isaacl (
talk) 16:51, 9 May 2024 (UTC)
What percentages of support are necessary for an administrator to pass a reconfirmation admin election?
It took me a while to realize that this isn't the same as #Reconfirmation threshold above, as this deals with Wikipedia:Administrator elections in conjunction with the question above. SWinxy ( talk) 23:11, 10 May 2024 (UTC)
When a petition is created at the Wikipedia:Admin Reconfirmation page, what notifications should be made (beside the admin's talk page)? Choose all that apply.
Other options welcome. Extraordinary Writ ( talk) 20:09, 9 May 2024 (UTC)
If other notifications are precluded with option A, it seems unduly restrictive. If no one knows about a petition, they won't be able to sign on. The decision would be made by a self-selected group of page watchers. It might be more effective to appoint a designated committee in that case. If other notifications are still permissible with option A, then there would be incentive for a "get out the vote" style campaign, which I feel would be unnecessarily divisive. isaacl ( talk) 03:13, 10 May 2024 (UTC)
The question assumes that you have to notify the admin in question. Is that actually codified anywhere, or should we create it as its own question? --
Ahecht (
TALK
PAGE) 13:55, 10 May 2024 (UTC)
If a rolling petition is used, what should be done with signatures that have "expired" because they are older than the longest rolling period (e.g. 1 year for Option A, 1 month for Options B and C, etc.)?
In order to prevent harassment and other nonsense, we should restrict how often someone can participate in initiating one of these.
To be clear, this isn't a limitation on participating in the subsequent discussion, but merely being an "initiator" as laid out in the proposals above.
I think I would prefer there be a minimum period between petitions for a given administrator. (Any serious concerns that arise during this period would have to be handled through an arbitration request.) If someone is starting petitions vexatiously, it can be handled through existing policies on collaborative behaviour. isaacl ( talk) 21:19, 27 May 2024 (UTC)
The original proposal 16c clarified that voters in an RRfA request must be extended confirmed, which is now also a requirement for voting at RfA. However, 16c didn't necessarily get "broad consensus". We might need to add a section to this page to confirm that only extended confirmed editors' votes in an RRfA request count. Toadspike ( talk) 17:04, 8 May 2024 (UTC)
By the time we get to an RRfA, there's been extensive discussion about the issues at hand and the admin has already gone through a full RfA process. Let's get rid of the "questions" process and all the baggage that goes with it. — Rhododendrites talk \\ 17:28, 8 May 2024 (UTC)
The issue at RRFA isn't "did they misuse the tools" (that's what arbcom is for), the issue at RRFA is "do they have the trust to be an admin?"). There is no thing-in-itself of adminship separately from use of the tools. If there is a lack of "trust" in someone's adminship that is somehow unrelated to misuse of the tools, then that lack of trust isn't a valid concern to begin with. Separated from any concerns over actual abuse of admin powers, this proposal aggravates the already dangerous tendency to equate adminship with some kind of social rank or esteem -- while also creating a new mechanism for removing any dissenting voices within this "trusted" group. It's difficult to overstate how disastrous that could be for the project. -- Visviva ( talk) 05:33, 10 May 2024 (UTC)
What happens to the page in the case of non-rolling petitions? Is it deleted, blanked, kept, or is the fate wholly up to the user in question? and does that vary based on whether it meets the threshold? The obvious argument for keeping is that it makes determining suffrage for petitions easier. The obvious argument against is that keeping a list of an admin's detractors is demotivating and easy to abuse. Copied from talk. Sincerely, Dilettante 18:25, 8 May 2024 (UTC)
Editors who are formulating this proposal should give some serious thought to making the case for why such a proposal is needed. After each of the survey points above has been hashed out, there will need to be a community-wide RfC on whether or not to make the proposal a policy. (Arguing that there was a consensus in Phase 1 to create some sort of proposal will be insufficient.) Are there examples of ways in which the status quo is not meeting the community's needs, that the new proposal will address? How will you answer concerns that good admins will be mistreated by the proposed process? -- Tryptofish ( talk) 00:51, 9 May 2024 (UTC)
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 current survey doesn't provide a way to evaluate "if any" procedure should be adopted. If the phase 2 discussion is modified to accommodate disagreement, then I don't feel another discussion is required. In its current form, though, a discussion on a consolidated proposal for the administrator recall process would be needed to determine consensus. isaacl ( talk) 03:07, 9 May 2024 (UTC)
I believe that there are interested parties who aren't raising objections on individual aspects, as they are letting those with strong opinions reach agreementThen those interested parties should raise the objections on the current phase, conditionally or otherwise. This proposal is not in a vacuum, and each section already has interactions with other sections currently. There are multiple supporting editors who reference other sections in their discussions, I see no reason why the same cannot be said for editors who have concerns.
I think it would be a good idea if you stepped back and let less involved parties (theleekycauldron, maybe?) manage the process of building consensusSounds good to me. I may have understood your "starting point for the discussions" comment a bit different than you intended, hence the 'Open discussion' sectioning phrased as it was.
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.There is a clear meaning to the words "if any": that it is at least possible that none of the "specific proposals" will get consensus to be adopted. Therefore, whatever is done in Phase II must include an option not to do the specific thing being proposed at all. And, as also noted above, the questions have all been formulated along the lines of "which of these options will be adopted?", without the option of "none of the above". That's a big problem! One cannot just wish it away, or ignore it.
force one of the offered options [in phase 2] to be adopted. Just because the concept has support doesn't mean that any implementation of that concept has support, as some (though not all) of the implementation points under discussion have been sticking points in the past for adopting a recall process. I don't think another full RfC discussion is needed if a consensus is reached on the individual aspects of the recall process, but I think it would be good to have a checkpoint: describe the complete proposed process in one passage, and allow interested parties to affirm that the overall process is one they can support. As different users may have different dealbreakers, it is possible for each part to have consensus support, while the process as a whole does not. It's probably unlikely, but I feel the process will have a more solid basis behind it with a checkpoint. isaacl ( talk) 02:09, 10 May 2024 (UTC)
Editors here seem to me to be a bit too confident that this proposed recall process will address the overall concern of RfA2024: that we should find more ways to get qualified editors to become administrators, and remove unnecessary obstacles. I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not. On the other hand, I think an argument can be made that qualified candidates might decide that no one in their right mind would want to become an admin if that means being subject to the kind of recall process contemplated here, as soon as they make a tough call. Even if the process might eventually "acquit" them, they would still have to defend themselves. I think that could greatly reduce the number of new RfA candidates.
So – how would editors who support this proposal make the case for need in that regard? -- Tryptofish ( talk) 21:13, 9 May 2024 (UTC)
Re: the question of whether a recall procedure will decrease the number of admins, because fewer candidates will find it attractive to run an RfA, or increase the number, because RfA !voters will feel less reluctant to support, knowing there's a recall procedure, is something we will find out only after the proposal might be implemented, and we see what happens.
The recall procedure will decrease the number of admins, because that's all it can do. The only question is whether the recall procedure causes a small, insignificant decrease, or a larger decrease. It's sure to raise the drama level several more notches; drama surrounding admins is not healthy for RfA. –
wbm1058 (
talk) 00:42, 12 May 2024 (UTC)
I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not
– No one knows if it's really true or not until we try it. We have to try something[s], because the present system is not working well (in multiple ways). The bane of adminship reform for over a decade has been community "the sky is falling" fear-mongering about what some effect might be, based on precisely the same kind of reasonable but highly subjective guessing as those in favor of various changes. The only way to be certain is to actually try things, and keep and improve upon those that work and undo those that make things worse. PS: For what it's wroth, Tryptofish, if this RRFA stuff (in addition to the rest of the RfA overhaul, especially the diff requirement for accusations) gets set up properly, it actually gives me at least a faint incentive to run for RfA for the first time since I was a noob. (That said, I would have to think of something adminstrative I actually want to take on, and my to-do list is already over-long). PPS: It is not possible for RRFA to result in "adminship is no big deal" actually becoming true again (it can't because discretionary sanctions, now folded into
WP:CTOP procedures, provide a "Judge Dredd" operating mode for any admin who wants it, whereby they can punitively issue blocks, topic-bans, and so on, based on their own individual personal judgment not any form of consensus, even among admins). But that doesn't means RRFA has no potential to make adminship less of a big deal. —
SMcCandlish
☏
¢ 😼 02:26, 23 May 2024 (UTC); rev'd. 02:39, 23 May 2024 (UTC)
We have to try something[s]is not true: we don't have to. You believe that
the present system is not working well, such that the present system of ArbCom handling it needs to be supplemented by a new system that will handle the cases ArbCom has been failing to address. I disagree. I'm not seeing ArbCom failing to desysop the admins that have been brought before them, and I'm not seeing problem admins going around with nobody taking them to ArbCom (things that were much different about a decade ago). If anything, community sentiment has been that ArbCom might have become too efficient at removing admins, which doesn't strike me as a reason to create even more ways to remove admins. -- Tryptofish ( talk) 21:32, 23 May 2024 (UTC)
we don't really know whether there is any merit to the argument that if we have a recall procedure, there will be fewer opposes.There is merit to the argument, it's that we've seen it before - Wikipedia:Wikipedia Signpost/2012-10-22/Special report. There is no guarantee this results in fewer opposes, and you are fair to oppose recall. I just do not necessarily agree with your rest of premise. We have receipts of it causing less strife over time. We're just trying our best to emulate enough things so enWiki gets the same results. Soni ( talk) 02:11, 24 May 2024 (UTC)
I'm a little concerned about those working in areas where they inevitably make a lot of enemies. Very long complext discussion, so I apologize if I'm just not seeing this, but has someone proposed how frequently such a petition can be started? What I'm primarily concerned with is a petition failing, and someone opening a new one the next day/week/month. I kind of feel like once a year is sufficient? Valereee ( talk) 17:59, 10 May 2024 (UTC)
I've seen it mentioned a few times that admins sometimes make "unpopular but correct actions" and that recall will affect this. Can someone explain this concept? Since policy is set by global consensus, it seems that any action that is in line with consensus, that is "correct," would also be popular. What is a hypothetical example of a correct (in line with consensus) but unpopular action? Thanks, Levivich ( talk) 20:56, 26 May 2024 (UTC)
This section is intended to help narrow us down in scope first. After a few days, we'll vote for specific proposals. Tweaks to 16CPer the close, 16C is a good starting point to this process. What changes to the current wording would be sufficiently good? Soni ( talk) 15:06, 2 May 2024 (UTC)
Other RFA2024 proposalsHow would an RRFA interact with admin elections or another proposal that passed? Soni ( talk) 15:06, 2 May 2024 (UTC)
Implementation detailsAre there any implementation details an RRFA process should consider Soni ( talk) 02:48, 3 May 2024 (UTC)
ProcessIn a few days, the open discussion section will be closed for more specific votable proposals (probably 7 days or so?). Is there a preferred structure for that? Soni ( talk) 15:06, 2 May 2024 (UTC)
Proposals for other RRFA mechanismsI want to clarify that while I saw a decent amount of support for 16c, and that's why I suggested it as a starting point for this discussion, it didn't gain broad consensus in the first phase. So while tweaking the details of 16c and going with that is certainly an option, it's not the only option. Now that we know the community wants some sort of RRFA, there might be new ideas for how it could be triggered, and I think people should feel free to propose and discuss them here. I also don't see any reason why there can't be more than one triggering mechanism, if multiple proposals find consensus. – Joe ( talk) 13:00, 5 May 2024 (UTC) Voter eligibilitySo only users with Extended Confirmed (30 days + 500 edits) can cast a vote to initiate the RRFA process poll, but then anyone can vote in the actual RRFA? Am I the only one seeing the mismatch in account eligibility between the two steps? OhanaUnited Talk page 14:09, 6 May 2024 (UTC)
General Comments
|