No current discussions. Recent RfAs, recent RfBs: (successful, unsuccessful) |
Candidate | Type | Result | Date of close | Tally | |||
---|---|---|---|---|---|---|---|
S | O | N | % | ||||
President-Wiki-Man | RfA | WP:SNOW | 16 Oct 2022 | 1 | 20 | 0 | 5 |
Isabelle Belato | RfA | Successful | 14 Oct 2022 | 236 | 1 | 0 | 100 |
Whpq | RfA | Successful | 2 Oct 2022 | 213 | 9 | 0 | 96 |
ScottishFinnishRadish | RfA | Successful | 21 Sep 2022 | 234 | 92 | 5 | 72 |
Z1720 | RfA | Successful | 29 Aug 2022 | 194 | 0 | 0 | 100 |
|
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.
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)
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)
- 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)
- If the confusion is about the
- 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)
- 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)
- @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)
- 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)
- Mass ping of people who participated in the discussion above: @28bytes, Acalamari, Ad Orientem, Barkeep49, CX Zoom, Chris troutman, Cryptic, Cullen328, Femke, Firefangledfeathers, Hammersoft, Isaacl, Ixtal, John Cline, Johnbod, Julle, Kusma, Lee Vilenski, Legoktm, Levivich, Nosebagbear, Primefac, SarekOfVulcan, ScottishFinnishRadish, Scottywong, Sdkb, SilkTork, Tamzin, TonyBallioni, Useight, Valereee, Vanamonde93, WaltCip, WereSpielChequers, Worm That Turned, Xaosflux, and Xeno: HouseBlastertalk 11:57, 7 October 2022 (UTC)
- HouseBlaster, you might find this interesting. Kudpung กุดผึ้ง (talk) 20:02, 7 October 2022 (UTC)
- Regarding displaying a real-time countdown timer: note this can only be done with Javascript, and thus would require some additional code to run for every page load. The interface admins generally do not favour having more Javascript code run for every page. If those interested in seeing a countdown didn't mind clicking on a link, there could be a custom link provided with a withJS URL parameter that loads an appropriate script to display the countdown. isaacl (talk) 20:22, 7 October 2022 (UTC)
- For non-realtime {{countdown}} could be used. — xaosflux Talk 20:42, 7 October 2022 (UTC)
- Which would be worse because without purging your timer might show 6 hours remaining when actually only 2 hours remain. The current system of showing end time works fine. No prejudice against anyone wanting to use a ?withJS url parameter though. —CX Zoom[he/him] (let's talk • {C•X}) 05:28, 8 October 2022 (UTC)
- Support a simple "scheduled to end not before <time, date>" with perhaps more reminders that one can set "Time offset" under Special:Preferences / Appearance. SmokeyJoe (talk) 06:29, 8 October 2022 (UTC)
- I'm still genuinely confused about this complaint/concern. Every listing at WP:RFA itself has the end date/time, and every RFA has Scheduled to end ... (UTC) in big bold writing at the top of the page. I don't see this "have to play hunt-and-peck with the calendar" thing; don't most devices give the date and time to their operator? Primefac (talk) 11:37, 11 October 2022 (UTC)
- For non-realtime {{countdown}} could be used. — xaosflux Talk 20:42, 7 October 2022 (UTC)
- I've already supported it but I don't have a clue about the technologies involved. If this idea passes - and it looks as if it will - if needs a fix at Phab, anyone who doesn't like it could put the kybosh on it by saying that this discussion doesn't count and it needs a community-wide debate. Kudpung กุดผึ้ง (talk) 06:26, 8 October 2022 (UTC)
- This should probably have some wider advertisment, and possibly a CENT listing. ScottishFinnishRadish (talk) 12:31, 8 October 2022 (UTC)
- I totally disagree. The point I was making above was in irony to the new trend in needing a site-wide RFC for every little nut and bolt and about people who just don't like things throwing a spanner in the works at Phab. Kudpung กุดผึ้ง (talk) 12:58, 8 October 2022 (UTC)
- I suppose a technical implementation could be done with some sort of "Protect after" / "Scheduled protection"; but that shouldn't be a hold up to implementing this process-wise if there is support here. — xaosflux Talk 02:21, 9 October 2022 (UTC)
- This can be implemented locally, using wikitext magic. Luckily, no need to go to Phab. HouseBlastertalk 21:58, 9 October 2022 (UTC)
- This should probably have some wider advertisment, and possibly a CENT listing. ScottishFinnishRadish (talk) 12:31, 8 October 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)
- 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)
- 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)
- 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)
- 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:
- 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)
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)]:
Special:Permalink/1120704495Special:Permalink/1121617449 - what it looks like when someone uses {{RfA/subst}} to create the base nominationSpecial:Permalink/1120704784Special:Permalink/1121617938 - what it looks like after {{RfA/readyToStart}} has been substed (i.e. they have transcluded their nomination)Special:Permalink/1120704826Special:Permalink/1121617970 - what it looks like after the seven days have elapsed
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, butyes, you are correct; I'll see if adding an extra #if statement sorts it out. Primefac (talk) 16:53, 10 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)
- 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)
- 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)
- Perhaps the generated deadline date/timestamp can be selectively transcluded into the footer. isaacl (talk) 16:31, 9 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 todayI 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)
Procrastination at RfA
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)
- 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)
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)
- 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)
- 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)