Jump to content

Wikipedia talk:Requests for adminship/Archive 264

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 260←Archive 262Archive 263Archive 264Archive 265Archive 266→Archive 270

RfC: should RfAs be put on hold automatically?

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
This proposal is successful. There is consensus to automatically place RfA discussions "on hold" after one week (i.e. no further comments will be accepted after 168 hours of discussion).
Supporters of this change argued that it would be beneficial at reducing stress for the RfA candidate. Opponents to the change often pointed out that many RfAs are already closed within a few hours after the one-week mark is reached, so the benefit of this change would be minimal. A few others raised the point that RfA is supposed to be a discussion, not a vote, and argued that arbitrarily cutting off discussion after a certain length of time would violate that principle. On the whole, however, most participants in this discussion did not find these concerns convincing, arguing that this is a lightweight change and that the beneficial effect this would have for the candidates outweighs the concerns raised.
The original RfC suggested a technical approach to implementing this change (i.e. modifying {{rfa}} to automatically place the RfA "on hold" after one week). I view the community consensus here as favoring an automated solution (perhaps with magic words) over a manual one (e.g. requiring editors to manually add {{rfah}}). Mz7 (talk) 00:01, 6 November 2022 (UTC)

Question: Should RfAs automatically be put on hold after one week?
Details: This would be implemented by modifying {{rfa}} to automatically place the RfA "on hold" after one week. Bureaucrats would still be responsible for evaluating consensus, formally closing the discussion, granting admin access itself, etc. This would not affect the ability of 'crats to extend the duration of RfAs, if they deem it necessary. HouseBlastertalk 11:57, 7 October 2022 (UTC)

See discussion just above. Valereee (talk) 20:55, 7 October 2022 (UTC)

Survey (putting RfAs on hold)

  • Support as proposer. Plenty of words have been said about this in the above discussion, but the main motivation behind this change is candidate stress. After his RfA, ScottishFinnishRadish noted in his Signpost interview that his experience would have been better if his RfA had been put on hold when it was scheduled to end. Both RfA candidates with substantial opposition this year (SFR and Tamzin) have said that the 'crat chat was the least stressful part of RfA, because they were no longer obligated to babysit a discussion where you are under a microscope. When Wikipedia becomes stressful, we can just take a break. When RfA becomes stressful, you have to either withdraw or push through, continuing to respond to questions and reading opposes that sting. I also want to highlight this comment by SFR (it is in the discussion above), where he eloquently advocates for this change. I agree with it in its entirety. HouseBlastertalk 11:57, 7 October 2022 (UTC)
    Adding on to the above. Everyone appears to be in unanimous agreement that RfA is stressful. This is clearly a problem. Sure, actually being an admin is stressful, but I reject any argument that leads to the conclusion that stress at RfA is a good thing. Stress is bad. Reducing stress is good. We should not be making decisions to increase stress at RfA to "prepare the candidate". SFR has clearly and unambiguously stated that automatically putting his RfA on hold would have been a small step towards reducing anxiety during the process. Multiple recent RfA alumni have agreed with him, including Moneytrees, the admin with the longest successful RfA. By my count, there are 10 admins who have opposed this RfC. Of those 10, one went through RfA within the last decade. One. Also by my count, there are nine admins in this RfC who were "promoted" after WP:RFA2011, eight in support. With all due respect to the older generation of admins, I trust them less than the newest crop of admins to know what is wrong with RfA, and what would actually help fix it. The younger generation of admins is saying this is a solution to a real problem; I believe them. HouseBlastertalk 02:01, 12 October 2022 (UTC)
  • Support I see benefits to this change - which should be simply on a visible level, changing the background of the RfA to say, yellow, and noting that it is on hold pending bureaucrat closure. It should be simple to over-write if a 'crat wishes to actively extend the RfA. There are clear improvements to candidate wellbeing in doing so, and I am unpersuaded by the arguments against in previous section. WormTT(talk) 12:25, 7 October 2022 (UTC)
  • Support A small but sensible improvement to the RFA process. ϢereSpielChequers 13:33, 7 October 2022 (UTC)
  • Support- Putting my support behind this as the person with the longest successful RfA. Moneytrees🏝️(Talk) 13:39, 7 October 2022 (UTC)
  • Support Oh, so now it's a competition for who had the worst successful RfA?[FBDB] Valereee (talk) 13:43, 7 October 2022 (UTC)
  • Weak Oppose - I don't like the idea of late-comers being able to add to the discussion but not being able to be replied to just because of a redline. Are we expecting any editor or admins to enforce this with reverts or protections? — xaosflux Talk 13:48, 7 October 2022 (UTC)
  • Support per my comment above. -Ad Orientem (talk) 13:55, 7 October 2022 (UTC)
  • Oppose, discussions should be closed when they are done, not at an arbitrary cutoff. As long as RFA is a discussion, fixed time closure is bad. Also, bureaucrats unofficially extending by a few hours simply by not closing will be far less stressful on the candidate than an official extension that will cause lots of people to re-examine the candidate. —Kusma (talk) 14:30, 7 October 2022 (UTC)
  • As discussed previously, I feel that flexibility is one of the characteristics of Wikipedia discussions. We shouldn't give incentive to editors to drop in last-minute comments before a hard deadline. I would prefer addressing the root problem of how to make the process less confrontational. isaacl (talk) 15:47, 7 October 2022 (UTC)
  • Support per above. Small improvement, but we'll need more. Femke (talk) 16:11, 7 October 2022 (UTC)
  • Support seems like something small but straightforward to try out. Legoktm (talk) 16:26, 7 October 2022 (UTC)
  • Oppose. RfA is a discussion, not an election. If the community wants to make admin an elected postion, then do it properly in an RfC. Then, we can have a fixed ending time, secret ballot, etc. - Donald Albury 16:35, 7 October 2022 (UTC)
  • Oppose Hammersoft et al.'s comments above make it clear this is not an actual problem in need of solving. * Pppery * it has begun... 16:37, 7 October 2022 (UTC)
  • Oppose As I said above, I would only support automatic closure where the Rfa is clearly passing after 7 days - with say over 80 or 85% supports. Otherwise it is unfair to potential voters who only check in once a week, have exams, are on holiday or travelling, or are just busy. Johnbod (talk) 16:44, 7 October 2022 (UTC)
    I'm not sure how the current setup (sort of like the old unannounced amount of stoppage time) is more fair to those groups. The only thing that's going to be more fair for editors who are unable to participate during the 7-day period is a longer discussion period that is specified ahead of time. isaacl (talk) 20:38, 7 October 2022 (UTC)
  • Support, per my comments above. It costs us nothing, especially as bureaucrats will retain the ability to reopen for comments, and there's many folks at this point who've said it would reduce stress. Vanamonde (Talk) 16:52, 7 October 2022 (UTC)
  • Oppose. I followed the entire discussion above as it unfolded, am unconvinced that an additional four hours adds more stress than an RFA candidate should be able to manage, and see strict deadlines on such an important process as a slippery slope, as one cannot envision how that might affect future RFAs and unforeseen circumstances.
    To my knowledge, a delayed closing of an RFA has only been used abusively once, about fifteen years ago, and the "abuse" that occurred in that case was less about a latecomer having a delayed objection as it was about the specific makeup of the large group of editors who also happened to "miss" the RFA until the last minute and followed on the first oppose to completely flip the outcome; I don't see such shenanigans as being possible or likely in 2022. If such things occurred often, I would be in the Support column here; they don't, and are a rarity.
    In the particular case that led to this RFA, there are very clear indications of how the quite-minimal delay of a few hours may have added confidence in the eventual close of the RFA by the 'crats, as although a considerable last-minute issue surfaced in an oppose, no one but me (I think) picked up on that in the additional period. One wonders if this figured, to the candidate's benefit, in the 'crats final decision, and if it did, the extra time served a useful purpose; surely the 'crats took into account that, even with extra time, no one came back to oppose based on new findings, and they might have figured that in to the final outcome. That is, the extra time was potentially useful to the candidate, "stress" notwithstanding. Let's not bootstrap the 'crats unnecessarily, when there is no evidence this change will cause any measurable effect, but may lead to some difficulty in unforeseen circumstances. Four hours is nothing on the internet. If RFA is broke, this is not the fix. SandyGeorgia (Talk) 16:58, 7 October 2022 (UTC)
    In particular, I agree with the points raised in the preceding discussion by Kusma, Primefac, Hammersoft, TonyBallioni, WereSpielChequers, Xaosflux, Isaacl, SilkTork, Acalamari, John Cline, and Xeno, and in the Survey by Donald Aubry. SandyGeorgia (Talk) 18:06, 7 October 2022 (UTC)
  • Support as a simple fix to better align when the RfA template says discussion will be closed and when it actually is. There are sometimes good reasons to extend an RfA discussion, but that should be done deliberately, rather than as a quirk of when particular bureaucrats happen to be awake and available. 28bytes (talk) 17:16, 7 October 2022 (UTC)
    If the confusion is about the Scheduled to end verbiage, that is easily fixed to something like "Not ending before"... — xaosflux Talk 18:10, 7 October 2022 (UTC)
    That's what we do on metawiki, a recent RFA for example: meta:Meta:Requests for adminship/Daniuu. — xaosflux Talk 18:14, 7 October 2022 (UTC)
    Huh. 29 votes, all support. No need for nominators. No discussion. Talk page still redlinked. I'm running RfA on metawiki asap. Valereee (talk) 18:27, 7 October 2022 (UTC)
    Tell me about it! Talk about a land of milk and honey... 🌈WaltCip-(talk) 18:30, 7 October 2022 (UTC)
    They are certainly not always like that, samples of some unsuccessfuls recently: 1, 2. — xaosflux Talk 18:56, 7 October 2022 (UTC)
    That wording would even more blatantly postulate the fear that HouseBlaster alluded to above, of an RfA that could in theory might never end. Of course, we know in practicality they will be terminated on or shortly after that time, but there is the risk of introducing a new culture based on the subtle change in wording. 🌈WaltCip-(talk) 18:16, 7 October 2022 (UTC)
    Yeah, I think that would be a step in the wrong direction. I don’t mind if an RfA gets extended past 7 days for a legitimate reason, but that reason should be explicitly stated rather than just letting the RfA languish in limbo for however long. Otherwise, if a 'crat who is monitoring that RfA decides it ought to go on for a bit longer, how will other 'crats who come by know not to close it? 28bytes (talk) 18:59, 7 October 2022 (UTC)
  • Support - Look, our RfA reform didn't accomplish anything except WP:XRV which arguably has absolutely nothing to do with improving the RfA process. This is something. It's the tiniest of steps to make an arduous process LOOK more tolerable.--🌈WaltCip-(talk) 18:07, 7 October 2022 (UTC)
  • Oppose for several reasons, though I suppose the main one is that flexibility, discussion, and consensus are at the heart of the success of the Wikipedia community - inflexible hard rules or formats are not part of that. I dislike the idea of hard wiring any aspect of Wikipedia - there should always be room for flexibility and judgement, and all that flexibility and judgement offers. SilkTork (talk) 18:32, 7 October 2022 (UTC)
  • Support - I'd support as long as all RfA pages (going forward) have some kind of countdown timer to clearly let everyone know when voting ends, similar to the "Scheduled to end" text that already appears on an RfA, but with a live timer added. Something like "This discussion will be automatically closed at 13:55, 10 Oct 2022 (UTC), which is 3 days, 7 hours from now." This auto-closing change shouldn't force people to do calendar math to figure out how much time they have left to comment. As long as it's made clear up front, no one can reasonably complain. —⁠ScottyWong⁠— 19:30, 7 October 2022 (UTC)
  • Support - this is a solution looking for a problem. In the well over 400 RfA I've examined and voted on since 2009 and at least since writing WP:RFAADVICE in 2011, AFAIK it's never been raised as needing discussion. However, I see no harm in it and to satisfy the proposer I'll go along with it and per Scottywong - if for no other reason than the en.Wiki spans every time zone in the world, and according to our prefs the actual time displayed may be local or UTC. Kudpung กุดผึ้ง (talk) 19:55, 7 October 2022 (UTC)
  • Support I don't see this having any real impact but why not enforce the deadline shown on the trackers and notices. Terasail[✉️] 20:00, 7 October 2022 (UTC)
  • Support. Seems sensible and I don't find the opposing arguments convincing. Nurg (talk) 20:50, 7 October 2022 (UTC)
  • Support, per my earlier statements. Anything we can do to make any process slightly less stressful or negative when there is no appreciable downside should be done. Crats will still be able to extend discussion if they feel it necessary, only now it will be an active choice, rather than a passive result. It will also eliminate RFAs that don't need additional discussion from staying open unnecessarily and causing stress for the candidate. I don't see any real drawbacks that would be specifically caused by this change that aren't already present in the current system. Discussions can still be closed by crats even if someone recently made a point that some think should allow for more discussion. If a crat is around to close right at the deadline those who may be on vacation or unavailable still won't be able to contribute. Automatically placing an RFA on hold at the end of a week wouldn't change that. Just because someone doesn't place importance on the stress another has to undergo doesn't mean that they're lying about the stress being real, and about believing this to be a small, easy way to reduce it somewhat.
    As for concerns that this isn't a large enough change, so isn't worth doing, why? Maybe I've paid attention to too many lean and continuous improvement training sessions (I'm a six sigma brown belt!!), but it's pretty obvious that it's much easier to make smaller changes with small gains than to rebuild a system. Even if this change is only a one or two percent improvement, why is that a bad thing? It's still an improvement. Find a few other pieces of low hanging fruit and we can get a ten percent improvement without having to dramatically change any structure. We have a process that is working as-is, so why not make small improvements where we can? ScottishFinnishRadish (talk) 23:07, 7 October 2022 (UTC)
    +1. Anyone who hasn't experienced this should really be thinking harder and trying to empathize. We're talking about a cheap fix that can make life easier for those it affects. Valereee (talk) 23:15, 7 October 2022 (UTC)
  • Support. An RfA shouldn't be extended just because there's no one to put it on hold at the time. It's not the same situation as something serious coming to light at the last second which would cause the RfA to be extended. The former is more common compared to the latter (didn't this last happen several years ago?) and this can ease candidate stress by placing a more definitive end date. So to me, this seems like a fairly obvious support. Honestly I'm suprised this isn't already the case. There's a part of me that wonders if a community desysop procedure might be more useful for the latter situation if it's really something that would cause the majority of supporters to change their mind. But wouldn't something like that be almost guarenteed to come up in the actual RfA? People examine RfA candidates with extreme scutiny and it'd be weird if "a skeleton in the closet" would come to light just as the RfA is close to be closing. Yes, different individuals have different time schedules (that's why I didn't !vote in the last RfA) but if something is really that problematic, presumably you're not relying on any single person to point that out? Clovermoss (talk) 03:22, 8 October 2022 (UTC)
    To expand on my reasoning here a litle bit, in general RfAs end at 7 days. If the RfA is contentious, bureaucrats put the discussion on hold when they get around to it. My understanding is that this proposal is just making the "on hold" part automatic instead of arbitrary, not getting rid of bureaucrat's discretion for extending the RfA in extenuating circumstances. I get that RfAs are a consensus-building discussion and not a vote, but they are not meant to go on forever. 7 days is the commonly accepted timeframe. This is why this seems like the obvious choice to me. If that was to change, we'd need a seperate RfC. But to me, the concept of people having limited time to participate in the RfA and wanting to participate after it would normally have been closed is such an edge case I don't nessecarily see how it's worth it compared to the alternative. I think this is a small improvement as outlined by ScottishFinnishRadish and therefore think we should do it. To eloborate a bit on the "skeletons on the closet" analogy I made earlier, the slim chances of that happening at that late point in the RfA could happen at any point after an RfA, too.
    I think that this concern about extending RfAs for wider input was more important in the days of the community when there several going on all at once all the time. Nowadays it's a handful per year. The last cited RfA being extended that I know of was in 2007 when another candidate running at the same time did not notice that particular RfA and provided evidence of doxxing. That's an exceptional circumstance and not the same as "sorry RfA candidate, all the bureaucrats were busy/asleep until now". Clovermoss (talk) 12:37, 8 October 2022 (UTC)
  • Oppose. Could be incompatible with consensus decision-making. Also oppose further straight-jacketing of the bureaucrats in using their discretion to manage RfA, and diminishing the role of bureaucrats. It is entirely possible that new information may arise late in an RfA and extension of the discussion becomes important. While the bureaucrats are not known for relisting RfAs, this doesn't mean that it will never be a good idea. The proponents go too far in writing rules out of norms without good reason. It is better to leave it to a bureaucrat to close an RfA as finished. A bureaucrat may very well apply a timed template, but that action should be left to bureaucrats and not transferred to a rule to be implemented by non-bureaucrats. --SmokeyJoe (talk) 06:24, 8 October 2022 (UTC)
  • Oppose An RfA should be a discussion, not a vote. If new information arises near the end of seven days, the information should be discussed, not swept away with a bureaucratic close due to rules. Stress for candidates is unavoidable—that's regrettable but it is better than creating an admin who does not have the temperament to wait. Johnuniq (talk) 06:50, 8 October 2022 (UTC)
  • Support glad someone thought of this. Thanks,L3X1 ◊distænt write◊ 01:20, 9 October 2022 (UTC)
  • Support One week is a long time to set aside. Except for some extraordinary exceptions, no need to prolong it. Schierbecker (talk) 04:46, 9 October 2022 (UTC)
  • I incline to oppose along the lines of a number of editors whom i respect ~ SilkTork, Xaosflux, &c. I have not, however, undergone the particular stresses RfA may generate, so i'm not certain i have the moral right to oppose those who have and are speaking out in support; if they believe that this proposal will reduce any of those stresses, i guess i have to take their word and experience for it, and therefore Support. Happy days ~ LindsayHello 09:14, 9 October 2022 (UTC)
  • Oppose. I fully support the goal of making RFA less of a hell week, but I am unconvinced that this will achieve that goal whereas the downsides higlighted by others are much more likely to occur. Thryduulf (talk) 10:06, 9 October 2022 (UTC)
  • Support I think that the bureaucrats still have (or should have) the ability to extend the discussion if desired. --Enos733 (talk) 17:25, 9 October 2022 (UTC)
  • Support per SFR, and I support allowing crats to extend if they actively choose to do so per WTT. Best, KevinL (aka L235 · t · c) 01:47, 10 October 2022 (UTC)
  • I oppose forcing the RfA discussion's end by automation. I reject the premise of this being a small step in the right direction and instead see a moderate to large step in precisely the wrong direction. Something is wholey awry when a process is seen able to grant the title and tools of leadership yet incapable of effecting its closure by leadership means.--John Cline (talk) 03:03, 10 October 2022 (UTC)
  • Oppose. In cases where the outcome is obvious, there's no source of stress, and where it isn't the tenor of the last hours of edits is often discussed by the bureaucrats. And if a candidate honestly finds having their RfA open for a few minutes to hours extra such a stress, then adminship might be too stressful. Espresso Addict (talk) 05:33, 10 October 2022 (UTC)
  • Oppose No need to strictly enforce one week. It give a chance for later participants, and really it does not matter if closure is delayed. It does not matter that much if it is stressful for the candidate, as they can expect that as an admin as well. Graeme Bartlett (talk) 07:21, 10 October 2022 (UTC)
  • Support The benefits to RFA candidates outweigh the costs of reducing whatever minimal discussion is happening at the end of an RfA. One week is sufficient for discussion. We should be looking to make the RfA process more appealing to candidates wherever possible in order to encourage additional candidates to run. W42 17:05, 10 October 2022 (UTC)
  • Oppose. First, If someone decides to run in a RfA, they should learn to cope with the amount of stress caused due to non-closure of an RfA for 3–4 hours at max. That is what all of us should expect from prospective admins. Secondly, I feel that a "This RfA is on hold" or something along that line will be more stressful for a candidate with 75% support than an outright closure as successful or 'crat chat. If the closing 'crat finds that more discussion time is merited, that flowing discussion shouldn't be hindered by a yellow wall of template for hours until a 'crat finally reverts it. Thirdly, community has decided that RfA isn't a vote, as such, there should be no hard closes. If it were a vote, I would've most likely supported it. —CX Zoom[he/him] (let's talk • {C•X}) 18:55, 10 October 2022 (UTC)
  • Oppose. When this first came up above a few days ago, I was inclined to support, as a simple matter of efficiency, "fairness", and empathy towards those running. However, on further reflection, I do think we should be more open rather than less for discussions to take the time they need (even if often delayed closes are usually just logistics), and I worry about bad actors swamping discussions with supports/opposes carefully timed to avoid scrutiny if there is an enforced precise deadline. I am reassured that closure delays seems to rarely exceed a few hours, which doubtless feels painful to those running at the time, but is ultimately not long compared to potentially stressful situations admins may experience -- or better yet attempt to defuse -- during their tenure. Martinp (talk) 03:31, 11 October 2022 (UTC)
    Adding, in response to the "crats can reopen if there are last minute shenanigans" counterargument: the issue is not "new news" to which crats can respond by deliberately extending, but the implied final word (with less community review) for !votes coming in just before closing time. I fear this will lead to gaming when there is a guaranteed precise ending time. Like people putting in their bids in the last seconds in a silent auction at a party. We can't expect crats to decide to reopen just because somehow 5 opposes (or supports) came in during the last 3 minutes, indicating agreement with arguments raised before (that others earlier found less compelling in the discussion). Also adding: I think the younger generation feels their online personas, here and elsewhere, are much more part of their overall personal identity, so perhaps feel more stress from lack of a deadline? I'm of an older generation that views online interactions as secondary to the "real me". So it's easy for me to say "if you're feeling stressed, just turn off your computer and go for a walk. if your online account's RFA tanks it says nothing about your worth as a real, warm-blooded person. And it's not like the candidate does much while the discussion is ongoing anyway so just look away.". The latter is in contrast to e.g. policy discussions where one does need to keep monitoring to add to the discussion, if you feel passionately about it (with the caveat on bludgeoning of course). Martinp (talk) 12:26, 11 October 2022 (UTC)
  • Support per above. If it's abused by last minute votes, crats will just reopen it. Levivich (talk) 05:48, 11 October 2022 (UTC)
  • Support. Easy to override if necessary, but the important point is that it encourages applicants to go through the torture if they can have some more confidence about when it will end. Jmchutchinson (talk) 09:43, 11 October 2022 (UTC)
  • Support. As someone who went through the process several years ago and didn't have the emotional strength at the time to see it through at the first signs of scrutiny so ended up withdrawing, I think this is a great idea, not just to encourage more to run but also as a bit of a help to those already running to think 'I've only got to get to this date and time'. Mike1901 (talk) 10:00, 11 October 2022 (UTC)
  • Oppose. Discussions should run as long as necessary. Just putting in a set end doesn't help this. Also...I for once get more nervous the nearer an end of a "countdown" gets, so the set end might actually be more stressful. Lectonar (talk) 10:52, 11 October 2022 (UTC)
  • Oppose per Donald Albury and Graeme Bartlett. LEPRICAVARK (talk) 22:08, 11 October 2022 (UTC)
  • Oppose per above. I've read the supporting arguments and I'm very unconvinced this is a legitimate issue that needs solving. -FASTILY 23:16, 11 October 2022 (UTC)
  • Support. Perhaps it's a small thing, but if we can - in any way - reduce how stressful and frustrating RfA can be, we should. ♠PMC♠ (talk) 06:33, 12 October 2022 (UTC)
  • Oppose. As per SilkTork, while RfAs are probably the closest thing we have to a "vote" structure, they are still a discussion on the matter as well and should remain as much so as possible. Editors should remain free to comment until a bureaucrat actually says "That's it for this one, time to make a decision." Seraphimblade Talk to me 10:16, 12 October 2022 (UTC)
  • Support, anything that would potentially help get more admins would be welcome. Stifle (talk) 13:10, 12 October 2022 (UTC)
  • Support, a small change, but anything that could possibly help with the very toxic RFA atmosphere is worth trying. Jackattack1597 (talk) 01:52, 14 October 2022 (UTC)
  • Support, I find the concerns about flexibility and bureaucrat judgement unpersuasive. As worded, the proposals explicitly retains that flexibility and judgement. What the proposal changes is simply the default flow of the process. The talkpage would presumably remain open, as would other venues, and there's always the IAR post if something critically important comes up. This seems like a a small yet helpful change, which should be the easiest change to RfA that could be made. CMD (talk) 06:42, 14 October 2022 (UTC)
  • Support - A reasonable, common sense improvement. A week of agonizing scrutiny is more than enough to ask of someone, and it is a reasonable condition that the process should end when it's scheduled to end. Really just strikes me as the most minuscule measure of decency to extend to candidates. In the event of extraordinary circumstances where more discussion is required, crats are already permitted to extend the discussion as they see fit, so nothing else needs to change. ~Swarm~ {sting} 22:17, 14 October 2022 (UTC)
  • Support per the proposal analogue of "wait, they aren't an admin already?". We display the time remaining; why not live up to that? XOR'easter (talk) 18:29, 15 October 2022 (UTC)
  • Support. RFAs have a 7 day duration for a reason. Clyde State your case (please use {{reply to|ClydeFranklin}} on reply) 22:09, 15 October 2022 (UTC)
  • I oppose in agreement with SandyGeorgia and me. If, however, we bureaucrats suddenly started taking ages to close RfAs or if we regularly have loads of candidates each week, then I'm happy to revisit and reconsider. Acalamari 01:38, 16 October 2022 (UTC)
  • Support per SFR. I generally don't care much myself, as I'd prefer it be either ended immediately by crats or ended immediately by technical implementation stuff (but crats have to be viewing the discussion to revert the close if something flared up or they otherwise thought it was proper to extend the RfA under their discretion). It doesn't really change what I think the system should be; merely which the crats take (e.g. either to close the rfa or to not reopen the RfA). However, I'm more inclined to sympathize with a recent RfA candidate (side note: reading SG's cmt and consdidering my own recollection, the RfA likely merited a few hours' wait to close). —Danre98(talk^contribs) 20:13, 17 October 2022 (UTC)
  • Oppose. RfA is not voting, it is a discussion. If something came up on the last days of the discussion, it should be discussed. Admins are lifetime appointments, I expected all of their work to be closely scrutinized and questioned by all. Yes, it would be stressful on some contentious RFA, but most RFAs are straightforward and have no problems that need addressing on this specific matter. If the candidate is elected, RFA might be the final time they are questioned and scrutinized by the whole community, if they didn't create problems in the future there won't be any "re-certifying" of their adminship. In short, more discussion will not be bad for the project. ✠ SunDawn ✠ (contact) 16:28, 19 October 2022 (UTC)
    @SunDawn: Bureaucrats would retain the discretion to extend the RfA; this proposal is trying to address the accidental extension of the RfA by default because a crat hasn't gotten around to it. Best, KevinL (aka L235 · t · c) 23:52, 19 October 2022 (UTC)
    In that case I would change the vote to Support. ✠ SunDawn ✠ (contact) 01:08, 20 October 2022 (UTC)
    As far as I'm aware (and someone please correct me if I'm wrong) there has never been an accidental extension of an RfA. Crats manage to deal with a RfA (to close, extend, or start a Crat Chat) on the 7th day. Where Crats may be a bit slow is not in closing a RfA, but in closing a Crat Chat. The Crat Chat for the RfA in question, took 44 hours, extending the decision by almost 2 days. Now, if someone says what we should do is close Crat Chats within 24 hours of the close of an RfA (which seems reasonable) then ScottishFinnishRadish would not have been promoted to admin, because 24 hours after the Crat Chat was opened, the result would have been 4 Crats saying No consensus against 3 Crats saying Promote. Now, we can have rushed decisions in order to save a candidate some anxiety, or we can have considered decisions. My assumption is that candidates would rather have a considered decision, even if that means waiting a little longer. SilkTork (talk) 23:52, 20 October 2022 (UTC)
    There has been no accidental extension by more than a day, but that isn't the issue. This proposal is about no longer leaving RFAs open for a few hours. ϢereSpielChequers 09:39, 21 October 2022 (UTC)
    This isn't about accidental extensions or crat chats not being conducted quickly enough. Purely about any RfA that doesn't need to be extended itself being closed while crats decide whether a crat chat is needed. Purely about allowing the candidate to breathe a sigh of relief that a discussion that has basically petered out is now completed and they can go offline. Candidates in the discretionary zone know the crat chat could take a while, but in the meantime there isn't anything they need to keep checking in for at the RfA itself. Valereee (talk) 12:06, 21 October 2022 (UTC)
  • Support. Anything to alleviate stress and lower the bar. Nardog (talk) 16:35, 19 October 2022 (UTC)
  • Support. Costs us nothing, seems fairer, definitely less stressful, and if it turns out to be a mistake it can always be changed again. BastunĖġáḍβáś₮ŭŃ! 09:30, 21 October 2022 (UTC)
  • Support: an RfA that has been open for a week and does not have enough discussion is a farcical concept based on its state over the last decade, particularly in recent years. There is more than enough scrutiny on candidates. IAR would suffice as justification for re-opening discussion if some revelation came about at the 6 day mark (something I don't know has ever happened). RfAs open for exactly 1 week strikes me as a better rule than "a week and a little bit until a crat is online". I can't see an oppose that points to the last time an RfA was deliberately extended through non-closure just past the one week mark, and that extension was useful in some way. — Bilorv (talk) 12:53, 21 October 2022 (UTC)
  • Support: RfAs are important because other than ArbCom elections, they decide who get the mops. That being said, if anything can change the result of an RfA after a week, then talk page posts will still show up on watchlist. RAN1 (talk) 22:05, 25 October 2022 (UTC)
  • Support - It was quite a surprise to me when I first found out that the one week time period wasn't a hard deadline, and that votes could keep coming in after it had passed if no bureaucrat had closed the request. If I'm understanding this correctly, it seems like a good way to make that close a hard one. Also, to whomever commented above that RfA is "not a vote it's a discussion", while this is true in other places (AfD, RfC), it's not really true in an RfA. While bureaucrats certainly have some discretion, it is de facto only within a range of votes as determined by hard numbers. Beyond My Ken (talk) 02:13, 27 October 2022 (UTC)
  • FWIW, I also support bureaucrats having the ability to extend the request for a longer period if -- in their collective opinion -- they need to get a better read on the community's feelings; although I trust that the discretion to do so would not be utilized regularly. Beyond My Ken (talk) 02:16, 27 October 2022 (UTC)
  • Support Makes the process less stressful and should be straightforward to implement. SpencerT•C 01:15, 30 October 2022 (UTC)
  • Support Running for RfA is stressful, a whole 168 hours of it is plenty long enough, and we should give candidates certainty that once the time is up, it all finishes automatically. SFR's wife put it quite eloquently; the way we currently organise ourselves is "dumb". Schwede66 01:01, 1 November 2022 (UTC)
  • Oppose. I don’t see the need. --Malcolmxl5 (talk) 08:36, 1 November 2022 (UTC)
  • Conditional support, condition being that it is something done manually and not automatically. Say someone discovers something that might be important to the RFA a few minutes before it's put on hold. The implication I get from it being automatically put on hold is that said person discovers this thing, and then shortly after the RFA is put on hold, resulting in discussion regarding said discovery not being able to happen. If it were done manually then the time needed for it to be put on hold could be extended or shortened, depending on the situation. ― Blaze WolfTalkBlaze Wolf#6545 16:32, 1 November 2022 (UTC)
  • Weak support I do understand the people who are arguing for not closing due to the potential for a "late rally" that may help a borderline case, but I think that balances out by the value in standardization here. Having them all last exactly the same time has a small net benefit of having a clearly defined end to the process. There is an element of fairness in that that I kinda agree with. Only a little. --Jayron32 18:13, 1 November 2022 (UTC)

Discussion (putting RfAs on hold)

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

Procrastination at RfA

It has been made abundantly clear that a user may transclude their RFA when they are ready to do so. Vanamonde (Talk) 19:02, 7 November 2022 (UTC)

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

How likely will an RfA nominee delay transcluding their RfA (which is apparently the case with Wikipedia:Requests for adminship/JPxG, for example)? An ideal RfA nominee should transclude their RfA as soon as they have finished answering the three standard questions. GeoffreyT2000 (talk) 15:46, 7 November 2022 (UTC)

I notice that you recently took an RfA nomination page to MfD where it was kept so this is obviously something you care about. I can think of any number of reasons why a candidate would choose to delay after answering the standard 3 questions - here are two: maybe the time they expected to have changed or maybe they're rethinking being the center of wiki-attention. Since even candidates that pass unanimously are, in my fairly tested judgement, not ideal candidates (we're all human so we all have wiki shortcomings) is ideal even the standard we should be using? Even if the answer is yes, why do you feel that an ideal candidate launches as soon as they've answered? Best, Barkeep49 (talk) 15:54, 7 November 2022 (UTC)
In the interests of transparency: if/when that RfA launches I will have a small (non-nominator) role to play so I've been aware of it. But my questions above are not about that RfA but more generic to all RfAs which this also is presumably asking about. Best, Barkeep49 (talk) 16:05, 7 November 2022 (UTC)
An ideal RfA nominee should not transclude their RfA until they are ready for it to start. —Kusma (talk) 15:55, 7 November 2022 (UTC)
I delayed my RfA by a day because I wanted to start the process when I would have more time to answer questions. I also wanted to proofread my answers to the standard questions. I do not see the harm of having untranscluded RfAs on Wikipedia. Z1720 (talk) 16:00, 7 November 2022 (UTC)
Just as with any page they are working on, editors can prepare it ahead of time, and then choose to make it active (whether that requires moving it or transcluding it) at a time suitable for them. isaacl (talk) 16:01, 7 November 2022 (UTC)
I'm amazed that anyone would care that someone didn't transclude immediately. I see no issue with a non-translcuded RfA unless the clock had already started. I don't see why we would police people embarking on one of the most stressful things that you can possibly do on-wiki. Lee Vilenski (talk • contribs) 16:15, 7 November 2022 (UTC)
Maybe they're waiting for more nomination statements or they have a particular time in mind? There's any number of reasons somebody might not transclude immediately (or at all even) but it's nobody else's business. It does no harm if it sits there forever. On the other hand, there are 6.5 million articles in the mainspace that could benefit from your attention. HJ Mitchell | Penny for your thoughts? 16:27, 7 November 2022 (UTC)
Kusma summed it up eloquently. Mz7 (talk) 18:38, 7 November 2022 (UTC)
I have nothing much more to add that hasn't been said above, but I do believe Kusma said it best. Primefac (talk) 18:57, 7 November 2022 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Inactive Admins

Not really my place to make a comment at the Bureaucrats' board, but i would just like to point out here how pleasing it is to see, after the notices of impending desysopping going out, three inactive admins, so far, coming along and confirming their inactivity in order to have the buttons switched off immediately. I know that there have been a number of occasions when it has seemed that the activity requirements might be or might have been gamed; seeing the opposite is a real pleasure and gives me faith that, no matter the issues with RfA, in the end we do tend to end up with trustworthy and responsible admins. Happy days, indeed ~ LindsayHello 23:22, 1 December 2022 (UTC)

I really appreciate and respect those admins as well. Best, Barkeep49 (talk) 23:30, 1 December 2022 (UTC)

Pending closure?

Why does the RfX template say that Wikipedia:Requests for adminship/Extraordinary Writ is pending closure? We're not even a day in. Clovermoss🍀 (talk) 04:06, 9 December 2022 (UTC)

I notice that I'm not actually using the right terminology. I'm actually referring to User:Cyberpower678/RfX Report here, which some userpages have and why I was under this false impression. Clovermoss🍀 (talk) 04:08, 9 December 2022 (UTC)
This relates to #RFA max time holds - technical implementation above; thanks for the notice, I'm working on a fix. I've changed the existing nominations and the bot should (in theory) update the page accordingly. Primefac (talk) 08:52, 9 December 2022 (UTC)

Question about Template:RfA/readyToStart

Moved to User talk:Primefac

Primefac (talk) 08:16, 11 December 2022 (UTC)

RFA max time holds - technical implementation

Now that the RfC above passed, whatever is going to be done needs to be created. Have a crat come by and manually do something should certainly not be part of the solution (as the premise above is that 'crats may be delayed). — xaosflux Talk 12:31, 6 November 2022 (UTC)

Using Wikipedia's syntax magic should be the correct solution - an edit filter or titleblacklist addition as suggested in Wikipedia:Bureaucrats' noticeboard#RfAs should now be automatically placed "on_hold" after 168 hours is needlessly too much. Anyone !voting after the automatic closure can be reverted by any user, and I don't believe it would cause any drama. DatGuyTalkContribs 12:35, 6 November 2022 (UTC)
Have the template add {atop}/{abot} (or equivalent) at 168 hrs after start. Levivich (talk) 14:36, 6 November 2022 (UTC)
Anyone should feel free to make and test sandbox mock ups, if you get something that works and can't edit the main just open an edit request. — xaosflux Talk 15:09, 6 November 2022 (UTC)
Inspired by the syntax we use to hide the nomination text box at WP:ACE2022/C before the start of nominations, I have just created a {{Hide until}} template that hides the specified text until the specified date. We could use this to do something like: {{hide until|<!-- RFA end time -->|text= {{Rfah}} }}. Mz7 (talk) 08:15, 7 November 2022 (UTC)
I was thinking {{Show by date}} originally but {{hide until}} is probably the better option here. All it would mean is adding that in to the RFA preload. Primefac (talk) 11:26, 7 November 2022 (UTC)
Looks like a great idea, @Primefac. I just want to note that I oppose using an edit filter as suggested here. Best, KevinL (aka L235 · t · c) 17:04, 7 November 2022 (UTC)
Agreed on the filter, also oppose a bot (even though we seem to have moved past that as an option). Primefac (talk) 18:53, 7 November 2022 (UTC)
Oh wow, admittedly I didn't even know that {{show by date}} existed. Looking at the documentation, that template seems to be limited to only the top of the hour (even {{show by}} uses math to round to the nearest hour). {{Hide until}} should be able to hide until down to the second if you give it a valid {{#time:}} expression. Mz7 (talk) 18:37, 7 November 2022 (UTC)
Yeah, it's not one I see (or come across) all that often, and every time I think about it I have to spent 15 minutes looking for it! As you say, {{hide until}} has a better timing so that would probably be the best way to go. I'm a bit annoyed because I actually had sandboxed the RfA preload when the RFC started turning in that direction, but I didn't save it (though it was easy enough to make so I wasn't too concerned). I'll see if I can whip something up tonight. Primefac (talk) 18:53, 7 November 2022 (UTC)
By using a template, will we have any problems with purging? That is, maybe the RFA will expire, but the template will not be smart enough to display it as such until someone edits the page, due to the page not being WP:PURGEd. –Novem Linguae (talk) 19:52, 7 November 2022 (UTC)
Maybe, but if you think about it potentially having *one* extra comment isn't the end of the world. Primefac (talk) 19:57, 7 November 2022 (UTC)

Coding v1 complete

I have created {{RfA/readyToStart}}, in which I pretty much sandwiched everything from that first paragraph (and got rid of some of the horribly awkward "scheduled to end" nonsense that shouldn't have shown up anyway). All of this I have placed into Template:RfA/sandbox for review. I also have done a dry run as proof-of-concept [updated 06:53, 13 November 2022 (UTC)]:

Now, the one potentially problematic element here is that there really isn't a good way to get {{rfab}} at the bottom of the nomination and have it only display when time is up. So at the moment, either it's always there awkwardly or we need to start putting {{-}} transclusions after RfA noms when they're put onto WP:RFA. If anyone has ideas for this I'm all ears (one not-ideal example would be having someone copy the {{hide until}} template after the nomination is live to place the rfab at the bottom). Primefac (talk) 11:03, 8 November 2022 (UTC)

Perhaps I'm missing something—is there an issue with putting the appropriate code to enable the {{rfab}} template at the right time at the bottom of {{RfA}}? Not sure if there would be a time synch issue between the top and the bottom of the enclosing box, but I imagine they would synch up again after a second or three. isaacl (talk) 21:46, 8 November 2022 (UTC)
Yes, and it's one of substitution. When someone creates a nomination (either through Wikipedia:Requests_for_adminship/Nominate or directly) and they substitute {{RfA/subst}}, none of the times are yet fixed (in either {{RfA}} or its sandbox), because the nomination is likely not yet ready. It is only when the page is ready to go that the time function (whether through {{RfA/time}} or this new subtemplate) is substed and the "clock starts" so to speak.
In the interest in making this sort of thing as easy and straight-forward as possible, I did not include any sort of transcluded time template at the bottom of the page. I am more than happy to do so, but it does mean that when the nominee is ready to transclude they will have to remember to subst the hidden {{rfab}} call as well. If you/others think that this is not an overly large burden on the nominee, then of course I will code it up; I just think (as a cynical template/real-life programmer) that it will get done after the fact more often than not. Primefac (talk) 08:09, 9 November 2022 (UTC)
Perhaps the generated deadline date/timestamp can be selectively transcluded into the footer. isaacl (talk) 16:31, 9 November 2022 (UTC)
I can test it out, but my guess (and honestly, it's just a guess) is that a transcluded timestamp won't work. Can't hurt to try though. Primefac (talk) 17:02, 9 November 2022 (UTC)
Update: it works if the timestamp is on the page itself, but until the "ready" template is substed there is no timestamp, so there's nothing to transclude. I suppose I could hide a fake timestamp inside some sort of "display:none" span, but then the editor would have to remove that as well; not sure how much hidden stuff there should be. Primefac (talk) 15:02, 10 November 2022 (UTC)
Adding additional hidden stuff for a nominee/nominator to sort out is not ideal. Best, Barkeep49 (talk) 16:07, 10 November 2022 (UTC)
It's been a while since I worked with selective transclusion but I think it returns nothing (rather than an error message) if there is no matching labelled section? If so, then I believe the code can be written so that the {{rfab}} template is omitted in this case. isaacl (talk) 16:33, 10 November 2022 (UTC)
That's LST not selective transclusion, but yes, you are correct; I'll see if adding an extra #if statement sorts it out. Primefac (talk) 16:53, 10 November 2022 (UTC)
Sure; the help page I linked to uses the term to cover section header-based transclusion, labelled section transclusion, and "the parameterization method" (which I haven't looked into and don't know anything about it). Thanks very much for your efforts! isaacl (talk) 21:29, 10 November 2022 (UTC)
My apologies, I didn't realise there was an LST subheader further down the page. Primefac (talk) 10:45, 11 November 2022 (UTC)
I just tried this in my sandbox, and it put the discussion on hold immediately (diff). I am guessing that {{hide until}} does not like the <section begin><section end> tags. Are there problems with this solution? HouseBlastertalk 21:44, 12 November 2022 (UTC)
No, but I've just done something more elegant. I've updated the permalinks above as demonstration. Primefac (talk) 06:53, 13 November 2022 (UTC)
The only other thing I can think of is trying to close as successful/unsuccessful to make sure it is working/update documentation as needed, which I leave to 'crats to do. Otherwise, I think we are ready to "go live". HouseBlastertalk 18:12, 14 November 2022 (UTC)
The documentation for how to close is terrible anyway, so I might use this as an excuse to improve it (I assume that's the "last step" you're referring to, if not please let me know). Primefac (talk) 09:08, 15 November 2022 (UTC)
Sorry for not being more clear—that is exactly what I was referring to. HouseBlastertalk 13:24, 15 November 2022 (UTC)
Coolio. If no one has issues with it in the next few days, I'll pop it live. If anyone puts up a nomination before I do that, I'll make sure the code ends up in there so at the very least we can get a "trial run" of sorts. Primefac (talk) 13:28, 15 November 2022 (UTC)

It has been a week and there have been no objections, so I think we are good to go. I am not about to try to make the change myself, because I would probably find some way to break things (is it as simple as copy/pasting [correctly, of course]? Or would things substitute themselves?). I also do not believe I should be updating documentation for something I have never done myself. In other words, I am asking for User:Somebody "Notme" Else (who I hear is really good at not breaking wikitext) to do the work for me. HouseBlastertalk 02:53, 22 November 2022 (UTC), edited for clarity 22:35, 22 November 2022 (UTC)

There were a number of things that caused me to not implement this over the weekend; I'll get to it at some point today I have now done so. also, I fixed your outdent, feel free to revert if you prefer it your way. Primefac (talk) 08:35, 22 November 2022 (UTC)
Thank you so much, Primefac. If being busy was not okay, I would have been SBAN'd long ago. An additional thank you for the outdent fix! HouseBlastertalk 22:35, 22 November 2022 (UTC)
I was away for a long time. I notice that rfab is coded at the bottom of the RFA. In my opinion, it is not ideal to have such templates at the end of "General comments" section. Editors (experienced or not) would be commenting there, and there's a good chance that comments would be added below the template. —CX Zoom[he/him] (let's talk • {C•X}) 14:54, 29 November 2022 (UTC)
I think the comment that says DO NOT EDIT BELOW THIS LINE is sufficient. In any event, I am not sure how you could close the <div> without having something at the bottom. HouseBlastertalk 16:05, 29 November 2022 (UTC)
Yeah, I spent a ton of time working and thinking about it, and it finally came down to either having no rfab or hardcoding it in. It screws with the main WP:RFA page if it's not hardcoded, so the note was the best I can do. We'll see how well it works when the next nomination drops (unless someone has a better idea before then). Primefac (talk) 18:03, 29 November 2022 (UTC)
Just as I had expected, there were comments below the rfab line (Special:Diff/1126511904), despite instructions asking to do otherwise. Well, tbf instructions being shown in the same visual style as the rest of editing interface inadvertently causes a blind eye to what it says. I've faced it many times. Unless you know that there has to be something at that place, you just miss that. —CX Zoom[he/him] (let's talk • {C•X}) 19:36, 9 December 2022 (UTC)
Let see if Special:Diff/1126653105 does it. If there's no further issues and no major opposition to that change, I'll put it into {{RfA}}. Primefac (talk) 14:11, 10 December 2022 (UTC)
My guess is that there are enough people who expressed interest in having the comments stopped precisely after seven days who can move the closing bit as needed when the time has elapsed. isaacl (talk) 21:02, 29 November 2022 (UTC)

First live test case

Noting that we have our first RfA with the new coding. I don't believe anything special needed to happen on launch for this to work, but confirming that this is the case. Best, Barkeep49 (talk) 23:23, 8 December 2022 (UTC)

I don't know if the issue reported by Clovermoss is related. When the changes were being implemented, I thought about asking that a test be done with the Lua-generated report, but after thinking about it, I didn't think it could be affected. However I didn't think about asking for a test with Cyberpower678's RfX report... isaacl (talk) 04:15, 9 December 2022 (UTC)
I'm working on a fix. The bot report should get updated automatically once I hotfix the existing ones. Primefac (talk) 08:49, 9 December 2022 (UTC)

Coding ver. 2 complete

I decided to overhaul everything to fix the issues; {{subst:RfA}} will now pre-load a template, with the relevant editors only needing to change the values of a few parameters. When all set, they can subst the subtemplate and it will then hard-code the three timestamps that are needed for the bot and the auto-hold templates. Hopefully this should fix everything, but I'll keep testing to make sure there are no funny issues.

There are some minor things I still plan on changing, namely some of the prompts and pre-loaded statements, but from a "we need to fix the code, NOW" standpoint I think we're good to go. Primefac (talk) 09:37, 9 December 2022 (UTC)

Extraordinary work, Primefac. Thanks! I really like the new {{RfA}} design, and it seems clear now this is how it should have been implemented from the start (i.e. since the template was created in 2005). Gone are the days of a big red notice telling prospective candidates to mess around with a "time parser function" [1]. Mz7 (talk) 11:46, 9 December 2022 (UTC)
Thanks. I think with version 1 I was trying to fenagle in a new version with as little change as possible to the original, which in hindsight was rather silly of me. I guess it's a good thing it broke? ;-) Primefac (talk) 11:49, 9 December 2022 (UTC)
Thank you so much, Primefac. I believe the third permalink should be to Special:Permalink/1126436968, but that is my only complaint. As an added bonus, it should prevent !voting before transclusion... HouseBlastertalk 13:59, 9 December 2022 (UTC)
How would I do a 2nd nomination with this new template? Best, Barkeep49 (talk) 14:31, 9 December 2022 (UTC)
It appears that the template takes an optional |nomStatement2= parameter, which hides itself if empty. HouseBlastertalk 15:41, 9 December 2022 (UTC)
Sorry I wasn't clear in my question. Not a co-nomination statement. How do I nominate a user for their 2nd RfA? And I ask this having experimented at Wikipedia:Requests for adminship/Nominate which is where I start when I am ready to nominate someone. More broadly it feels like those instructions need to be updated as I think this revised template needs to be handled slightly differently? To be clear I like what Primefac has done here and am just doing a bit of stress testing. Best, Barkeep49 (talk) 15:46, 9 December 2022 (UTC)
Same as before, you would put the username with a number in the field where Wikipedia:Requests for adminship/USERNAME is above the "nominate X" button. I'll get to updating that page's documentation tomorrow. Primefac (talk) 16:02, 9 December 2022 (UTC)
Did the old template break when we did that also? Because this one definitely does. 2nd/3rd noms are infrequent enough that maybe I've forgotten. Best, Barkeep49 (talk) 16:03, 9 December 2022 (UTC)
The short answer is yes - you would have to change the {{subst:SUBPAGENAME}} to the specific user name. I'll make sure that's a bit more obvious in the documentation when I go through it. Primefac (talk) 16:11, 9 December 2022 (UTC)
Just as an update to this, I don't really see anything at Wikipedia:Requests for adminship/Nominate that needs to be updated with the new template, since the setup/loading is still the same. I might tweak the {{RfA/subst}} message to indicate that subsequent RfAs will need a parameter value tweak. As a minor note, yes, Barkeep49, folks were needing to pull the "2" before this switch. Continuing feedback is always welcomed as more bugs gets uncovered. Primefac (talk) 08:13, 11 December 2022 (UTC)

First RfA closed

In just 5 minutes the first RfA since the change will end, and we will see if there are any problems. Thingofme (talk) 23:07, 15 December 2022 (UTC)

From where I am standing, it looks like things went okay? HouseBlastertalk 00:16, 16 December 2022 (UTC)
Let's ask the test subject: Extraordinary Writ, as the first person to go through RfA with the new template, how do you feel? Please let us know if you're experiencing any symptoms such as nausea, lightheadedness, or double vision. Levivich (talk) Levivich (talk) 01:23, 16 December 2022 (UTC)
Now that you mention it, Levivich, there is something going on with my vision: on my watchlist, I see a mysterious button that says "block" right next to your username. Wonder what that does.... (Aside from that, no complaints about the template on my end.) Extraordinary Writ (talk) 01:34, 16 December 2022 (UTC)
I heard a rumor that the button labelled "delete" on this page gives you another 100% pay raise, on top of the one you received for becoming an administrator. HouseBlastertalk 02:08, 16 December 2022 (UTC)
I mean, obviously the first thing a new admin should do with their tools is to ensure their permanent entry on Wikipedia's monument to greatness. Ed [talk] [majestic titan] 05:45, 16 December 2022 (UTC)

Ability/Mechanism to disable annoying push notifications

Hey,

Is there any mechanism to explicitly turn off the push notifications on the top of my watchlist every time a new RfA is advertised. I have tried dismissing these "RfA type" notifications multiple times, but they still keep coming back when a new RfA gets posted and it is genuinely distracting. I am not interested in the general governance side of the project right now, and I have no idea who these editors are (no offence to them) since I generally stick to mostly technical areas and/or technical articles (+ general cleanup and vandalism reverting when I get time).

Also, AFAIK this is not a MediaWiki-core/extension's feature, if it is, I'll be happy to file a issue on phab and provide a gerrit patch to enable such a mechanism if it is not already present. :)

Regards, Sohom Datta (talk) 15:19, 10 December 2022 (UTC)

Special:Preferences#mw-prefsection-centralnotice-banners ? Cabayi (talk) 15:38, 10 December 2022 (UTC)
I have all of those turned off on English Wikipedia, but it doesn't appear to make a difference :( Sohom Datta (talk) 16:02, 10 December 2022 (UTC)
Wikipedia:Watchlist notices#How to hide the notices should help. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:10, 10 December 2022 (UTC)
Ah, okay yeah that does help :) I assume there is no way to just disable just RfA/RfB notices ? (I do like getting a notification for the Signpost) Sohom Datta (talk) 16:15, 10 December 2022 (UTC)
You can subscribe to Signpost. And if you don't want that red notification, you can subscribe to that on one of your user talk subpages, like I did at User talk:CX Zoom/Newsletters/Current year. —CX Zoom[he/him] (let's talk • {C•X}) 16:20, 10 December 2022 (UTC)
Every notice should have a "don't display this notice again" link. I have all my notices turned off but I'd much rather be able to select only certain notices to turn off. Would support a phab ticket for this but I'm guessing one already exists. Levivich (talk) 16:23, 10 December 2022 (UTC)
Recurring notifications could have a specific CSS class placed on its enclosing list item, thus allowing a user to customize their CSS (or for a gadget to be written to help customize their CSS) to hide the CSS classes corresponding to categories of notices in which they aren't interested. isaacl (talk) 18:18, 10 December 2022 (UTC)
Are there specific categories of notices you have in mind? When I asked about this at MediaWiki talk:Watchlist-messages#Categorizing recurring watchlist notice items with a corresponding CSS class, it was suggested that RfX and Signpost notices are the only ones that recur with sufficient frequency to warrant suppression, but perhaps there are some being overlooked. isaacl (talk) 06:11, 18 December 2022 (UTC)
I guess the Arbitration Committee election message would repeat, but I'm not sure we want to allow people to snooze that ? Sohom Datta (talk) 15:47, 18 December 2022 (UTC)

Is a reason for oppose required

If I oppose an RfA, am I required to state a reason? I am not asking in response to a particular candidacy, as none or open at the moment. I am asking in regards to the general voter, which is not a new account or under suspicion of manipulation. Is there a risk that my vote will be removed or stricken if I don't give a reason, or respond to questions / negative comments about my reason or lack thereof?

I understand that some people will think poorly of the vote or my judgement, but that is not the question I'm asking. If half of all voters oppose, even if many do not give reasons, and if these voters are found to be long-term editors and not single-purpose accounts or meatpuppets, the guideline strongly suggests that the RfA will be unsuccessful. Is this under dispute? —Lights and freedom (talk ~ contribs) 03:47, 9 November 2022 (UTC)

1) No - typically a high number of supports don't give a reason, or a full one. But it is a good idea to give some explanation, even if just by reference to others. 2) No, not in dispute. In fact the number of opposers needed for a fail is less - around 35%. See the explanations on the Rfa page. Johnbod (talk) 04:48, 9 November 2022 (UTC)
Giving a decent reason makes your !vote less likely to be downweighted or discarded when the RFA is in the discretionary range (65-75%), which is the range where bureaucrats start treating it more like a regular RFC and start weighing strength of argument. –Novem Linguae (talk) 05:11, 9 November 2022 (UTC)
Yes, a reason is required. Your vote won't be stricken, but it could be ignored by bureaucrats if the RfA is closely divided. When supporters at RfA don't give reasons, it is generally implied that they endorse the reasoning expressed by the nominators. However, if you are the first one to oppose a candidate, it is expected that you should provide reasons for disagreeing with the nomination. If there is already an oppose section, and you wish to pile on, I would still strongly encourage you to still provide a reason, even if it's just an "oppose per user X", or you do risk your view being downweighted as Novem Linguae mentioned. Mz7 (talk) 05:43, 9 November 2022 (UTC)
Neither are required to give a reason, but the bureaucrats give more weight to opposers than supporters, so supporters are best advised to give reasons. Hawkeye7 (discuss) 06:19, 9 November 2022 (UTC)
Speaking as a 'crat, a reason is not required for either supports or opposes, nor do we "ignore" !votes without explanations (in either direction). If a reason is given, of course, it makes it much easier to weigh the opinions of the discussion, but pile-on opposes are often treated (at least by myself) as "per the other opposes", which still does add weight to the opposition arguments that were made. I do realise that I do not speak for all of the 'crats (and some do heavily discount no-reason opposes) but it is less of a case of "requirement" and more a case of "how much you want your opinion to be counted". Primefac (talk) 09:26, 9 November 2022 (UTC)
Hi! Like Primefac I don't believe one to be "necessary", but I do think there is a moral reason to comment why you would oppose. Whilst I think every comment should have some rationale, I understand why people don't have a specific reason to support a nomination. I know some people support because they don't have a reason to oppose. In contrast, saying "oppose" because you don't have a reason to support isn't all that convincing. I wouldn't discount such a !vote, and considering that RfAs are based on a ratio of support to oppose !votes (at least until a cratchat) then these !votes are inherently valid.
If I'm honest, I find the moral aspect to be more convincing on why you shouldn't leave no comments more valid. There is, after all, someone on the other end of the !vote, who has dedicated a lot of time to the improvement of Wikipedia. An oppose !vote is saying you don't believe that person to be trustworthy enough to use the toolset (or a similar argument), so an uncommented oppose !vote, or what we see quite often - a bizarre reason to oppose (such as the "should not be unanimous") - are potentially quite upsetting to the user.
I'm not saying don't do it - but also maybe think about the reasons a bit more thoroughly. It's a civility thing to me, and why we also shouldn't jump on opposers, who also don't want biteback for doing what can be a hard task - saying no to a volunteer. Lee Vilenski (talk • contribs) 10:33, 9 November 2022 (UTC)
RfA is a discussion. Opposes, supports, and neutrals generally contribute to the discussion process more when they contain substance. — xaosflux Talk 12:01, 9 November 2022 (UTC)
If you want to sink an RfA, you do it through the comment (and "damnning" diff) you make while voting. It matters very little whether that comment happens in the oppose, neutral, or even support sections. It can be beneficial to the candidate if you do not leave a comment. —Kusma (talk) 17:21, 29 November 2022 (UTC)
I've seen an oppose !vote struck out in an RfA that was otherwise unanimous because the rationale basically amounted to "nobody's perfect". I think under similar circumstances when the level of support is so massive, it's highly likely that an oppose !vote with no rationale will be given the same treatment. 🌈WaltCip-(talk) 18:18, 24 December 2022 (UTC)
Oppose Pobody's nerfect. — xaosflux Talk 18:23, 24 December 2022 (UTC)

Unfiled RfAs

I put together a weekly report listing RfAs that have yet to be filed. None of these appear to be in need of immediate attention, but I imagine that this info may be of interest to at least some of the folks who watch this page. -FASTILY 05:30, 30 December 2022 (UTC)

There are some unfiled RfAs were WP:NOTNOW editors, and mostly abandoned their intentions of getting adminship after reading they are not yet qualified. Thingofme (talk) 14:12, 31 December 2022 (UTC)
Only three in the list appear to have any chance of passing now, and one is already an admin. That said, there have been some outliers in the past. Dsuke1998AEOS (talk) 14:26, 31 December 2022 (UTC)
Should these pages be deleted? For me they are mostly junk contents except for JPxG's RfA. Thingofme (talk) 15:08, 31 December 2022 (UTC)
Maybe they should be treated like abandoned drafts; no edits in 6 months = deletion. --Hammersoft (talk) 16:05, 31 December 2022 (UTC)
Is there a particular need to delete them? Writ Keeper ⚇♔ 16:07, 31 December 2022 (UTC)
I mean RfAs are farther from encyclopedic content than Drafts are and if we think under NOTWEBHOST it's appropriate to delete drafts after 6 months, why not unfiled RfAs? Best, Barkeep49 (talk) 16:46, 31 December 2022 (UTC)
Well, why not user pages? Or project essays? Generally speaking, I think we don't delete things unless there's a compelling reason to do so.
For drafts, my impression has always been that drafts *look like* Wikipedia articles; even if they're noindexed and all that jazz, someone could easily follow a hyperlink, miss (or misunderstand) the "Draft:" prefix in the title/URL, and think they're reading a real Wikipedia article--which I have actively seen happen with some of my non-editor friends--so we fight that by making draft space impermanent. That doesn't apply to unfiled RfAs, since nobody would ever confuse one for a genuine mainspace article. Writ Keeper ⚇♔ 17:19, 31 December 2022 (UTC)
Ultimately these RfA pages are whatever. I don't actually care if they're deleted or not and think I might have weighed in on a previous occasion with "what's the harm". But in terms of drafts, I've never really understood the thinking because we allow drafts in userspace to stay indefinitely and those can look just as much like an article as something in draft space. In fact we let something in draft space as long as there are token edits within every six month period. Anyhow this was more an attempt to give an answer to the question you posed than a statement of real belief on my part. I'm pretty Live and Let Live with stuff in Wikipedia and this would be another case of that. Best, Barkeep49 (talk) 17:28, 31 December 2022 (UTC)
If the editors in question are still active, the collaborative thing to do is ask them if they're still interested in working on their nomination, and suggest moving the page to their user space if there are no immediate plans to continue. If they aren't, and there is a consensus that it's desirable to move the works-in-progress from their current location, then we can move them to user space and leave a note on the corresponding user talk pages. isaacl (talk) 17:31, 31 December 2022 (UTC)
If they're not aware it exists, yes. If they're aware of it (or they created it) and and they haven't asked for it to be deleted, the collaborative thing to do is to leave it alone until and unless the editor being nominated chooses to do something about it. HJ Mitchell | Penny for your thoughts? 17:44, 31 December 2022 (UTC)
Sure, not talking to someone is fine, too. I do think that asking someone if they're still interested in proceeding is a collaborative approach: we might get someone working again on their nomination. isaacl (talk) 18:00, 31 December 2022 (UTC)

I can't see the deleted version so can't recall who did this without my agreement, but editor should not have to go through MFD to get rid of these ... not sure if that helps, but that's my experience. SandyGeorgia (Talk) 17:40, 31 December 2022 (UTC)

@SandyGeorgia well you know what you need to do to see deleted revisions! I prob would have IAR deleted or moved or something that if you had tagged it and I had come across it. — xaosflux Talk 17:57, 31 December 2022 (UTC)
Sometimes these should be deleted with people able to restore it via WP:REFUND but admins should have a advice for people that they are not qualified enough. Thingofme (talk) 23:33, 31 December 2022 (UTC)

Also the report needs to be updated daily as we can know potential RfAs to happen. Thingofme (talk) 04:14, 2 January 2023 (UTC)

Thoughts about admin elections on SecurePoll

  • Looking back at the admin elections proposal (detailed), one of the big problems was that people no longer knew what exactly they were supporting. The original proposal? A trial of the original proposal? The concept of holding elections? Any proposal should make it very clear what will actually happen if it receives consensus.
  • The most common reason for opposition was that admins should be selected via consensus, not a vote. I believe that is a feature of this proposal, not a bug.
  • If we get phab:T301180, we would be able to set up our own SecurePoll elections: we could allow people to "run" whenever they please. We would still have to decide a process for (s)electing election admins. We would have to decide if we will scrutinize the process (i.e., do a thorough check for sock votes).
    • As a note, SecurePoll makes the list of voters public, and we do not currently scrutinize every !voter at RfA. This might mean we can get away with not doing so.
    • If we decide to scrutinize, we would have to set up a separate process to (s)elect people to do it. For ACE, we just ask for some volunteer stewards. We could do that. We could also just ask for volunteer CUs.
  • My shower thought: what if we use the textbox feature on SecurePoll to collect feedback, to be summarized by an election admin. Furthermore, writing something intelligible in the textbox ("User Foo is ugly" is a poor reason to oppose, but it is intelligible. "ilwehtgfdhtrj", OTOH, is not.) would be required for a "no" vote to be counted.
    • Supporters would not be required to use the textbox in keeping with the longstanding tradition of interpreting support !votes without rationales as !votes per nom.
    • How would this help? In the original proposal, there were concerns about how candidates would receive feedback. Instead of eliminating !voter feedback entirely, it actually would improve it. Hearing "10 people thought you are prone to BITEing newbies (diff1 diff2 diff3)" is easier than reading 10 different comments phrased 10 different ways from 10 different editors you respect, but you still get the necessary feedback.
  • One thought about a trial: we could bundle it with a trial the other proposal that came close to passing: temporary adminship.
    • This prevents any "long term damage" from That One Candidate Who Should Not Be An Admin passing, and removes the "cloud" that would surround anyone "promoted" through a process that was ultimately scrapped after being used once.

My current thinking is that 3 RfCs is the best way to go: one figuring out the specifics and one on holding trial election(s) at all, in that order (so it is entirely clear what you are supporting/opposing). After the election(s) are held (assuming they are), a third RfC for permanent implementation. Questions? Comments? Concerns? Thoughts? Other ideas? I realize this is being discussed above, but admin elections are not a way of reviewing RfAs in 2022. HouseBlastertalk 06:48, 2 January 2023 (UTC)

  • With a vote, people would happily support per "no big deal" or "why not?" (see the first day of most RfAs). A couple of days after the start, someone might find a good reason that the candidate is not suitable. Problem: very few people would see a comment hidden in a blizzard of election pages (statements, questions, discussions). An RfA has two benefits. First, it is relatively easy to find any discussion about why someone should not be supported. Second, if the candidate cannot remain calm for a week, they are not a good choice. We don't need to scrutinize RfA participants because someone would notice if a bunch of unknown people appeared. If votes were not scrutinized, corruption would occur. A well known LTA nearly became an admin before being discovered. They would laugh if they only had to rig a vote. Voting is fine for Arbcom because a couple of bad arbitrators cannot do much on a committee. Johnuniq (talk) 07:24, 2 January 2023 (UTC)
    I agree with Johnuniq; we seem to keep trying to solve the wrong problem the wrong way. SandyGeorgia (Talk) 12:45, 2 January 2023 (UTC)
Main thought: don't start a RFC unless we actually get securepoll released for use. — xaosflux Talk 10:29, 2 January 2023 (UTC)
Why hold any RFC, though? Beyond what xaosflux said - despite all the problems with RfA, it seems pretty clear that this isn't one of them. casualdejekyll 17:19, 2 January 2023 (UTC)
Because what seems clear to some of us may not actually be clear, or true. Levivich (talk) 17:40, 2 January 2023 (UTC)
3 RFCs is too many. Just one RFC, making a specific proposal, like:
  1. One-week election period
  2. Elections occur first week of every month, candidates to submit their names at least a week in advance
  3. Use SecurePoll, people can change their votes, etc., same as we do for Arbcom elections
  4. Q&A and discussion occurring during the one-week voting period
Each of those could be tweaked but I think just some specific workable proposal put up for a thumbs-up/thumbs-down vote is the best way forward. Levivich (talk) 17:47, 2 January 2023 (UTC)
The voting SecurePoll has already been implemented in Chinese Wikipedia but one every month seems practical. We can nominate from the day 1-4 of every month, day 5-11 is the voting phase. During the voting questions and comments can be added. Thingofme (talk) 15:04, 3 January 2023 (UTC)

2022 RfAs in review

In 2022, we have two major changes in the RfA workload and the admin tools:

  • December 7, 2021 admins do not have autopatrolled automatically.
  • From October 2022 all RfAs automatically end in 7 days.

We also had a increase into the number of successful RfAs (14 compared to 7 in 2021) but is only higher than 2021 and 2018 and is still extremely low. Also this year we have 2 RfAs that need to go to cratchat and three record-breaking RfAs:

  • Firefly: Most supported RfA with no opposes or neutrals
  • DanCherek: Most supported RfA with no opposes
  • Tamzin: Most votes /support votes in any RfA, longest ever RfA .

What do you think about the number this year? Thingofme (talk) 15:13, 31 December 2022 (UTC)

The bottom line remains that we need far more admins.
I'd also be curious to see some statistics about nominators; my sense is that there was a little diversification there. {{u|Sdkb}} talk 15:39, 31 December 2022 (UTC)
While the number of RfAs was a very nice increase, it effectively had no impact :( --Hammersoft (talk) 15:57, 31 December 2022 (UTC)
Tomorrow >100 sysops will be removed for the new criterion for inactive admins so the number should go down to under 900. Thingofme (talk) 16:32, 31 December 2022 (UTC)
That's less of a problem than many people realize. The reality is that most admins don't do much admin work. Here are the admin stats for the past 3 months. This table doesn't include items such as closing discussions or Main page tasks, but I still think it provides good insight into the current situation. We've got maybe 100 admins doing 95% of the work. -FASTILY 00:23, 1 January 2023 (UTC)
...which proves we don't need anywhere near 900. Levivich (talk) 04:00, 1 January 2023 (UTC)
Maybe the number of active admins are getting down but it's not as much of an issue if 100 admins can do 95% of the workforce. Thingofme (talk) 04:08, 1 January 2023 (UTC)
Just because 100 administrators are doing 95% of the work that gets done, it doesn't mean that 100 administrators are doing 95% of the work that needs to be done. Useight (talk) 04:12, 1 January 2023 (UTC)
If folks are avoiding certain tasks, then there's probably a good reason why they're not being done. -FASTILY 04:51, 1 January 2023 (UTC)
100 admins are doing 95% of the admin work that is being done AND that is being measured. There is plenty of incomplete, measurable administrative work. Then there's the less quantifiable stuff. Anecdotally, there's a night and day difference between topic areas that have active administrators who will pop in and warn a user or close a discussion and ones that are ignored, or where experienced and hardworking admins have thrown in the towel. Firefangledfeathers (talk / contribs) 04:15, 1 January 2023 (UTC)
If someone did compile statistics on the "less quantifiable stuff", I wouldn't expect the outcome to be very different. Even well-run organizations struggle to escape the 80/20 rule. -FASTILY 04:51, 1 January 2023 (UTC)
I don't disagree on 80/20, but it doesn't follow that we have enough admins. Firefangledfeathers (talk / contribs) 05:01, 1 January 2023 (UTC)
We could absolutely use more active admins. I seriously doubt we're losing much by shedding dead weight, which is the point I'm trying to make. Naively counting the accounts with sysop rights doesn't tell us anything useful about the actual health of our admin corps. -FASTILY 05:12, 1 January 2023 (UTC)
I recognize that your comment is the parent of the subthread, but I'm not really replying to your point about the imminent desysopping. I agree with you. Firefangledfeathers (talk / contribs) 05:16, 1 January 2023 (UTC)
While I would love if I wasn't nominating such a large % of candidates, I don't think a lack of nominators is the issue. One reason there aren't more nominators is that people who try get turned down repeatedly by candidates and so they end up spending their time elsewhere. I hear this both directly from both potential candidates (my getting turned down) and potential nominators (who tell me about their failed attempts). That said if someone reading this is like "I have someone to nominate and just don't know what to do", Ritchie and I, as I believe the two most frequent nominators over the last several years, have documented our process so people who want to nom can learn from it. People are also welcome to contact me directly if they're interested in being a candidate (I'm happy to give an evaluation of what I think) or nominator. Best, Barkeep49 (talk) 16:42, 31 December 2022 (UTC)
We as a community know RfA is broken. We don't agree why its broken in large enough numbers to have consensus. And because we don't agree why in large enough numbers can't do anything to fix it. I think one or more of those three sentences explains just about all the numbers listed above. Best, Barkeep49 (talk) 16:44, 31 December 2022 (UTC)
Barkeep49, RfA has been a broken process almost ever since it started nearly 20 years ago. We all know why it's broken but no one has the balls to spell it out because the community will fight tooth and nail to retain its playground. All the attempts to address it have failed, yours, Biblioworm's, and mine. The possible solution is a once or twice yearly election on the lines of an ACE. There would be plenty of opportunity to be spiteful in the voter guides, questions for the candidates, and 'discuss the candidates'. Safety in numbers for the candidates and anonymity for the voters. Perhaps it might encourage more editors of the right calibre to come forward and fewer governance obsessives. There are some good people on the committee but never enough and with so few candidates the seats will be filled with them so the results take the rough with the smooth. The 'crats might lose their privilege of holding the occasional 'crat chat, but getting them together for it is harder than obtaining a quorum on Arbcom. Kudpung กุดผึ้ง (talk) 05:19, 1 January 2023 (UTC)
I know the closers disagreed, but in my view, there was community consensus in the last discussion for admin elections. If we can confirm there is no unsurmountable technical obstacle, then there's an excellent chance of the community agreeing to have elections for administrators. isaacl (talk) 05:49, 1 January 2023 (UTC)
A close conditional on technical resolution (like we saw at WP:VECTOR2022) would have been good there imo. Such a close is an elegant way to avoid unnecessary follow-up discussions.
The meta:Community Wishlist Survey 2023 may be a good way to get the SecurePoll improvements that the opposers required. It's a big enough problem to get large numbers for it. —Femke 🐦 (talk) 10:18, 1 January 2023 (UTC)
The first RFA in 2023 is here, in the first day of the year. I hope he will be successful. Thingofme (talk) 14:50, 1 January 2023 (UTC)
I think elections are hanging out there for someone to bring to the finish line. I hope someone does so. Best, Barkeep49 (talk) 16:50, 1 January 2023 (UTC)
On the "broken process ever since it started" and "we know RFA is broken but don't agree why in large enough numbers", I continue to believe that is a faulty starting premise for the problem we seek to solve (not enough admins). RFA mostly works except that some who shouldn't get through do. When the discretionary threshhold was lowered, that increased the need to lodge opposes that candidates find unpleasant. Elections won't solve the underlying "what's broken" issue: not enough admins is a lesser problem than too many admins who shouldn't be admins, and elections as Johnuniq seems to be saying, are likely to give us a few more admins who shouldn't be, while we don't have an equivalently eas(ier) desysop process. And as an editor who has never, ever wanted to be an admin, for reasons that have varied as often as the years I've been editing, and regularly speaks to many others who don't either, I disagree that elections will solve this "brokenness" or that the unpleasantness of the process is the biggest brokenness. I didn't consider RFA broken back when I was a frequent (100% successful) RFA nominator, before the discretionary theshhold was lowered. SandyGeorgia (Talk) 12:41, 2 January 2023 (UTC)
I'm putting it on wishlist, some work is done via phab:T301180 and many links tasks, but it's just not getting dev and wmf priority. — xaosflux Talk 17:43, 1 January 2023 (UTC)
Pardon my ignorance, but wouldn't elections raise the bar for adminship by virtue of making it a more formalized, structured process that people would then take more seriously? You'd be putting it in the same category as ArbCom and Wikimedia Board elections. I think this would then give potential candidates some pause as to whether or not they'd want to go through something that seems even more contentious. It might not be as open a bloodbath as RfA, but it still wouldn't be "fun". 🌈WaltCip-(talk) 17:44, 1 January 2023 (UTC)
For me, elections would have lowered the bar for an RfA significantly. It feels less personalised. I think the major risk of an RfA is not failing per se, but getting damaged by the way people formulate opposes / knowing that people you trust and respect oppose you.
Anyway, the proposal that almost made it in WP:RFA2021 was an optional election process, so that people can still opt for the old process if they would perceive it as less stressful. —Femke 🐦 (talk) 19:04, 1 January 2023 (UTC)
With an anonymous vote, there's no need for multiple people to comment on the same strengths or shortcomings of the candidate, since there's no need to establish a consensus view through discussion. With fewer comments, there's less opportunity for dissenting responses. There should be less repetition, thus reducing the number of times a candidate has to read about their drawbacks, and more participants would focus on just voting, saving everyone time. (There are of course cons to this, depending on how much you feel the process should be discussion-based resulting in a consensus.) isaacl (talk) 21:46, 1 January 2023 (UTC)
@WaltCip Despite being considered a more "serious" position, I found ACE to be significantly less contentious and have far less scrutiny than RfA, but I don't think that's entirely the result of ACE being a "private" election. Moneytrees🏝️(Talk) 23:09, 1 January 2023 (UTC)
This I think is the secret to why elections as proposed might work. I think ACE benefits from having so many people running at once. There simply can't be the same focus on each individual as at RfA and that makes it less contentious. Also you get all the bad news - opposes - all at once rather than as a trickle with each minute spent in suspense not knowing if another piece of good news (supports) or bad news (opposes) will come your way. I think elections will bring other problems - my 82% at ACE Is a rousing success in a way that it would not be at RfA - but I think this feature is real and will be attractive to some people who are not attracted to RfA. Best, Barkeep49 (talk) 00:01, 2 January 2023 (UTC)
The problem with SecurePoll is there is one votewiki and only one wiki are able to use each time, and each time the interface language of the wiki has to be changed. Also to maintain this wiki we need to have stewards and other global users. However I think a monthly/once every 3 months RfA election is ok as well, if we have 20 admins/year. Thingofme (talk) 04:11, 2 January 2023 (UTC)
As I understand it, multiple polls can be run with the same interface language (see 4nn1l2's post in the 2021 discussion). The Phabricator ticket mentioned by Xaosflux is tracking work needed so that English Wikipedia admins could run the election on English Wikipedia, without using votewiki. As described by Joe Sutherland, the primary bottleneck is staffing support for running a poll. isaacl (talk) 04:23, 2 January 2023 (UTC)
Too bad WMF is so low on free cash flow and has such a small staff, or that could be addressed. ScottishFinnishRadish (talk) 04:46, 2 January 2023 (UTC)
WP:CANCER. They have a lot of money and a lot of staff and they are spending it improperly. The problem can be resolved by only changing the interface language when people is voting (only in the voting page) and other pages in votewiki can be defaulted to English. Thingofme (talk) 04:49, 2 January 2023 (UTC)
The interface language isn't a practical issue at present as there aren't many polls run on votewiki (Joe Sutherland's post has a link to all SecurePolls that have been run). isaacl (talk) 04:55, 2 January 2023 (UTC)
Perhaps @Xaosflux could incorporate something that would allow with less/no staff into the wish? I suspect that following the unsuccessful banner campaign that there will be less WMF staff and so maximizing whatever staff we can get feels prudent. Best, Barkeep49 (talk) 04:59, 2 January 2023 (UTC)
This comment from phab:T301180 is interesting:

The current process of requesting an election is quite obscure since SecurePoll requires those CLI steps (setting up encryption) and because it requires access to votewiki, which is not an SUL wiki (and so that access must be requested, at the moment from the Foundation). There are some security reasons for that, mostly that the access one gets as an electionadmin is akin to CheckUser access — arguably even more powerful since one doesn't need to actively run a tool to see voter data (more on that in T270342#6702969).

The ideal set up process would be thus:

  1. A wiki decides it needs to run an election (e.g. an ArbCom election, a request for adminship, etc)
  2. The wiki nominates some user(s) to serve as admins to set up the election - eligibility criteria would ideally be more configurable than it is now since some wikis have different criteria, though that's a different question
  3. The wiki nominates some user(s) to view the voter list (to scrutinise it for duplicate votes etc.)
  4. The selected admins then tally the election and share the result with their community

Probably missing some steps here, but I think that's the overall ideal flow.

It seems we are on step 1. Levivich (talk) 05:06, 2 January 2023 (UTC)
I don't really think this is a problem. We can still run SecurePoll elections, and getting stewards involved is not a hard thing if we actually need them to do the work there. SecurePoll is a crappy extension from everything I've heard, but it still works and an election system using it would be easily feasible. The perfect should never be the enemy of the good, and that's especially true when we're talking about technology. TonyBallioni (talk) 05:54, 2 January 2023 (UTC)
If I understand correct, the Phabricator ticket is asking for SecurePoll to be deployed on local wikis in a manner such that polls can be entirely administered by designated members of the local community, so that WMF staff involvement is not required. isaacl (talk) 07:09, 2 January 2023 (UTC)
I read all this stuff forever ago so forgive me if my memory is foggy but I thought the main issue with SecurePoll wasn't the format but that only one Wikimedia site could use it at once. Was this fixed or is my memory just awful? Clovermoss🍀 (talk) 07:29, 2 January 2023 (UTC)
You can see my earlier posts in this thread where I linked to the quotes from various persons regarding the ability to run multiple polls simultaneously and how the primary bottleneck is the administrative support required. (If I understand it correctly, the Phabricator ticket describes certain commands that right now must be executed at the command line. Either they have to be made to work reliably from the web interface, or they have to be packaged up in a sufficiently bulletproof and standalone manner that a sysadmin could be asked to run them in a service support ticket.) isaacl (talk) 07:33, 2 January 2023 (UTC)
I meant the first comment as a reply to Tony but I messed up the indenting (his edit summary uses the words "non-issue" [2]). I wasn't certain enough about the particulars to know if what you were talking about earlier was about fixing the same problem my half-baked memory provided. I was specifically thinking about the 8B Admin elections proposal where people brought up SecurePoll back in WP:RFA2021. It's a mess of a thread and I couldn't even make sense of how many walls of text there were back then, but this discussion jogged my memory of trying to read that one. I figured I'd bring it up in case it was useful information, but I'm guessing that most of the people contributing here are way more familiar with how RFA2021 went. Clovermoss🍀 (talk) 14:20, 2 January 2023 (UTC)
isaacl, I also happened to miss the one comment where you actually said this wasn't the issue I thought it was. I saw your other comments and was confused about how they applied to this situation but I think I get what you mean now. Clovermoss🍀 (talk) 14:31, 2 January 2023 (UTC)
From what I've gotten to so far, the main problems are (a) encryption management; (b) private data management. A is a tech problem that the wishlist may get developers on ; B is mostly a back-and-fort argument about how the checkuser data in the securepoll is accessed. — xaosflux Talk 10:24, 2 January 2023 (UTC)
Anybody know the details of how the encryption works? Does it encrypt values in the SQL database? And do any other extensions that handle private data (such as mw:Extension:CheckUser) use encryption? If not, is this extension perhaps over-encrypted? –Novem Linguae (talk) 16:41, 2 January 2023 (UTC)
From what I understand from the ticket, each vote is encrypted in the database. Encryption is an optional feature. Whether or not the community wants votes to be encrypted comes down to whether or not it wants each voter's choices to be visible in the backend to anyone with database access. (Votes could be stored without associating them with voters, but then they would not be auditable, and voters couldn't change their choices by re-voting as they can today.) isaacl (talk) 17:02, 2 January 2023 (UTC)
If encryption is one of the blockers for mass-installing SecurePoll on wikis that want it, and there's a consensus that encryption isn't really needed, then encryption might be a good feature to remove or turn off, in order to make SecurePoll more easily installable. –Novem Linguae (talk) 18:44, 2 January 2023 (UTC)

"Not enough admins is a lesser problem than too many admins who shouldn't be admins" I want to pick up on this point here; no example was given, but I can take a guess that this was in reference to Wikipedia:Requests for adminship/ScottishFinnishRadish which was certainly a contentious RfA. However, the bureaucrats decided there was consensus to give SFR the toolset, and after a lengthy discussion. So at best you can only say "too many admins who I think shouldn't be admins". And that's why I think that RfA is not actually a solvable problem because it relies on opinions of the entire community, which are as diverse and contradictory as you can get. I think all the regulars at RfA have opposed somebody at some point, so we all have opinions on who shouldn't be an administrator ... it's just they're all different. Ritchie333 (talk) (cont) 12:06, 6 January 2023 (UTC)

Another technical update needed

Because User:Amalthea/RfX/RfA count is showing "1", the watchlist message that says "a request for adminship is open for discussion" continues to be active, even though the current request is no longer open for discussion under the new rules for putting RfAs on hold after exactly one week. Can a workaround for this sort of case be implemented, since it is likely to occur at the end of most RfAs in the future? Dekimasuよ! 17:34, 8 January 2023 (UTC)

For a "quick fix" perhaps the text in Template:RfA watchlist notice/text can just be tweaked such as "[is|are] open for discussion" to "[is|are] listed"? — xaosflux Talk 17:46, 8 January 2023 (UTC)]
Just for the record, the current RfA being on hold has nothing to do with the new rules - it has been put on hold by a 'crat (me). Courtesy ping to the bot operator to add {{rfah}} to the "list of reasons to remove an RfA from the list". Primefac (talk) 17:53, 8 January 2023 (UTC)
In August 2022, Xaosflux restored the change to use Module:RFX report, but I see later in the month NovemBot started updating the count. That being said, Module:RFX report also returns 1 right now. Where the fix needs to be done depends on which approach will be used going forward for the watchlist. (I can't remember right now if the module is used elsewhere just to return the count.) isaacl (talk) 17:54, 8 January 2023 (UTC)
@Isaacl it should only be there (anyone else relying on it should expect the same result as there at least). I think it was restored because it was broken before. If a bot will update this count frequently and can not list ones on hold, that should be fine. — xaosflux Talk 18:13, 8 January 2023 (UTC)
Loading the watchlist had slowed down, which was thought to be due to the module parsing the RfA page (it had a very long RfA on it at the time), and thus the call to the module was removed. You restored it in August, and I asked you about it at the time (paraphrasing, you said let's try it again and see if there's an issue). I agree the module should give matching results; I was only reflecting on the priority of fixing the issue if the count value isn't being used anywhere. isaacl (talk) 18:19, 8 January 2023 (UTC)
The module is "slow", esp if there are multiple very large rfx's open. Someone can propose a change to the bot and/or the module on how it counts these of course. Having a backup isn't a bad idea. — xaosflux Talk 19:08, 8 January 2023 (UTC)
Yeah, I raised the performance problem in August when you restored the use of the module. As I said somewhere, I do think it's better not to run Lua code each time someone loads their watchlist, and so a bot-based solution is a good one. isaacl (talk) 21:50, 8 January 2023 (UTC)
A bot could just subst the module on a regular basis, which should be the best of both worlds: all the code is maintained on-wiki and the performance is fast. Legoktm (talk) 19:38, 8 January 2023 (UTC)

Hello. Bot maintainer here. Currently the bot just counts the number of transclusions on the WP:RFA page. Will require an hour or two of programming to rewrite the bot to check the wikicode of every RFA for {{rfah}}. I wonder if there's a better algorithm. I'll give it some thought. In the meantime I'll turn the bot off so that we can get rid of the watchlist notice. –Novem Linguae (talk) 20:15, 8 January 2023 (UTC)

A bot could just subst the module on a regular basis. Hmm. Maybe I'll switch to this algorithm. Do we want to give this a try? –Novem Linguae (talk) 20:23, 8 January 2023 (UTC)
I did a quick test of {{#invoke:RFX report|countRfas}} and it is incorrectly returning 1. It also is confused by the crat chat. So that approach might not work unless the module is also changed. –Novem Linguae (talk) 20:25, 8 January 2023 (UTC)
Yes, I mentioned above that the module would have to be changed as well. The module parses through the text to count the supports/opposes/neutrals and to extract the status (which is what makes it slow). Since the RfA report currently shows "Pending closure...", I'm guessing it is detecting that the current RfA in question isn't open. Assuming that's true, it's fairly easy to change the module to return a count of only the open RfAs. (I'm not sure I'm up for changing it myself, as I would want to introduce hooks to facilitate testing, and then create test cases. If someone else wants to make a quick-and-dirty change, please feel free.) isaacl (talk) 21:50, 8 January 2023 (UTC)

Acknowledge that discretion range is actually crat chat range

At the moment Wikipedia:Requests_for_adminship#Discussion,_decision,_and_closing_procedures says RfAs that finish between 65 and 75% support are subject to the discretion of bureaucrats (so, therefore, almost all RfAs below 65% will fail). In practice the @Bureaucrats: no longer seem to be willing to use individual discretion to close and instead default to group discretion. Since in my mind policy is practice, should we update that line to something like RfAs that finish between 65 and 75% support are subject to a bureaucrat discussion (so, therefore, almost all RfAs below 65% will fail). If this makes sense to people I think we could just do it without an RfC since, again, it's already what happens and isn't therefore a substantive change but rather a change to reflect that reality. Best, Barkeep49 (talk) 16:43, 8 January 2023 (UTC)

It says discretion of bureaucrats, plural, not bureaucrat (singular), so I do not see how it is not in keeping with policy what we currently do. Primefac (talk) 16:46, 8 January 2023 (UTC)
I'm not suggesting the crats are doing anything wrong. I'm suggesting that we formalize the current crat practice in a way that would make clear to editors and crats what the expectation is. Best, Barkeep49 (talk) 16:49, 8 January 2023 (UTC)
But an individual 'crat can close a discussion without a chat, though usually it is done after discussion. With your change that would not be possible, which would mean that SFR's "won't need an RFC" comment below is incorrect. Primefac (talk) 16:50, 8 January 2023 (UTC)
policies and guidelines are designed to describe its principles and agreed-upon best practices. and this is already, quite clearly, an agreed-upon best practice as revealed by the actions of the crats. I am aware, since the range change, of 1 close in that range without a cratchat by @AmandaNP and that received criticism. The crats have made clear, through their repeated actions, that they feel this is not an individual power of crats and this change would update the writing to make that clear. Best, Barkeep49 (talk) 16:57, 8 January 2023 (UTC)
As for the RfC, I consider this akin to the recent removal of A5 as a CSD. Practice had revealed existing consensus and so a talk page discussion was sufficient to make it formal. Best, Barkeep49 (talk) 16:58, 8 January 2023 (UTC)
As far as I can tell, bureaucrats have discretion over the procedures they follow to determine the outcomes of requests for administrative privileges, within the bounds of instructions set by the community. Thus I feel the best approach to avoid confusion over whether or not the community is imposing a new requirement is to leave the documentation of best practices to the bureaucrats. isaacl (talk) 17:16, 8 January 2023 (UTC)
The one Amanda closed (Greenman's in 2019) was actually outside the discretionary range at 61%; I think it was controversial mainly due to the trendline, which some were using to argue for an extension. Unless I'm missing one, the last unilateral close within the discretionary range was Bri's nearly seven years ago...so I agree that it's become very rare. And even if it wasn't rare, I still think the proposal would be a good idea: there are so few discretionary-range RfAs these days that the benefits of sending them to crat chat (increased legitimacy) are worth the extra effort. Extraordinary Writ (talk) 23:44, 8 January 2023 (UTC)
Good change, I agree it doesn't need an RFC. ScottishFinnishRadish (talk) 16:46, 8 January 2023 (UTC)
I don't think the documented process needs to be overly prescriptive. The current wording covers both individual bureaucrats exercising their discretion, as well as the entire group of bureaucrats exercising discretion. isaacl (talk) 16:51, 8 January 2023 (UTC)
That might be interpreted as meaning RfAs that fall below 75% will always need a Crat chat. I'd prefer that the decision is left open to the judgement of a Crat. An RfA which started badly because of a misunderstanding which was cleared up in the last day or two, and the trend toward support then shot up quickly, but, because we now have an automated finish, the RfA was stopped on the 7th day at 74%, should not need a Crat Chat to promote. SilkTork (talk) 16:58, 8 January 2023 (UTC)
And yet Crats are so unwilling to make an individual determination in tough cases that when an RfA finished above 75% someone still opened a cratchat. Best, Barkeep49 (talk) 17:00, 8 January 2023 (UTC)
You keep saying Crats plural like we all decided that a close needed to go to a chat, but the decision to open a chat is still left to an individual 'crat. Just because one 'crat opened a chat does not mean that all 'crats would have done the same. Primefac (talk) 17:05, 8 January 2023 (UTC)
And yet when crats, in RfA after RfA, make the same decision it means that it is procedure and if all crats wouldn't have done that, we should update the guidance to reflect the existing consensus revealed through repeated practice. Best, Barkeep49 (talk) 17:08, 8 January 2023 (UTC)
I have to agree with SilkTork and Primefac. I would still prefer the option to close an RfA in this zone if I found consensus. The reason I feel we don't is because we don't want to be seen by the community as a bunch of cake eaters - some people just want to see an extensive thought process. And when they don't, it kinda blows up - right or wrong. If the community as a whole wants us to automatically take it to crat chat, sure, I'll do that. But for now, there is discretion I don't want to push out of policy. -- Amanda (she/her) 18:15, 8 January 2023 (UTC)
As this is informative, not policy, there is room to describe it more. I wouldn't say any RfA outcomes are actually at the "discretion" of a 'crat or a team of 'crats. The 'crat job isn't to discretionarily decide the outcome, it is to measure the community consensus. — xaosflux Talk 17:43, 8 January 2023 (UTC)
Our sample size is too small to say with confidence that crats would open a chat for every RfA at 74.5%. The proposed text needs at least a "usually" to allow less bureaucratic bureaucrat discretion. —Kusma (talk) 17:48, 8 January 2023 (UTC)
I agree the proposed change better describes current practice than the current text. I'm fine with adding a "usually" or other similar qualifier to it. I also agree it doesn't need an RFC. And I agree with xaos's point that there isn't actually any "discretion" in what 'crats do, anyway. The word "discretion" means "the freedom to decide". One has "discretion" when making a decision, but the assessment of consensus does not involve the use of discretion; in fact, the assessment of consensus is the very opposite of "the freedom to decide". Levivich (talk) 16:35, 9 January 2023 (UTC)

A whole different approach to this situation might be to revisit the (now old) 2015 RFC, taking into consideration RFA results since that RFC. Analyzing the results of all RFAs that dropped below 70 in those seven years suggests that restoring the 70% could solve a lot of these issues. There are some less than stellar results to be found in the analysis. I understand we want and need more admins, but we seem to keep breaking the process, and making it unnecessarily complex, in trying to fulfill that aim ... and not making it anyway. SandyGeorgia (Talk) 18:13, 8 January 2023 (UTC)

As an extreme example, if an RFA were to drop from >95% to <75% in the last day or so, and at the end of the 7 days was still in free fall with supporters striking and moving to oppose every hour; I'd hope that no one would demur at a crat closing the RFA as unsuccessful despite being in the discretionary zone. TLDR, just because the few recent discretionary zone closes have involved crat chats don't assume they will always need them. ϢereSpielChequers 23:29, 8 January 2023 (UTC)

  • The current wording is sufficient as is to mean either a sole bureaucrat closing a contentious RfA or an RfA going to bureaucrat chat. That the recent disputed RfAs have gone to a chat doesn't mean all the ones in the future will. Acalamari 01:23, 9 January 2023 (UTC)
I'm not against curtailing bureaucrat discretion if that is accompanied by a more coherent structural reform to the process. So long as consensus is that RfA is more of a discussion than a vote, it would make more sense to me to have bureaucrats retain discretion as to when to call a crat chat or not. I would summarize current procedure a bit differently, roughly as follows: anything under 60% fails and anything over 80% passes as general brightline rule with exceptions for truly pathological cases; 60–65% and 75–80% will generally fail and pass, respectively, often without a crat chat, but 65% and 75% aren't really as brightline as are 60% and 80%; and 65–75% usually go to a crat chat, not necessarily so, but if it as a crat chat, the outcome based on previous crat chats will tend to a toss-up for RfAs in the 70–75% range and probably failure for the 65–70%.
If we're going to down the rule of placing hard(er) numerical limits on the RfA process, I feel it would be cleaner to adopt something more along the lines of the steward elections (and what to some extent was done for ArbCom this year), where there is a preliminary (e.g. 5 days) question period followed by a vote (for example 5 days too, not SecurePoll). A successful RfA could be >70% or >2/3 support. In exchange for three more days of RfA, it would be likely that by far not every oppose vote would describe someone's supposed misdeed(s) in varying detail. Maxim (talk) 14:08, 9 January 2023 (UTC)
While I see merit in looking at the preponderance of the discussion among 'crats in truly difficult cases, I would prefer that any single 'crat can and should handle a contentious nomination if they are comfortable with their analysis. After all, that's why 'crats are paid the big bucks. If every dodgy nomination goes to a 'crat chat, then the community will start expect a chat as a matter of course.
As to extending the RfA, I am generally opposed; I think we are opening a door for making RfA into a melee. If you have a championship boxing match of 12 rounds, would we support the referees saying: "ah, let them go three more rounds" and see where we're at." Cecropia (talk) 15:47, 9 January 2023 (UTC)
Paid? Damnit I've been missing out from collecting on top of my $0 ArbCom pension & $0 Ombuds pension. With $0 in active duty for the other things! So much i'm missing out on... -- Amanda (she/her) 17:13, 9 January 2023 (UTC)
So what I'm hearing is that the real money is being a steward because I see that is conspiculously left off your list... Best, Barkeep49 (talk) 17:15, 9 January 2023 (UTC)

Error

Many unsuccessful RfAs at the bottom of Wikipedia:Requests for adminship by year/2006 and earlier show an error message Expression error: Unrecognised word "x". — Preceding unsigned comment added by 2405:204:531D:956A:0:0:9E9:48A1 (talk) 04:32, 24 January 2023 (UTC)

That's because the template calls use an X for some of the !vote counts. The page isn't finished. You might ping User:Oshwah. [3] Gimmetrow 04:50, 24 January 2023 (UTC)
Hi there! That's because I haven't manually updated each final vote tally for those RFA discussions yet. Fear not, it's on my to-do and it will (eventually) get done. ;-) ~Oshwah~(talk) (contribs) 04:54, 24 January 2023 (UTC)

The automated "RfA on hold" statement

RfAs are now automatically put on hold after 168 hours. Unfortunately this is done by template magic and isn't visible in the page history, leading to complete nonsense in the page history like this RfA pretending to be on hold right after it started. Could this be fixed for future RfAs? —Kusma (talk) 11:27, 19 January 2023 (UTC)

This particular issue can be technically fixed by adding {{subst:#ifexpr: {{REVISIONTIMESTAMP}} < {{subst:#time: YmdHis |{{subst:CURRENTTIMESTAMP}} +168 hour}}| show nothing | show hold template }} to the template. —CX Zoom[he/him] (let's talk • {C•X}) 11:23, 21 January 2023 (UTC)
If I'm understanding the proposed change, I think that a page edit would be required after the deadline in order for the RfA to be placed in a hold box? I'm not saying that's a dealbreaker, and it might be preferable from a page history standpoint; it's just a change from the current behaviour that only requires a page purge. isaacl (talk) 18:25, 21 January 2023 (UTC)
I would personally prefer an edit for greater clarity, but what @CX Zoom suggests would probably fix the "old revisions look weird" issue. —Kusma (talk) 18:48, 21 January 2023 (UTC)
Oh yes, you're correct. It didn't occur to me but unless there's an edit, the latest revision timestamp would be lesser than the closing timestamp. So, the "automatic" hold template would be rendered useless. —CX Zoom[he/him] (let's talk • {C•X}) 19:52, 21 January 2023 (UTC)
It could be argued there isn't much difference between a purge and a null edit... Assuming the current behaviour of only requiring a purge is kept, I can't think of a way to stop older revisions from also appearing to be on hold when the deadline passes. However a template/Lua module could be created that would accept the page title of an RfA and return a revision date when it was closed, and then a check to this could be added to the current template used to control when the hold box is made visible. Then after an RfA is closed, someone can update the lookup table, and the older revisions would be fixed to appear as intended. isaacl (talk) 18:44, 23 January 2023 (UTC)
Isn't this going to behave differently on the RfA and on a page that transcludes it? —Kusma (talk) 19:20, 23 January 2023 (UTC)

If we're going to implement a manual solution, why not the manual solution that isaacl mentions above (18:44, 23 January)? This preserves the automatic close endorsed by RfC consensus, and it's the historical pages that are fixed manually. Firefangledfeathers (talk / contribs) 16:54, 24 January 2023 (UTC)

  • The original proposal was for a bot, which is a viable alternate option, though it requires a volunteer to code, test, and maintain it. isaacl (talk) 17:06, 24 January 2023 (UTC)
    I did propose an idea to allow for the appearance of past revisions to be restored, by editing a lookup table once the RfA is closed. If a value exists in the lookup table, then hide the hold box if the revision date is lower than the returned value; otherwise, continue to evaluate the {{hide until}} template. isaacl (talk) 17:06, 24 January 2023 (UTC)

Time for a rule about only 'crats refactoring or closing discussions?

It's mildly annoying to see involved editors refactoring oppose discussions to the talk page (after they've already !voted support), and then seeing those discussions closed by non-crats that are equally involved editors (!vote supporters). Am I alone in thinking maybe it's best for 'crats to be the ones making those decisions and if help is needed, asking at WP:BN? —Locke Cole • t • c 20:01, 6 March 2023 (UTC)

Personally I'd prefer the crat role to be a bit more hands on in that way, but we have had this discussion before. To my knowledge the crat role has been pushed away from controlling the discussion. Lee Vilenski (talk • contribs) 20:29, 6 March 2023 (UTC)
They are probably involved but what you suggest is probably way too bureaucratic than it needs to be. Such janitorial tasks even when done by involved editors do not appear to be disruptive enough to warrant excessive rules. —CX Zoom[he/him] (let's talk • {C•X}) 20:43, 6 March 2023 (UTC)
Oh, nothing excessive is necessary, I agree. It should just plain be "'Crats will conduct the RfA, and handle any issues of moving topics/collapsing discussions/striking votes". —Locke Cole • t • c 22:59, 6 March 2023 (UTC)
See Wikipedia:2015 administrator election reform/Phase II/Clerking RfC. --Hammersoft (talk) 21:07, 6 March 2023 (UTC)
I find it interesting that of the options given for "who can clerk" that 'crats got the most votes. I think the rest was... a bit much. I think the deep dives into what "clerking" would be should come later, with just a basic understanding that nobody should be striking votes, moving conversations, or collapsing discussions except a 'crat. —Locke Cole • t • c 22:58, 6 March 2023 (UTC)
This was definitely brought up at WP:RFA2021 last year. Lee Vilenski (talk • contribs) 23:09, 6 March 2023 (UTC)
Actually, it looks like from this edit to the edit-notice (which exists to this day) this is already a thing? With that being the case, should non-'crats/involved editors be making the types of changes/closures we're seeing at Wikipedia:Requests for adminship/Aoidh and the talk page there? —Locke Cole • t • c 00:28, 7 March 2023 (UTC)
One concern that has been discussed before (such as at the end of Wikipedia talk:Requests for adminship/2021 review/Proposals § Discussion (Formal moderation of RfA)) is that the editors in charge of evaluating the consensus outcome of the discussion shouldn't also be moderating it. isaacl (talk) 23:28, 6 March 2023 (UTC)
So if one 'crat clerks the discussion, that same crat shouldn't opine in a crat chat? Seems like a reasonable way to go. Jclemens (talk) 22:55, 7 March 2023 (UTC)
  • as long as constructive/valid, support/oppose opinion is immaterial. Definition of "involved" is also subjective. "Involved in RfA" is one view, "involved in the discussion being refactored" is another view. —usernamekiran (talk) 20:48, 10 March 2023 (UTC)

RFA review

How did the process behind WP:RFA2021 start? I started a thread on WP:VPIL (link) after giving some tips to a new editor. He gave me the idea to improve the instructions on starting RFCs which made me realize our guidance for new editors is not as good as it could be. I would be interested in seeing if the community would support some wider review of our advice and instruction pages on wiki with a similar format to RFA2021 so I'm curious how I could get the wheels moving on that. — Ixtal ( T / C ) ⁂ Non nobis solum. 23:33, 9 March 2023 (UTC)

I'd ask Barkeep49. My understanding is that they were quite involved in RFA2021 (although I could be wrong). Clovermoss🍀 (talk) 23:38, 9 March 2023 (UTC)
I had been slowly collecting ideas and causes people had around RFA reform, had found I lacked time to individually vet candidates in the way I had in the past, and given a long RfA dryspell just decided to launch based on the several previous RfA reform efforts. I would not recommend this as something instructive for new editors for a host of reasons. Best, Barkeep49 (talk) 00:15, 10 March 2023 (UTC)
Barkeep49, I don't think I understand what you mean. My question to you would be, if I were to organize some kind of community review of our educational resources how could this be done and what possible obstacles could it face? — Ixtal ( T / C ) ⁂ Non nobis solum. 00:18, 10 March 2023 (UTC)
As I recall, User:Sdkb has previously communicated their thoughts on trying to revise the help documentation, so they might be a good person to touch base with. I will forewarn you, though, that they found it difficult to progress. It's sort of like the old adage about how you eat an elephant—one bite at a time, except that in this case, the community keeps knocking each bite out of your mouth. In a nutshell, there are generally supporters for every piece of guidance written, thus oftentimes there are objections to change attempts, so people create new pages as the path of least resistance, and now there are a lot of pages with overlapping scopes and varying levels of ongoing updates. I don't have any good suggestions beyond trying to make changes incrementally to one page at a time, and being prepared that there's a good chance no changes will gain consensus support. isaacl (talk) 02:35, 10 March 2023 (UTC)
Yeah, the comment isaacl might be referring to is this one. Overall, I'm not sure a large-scale review is what's needed in the area of reforming help documentation, for the reasons isaacl mentions. Also, any sort of large-scale discussion would need to have a potentially actionable outcome, and "we'd like our help pages to be simpler" is not an actionable proposal, just a sentiment. Overall, to help out in this area, you can take on a given guidance page and try to simplify it, but there's no real shortcut. Cheers, {{u|Sdkb}} talk 03:02, 10 March 2023 (UTC)
Now that I understand what was being asked better, I agree with Sdkb that large scale RfC isn't a good format for large-scale analysis of the community's educational resources. Best, Barkeep49 (talk) 19:27, 10 March 2023 (UTC)
Wikipedians are fundamentally small-c conservative, as in generally opposed to change. Consider the massive uproar over Vector 2022 as but once example. This has been a positive at times, but when it comes to reforming RfA you have to overcome a major amount of inertia, so to speak. Barkeep49 worked extremely hard on the last RfA reform drive, only to see almost everything shot down, again because there's an inherent aversion to change. Trainsandotherthings (talk) 19:32, 10 March 2023 (UTC)
I do feel like changing RFA is very different to improving editor guidance, though, Trainsandotherthings. I don't think there would be as much uproar over pages that are reading-optional as the UI of the site. — Ixtal ( T / C ) ⁂ Non nobis solum. 20:07, 10 March 2023 (UTC)
Drafting documents by committee is a well-known way to draft a terrible document. If you want to improve the documentation, the most effective thing you could do is to write new documentation and post it somewhere for people to comment on it. My theory is that the reason our docs suck is that nobody actually wants to spend their time doing this (I don't blame them, because I don't either). But if anyone does, they'll have my thanks. Levivich (talk) 20:12, 10 March 2023 (UTC)
@Levivich, it can be thankless at times, but I do find it fulfilling, not least since there's so much need in the area that there's tons of low-hanging fruit.
On rewriting from scratch, that can be a good approach, but only if it leads to eventual replacement of the guidance, not if it creates a fork — having tons of duplicative guidance is a big part of the problem. {{u|Sdkb}} talk 20:28, 10 March 2023 (UTC)
Remember that the next time someone says how great crowdsourcing is at creating new articles. It really isn't. It works well for making uncontroversial, incremental changes, which fortunately covers a lot of ground. For a cohesive new article, it's good to have someone responsible for the overall structure and integrating all contributions together, without having to make all decisions in a large group discussion. isaacl (talk) 23:01, 10 March 2023 (UTC)
It's not so much the total volume of discontent, but the number of divergent viewpoints. And for quiet pages with few watchers, it's hard to find enough people to agree upon a direction to move forward. Even when a discussion is brought to people's attention in some manner, a lot of the time they don't feel vested enough to either comment at all, or to participate for long enough to work out an agreement. All this being said, it is possible to improve documentation. It just can be hard to predict sometimes which changes will garner objections, so to avoid being overly discouraged, it's good to be prepared for it to happen. isaacl (talk) 23:12, 10 March 2023 (UTC)
there's an inherent aversion to change While I think that's true, I think there is an overriding explanation: large multi-part RFCs don't work, because they're structurally deficient (because they're "won" by whomever has the most time, not whomever has the best ideas). Levivich (talk) 20:13, 10 March 2023 (UTC)
That's not unique to multi-part RfCs. All of English Wikipedia's unmoderated discussions fall prey to the problem of conversations being dominated by those who spend a lot of time on them. But it's a catch-22, since it takes an unmoderated discussion to agree upon a different format. isaacl (talk) 22:24, 10 March 2023 (UTC)
No, it's not unique, but it's a lot more pronounced when the required reading is 100k than when it's 1k. Look at some large RFC pages: here, here, here ... who in their right mind is going to read all of that? Normal talk page discussions, normal RFCs, they're short enough that people will actually read them and participate. And yeah, it's still "whoever shows up", but a lot more people are likely to show up if the discussion is manageable. Once you get into 10+ proposals or multiple phases, only the most hardcore dedicated lots-of-time-on-their-hands editors will participate. And we end up making poor decisions, or no decisions. Despite that, all three of those RFCs I linked above actually resulted in some improvements. But in each case, a huge amount of resources (editor time, patience, goodwill) was expended for a very small gain. Levivich (talk) 16:55, 11 March 2023 (UTC)
Some issues are complex and require more discussion. Large, unmoderated discussions where the outcome is determined by consensus are just a bad fit. In the offline world, a working committee willing to invest the time required would look at the issues, weigh the pros and cons of solutions, and present recommendations to proceed. Unfortunately, there are vocal editors who think every step should be crowdsourced, even though that places huge demands on the community's time. isaacl (talk) 18:30, 11 March 2023 (UTC)
Personally I'd character RFA2021 as a failure and think even a more generous interpretation would call it a disappointment. I think the first round was solid in identifying issues but they're really hard issues to solve and so finding consensus in the second phase was challenging. It was also, as we've seen in this latest RfA, incomplete as there weren't serious conversations about clerking beyond the idea of creating a clerking team that never got developed enough to be offered. Barkeep49 (talk) 20:35, 10 March 2023 (UTC)
I think "failure" is a bit strong as long as English Wikipedia is still making decisions by consensus in large unmoderated discussions, because the best process following this constraint can't force agreement, nor get people to volunteer to spend time on developing and shepherding proposals. And I get that: it's a lot of investment to spend when it's likely that your proposal will get a lot non-constructive criticism, with a few people making claims with varying degrees of intensity about your lack of some quality. isaacl (talk) 22:54, 10 March 2023 (UTC)
If I ever volunteer for anything ever again, contact T&S. Valereee (talk) 16:49, 11 March 2023 (UTC)
I think certainly it was a disappointment. It's somewhat telling that I started a thread on ANI a few days back, when Moneytrees said I could have used WP:XRV, which I'd forgotten about. I had good intentions for that board, hoping it wouldn't turn into another ANI, but it didn't gain traction because too many people didn't see the value and it escalated up to borderline name-calling. Although I do recall people like Floq gave genuine constructive criticism on the matter, it was kind of drowned out by nobody being able to agree on what format and structure the board can take. So consequently, the board has died a death. The admin elections is an interesting concept, and I've still got an idea of dropping the consensus threshold to a supermajority (66%) for a straight pass, and a majority (50%) for a crat chat - but I don't that'll get consensus (and saying "if it's good enough for Brexit it's good enough for RfA" probably won't cut it). Ritchie333 (talk) (cont) 15:00, 29 March 2023 (UTC)

Responding to (what you think are) daft opposes

I know we're going over old ground, but can we publicise somewhere that it's not a good idea to respond to lone opposes that might appear daft, misguided or erroneous, especially when over 100 people have supported and it's the only one? It just leads to lots of unnecessary conversation. I was thinking of some addition to Template:Editnotices/Group/Wikipedia:Requests for adminship along the lines of "please stop and think before you reply to an oppose, especially if the tally is 150/1/0" but slightly more diplomatic. Ritchie333 (talk) (cont) 17:17, 6 March 2023 (UTC)

Responding to daft or erroneous opposes should be done in a way that makes it clear the answer isn't addressed at the opposer, but at other people reading the oppose. It is pointless to discuss such opposes, but still useful to point out that they are erroneous. —Kusma (talk) 17:31, 6 March 2023 (UTC)
I think it may be helpful at times to post an objection to the underlying reasoning (whether or not that is erroneous is up to interpretation), but not always. If it's evident that the viewpoint has very little popular support, leaving it be might be better. Even when it may be helpful, note that one objection is often enough. Not giving the discussion more oxygen can be the simplest way to tamp it down. isaacl (talk) 17:56, 6 March 2023 (UTC)
We have in the past had quite a few unambiguously wrong reasonings such as "too many deleted edits, doesn't understand notability". Anyway, if RfA is a discussion (I personally would prefer it to be a vote) responding to opposes should be encouraged. —Kusma (talk) 19:42, 6 March 2023 (UTC)
responding to opposes should be encouraged What about responding to supports? Especially one or two word supports with little to no explanation? —Locke Cole • t • c 19:57, 6 March 2023 (UTC)
Unless you find the reasoning given (or not) to be faulty, I don't see the point, but as long as consensus supports that RfA should be a discussion, there is nothing per se wrong with asking for clarification. (Personally, when I don't think it is necessary to campaign for my position, I will just vote without reasoning, but if there is danger for the RfA to hit the discretion zone, I will certainly explain it so my vote gets counted). Anyway, ceterum censeo: RfA should be a vote, or at least discussion and voting should be separate. —Kusma (talk) 21:07, 6 March 2023 (UTC)
Well, currently it is encouraged, as you desire. There are quickly diminishing returns with each additional response, though. Just because we can do a thing, doesn't mean we ought to do it. Sometimes denying recognition is the best way to deal with comments. isaacl (talk) 22:20, 6 March 2023 (UTC)
And often, the discussion is held against the candidate, whether they participate or not. It is quite depressing. I just can't see how we can discourage discussion and at the same time say "RfA is a discussion". —Kusma (talk) 23:33, 6 March 2023 (UTC)
If I'm understanding your concern correctly, I think you feel some commenters are reading an oppose statement uncritically, and not fully evaluating the counter-responses. I understand that point of view, and sympathize; I don't have a solution that the community would support. (My proposal failed.) I think, though, that the types of opposes being discussed here are those where there is a high level of agreement with the counter-responses, and thus there isn't a problem with the opposes being examined uncritically. isaacl (talk) 00:05, 7 March 2023 (UTC)
It is ridiculous that we are more concerned with responses to people making offtopic comments in their oppose votes than with the people using the oppose section essentially for trolling. —Kusma (talk) 07:29, 7 March 2023 (UTC)
I don't think the community is less concerned about commenters trolling. There are just different ways to handle trolling, and denying it oxygen is effective for editors trolling just to stir up commentary, because they're kept waiting forever to read more responses. isaacl (talk) 16:58, 7 March 2023 (UTC)
If there is support for a change to the edit notice, perhaps it could be a bullet point saying something like this: "Before responding directly below any support, oppose, or neutral statement, consider carefully if your points have already been covered by someone else, and how much effect your comment will have on the outcome. For example, in cases where the outcome is assured, further comments have no effect." (I'm ambivalent about adding anything; I don't think edit notices are very effective at providing this type of behavioural guidance to their target audience.) isaacl (talk) 18:08, 6 March 2023 (UTC)
It seems part of the problem is that some people forget bureaucrats exist (and exist for a reason) Crazynas t 19:24, 6 March 2023 (UTC)

I wonder whether the policy/recommendation/guidelines should be change to actively discourage responses to votes aye or nay. Can anyone point to an example where responding to a vote rationale ever made a difference? I can recall many instances where a vote rationale was persuasive, even turning results around 180°. But I can't recall a single instance where a post challenging a vote rationale has made a dime's worth of difference. Short of that Enos733's suggestion is something I could get behind. Banks Irk (talk) 22:45, 6 March 2023 (UTC)

If responses to vote rationales are discouraged, then rationales should not be posted in the voting section, but in a separate discussion section. —Kusma (talk) 23:35, 6 March 2023 (UTC)
Has any of the "obviously wrong" opposes ever swung an RfA result? No? Then they should be ignored. The dustup and crappy block at the most recent RfA could have been avoided by... anyone doing literally anything else with their time. Hectoring opposes, even ones people disagree with or are wrong, is more pointless than the oppose vote itself, and in the interests of keeping RfA less cruddy, should be actively discouraged. Der Wohltemperierte Fuchs talk 23:40, 6 March 2023 (UTC)
+1, I think the problem is that you only need a small fraction of editors to respond to cause an issue and it seems hard to get that fraction to become zero. Galobtter (pingó mió) 10:40, 7 March 2023 (UTC)
A succint reply of "Seems WP:POINTY" would get the job done of responding proportionately, without turning it into a dragnet discussion. ~ 🦝 Shushugah (he/him • talk) 12:46, 7 March 2023 (UTC)
Yep. Doesn't have any bearing on anything. Nothing wrong with letting it go. Useight (talk) 18:55, 7 March 2023 (UTC)
I think I've definitely seen cases where someone brings up evidence in an oppose, and another editor digs into the evidence and their analysis helps swing my mind the other way. Galobtter (pingó mió) 10:42, 7 March 2023 (UTC)
@Banks Irk, I can think of one. It was the first oppose in the RfA, by a very highly-respected editor, that many in the community might have agreed with due to what at the time was a widely-held misapprehension. Reasonable people responded to it, and it didn't become the snowball it IMO likely would have. I don't know that the snowball would have turned into an RfA fail, but it certainly would have made it more unpleasant or possibly sent it to crat chat. Valereee (talk) 13:03, 1 April 2023 (UTC)

I agree but I don't think a change to the editnotice would do all that much. I think this stems from how RfA works as a weird vote discussion hybrid. The way the system works is that attention is drawn to lone opposes that have no effect on the outcome. If we separated the voting and discussion (or I suppose made RfA into a true discussion with intermingled !voting) this wouldn't happen as much. I'm sure there are many people who oppose every ArbCom candidate because they think running for ArbCom is prima facie evidence of power hungriness, but since the ArbCom elections use a true polling system no one cares. Galobtter (pingó mió) 10:40, 7 March 2023 (UTC)

To avoid making daft opposes, see WP:Common oppose reasoning (WP:RFANOPE). Levivich (talk) 02:02, 8 March 2023 (UTC)

Perhaps a blanket ban on responding to RfA !votes is the solution. Not that you can't talk about the opposers on a different venue, but it would make the actual RfA page an easier read. Lee Vilenski (talk • contribs) 13:43, 1 April 2023 (UTC)
I think we have to allow responses to the reasons for a well-intentioned and on-its-face reasonable oppose. If the rationale is based on a misunderstanding, for instance. The problem is that multiple people respond to just BS opposes that literally no one is paying attention to. Valereee (talk) 14:00, 1 April 2023 (UTC)
I don't know, Valereee, that seems like we're allowing for badgering a good-faith oppose but not the trolling? Seems backwards to me. Yes, people give the bad-faith opposition more credence than they're due, but that's a cultural problem; we can't legislate against it. Vanamonde (Talk) 16:47, 1 April 2023 (UTC)
Sorry, wasn't being clear. I was responding to the suggestion we blanket ban responding. We need to be able to respond to those that others will likely take seriously if the oppose statement is based on a misunderstanding. I think in general we should just ignore trolls, I just don't think a blanket ban is the answer to the fact people do seem to want to give trolls the attention they so badly desire. :) Valereee (talk) 16:53, 1 April 2023 (UTC)
If you look at my response to Banks Irks above, you may remember that one. Valereee (talk) 16:54, 1 April 2023 (UTC)
I don't immediately recall that specific instance, but yes, that makes much more sense to me; thank you. I do agree that we should be able to reply to !votes based on a misapprehension. Vanamonde (Talk) 16:56, 1 April 2023 (UTC)
"It's a discussion but you can't reply to anyone" isn't really a discussion and at least for now the community wants RfA to be a discussion not just a vote. As someone who works in a venue that does this by design at times (hi mandatory sectioned pages at ArbCom) it can definitely work at limiting back and forth and things spiraling. It also limits actual discussion and makes following the discussion which does happen very difficult. Best, Barkeep49 (talk) 14:41, 1 April 2023 (UTC)
Having the discussion in a discussion section would allow for direct responses to each statement other than the initial expressed viewpoint, while also enabling common threads of conversation to be grouped together to reduce redundancy. I appreciate, though, that has been limited support for this approach based on the various reform discussions in the last decade or so. isaacl (talk) 17:21, 1 April 2023 (UTC)
But will the 'per X' pile-ons see the discussion? I think well-intentioned response to well-intentioned oppose does actually need to be threaded below that oppose. Valereee (talk) 17:34, 1 April 2023 (UTC)
There can be pointers to related discussion threads if desired. isaacl (talk) 20:48, 1 April 2023 (UTC)
That assumes the pile-ons will bother, though. I don't think we should be making well-intentioned responses to opposes to be more work to find. Valereee (talk) 22:34, 1 April 2023 (UTC)
If pile-ons aren't bothering, then I don't know if they will bother to read direct replies anyway. I appreciate there are of course advantages to having lots of multithreaded conversations below each statement of support or opposition. Currently, most people agree with you that they prefer the advantages to the disadvantages. isaacl (talk) 22:39, 1 April 2023 (UTC)
I would rather go for the opposite: there should be a blanket ban on anything other than voting in the "support" or "oppose" sections. If you want to say something about the candidate, do so in a section that is explicitly for discussion, not in one that is for voting. —Kusma (talk) 16:29, 1 April 2023 (UTC)
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia_talk:Requests_for_adminship/Archive_264&oldid=1152917298"