Wikipedia talk:Requests for adminship/2021 review/Proposals

• I generally agree with Ravenswing. The mobocracy that is RFA is the job interview from hell. Anyone can turn up, even at the last minute, and ask any question on any subject, potentially completely derailing an RFA. This is more like what politicians are exposed to, not someone being asked to fulfil an administrative role. This imo is the main factor discouraging potential candidates. An appointments board would be much saner. It would be clear from the outset what was required from candidates and the process would be much less dramatic. The appointments board would have to be elected of course, but that's a much smaller cohort.

Instead of addressing this central issue, most of the proposals are addressing something else entirely. They are addressing what to do about potential admin bad behaviour or decisions. That is just way off-topic here and will not solve the problem. In fact, it is a further example of mobocracy. The community mob are not really interested in encouraging more admins. In fact they view admins as dangerous who need to be kept under control. They would be happier with fewer admins, not more of them. SpinningSpark 18:24, 7 November 2021 (UTC)[reply]

Well you could have made your own proposal. Instead you've ... voted against 14 different proposals. That'll mix things up for sure! --JBL (talk) 01:42, 8 November 2021 (UTC)[reply]

The proposal was made as stated earlier in the thread, but did not make it to the voting stage. So of course I'm going to vote against everything because I can't vote for the one thing that will fix this problem. SpinningSpark 16:22, 8 November 2021 (UTC)[reply]

I think if everyone decides to only vote for their preferred solution, we will never achieve consensus on something. It's why I've personally abstained on some proposals I think are meaningful although give me some pause. I'd also be happy to support multiple different directions, as long as the directions are decent, in the hope that at least one will achieve consensus. I think voting oppose on everything but a preferred solution is how we create deadlocks and end up stuck with the status quo we know doesn't work. ProcrastinatingReader (talk) 17:48, 8 November 2021 (UTC)[reply]

The rationale for proposals making it easier to censure/desysop admins is that editors would no longer have such high standards at RfA, as the consequences of a poor promotion would be perceived as less consequential. Perhaps there would be less incentive to search out a candidate's mistakes as well, but some level of that is probably inevitable due to human nature, regardless of what system is used. Sunrise (talk) 01:57, 8 November 2021 (UTC)[reply]

I understand the rationale, I just don't believe that's how it will work out. Historically, admins have been put under greater and greater scrutiny over the years. People who have a poor opinion of admins will continue to go through histories with a fine toothcomb no matter what. SpinningSpark 16:22, 8 November 2021 (UTC)[reply]

• Broadly agree with Ravenswing, my only possible disagreement being that it should be made clear that whatever body appoints the admins should be democratically elected (or at least appointed by a democratically elected body). As I've already said elsewhere, simply giving admins the power to choose other admins is a bad idea, and creates the kind of self-perpetuating corrupt elites that are even more characteristic of dictatorships than of our existing (inevitable somewhat flawed) democracies. (And quite likely one gets the same effect when roughly the same 200 or so voters elect admins, even without the kind of rigged voting system we've had to use here). But in real democracies (all of which are of course somewhat flawed, because human nature is somewhat flawed) we don't elect individual low-ranking police officers either, especially not with the kind of rigged voting system understandably used here in order to try not to discourage people from applying to be admins (no secret voting, no right to criticize anonymously but with civility, no right to oppose without giving a reason, etc, all of which is why I rarely take part in RFAs, and why proper democracies don't have this kind of rigged voting system). The solution would seem to be to elect a body that appoints admins, just as we do with the appointment of low-ranking police officers in the real world. The question would then be whether we should use our current elected body (Arbcom) or a new elected body, but that's a question for another day. Tlhslobus (talk) 18:34, 8 November 2021 (UTC)[reply]

Hopefully it's a question for another era. Some misconceptions needs to be dispelled. Admins are NOT leaders. They are community selected editors with tools, extra rights and sensitive responsibilities. They don't lead - they follow the community. Same with Arbcom - selected by the community to deal with challenging editorial behavior. We need to get away from Admin as a promotion and Admin - 'Crat - Arbcom as a defacto hierarchy to be aspired to. Leaky caldron (talk) 20:47, 8 November 2021 (UTC)[reply]

Well ... my rebuttal is basic: what exactly do admins DO that there'd be any legitimate worry of a "self-perpetuating corrupt elite?" Admins have no more say in the creation of policy than any other editor, I can't see that there's an "admin outlook" on things all that different from most editors, there are many editors out there watchful (indeed, sometimes overwatchful) of bungling, and we should put this in perspective: we're talking admin tasks on Wikipedia, not governing the finance or energy ministries of a nation-state. Not that your average RfA doesn't give the impression that a lot of editors don't view the mop as being just that important and dangerous. I'd honestly be pretty comfortable with RfA voting being restricted to admins. Ravenswing 17:44, 9 November 2021 (UTC)[reply]

I wouldn't. Put the idea to the test - ask the community. Leaky caldron (talk) 18:08, 9 November 2021 (UTC)[reply]

What admins do (among other things) is try to enforce policy as they see fit, often by punishing actual or alleged transgressors. In effect they are our police force (and to some extent our judges and prison officers as well). And, human nature being what it is, any force that has power over others will tend to abuse that power, with the abuse tending to be worse if those at the bottom have no say in the matter. That is largely why democracy was invented, and why democratic control of any proposed appointing body seems essential, at least to me. But I'm a bit surprised that you seem to be rebutting a person (and perhaps people) who seem to be broadly agreeing with most of what you at least appeared to be originally saying (after all, I have agreed with you that we should not be electing individual admins; I just want us to have direct or indirect democratic control over the appointing body, as happens in every normal democracy). Tlhslobus (talk) 18:55, 9 November 2021 (UTC)[reply]

I wanted to ask why the TOC is limited to two levels and the proposals are listed in the box like "1B 1C 2A"? I have no idea what proposal 1B or 2A is. (Similar with references to "issue 1", "issue 2", etc. Can we just use descriptive names so I don't have to keep consulting an index?) I'm trying to find the "quarterly election" proposal but it's not linked at all on the top of the page (have to use ctrl+f instead, which isn't how we should have to find sections). This page is totally impossible to use on mobile, but it's also very hard to navigate on desktop. Am I the only one? Anyone else prefer a normal TOC? Levivich 15:24, 3 November 2021 (UTC)[reply]

• I have removed the TOC limits; it is larger than normal, but not unwieldy; I have decided to compromise and omit the "support" and "oppose" sections from it. While new proposals may come before the 7th, I think most proposals are already present. – John M Wolfson (talk • contribs) 15:35, 3 November 2021 (UTC)[reply]

Instead of sortition for candidates, sortition could pick the voters. Twice per year, a pool of 20 selectors is chosen from a pool of volunteer Extended-Confirmed editors. A cohort of candidates may nominate themselves for adminship. The selectors assess and vote on each of the candidates. Candidates who receive 14 positive votes become admins. I'm not sure I actually like the idea (and there are quite a few moving parts to get right), but I do think that if "sortition" is viewed as a solution that is what the proposal should be. By having fewer voters, the sense of scrutiny should be decreased. User:力 (powera, π, ν) 23:42, 3 November 2021 (UTC)[reply]

I've de-watchlisted this page so ping me if you really need my input. User:力 (powera, π, ν) 23:42, 3 November 2021 (UTC)[reply]

• This suffers from the same problems as any "appointment board" idea, but as those ideas go this isn't a particularly bad one. – John M Wolfson (talk • contribs) 00:03, 4 November 2021 (UTC)[reply]

Huh... That could actually work. @

☖ 04:09, 4 November 2021 (UTC)[reply

]

The idea is any extended confirmed editor is eligible; the only activity check (at least until problems are pointed out) is "were you active enough to volunteer for that specific election". Presumably editors would sign up at the same time (and choose between) for the "running for admin" cohort and the "eligible to be selected as voter" list. I did notice one other detail: the voting should probably have 13 or 14 votes be a "discretionary zone" to avoid the situation where the last voter determines on their own whether an editor gets the bit. User:力 (powera, π, ν) 04:31, 4 November 2021 (UTC)[reply]

@MJL: I'm not going to propose this. I think 8B is better at addressing the issue. User:力 (powera, π, ν) 21:01, 5 November 2021 (UTC)[reply]

@

☖ 03:59, 6 November 2021 (UTC)[reply

]

• Yes; that would, I believe, go under Issue 2. – John M Wolfson (talk • contribs) 16:48, 5 November 2021 (UTC)[reply]

  Courtesy ping for @

  Scorpions13256. Best, Barkeep49 (talk) 17:02, 5 November 2021 (UTC)[reply

  ]

@Barkeep49: the third "Introduction and format" paragraph reads a bit oddly now it's been changed a few times, and it's also got a bit mixed up in tenses. Can I suggest this as the simplest phrasing:

To attempt to ensure the most editors possible could supply feedback for ideas, for 7 days prior to the start of Phase 2 and during the first 7 days of the 30 day discussion period, editors could propose changes, and no votes were allowed before the discussion period. Now these periods have closed, new ideas suggested will be moved to the talk page. To help editors navigate proposals, proposed changes are grouped according to the main issue they are addressing.

— Bilorv (talk) 17:52, 7 November 2021 (UTC)[reply]

@Bilorv  Done. Best, Barkeep49 (talk) 17:59, 7 November 2021 (UTC)[reply]

Assuming I'm not busy, sure. Primefac (talk) 21:24, 7 November 2021 (UTC)[reply]

Just as an update, as we are to close very soon, is there anyone else (uninvolved) who would also like to form a closing committee? Are you still up for this Primefac? Best Wishes, Lee Vilenski ^{(talk • contribs)} 12:07, 29 November 2021 (UTC)[reply]

Per my general feelings on panels, I think this could be closed by a single qualified person, but do think this is one of the few times e where there is enhanced legitimacy by having more than one closer and am very appreciative of the work Primefac and Wugs did for Phase 1. Best, Barkeep49 (talk) 19:46, 29 November 2021 (UTC)[reply]

I have done a (very) quick skim and concur with your assessment; many of the discussions are in fairly "clear consensus" territory with only a handful needing a deep dive. While extra assistance is always appreciated, I do not think it will be unmanageable to close this myself should it become necessary to do so. Primefac (talk) 12:10, 30 November 2021 (UTC)[reply]

Still acting under the assumption that I am not busy, sure. Primefac (talk) 12:10, 30 November 2021 (UTC)[reply]

@Primefac @Lee Vilenski with the RfC tag having been removed by Legobot, you can decide if you'd like to put a closing template up or if you'd like to allow further discussion as you explore your close. Best, Barkeep49 (talk) 16:06, 30 November 2021 (UTC)[reply]

It might be worth holding off on closure for a few more days: there's been a big spike in participation lately (probably due to the Signpost coverage?) and it would be a shame if we missed out on further comments. While 30 days is a good guidepost, it shouldn't be observed religiously, particularly when the discussion isn't yet stale. Extraordinary Writ (talk) 20:36, 30 November 2021 (UTC)[reply]

I'm pretty easy on this, but I don't really want to hold up the next stage of discussion just to retain a conversation on things that aren't going to pass at this time. With the agreement of Primefac, I think it's suitable to close the items that aren't very likely to be retained even with a day or two extra discussion. Best Wishes, Lee Vilenski ^{(talk • contribs)} 09:35, 1 December 2021 (UTC)[reply]

I just closed two that obviously did not achieve consensus, and obviously weren't going to; there are several more of those. --JBL (talk) 17:05, 1 December 2021 (UTC)[reply]

Do you still need closers? I have not touched the RfC (and did not read it to be honest), I can help but probably not before the weekend.--Ymblanter (talk) 17:14, 1 December 2021 (UTC)[reply]

To RfC participants who are evaluating consensus for indvidual proposals: I appreciate you feel you are determining the consensus views for obvious scenarios. All the same, personally I think it would be better to wait for non-participants to evaluate consensus. Given there is no immediate urgency, I feel showing patience helps establish a more collegiate atmosphere for the next steps going forward. isaacl (talk) 23:11, 2 December 2021 (UTC)[reply]

• @Lee Vilenski and Primefac: I see that Primefac started closing specific proposals, and I will also do some. I suggest that we individually close the obviousl cases, and come with a joint statement for the whole RfC, as well as (if needed) for non-trivial specific proposals.--Ymblanter (talk) 09:31, 3 December 2021 (UTC)[reply]

  To copy it from the topic below, there are three open discussions 6C, 6E, and 8B. I suggest that we read them and then exchange opinions about the closing. I am likely out (busy at work) for the next seven-eight hours.--Ymblanter (talk) 09:55, 3 December 2021 (UTC)[reply]

  Works for me. Primefac (talk) 10:07, 3 December 2021 (UTC)[reply]

  I think 6C needs a collective close indeed. Have not read the other two yet, will try to read through them tomorrow.--Ymblanter (talk) 23:27, 3 December 2021 (UTC)[reply]

  6E is on the edge but is probably also best closed collectively.--Ymblanter (talk) 22:37, 4 December 2021 (UTC)[reply]

  And 8B has obvious issues as well. @Lee Vilenski and Primefac: Should we open an e-mail thread and discuss them one by one?--Ymblanter (talk) 20:11, 6 December 2021 (UTC)[reply]

  Yeah, shoot us an email. Primefac (talk) 11:45, 7 December 2021 (UTC)[reply]

  Indeed. Best Wishes, Lee Vilenski ^{(talk • contribs)} 13:01, 7 December 2021 (UTC)[reply]

• We have closed all specific proposals, but will take time to consider whether closing the whole RfC needs a separate (non-trivial) statement.--Ymblanter (talk) 16:40, 14 December 2021 (UTC)[reply]

  Now, good luck with this one.(Personal opinion, not discussed with Primefac or Lee Vilenski)--Ymblanter (talk) 06:32, 24 December 2021 (UTC)[reply]

Observation: Reading the whole page, each support, oppose, and discussion, I see some signs of a corrosive culture. I think the issues might be greater than the RfA process. Cultural change is hard. —¿philoserf? (talk) 17:25, 7 November 2021 (UTC)[reply]

• Also, the RFC is about how to change the rules, but changing the culture and changing the rules are two entirely unrelated phenomena. Marcocapelle (talk) 07:13, 8 November 2021 (UTC)[reply]
  • Surely not entirely unrelated -- existing rules inform culture, and existing culture informs rules. --JBL (talk) 14:41, 8 November 2021 (UTC)[reply]

  I borrowed the word from here: Wikipedia:Requests for adminship/2021 review/Proposals#Issue 1: Corrosive RfA atmosphere —¿philoserf? (talk) 20:20, 10 November 2021 (UTC)[reply]

The following proposal was removed by Chicdat as being posted after the period for new proposals. I guess Chicdat felt it would be appropriate to preserve it here. --JBL (talk) 14:40, 8 November 2021 (UTC)[reply]

6F Fixed limited term with mandatory follow-up desysop period (optional)

Rather than having a probationary term, I suggest the following for new admins to get back to "not a big deal" and not something that permanently creates a two-class system:

1) Editor runs an RfA, (however we decide that is to be done after this RfC) but declaring this option up front.

2) If editor is selected for admin bit, they are given full admin rights for six months upon closure.

3) Upon six months expiry of admin bit, the editor is desysop'ed automatically, and forbidden from holding admin privileges for a further six months.

4) One year after initially getting the admin bit under this scheme and six months after desysop, an editor is free to run for RfA again, under whatever options, (this, traditional appointment for life, or any other option)

This might appeal to some editors, to others it might not. The community doesn't have to worry about privileges-for-life-unless-revoked-for-cause. Editors who have been great editors but hate adminning don't have to stick with it. Editors who suck at adminning and realize this simply never run again, or don't realize it and aren't selected if they do run again. Jclemens (talk) 05:40, 8 November 2021 (UTC)[reply]

Support 6F Fixed limited term with mandatory follow-up desysop period (optional)

1. As proposer. Jclemens (talk) 05:40, 8 November 2021 (UTC)[reply]

Oppose 6F Fixed limited term with mandatory follow-up desysop period (optional)

Discuss 6F Fixed limited term with mandatory follow-up desysop period (optional)

@Jclemens: This differs substantively from 6E only in the presence of a mandatory 6-months-of-not-being-an-admin-after-being-an-admin-temporarily period, but your comments do not indicate what the advantage of that specific change is supposed to be (everything concrete you say about this proposal already applies to 6E). Could you either articulate a case for a mandatory cool-off period of 6 months, or else withdraw this and support 6E instead? --JBL (talk) 10:59, 8 November 2021 (UTC)[reply]

Agreed. I don't understand the point of revoking the tools for six months. Seems like just long enough to forget anything they learned while having the tools.

talk) 18:32, 8 November 2021 (UTC)[reply

]

The point is to encourage admins to function as non-admins. The project is not served well by admins who forget what it's like to be a non-admin. This would eventually be part of a move to include encouraged, perhaps eventually mandatory, admin sabbaticals, to blur the lines and mix up the division between "has-the-tools" and "has no tools" classes. Jclemens (talk) 18:57, 8 November 2021 (UTC)[reply]

Not seeing how this would make it more likely to attract candidates for RFA, or voters to RFA. This is an example of admin tool reform, not RFA reform. The purpose of this exercise is to get more people to run for adminship, not to reform the admin tool set. People need to stop conflating the two; you're certainly not alone in that. Risker (talk) 19:03, 8 November 2021 (UTC)[reply]

• Concurring with Risker, this original reform project as begun by Barkeep49 has become so blurred and sidetracked that I have a growing sense of doom that the participation overall is so thinly spread among the many proposals and the low number of participants (140) that none of the results of the single issues under discussion will be a representative quorum of the community. Indeed, the average RfA itself has a higher participation. Important policy issues need important participation, not in the dozens, but in the hundreds. Kudpung กุดผึ้ง (talk) 20:35, 8 November 2021 (UTC)[reply]

Yeah, I discuss this problem in my

talk) 21:02, 8 November 2021 (UTC)[reply

]

To the above critiques, the goal is to stop electing Admins for life, let people step into the role for an intentionally limited duration, and thus have far less tolerance for the high-stakes scrutiny and follow-up contribution proctoscopy. Is RfA currently a place where people can say "Sure, why not?" without seeming irresponsible? Whether or not this could change that, that's the idea behind it. Jclemens (talk) 21:36, 8 November 2021 (UTC)[reply]

What you're saying is that you don't like the current removal process. You have zero reason to think that the "RFA regulars" would stop carrying out the proctoscopy, and in fact I'm quite sure they will. Your "solution" is essentially for people to go through the same process with the guarantee that if they like the job, they'll have to do it again and again. I do wish people would stop their utopian thinking. Risker (talk) 22:13, 8 November 2021 (UTC)[reply]

I'm sorry if I gave the impression that I thought this timing/rotation proposed change, in isolation, would solve everything. Rather, I think in combination with several of the other ideas, it might make a meaningful, positive cultural change. I've got to chuckle a bit at the "utopian thinking" comment--thanks for the compliment, but I'm still far too cynical for that. I mean, even talking about drastic change in private can have deleterious effects on one's Wikipedia career, as you saw me discover the hard way. Jclemens (talk) 22:47, 8 November 2021 (UTC)[reply]

I've been trying to keep an eye on this process but the notified part seemed to go immediately from "list the problems" to "we've listed the only solution ideas that are open for discussion" Or is the process till open for ideas? Sincerely, North8000 (talk) 22:26, 8 November 2021 (UTC)[reply]

@

WP:RFA2021). I had also created a mass message list but it seems you didn't make it on there. I am sorry you missed this as it was my intent to try to advertise widely while saving the watchlist notice for when things would be stable enough for other editors to weigh in. Best, Barkeep49 (talk) 23:02, 8 November 2021 (UTC)[reply

]

I suppose for future big discussions like this, "brainstorming" could be a numbered phase. Not like it would help much, just a tweak. Enterprisey (talk!) 02:43, 9 November 2021 (UTC)[reply]

@Barkeep49: I'm not sure if I misunderstood the above but one note....good to identify a "submit & develop proposals" phase which is different than brainstorming. Also it needs to be longer; developing & refining good proposals IMO is the most important and difficult part of the process. Regardless, I have to say it anyway. One of the two biggest fixes (the other being bifurcation and there's not even a viable proposal on that) would be to provide some structure to RFA. Decide on the key qualities needed for admin and encourage responses to comment on the strength of the candidate in those areas. Much better than the current random-walk discussion with the mob. And a little fix would be to emphasize that one can volunteer/self nominate. Right now it has the appearance of an unwritten rule that you need to get a prominent person to nominate and vouch for them. Sincerely, North8000 (talk) 15:03, 9 November 2021 (UTC)[reply]

That approach was talked about in various ways both during Phase 1 and Brainstorming and even had a form of it here as a proposal. A comprehensive review of a topic like RfA is always going to be tricky. As I indicated in a reply to Kudpung after this is all over I will have thoughts to share about the process, including what I'd done differently had I known more. That said one of the reasons I launched this is because both the issues and solutions had been talked about repeatedly for several years. It did not feel like the conversation was progressing in any meaningful way through abstract discussion - lots of editors had their pet theory about what was wrong with RfA and/or what RfA needed to be fixed. The idea with this process was to provide a predictable and fair way to find out what the issues where and then which solutions had consensus on fixing them. In the end this process will have begun in late August and wrap-up sometime in early December. I made a judgement call that the Brainstorming phase was facing decreasing marginal utility - indeed there were suggestions post-Eostrix that the whole process should be scrapped something I think subsequent discussions have proven would have been an over-reaction - and we were ready to proceed to concrete proposals. In a multi-month process, building off of years of discussions, there's always going to be a balance between having a process that allows enough time to adequately and fully do the work and one where people drop out over frustrations of nothing happening or just because they lose interest. Best, Barkeep49 (talk) 16:09, 9 November 2021 (UTC)[reply]

Thanks for your work on this! Sincerely, North8000 (talk) 16:12, 9 November 2021 (UTC)[reply]

Yeah, the idea of weighing the qualities desired in an administrator got even less attention than when I proposed it in 2015. It's an approach that would probably gain more favour if a nominating or appointment committee were put in place, as that would basically mirror what's done in organizations everywhere. isaacl (talk) 16:23, 9 November 2021 (UTC)[reply]

There's two degrees of doing that. The more extreme one (and thus less likely to get support) would be to make the decision based on judgment per those criteria. I was positing a milder form, which is to list some of those points and encourage responses to comment on those. North8000 (talk) 18:44, 10 November 2021 (UTC)[reply]

Perhaps some of the regular RfA commenters would be willing to set an example by formatting their comments as, say, a standard checklist of characteristics with their evaluation of each one? Maybe it'll then catch on. isaacl (talk) 21:48, 10 November 2021 (UTC)[reply]

An idea for a revived WikiProject Admin Nominators, or for anyone who is seeking administrator candidates: get some of your prospective candidates to write their own nomination statements, to show by example that this is a viable option. isaacl (talk) 16:18, 9 November 2021 (UTC)[reply]

There are a number of withdrawn or closed proposals; could you either add strike-through < s > ... < /s > or have something like "(closed)" appended to the top-level heading for those sections, to aid navigation using the ToC to active discussions? --JBL (talk) 12:16, 10 November 2021 (UTC)[reply]

@JayBeeEll  Done. Best, Barkeep49 (talk) 17:42, 10 November 2021 (UTC)[reply]

Why are 4A and 4D relating to sortition not closed? Neither has received more support than opposition, either numerically or by weight of argument. Leaky caldron (talk) 08:34, 12 November 2021 (UTC)[reply]

When I closed some last Sunday I just closed those with more than 2/1 opposition at that time. Given that there was going to be a watchlist notice I had some thinking that consensus could change from that group of people. The two sortition ones didn't qualify (well maybe 4D did but it also hadn't been open long). At this point the overwhelming majority of people who are going to participate have at least made 1 edit and so I don't know how much benefit there is to closing. But if there's some sense that it should happen I can do another pass for SNOW. Best, Barkeep49 (talk) 20:27, 12 November 2021 (UTC)[reply]

This issue has been discussed many times: on many instances editors comment under neutral section something similar to "I am currently busy, I will look into the candidate, and vote later". Neutral section is not a placeholder place. Maybe we should add something in invisible comment? ^{Or maybe we should rename the section to "suppose"? (portmanteau of support+oppose) /end humour.} —usernamekiran • sign the guestbook • (talk) 19:58, 18 November 2021 (UTC)[reply]

While certainly not the most pressing issue, I have long found such comments to be useless self-important noise of no value.

talk) 02:02, 19 November 2021 (UTC)[reply

]

yeah, I find them annoying. —usernamekiran • sign the guestbook • (talk) 04:53, 19 November 2021 (UTC)[reply]

Very! Leaky caldron (talk) 07:59, 19 November 2021 (UTC)[reply]

At Wikipedia:Requests_for_adminship/2021_review/Proposals#5A_Revise_standard_Question_1, which clearly is going to pass, in the Discussion section the question was raised of what to do with opposes for "no need", and WereSpielChequers asks that if the community is intending crats to ignore such opposes, we make that clear. Is it possible to add a new sub-proposal, or do we need to deal with that detail subsequently? —valereee (talk) 16:23, 19 November 2021 (UTC)[reply]

There is already a community consensus that no need for tools opposes is a poor reason. I would hope crats, who are trusted to be skilled evaluators of discussions, could apply that consensus appropriately. Further discussion or BOLD editing to document the consensuses reached during this process does, of course, seem helpful and normal. Best, Barkeep49 (talk) 16:42, 19 November 2021 (UTC)[reply]

A leading question on which my views are conflicting: if "no need for the tools" is a bad reason to oppose at RfA, why is it a good reason to decline at (all areas of)

WP:PERM? — Bilorv (talk) 12:57, 28 November 2021 (UTC)[reply

]

@Bilorv: we're probably in the wrong venue for this, but I'd say the primary difference is that PERM is actually driven by need more than anything else. The bar for entry is much lower, and things like trial periods are often used. Some of those tools can be disruptive, so a large part of the review is "can you use this without breaking things" not just "are you trustworthy enough to use this according to policy". For RfA there is an implicit "are you trustworthy enough to not try to use tools that you don't understand" part of the trust review, as admins get such a large tool box. — xaosflux ^Talk 20:02, 28 November 2021 (UTC)[reply]

• This does generally seem to be a "poor reason" to oppose, and a reference to the identified issues (e.g. Wikipedia:Requests_for_adminship/2021_review/Issues#O) should probably be part of the closure of this RfC. That being said, literal opposes of "Oppose - no need for the tools" are quite uncommon, and I know I would already consider them less helpful to the consensus gathering process. Unless, this concern was explicitly developed elsewhere in the discussion (such as a fanciful candidate who ran on a position of something like "Why are you interested in becoming an administrator? :: Because I want the prestige of saying I'm an administrator here, I have no intention of ever helping in any administrative areas"). — xaosflux ^Talk 19:53, 28 November 2021 (UTC)[reply]

  Crap, now I gotta rewrite my answer to Q1. Levivich 03:09, 29 November 2021 (UTC)[reply]

I've just found out about this process now, because it was mentioned in the Signpost. I had no idea anything like this was going on, yet it seems fully-fledged proposals are already being aired. Please can we put this in a watchlist notice so that everyone in the community has their chance to air their views?  — Amakuru (talk) 09:33, 29 November 2021 (UTC)[reply]

It's due to end tomorrow, so it's probably too late for a watchlist notice. It has been listed at

WP:CENT for three months. – Joe (talk) 09:40, 29 November 2021 (UTC)[reply

]

There was a watchlist notice from November 7 to November 15. Rummskartoffel 10:11, 29 November 2021 (UTC)[reply]

People are always discussing ways of reforming RfA. See WP:PERENNIAL. Andrew🐉(talk) 11:01, 29 November 2021 (UTC)[reply]

Well yes, and 99 times out of 100 it never comes to anything so although I should have been paying attention, I hadn't really clocked that anything was going on. Yet here we are on the verge of scrapping the existing RFA altogether, yet there's been no specific mention of that on the watchlist, just a generic message that was gone inside a week and I had to find out via the Signpost. If I'm the only one who's not known about this, then that's fine - it's not like I'm going to sway any of this process either way by myself, but I do worry that others may not be aware of this either.  — Amakuru (talk) 11:06, 29 November 2021 (UTC)[reply]

Are we "... on the verge of scrapping the existing RFA altogether ..."? I assume you're referring to 8B, the admin elections suggestion, but that is clearly marked as "complementary" to to the existing process. Worm^TT(talk) 11:42, 29 November 2021 (UTC)[reply]

There will always be people who feel left out of discussions like this, but with a three-month schedule set out in advance,

WT:RFA,[8] and a watchlist notice that ran for a full week, I think Barkeep49 has done as much as anyone can to make sure this RfC gets wide participation. – Joe (talk) 12:02, 29 November 2021 (UTC)[reply

]

In addition to what Joe notes, I'll also say that I put together an update list for people to be notified and that this is the third consecutive month the Signpost has covered it[9][10] (thanks to

Mikehawk10 for that unsolicited coverage). Widespread participation was always my hope with this process and I'm glad you found your way here now. Best, Barkeep49 (talk) 20:23, 29 November 2021 (UTC)[reply

]

There seems to have been a surge of interest after the recent Signpost article, so perhaps closing it a few days late would be appropriate? Espresso Addict (talk) 22:09, 30 November 2021 (UTC)[reply]

Quick suggestion. Maybe put the close date at the top of the page. I skimmed the top and was unable to determine the date confidently. Nov 30? Dec 7? Closing at an exact time or flexible on the time? Thanks. –Novem Linguae (talk) 13:18, 2 December 2021 (UTC)[reply]

• I'm "closing" it right now; people had enough time to know about this and put down any appropriate concerns, and somewhat importantly I don't believe any eleventh-hour extensions will materially affect any outcomes. – John M Wolfson (talk • contribs) 19:26, 2 December 2021 (UTC)[reply]

  Although I agree there isn't much long-term effect to closing discussion (after all, people can keep discussing elsewhere), I think it would have been better for someone who didn't participate in the RfC to close it. isaacl (talk) 20:53, 2 December 2021 (UTC)[reply]

  I agree with an immediate close, but I am a bit confused at how

  WP:INVOLVED problem. These aren't just discussions—there's several major proposals we can start implementing if they pass. I thought Barkeep49 found some prospective closers at #Update: End of Proposal Period & Closers, above. When one of them starts reading the discussion to deliberate on outcomes, that would be the time to mark with {{Closing}} and temporarily fully-protect the page. — Bilorv (talk) 21:23, 2 December 2021 (UTC)[reply

  ]

  Yes, my understanding was that uninvolved closers would be responsible for that as well. What's going on? Trainsandotherthings (talk) 21:35, 2 December 2021 (UTC)[reply]

  There are 3 editors who've volunteer to help close and who are uninvolved in this process. Ultimately I think closing the discussion was the right decision but felt it best for one of the closers to make that call which is why I pinged the (then 2) closers when the tag was removed so they could make a decision. By their inaction and Lee's subsequent comment it seems that they felt some additional commentary was OK. This kind of judgement is probably helped by their being completely uninvolved which, while agreeing on substance with him, think @John M Wolfson was not the right editor to have done it (just as I was also not the right editor). Best, Barkeep49 (talk) 21:36, 2 December 2021 (UTC)[reply]

  For convenience I was a bit reductionist in my statement. Although there is at least one proposal I can think of where consensus will have to be weighed closely, personally I don't feel that the trickle of opinions being made at present will significantly alter this determination. But on the other hand, since the discussion lacks acrimony, I don't see any upside in someone other than Barkeep49 or the closer(s) in closing the entire RfC. isaacl (talk) 21:40, 2 December 2021 (UTC)[reply]

  @Isaacl:, @Bilorv: and @Barkeep49: You're all right and I agree that John M Wolfson did not actually close the discussion, they had only placed a closure header in good faith so as to prevent any more new !votes because the scheduled time for this RfC has already ended. Since, this is a very important community wide RfC impacting Wikipedia, I have therefore removed closure template and would welcome uninvolved editor/s to close it as per the procedure. TheGeneralUser (talk) 21:47, 2 December 2021 (UTC)[reply]

  It seems I was perhaps the only one to misunderstood the situation, but I thought John M Wolfson's comment meant that they had marked the discussion with {{Closing}} and were just about to close each discussion with rationales. So were I an admin planning to close the discussion, I would have seen somebody else was doing it and walked on. Anyway, I still think my comment above stands and removal of the tag was best. — Bilorv (talk) 21:56, 2 December 2021 (UTC)[reply]

I apologize for any miscommunication. I have no intention of actually determining consensus in the discussions given my !votes therein, I simply put the "closing in progress" template to stop further !votes given the timing issues. The three volunteers may start analyzing the results at their earliest convenience, and have my utmost gratitude in that job – John M Wolfson (talk • contribs) 22:14, 2 December 2021 (UTC)[reply]

@John M Wolfson: That is exactly how I read your update. —¿philoserf? (talk) 22:35, 2 December 2021 (UTC)[reply]

Again, I don't think it's a good idea for a participant to close discussion, and since Barkeep49 asked the closers to exercise their judgment, I think they should decide when they want to do it. isaacl (talk) 22:39, 2 December 2021 (UTC)[reply]

Echoing something written elsewhere by Isaacl, I want to ask anyone considering closing a section to not do so. This is a multi-month process and any results are likely to play-out for a long time. We are in no rush here. We have a great group of closers lined up, in Lee Vilenski, Primefac, and Ymblanter. They have, for the moment, made the decision to let discussion continue. I would ask that this decision of theirs be respected. There are advantages to having a cohesive close, considering discussion as a whole in addition to discussion of each particular idea. Best, Barkeep49 (talk) 23:30, 2 December 2021 (UTC)[reply]

• You're completely right Barkeep49. I also fully agree with Isaacl on what they had said above. There is no immediate urgency as such and it would be better to have completely uninvolved editors (who have not taken part in this RfC anywhere) to close all the individual proposals and in general the whole RfC overall as well with their full detailed rationale. TheGeneralUser (talk) 23:41, 2 December 2021 (UTC)[reply]
• I've added a note to this effect at the top of the RFC page. User:力 (powera, π, ν) 23:44, 2 December 2021 (UTC)[reply]
• With all due respect, the main 2021 reform page states that November 30 was when the 30 day discussion period end[ed], not that the period was some sort of minimum. While the closers are free to close this phase as they wish, I suggest they do so at a timeline that respects the spirit of that page and not draw discussion out too much longer. As said earlier, people had months to figure this whole process out and those couldn't, or didn't, should not be given undue leave. I highly doubt that any material outcome would be changed much by such extensions in any event – clear-cut cases will remain clear-cut, and controversial cases will remain controversial. – John M Wolfson (talk • contribs) 00:24, 3 December 2021 (UTC)[reply]
• Just as a note, there are only three discussions left: 6C, 6E, and 8B. One or two of them might require some inter-personal discussion between closers, but on the whole I think we are nearly there. Primefac (talk) 09:49, 3 December 2021 (UTC)[reply]
• I was mulling over whether or not to say this, but in my personal opinion (which you are free to disagree with), I see a narrow consensus for 6C. In terms of numbers, there is a two-thirds supermajority of supports. The opposition is centred around a) ANI being already suitable for this, b) too similar to the deprecated RfC/U and c) the wrong place to discuss this. I think c) is a procedural remark that carries less weight than the other two, which means I see a consensus for an Administrator Review noticeboard, but ensure further discussion takes place with "ground rules" to make sure the concerns of a) and b) are minimised. Ritchie333 ^{(talk) (cont)} 13:00, 6 December 2021 (UTC)[reply]

  In the interest of forestalling a spread of discussion to multiple locations, perhaps views on the key points made by different participants can be put forth in the corresponding "Discussion" section of the proposals page. isaacl (talk) 20:14, 6 December 2021 (UTC)[reply]

• 6C, 6E, and 8B(+8B.a) are still open - just a check-in to make sure someone was still working on this, even if off-line? Note, should 8B be approved there will certainly be some implementation work to do, and it won't be "fast" (I've started a little behind the scenes work in case it gets approved, details may need to adjust depending on how the closure goes). 6C should be able to be immediately worked on, will need someone to help get process documentation updated if it passes. 6E should be fairly rapid as well, as it is just process and policy adjustments. — xaosflux ^Talk 14:42, 7 December 2021 (UTC)[reply]

  Yes, the closers are aware that these threads are still open.--Ymblanter (talk) 15:27, 7 December 2021 (UTC)[reply]

I feel that the entire 2021 RfA review has been positive and productive. I thank every participate for their time and ernest effort which, today, gives cause for some wiki-pride. Sincerely.--

Hello all! In regards to

Seems sensible. HighInBC ^{Need help? Just ask.} 13:06, 3 December 2021 (UTC)[reply]

Yep, sounds good to me. — Bilorv (talk) 16:54, 3 December 2021 (UTC)[reply]

I've added this to the next administrators' newsletter issue. Unfortunately, we just missed the December issue, which means that it'll only be sent out in January. Due to this, I think it may be preferable to wait a week or two until after the issue is sent before removing the right. Tol (talk | contribs) @ 17:29, 3 December 2021 (UTC)[reply]

I would suggest that this might be worth a separate mass message to administrators rather than just including it in the administrator's newsletter. I can't find the history around the creation of EFM, but I don't think we've ever explicitly broken out a self-assignable tool from the toolbox. Waiting a week a week or two after that announcement (and post to other appropriate places) before doing the technical side also sounds right. Best, Barkeep49 (talk) 19:17, 3 December 2021 (UTC)[reply]

@Barkeep49: we could let them know via Wikipedia:Administrators/Message list - want to craft a message? Should probably include: (a) Pointing to this RfC; (b) Letting them know they can do this, possibly with a link to [[Special:UserRights/{{BASEPAGENAME}}]]; (c) Neutral explanation of why they may or may not want to do this; (d) link to Wikipedia:Autopatrolled. — xaosflux ^Talk 19:31, 3 December 2021 (UTC)[reply]

My version of the draft is:

A

Edit Filter Manager, choose to self-assign

this permission to yourself. If you have any questions ask them at the [[Link to AN announcement]]. ~~~~~

As we trust administrators to use the tools they have wisely and competently, I would suggest the link to the RfC, Autopatrol, and a place for questions is sufficient background and a neutral explanation would be unnecessary. Best, Barkeep49 (talk) 19:48, 3 December 2021 (UTC)[reply]

With apologies for pedantry, I would suggest changing "similar" to "similarly", as it modifies the verb "choose". Tol (talk | contribs) @ 21:38, 4 December 2021 (UTC)[reply]

I have edited the text above with this change. For ease of reading for anyone else who might want to comment on the message I have done so without annotation of the refactor. Best, Barkeep49 (talk) 04:02, 5 December 2021 (UTC)[reply]

Hmm. I hadn't considered this aspect. Is it a good idea to encourage admins to assign it to themselves? Will almost everyone then do so, negating this successful proposal as soon as it begins? Instinctively I would say that you shouldn't be giving yourself perms, you should be asking a colleague to give it to you, for transparency. Apart from EFM, a counter-precedent could be that we expect admins not to unblock themselves, even though we technically can?

On another note, when you say do this in a month, can we actually do it in a month? I thought there would have to be a phab ticket, and who knows how long that could take. – Joe (talk) 21:24, 3 December 2021 (UTC)[reply]

@Joe Roe: yes it will be a phab, but it is an "easy" type (config file, not software patch) - it will likely go live 1-2 weeks after we enter it. — xaosflux ^Talk 22:49, 3 December 2021 (UTC)[reply]

That's good. I suggest we open the phab ticket and I agree a date with whoever is going to flip that bit before any notifications. – Joe (talk) 07:39, 4 December 2021 (UTC)[reply]

This has now been done by Wugapodes. Best, Barkeep49 (talk) 04:33, 5 December 2021 (UTC)[reply]

It's at phab:T297058 for reference with a patch at gerrit:743646. I can't deploy, so whatever date we want them deployed should be noted at those locations as well. — Wug·a·po·des​ 04:55, 5 December 2021 (UTC)[reply]

Well, I had an autopatrolled flag before becoming an admin, and the flag was given to me on the basis of my main space contribution (actually, without me asking for the flag). Earlier today, I restored this flag, and I do not see any problem with it to be honest, my contribution is still 70% or so in the main space, and I still create several articles per week. If someone thinks I have abused my privileges, please say so, but absent exlicit objections I do not consider this action controversial.--Ymblanter (talk) 21:31, 3 December 2021 (UTC)[reply]

Oh yeah, if you had it before, that's absolutely fair enough. (Though I had it before too, and I don't plan on retaining it, because after a few years being one of the main admins working

WP:PERM/A, I'm convinced that the right should be abolished for all but the most prolific mass-creators.) – Joe (talk) 21:34, 3 December 2021 (UTC)[reply

]

The RfC wording clearly says it can be self assigned so implementing on that basis is clear. I would suggest my proposed wording does not encourage it. Do you feel differently @Joe? Best, Barkeep49 (talk) 05:32, 4 December 2021 (UTC)[reply]

Can, not should. And I think saying a mass message with that in it will have that effect. If we just don't mention, a convention on (re-)assigning it is going to emerge organically, no? – Joe (talk) 07:39, 4 December 2021 (UTC)[reply]

Leaving it out makes it unclear whether admins are permitted to assign it to themselves. They may think they have to go through the normal

WP:PERM/A process. — Bilorv (talk) 10:45, 4 December 2021 (UTC)[reply

]

Only a small subset of admins self assigns EFM. Making that parallel makes things clear. Finally I will re-iterate that admins have been trusted to use autopatrol correctly now and it is being removed to make RfA easier not because of current documented abuse. Admins are generally trusted to use their tools wisely and so I trust that telling them that they may do this is no different than the many other things that we tell them they may do but most do not. Best, Barkeep49 (talk) 15:27, 4 December 2021 (UTC)[reply]

I feel that newly approved administrators will understand that rights not assigned to them automatically shouldn't be self-assigned without appropriate reflection. Additionally, if the hypothetical commenters whose approval hinged on the absence of the autopatrolled right express their concerns during the request for administrative privileges, there will be a reminder to the admin on this matter. (In an extreme case, if the commenters really don't trust the candidate to avoid self-assignment of the right, they should put forth an argument for opposing the request and convince others to oppose.) isaacl (talk) 16:09, 4 December 2021 (UTC)[reply]

I am worried about the increase in articles in the NPP backlog from this. We are already at around 9,000 articles, and our recent NPP backlog drive barely made a dent. Adding a bunch of articles from non-problematic users is not going to help the backlog size. In short, I think it'd be wise to encourage admins to self-assign this right, to help with the backlog, as their creations are almost always un-problematic. –Novem Linguae (talk) 04:57, 5 December 2021 (UTC)[reply]

I believe most administrators do not create new articles, and those who do are active enough to assign themselves the flag.--Ymblanter (talk) 18:45, 5 December 2021 (UTC)[reply]

@Ymblanter: admins may do other things that benefit from autopatrol, in and out of mainspace. Certain article maintenance tasks related to mergers, moves, transwiki's etc -- so if an admin works in those areas they may also want to avoid bothering NPP. — xaosflux ^Talk 23:23, 5 December 2021 (UTC)[reply]

This is correct, but I still believe the effect of removal of the autopatrolled from the admin toolset would only have very little effect on the NPP queue. The main NPP effort is anyway checking whether articles should stay in the mainspace due to sourcing and copyvio issues.--Ymblanter (talk) 06:14, 6 December 2021 (UTC)[reply]

Arbitrary ease of reading break

• I asked for Autopatrolled some time before I ran for RfA. Will I need to ask for the permission again? Ritchie333 ^{(talk) (cont)} 13:06, 6 December 2021 (UTC)[reply]

  I think that's a judgement call you, as an admin, are capable of making. Personally, I would see zero issue with you re-granting yourself a permission you were given before you even became an admin, just as we will often re-grant the perms given to those handing in their mops voluntarily without the need for them to re-apply at PERM. Of course, I also do not see much issue with any admin granting themselves the flag if they feel it will be necessary, since "good judgement" is one of those things admins are supposed to have in the first place ;-) Primefac (talk) 13:08, 6 December 2021 (UTC)[reply]

  Exactly. Keep in mind that the bar to move a new page from unpatrolled to patrolled isn't that high. It doesn't mean this page is brilliant, and in the case of non-article pages it basically only means "this page isn't a CSD". — xaosflux ^Talk 13:13, 6 December 2021 (UTC)[reply]

• @Wugapodes: appears to have jumped the gun on this timing disucssion at phab:T297058; not sure if I got a block on it quick enough. We certainly all agree this should happen - but at the least it seems getting communication out before implementation has support above. — xaosflux ^Talk 19:35, 6 December 2021 (UTC)[reply]

  @Xaosflux while @Wugapodes had written the change, it was never scheduled for deployment. I'm going to start a subsection with more in just a moment. Best, Barkeep49 (talk) 19:39, 6 December 2021 (UTC)[reply]

• @Xaosflux, Regarding your final sentence: Is there any reason we don't just have a bot automatically patrol pages created by extended-confirmed users outside of the four wholely or partly reader-facing namespaces (main, category, portal, template)? (Could also whitelist certain things that aren't reader-facing, like user categories, and could blacklist a user if they somehow get a reputation for constantly creating problematic TimedTalk text pages or something.) I'm aware that this would require a separate discussion, but if we're about to see an influx of non-content-creator admins +AP'ing themselves since they mass-create usertalk pages, now might be a good time for that discussion, assuming it has a chance of success. -- Tamzin^{[cetacean needed]} (she/they) 17:58, 7 December 2021 (UTC)[reply]
  • I've never understood this situation at all. What is the purpose of having the patrol feature on editor-facing namespaces? Who monitors these unpatrolled pages and why? When I encounter innocuous unpatrolled pages (like GA review pages), should I be marking them as patrolled? — Bilorv (talk) 18:35, 7 December 2021 (UTC)[reply]

  @Tamzin and Bilorv: there are odd workflows such as creating a page, getting it patrolled by someone that doesn't actually look at it (like a bot) - then sub-sequentially moving that page. Other maintenance activities can get mixed in between native patrolling and the PageTriage extension - it is just a messy situation. As far as something like "just mark any namespace_x page by someone as patrolled" - that detracts from literal new page patrol (not "new article patrol") from spotting bad pages being published and overlooked. It is just as bad for us to host Mediawiki talk:A page full of libel about Tamzin as it is to host A page full of libel about Tamzin, and even worse if a workflow would patrol the former and let it survive certain moves in to article space. Unpatrolling after moves has been stalled for many years (phab:T159028). Now for admins, perhaps a bot to patrol any page by an admin would be fine - but without that last change leaves open the door that those sneaky admins would create a page, get the bot to patrol it, then slip it in to an article without the new article patrol people catching it (<sarc> they are very nefarious after all, why we obviously can't trust them with autopatrol </sarc>). — xaosflux ^Talk 18:52, 7 December 2021 (UTC)[reply]

  @Xaosflux: I agree that problematic pages are just as problematic in any namespace, but the current situation (even before factoring in AP unbundling) makes that more of an issue, not less. There's only a few people (or maybe just Elli?) who regularly patrol pages in a lot of these namespaces. You, as an OS, can check Ticket#2021052710009446, where I found OSable info that had sat in projectspace for months. I have a currently-stalled project to go through a number of projectspace pages that have slipped through the cracks like that. As such, unless there's a sudden surge in interest in patrolling pages outside of mainspace, I think we'd obscure less abuse by mass-patrolling extended-confirmed editors than we obscure by not. After all, if someone's going to game EC, creating Mediawiki talk:A page full of libel about Tamzin seems like a weird thing to spend that effort on. (Also I'm pretty sure that's just User talk:Tamzin.) If EC is too low a barrier, I still think we should have some sort of whitelist. Patrolling usertalkspace is basically pointless when we have non-AP recent change patrollers creating a few usertalk pages every minute. Likewise I created 39 projectspace pages last month.

  I do agree that the pagemove thing is an issue, though... Seems like something we should have a bot for regardless? -- Tamzin^{[cetacean needed]} (she/they) 21:28, 7 December 2021 (UTC)[reply]

  @Bilorv: - anyone that wants to of course! For an easy example, it can be useful when patrolling Special:NewFiles. — xaosflux ^Talk 19:00, 7 December 2021 (UTC)[reply]

  @Bilorv: I monitor these pages, you can see a lot in my CSD log. Yes, please mark ones that are fine as patrolled when you come across them. Elli (talk | contribs) 19:49, 7 December 2021 (UTC)[reply]

  Xaosflux and Elli, thanks for the information. — Bilorv (talk) 22:11, 7 December 2021 (UTC)[reply]

  It is my impression that NPP focuses almost completely on mainspace (articles, redirects, disambiguation pages), and that other namespaces are hardly reviewed at all, are not reviewed in a methodical (every article) way, and are even actively discouraged from getting reviewed. For example, someone asked at

  WT:NPPR one time if we should be marking userpages as reviewed, and folks said no. There exist checklists for some unusual-to-review namespaces such as template, Wikipedia, and file, but I do not believe reviewing these to be the norm. In conclusion, I do not think we would need a bot to mark these patrolled/reviewed since these don't really show up in a queue that we are trying to empty. –Novem Linguae (talk) 22:32, 7 December 2021 (UTC)[reply

  ]

  I think there is a bit of a cult mentality in a vocal subset of editors in "NPR", thinking patrolling of new articles is the most important review function that exists; I think most of the traditional "new page patrol" functions have been combined with "recent changes patrol" (as everything is a change anyway). I agree that patrol of new pages in mainspace is more important than patrol of new pages in some other namespaces - but that doesn't mean that they should be ignored. — xaosflux ^Talk 22:54, 7 December 2021 (UTC)[reply]

  Well, note that Special:NewPagesFeed does not even include anything outside article (and user) namespace. That's the feed new page patrollers use. The older Special:NewPages also defaults to showing just articles. I believe the autopatrolled right is also solely granted based on articles created. As such, I too don't think it's desirable for admins who create maintenance pages to add it to themselves, as other editors who create a maintenance pages aren't given autopatrolled. Problematic pages in other namespaces are handled just via RCP. – SD0001 (talk) 18:43, 15 December 2021 (UTC)[reply]

  Due to the open nature of the project, and the many tools available, those that want to patrol new "pages" can do it however they want, and they don't need to associate themselves with that wikiproject if they don't want to. — xaosflux ^Talk 19:11, 15 December 2021 (UTC)[reply]

7D Rollout plan

It appears that things are fairly set on the "back-end" to implement this change, with the remaining step being to choose a "window" to enact this. My suggestion is to announce, at

A

Edit Filter Manager, choose to self-assign

this permission to yourself. This will be implemented the week of December 13th, but if you wish to self-assign you may do so now. To find out when the change has gone live or if you have any questions ask them at the [[Link to AN announcement]]. ~~~~~

One further piece. My intent, once we have agreement on all this, is, using my administrator discrestion, to grant the user group to the 129 admins who've had it in the past (or at least since Nov 2011). Best, Barkeep49 (talk) 20:10, 6 December 2021 (UTC)[reply]

This sounds sensible to me. — Bilorv (talk) 18:35, 7 December 2021 (UTC)[reply]

I don't think there has been any "confusion"?

talk) 20:37, 6 December 2021 (UTC)[reply

]

I agree Eddie wasn't confused. The confusion stemmed from MusikAnimal. Best, Barkeep49 (talk) 20:44, 6 December 2021 (UTC)[reply]

• @Barkeep49: I don't think there is any reason to delay the communications - lets get it going as soon as possible. (perhaps update Wikipedia:Autopatrolled to reflect the new-state at the same time) My only hold was to not push the config change until a sufficient (2-4 weeks?) period elapsed from the communications. — xaosflux ^Talk 14:34, 7 December 2021 (UTC)[reply]

Regarding grammar: the previous wording was an elision of "in a similar manner to Edit Filter Manager". With the change to "similarly", then I think it should be "similarly as with Edit Filter Manager", since the admin is choosing similarly as they would with Edit Filter Manager. isaacl (talk) 14:54, 7 December 2021 (UTC)[reply]

I have gone ahead and sent the MMS and posted as I indicated above. I will next be going to the phab to ask for the removal of the hold and the implementation some time next week per the message. Best, Barkeep49 (talk) 20:10, 7 December 2021 (UTC)[reply]

Any strong opinions when to schedule the rollout? I'm free during the Monday evening backport window, but if we want to do it later in the week, I can do Thursday as well to line up with

WP:THURSDAY changes. — Wug·a·po·des​ 01:03, 11 December 2021 (UTC)[reply

]

@Wugapodes: think dev's choice is fine - we've sent out our communications, so whenever is convenient over the next week should be fine. — xaosflux ^Talk 03:03, 11 December 2021 (UTC)[reply]

Sounds good, I've scheduled it for 19:00, 16 December (UTC). — Wug·a·po·des​ 19:05, 15 December 2021 (UTC)[reply]

 Done — Wug·a·po·des​ 19:35, 16 December 2021 (UTC)[reply]

RWHITELIST?

With the stripping of autopatrol from admins, should we add all of the admins to

Great question @Xaosflux. I'm going to ping Rosguill who is the admin who most actively works that but my first impression is I think we should add all admins to the redirect whitelist. If we have an admin whose redirects aren't even OK that would strike me as an issue of overall competency. Best, Barkeep49 (talk) 19:10, 7 December 2021 (UTC)[reply]

We used to have an admin who created a lot of redirects which we not ok. The admin was eventually blocked and the redirects deleted. I guess if we discover another one (unlikely in my opinion) we can delete their redirects as well.--Ymblanter (talk) 19:29, 7 December 2021 (UTC)[reply]

I had exactly that user in mind when writing that if someone can't be trusted to create redirects, I would question their fitness to be an admin. Best, Barkeep49 (talk) 19:41, 7 December 2021 (UTC)[reply]

Wouldn't we want that to come to light through NPPs stumbling on the bad redirects, then? Personally, as a redirect patroller, I'd rather we take a short-term hit in the size of the queue, but liberally add admins to the whitelist without requiring as large a body of redirects as we do with non-admins (basically just an "are you recreating anti-trousers?" test). -- Tamzin^{[cetacean needed]} (she/they) 21:34, 7 December 2021 (UTC)[reply]

This change wasn't justified under the rational that admins are abusing autopatrol. It's being made to make RfA easier. Barkeep49 (talk) 21:43, 7 December 2021 (UTC)[reply]

Yes, but now that it is being unbundled, the question of whether admins should be automatically redirect-whitelisted is a question of what's in the best interest of redirect patrol. -- Tamzin^{[cetacean needed]} (she/they) 22:07, 7 December 2021 (UTC)[reply]

Barkeep49, I don't have much of an opinion either way as far as adding admins to RWHITELIST is concerned. IMO we could add them all, or we could leave it be and only add them if I or other reviewers identify them as high volume/high precision redirect creators. _signed, Rosguill ^talk 19:47, 7 December 2021 (UTC)[reply]

I'm probably late to the party, but I just came up with this. Put some sort of limit on how much digging is allowed when a candidate presents themselves in an RfA. Example of possible restrictions:

Questions or concerns about anything that is over 1 year old may only be brought up/discussed if at least one of the following is true:

• The candidate brings it up first.
• It concerns general statistics. (for example: "in 2015 the candidate made 100 edits, 50 of which were reverted")
• It concerns an issue related to adminship on any Wikimedia project. (for example: a failed RfA or wheel warring on another project)
• It concerns an issue that was handled by the Arbitration Committee.

Something like this would perhaps help to stop users from digging up mistakes that just aren't relevant anymore. Exact requirements may need adjustment, but possibly an idea worth exploring. — Alexis Jazz (talk or ping me) 14:41, 6 December 2021 (UTC)[reply]

@Alexis Jazz, I would expect the community will need a little breathing time after this process. But one of my hopes is that in the medium term that the consensus reached during Phase 1 could still be used for further improving RfA. As to the merits of this proposal in my attempt to spur discussion I had thrown out an idea during the Brainstorming phase which you might be interested in. I think there are real limits to these kinds of rules, but there does seem to be community agreement that digging through candidates' pasts does not help with RfA so perhaps with further refinement there is a viable proposal to be had. Best, Barkeep49 (talk) 16:04, 6 December 2021 (UTC)[reply]

Barkeep49, I see. I think changing the weight of votes is difficult to apply, potentially gives crats too much power and once something has been mentioned it can influence other voters anyway. It's also too late: the point is too make potential candidates more comfortable that we let bygones be bygones. Simply putting a restriction on what may be dug up (and revdelling anything that violates that) should be more effective, at least in theory. — Alexis Jazz (talk or ping me) 16:38, 6 December 2021 (UTC)[reply]

I have started a discussion on implementing 6C Administrative action review. Interested editors are invited to join in. Best, Barkeep49 (talk) 23:11, 10 December 2021 (UTC)[reply]

Thanks Ymblanter, Primefac, and Lee Vilenski for the close of 6E -- obviously it is not the outcome I would have preferred, but your close is a thorough and fair summary and analysis of the discussion, so I have nothing to complain about. In the close, you raised the possibility of running an RfC for an improved version of this proposal. I am not going to pursue that immediately (I think it would be good to wait at least to see to what extent other implemented proposals have a positive effect). However, if at some point in the future I do decide to pursue it, is

I think that would be a reasonable place to put it, yes. Additional cross-posting to

T:CENT would probably be wise as well. Primefac (talk) 14:19, 13 December 2021 (UTC)[reply

]

Yeah, that's the idea. I don't have any prejudice against another RfC being created about this, unfortunately this one wasn't quite clear enough to enact. Indeed it would be wise to give it some time before doing so as you suggested. Best Wishes, Lee Vilenski ^{(talk • contribs)} 14:37, 13 December 2021 (UTC)[reply]

Thanks both! --JBL (talk) 18:48, 13 December 2021 (UTC)[reply]

The closure of 8B as "unsuccessful" has fortunately been overturned now. How do we continue? And where? ~ ToBeFree (talk) 00:58, 25 December 2021 (UTC)[reply]

Let's figure out whether the 'SecurePoll technical concerns' are real or a myth, as that seemed to be divisive. Perhaps at

WP:VPT and ping in Risker & 4nn1l2 as the primary claimant and counter-claimant, along with some other technical editors experienced with SecurePoll. If the fact of the matter is there's no technical issue, maybe re-RfA? If there is a technical issue, it's probably better to resolve that first. ProcrastinatingReader (talk) 02:48, 25 December 2021 (UTC)[reply

]

I'd rather it be along the lines of "Does the community support selecting administrators via election by secret ballot" and leave off the technicalities of how that would be implemented - because if there is no support we shouldn't waste dev time. — xaosflux ^Talk 02:57, 25 December 2021 (UTC)[reply]

I agree with Xaosflux. This proposal was way too significant a change to be proposed as point 8B in an enormous omnibus RFC. This needs a standalone RFC, clearly labeled so that community members know exactly what they're supporting/opposing, instead of being stuck near the end of a mishmash of suggestions and ideas. I'd suggest that the RFC question be phrased as Xaosflux proposes, but I think it might be useful to have someone from the WMF who is familiar with both the technical and practical aspects adding an impartial comment on what SecurePoll can and cannot do. I have a lot of respect for 4nn1l2, but at the end of the day they're a volunteer just like the rest of us, and I think it is essential that we get information on matters such as which WMF department is responsible for the technical maintenance and improvement of the extension, what it can and cannot do from a technical perspective, what it can and cannot do from a practical perspective (e.g., are there sufficient human resources to educate and assist in the management of SecurePoll) what kinds of limitations we should expect (e.g., requiring multiple candidates to run simultaneously rather than allowing each candidate to run at their own time), and so on. It's really great that 4nn112 has been supporting the use of SecurePoll; however, if we were to move in this direction, we as a community need to know that the WMF is going to accept responsibility to manage and support both the software and the users of the software as required. (Note that, to date, this kind of support has NOT been guaranteed.) This information is probably important for the community to make an informed choice. Risker (talk) 04:52, 25 December 2021 (UTC)[reply]

I fully agree. Let's ping Joe Sutherland from the WMF to opine on this matter. User:JSutherland (WMF), you probably know me. I'm one of the organizers of fawiki elections (phab:T292685). I know that you are mostly single-handed in the Trust and Safety team, but I also hope that User:NahidSultan (WMF) can help you too in this matter.

1) At first, I want you to confirm that at the moment only 3 communities (namely enwiki, fawiki, and zhwiki) hold their elections on votewiki using SecurePoll (of course besides WMF and its affiliates).

2) Secondly, I want you to confirm that simultaneous election are possible on votewiki for multiple projects from a technical point of view. The reason that fawiki postponed its elections for one week (phab:T292685#7412256) was that we only wanted more cosmetics for our voters to see Farsi text (in Arabic script) from right to left (unlike this screenshot which shows RTL text in an LTR environment).

3) Finally, I want you to confirm that you can help enwiki community to hold administrative elections (as opposed to ArbCom elections) every six months in a proper predetermined time (for example Febs and Augs).

Thanks 4nn1l2 (talk) 12:09, 25 December 2021 (UTC)[reply]

I will just note that *all* WMF staff are on the organization's end-of-year break (with the exception of extremely time-sensitive or "emergency" situations), so while I think we'll get a response at some point, it probably won't be until early January. This isn't a criticism by any means, but it does give us more time to think about what we really need to know and to think more closely on what we would want to ask the community. I'm a little more hesitant to concur with Xaosflux below about the possibility of developing *different* secret-ballot software because there isn't guaranteed support for the one we have now; I don't think adding more unsupported or volunteer-only supported software is an answer to anything. Risker (talk) 19:30, 25 December 2021 (UTC)[reply]

@Risker: agree, I think where I was going was that if staff wanted to support some sort of COTS solution, or the community wanted to use an external solution - that is something that could be fluid, but that any of those type of ideas are useless if the concept of "elections" with "secret ballots" are outright rejected. — xaosflux ^Talk 20:02, 25 December 2021 (UTC)[reply]

To be fair, there is critical infrastructure that is maintained by volunteers, both in the WMF ecosystem and outside, and has no WMF support. Consider the AbuseFilter extension, for example. I don't think WMF support is critical to proceed here. After all, SecurePoll is unsupported right now and still used for ArbCom elections. ProcrastinatingReader (talk) 20:05, 25 December 2021 (UTC)[reply]

I don't think saying that we already have an election using unsupported software is a good argument for saying that we should have *more* elections using unsupported software. And the underlying AbuseFilter extension is supported by WMF staff/contractors; each project determines locally how to use that software (i.e., we write our own filters, determine which ones will be active, etc.). Risker (talk) 20:15, 25 December 2021 (UTC)[reply]

The underlying extension is maintained by Daimona Eaytoy (per mw:Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation), who is a volunteer. A future overhaul is supported by a project grant (meta:Grants:Project/Daimona Eaytoy/AbuseFilter overhaul), but the current version and prior versions are supported mainly on volunteer time I think. ProcrastinatingReader (talk) 20:23, 25 December 2021 (UTC)[reply]

Looking at the MediaWiki page, it seems some extensions don't even have maintainers (like CheckUser). FlaggedRevs doesn't even have a code steward. SecurePoll at least has a volunteer maintainer, even if it has some functional inadequacies. ProcrastinatingReader (talk) 20:33, 25 December 2021 (UTC)[reply]

@Risker: I assume that holidays in the West are over, but I still see no replies from the WMF staff. Am I wrong? 4nn1l2 (talk) 12:13, 7 January 2022 (UTC)[reply]

I just sent an email to Mr. Sutherland asking him to participate in this discussion. 4nn1l2 (talk) 11:08, 11 January 2022 (UTC)[reply]

I immediately received an automatic response that he would be out of office until 18 January 2022. 4nn1l2 (talk) 11:10, 11 January 2022 (UTC)[reply]

Agree with Risker that it is still worth looking in to SPoll options, including options for community-run polls that don't require use of another server or staff (some work on this is occuring over on testwiki still - it is slow) - I certainly don't think that if the concept of using secret ballots and moreso the concept of actually using an election for this process is supported that it should be dependent on any specific piece of technology. Securepoll is a good example of what could be used, but it could evolve or something better could come along. — xaosflux ^Talk 12:17, 25 December 2021 (UTC)[reply]

Merry Christmas, all. I think it would be wrong to go to the community for a decision without a fully thought through proposal accompanied by chapter and verse from WMF IT staff confirming that it can be done exactly as envisaged. I think the next stage must necessarily be to ask the WMF to talk to us about the limits of SecurePoll.—S Marshall T/C 09:59, 25 December 2021 (UTC)[reply]

Hi folks - sorry for the delay, between end-of-year holidays, personal time off, and other stuff, it's been a wild few months. Hope you're all well! To answer 4nn1l2's questions above:

1. At first, I want you to confirm that at the moment only 3 communities (namely enwiki, fawiki, and zhwiki) hold their elections on votewiki using SecurePoll (of course besides WMF and its affiliates).

   At this moment, yes. The history of every poll ever run is public information on votewiki.

2. Secondly, I want you to confirm that simultaneous election are possible on votewiki for multiple projects from a technical point of view. The reason that fawiki postponed its elections for one week (phab:T292685#7412256) was that we only wanted more cosmetics for our voters to see Farsi text (in Arabic script) from right to left (unlike this screenshot which shows RTL text in an LTR environment).

   This is also my understanding. This seems to be a pretty common misunderstanding of what SecurePoll can or can't do. It is totally possible to run two elections at the same time. The reasons we haven't and don't historically are:

   • There just aren't that many elections (typically there were only two local elections and, every three-ish years, a Board election), so clashes didn't really happen
   • As you describe, the "skeleton" of votewiki is only available in one language at a time. You could run the Farsi elections with the project set to English but it would be extremely disorienting because of the LTR issue
   • (This is the primary reason:) Running an election is a long and drawn out process and we simply do not have the staff time to support multiple elections running at the same time.

   So it's not really a technical reason, it's a staffing reason.

3. Finally, I want you to confirm that you can help enwiki community to hold administrative elections (as opposed to ArbCom elections) every six months in a proper predetermined time (for example Febs and Augs).

   For the reasons outlined above, and the fact that I would need to liaise with potentially dozens of colleagues at the Foundation to make this happen, I cannot confirm this or really anything like this myself. Joe Sutherland (WMF) (talk) 18:07, 26 January 2022 (UTC)[reply]

Spend plenty of time with at least several people involved crafting an excellent proposal, and invite participation in the crafting. And then everybody who worked on it and more or less agrees actively support it in an RFC, even if you disagree with 10% of it. North8000 (talk) 14:43, 25 December 2021 (UTC)[reply]

I'm seeing a lot of sense in what is being suggested. Those with addressable concerns should be heard. Concerns might be mitigated somewhat. BusterD (talk) 15:50, 25 December 2021 (UTC)[reply]

The main problem is the mechanics of these things mean that no significant changes get made in Wikipedia. My advice was on the mechanics of a way to actually get something done. A lot of time & work formulating a really good proposal, and then everybody who generally supports it actively support it in the RFC, even if they only 90% agree. North8000 (talk) 20:48, 25 December 2021 (UTC)[reply]

For my part, I do not wish to insert any "poison pill" or discourage change; it is apparent from the 8B discussion and resulting upset after the first close a significant segment of wikipedians wish to at least try straight secret voting. I don't like it myself but would hope to reduce my concerns about any such proposal before the RFC is put to a !vote. BusterD (talk) 21:06, 25 December 2021 (UTC)[reply]

@ToBeFree @4nn1l2 @Bilorv @BusterD @Kudpung @Leaky caldron @North8000 @ProcrastinatingReader @S Marshall @W. Tell DCCXLVI @Risker: Would anyone consider proposing this at meta:Community Wishlist Survey 2022/Proposals, considering technical issues seem to be the main problem? ― Qwerfjkltalk 16:18, 22 January 2022 (UTC)[reply]

I don't agree that technical issues were the main problem; one claimed "issue" was an outright falsehood. It's not worth wasting a wish on this, given how few the WMF pay attention to and how many more critical technical issues for Wikimedia exist. — Bilorv (talk) 16:26, 22 January 2022 (UTC)[reply]

I wouldn't do so, for two reasons: 1) The Community Wishlist Survey is a vote. People from all communities vote for the features they desire most. Fixing SecurePoll to work with one specific community's RfA reform proposal that was closed as "no consensus" won't gather enough support to be implemented. 2) If we need this and there is a strong community consensus to use SecurePoll for the task, my personal position is that WMF developers are obligated to fix SecurePoll, independently of the Community Tech team's annual wishlist. ~ ToBeFree (talk) 16:33, 22 January 2022 (UTC)[reply]

Bilorv is correct that the problem wasn't technical. What would potentially drive it forward is a RFC specific to this proposal.—S Marshall T/C 17:00, 22 January 2022 (UTC)[reply]

I too believe there are no technical barriers. I am shocked that the WMF has effectively ignored us for almost a month. I already knew that WMF did not give a hoot about a medium-sized project such as fawiki, but this is news to me that WMF does the same about enwiki, its flagship project which is the root cause of about 50% of the received donations (Wikipedia:Wikipedia Signpost/2021-12-28/News and notes#WMF's audited financial statements released)! 4nn1l2 (talk) 19:01, 22 January 2022 (UTC)[reply]

You do know they don't read these pages, right?—S Marshall T/C 10:41, 23 January 2022 (UTC)[reply]

How to continue?

I deliberately did not vote on this, I still have no opinion on it, and it's probably not a solution that I would have proposed, but FWIW having read it now three times, I would have closed it with 'Consensus'. The opposers each wrote more but IMO it didn't give more weight to their arguments.

So just my opinion, but the way to go is to hold a stand alone RfC. This reform project has dragged on now for nearly four months, the sky is not falling (yet), and another few weeks to get it done properly won't sink the

In my experience the most successful RfC of this kind are based on a clean proposal statement calling for Support/Oppose (practically a straw poll) and excluding any details of how, in the case of consensus, it should be addressed. The RfC proposal wording is critical and should be composed by a small drafting committee (what I used to call a 'task force'). How to get such a team together is up to the editor who wishes to take the initiative to coordinate and propose it, but the lists of participants below may help.

Hence it should be mentioned in the preamble for example:

• This RfC is strictly 'For and against' holding secret polls for adminship.
• This RfC is for a trial to be offered parallel to the traditional RfA, for a period to be determined in a in a follow up RfC if successful.
• Alternative suggestions were made and discussed during the run up to this RfC and should not be redebated here.
• Any opposes based purely on the technical issues of a secret poll will be inadmissible. The WMF is wallowing in funds so the classic excuses won't gel. If the community wants a secret poll, the WMF must provide the infrastructure for it (we've
  been there
  , done that, and I and a couple of others got the T-shirts for it).
• Frequency of the poll should be discussed in a follow up RfC.
• Scrutiny of votes should be discussed in a follow up RfC.
• Durations of nomination period, discussion period, and voting period should be discussed in a follow up RfC.

Here is a break down of voting that may or may not be useful: