#'''Support'''. Worth trying. It could mitigate some unfair RFA dynamics that happen even in the absence of incivility or trolling. [[User:MarioGom|MarioGom]] ([[User talk:MarioGom|talk]]) 18:16, 19 February 2024 (UTC)
#'''Support'''. Worth trying. It could mitigate some unfair RFA dynamics that happen even in the absence of incivility or trolling. [[User:MarioGom|MarioGom]] ([[User talk:MarioGom|talk]]) 18:16, 19 February 2024 (UTC)
#'''Support'''. Although I like the 2+5 idea better. It should relieve stress either way. <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Lulfas|Lulfas]] ([[User talk:Lulfas#top|talk]] • [[Special:Contributions/Lulfas|contribs]]) 20:23, 19 February 2024 (UTC)</small>
#'''Support'''. Although I like the 2+5 idea better. It should relieve stress either way. <!-- Template:Unsigned --><small class="autosigned">— Preceding [[Wikipedia:Signatures|unsigned]] comment added by [[User:Lulfas|Lulfas]] ([[User talk:Lulfas#top|talk]] • [[Special:Contributions/Lulfas|contribs]]) 20:23, 19 February 2024 (UTC)</small>
#'''Support''' I'd like to see this AND anonymous voting. That would eliminate the oppose-vote-badgering as well. But I'll take this as a sensible first step in the right direction.<span style="color:red">→</span>''[[User:Stanistani|<b style="color:green">Stani</b>]][[User talk:Stanistani|<b style="color:blue">Stani</b>]]'' 01:25, 20 February 2024 (UTC)
probably, yes. This shows that there is probably little reason to keep the article in question, so can be deleted. However, if a good reason does exist, it should be reinstated, hence soft deletion Cal3000000 (talk) 16:08, 13 February 2024 (UTC)[reply]
Details (RfC: allow soft deletion of unopposed nominations)
If a nomination has received few or no comments from any editor, and no one has opposed deletion, and the article hasn't been declined for proposed deletion in the past, the closing administrator should treat the XfD nomination as an expired PROD and follow the instructions listed at Wikipedia:Proposed deletion#Procedure for administrators.
This proposal would remove the requirement that an article be eligible for PROD to be "soft deleted". In effect, this would mean poorly-attended but unopposed deletion debates can be closed as WP:REFUND-eligible soft delete.
Survey (RfC: allow soft deletion of unopposed nominations)
In fairness, there were four (4) articles that are still bluelinks because they were ineligible for soft deletion: 1,[d]2, 3,[e] and 4. But I don't think that a redirect, a stub, a non-neutral REFBOMB mess, and No Pants Day justify the volunteer time rubber-stamping nominations. WP:OFD2023 shows that ~15% of AfD nominations are closed as keep, which is ~twice the 8% survival rate of the "ineligible-for-soft-deletion" December group. This suggests that editor time is better spent rescuing other articles.
I want to add a little bit to my rationale: this proposal would result in PROD and soft deletion being treated differently, and that is the point. A well-advertised-but-unattended discussion is not the same thing as a banner staying atop a page for a week. Arguing against this proposal because it would treat soft deletion and PROD differently is textbook circular reasoning: treating them the same way is A Good Thing because they should be treated the same way. Respectfully, why should fundamentally different processes have the same outcome?
I would also point out that the status quo is the 46 articles from December are "hard" deleted: you either need some showstopping sources to show the closer/an admin at WP:REFUND or else must make your case at WP:DRV to get them undeleted. This proposal would result in all of them being REFUND-eligible. HouseBlaster (talk · he/him) 03:29, 14 January 2024 (UTC)[reply]
Support Makes it easier to restore deleted articles and discourages drive-by/rubber stamp !votes. Seems like a net-positive. -Fastily01:54, 13 January 2024 (UTC)[reply]
Support but caveats: The nominator must make a clear delete rational; the nominator must declare that they have followed WP:BEFORE, and say why the BEFORE options, especially WP:ATD are not suitable. I assume that this can override a previous PROD removal. —SmokeyJoe (talk) 05:29, 13 January 2024 (UTC)[reply]
Oppose I have always held that soft deletion at AfD is simply a procedure where we pretend that the nominator, instead of nominating the article for AfD, tags it for PROD instead. So there should be no difference in the rules for soft deletion vs. PROD IMO. However, I am open to considering introducing an expiration for PROD declines, such that an article which has not been declined for PROD in, say, the last five years becomes eligible for both PROD and soft deletion. The reason why declined PRODs are ineligible for PROD is the same reason why we discourage edit warring - you shouldn't be able to get the last say just by being more obstinate at forcing your changes through. However, five years is long enough to presume that the original decliner may have forgotten about the article; they can always maintain their opposition by re-removing the PROD or !voting keep at AfD. -- King of ♥ ♦ ♣ ♠06:19, 13 January 2024 (UTC)[reply]
Support. It took me a bit to parse the proposal, which boils down to "can articles be soft deleted if they've had a contested PROD?". Q for nom: would this change mean that after a single week a decision would be made, or would the normal relisting cadence happen? I'm with King of Hearts in an alternate solution where a soft deletion would only be blocked if the PROD was less than some number of years ago. Eight years, perhaps? Ten seems too long (2014 was a decade ago) but 5 feels too soon (2019 was just a few days ago). SWinxy (talk) 19:22, 13 January 2024 (UTC)[reply]
I envisioned it being a tool in the closer's toolbox: namely, if they feel relisting would be productive, relist. If not, it would be eligible for soft deletion. HouseBlaster (talk · he/him) 22:33, 13 January 2024 (UTC)[reply]
Oppose per King of Hearts. If someone nominates an article for PROD, which is contested, and then immediately renominates it for AfD, just because the person who opposed that PROD didn't show up to the discussion, doesn't mean the article should be deleted. Also open to allowing PROD again after 10 years or something like that, but soft deletion is just applying PROD rules to AfD. Galobtter (talk) 19:31, 13 January 2024 (UTC)[reply]
Oppose. This proposal would effectively allow an article to be PRODed twice. If a PROD has already been removed once, the nomination is controversial. If the person who removes the PROD states in his edit summary that the article should not be deleted, or that the grounds for deletion are erroneous, or that the article satisfies GNG, or the like, I can only infer that the AfD is not unopposed, and that making a comment like that amounts to opposition. James500 (talk) 02:53, 14 January 2024 (UTC)[reply]
This proposal is also explicitly based on the assumption that changing the rules of AfD will not change the behaviour of AfD participants described by the statistics cited. It is not obvious that the assumption is true. This proposal might result in an increase in the number of nominations being made in the first place. Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. This proposal might also result in more keep !votes being made in the first place, if deprodders cannot just wait for an unattended AfD to be closed as no consensus. I also notice that the statistics cited are for December (the time of year when we have the fewest active editors), and do not take into account any seasonal variation that might exist. James500 (talk) 18:06, 14 January 2024 (UTC)[reply]
Finally, the behavior changes you cite seem to be positive changes. The point of any discussion is to find consensus, which logically means "no consensus" closes are not an ideal outcome. We allow speedy renomination of no consensus closes for a reason, after all. Thus, I would argue that discouraging dePRODers from seeking a "no consensus" close is a good thing. I also take issue with the assertion that Nominators might decide to send every declined PROD to AfD in the hope of getting a soft deletion while no one is watching. First, I would hope that people would not attempt to game the system. But holding a full-blown AfD is absolutely not while no one is watching. There is a banner atop the page (which was evidently enough to attract the dePROPer), it is listed on the daily AFD log, and there is literally an entire WikiProject dedicated to ensuring other interested participants see the discussion. HouseBlaster (talk · he/him) 22:13, 14 January 2024 (UTC)[reply]
ExploreLearning and the deleted Explore Learning (AfD discussion) are two different subjects on two different continents. The latter went through Proposed Deletion in July 2008, one month after it was written. Also relevantly, a succession of copyright violations of corporate advertisements, editors with declared and undeclared (but obvious) conflicts of interest rewriting most of the article, and preference for the company WWW site over independent sourcing caused the non-company sources cited in 2008 when Proposed Deletion was challenged to have been long-since lost, buried years deep in the edit history, in 2023 when the article came to AFD. Uncle G (talk) 12:31, 18 January 2024 (UTC)[reply]
Oppose there is often low participation at AfD so waiting a second week for comments is reasonable. Also the deprodder would be rushed into responding when they may be offline for a period. This suggestion would unnecessarily speed up deletion without any consensus in my view, Atlantic306 (talk) 22:48, 14 January 2024 (UTC)[reply]
Oppose. If an article is ineligible for PROD then it is, by definition, controversial and is thus completely unsuitable for deletion without an active consensus to do so. Thryduulf (talk) 11:01, 15 January 2024 (UTC)[reply]
Oppose, although well-motivated, this proposal would open the door to deletion of articles that just don't happen to be interesting to the handful of editors who regularly visit AfD, even when the nomination is obviously spurious or misguided. Admins should be both allowed, and expected, to use their discretion to relist, or otherwise ensure that deletion is for policy-based reasons, not just because no one could be bothered that week. Elemimele (talk) 12:10, 15 January 2024 (UTC)[reply]
Oppose may open door for misuse. I see these cases as no consensus to delete which if anything should default to keep. Well-meaning proposal but defies conventional wisdom. --PeaceNT (talk) 04:36, 16 January 2024 (UTC)[reply]
Support. If nobody cares enough about an article to make a brief comment on an AFD, it does not have enough support to exist. Stifle (talk) 09:52, 16 January 2024 (UTC)[reply]
Meh This RFC seems poorly written, as it fails to note that very section the nomination links to goes on to offer several options for when it was an opposed prod, one of which already is soft deletion. It's unclear to me whether "supports" will be interpreted as supporting the status quo or as calling for something more strict, and I could see some opposes actually supporting the status quo too. I see there was a better-worded RFC on this topic at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes that didn't get many responses.
Personally I think we can afford a relist or two before soft-deleting, even if the de-PRODder didn't notice the AFD to oppose there too, per WP:NODEADLINE. But leaving it open to admin discretion (i.e. the status quo) is ok with me too on the assumption that admins will save immediate soft deletion for clearer cases. Anomie⚔12:12, 16 January 2024 (UTC)[reply]
Oppose For similar reasoning as King of Hearts. I would not necessarily be opposed to this in cases with a multi-year gap between PROD and AfD, but I do not like the idea of essentially being able to PROD an article twice in a short period of time. As for a timeframe, leave it to admin discretion. Curbon7 (talk) 12:24, 16 January 2024 (UTC)[reply]
Oppose - a week is nowhere near enough time, a lot of articles for deletion are likely to be on more obscure topics, that we possibly should have articles about, but that most editors will not be familiar with. A week is not enough time to be seen by someone who might be able to expand the article or explain it's importance. If there's an automatic deletion cut-off it should be closer to a year. Irtapil (talk) 15:11, 16 January 2024 (UTC)[reply]
Procedural Oppose per Anomie. There is a lot of context missing from this RfC, such as how that sentence got added to the process and the conflict with another part of the same section, i.e. it may already be an option. I put forward a discussion at Wikipedia talk:Deletion process#Clarifying NOQUORUM Soft Deletes to try and discuss some different wordings and options that could be used in a proper RfC per WP:RFCBEFORE. It would be advisable to close this discussion, workshop the wordings on that talkpage, and come up with a more comprehensive one since the current wording is self-contradictory. The WordsmithTalk to me20:52, 16 January 2024 (UTC)[reply]
I take this proposal to be stating that we should strike and the article hasn't been declined for proposed deletion in the past, which I think would resolve the contradiction. voorts (talk/contributions) 04:01, 17 January 2024 (UTC)[reply]
If that's what this means, then support, to strip away some bureaucracy and also get rid of the kind of nonsensical idea that some CoI or other "problem article" writer gets a special "right" for having removed a prod tag while addressing no problems in the article. — SMcCandlish☏¢ 😼 01:31, 18 January 2024 (UTC)[reply]
I don't think that would have been deleted after just one week. There's no consensus for deletion in the first week - two different redirect arguments and a delete !vote. -- asilvering (talk) 00:07, 20 January 2024 (UTC)[reply]
eh. I appreciate the reasoning, but I don't much like the idea of an unopposed AfD being soft-deleted at the end of a single week, and I don't really think it's too much to ask that someone second an AfD in the event that an article was deprodded. I'd be happier with the idea if it was something like "can be treated as an expired PROD if they've been relisted at least once", I suppose. -- asilvering (talk) 00:14, 20 January 2024 (UTC)[reply]
I'll generally relist a no comment nom when I'm patrolling the logs but when no one has argued in support of retention or even commented indicated an interest, I will close these as a soft delete. No one has shown up in that two week window but if they do down the road, they don't need to do the DRV dance. They can have it restored and it can be addressed, if necessary at that time. I do think a week might be too little of a time though so while i do this, I'm not in full support. It's something that deserves merit though. StarMississippi01:31, 20 January 2024 (UTC)[reply]
Oppose if an article is ineligible for PROD, it is because someone has deprodded the article and would, presumably, !vote to keep in an AfD. They should not be expected to have to do this twice. I would be in favor of considering a time limit on prod (ie articles proposed for deletion >10 years ago can be re-proposed), when considering how much our notability standards have changed, and the possibility for PROD to be abused. Eddie891TalkWork15:55, 20 January 2024 (UTC)[reply]
@Eddie891 I don't think this is an accurate assumption. I frequently see PRODs like "article has existed since 2007, take it to AfD". Many de-prodders give no reason at all, and also do not show up to the AfD. -- asilvering (talk) 00:00, 22 January 2024 (UTC)[reply]
yes, but the implied de-prod reason in the first instance you give is that the person is suggesting the article be taken to afd, where more editors can !vote on the afd. And editors not showing up to the AfD is part of why I opposed— we cannot expect good faith de-prodders to have to keep tabs on a subsequent afd nomination and comment again. Eddie891TalkWork00:13, 22 January 2024 (UTC)[reply]
If I PROD an article, I keep it on my watchlist in case it is de-PRODed, so I can then determine if I want to take it to AfD. Presumably a person asking to take something to AfD will want to participate in that discussion, and if they do not, I don't think asking someone to take something through another bureaucratic hoop is a great reason to de-PROD. voorts (talk/contributions) 00:21, 22 January 2024 (UTC)[reply]
The person is suggesting the article be taken to AfD, yes. But it doesn't make sense to infer from that that the de-prodder would vote "keep". In my experience, they do not, since "article has existed since 2007" (or whatever) is not a valid keep rationale, and they can find no other. -- asilvering (talk) 00:27, 22 January 2024 (UTC)[reply]
On multiple occasions I've deprodded something not because I think it should be kept necessarily, but because I believe determining whether the topic should or should not have coverage on Wikipedia and/or whether it should have a standalone article or be covered on a broader one (i.e. merge and/or redirect) needs more time and effort than PROD allows. For example, I deprodded The Roaring Twenties (band) recently because google searches brought up so many false positives that determining whether sources exist for the subject is not possible from just a cursory look - especially as many of the obvious ways of excluding false positives will also exclude an unknowable proportion of true positives if they exist. In other cases I've deprodded because the most likely place sources are going to exist is in offline resources and/or in languages other than English. A third category is where the only realistic outcomes at AfD are keep, merge or redirect. Thryduulf (talk) 22:38, 7 February 2024 (UTC)[reply]
Sure, those are all fine reasons to contest PROD. That's exactly why it doesn't make sense to infer that a de-prodder would vote "keep". -- asilvering (talk) 03:25, 8 February 2024 (UTC)[reply]
But a PROD isn't a keep vote, it's a statement saying "this article should not be deleted by PROD." If there's no subsequent discussion at an AfD on an article that has been PROD-ed, the two statements are "delete this article" (nominator) and "don't delete this article through PROD" (the de-prodder) which is a no consensus as far as deletion is concerned. SportingFlyerT·C20:29, 13 February 2024 (UTC)[reply]
Support: it is too easy to create an article that worsens the encyclopedia's quality and too difficult to delete it. Anyone may object to a PROD without a valid reason, but only justified AfD comments are taken into account by the closer. Deletion should not be prevented because of baseless objections by article creators. Soft deletion after no reasoned opposition at AfD is a good approach. Relisting indefinitely is not a solution to low participation at AfD as a venue: the same number of discussions will need contributors regardless of how long they are open. A closing admin who sees the nomination is poorly reasoned should not delete the page. They should instead !vote in the AfD, present some references and/or improve the article (just as they should if it was a nomination and three baseless "delete" !votes). — Bilorv (talk) 21:37, 21 January 2024 (UTC)[reply]
Oppose - A week is too short of a time, so I would appreciate at least one relist. Since there are no requirements for editors in nominating an article for deletion (just expectations), suggestions to require a more complete nominations are unrealistic, or subject to interpretation by the closing editor. --Enos733 (talk) 19:13, 22 January 2024 (UTC)[reply]
Oppose I don't see anything wrong with the procedure here of relisting ineligible AfDs when discussion is light. The problem is really just that we need more AfD participants. SportingFlyerT·C19:16, 22 January 2024 (UTC)[reply]
Oppose - One week is not long enough. If it went through the cycle three times with nobody offering an opinion, I might see it — but when's the last time that has happened? A solution in search of a problem — or a short-sighted "solution" that will create problems. Carrite (talk) 03:53, 23 January 2024 (UTC)[reply]
Strong support If the administrator believes an relist would be appropriate, they should relist it. If an administrator believes an article that has received no opposition to deletion should be deleted similar to PROD, they should delete it, with the opportunity for REFUND. I see no need to forbid soft deletion in these cases that typically still result in deletion and no need to expect others to expend time casting a !vote for what may be obvious or easily undoable. Reywas92Talk21:42, 24 January 2024 (UTC)[reply]
Oppose per KoH (who, no, I am not related to). If someone has previously objected to deletion, we should not just go behind their backs deleting it. QueenofHearts04:13, 26 January 2024 (UTC)[reply]
Oppose A handful of editors are saying it doesn't harm anyone. It will drive off many a new editor who sees their hard work turn into a red link and who leaves without asking for a WP:REFUND, either due to ignorance of its existence or anger/sadness with the community. Also per Thryduulf in particular. Sincerely, Novo TapeMy Talk Page18:30, 30 January 2024 (UTC)[reply]
If people use AfD as cleanup, then this would be true. But it an experienced editor truly believer an article was not notable, no process whether DRAFT'ication, reviewing it or even PROD'ing it will make it notable. New editors should interact with kind AFC reviewers and or NPP reviewers. I see this proposal as reducing the amount of time in AfD to precisely increase time for reviewing AfDs themselves and reviewing new articles. But testing this out would reveal that better. ~ 🦝 Shushugah (he/him • talk) 21:46, 7 February 2024 (UTC)[reply]
People shouldn't use AFD as cleanup, but it happens quite often. New editors should interact with kind AFC/NPP reviewers, but many get bitten instead. This proposal will not go any way to remedying either problem, rather it will make the impact of people incorrectly using AfD as cleanup worse and it will increase the number of new editors who are bitten. Thryduulf (talk) 22:24, 7 February 2024 (UTC)[reply]
As Thryduulf wrote, unfortunately many do use AfD as cleanup.
Also, any logged-in user, regardless of knowledge of policy, may nominate. The proposal doesn't require anyone to vote (assuming I'm reading it correctly), so experienced editors may not even voice an opinion. Sincerely, Novo TapeMy Talk Page18:12, 9 February 2024 (UTC)[reply]
Strong Support AFDs with no participation is a major problem in this process, there are at least 20-30 of them that get zero attention at any given point of time - just look at Cyberbot. Saying that more people should join AFD is NOT going to solve things, most people gather around a few popular AFDs anyway and ignore the rest. Swordman97talk to me22:17, 5 February 2024 (UTC)[reply]
Support? oppose per below - I don't think I understand the opposition. The proposal requires closing admins to go through the "before deletion" part of WP:PROD, right? That includes making sure "The page is eligible for proposed deletion: the page is not a redirect, never previously proposed for deletion, never undeleted, and never subject to a deletion discussion." So let me spell out what I'm supporting: PROD → DEPROD → NO-VOTE AFD → NO SOFT DELETE [NO PROD/DEPROD] → NO-VOTE AFD → SOFT DELETE What am I missing? — Rhododendritestalk \\ 18:11, 6 February 2024 (UTC)[reply]
I think I got caught on the fact that once an article has gone to AfD, it is by definition ineligible for PROD, and this was to address that problem but is worded in an overly broad way. Sounds like extra breadth (to apply to articles that have been prodded/deprodded in the past) is kind of the point. In that case, yes, I am opposed. — Rhododendritestalk \\ 18:27, 6 February 2024 (UTC)[reply]
Oppose per king of hearts but I do think that allowing a PROD again after a long time period (10 years? 5 years?) is reasonable. Hobit (talk) 21:13, 7 February 2024 (UTC)[reply]
Why does the passage of time automatically make something that was controversial no longer so? Sure it will in some cases, but unless it does in at least the significant majority (which I'd be interested to see evidence for) then it doesn't strike me as beneficial to the project. Thryduulf (talk) 22:26, 7 February 2024 (UTC)[reply]
To me it's because an objection from years ago has little weight now. Our inclusion guidelines (and more so, how they are interpreted) have changed significantly in that time. An old objection based on how things were doesn't seem like it's hugely relevant at this point. It's not something I really want, but I think it would be a reasonable compromise. Hobit (talk) 23:49, 7 February 2024 (UTC)[reply]
That assumes that the old objection related to something that is no longer relevant and/or standards that have been superceded. That is going to be true in some cases, but in other cases the objection is still going to be "hugely relevant" today. For example rationales like "plenty of sources in books", "seems notable based on the <other language> Wikipedia article", "widely covered in contemporary (non-English) newspapers", "sources seem to be available but they're paywalled so I can't check myself" and "if this is not individually notable it should be merged not delete", for example. It would be better if sources were in the article of course, but assertion that sources existed 5-10 years ago is as much a reason to take it to AfD today as it was 5-10 years ago. Thryduulf (talk) 01:12, 8 February 2024 (UTC)[reply]
Fair. And because AfD is always a way forward, that's reasonable. But it feels reasonable to me to let them expire as described. I agree it could be abused. Hobit (talk) 01:48, 8 February 2024 (UTC)[reply]
Oppose I've been here for (mumble, mumble) a very long time, & this is the first time I've heard of "soft deletes" & I don't understand the point of it: an article is either kept or deleted. And if someone as experienced as I doesn't understand the point, I figure new volunteers will be equally confused. (Unless they are uniformly smarter than me, which is entirely possible.) -- llywrch (talk) 22:18, 8 February 2024 (UTC)[reply]
AWP:Soft delete is basically a PROD that spent some time at XfD and received very few (if any) comments rather than being prodded. If a page has been prodded or soft deleted anyone can get it back by going to WP:REFUND and asking. If a page has been deleted following a consensus, they need to go to DRV and convince folk there that there was something significantly wrong about the deletion. Thryduulf (talk) 22:44, 8 February 2024 (UTC)[reply]
Oppose I think that this is the defacto process for those anyway, except that this proposal speeds up the time table. Lots of AFD's need more than a week to get some input. North8000 (talk) 23:04, 8 February 2024 (UTC)[reply]
Reluctant oppose This creates a loophole where deprodding can be bypassed through a low-attendance AfD (i.e. you prod, they deprod, you AfD, they ignore or fail to notice it, the article gets deleted, all in a relatively short amount of time). I would support if the proposal specified that the deprod must have been at least (say) five years ago. I would alternatively support a proposal to "expire" old deprods as King of Hearts suggests (in which case this proposal would be unnecessary). I would also also support a proposal to discourage (but not prohibit) relisting more than N times (for, say, N=3), to encourage the closing admin to select another option (policy already allows the use of soft deletion at the discretion of the closer).This is already in the policy, oops. Any proposal along those lines would have my support. It's just this particular combination of features that, in my opinion, is problematic. --NYKevin04:17, 11 February 2024 (UTC)[reply]
Mild support though I think one re-list is a reasonable check on this. It's pretty rare that something slides through AFD without any comments, and there is always a WP:REFUND later. Shooterwalker (talk) 14:42, 16 February 2024 (UTC)[reply]
Strongest possible oppose This will certainly result in articles that should not be deleted getting deleted and remaining deleted, per other opposes above. AFD soft deletes are a problem and we don't need any more of it. One takes an article to AFD in the hopes that an enforceable consensus will determine the fate of the article for what is usually a considerable amount of time. Soft deletes of AFDed articles are a loophole for COI/UPE. If I counted all the times problematic articles got soft deleted by admins not knowing to evaluate whether a misuse was likely, and got refunded soon after, I would be very mad right now, and that's just not healthy. Usedtobecool☎️15:49, 19 February 2024 (UTC)[reply]
Discussion (RfC: allow soft deletion of unopposed nominations)
So not comment then default deletion ..... do those involved in deletion at least look for sources...as in is there an common sense or effort involved if noone comments? Moxy-04:48, 14 January 2024 (UTC)[reply]
MIKTA is just a case of a really bad nomination by a user who clearly sent an article to AfD without Googling its title. Lazy nominations are a problem with or without soft deletion. Pichpich (talk) 04:35, 15 January 2024 (UTC)[reply]
Perhaps, although I'd be counting on the closing admin to review the deletion rationale before actually soft-deleting the article, just as I'd expect admins to close PRODs as deletions only after performing the usual and basic WP:BEFORE checks. Am I just being naïve here? Pichpich (talk) 12:58, 15 January 2024 (UTC)[reply]
Am I just being naïve here? unfortunately you are. While the worst offender that I know of was desysopped, there is no shortage of deletions being done without proper checks. Thryduulf (talk) 14:56, 15 January 2024 (UTC)[reply]
I know for a fact at least some admins don't look at articles at all when closing deletion discussions, so no. (And TBF deletion closers have a lot of work to do without replicating the participants work) Mach61 (talk) 16:49, 15 January 2024 (UTC)[reply]
The admin instructions for handling expired PRODs do not require us to conduct checks for sources (etc.) prior to deletion, but if you feel they should be changed to include such a requirement, feel free to gather a consensus to that effect at Wikipedia talk:Proposed deletion. WP:BEFORE is a part of a different process, namely WP:AFD; PROD is intentionally a more streamlined process. Stifle (talk) 08:55, 23 January 2024 (UTC)[reply]
The intention behind this proposal is decent. I might encourage another proposal with a few more checks and balances, but I think it's so rare that a deletion discussion would go more than a week with no response. Shooterwalker (talk) 14:38, 16 February 2024 (UTC)[reply]
Notes
^with the relist comment Not eligible for soft-deletion (due to contested prod back in 2006 (!) ...)
^a batch nomination of seven was relisted because one had been dePROD'd
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.
Although this hasn't been kicking for quite 30 days yet, it looks ripe for closure with no input in a few days and a pretty solid ratio. There is no consensus to authorize General Sanctions for the topic of Darts. By the numbers we're looking at an almost even split, and there are no strong policy based arguments that support or refute the authorization of GS, so it comes down to if editors believe that the disruption is severe and widespread enough to warrant GS. Arguments from those supporting the authorization simply weren't enough to convince even a slim majority that GS was necessary, rather than the enforcement mechanisms we already have in place. ScottishFinnishRadish (talk) 19:26, 13 February 2024 (UTC)[reply]
After reviewing this thread, the linked diffs and talkpages, and the requested closure above, I'm supremely unimpressed with the conduct of a number of people in this topic area. It certainly isn't just one person, incivility is rampant throughout the area. In order to break the back of this problem, I'd propose General Sanctions be authorized for the Darts topic area, text below copied from WP:GS/PW. The WordsmithTalk to me02:04, 17 January 2024 (UTC)[reply]
Any uninvolved administrator may, at his or her own discretion, impose sanctions on any editor working in the area of conflict if, despite being warned, that editor repeatedly or seriously fails to adhere to the purpose of Wikipedia, any expected standards of behavior, or any normal editorial process.
The sanctions imposed may include blocks of up to one year in length, bans from editing any page or set of pages within the area of conflict, bans on any editing related to the topic or its closely related topics, restrictions on reverts or other specified behaviors; or any other measures which the imposing administrator believes are reasonably necessary to ensure the smooth functioning of the project.
Prior to any sanctions being imposed, the editor shall be given a warning with a link to this decision and, where appropriate, should be counseled on specific steps that he or she can take to improve his or her editing in accordance with relevant policies and guidelines.
Sanctions imposed may be appealed to the imposing administrator or at the appropriate administrators' noticeboard.
I considered it, but chose not to on purpose. WP:CTOP is specifically tied to Arbcom and subject to their oversight; we still have template issues leftover from when Contentious Topics replaced WP:ACDS. By using the older Discretionary Sanctions language, it makes things much more clear that it was placed by the community and not Arbcom, that it doesn't happen at WP:AE or get appealed to WP:ARCA, etc. Separating community-based sanctions from arbcom-based sanctions reduces confusion in the long run. The WordsmithTalk to me06:10, 17 January 2024 (UTC)[reply]
Over the long run, personally I think it would be simpler to have one procedure for authorizing additional actions by administrators, with either the community or the arbitration committee designating topic areas where the procedure can apply. I appreciate, though, that this would be breaking new ground for the community and so at present has more uncertainty. isaacl (talk) 06:21, 17 January 2024 (UTC)[reply]
Before Wikipedia even existed, I received the wisdom that politics, religion, and sports were subjects that caused heated arguments. So I am not surprised at all. That said, from what I've been able to follow of the dispute here, it's not the topic, but the fact that articles have been written in one form for a long time, and the argument is over whether that form adheres to our policies and guidelines. It's the common "But no-one has objected since 2006!" argument, combined with arguments over Manual of Style compliance, original research, and sports statistics, all of which have provoked heated arguments in other areas in the past. It's not really darts itself that is being argued about. Uncle G (talk) 12:01, 18 January 2024 (UTC)[reply]
Nothing that cannot be resolved with some AGF colleborative discussions. But that will need the necessary goodwill on both sides. An outsider barging in with "my opinion can't be swayed" as their motto doesn't work at all, as the last two years have shown. And assuming bad faith of the darts regulars isn't helpful either. This proposal is an overreaction. It will only discourage discussion. Tvx117:32, 18 January 2024 (UTC)[reply]
Ah, yes, the perennial WP:CONTENTAGE "argument to avoid", which supposes incorrectly that old content is mystically exempt from later changes to policies and guidelines and process (often even compliance with the P&G rules that existed all the way back then but weren't followed in that topic at the time, without much of anyone noticing). The more obscure a topic is, especially if it has a fans/practitioners editor base that leans in a walled-garden direction (often via a topical wikiproject), the less it tends to attract cleanup efforts, especially compared to things of broad editorial interest like major sciences or globally famous persons. It's a severe misunderstanding of WP:EDITCON, a supposition that because a loose consensus can be established simply through acceptance of content being as it is for a long time that this equates to the formation of an ironclad topic-specific consensus that somehow overrides any highly-specific site-wide consensuses established through affirmative processes, like policies and guidelines, that have a much higher WP:CONLEVEL. This fallacy is a long-term source of squabbling, across many topics. I only ends one way (with the P&G eventually being followed as in every other topic), but has a very corrosive effect on editorial goodwill. Sports and games in particular are commonly a nexus of this recurrent problem. CONLEVEL policy was created to curtail it, but perhaps is not clear enough, or simply too infrequently acted upon. — SMcCandlish☏¢ 😼 18:32, 18 January 2024 (UTC)[reply]
I'd forgotten about that, and it's worth developing further. Though that rather long discussion was most immediately about WP:YEARS and "their" articles, WP:ITN, and a few other specifics, what SnowRise said there (in part paraphrasing Levivich) resonantes strongly and is broadly applicable. — SMcCandlish☏¢ 😼 06:50, 19 January 2024 (UTC)[reply]
Oppose This is a massive overreaction. The entire situation really revolves one user, who even during the AN report stated their intention that they would not colleborate and stated that "their opinion can’t be swayed", against whom the community seems to be unwilling to take action. This proposal amounts to using a large blow torch to get rid of a fly. All it really needs is users on both sides to be colleborative and to accept nothing is black and white here.— Preceding unsigned comment added by Tvx1 (talk • contribs)
The issue goes far beyond the one person you're pursuing an indef on, as well as the other two long term users who have been indeffed over Darts content. Invicility, WP:BATTLEGROUND conduct, and WP:OWNership seem to run rampant in this topic area. For avoidance of doubt, here are a few examples of your own recent conduct: [1][2][3][4][5]Wrong link, should have been [6]The WordsmithTalk to me17:28, 17 January 2024 (UTC)[reply]
What point are you even trying to make with these diffs? More than half of them is me just reporting factual events like two users having been blocked. Care to explain what policy I violated posting that? Or is it just a blockable offense to just post something in a darts-related discussion that doesn't agree with the non-regular darts article editors?? As for the first two, maybe you should also read and cite what I was replying to? Heck, I'm not even a member of that darts project, I'm just an occasional editor to those articles, mostly those on the world championships. I was just baffled by behavior shown on the talk page by BOTH sides during the last world championship and it's still inexplicable that only one of the users who resorted to personal attacks was sanctioned. Even more so because the unsanctioned users had displayed the same behavior before in an other topic area and got topic banned there as a result, and because the user did not show any insight on their behavior and no willigness to change during the AN proceedings. I honestly don't understand why you and others keep putting all the blame on one side. In fact all the drama that occured over the past two years in that topic area is somehow connected to that user. A core issue is their ""my opinion cannot be swayed" they displayed throughout and which they reiterated at WP:AN. That's why I maintain that this proposal amounts to suggesties to using a nuclear missile to kill ant. Start with dealing with that one user, as multiple people suggested during the AN, and then see how things evolve at the topic over next weeks and months before resorting to such drastic measures as general sanctions.Tvx117:25, 18 January 2024 (UTC)[reply]
I honestly don't understand why you and others keep putting all the blame on one side. The whole point I am making is that all the blame is not on one side. This entire time you've been crusading for an indef on ItsKesha, and you're right that she's been grossly uncivil. Much of her behavior has also been in response to even worse personal attacks and even slurs hurled by the now-blocked editor and others. That doesn't excuse it at all, but rather it points to a wider problem. As far as which policies you've violated, right off the bat You need to learn to read is clear WP:NPA and WP:CIVIL violations, especially given that it was a response to a ten month old comment. The rest demonstrates WP:BATTLEGROUND conduct, WP:OWNership, and assumptions of bad faith, though my fifth diff has the wrong revision so I'll correct that now. The point is that there's enough conduct here to block half the editors on Darts pages, but instead I'm trying for a gentler approach of "final warning for everyone, cut it out or else". The WordsmithTalk to me20:28, 18 January 2024 (UTC)[reply]
Battleground, Ownership and assuming bad faith are things that I hope are not referring to me, because these are not characteristics of mine. I was one of the few who actually did the effort of carefully reading the policy and guideline arguments and the relevant policies and guidelines and properly adressing the arguments. I certainly do not consider myself the owner of any article ever. And as I said, I'm not a darts project member at all. Just an infrequent editor of some related articles. Tvx123:51, 30 January 2024 (UTC)[reply]
Support but with a time limit like a year or 18 months or something. We have too many topics that stay perpetually under conditions like these (community or ArbCom ones), when the problems are usually traceable to fewer editors than it takes one hand to count, most of whom learn their lesson, do something else around here, or go away entirely. — SMcCandlish☏¢ 😼 22:33, 17 January 2024 (UTC) PS: I don't mind waiting for a while as Tvx1 suggested. This might actually just fizzle out on its own. — SMcCandlish☏¢ 😼 18:33, 18 January 2024 (UTC)[reply]
@SMcCandlish: A time limit does seem like a good idea, though I'd suggest 24 months to capture the full 2024 and 2025 darts "seasons". Even the frequent use of words like "outsiders" make it clear that we're dealing with a group of entrenched editors centered on one topic area, and GS/DS/CTOP is the only tool we have that has a proven track record of success for this type of issue. The WordsmithTalk to me20:39, 18 January 2024 (UTC)[reply]
Sure, works for me, if it comes to actually needing the GS. Hopefully Tvx1 is correct that it won't be, though I'm not sure how that is determined? Do we have yet wait for yet another ANI to come up? — SMcCandlish☏¢ 😼 06:50, 19 January 2024 (UTC)[reply]
Oppose. We're talkin' 'bout darts...darts. GS is one of the worst pieces of Wikipedia red tape. I've been here for years and I still don't understand how it really works. This is some sort of heavy-handed response to a few people that can't play nice together. Just block them and move on. Don't put some big hanging sword over the entire topic. For the record, I've never edited a darts page, and couldn't really care less about the topic. I just happened to see this pretty randomly and was dumbstruck. 35.139.154.158 (talk) 05:33, 18 January 2024 (UTC)[reply]
Support having reviewed (what I could see) of the evidence, it is clear that nearly every single editor involved in the area has a tendency to go all BATTLEGROUNDy at the drop of a hat. See Tvx1 above. ~~ AirshipJungleman29 (talk) 19:57, 18 January 2024 (UTC)[reply]
Comment: I'm neutral on whether or not general sanctions would help, but I don't believe the problem is darts. The problem is one we've seen time and time again where a few editors take control of a specific corner of Wikipedia, establish their own way of doing things, and the community drags its feet on doing anything about it. GS is a bandage that might have a marginal effect on this outbreak, but it doesn't actually solve the problem. We don't need to fix the darts topic area, we need to fix WikiProjects and the way they facilitate ownership of content, and we need to start handing out bans to editors who can't engage civilly. If general sanctions are adopted, I agree that it should only be for a limited time. Thebiguglyalien (talk) 21:43, 18 January 2024 (UTC)[reply]
I'm not sure the problem is WikiProjects any more than it is Darts. To me the problem is groups of entrenched editors fixated on isolated topic areas (darts, roads, weather etc); they do tend to congregate at Wikiprojects but also regular article talkpages, project-space pages, etc. Even off-wiki locations, so restructuring the WikiProjects themselves won't be effective. Discretionary Sanctions are the one thing that's shown promise, so I think applying it to more of these areas could help correct the issue. The WordsmithTalk to me22:16, 18 January 2024 (UTC)[reply]
Overall I agree, but WikiProjects seem to facilitate it the most when this comes up, and getting better about restricting the whole "controlling a topic from a WikiProject" thing would benefit Wikipedia overall. But you're right that there's an underlying problem here beyond individual topics and beyond WikiProjects. Walled gardens need to be broken whenever they crop up, and group ownership over a topic area needs to be easier to address. Once a group of editors decides to ignore best practices in their topic area, there's very little recourse short of a massive Village Pump or ANI discussion (and even those are hit or miss). Thebiguglyalien (talk) 01:54, 19 January 2024 (UTC)[reply]
Yes, this is exactly the problem. We see the same things in so many areas, and LOCALCONs just self-perpetuate due to the editors in a niche WikiProject being the only editors following a DELSORT topic. So we end up with long-term "consensus" that, e.g., academic journals do not have to have ever received any significant or even secondary independent coverage to have an article, simply because editors in that area misrepresent an essay as if it's a real guideline or as if it was compatible with GNG at all. That leads to articles on pseudoscience-peddling academic journals that can only be based on puffy content from their own website and outdated, trivial primary data from an indexing service they applied to join... Or, e.g., the "600 articles on phone versions" from that other thread, or the "solar eclipses sourced only to primary news reports and listicles" issue pointed out there by @TryKid. It's Wikipedia-wide. JoelleJay (talk) 03:42, 19 January 2024 (UTC)[reply]
Believe me, I know. I spent several months challenging WikiProject ownership at WP:YEARS with mixed results, and I keep an eye on Wikipedia:WikiProject Deletion sorting/Events because many of the regulars there have decided that routine news coverage demonstrates notability. There just needs to be a way to address the Wikipedia-wide problem rather than playing Whac-A-Mole with general sanctions and then hoping that admins actually pay attention to the given area. Thebiguglyalien (talk) 04:10, 19 January 2024 (UTC)[reply]
It's dissapointing that some people only see the negatives of WikiProjects and don't see the many WikiProjects have actually been very positive to Wikipedia by colleborating to do things like writing multiple Good and even Featured Articles. Tvx123:41, 30 January 2024 (UTC)[reply]
Oppose I'm not sure that sufficient evidence has been put forth that this is a widespread problem, rather than being a few editors we could easily handle through regular process. I also don't see how this solves the walled garden issue. There is considerable muttering that the darts regulars are being recalcitrant. But somehow I doubt that GS is going to be used against the regulars. Indeed, it seems more likely that GS is going to be used against darts newbies, to keep out dissenting voices. CaptainEekEdits Ho Cap'n!⚓23:08, 18 January 2024 (UTC)[reply]
Contrary to the previous three users, when I read the pages the nominator links, I can see behaviours that rise to the level of community sanctions. Way back last year, JRRobinson was indefinitely blocked and topic-banned, but I think his conduct and language has become normalized in this topic area, and we're still seeing discourse at his level. The AN/I thread led to an indefinite block of Penepi, which I think is a useful intervention. In the AN/I thread, ItsKesha articulated a clear apology and retraction, and pledged to do better in future. I think the jury's still out on whether there's more to do; but as a precautionary measure, for the time being, I would support community sanctions.—S MarshallT/C10:07, 22 January 2024 (UTC)[reply]
Support: It's not just currently, but there've been issues with darts-related topics going back a decade or more. Some people might think the topic a petty one for sanctions, but the measure of a contentious topic is, well, the degree to which people are running to the battlements. Ravenswing 17:49, 22 January 2024 (UTC)[reply]
Leaning oppose. GS (and DS, CT, and the like) are good for a handful of particular problems: mainly blocks that won't stick, pages in need of more liberal protection, and editors who need to be topic-banned rather than blocked. They shouldn't be used just as ways for the community to signal its unhappiness with something, I don't think. It seems that the conduct issues in this area are already being resolved quite effectively when they're reported at AN[I], and adding general sanctions just adds more long-term bureaucracy for little gain. But I certainly support the underlying idea that the behavior in this topic area hasn't been appropriate and that admins should feel empowered to make blocks as necessary. Extraordinary Writ (talk) 07:42, 23 January 2024 (UTC)[reply]
Oppose, seems to be much more preferable to deal with on a case by case basis. While there is some issues with WP:OWNership from the looks of things, I don't see (and can't imagine) the problem to be articles about darts tournaments, but rather a behavioral thing with users. It might end up in shared spaces with darts and related talk pages... but "darts" are not the cause, and the topic doesn't seem like it needs to get hit with sanctions. Utopes(talk / cont)07:54, 24 January 2024 (UTC)[reply]
Strong Support I don't think that darts are above sanctions, and this topic area needs to be cleaned up from the link above. Culture is the single worst problem Wikipedia has right now. Swordman97talk to me22:04, 5 February 2024 (UTC)[reply]
Try lesser sanctions like blocks of the editors involved. A contentious topic or general sanction designation should really only be used when we need to discourage good-faith editors to ensure accuracy and minimal to no disruption. I am not seeing how this is a topic that will attract continued disruptive editing. Interesting side note: almost every topic designated on WP:GS already are very contentious topics in the real or academic world outside of Wikipedia. AwesomeAasim06:30, 7 February 2024 (UTC)[reply]
I was hoping that imposing sanctions on the topic area would be the less severe option, with the possibility of restrictions and blocks inducing better behavior without the need to actually impose blocks on anyone. Nonetheless this proposal doesn't seem likely to achieve consensus, so it may be necessary to take this advice the next time this topic area flares up. The WordsmithTalk to me17:09, 7 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Purpose of ANI
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.
Support as nom The new title would clarify the noticeboard's purpose to new editors. AN is much less clogged than ANI, and complex issues can be discussed in AN without the trouble of short archive durations or large page sizes. Catalk to me!16:31, 18 January 2024 (UTC)[reply]
Oppose ANI's original purpose is for "urgent incidents", which overlap with user conduct issues much more than they overlap with the routine administrator actions and ban appeals than AN sees more often. ChaotıċEnby(talk · contribs) 16:01, 18 January 2024 (UTC)[reply]
Oppose: “ANI” is just too iconic, and incidents that aren’t user conduct can sometimes appear. Both urgents and user conduct need urgent review, and splitting would require prospective people to watchlist subscribe to both pages and get everything at once. Aaron Liu (talk) 16:22, 18 January 2024 (UTC)[reply]
Weakish oppose. This isn't a bad thought, and if we were just setting up the noticeboard, I'd want to give it serious consideration. I do think it'd help newcomers understand the noticeboard's purpose more easily, and that it'd discourage the (frequent) misuse of ANI as a place to litigate content issues. My main hesitation would be that titling the noticeboard "user conduct" would make the "you've been mentioned on ANI/ANUC, therefore you've done something wrong" implication even stronger than it already is, which might in turn raise the heat level, which is, uh, not what that noticeboard needs. That said, I have to oppose because, in 2024, the noticeboard has been ANI for ages, and retitling it would cause disruption/make it harder to read the historical record. There is not a compelling enough need for a change to make that worth it. {{u|Sdkb}}talk16:50, 18 January 2024 (UTC)[reply]
Oppose. As I showed in the RM, incidents requiring immediate admin intervention aren't ANI's "secondary purpose"—the clue is in the name—they're the original and primary reason that the board exists. Its mob-justice user conduct function crept in over time without anyone really meaning it. If change is needed, it's in the other direction: we should be directing user conduct complaints away from ANI and towards lower-drama options like WP:DR and WP:XRV. – Joe (talk) 17:20, 18 January 2024 (UTC)[reply]
Oppose - This feels a bit like rearranging deck chairs on the Titanic, and would just continuously confuse users with 33% of posts being closed as "No action, take it to WP:AN". We don't need to create more problems in a board that's already rife with problems. Duly signed,⛵ WaltClipper-(talk)17:24, 18 January 2024 (UTC)[reply]
Oppose and topic ban Ca from meta edits/discussion about ANI Ca seems to be unable to drop the stick about ANI being not what they want it to be. The requested move was closed only 12 days ago and we are having a very similar discussion. --GuerilleroParlez Moi17:57, 18 January 2024 (UTC)[reply]
Ehhh, seriously? It was just seekings of consensus within process (the RM) after a bold edit, and following okay advice from someone else. I don’t see why this warrants a topic ban. Aaron Liu (talk) 18:03, 18 January 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I think I would prefer the reverse: discuss patterns of user behaviour at the administrators' noticeboard, and leave the incidents noticeboard solely for incidents that require immediate attention. isaacl (talk) 17:19, 18 January 2024 (UTC)[reply]
I find AN to be a place I'm more likely to check in on given the pace, volume, and temperature of discussions when I'm busy than ANI. Bringing some, but not all, of the discussions where temperatures flare the most to AN would, for me, not be any sort of improvement. Joe's suggestion above about directing some stuff to other forums already setup to handle them is also a good one. Best, Barkeep49 (talk) 17:41, 18 January 2024 (UTC)[reply]
To double-check my understanding, are you saying that you feel discussions on patterns of user behaviour as well as discussions of incidents requiring immediate attention are both discussions where temperatures flare the most? isaacl (talk) 18:07, 18 January 2024 (UTC)[reply]
I wrote the following a few minutes before the RfC closed, and I am not convinced there is WP:SNOW possibility of a change in the opposite direction: [Oppose, but] delete the words "and chronic, intractable behavioral problems" that were added to the page header in June 2018 per Joe Roe. ANI is certainly not a suitable venue for dealing with accusations of that kind. At the moment ANI certainly sometimes functions as a kangeroo court, where it is not possible to get natural justice or a fair hearing (!voters are not even required to be impartial, or to be capable of telling the difference between reality and fantasy, and there are no rules of evidence etc); such discussions there are sometimes vehicles for subjecting regular editors to harassment and psychological abuse, that sometimes rises to the level of a massive public show trial, complete with ritual public humiliation and threats, bullying, gaslighting and other pressure to make forced false confessions; such discussions there are sometimes vehicles for trying to gerrymander a content dispute by making false or frivolous conduct accusations in attempt to get the other side blocked or banned so that they won't be able to !vote in the content dispute; and such discussions there are sometimes a an exceptionally toxic environment, and sometimes not an environment compatible with the safety of editors either. James500 (talk) 20:08, 18 January 2024 (UTC)[reply]
@James500 I closed it due to the fact that the RFC is for changing the whole purpose of ANI in general, (which doesn't have a chance right now)) not just the header, that is why I left this section open so things like changing the header can be discussed. Seawolf35T--C20:23, 18 January 2024 (UTC)[reply]
I think there should be a more concerted effort to direct people to the more structured alternatives that already exist for specific types of disputes (WP:DRN for content disputes, WP:XRV for contested use of permissions, WP:AE for edits in contentious topics, etc.) and, as a last resort, ArbCom for the remainder. – Joe (talk) 07:54, 19 January 2024 (UTC)[reply]
For example, the heading "April 18" would appear as large as the page title, and an article title like OneGet would look like the "Bump XfD heading sizes" heading above. For obvious reasons, this does not include WP:Requested moves.
Yes. This would make all such individual page discussions subscribable, and only level-2 headings are subscribable due to technical complexity. As for the level-1 heading, most XfDs already have a separate page for each day's log anyway, so displaying it as large as the page title shouldn't cause much problems. Aaron Liu (talk) 17:00, 26 January 2024 (UTC)[reply]
@Aaron Liu: Two questions. (i) Have you informed all relevant bot operators, and the maintainers of scripts like XfD Closer? (ii) do you intend to alter old XfD pages? --Redrose64 🌹 (talk) 20:26, 27 January 2024 (UTC)[reply]
No and no. You do bring up a good point with notifying scripts, but I don't see any scripts other than @User:Evad37's XfDcloser and @Awesome Aasim's xfdvote that could be affected. I do not intend to alter old XfD pages, as there really isn't much of a point in doing so. Maybe we could only alter these beginning in March so monthly logs retain some uniformity. Aaron Liu (talk) 23:20, 27 January 2024 (UTC)[reply]
I see it as pointless. At the most, the heading for the top level should be level 2, not 1. If anything it could mess with scripts as stated by Pppery Redrose. I don't think my script would be affected, but others certainly can be. AwesomeAasim23:49, 27 January 2024 (UTC)[reply]
I think you meant Redrose Having the top heading would be very confusing and wouldn't have everything below it fold, and I can name at least one other discussion page that has level-1 headings. I don't see why it would be bad either, and while I don't know much about XfD closer's code, I suspect it'll be an easy fix of adding one equal sign to everything. Aaron Liu (talk) 01:08, 28 January 2024 (UTC)[reply]
Subjectively I prefer the look of the current smaller headings. Though I realise this is pretty small compared to the practical advantages of subscribing to a new topic. ― novov(tc)11:15, 28 January 2024 (UTC)[reply]
Some other thoughts: 1) Using H1's seems to be a bad practice and is avoided almost everywhere on enwiki. 2) Changing this would likely require patches to several pieces of software including WP:Twinkle and mw:Extension:PageTriage. 3) It may be a good idea to sandbox this and drop a link here so we can see what it would look like. –Novem Linguae (talk) 09:26, 30 January 2024 (UTC)[reply]
Traditionally the advice has been to avoid multiple first-level headings on the web, but for semantic reasons, rather than technical problems, assuming the heading structure is laid out in appropriate hierarchical order. (As far as I know, assistive technology such as screen readers don't have a problem, and search engines deal with it as well.) It can be argued, though, that a web page could semantically be a container for multiple documents, each with its own first-level heading. In the context of MediaWiki, since the software automatically generates a first-level heading for the page title, then semantically everything before the first = heading = in the wikitext would be its own document.
Although personally I feel a bit uneasy with more than one <h1> element on a page, I can't say that it causes any practical problems from a general web perspective (I don't know about the various tools and extensions used by editors). There are of course already English Wikipedia pages with multiple first-level headings, such as Wikipedia talk:Mass message senders. isaacl (talk) 18:44, 30 January 2024 (UTC)[reply]
I agree that there should be no technical wider-web issues; the HTML spec even provides an example of how outlines with multiple h1 elements can be rendered, so any fully-compliant user agent will take it in stride. Having said that, if there are a bunch of internal tools that will need to be updated to handle the change (and it seems that there are), then that's the more relevant technical issue. I'm not worried about the semantic aspect, given that something like XfD should prioritize the needs of its specific users, determined through consensus, rather than doggedly adhere to general advice. Regards, Orange Suede Sofa (talk) 00:18, 31 January 2024 (UTC)[reply]
If you mean how the list is transcluded under the final section, I actually don't see much of a problem with that as the headers will only appear at the end of the ToC. RfD was an intended target. Aaron Liu (talk) 23:48, 8 February 2024 (UTC)[reply]
I wonder how well the existing structure of MFD works for people using screen readers, when they go directly to the page. It has a =Level 1= (the page title), then nothing for ==Level 2== or ===Level 3===, but there is a ====Level 4====. I'm pretty sure that skipping levels like that is not recommended. WhatamIdoing (talk) 05:27, 12 February 2024 (UTC)[reply]
@WhatamIdoing: It's not in the HTML spec; you need to burrow about in WCAG 2.2 in order to find G141 Organizing a page using headings, which says To facilitate navigation and understanding of overall document structure, authors should use headings that are properly nested (e.g., h1 followed by h2, h2 followed by h2orh3, h3 followed by h3orh4, etc.). In the "Other sources" on that page, we have a link to WebAIM: Semantic Structure: Regions, Headings, and Lists which has The <h1> describes the page as a whole (and should be similar to the page <title>). A page should typically have only one <h1>. Headings <h2> through <h6> represent increasing degrees of "indentation" in our conceptual "outline". As such, it does not make sense to skip heading levels, such as from <h2>to<h4>, going down the page. --Redrose64 🌹 (talk) 18:19, 12 February 2024 (UTC)[reply]
In late 2022/early 2023, the discretionary sanctions procedure was overhauled by ArbCom and converted to "contentious topics". With now two different processes for two different kinds of sanctions there is now a lot of fragmentation and inconsistency in how contentious topics should be handled, with even conflicting wording. The main goal of this RfC is to unify the procedure used for all areas where general sanctions are in effect with the one designated by ArbCom, going forward.
As proposed at this time, there will be the some similarities and differences between community and arbitration contentious topics, including:
The imposition of the standard set of restrictions by consensus of administrators in a community designated topic would be at WP:ANI rather than WP:AE.
Reconsideration of contentious topic restrictions would be done at WP:AN instead of at WP:AEorWP:ARCA.
Awareness of a community contentious topic would include but not be limited to being mentioned in the discussion closing summary regarding that contentious topic, which is the closest there is to a "final decision".
And of course, ArbCom would be able to convert community contentious topics to those designated by the committee, after which all the ArbCom venues would have to be used from that point forward, though existing restrictions would remain appealable to WP:AN until renewed at ArbCom.
Survey (community contentious topics)
Support as proposer. It needs to be clear, especially for new editors, what contentious topics are and what the expectations are for editing topics designated as contentious by either ArbCom or the community. A unified procedure will ensure consistency rather than fragmentation and will make editing the list of contentious topics and their restrictions much easier. (I did do a little bit of work in the Module:Sanctions/sandbox adding in support for ArbCom contentious topics, as it would make it so much easier to use the related sanction templates. I also did work in user space to help envision what a unified contentious topics page might look like.) AwesomeAasim05:55, 7 February 2024 (UTC)[reply]
Strong Oppose The current iteration of WP:CTOP is far too tied in to the Arbitration Committee. The available sanctions and procedures are under the jurisdiction of WP:AC/PR can be modified by the Committee by motion at any time, which in this scenario would be binding on decisions made by the community without community consensus. Additionally, many of the General Sanctions areas have a set of restrictions that either exceed what CTOP would allow, or have a more limited subset of them. The community currently has the flexibility to customize sanctions based on the needs of the individual topic area (similar to how Arbcom can impose their own restrictions either alone or on top of the CTOP designation), rather than relying on a "one size fits all" solution. Regarding the possibility of Arbcom choosing to convert community-based CTOP to Arbitration Enforcement, the Committee already has the power to supercede and convert General Sanctions. They've done so before, in cases including WP:ARBCC and WP:ARBTPM. This proposal as written would reduce the community's autonomy and flexibility for the sake of consistency, and I don't see that as a net positive.
I would, however, support the community adopting a "standard/default" DS language that could be used when customization isn't needed, and reviewing all the existing GS areas to see if they should be abolished or modernized. Updating our own process, templates, info pages etc to completely separate from the Arbcom version would also accomplish this proposal's goal of reducing confusion and would be better than the current system of sometimes linking to CTOP, sometimes linking DS which redirects to CTOP (when they really mean the older version of DS), sometimes a completely different thing with no consistency. Template:Gs/alert is one example of this, where it links to WP:CTOP even when the actual restrictions are unrelated to that designation. Revamping our own procedures would be a better way to reduce fragmentation and confusion than glomming onto what Arbcom chooses to do. The WordsmithTalk to me18:32, 7 February 2024 (UTC)[reply]
I am not exactly seeing how this is a dealbreaker. The CT procedure applies only to designated contentious topics; community consensus or arbitration remedies can always add additional sanctions regardless of WP:CTOP like in WP:ARBPIA. AwesomeAasim22:13, 7 February 2024 (UTC)[reply]
Support The phrase "discretionary sanctions" is not clear and so the phrase "contentious topics" was introduced as an improvement. We should have clear and consistent language for contentious matters so that discussions and actions are comprehensible. Andrew🐉(talk) 08:57, 10 February 2024 (UTC)[reply]
Discussion (community contentious topics)
Cooperation of ArbCom
I wonder if adding in stuff to the WP:CTOP page and similar would require the petition and referendum process. If so, then I guess the merging of templates would have to hold off until a former petition and request for amendment actually passes. It is possible ArbCom will green light the merge if this RfC passes, but I do not know. AwesomeAasim05:55, 7 February 2024 (UTC)[reply]
I feel the community should work with the arbitration committee to assume responsibility for the contentious topic process, with a pointer to an arbitration-committee specific page where it can customize the process as it feels necessary. This would bring the process under community control, while still allowing the arbitration committee to adapt it to its needs. (There is no change to arbitration policy and so no need to amend it.) isaacl (talk) 19:07, 7 February 2024 (UTC)[reply]
Wouldn't that just be the status quo (or perhaps the old GS/DS) status quo? I think Arbcom is more agile than the community in drafting this kimd language given that passing a motion is easier than an RfC and motions can be adjusted mid vote which is nearly impossible to do with an RfC. Truthfully I think the right place to start is with the standardized language for community GS and perhaps to be more intentional about whether it wants its restrictions to be eligible to be heard at AE, though as The Wordsmith points out there are really good reasons for the community to decide not to do that. Barkeep49 (talk) 04:30, 9 February 2024 (UTC)[reply]
The process for authorizing discretionary sanctions was documented by the committee, and then later the community started authorizing discretionary sanctions, with its process pointing to the Arbitration Committee pages and saying, "like that". This resulted in the community's process being coupled to decisions made by the arbitration committee. I'm suggesting the reverse: have the community assume responsibility for the contentious topics process, and then the arbitration committee can point to it and say, "like that, but with our specific customizations". I agree the community can decide on its own on what contentious topic process it wants to create. I think it would be good, though, to check with the committee that it is amenable to adopting the community process as a base, and layering any desired differences on top. isaacl (talk) 04:52, 9 February 2024 (UTC)[reply]
That also sounds like a good idea: community authorizes the remedies that are appropriate, ArbCom implements them. If ArbCom were to deviate then they would just need to ask the community whether it is an appropriate deviation or not. AwesomeAasim17:28, 9 February 2024 (UTC)[reply]
The committee doesn't have to be constrained by the community as it is already authorized through the arbitration policy to enact remedies of its devising for matters within its scope. It would be simpler for editors to understand, though, if the arbitration committee version of the process was just a set of differences upon a common process. Differences could include things like additional administrator actions that could be performed, or a specific venue for appeals. isaacl (talk) 18:03, 9 February 2024 (UTC)[reply]
I think you know what I mean :)
WP:ARBECR is already used a lot by both the community and by ArbCom, like in WP:RUSUKR and WP:CT/A-I. What I am saying is if ArbCom feels that a specific sanction that there has never been any precedent for is necessary, they should propose it to the community, where there then can be consensus on the exact wording. Placement, enforcement, and appeals are all going to differ though depending on whether the restriction is placed by the community or ArbCom. AwesomeAasim18:43, 9 February 2024 (UTC)[reply]
The community can provide feedback on proposed decisions. I disagree that the committee needs to obtain community consensus on new types of remedies. The arbitration committee is empowered to impose a restriction that community consensus has been unable to reach through prior dispute resolution. If you are referring specifically to the standard set of restrictions that can be imposed for designated contentious topics, I still disagree that community consensus should be mandatory. Typically the committee will provide an opportunity for feedback and the last review of discretionary sanctions illustrates that it strives to lighten the load of enforcing administrators. isaacl (talk) 19:17, 9 February 2024 (UTC)[reply]
Regarding the extended-confirmed restriction, it was initially devised by the committee on its own. After taking some time to evaluate its effectiveness, the community chose to adopt it as an available restriction. isaacl (talk) 19:25, 9 February 2024 (UTC)[reply]
I agree with isaacl that ARBPOL and CONEXEMPT explicitly mean that the committee does not have to, with-in its scope, get community consensus.
However, ECR is a example of why I think the committee is better placed at the moment to be a leader when it comes to contentious topics. The committee having to deal with the absolute hardest conflicts means there is going to be more of an incentive to try something new and ~15 people are going to have an easier time getting to yes than what is required to get community consensus for that newness. It's also revealing to me that ArbCom gets more requests for us to assume community imposed sanctions (examples: COVID, Horn of Africa as two that the committee did assume and Russia-Ukraine War as one that committee has twice been asked to assume and haven't). I would really love it if the community could, as it does in so many other ways, demonstrate broader capabilities when it comes to general sanctions than it has in the past. And to that end getting consensus for some standard wording would be a great place to start. Barkeep49 (talk) 19:48, 9 February 2024 (UTC)[reply]
I agree that the arbitration committee is better positioned to try new approaches (consensus doesn't scale up well, so getting consensus amongst 15 people is definitely easier). In a similar vein as you expressed, I feel it would be ideal for the community to agree on a base contentious topics process, which the committee could extend in new ways that the community could later choose to incorporate back into the base process. isaacl (talk) 19:57, 9 February 2024 (UTC)[reply]
I definitely think we should split contentious topics from WP:AELOG. A separate contentious topics log would make restrictions much easier to follow - and, if the restriction is rescinded or converted from community to ArbCom or the other way around - it can be logged as well. AwesomeAasim21:21, 10 February 2024 (UTC)[reply]
Request revision to initial question
The statement all community general sanctions (DS) in the initial question is misleading. "General sanctions" is not synonymous with community authorization for discretionary sanctions. I think the intent should be clarified that the proposal only affects discretionary sanctions authorized by the community, and not all general sanctions. isaacl (talk) 19:03, 7 February 2024 (UTC)[reply]
If you look at wikipedia pages relating to club teams or club games it will often have lists of players and beside each one a little flag denoting 'nationality'. As per wikipedia protocol these flags represent sporting nationality rather than actual nationality however nowhere is this ever explained to the reader on the page. My suggestion is that where possible, for instance on a chart with a 'nationality' column, there should be a pop up note. Obviously for international sport this is not needed as it is obvious that used flags denote the country a player represents rather than actual nationality. Firestar47 (talk) 14:30, 12 February 2024 (UTC)[reply]
Separate Buttons For Visual Editing and Source Editing
As we all know, Wikipedia has two different modes of editing: visual editing and source editing. However, upon a visit to German Wikipedia to translate an article, I noticed that they separate the "Edit" button that appears on top of the page to two different buttons - "Edit" and "Edit Source Code" (the bar shows Read | Edit | Edit Source Code | History). I think that would be a useful change to make on the English Wikipedia. Sometimes you want to make simple edits and it pulls up the source editor, which means you have to waste a few seconds switching it, and vice-versa. This would simplify the process of editing as it would allow users to jump straight to visual or source editing depending on their needs without having to waste time switching it. It would also help let users know when a page only allows source editing instead of visual editing, which some pages do. StreetcarEnjoyer (talk) 20:50, 13 February 2024 (UTC)[reply]
I think you'll find it's more complicated than that. The mw:VisualEditor/Single edit tab (an unfinished project of the mw:Editing team; pinging @Trizek (WMF)) is better for brand-new editors, who don't know what the difference between "Edit" and "Edit source" is. For myself, as a power user, I prefer two tabs, and I use both frequently, based on what kind of edit I plan to make.
Maybe edit source could be renamed to something like "edit wikitext" to better clarify what it does? When I was new I thought source editing would be editing HTML directly so it was a bit confusing. StreetcarEnjoyer (talk) 21:39, 13 February 2024 (UTC)[reply]
New editors don't know what "wikitext" is, so I don't think that will help.
I don't think there is a perfect name for this label. I believe I saw one comment, some years ago, from someone who thought that "Edit source" meant editing the Wikipedia:Reliable sources. Mostly, I think that people will figure it out by clicking on the button. WhatamIdoing (talk) 16:54, 14 February 2024 (UTC)[reply]
I believe it's time to consider updating the design of the main page. I'm not certain when the current style was implemented, but it seems to date back to 2006 or even earlier. Nowadays, there are numerous modern and colorful box templates available that could give the page a more contemporary look. What are your thoughts on starting this initiative? After all, the main page represents our entire community. I understand that changing a familiar style can be challenging for many users, but it's part of the natural cycle of updates.
Wikipedians don't like change (see above), so it's not going to happen without a lot of work, but I do agree that it's time for a redesign. Since the last major attempts a decade ago, responsive design technology has advanced enormously, a new design system has been rolled out across Mediawiki, and we got a new default skin. All of this makes the main page look particularly dated and out of place in 2024. Ideally, we'd proceed by asking Wikimedia's design team to lend us their expertise and create something new – subject to community-agreed goals and constraints but not a crude yes/no vote on using it (which would inevitably fall afoul of the "change is bad" phenomenon). – Joe (talk) 07:36, 14 February 2024 (UTC)[reply]
Riad Salih You could probably get consensus for the general idea that the MP should be changed, but the consensus would break down over what specifically to change it to, as everyone has their own idea about that. As noted, this is a constantly made proposal. The best chance of success would probably be to propose incremental changes, one at a time- a wholesale redesign would never gain consensus. Even a small change would take much work to convince others to support and implement. 331dot (talk) 08:53, 14 February 2024 (UTC)[reply]
One idea that might get approval is moving to a single column. The current layout was well designed when pages used the whole screen, but there are very few words on each line now that we have two thin columns shoehorned into a narrow stripe down the middle of the screen with an acre of empty white space either side. Certes (talk) 10:17, 14 February 2024 (UTC)[reply]
The white space is probably from the skin you are using. It looks fine in legacy vector. Easier to change the skin to something that you like rather than change the main page for everyone RudolfRed (talk) 01:41, 15 February 2024 (UTC)[reply]
From a purely selfish viewpoint (which is allowed, as this is an aesthetic matter), I want the main page to remain unchanged. I use Vector 2010, and everything looks just fine to me. However, the vast majority of readers don't have the luxury of setting that preference, and are stuck with wide blank sidebars. Certes (talk) 09:51, 15 February 2024 (UTC)[reply]
I use the full width view of new Vector, but when checking it on the narrow width, it looks fine to me. A little narrow perhaps, but not nearly constrained enough IMO to obviate the advantages of a two-column view. ― novov(tc)08:33, 15 February 2024 (UTC)[reply]
@Cremastra Yes, I do agree with that, especially the Slovakian one. However, you know we still need ideas from other contributors, which can be challenging. Nevertheless, I will make an effort to advocate the idea of changing the main page design. Riad Salih (talk) 14:19, 16 February 2024 (UTC)[reply]
I agree that the Slovakian one is too dated. I don't see any problems with the Spanish version under vanilla V22. Maybe swap POTD with On this day for slightly longer line lengths for the latter, make Other projects full-width (and maybe unbox it), and of course adapt ITN to our format, but I don't think the Spanish version needs any more changes. Aaron Liu (talk) 16:25, 19 February 2024 (UTC)[reply]
I would concur that it's a good idea. IMO, some of the other Wikipedias have Main Pages that put enWP's one to shame. But as others have stated, good luck finding something that everyone can agree on. ― novov(tc)08:38, 15 February 2024 (UTC)[reply]
Redesign it, but in a way that removes ITN and DYK. Both are massive investments for very little return, and much of the content they display is low quality. Thebiguglyalien (talk) 00:50, 19 February 2024 (UTC)[reply]
Fucking excuse me? How the heck are the articles that we've vetted low quality? ITN gives us some global perspective and is one way readers could keep themselves up to date in current events. DYK makes everything a bit more fun for everyone and trivia is fun. Both highlight our utility as an online encyclopedia and good work on our behalf. Removing it would make no sense at all. It has worked, it is working, and it returns. Aaron Liu (talk) 02:51, 19 February 2024 (UTC)[reply]
Thanks for the work, but unfortunately I don't like it very much:
I don't know any good ways to fix this, but flushing the Welcome banner's text to the left leaves a lot of blank space in the rest of the box, making it feel weird.
We already have a search box; we don't need another one.
The third column has line lengths that are way too short in the limited width. That makes the excessive space to the right of the descriptions all the more jarring. And that is in my version of V22 enhanced with my private styles. Under the normal limited width all the columns have line lengths that are too short and the sister projects' descriptions run off the page.
Something feels wrong about the concept of giving that much prominence to our sister projects. Wikipedia readers are hardly gonna go there and this introduces a lot of colorful icons that clutter up your attention. Previously it'd only take attention when you scroll/look down and want to dedicate attention to it.
Lots of useless blank space under the third column.
Probably a bug, but Other areas of Wikipedia appears twice.
That does look much better! Combining the search box with the first box seems alright, though maybe I'd use the tagline "Search free knowledge". I'd also recommend making the globe logo stick to the bottom of its box, replacing the whitespace between the first two boxes with a horizontal rule, and maybe put the occasional banner before that rule with a white background. Aaron Liu (talk) 18:48, 19 February 2024 (UTC)[reply]
Is it possible to have, say, the current main page visible to users with the Vector legacy skin, but a main page similar to eswiki's for Vector 2022 users? This way we could keep up the "modern" look for Vector 2022, but keep the "legacy" style for Vector legacy. I just don't know if this is technologically feasible. Relativity 03:06, 19 February 2024 (UTC)[reply]
I am dubious Why? No clear argument for why this would be desirable. Can we be sure it would not lower general accessibility depending on the device being used to access the site? I am not adamantly opposed to sprucing things up a bit. But the oft quoted adage "if it aint broke, don't fix it," definitely comes to mind. -Ad Orientem (talk) 04:43, 19 February 2024 (UTC)[reply]
I think where previous proposals have failed before is in trying to do many changes at the same time (e.g. changing the emphasis of different parts of the main page while also restyling it). Anyways I have a modest proposal, under the principal that less is more and that the boxes around everything is the most dated part of the main page, at User:Galobtter/sandbox/Main page. It could do more work from someone who actually knows how to design (I like ptwiki's main page header a lot and that could be incorporated), but all I did was basically remove unnecessary (imo) styling. Galobtter (talk) 06:13, 19 February 2024 (UTC)[reply]
I like that! It's simpler but clearer. Although something seems a little off with the header box, the lack of border makes it feel poorly-defined to me. 🌺 Cremastra (talk) 13:45, 19 February 2024 (UTC)[reply]
I like a lot of that, but (at least on Desktop on MonoBook) the colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides. Much better than the es.wiki one linked above, which is visually clean but seems to lack any sort of flavor. The WordsmithTalk to me16:42, 19 February 2024 (UTC)[reply]
I think the border's supposed to be like the heading's border. I believe that whatever we think about the rest of it, we should adopt the first box of the eswiki/ruwiki main page. Aaron Liu (talk) 16:52, 19 February 2024 (UTC)[reply]
colored section headers only seem to have a thin border on the bottom and nothing on the other 3 sides is intentional - I wanted to have a simple header style rather than having an unnecessary box around the headers. Yeah, I liked ptwiki's a lot more than eswiki's, which is probably technically the "best" in terms of modernization but is too bland. Galobtter (talk) 23:17, 19 February 2024 (UTC)[reply]
@Ahecht I added 1px of margin, which was missing since I removed the 1px border. It looks ok to me now, although you might be right that more margin is needed. @User:Cremastra I stole the box shadow from ptwiki - what do you think now?
I want to avoid doing more with this, since I think that's where previous proposals have failed - people want some of the changes but not others so it ends up a whole mess. And since at least some people seem to like this, I might try to put it up for RfC soon, but want to make sure there aren't small tweaks needed to what I've done. Galobtter (talk) 00:24, 20 February 2024 (UTC)[reply]
going to withdraw this proposal. To those of you who cited already existing powers among the admin and 'crat corps to enforce civilty: I agree, and we should be finding people who are willing to use them. I'll be one of 'em wherever I can. But let's revisit trying to fix RfA if it turns out that a reminder and encouragement doesn't do the trick. theleekycauldron (talk • she/her) 02:49, 15 February 2024 (UTC)[reply]
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.
The structure of this GS area would be modeled after the contentious topics procedure. It covers all participation in the requests for adminship (RfA) process, broadly construed. It does not cover mainspace editing about the request for adminship process, nor does it cover discussion of the same.
Uninvolved administrators and bureaucrats are held responsible for enforcing civility and all other behavioral policies and guidelines through all remedies available under the contentious topics model, as well as the ability to strike or remove comments (up to and include the vote itself) that are judged to be disruptive, corrosive, or otherwise in breach of conduct policy. They are not empowered under this topic area to institute "enforced BRD" or "consensus required" restrictions on a page, or to institute revert restrictions on a single editor. No part of this GS can be made to empower administrators or bureaucrats to enforce any policy they are not already tasked with upholding.
Requests for enforcement should be placed at the arbitration enforcement noticeboard (AE). An enforcement action can be overturned on appeal only with: a clear uninvolved editors at the administrators' noticeboard (AN); a clear consensus of uninvolved admins at AE; or (in more extreme cases) a clear consensus of uninvolved bureaucrats at the bureaucrats' noticeboard (BN). Standards of review for an appeal to uninvolved editors or administrators are listed here, and the same for uninvolved bureaucrats are listed here.
Support: Community sanctions are intended for topic areas where standard enforcement procedures are not enough to maintain decorum on the project, and, well, RfA and its chronic hostility problem certainly meet that definition. Not once, but twice in the past month or so have we had a situation where the bureaucrats failed to act on serious and baseless aspersions cast about a candidate in front of hundreds of other editors.
This, despite the fact that as far back as WP:RFA2015 (nine years ago!), we as a community came to the conclusion that incivility and battleground behavior at RfA is out of control and tasked the bureaucrats with improving it. But unfortunately, bureaucrat enforcement of civility norms has been scattershot and ineffective, and nearly all bureaucrats avoid the task entirely. We tried to fix this again in 2021, but no substantive changes were made. Thanks to a systematic failure of enforcement, RfA remains toxic and discouraging. This is a chance to do real good for future candidates who don't want to get hazed and future !voters who don't want to get badgered.
There is not going to be a perfect solution to all of RfA that waltzes down the aisle in a month or two if we procrastinate on this problem again – it's going to be another three to six years before we get another opportunity, and in the meantime, another crop of qualified candidates will be beaten down, discouraged, or scared off by the RfA process, not to mention the drama and time sink for RfA participants. It is time to fix what we all have already agreed, many times, is broken. I support, and implore the community to do the same. theleekycauldron (talk • she/her) 20:05, 14 February 2024 (UTC)[reply]
Oppose. I'm sympathetic to the intent here, I really am. But I think this proposal will make things worse instead of better. Sometimes editors take controversial positions in RfA discussions. Not too long ago, I did, in fact, and one admin left a message at my user talk, calling my comment "shitty". It would be too easy to end up blocking someone for not having a rationale that was "good enough". We already allow administrators to enact sanctions for violations of the WP:CIVIL policy, and the fact that there have been a few recent examples when no admin elected to do so does not mean that we need to enact a new category of community sanctions. Wikipedia just isn't very good at dealing with civility, unless it's very black-and-white. RfA is no more toxic than ANI (yeah, that's a ridiculously low bar!), so successful RfA candidates will just have to learn to deal with it. --Tryptofish (talk) 20:40, 14 February 2024 (UTC)[reply]
@Tryptofish: If civility is something the admins are already empowered to enforce, and the assertion is that admins being empowered to enforce civility would have them tend to abuse that power, why isn't that a trend we see already at RfA? The opposite is true: admins aren't using their current ability to enforce civility enough, maybe in part because of all the process questions around it. It's not the case that GS and CTOP have a reputation for admins who go around blocking people simply for having comments that aren't good enough, and I don't think RfA would be an exception to that – I think admins would be more cautious at RfA than they would be at ARBPIA or another similarly contentious topic area. theleekycauldron (talk • she/her) 21:02, 14 February 2024 (UTC)[reply]
I didn't mean to imply that I thought that admins would intentionally engage in any sort of abuse of the admin policy. Sorry if it sounded like I did. --Tryptofish (talk) 21:27, 14 February 2024 (UTC)[reply]
Oppose For most editors, that designation means that it's some type of a dangerous minefield and to not edit there. Not good to turn RFA into such. Having 1 or 2 outlandish posts isn't the thing that makes RFA something that most good potential admins don't want to go through. RFA needs some other changes. Sincerely, North8000 (talk) 21:18, 14 February 2024 (UTC)[reply]
that designation means that it's some type of a dangerous minefield and to not edit there As I understand it, for a very, very long time the community has considered RfA to be a toxic and broken system. I know several candidates who have described the process as one of the most stressful things in their life, in no small part because the toxicity of some RfA participants. The only thing we as a community haven't been able to agree upon is how to reform it and address these issues. RfA is already a dangerous minefield, the only difference in this proposal is that maybe we'd acknowledge that in a way that would see some improvement in the process' moderation (or lack thereof). Sideswipe9th (talk) 22:58, 14 February 2024 (UTC)[reply]
Oppose per wot Tryptofish and North800 just said. I just don't think this particular enforcement style is going to be compatible with the way RFAs work. Something is required, but GS is probably not it. Sohom (talk) 21:25, 14 February 2024 (UTC)[reply]
Oppose - This proposal is certainly well-intentioned, but it ultimately will just add more pointless bureaucracy. Honestly, all we need is for the bureaucrats to deal with the occasional bullshit accusation. Alternatively, an uninvolved administrator should be allowed to if the bureaucrats won't. Cheers! Reaper Eternal (talk) 21:57, 14 February 2024 (UTC)[reply]
Support. If this were an encyclopedic subject, it would have been designated a CTOP eons ago. Leeky perfectly explains why this might be beneficial, so I am going to take a look at the three reasons (that I can think of, at least) one might oppose this.
First, one might argue that there is no problem at RfA. I'm not going to say anything other than, really?
Second, one might say there is a problem but GS won't solve it. At the very least, I think we should try this. We will never know if we don't try. But I would also argue that CTOP usually works to ease the editing environment. I think one of the strongest endorsement of CTOP that I can give is to mention we haven't needed AP3 even with the Trump era of US politics.
The final one I can think of is that it is undemocratic: we shouldn't give admins the ability to deny people the right to !vote for/against a candidate. First, WP:NOTDEMO. Second, we choose admins for their good judgement: I don't think they will abuse GS to block a !voter for having The Wrong Opinion. Even if one did, that is not the real problem; the real problem is that such a person is an admin. But the purpose of RfA is to produce suitable admins to help Wikipedia function, not to allow the community to judge a contributor. If you can't respectfully disagree about abortion, you get tbanned, no matter your stance on the topic. If you can't respectfully disagree about climate change, you get tbanned, no matter your stance on the topic. And so on. It is perfectly possible to oppose a candidate without attacking them. If you can't do so, you shouldn't be allowed to participate. HouseBlaster (talk · he/him) 22:39, 14 February 2024 (UTC)[reply]
Oppose I'm sure this is well-intentioned, but it will probably do more harm than good. I do not believe RfA is actually as bad as it used to be, nor do I think the current problems are beyond the capacity of our admins to handle in a normal fashion. In practice, enacting GS would make it less safe to oppose a popular candidate, and I don't think that would be a good thing. I've seen a number of proposed solutions for RfA over the years, and I have come to the conclusion that RfA, to the extent that it is broken, is simply unfixable. LEPRICAVARK (talk) 22:52, 14 February 2024 (UTC)[reply]
I don't know if I feel strongly enough about this to oppose/support, but I can't really see this being helpful, and I think it's more likely to have negative unintended consequences. The problem isn't that no one can enforce civility on RFAs; the problem is that the rules we already have aren't being enforced to the degree that some (most?) people would like. That problem can easily continue under GS. Meanwhile, it seems pretty likely to me that with GS involved fewer people would feel comfortable opposing, whether there's any real risk there or not. -- asilvering (talk) 22:53, 14 February 2024 (UTC)[reply]
Oppose Like others, I believe this proposal was made in good faith. I think the simpler solution is that when these unfounded Oppose !voters or serial opposers comment, we just ignore them or follow WP:TYFYV. RfA is way less toxic than it used to be, and bad opposers are much less common than in the "too many admins"/"self nominations are prima facie evidence of power hunger" days. And yet, each bad opposer gets way more of a reaction than they used to. The better way is to trust Crats to strike or discount the !vote, which is the job we entrust them with. Having one or two opposers with dumb reasons isn't going to tank an RfA. The WordsmithTalk to me23:11, 14 February 2024 (UTC)[reply]
Support This strikes me as a good idea. For a very long time, the community as considered RfA to be a toxic and broken process. I know several candidates who have described the process as one of the most stressful things to go through in their life. As someone who primarily edits in one of our CTOP areas, I know from experience that the CTOP procedures far from perfect. However they do work in addressing some of the baseline problematic issues that frequently come up when writing content about controversial topics. Now this isn't going to fix all of RfA's problems, at the end of the day people are still going to be people, but it will help prevent some of the baseline problems that contribute to RfA toxicity.
In recent months, there have been at least three RfAs that I'm aware of where the crats have been asked to intervene in relation to problematic contributions from editors. Leeky mentions two of these in her !vote, the other I'm aware of was at Clovermoss' Rfa (BN discussion). I'm sure if I went looking, I could find other recent examples of this. Now I understand the catch-22 situation the crats find themselves in when getting requests like this. If they start taking moderation actions when requested, some of them feel as they would start being perceived as non-neutral at close time or cratchat. And there is an argument that maybe if we had more crats (we currently have only 19), some of them might feel more free to take clerking actions where necessary. However this proposal sidesteps that issue, by empowering non-crat admins to act in the exact situations that the crats are currently hesitant to act upon.
To the folks who are saying that this would make it, as Lepricavark said less safe to oppose a popular candidate, I respectfully disagree. If you want to oppose a popular candidate, you will still be able to oppose a popular candidate. If you have a good faith reason to oppose a candidate, and if you can evidence that and present it in a way that complies with the relevant conduct policies, I really don't think you have anything to worry about. If you feel a candidate is fundamentally unfit to be an admin, you will still be able to put forward a case to try and convince the community of this. What you won't be able to do however is make contributions that would almost instantly be reverted or redacted in any other venue, or be able to flagrantly contravene our civility policy and our policy against personal attacks.
Oppose as adding bureaucracy to something that can already be dealt with by reverting trolling, personal attacks or excessive rudeness. RFA is the place to be critical of a candidate, and extra rules should not be inhibiting that. Graeme Bartlett (talk) 23:45, 14 February 2024 (UTC)[reply]
Oppose I'm all for being nice but a candidate should be able to tolerate a couple of trolls. The problem is the attention they get and GS would just encourage more civil off-topic bickering. Johnuniq (talk) 23:54, 14 February 2024 (UTC)[reply]
Oppose. The standard conduct enforcement procedures don't seem to be inadequate here, rather they just aren't used as much as they could/should be. RfA is a regular projectspace page, and the comments made there should be held to the same standard as they would on any projectspace page; personal attacks should not be tolerated. However, the lack of enforcement is not a failing of it, and I'd prefer we try to be more proactive with standard enforcement before adding bureaucracy. Giraffer (talk) 00:23, 15 February 2024 (UTC)[reply]
Oppose. Administrators and bureaucrats (in their admin capacity) already have the ability to block someone if they are being particularly uncivil. Adding these specific proposed general sanctions doesn't enable admins to do anything new; it merely adds a level of bureaucratic friction should any block be challenged. But if the problem is that people aren't doing anything here, then merely adding more bureaucratic friction isn't a solution—we should try actually using our existing policies and guidelines before we declare that we need something extraordinary here. And if nobody is willing to enforce our ordinary policies and guidelines, then we should elect someone who will. — Red-tailed hawk(nest)02:31, 15 February 2024 (UTC)[reply]
Oppose If I'm understanding the proposal correctly, it would enable any individual administrator to unilaterally decide that someone should be indefinitely topic bannned from participating in all future RfAs. I don't like that – it's overreaching and if that kind of outcome is needed, it should result from a community discussion. DanCherek (talk) 02:45, 15 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Discussion (RfA civility)
wrt [i]t does not cover mainspace editing about the request for adminship process – is RfA a topic that should even be discussed in mainspace in the first place? M Imtiaz (talk · contribs) 20:35, 14 February 2024 (UTC)[reply]
Whilst I agree that RfA needs more guidance as to what can and can't be done - is GS the way to go? For instance, how would we notify users such sanctions are in place? Presumably this wouldn't include editing restrictions like on most other GS pages (such as 30/500). Lee Vilenski(talk • contribs)20:40, 14 February 2024 (UTC)[reply]
@Lee Vilenski: GSes that do 30/500 automatically often aren't full discretionary sanctions procedures like WP:GS/UYGHUR or this one. For this, no, I don't think we'd have any kind of need for an automatic 30/500. As to notification, that's something we take care of without much problem for other GSes and CTOPs – maybe we'd even consider an editnotice warning or other hatnote sufficient. theleekycauldron (talk • she/her) 20:48, 14 February 2024 (UTC)[reply]
To clarify, general sanctions is an umbrella term for ... sanctions that apply to all editors working in a particular topic area. Examples include a one-revert rule, an extended-confirmed restriction, community authorization for discretionary sanctions, and arbitration committee designation of contentious topics. If I understand your proposal correctly, you're proposing a new set of rules for Wikipedia:Requests for adminship and its talk page (and possibly some other associated pages). This would a be new restriction that falls in the category of general sanctions. isaacl (talk) 23:36, 14 February 2024 (UTC)[reply]
If the proposed set of rules explicitly disallows admins from enacting any remedies that they aren't already empowered to enact via existing policy and guidelines, then I think the comparison to contentious topics isn't quite apt. It's true that the contentious topics process allows admins to enact a remedy which cannot be reversed until there is a consensus to do so, which is similar to this proposal. However it also provides admins with a standard set of additional remedies. I suggest leaving out the part about modelling the proposed process after contentious topics. isaacl (talk) 23:47, 14 February 2024 (UTC)[reply]
I've thought about this some more, and I thought of something that I would have added to my comment in the now-closed discussion, so I'll say it here, instead. The discussions here grow out of a perception that RfA is an unpleasant process that discourages good candidates from coming forward. I share that perception, and I agree that it's a problem that would be good to solve. But the problem isn't with plainly inappropriate reasons for opposes, or personal attacks. Those things don't sink RfAs that should have been successful. They get refuted, or ignored, and the process works, albeit with a lot of users justifiably rolling their eyes at the refuted or inconsequential stuff. The problem, fundamentally, isn't even badgering of opposes or inappropriate questions to candidates, even though those things really are problems. None of these things are likely to discourage a qualified candidate from coming forward. No, the problem is that little things, like a bad day or a one-off mistake, get blown up out of proportion. A strong candidate is found to have, just once or twice, posted something that was a bad judgment call, and all of a sudden, there is a flood of "Oppose, per the problem cited by [name]." A lot of good editors know perfectly well, that if they became candidates, this would happen to them, and decide that it wouldn't be worth the trouble. That, not any of the other things, is the real reason good candidates decide not to have an RfA. And none of the proposals being discussed would fix that problem. You cannot sanction an editor for opposing, with a diff or two that indicates what that editor thinks, in all sincerity, is a problem. And you cannot sanction other editors for agreeing with it. But that's the thing that makes RfA an unpleasant place. If editors really want to fix that, there's no easy fix, but the best way to start is to make a practice of thinking carefully before registering a pile-on oppose, and to explain support reasons clearly, including where appropriate, why an oppose does not demonstrate unsuitability. --Tryptofish (talk) 18:23, 15 February 2024 (UTC)[reply]
Having a two-phase approach with a discussion phase and an anonymous voting phase (such as the proposal made during the 2021 review of the RfA process) would help mitigate the morale-draining effect that opposing votes can have on candidates. The rationales would still get discussed, but they wouldn't get repeated by each person opposing (which currently can lead to multiple threads about the same concern). isaacl (talk) 18:39, 15 February 2024 (UTC)[reply]
Alternative proposal (RfA civility)
This is not a formal change in rules (and I do not see it as mutually exclusive with the above), but an encouragement for admins to use the tools available to them. Add something like this to WP:RFA (i.e. literally add it to the RfA page; wordsmithing more than welcome):
Uninvolved administrators and bureaucrats are encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks.
Support as proposer. If we are not ready for GS, I think we should have a formal acknowledgement (importantly, one placed there by community consensus) that editors should be respectful, and disagree without being disagreeable. I will also note that if an admin uses the tools to silence civil comments that would be egregious WP:TOOLMISUSE; I have much more confidence in our ability to deal with tool abuse than with civility RfA. (Note that this is intended to apply equally to all participants, including opposers as well as those who badger opposers.) HouseBlaster (talk · he/him) 02:19, 15 February 2024 (UTC)[reply]
Support. This strikes me as a good idea. While a lot of the stress of RfA is caused by things other than outright incivility, a simple encouragement is unlikely to hurt. Eluchil404 (talk) 02:46, 15 February 2024 (UTC)[reply]
Oppose I want to know (a) if someone has some dirt; and (b) how the candidate reacts to trolling. Re (a): obviously any aspersions would be closely examined and dealt with appropriately if unsubstantiated. We can't put a header on every noticeboard with this information. Johnuniq (talk) 03:04, 15 February 2024 (UTC)[reply]
I haven't been following the details of recent RfAs but I have looked and the trolling I've seen has been very minor. The current fuss is not trolling in the sense of something outrageous: it's one oppose that might be misguided but does not warrant all the discussion IMHO. Are there any links showing trolling that really should be removed but hasn't been? Johnuniq (talk) 06:12, 15 February 2024 (UTC)[reply]
Off the top of my head, since December we have one RfA where more than 50 revisions had to be suppressed because it took 48 hours for a wildly inappropriate comment to be removed and one neutral which literally cited the candidate's religion as a reason they would be uncomfortable if the candidate got the mop (see also Q6 and Q7 by the same editor).HouseBlaster (talk · he/him) 12:53, 15 February 2024 (UTC)[reply]
Oppose a lot of these concerns could be alleviated if someone would just p-block Lightburst from the RfA. We don't need to make community-wide statements in response to poor behavior from one editor (I realize there were two editors misbehaving at the current RfA, but the one !vote was already struck as a crat action, so evidently our current approach is not completely broken). LEPRICAVARK (talk) 07:05, 15 February 2024 (UTC)[reply]
Plenty of other editors have recently engaged in problematic conduct at RfA. It's a systemic issue and admins and 'crats are way too reluctant to enforce community norms at RfA in my opinion. I'm not optimistic that this notice will solve all of RfA's problems, but hopefully it'll serve as a reminder to everyone that personal attacks and aspersions are just as unacceptable there as they are everywhere else and should be met with appropriate warnings or sanctions. — Callitropsis🌲[talk·contribs]07:19, 15 February 2024 (UTC)[reply]
@Lepricavark: it is true that if you block the minority voters or those who defend them, you can get a 100% result. In my experience, whoever dares to oppose the majority gets in trouble at RFA. The process is broken because it is public. Imagine going to the polls in the US, and they say who are you voting for? You tell them and they ask why? Now imagine having to declare your reasons to everyone in the polling center. And if they disagree with your reasons they strike your vote. If part of the Homeostasis07 rationale was an aspersion, strike it [[WP:RPA]]. But that is not what happened, first they poked at it, then they became outraged. Then they moved the entire rationale to the talk page. Then someone erased the vote entirely. I am just trying to stick up for the minority even though I voted with the majority. I guess FRAM struck my vote as well and that did not surprise me. Lightburst (talk) 14:45, 15 February 2024 (UTC)[reply]
If you are going to ping me, then please have the courtesy to write something that it is worth my time to read. No, the process is not broken because it is public. The process is broken because of editors, such as yourself in this and other instances, who provoke needless disruption and drama instead of evaluating the candidate in a policy-compliant manner. To address one of your red herrings, this is not about getting a 100% result. The first oppose was removed because, despite your seeming wishes to the contrary, RfA is not a safe haven for innuendos against the candidate. Your !vote should be struck because it is admittedly irrelevant to the candidate. If someone were to subsequently draft a relevant oppose that did not violate basic policies, it should and would be allowed to stand. LEPRICAVARK (talk) 17:10, 15 February 2024 (UTC)[reply]
In light of the community's failure to do anything about the latter two pointy opposes even though it was blindingly obvious that they were pointy, perhaps this is actually a good idea. Therefore, I change my position to support. LEPRICAVARK (talk) 00:45, 18 February 2024 (UTC)[reply]
Support :) I think that, one way or another, what admins and 'crats have lacked is a clear mandate. This seems like a good first step towards a more healthy community. (Maybe another good first step would be disabusing ourself of the notion that a little trolling is good for the soul. A world in which no troll ever enters Wikipedia again is not a world where everyone on it grows soft, there's a real world too and people learn how to deal with hardship.) theleekycauldron (talk • she/her) 07:19, 15 February 2024 (UTC)[reply]
Support as plain common sense. Those saying "but but but but trolling an RfA lets us show how a candidate reacts!" miss the point that it also discourages candidates from standing in the first place. Ritchie333(talk)(cont)11:27, 15 February 2024 (UTC)[reply]
Support as a reminder of our existing conventions and rules rather than extra bureaucracy. RfA is not a welcoming environment, and I'm sure it deters many potential candidates who would make good admins. Certes (talk) 11:44, 15 February 2024 (UTC)[reply]
Support - The fact that we have to even vote on this and that it's not unanimous really is quite telling of how differently RfA is viewed across Wikipedia. But we need more civility, please. Not less. Particularly at a venue such as RfA. Believe it or not, we'd still like to encourage people to become admins. Duly signed,⛵ WaltClipper-(talk)13:33, 15 February 2024 (UTC)[reply]
Moral support, but... I think we all know that we could already be doing this, admin or not. The problem with 'moderating' Wikipedia, compared to other places, is is that everything is out in the open and that everyone is on a level footing. Elsewhere, a mod sees a problematic comment and they remove it. Maybe the author can appeal, but it's going to be handled by other mods, and there certainly won't be a peanut gallery. If you remove a comment at RfA (or anywhere really), the author is very likely to publicly kick up a fuss, and that fuss is going to attract others to weigh in on both sides. There's a not-insigificant chance that, even if you're really sure that the comment was out of line, it's going to escalate to the point where you end up at ANI or ArbCom or wherever. I think admins are more aware of this than most, which is why you don't see us intervening unless the conduct is very obviously very bad. Encouragement or not. – Joe (talk) 14:05, 15 February 2024 (UTC)[reply]
Oppose I know we're all trying to make RfA better, and I'm not for personal attacks. I'm just worried this will make it harder to oppose candidates who need to be opposed, since the "casting aspersions" line seems like it could cause problems if someone opposes an RfA without presenting evidence, and as Joe Roe notes, who is the arbiter here? For instance is opposing someone on religious grounds a personal attack or aspersions, or does it just say a lot about the person opposing? I think a better idea might be for there to be explicit moderators for RfAs instead of putting up a notice of something we all aspire to, but is in a situation where it's difficult to enforce. SportingFlyerT·C14:29, 15 February 2024 (UTC)[reply]
I'm really not seeing the connection between putting this notice and make it harder to oppose candidates who need to be opposed. If someone says I had off-wiki encounters with the user that do not make me believe they should be an adminorSome off-wiki observations that I cannot show have made me lost my trust in this candidate they would not be casting aspersions. People would definitely be curious at what it is, but if you can't provide any proof or evidence for your claim, you can't really specify anything other than how it made you feel without making an unsubstantiated claim.
So my question is, if my understanding of what it means to cast aspersions is correct, in what way do we benefit from giving consideration to people making unsubstantiated claims where no evidence were sent to anyone? 0xDeadbeef→∞ (talk to me) 14:38, 15 February 2024 (UTC)[reply]
Doesn't your question confirm my concern, though? If I say something like "I've interacted with RfA candidate in the past and over the course of numerous encounters don't feel they have the capacity to be an administrator," is that a validly held opinion/oppose, is that an aspersion, is that an unsubstantiated claim that should be disregarded? I think it's the former, but don't want it to be confused with an aspersion. SportingFlyerT·C20:39, 15 February 2024 (UTC)[reply]
Support. This issue is not merely something that happened recently. Repeated violations of WP:NPA and WP:CIVIL in RFAs have been problematic for a while - off the top of my head, I can name at least three users who were specifically topic banned from RFA in the last several years due to civility issues. If someone has a legitimate reason to oppose an RFA, there is no reason why it cannot be done civilly. Epicgenius (talk) 15:04, 15 February 2024 (UTC)[reply]
Oppose. As I mentioned in my oppose comment in the now-withdrawn proposal, I got a lot of heat for a comment I made in a fairly recent RfA. I put myself at neutral, and based it on something that I said I did not feel comfortable posting in public. I also said that I did not think my reasons were solid enough for me to oppose, which is why I chose to be neutral. The problem I have with this new proposal is that it seems to say that, without evidence, what I did would have been block-worthy. --Tryptofish (talk) 18:06, 15 February 2024 (UTC)[reply]
Concern - I am concerned about how this will be applied when an editor leaves a good faith but bluntly worded comment at an RFA… situations where Incivility isn’t intended, but may perceived. Blueboar (talk) 18:24, 15 February 2024 (UTC)[reply]
It would be handled the same way we handle civility issues in the rest of the encyclopedia. That is, we WP:AGF and politely ask that the editor reword their statement. — HouseBlaster (talk · he/him) 19:51, 15 February 2024 (UTC)[reply]
There is no one single way that we handle civility issues in the rest of the encyclopedia. It varies wildly depending on the particulars of any given situation. LEPRICAVARK (talk) 23:31, 16 February 2024 (UTC)[reply]
Support I will continue to support any little steps that will improve RFA until we get an RFA that isn't broken. If there's sufficiently detailed bigger steps, I will happily support them too. The community both needs a reminder of our civility policies and stronger enforcement of them in RFAs. Soni (talk) 06:01, 16 February 2024 (UTC)[reply]
Support (and yes, I know). A reminder never hurt. Plenty to gain (editors like Homeostasis07 will in future know they will be blocked for trolling before in advance, and admins will be reminded that their normal tools can still be used alongside any specific crat actions that may also be taken, and crats will hopefully be encouraged to keep a gimlet eye on proceedings safe in the knowledge that they have codified backing), and nothing to lose, except some of the toxicity which is an inevitable by-product of treating RfA where NPA, ASPERSIONs, etc, does not run (as a worrying number of admins and even crats seem to believe). ——Serial19:55, 17 February 2024 (UTC)[reply]
Oppose As long as RFA comments are coupled with voting, I will have to oppose anything that could be used as a restriction on how people vote. Anyone should be able to vote how they want for any reason bar outright trolling. Now if voting and comments became uncoupled (see #Anonymous voting) and not everyone was forced to give a rationale, it would be a good idea. Pinguinn🐧19:56, 17 February 2024 (UTC)[reply]
Support RfA should at least have the same standards of user conduct as any other area of Wikipedia (not that our standards are that high). Maybe with an addition that explicitly states that votes that are aspersions/personal attacks can be struck/removed, since I think the often the issue is people being reluctant to enforce policies against oppose voters since they don't want to impugn people's "right to suffrage". Galobtter (talk) 06:52, 19 February 2024 (UTC)[reply]
Weak Support If there are admins and crats who feel as though they will be willing to enforce CIV and NPA, then this is a good idea. I'd consider it a pre-warning that editors should not make the type of comments they cannot make anywhere else on the project without sanction or summary removal. However if there aren't admins or crats willing to enforce those policies, then at best this is a fig-leaf sign that some can point to when telling others that their contributions are unacceptable per policy, and at worst this will just be some boilerplate text that editors ignore while violating the relevant conduct policies. Sideswipe9th (talk) 22:56, 19 February 2024 (UTC)[reply]
Strong oppose with apologies to HouseBlaster because I'd love to believe this would make a difference. One way it won't is regarding disruptive editors because as we've seen recently, they will never back down, not one inch, from their assertion that their behavior is completely fine, they only went on the attack with great reluctance because of something someone else did, or whatever.
If this has a positive effect, it'll be because it motivated editors who can actually enforce these policies to finally end their infuriatingly hands-off approach to disruption at RFA. And that won't happen, either. On the most recent request for adminship's talk page, two bureaucrats, User:Primefac and User:28bytes, said that they wouldn't remove two oppose votes that were blatant policy violations from the final account because the RFA was going to easily pass and besides, the community can rest assured that 'crats don't take such votes into account. That, to me, is incredible: two bureaucrats are on the record saying they flat-out won't enforce policy at RFA. (Everybody knows they didn't affect the vote! Everybody knows you wouldn't take them seriously! Toss them anyways!) No administrator or bureaucrat needs to be told that they're『encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks.』They know. The problem is that they still almost never enforce anything. (Change the word "encouraged" to "required" and I'd switch to strongest support possible.) CityofSilver00:01, 20 February 2024 (UTC)[reply]
I think the reason that admins and bureaucrats are reluctant to enforce the rules at RfA is the fact that it feels like election interference. The reason I think we need a note like this is to make it clear that the community does not see enforcing behavioral policies/guidelines as election interference. (In other words, I think that it will have a positive effect because it motivated editors who can actually enforce these policies to finally end their infuriatingly hands-off approach to disruption at RFA.)HouseBlaster (talk · he/him) 00:29, 20 February 2024 (UTC)[reply]
Yeah, the "election interference" angle is important here. And this becomes especially worse since most admins who see policy-violating behaviour have probably already voted in the RfA and so are involved. Galobtter (talk) 00:31, 20 February 2024 (UTC)[reply]
Discussion: alternative proposal (RfA civility)
Let's say an editor makes an oppose comment like this:
Oppose. I don't have any specific incidents in mind, but my interactions with the candidate leave me with the gut feeling that they will be too quick with the block button.
Supporters of the RfA candidate might believe sincerely that this is an aspersion made with the express statement that no specific evidence is going to be presented. It's possible to read the alternative proposal literally, as indicating that the community would authorize an administrator to sanction the editor who made the oppose. And yet it seems to me that this should be an allowable argument to make at an RfA. --Tryptofish (talk) 18:56, 15 February 2024 (UTC)[reply]
That's an absolutely reasonable thing to say at RfA. I almost never comment at RfA except when it's somebody I've known for a while because that's the only way to really get to know a person. If somebody who has interacted with the candidate over a period of time has a gut feeling one way or another, that's something I want to know. RoySmith(talk)20:05, 15 February 2024 (UTC)[reply]
Yes, indeed it is. The alternative proposal says, however, Editors may not make allegations of improper conduct without evidence. I suppose that one could wikilawyer that "they will be too quick with the block button" is speculation about future conduct instead of an allegation of improper conduct that has already happened. And one would hope that admins would be clueful enough to know that the oppose isn't really what this proposal is trying to prevent. But the practical reality is that this proposal would put a chill on such opposes, and could well lead to attempts to game the language to make a mountain out of a molehill. (If anyone doubts that, just consider how some opposes get badgered.) And if admins are clueful enough to know not to block the opposer in this example, then they are clueful enough to deal with real problems without the need for the proposed language. I think this alternative proposal would end up being a net negative. --Tryptofish (talk) 20:45, 15 February 2024 (UTC)[reply]
IMO what's actually wrong with RFA is the whole idea of it. There is no fixing it, because it's a stupid idea from the get-go. It's the same stupid idea as WP:RFC/U was. And for some reason that I don't understand, this community figured out that RFC/U was a stupid idea years ago and got rid of it, but maintains the same damn system for admin rights.
What's stupid about RFA and RFC/U, fundamentally, is the very idea that we should publicly evaluate one of us. Has anyone reading this ever, in any other aspect of their life, seen anything like this happen? Ever gone to a school where the entire faculty and student body gets together and talks about you? Or had a job where an all-staff meeting is called and the subject of discussion is the performance of an employee? The closest thing I can think of is an intervention (counseling), and even then, that's close family and friends, not hundreds of strangers. (And that's without getting into real world elections, which are done by secret ballot.)
Why do we do this? Because years ago WMF Legal said "community vetting" had to happen in order to give someone the viewdeleted permission. More recently, at one of the rounds of RFA reform discussion, WMF Legal backed off of that and said they'd consider alternatives. I think the community should tell WMF Legal tough cookies, we are not going to engage in public discussions of the job performance of editors, and WMF Legal is just going to have to figure out some other way. Because public performance reviews of editors are not healthy. It's way too easy, as we have seen time and time again, for such discussions to be derailed or to devolve into accusations, arguments, and so forth.
You can't control hundreds of people... the more participation, the more likelihood that someone, somehow, will cause a problem. That's why in the real world we don't have public performance reviews in which hundreds of people participate. It's foolish to even attempt such a thing, even moreso on a website with hundreds of strangers, where almost literally anyone can participate. Yet Wikipedia continues the tradition. It's time for everyone to stop pretending that public performance evaluations are a normal thing to do. It's unhealthy. End it. Levivich (talk) 21:09, 15 February 2024 (UTC)[reply]
All that WMF has ever said is that there should be some form of community process. It never specified what form that should take. A proposal to have an Arbcom style election had good support but failed only due to technical issues. Hawkeye7(discuss)21:25, 15 February 2024 (UTC)[reply]
The supports were close to double the number of opposes, so I'm not sure "failed" is the right term. There isn't a technology-based technical issue at the frequency level that was being discussed. The concern is WMF staffing to support the vote. isaacl (talk) 05:16, 16 February 2024 (UTC)[reply]
That RFC result was very unexpected. In my opinion, it should have been similar to the bot approval process: you get consensus first, then worry about technical details later in a separate step. That rfc should have been the consensus statement. It should have closed as "consensus to try some kind of RFA voting system, with technical details to be determined later". If someone were to rerun that rfc, with the correct closers, I'm pretty sure it would pass. –Novem Linguae (talk) 05:42, 16 February 2024 (UTC)[reply]
English Wikipedia has a history of being influenced by libertarian views that underlie its adherence to consensus decision-making for almost everything. But consensus doesn't scale up to larger groups; it stalemates action. And yes, on top of that, evaluating people in a large, public group meeting isn't done outside of very specific professions. On a sidenote, RFC/U didn't end because of a consensus view that it was a bad idea to have public evaluation of editors. It ended because the commenters couldn't impose any sanctions through that process, so they thought it was ineffective. WMF Legal is not to blame for this. Those who like to participate in discussions about decision-making are loathe to give up the outsized-influence a small number of people can have to block changes they disagree with. So the community has been unable to agree on following approaches used by other organizations to make decisions more effectively. I understand and appreciate the advantages of consensus decision-making and letting everyone weigh in, but they come with an inherent cost that can't be avoided by tinkering with rules of behaviour. The community will have to shift towards other options for at least some things, which can include voting on certain decisions, delegating primary responsibility for certain tasks to designated subsets of the community, adopting some community hierarchy for interpreting policy, or some other commonly used option in the real world. Alternatively, the community can shrink down drastically back to a level where consensus might be more effective, but that's probably only going to happen if the site is abandoned by most of the existing community (and likely overrun by promotional editing at that point). isaacl (talk) 22:56, 15 February 2024 (UTC)[reply]
@Levivich during WP:RFA2021, legal confirmed what Hawkeye says. There are any number of community processes which can work from their perspective. What wouldn't work is something like we do for ECR where we would give sysop to everyone with at least X years and Y edits or whatever. Best, Barkeep49 (talk) 23:00, 15 February 2024 (UTC)[reply]
Since the discussion has broadened to RfA in general, I'd like to make a general comment that does get back to the proposal here, as well. If I try to think of two things where the community keeps trying to come up with proposals for improvement, and the proposals never get consensus, the top two might very well be civility and RfA. Everyone (including me) agrees that we ought to do better with civility, and we ought to do better with the RfA process. And year after year, proposals are made, and fail. Alas, the proposals here have hit the jackpot, by trying to deal with both civility and RfA. (What could possibly go wrong?) I've also been editing here for long enough that I well remember when the widespread concern in the community related to RfA was how to have a sort-of reverse RfA, where the community could have a mechanism to de-sysop admins who were acting like jerks. Gradually, over time, ArbCom got to be good at dealing with that. So now, the pendulum has swung back the other way, with concerns over RfA being unable to get enough new applicants. As I've said earlier in this discussion, the solution to that problem won't be found in the proposals here. The community just needs to decide not to pile on when reasons for oppose at RfA are not part of a pattern. Editors don't decline to be candidates because someone at the RfA is going to be incivil. It's because real people, including those who would make excellent admins, don't want to get hassled over the one or two times they did something genuinely regrettable. --Tryptofish (talk) 23:31, 15 February 2024 (UTC)[reply]
Can we please not waste more words and time on these proposals? The community in its current state has shown itself that it wants RfA reform but cannot and will likely never agree with itself on how carry out that reform. If the community can't agree to come up with a system that is better than forcing people into public performances in front of hundreds of strangers, then so be it. What should be a cordial and basic exercise of governance can evolve into a poorly moderated jeering mass at a moment's notice. Not to mention the public nature of !votes means that people expressing their opinions are subject to badgering and drama. This discussion is particularly disappointing for me, a poor guy had his religion belittled amidst drama and attention from other editors he did not ask for. If we had an actual secret ballot both candidates and !voters would be spared of ridicule, but obviously nothing will be done because of technical infeasibility or people liking the current system more for their own personal reasons. Better to let them continue their talk of the lack of admins and just move on. Alright, that's enough words from a rando like me wasted on this topic. Time to step away from this and get back to cleaning up spam. The Night Watch(talk)03:34, 16 February 2024 (UTC)[reply]
I think there are structural reasons for the pile-ons too. Notionally opposes at RfA carry more weight because success requires a 2:1 ratio of supports to opposes. But the reality is the reverse, because unless an RfA fails immediately as WP:NOTNOW, there's usually at least 100 or so supports before the first substantial oppose vote is made. So opposers feel like they have to overcome the momentum of the candidate's friends and those who just vote support for every RfA (as they're perfectly entitled to), leading to lengthy and repetitive rationales, which provokes badgering, which leads to more verbiage and repetition, and so on.
The only ways I can think of addressing this involve making RfA either a secret ballot and/or having some sort of selections committee. As Levivich says, holding public elections-cum-performance-reviews is just a fundamentally odd thing to do. It produces all sorts of weird dynamics that can't be fixed by exhorting people to just be nice or not pile on or whatever, because individually they're already trying to. – Joe (talk) 08:53, 16 February 2024 (UTC)[reply]
Alternatively, an RfA could start with some period of discussion before voting begins (and this could be combined with one of your other methods, as indeed was proposed in the elections one that almost passed in 2021). Barkeep49 (talk) 17:56, 16 February 2024 (UTC)[reply]
Yeah, I still think an open discussion period followed by a closed ballot is the best model all-round, and still think the 2021 discussion showed a solid consensus to at least try that... – Joe (talk) 21:41, 16 February 2024 (UTC)[reply]
The "community vetting" thing is an extremely low bar, and I think it only precludes things like automatic promotion based on edit count. I am mystified why this WMF comment has been used so successfully to argue for the broken and harmful status quo. —Kusma (talk) 09:25, 16 February 2024 (UTC)[reply]
Yes, exactly. As I noted above (but which might have gotten lost in subsequent discussion) in 2021 WMF Legal commented (in part) The key point, per our previous commentary on the issue is to ensure that the process is one that can make sure that the selected candidates are overall trustworthy and responsible.. Best, Barkeep49 (talk) 19:09, 16 February 2024 (UTC)[reply]
Perhaps it has been used, but offhand Levivich's comment above is the only one I can recall right now, so I don't agree that this concern has been used successfully to support the current RfA process. My recollection is that commenters understood the rationale from WMF Legal, as both Barkeep49 and Hawkeye have expressed, that in order to meet the responsibility of removing legally prohibited content, the privilege of viewing deleted content can't be handed out automatically through criteria that any editor can achieve. Other selection processes still meet the need of choosing "trustworthy and responsible" candidates. isaacl (talk) 19:44, 16 February 2024 (UTC)[reply]
Not really an offhand comment :-) WP:RFA2021 is what I was referring to when I wrote "at one of the rounds of RFA reform discussion, WMF Legal backed off of that." One can read the Brainstorming, Phase 1, and Phase 2 pages to see the discussion surrounding WMF Legal (CTRL+F for "legal," for Phase 2 you have to uncollapse all collapsed boxes), and in Brainstorming is the discussion about BK reaching out to WMF Legal which results in WMF Legal "backing off" as it were, saying they'd be open to RFA alternatives.
FWIW, there are good reasons not to have any kind auto-admin system (automatically given to all editors upon meeting some threshold like 2 yrs/20k edits), but WMF Legal's objections aren't among them. As I said in my post above, I think the community should devise whatever system works best for the community (discussion, secret vote, even auto-admin if that's what the community wants); any objections by WMF Legal, or technical challenges e.g. SecurePoll limitations, can be overcome. We shouldn't treat (as we have in the past) either an objection from WMF Legal or asserted technical limitations as if they created insurmountable obstacles. The obstacles are very surmountable. We should do what works best -- the technology and the lawyers will conform to the needs of the people creating the content, we don't have to do it the other way around. Levivich (talk) 20:35, 16 February 2024 (UTC)[reply]
By offhand, I meant off the top of my head, I can't recall anyone successfully making the same argument you made. I've been following the discussions about this from long before the 2021 review; there hasn't been a consensus view that WMF Legal only supported keeping the RfA process as it existed at the time it issued its original opinion. But history doesn't matter for moving forward. I agree there seems to be an available consensus for anonymous voting that can be established. isaacl (talk) 22:53, 16 February 2024 (UTC)[reply]
How to implement anonymous voting
As a practical matter, how would be implement anonymous voting? The available tool is meta:SecurePoll, but I think the community would find it rather onerous to use. It needs to be configured for each election, has some scheduling limitations, and requires WMF staff to get involved to set it up each time. RoySmith(talk)23:28, 16 February 2024 (UTC)[reply]
We'd be leaving the old RfA system intact, so i guess the baton would live on for those who choose to do public RfAs. More to the point... I don't think it matters too much. theleekycauldron (talk • she/her) 23:47, 16 February 2024 (UTC)[reply]
Traditions are made for the participants, rather than the other way around, so I'm sure the community will find a way to adapt. isaacl (talk) 23:49, 16 February 2024 (UTC)[reply]
I don't think voters would find it unduly onerous. Staffing resources is a constraint. There is a Phabricator ticket open to track the task of allowing it be administered by local admins, so in the longer term, if the community is able to assume responsibility for configuration, it can ramp up usage. Initially I imagine that elections would be a supplementary path for selecting administrators. The community would be able to learn from the experience and decide how to proceed. isaacl (talk) 23:48, 16 February 2024 (UTC)[reply]
My favorite question when considering new and untried things is, "What's the worst that could happen?" In this case, the worst that could happen is we run an election and it goes badly. But we've got that already. So I say let's go for it. RoySmith(talk)23:56, 16 February 2024 (UTC)[reply]
"Allow local wikis to set up elections" is phab:T301180. SecurePoll is also very secure. Perhaps overly secure. Steps like scrutineering (checkusering every voter) can probably be dropped from the RFA voting workflow. The entire workflow of SecurePoll should be documented somewhere by someone knowledgeable, and then examined to see if other optimizations can be made to it. For example, is encryption overkill for RFA, and would turning that off help speed things up? etc. We should also consider if we want to institute minimum voting requirements such as extended confirmed, to prevent mass IP or throwaway account edits that could swing the vote. –Novem Linguae (talk) 00:01, 17 February 2024 (UTC)[reply]
As I discussed previously on the Requests for adminship discussion page, votes are encrypted so no one with access to the underlying database (either directly or I suppose via a MediaWiki vulnerability) will be able to determine how people voted. Running an unencrypted election removes a bottleneck in administering the encryption, and would speed up the tallying process. I don't think the tallying process part is a big problem in the overall picture; scrutineering is the most significant delay. isaacl (talk) 00:23, 17 February 2024 (UTC)[reply]
It is still quite an ordeal to run Secure Poll, but would be feasible if we wanted to do quarterly elections - perhaps in addition to having the existing RFA process for on-demand; candidates could choose which they prefer. The "big deal" would be that it is a vote. Something to decide would need to be if there is also an on-wiki "discussion" to go along with the vote or not. If no discussion is allowed, we could also have an on-wiki pure vote, and make a rule that the only contributions allowed are "support" or "oppose", without commentary. — xaosfluxTalk10:23, 17 February 2024 (UTC)[reply]
I imagine there would still be discussion somewhere. Perhaps a week of q&a and discussion, and then a week of secret voting. Similar to how ACE is divided into the q&a phase and the voting phase. –Novem Linguae (talk) 11:47, 17 February 2024 (UTC)[reply]
Anonymous voting
Wifione and a couple of other very problematic contributors have demonstrated that RfA needs to be in the open. With anonymous voting, no one would notice the waves of sock and meatpuppets that had been carefully prepared to control who gets to be an admin. Once the word gets around the paid-editing community, they will also set up a hundred dependable voter accounts. They would vote oppose for anyone with a record of opposing paid editing, and support for their candidates. Johnuniq (talk) 01:34, 17 February 2024 (UTC)[reply]
I think someone with your technical expertise should know about ACE and its rather robust scrutineering procedures. Also, everyone in the core community (and everyone who RfAs) virulently opposes paid editing, it's a cliché. Even if that conspiracy theory were 1. true and 2. technically viable, there's no pro-paid-editing faction to even boost. theleekycauldron (talk • she/her) 01:45, 17 February 2024 (UTC)[reply]
There is no pro-paid-editing faction now because everything is in the open and someone would notice dubious RfA votes. Three scrutineers under pressure to quickly check 2 or 3 hundred votes would find it very hard to investigate dubious voters. Scrutineers would more likely be bound by prescriptive rules that prevent an investigation based on a vague suspicion. We know that Wifione was successful in socking as Lourdes and becoming an admin (diff). We know that an RfA that looked like it was going to be successful was closed when someone decided the candidate was a sock of an LTA (I would have to remind myself where that was). Johnuniq (talk) 03:24, 17 February 2024 (UTC)[reply]
The current process, though, didn't stop either of these situations. If the community really wants to reduce the probability of this happening again, it's going to have to be willing to tradeoff some of its other views that it currently holds by consensus. isaacl (talk) 04:01, 17 February 2024 (UTC)[reply]
Those two cases involved talented individuals working alone. There has been compelling off-wiki evidence of two cases showing people organizing off-wiki to set up teams of editors to push their favorite POV in contentious topics. In addition, several similar cases of paid editing teams have been found. They get noticed because of the open nature of editing—someone sees unfamiliar user names arguing in a meat kind of way and uses Google to find a website where it is being arranged. It would be easy for these kind of groups to organize underground and create 100 hard-to-detect socks with 500/30 status. They could then sway an anonymous RfA. That doesn't matter for Arbcom because there are a very large number of voters and they elect a committee where it wouldn't be an enormous problem if there were one or two bad apples. Johnuniq (talk) 04:25, 17 February 2024 (UTC)[reply]
Any group willing to put in the long-term effort to build up a coterie of reputable editors is going to be able to influence the current RfA process as well. I'm not saying we shouldn't be concerned about the possibility. But any remedies to address that type of concerted effort are going to involve changing something from the current setup, and probably something creating some kind of hierarchy of trust. isaacl (talk) 04:37, 17 February 2024 (UTC)[reply]
You don't know if those two cases involved talented individuals working alone or groups of people working together. What those two cases prove is that the current system isn't good for vetting because it's easy to beat.
Also, admins are a bigger pool than arbcom (400+ active admins) so there is even less damage a single bad admin can do, which is another thing the Wifione case proved. What harm did he do with the Lourdes account? The Wiki is still here. Frankly, bad admins can and have done damage, but it's always fixable, and the current system has passed plenty of bad candidates (and failed good ones).
Above all, we don't know if another system would work better or worse than the current system because we've never tried any other system. Levivich (talk) 16:31, 17 February 2024 (UTC)[reply]
I do not think it is prudent to dismiss something purely on the basis of containing a hypothetical conspiracy, since thousands of conspiracy theories are verifiably correct. "What if incandescent lightbulb manufacturers colluded to make shitty bulbs that burnt out prematurely", or "what if Bolsheviks conspired to depose the Tsar", for example, are things which actually happened.
More pointedly, "what if right-wing dudes took over the Croatian Wikipedia" is also a thing which actually happened, so the idea that conspiracies are simply impossible due to Wikipedians being too smart seems untrue. jp×g🗯️19:42, 17 February 2024 (UTC)[reply]
With most configurations of the current Secure Poll setup, the "votes" are anonymous, but the "voters" are not. For example here is a list of everyone that voted in ACE last year, and if their vote was accepted. No one knows how they voted, but anyone can know if they voted. So traditional on-wiki methods can be used to investigate participants in secure polls. — xaosfluxTalk10:17, 17 February 2024 (UTC)[reply]
Does this need to be anonymous, though? Would it be possible to set up a system exactly the same as the one we have now, but instead of !voting by posting in the article, you !vote by filling out a little form which gets revealed at the end of the RfA process, and the transcript of which gets sent to crat chat if it's close to the 66-70% threshold? The problem here is that we still need to discuss the RfA as a community, so there really may not be an easy fix. SportingFlyerT·C10:38, 17 February 2024 (UTC)[reply]
This is generally where I am at. I think there is great value in RfA !voters engaging in the discussion (whether reviewing the community questions or reviewing any general discussion) before casting a !vote (whether through a poll or in the current setup). Unlike others editors here, I think in a Secure Poll setup, there will be more "promote" votes because many editors won't notice any concerns that may exist. - Enos733 (talk) 17:46, 17 February 2024 (UTC)[reply]
I think the community being able to assist in the scrutineering of votes in such a way would be positive. It might be a bit weird compared to know if we had a week of discussion followed by a week of votes and then untimed scrutineering, but it seems like a better alternative to now where you'll get a flood of 50-odd support votes before any concerns are even brought up followed by (usually) a shitshow for the 6 remaining days and a sudden closure. — ♠Ixtal( T / C ) ⁂ Non nobis solum. ♠ 17:51, 17 February 2024 (UTC)[reply]
As the arbitration committee elections demonstrate, discussion of the candidates can still occur while using an anonymous vote. Part of the confrontational nature of the current RfA process is that each person weighing in is potentially starting a new discussion thread. In addition to the candidate getting to witness the same debates play out repeatedly, those commenting have to consider their desire to participate in selecting an administrator versus their appetite for engaging in possibly a prolonged debate. I appreciate why some consider this to be a feature, but it also discourages certain personality types from wanting to participate, and I think the RfA process can benefit from getting input from those editors as well. isaacl (talk) 18:27, 17 February 2024 (UTC)[reply]
I think it's perfectly possible to have our cake and eat it too per others in this thread. We can have a discussion section about the candidate where people can bring up potential concerns with a candidate combined with anonymous voting. If someone has a reason to vote one way or the other that they want to share with the community to convince others, they can put it in the discussion section. Otherwise everyone else would simply vote. Pinguinn🐧19:47, 17 February 2024 (UTC)[reply]
I think the issue is that it is not anyone's business what a person's reason is for voting a certain way. It is none of the crat's business either. When we vote for ARBs we do not need to pontificate or satisfy someone else by providing a "valid" reason. If someone wants an issue or an experience that they had with a candidate to be known they can choose to share it on a talk page. This way everyone votes their conscience and nobody holds grudges over a vote. Primefachas said RFA is a consensus building, but that is not what it is, it is a vote. 75% is an automatic pass so where is the consensus in that? See this discussion where multiple editors said it is a straight vote. The cliff notes: In that discussion, HJ Mitchell said it was a straight vote, Vanamonde93, RickinBaltimore and Serial Number 54129 agreed. Lightburst (talk) 22:43, 17 February 2024 (UTC)[reply]
The views of four editors can't be extrapolated to represent the views of the community at large. Many editors have more nuanced opinions on the matter. isaacl (talk) 23:13, 17 February 2024 (UTC)[reply]
Here is the broader context of HJ Mitchell's comment: If your vote (and it is a vote, RfA is about numbers, not discussion or consensus) is not based on the candidate's suitability for adminship, it absolutely should be struck. Given that you recently placed yourself at the center of controversy by casting a !vote that would be struck per HJ Mitchell's reasoning, it seems duplicitous for you to cite him as being in agreement with your position. I have taken the liberty of pinging him here since I'm sure you wouldn't want to misrepresent his position. LEPRICAVARK (talk) 00:41, 18 February 2024 (UTC)[reply]
I am very concerned by your hostility toward me and I have left you a message on your talk page. I hope we can each discuss governance without sniping and parsing. The gist of the statement involved whether RFA is a vote or consensus. There seems to be this belief that we all have to agree on everything, including RFA candidates. And that leads to vote striking and other nonsense in an RFA. I want to ask you to please avoid following me as you did to Lilian's page, and avoid calling me out as you did here, and on other pages yesterday, and below. It is troubling and it feels like harassment. Thanks. Lightburst (talk) 02:55, 18 February 2024 (UTC)[reply]
I like to call things what they are instead of what we think they should be (very un-Wikipedian of me!) so yes, it's clearly a vote. But I've always said that I'd prefer it to be a discussion of a candidate's suitability for adminship, like a (good) job interview and less like a popularity contest. I don't know if the outcomes would be different but I think it would make the experience more pleasant for all involved, which might attract a different kind of candidate and/or a different kind of voter. HJ Mitchell | Penny for your thoughts?06:20, 18 February 2024 (UTC)[reply]
Consensus usually refers to general agreement among the members of a group or community. The community is in general agreement that any user receiving above 75% of the !votes at an RFA will be granted adminship, and any with 65-75% would be sent to a 'crat chat to find a general agreement amongst 'crats whether there was general agreement amongst the RFA participants whether the user should be an administrator. We do not need to go to a 'crat chat when a supermajority of participants finds general agreement to promote. So yes, it is a consensus-building exercise (see also the 2019 reaffirmation of this), and we use the votes to help determine that consensus. (please ping on reply) Primefac (talk) 08:56, 18 February 2024 (UTC)[reply]
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Following the passage of this RfC, for 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW (or for six months, whichever happens first), RfAs will last 10 days. For the first 3 days (72 hours) no "Support", "Oppose", or "Neutral" comments/!votes may be made. Optional questions may still be asked and answered, and general comments may still be left. After 3 days, "Support", "Oppose", and "Neutral" !votes may be left for the remaining 7 days (same length as an RfA is now). This RfC does not change other RfA procedures/rules. 17:49, 17 February 2024 (UTC)
Support (Discussion-first RfA trial)
This doesn't fix RfA. But I think it has the potential to take some of the temperature of it down since people will be able to express concerns and respond to those concerns without the immediate stakes of having that discussion impact the support percentage. It might also allow for easier clerking because comments which cross the line may not be attached to a vote. The trial would also serve as a data point to understand how other proposed RfA reforms (such as anonymized voting with seperate discussion being discussed above) might work in reality. I suspect that this change might make increase the number of opposes because people who check an RfA once may not return to !vote or may !vote after seeing concerns and thus oppose or abstain from !voting where they might have supported before. But I do not think that will necessarily mean fewer people will pass RfA. It's just that support %s will return to historical norms, with fewer ending in the very high 90s. Importantly for me, I think it has the potential to make RfA less unpleasant for candidates. So I think this is worth trying. Barkeep49 (talk) 17:49, 17 February 2024 (UTC)[reply]
AsI've previously discussed, I think a two-phase approach would help improve the effectiveness of discussion and provide the opportunity for additional information being available to those offering their support or opposition when the second phase begins. isaacl (talk) 18:01, 17 February 2024 (UTC)[reply]
I like this as a first step to a secret ballot. Many of the concerns about a secret ballot are that voters would not be aware of past indiscretions without doing a significant amount of research, but if this process works to raise and vet concerns about the candidate first, it would open the door up to reconsidering a closed voting process. --Ahecht (TALK PAGE) 20:14, 17 February 2024 (UTC)[reply]
This seems to be a good trial. I would suggest that the trial last until 5 RfAs occur (without the time period), just to make sure we get a few RfAs to evaluate. --Enos733 (talk) 20:17, 17 February 2024 (UTC)[reply]
While I'm against ever turning RfA into a secret ballot, I think this is worth a trial run as a way of avoiding the premature pile-on supports that so often occur prior to proper vetting. I do, however, wonder if this will dissuade candidates from running during the trial period for fear that they will end up linked to an experiment gone wrong. Also, will there be any measures taken to prevent participants from declaring their intent to !vote one way or another during the discussion phase? LEPRICAVARK (talk) 20:34, 17 February 2024 (UTC)[reply]
I rather like this idea. If nothing else, it would allow people to express their thoughts, and receive feedback on those, before actually staking them to a position on supporting or opposing. It's always easier to change one's mind prior to publicly taking a stance than after having done so. But absolutely never would I support any "secret ballot", and I am certainly not supporting this as a way toward that. This should be a supplement to, not a replacement for, discussion during the actual "voting" phase. SeraphimbladeTalk to me20:46, 17 February 2024 (UTC)[reply]
I think this is a very good idea, so don't mind my concerns too much. I'm concerned 10 days is a lot. I'm concerned people will comment and then forget to vote. And I'm concerned this will be a tool to increase self-nominations, since you won't immediately get jumped on with a bunch of opposes. The first concerns will be interesting to see if we approve this. The final concern is more pressing, I think we should exclude self-nominations from the trial process. But we should absolutely try this. SportingFlyerT·C21:07, 17 February 2024 (UTC)[reply]
With the addendum that candidates be allowed to opt-out of this and in to the normal system. I would slightly prefer if votes were left on a seperate page entirely and not allowed to have attached rationales, but this is an excellent first step Mach61 (talk) 21:29, 17 February 2024 (UTC)[reply]
Yes, I support anything that gets us closer to a "secret ballot. As I said in discussion it is not anyone's business who another editor voted for. This is the way editors can be free to vote their conscience. But this is a step in the right direction by removing the badgering on the voting page. Lightburst (talk) 22:46, 17 February 2024 (UTC)[reply]
This'll be great because otherwise someone might support, but then a new piece of information comes up where they might oppose then, but may not strike their support. Or vice versa. Let's at least give this a try. Relativity 01:36, 18 February 2024 (UTC)[reply]
I would also support a 2+5 – lengthening RfA isn't my favorite tack, but again, let's try something. I'm glad we're getting proposals off the ground :) theleekycauldron (talk • she/her) 18:24, 18 February 2024 (UTC)[reply]
I think this discussion-first proposal is worth trying, though I have concerns: 1) Extending the length of time someone is under scrutiny could increase the tension for the candidate - especially as they have to wait until after people start examining/criticising them before the voting begins; 2) It is possible that the same incivility will occur when people raise concerns, and others directly challenge those concerns, and heated discussions result, as this proposal doesn't address those issues, just delays the voting period; 3) This may increase the number of questions a candidate will have to answer both in terms of the extended time, and the lack of information being put forward by voters (so people may seek out that extra information by asking questions of the candidate), which may put off future candidates. However, my concerns may not materialise, so it's worth trying. My main thoughts, meanwhile, on toxicity in RfA is that it is caused by threaded discussions - people engaging in direct responses, sometimes emotionally, heated, and personal, which then escalate. I think it would be worth trialling an RfA in which people only comment in their own sections, as in ArbCom discussions. I won't formally suggest that now, as I feel that would take attention away from this proposal. I'll suggest it after this proposal has been trialled (as I hope and expect it will be). Thanks Barkeep49 for suggesting it. SilkTork (talk) 02:56, 18 February 2024 (UTC)[reply]
That would be the idea, as that is where the toxicity occurs. Folks tend not to get so heated over comments as much as they do over votes, especially (almost exclusively) negative votes. I've seen people complain when someone raises a justifiable objection in an otherwise 100% support RfA as though that single negative vote somehow soils the RfA; or perhaps they may be concerned that the negative comment will have traction, and turn the course away from their favoured candidate. The nature of Wikipedia is that we invest a bit of ourselves into the project, this aids motivation, work ethic, pride in the job, etc, but can drive us to be too obsessive and to be lead by our emotions rather than our intelligence and judgement. SilkTork (talk) 11:00, 18 February 2024 (UTC)[reply]
Frankly, I don't think this will accomplish much. Supporting in the hope that I'm just a little jaded when it comes to RfA, and in support of experimentation with fraught processes in general. — Rhododendritestalk \\ 04:58, 18 February 2024 (UTC)[reply]
Weak support. Making the period longer is a strong disadvantage for me, and I had hoped for a 3 days discussion and 5 days !voting proposal. That said, the current situation is untenable and this is a move towards a less cruel system where votes are blinded and discussion is an actual discussion rather than a vote. —Femke 🐦 (talk) 07:39, 18 February 2024 (UTC)[reply]
Support as a trial: almost anything is worth trying. Hopefully we have five knowing volunteers who are happy to test this out (or at least no less happy than they would be to try the current RfA system). Back when I thought it was possible I would ever run at RfA, I considered announcing it 2 days in advance and soliciting discussion and feedback so that constructive criticism wouldn't be so high-stakes or so argumentative as in a "vote". I don't like extending the total length of time, however: it should be 3 days of discussion and 3 days of !votes. — Bilorv (talk) 08:47, 18 February 2024 (UTC)[reply]
Definitely worth a shot, although I share @Usedtobecool's reservations below regarding both the increased length as well as the uncertainty for the candidate who is answering questions for three days without getting to see any confirmed support. Regardless, hard to know until we've seen it in effect—and better to try something different than to leave it alone when all agree it's currently in need of help. Retswerb (talk) 09:00, 18 February 2024 (UTC)[reply]
I think this needs to come with a prohibition of comments in the voting section, but it goes in a good direction. Femke is right about the length though. —Kusma (talk) 09:20, 18 February 2024 (UTC)[reply]
I am not yet convinced that this will make a meaningful difference, but I am fully in support of trying things out to see if they actually do. There is essentially no downside to testing this. firefly ( t · c ) 11:10, 18 February 2024 (UTC)[reply]
Per Firefly. No reservation re. length of time, as the period of most stress will be reduced from seven to three days. Just to call it a '10-day period' is too round; RfA is likely most broken now because everything is bundled together. ——Serial13:49, 18 February 2024 (UTC)[reply]
We will never see if it works unless we try. I think that ideally, we should restrict the first three days to Q&A only, without discussion that may influence future votes (particularly since the candidate will be tempted or even obliged to reply to that discussion), but let good not become the enemy of perfection. We can also try the ARBCOM-style threaded discussions, where only the user and the candidate may speak to each other, but let's see first if this trial succeeds. Szmenderowiecki (talk) 15:14, 18 February 2024 (UTC)[reply]
I support this in principal. TEN consecutive days sounds like an ordeal. A couple days of Q&A followed by a break. Candidate should have the option to have a break in between Q&A and voting. Schierbecker (talk) 20:27, 18 February 2024 (UTC)[reply]
Weak support. Mach61 (currently support vote #15) made a very good point that this should not be mandatory for the next five nominees and I'm disappointed that doesn't seem to have gotten traction. I also echo the concern expressed by Femke (currently support vote #25) and others that jeez, ten days is an awfully long time. CityofSilver20:32, 18 February 2024 (UTC)[reply]
I don't love that it's mandatory, but I would less enjoy the perception that not waiving the discussion period is a sign of weakness. We need a mix of strong and weak candidates to test this, and allowing a self-selection bias throws off the results. theleekycauldron (talk • she/her) 23:15, 18 February 2024 (UTC)[reply]
If I were ready to run for adminship but I didn't want to participate in this experiment, I'd opt out by, well, not running until the experimental period is over. Passively opting out like that would have no avoidable consequences for me. Either the experiment fails and I'd get my way or it passes and I'd be exactly where I would have been had I, against my will, been one of its five subjects. It's the community that would suffer here because we'd be missing out on up to six months of administrative contributions from someone who's good enough to get promoted.
So no matter what, there will be an opt-out and the candidates who participate will have self-selected. I know I'm on kind of a weird side of AGF when I go on and on about an adminship-worthy candidate getting sneaky like this. I'm just pretty sure that someone who would opt out if they officially could be awfully motivated to passively opt out if they officially couldn't. CityofSilver21:27, 19 February 2024 (UTC)[reply]
Yes, this is exactly what will happen. Anyone who is hesitant will simply wait out the next five RFAs. Which may take a whole six months, if it makes enough people hesitant. -- asilvering (talk) 21:39, 19 February 2024 (UTC)[reply]
Support only with Mach61's proposal that any candidate should be allowed to opt out of the trial; if consensus does not develop for that condition, my !vote should be counted as an oppose per Novem Linguae and Yngvadottir. Schierbecker also makes a good point regarding allowing the candidate to take a break.voorts (talk/contributions) 20:40, 18 February 2024 (UTC)[reply]
I think it is worth trying. Like a few others I think 10 days may be too long. But I am not sure we can make it perfect right away so I am willing to support. Bruxton (talk) 03:09, 19 February 2024 (UTC)[reply]
Support I will continue to vote for all sufficiently logical RFA reform proposals. I wish this trial was longer, but 5 RFA should at least be a step forward, in case it's a net positive towards RFA's hostility. Having more days for RFA does feel like a negative, but not sufficiently enough for me to oppose. Soni (talk) 14:36, 19 February 2024 (UTC)[reply]
Support I'd like to see this AND anonymous voting. That would eliminate the oppose-vote-badgering as well. But I'll take this as a sensible first step in the right direction.→StaniStani01:25, 20 February 2024 (UTC)[reply]
Oppose (Discussion-first RfA trial)
IMO too complicated and won't do much good. RFA really wouldn't be that hard to 80% fix but IMO his isn't it. Sincerely, North8000 (talk) 20:34, 17 February 2024 (UTC)[reply]
@Novem Linguae: I agree that ten days is long, but I am hopeful that the actual vote may be less stressful. I think many of us would like to try a different way. (I hope this does not feel like badgering) :) Lightburst (talk) 03:01, 18 February 2024 (UTC)[reply]
Oppose basically per Novem Linguae. This would simply prolong the process for the candidate (and we already have participants being impatient with candidates who don't appear to have their RfA on speed dial for the entire 7 days). It would be difficult to address the merits of the candidacy without in effect casting a premature vote, so I expect the preliminary 3 days would be mostly questions, and there's already a tendency to ask quirky, sometimes repetitive questions; some RfAs in recent years have been a bit of a marathon of questions. I'd expect this change to exacerbate that, and also to front-load the voting once it opens with reactions to the candidate's responses; not only would this mean 3 more days of intensity for the candidate, but fielding questions isn't every candidate's strength, and it doesn't track perfectly with the kinds of communications skills we want from admins. Yngvadottir (talk) 11:27, 18 February 2024 (UTC)[reply]
Oppose. I'm sorry to be here, and I appreciate the effort BK49 and others are putting in to try to improve the climate at RFA. But I worry this would have the opposite effect than intended on the candidate's experience. First off, there's the length issue that Novem Linguae points out above. 7 days of hell are quite long enough. Second, there's the issue of morale. By their very nature, negative concerns are...louder, for want of a better word. I suspect that people who have concerns about a candidate are far more likely to post in those first few days than people who don't. As things stand, a candidate who is coming under fire can still see the supports piling up: here they're going to have to endure 3 days of hard questions without the emotional cushion of the supports. Unless of course you allow people who trust the candidate despite concerns to say so, in which case we're back at a !vote. Third, there's the issue of voter commitment. Having seen the RFA banner go up on your watchlist, you as a semi-engaged !voter would need to remember to check back in in 3 days time to express your opinion, assuming you don't have one at the outset. I suspect a fair number of editors are not going to be able or willing to do this. Finally, and taking a step back for a moment; even I've not been here long enough to remember RFC/U, but I did look up why it failed, and I believe a lot of the reasons it got to be an unproductive exercise will apply here as well: I think it does more to enable toxicity, not less (regardless of which "side" that toxicity is coming from). Vanamonde93 (talk) 23:04, 18 February 2024 (UTC)[reply]
In terms of the RfA banner, I think that problem is partially solvable by changing the text after the initial discussion period. Starting with something like "questions are now open" to the normal watchlist notice later. My hope is that we can recreate the calmer environment of the Arbcom elections in this initial period; perhaps a follow-up proposal can mirror this process even further. —Femke 🐦 (talk) 08:27, 19 February 2024 (UTC)[reply]
Oppose While I can see how RFA needs to be 7 days, I'm aware that a 7 day process is intimidating, and not something everyone can readily make time for. However most of the !voting is in the first three days, many RFAs are relatively quiet after the first 72 hours. A two stage RFA with an extra three days at the beginning makes one of the problems of RFA worse, as it is likely that the intense bit would also be extended as both the extra three days and the first three days of voting will be high pressure for the candidate. There's also the problem that RFA is already too focussed on the Q&A section at the expense of actually vetting the candidates edits. My fear is that adding an extra three days for increased question activity will exacerbate this problem and make RFA less attractive to potential candidates, as well as less effective at weeding out candidates who would make bad admins ϢereSpielChequers01:05, 19 February 2024 (UTC)[reply]
OCRP is a meta-discussion about the candidates’ chances, it has nothing to do with what the participants personally want in an admin Mach61 (talk) 04:38, 19 February 2024 (UTC)[reply]
Speaking as someone who would like to be an Admin to do more on WP:RM, and has already done OCRP, I honestly find the prospect of a ten-day process, the first three days of which won't have any !voting so you're essentially just twisting in the wind waiting for something to go bad, even more daunting than that of the present 7-day process. FOARP (talk) 13:02, 19 February 2024 (UTC)[reply]
Oppose per Vanamonde - as someone who had a controversial RfA, I think it would've been worse if the first 3 days had just been people discussing - i.e. most likely expressing concerns. The "emotional cushion" - as Vanamonde put it well - of knowing that 80+% of people did support me, was definitely nice and gave me confidence through my RfA. Also yeah, questions were definitely the most stressful part of RfA for me, and more time for those would not help imo. Galobtter (talk) 06:22, 19 February 2024 (UTC)[reply]
Oppose There seem to be too many procedural problems. Trying to forbid !votes is impractical and impossible as there will be plenty such regardless in places like Wikipediocracy, Discord and elsewhere. And compressing the Q&A into a 3-day period will put more pressure on the candidate to be responsive during that time which might be difficult to schedule. And there will tend to be more questions because that's the main way for enthusiasts to participate initially. And they will tend to be loaded questions. And then, when the floodgates open for actual voting, there will be a big rush to get the groupthink bandwagon rolling. And so on. No – what RfA needs is a secret ballot like Arbcom. That seems to work well without so much intense drama, which is what's wanted. Andrew🐉(talk) 16:51, 19 February 2024 (UTC)[reply]
I think you're misunderstanding.
You can't vote for an RfA in Wikipediocarcy. Discussions can still contain opinions about the candidate.
The Q&A and discussion are allowed for the entire period, not just the first 3 days.
Weak oppose. I've held off on !voting, because I'm very reluctant to oppose just having a trial of something, to see if it works. And my oppose is a mild one, for that reason. But the comments of Vanamonde93, WereSpielChequers, and FOARP have persuaded me to oppose. In particular, WSC's point about extending the most stressful part while leaving decision-making for a stage where interest sometimes wanes, pushes me to here. --Tryptofish (talk) 19:52, 19 February 2024 (UTC)[reply]
Weak oppose. I initially started posting here since there isn't a formal "neutral" section. I thought I was leaning to support, but wouldn't want to do so unless a few suggestions already mentioned were formally added to the proposal: namely, I think 10 days is far too long, and I like Femke's solution to Vanamonde's issue #3. But in writing this out I've come around to think Vanamonde's issue #2 (echoed by FOARP) is the most important one. I don't see anyone in the Support section saying "I would run for RFA if it were like this", though Bilorv's comment comes closest. -- asilvering (talk) 21:12, 19 February 2024 (UTC)[reply]
Oppose Maybe this is a failure of imagination on my part, but I fail to see how making an already stressful process longer is going to help. Maybe if after the three days, contributors could only vote without making any form of substantive comment, I could see that being an improvement. But as written this just seems like it's going to prolong the misery put on candidates. Sideswipe9th (talk) 22:45, 19 February 2024 (UTC)[reply]
Like, this doesn't substantively change the environmental problems that are the cause of RfA toxicity towards the candidate. Editors will still be able to violate WP:CIV and WP:NPA because no-one is willing or able to moderate those violations when they occur. All this is doing is giving three extra days for that same type of vitriolic comment to be made. Sideswipe9th (talk) 22:50, 19 February 2024 (UTC)[reply]
It goes back to 7 days with immediate !voting. If the community wants it to continue a new RfC would need to establish that consensus. Best, Barkeep49 (talk) 18:30, 17 February 2024 (UTC)[reply]
Two differences in that 2008 RfA is that the discussion phase was closed when the voting phase started, and unlike today's process, there was no limit on how many questions each person can ask. isaacl (talk) 19:09, 17 February 2024 (UTC)[reply]
Probably yes, but that could lead to an unintended consequence of opposes being cast by voters who are angry at the candidate for not playing along with the experiment. LEPRICAVARK (talk) 22:09, 17 February 2024 (UTC)[reply]
In my opinion, we need to let candidates opt out, or, alternatively, change the proposal from the first five, to the first five who opt in. It also seems to me that we simply don't know how this will affect the percentages for success or failure, and that could leave bureaucrats unsure how to determine consensus. --Tryptofish (talk) 22:50, 17 February 2024 (UTC)[reply]
I'm also noticing that some editors are supporting the proposal, saying that they like the way it is a secret ballot, but the proposal as written is not that. --Tryptofish (talk) 22:52, 17 February 2024 (UTC)[reply]
Searching on the word "secret", I'm not seeing any supports saying they like how the proposal is a secret ballot. At the moment, two supports say they think it is a good step towards having a secret ballot in future, and two say they support the proposal even though they do not support a secret ballot. isaacl (talk) 23:16, 17 February 2024 (UTC)[reply]
Lightburst also seems to believe that this proposal would remove the so-called badgering of opposes, but I see nothing in the proposal to support that perception. LEPRICAVARK (talk) 00:32, 18 February 2024 (UTC)[reply]
I said removing the badgering on the voting page. So it will stop the badgering on the project page. I still do not like having to publicly declare, "Are you now or have you ever been..." I would like to just vote and move on to building the encyclopedia. When I vote here in my town it is drama free because I do not have to tell the whole town who I voted for and then pass their litmus test. Lightburst (talk) 01:39, 18 February 2024 (UTC)[reply]
I have real concerns about secret ballot/anonymous voting myself even as I feel it's the option likely to do be the largest change for positive in appointing adminship that has a reasonable level of community support right now. I think it will push the support %s down considerably - as we saw with the move from public to secret balloting for ArbCom - and I think @Johnuniq's concerns about opening us up to UPE has some validity. So I'm not sure we should adopt it despite its potential benefits. But I think the discussion first system could have merit on its own as an improvement at RfA and think it could be paired with some other mooted changes to RfA - including secret ballot - in ways that would complement each other. Best, Barkeep49 (talk) 23:33, 17 February 2024 (UTC)[reply]
Keeping our current process is more likely to result in UPEs becoming admins than moving to a secret ballot. Our current process does not filter out all bad eggs (Eostrix, Wifione) and has horrible effects on the mental health of true volunteers, so hundreds of qualified editors refuse to run. Perhaps some people would find that acceptable if the process kept out bad eggs, but it demonstrably does not. So "but UPE" does not appear to be an argument against changing things, rather the opposite. —Kusma (talk) 10:25, 18 February 2024 (UTC)[reply]
@Asilvering just look at someone like NewYorkBrad. When voting was public here he is getting 97+% support. Where as in 2019 when he ran again he was by far the most popular candidate but got "only" a hair under 80% support. This is also reflected by the drop-off in % support the first year they did secret ballot voting but I'll leave the finding of that to someone else. Barkeep49 (talk) 01:14, 20 February 2024 (UTC)[reply]
Find it hard to imagine how this would benefit the candidates. Seems like 10 days of stress instead of 7, especially while it's not yet clear what the Bureaucrats can or are willing to do. Was 2+5 considered? Is there something about the necessity to cast votes for 7 days? I think the real guns won't come out at RFA until the real numbers start to come in, which would be the voting period. The first few days may end up like ORCP. Or they maybe as bad as the typical days of current RFAs but without the comfort of a support percentage, making candidates who would have passed withdraw even before voting begins. Usedtobecool☎️02:27, 18 February 2024 (UTC)[reply]
In past discussions, some participants have expressed a desire to allow for editors who edit once a week to have their views considered towards the consensus outcome. This would require a 7-day minimum period where they can weigh in with their supporting or opposing opinion. isaacl (talk) 05:44, 18 February 2024 (UTC)[reply]
I disagree with this argument as it views RfA as a Big Deal. The concept of everyone in the community being entitled and accommodated to vote frames it like a presidential election rather than a discussion to establish consensus. Discussions with much wider-ranging community impact on AN and ANI often last a couple of days only: editors often don't know about the discussion until after the fact, but it's still served its purpose of ascertaining consensus through a sample. — Bilorv (talk) 08:40, 18 February 2024 (UTC)[reply]
I would agree with Bilorv. Furthermore, by engaging in the pre-!voting discussion, you also participate in the process, so people that edit less are included in the RfA by design. —Femke 🐦 (talk) 08:45, 18 February 2024 (UTC)[reply]
Given how dynamic RfA is (not all votes are equal, providing a single diff that makes the candidate look bad has great effect within the first couple of days, not so much in the final hour), this is meaningless in practice. Also, the candidates' mental health is perhaps a bigger issue than the views of a few weekend only contributors. —Kusma (talk) 10:30, 18 February 2024 (UTC)[reply]
Yeah I agree, to have a real impact on an RfA outcome diffs have to be dig up within the first few days. I'd be more supportive of a 2 + 5 proposal. Galobtter (talk) 06:28, 19 February 2024 (UTC)[reply]
Barkeep49, given the above, do you think it would be possible to add a 2+5 proposal as an alternative and see if it receives a more enthusiastic support? I do strongly believe that changes that make the RFAs longer have a lesser chance of being successful. — Usedtobecool☎️13:03, 19 February 2024 (UTC)[reply]
Ultimately I don't control this RfC, of course, it's the community. That said I am not without thoughts about what 3 extra days could mean, but that for me is why doing this as a trial is important. It would not surprise me if an outcome of the trial is "discussion period first is good, but 10 days is too long" and so it gets permanently adopted as a 2+5. But in the spirit of an experiment I thought changing one variable (discussion period) rather than two (discussion period + !voting length) would yield more informative information. Best, Barkeep49 (talk) 01:08, 20 February 2024 (UTC)[reply]
The one time I've seen a discussion-first RFC on a contentious topic (the 2018 Daily Mail discussion) the whole thing devolved very quickly into round of "Oh my god HOW DARE YOU stop us from voting!"-style accusations. For better or worse, people come to a discussion with attitudes already formed, and things they want to say. This essentially limits the voting period to the last four days of the RFA or extends the RFA by 3 days, and will lead to people casting not-votes in the discussion as they don't have the time to come back to !vote. I see no sign that discussion would have avoided the FUBARs in recent RFAs - people put down their marker early either way. FOARP (talk) 12:49, 19 February 2024 (UTC)[reply]
No threaded-discussion RfA trial following the discussion-first RfA trial
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial of threaded-discussion RfA will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. A RfC to then be set up to see if elements of either or both trials should be made permanent. In the no threaded-discussion RfA trial, the rules and procedures are to be followed normally, except that, other than 'Crats, nobody is allowed to comment below another user's vote or comment. Each user, including the candidate, may address issues or respond to other comments either after their own vote comment, or by creating their own sub-section in the General comments area. SilkTork (talk) 11:33, 18 February 2024 (UTC)[reply]
Support (No threaded-discussion RfA trial)
I was going to wait until the above Discussion-first trial had concluded before suggesting this, but I think it would be more helpful to set it up now to see if there is traction for the idea, so that if there is traction, the trials can be set up to follow one another, and then we have a RfC to see what, if any, ideas can be taken forward. SilkTork (talk) 11:36, 18 February 2024 (UTC)[reply]
Support this as well, though I think it would be better for the two trials to run concurrently. The endless bludgeoning of opposes and neutrals has got to stop and this seems like the only way to stop that. NW1223<Howl at me•My hunts>13:17, 18 February 2024 (UTC)[reply]
This is an interesting option. My initial reaction to this idea was a bit meh, but upon reflection I think this might help a bit and moves us closer to the standard democratic process organisations have for selecting individuals for tasks (which is closed voting with a discussion about the candidate, rather than about a vote). There is a social dynamics when there are two options (support or oppose), which pits people against each other. By moving the discussion to the discussion section, you make that dynamics less prominent. —Femke 🐦 (talk) 15:20, 18 February 2024 (UTC)[reply]
Consolidating discussion about a given concern will reduce repetition, making it easier for new commenters to join in or for previous commenters to catch up. It will also mitigate the demoralizing effect on candidates from seeing the same criticisms being discussed repeatedly in separate threads. I think there remains social pressure against oppose voters, as they can still be challenged and engaged, and it also makes it easier for multiple challengers to engage. The convenience of the challenged and an initial challenger is traded off for the greater convenience of everyone else following the discussion about a common concern. isaacl (talk) 18:07, 18 February 2024 (UTC)[reply]
Support. As an implementation procedure, there could be language on the page or in the section to remind editors to respond in the general comments section or the talk page. --Enos733 (talk) 18:49, 18 February 2024 (UTC)[reply]
Worth a shot :) I would encourage future RfA candidates to mess with the template on their RfA – if you can add something interesting to your RfA's structure that doesn't impair the community's ability to find consensus, ask for forgiveness, not permission. People have done it before! I wish I'd thought to do so before my second RfA. theleekycauldron (talk • she/her) 23:01, 18 February 2024 (UTC)[reply]
Support as a trial: almost anything is worth trying. It's possible that preventing threaded discussion will reduce the overall number of words wasted at RfA, as one could argue applies at various ArbCom pages. RfA has a tendency to create ludicrous overemphasis of minor events or details, completely unrelated to whether the candidate will be a net positive as an admin. I'm not sure whether this would exacerbate or alleviate this but we could find out by testing.
My concern would be that false information or BLP and civility violations may remain unchallenged under this format, as bureaucrats and oversighters typically refuse to enforce such policies and no-one else feels qualified to (it took six days for a very prominent BLP-violating comment to be removed at a recent RfA). But such things should be challenged with removal rather than badgering anyway. — Bilorv (talk) 23:08, 18 February 2024 (UTC)[reply]
Weak support, basically per Bilorv and Femke. If the 'crats and oversighters enforce civility and keep BLP-violatey stuff out, this will work well. If they don't, it won't. -- asilvering (talk) 21:22, 19 February 2024 (UTC)[reply]
Middling support - I really find the bashing on oppose !votes unproductive and serves to heighten and draw attention to drama rather than reducing it in any way. I'd be happy to see discussions without it. FOARP (talk) 22:03, 19 February 2024 (UTC)[reply]
Oppose (No threaded-discussion RfA trial)
This just makes the discussion impossible to follow. If replies to votes are outlawed, then voting comments should be restricted to seven letters instead of allowing the posting of out-of-context character assassination diffs without a right to highlight a reply. —Kusma (talk) 14:19, 18 February 2024 (UTC)[reply]
This is not at all comparable to an Arbcom case. Voters will not be added as parties whose behaviour is scrutinised and will not be subject to sanctions if they misbehave. —Kusma (talk) 16:03, 18 February 2024 (UTC)[reply]
I think this will make it easier for people who oppose while not offrring any benefit to candidates. I think the social pressure against opposing is, on the whole, a positive. For me, fixing RfA isn't an ends of its own but a means to the ends of getting more admin. Since I think this gets us farther from that I am oppoosed. Best, Barkeep49 (talk) 15:25, 18 February 2024 (UTC)[reply]
Per Barkeep. This will result in an increase in non-substantive opposes for reasons not relevant to the candidate's suitability for adminship. We should not be rewriting our procedures in a way that will primarily protect disruptive editors. LEPRICAVARK (talk) 18:29, 18 February 2024 (UTC)[reply]
Does it break subscriptions? I'm under the impression that since only level-2 headings can be subscribed to, you can't subscribe in the first place. Aaron Liu (talk) 21:50, 18 February 2024 (UTC)[reply]
At present the request is to implement subsection-specific subscriptions, though, and not individual numbered items in a list. While I imagine the same underlying implementation can be re-used for lists, I'm not sure the resulting tradeoff of additional markup would be worthwhile given the lesser frequency where subscribing to list items would be a preferable option. isaacl (talk) 18:35, 19 February 2024 (UTC)[reply]
I agree entirely with Kusma. I think the core idea here is a good one: why not prohibited threaded discussion altogether? Any discussion consisting of more than one reply to a bolded !vote must happen on the talk page (or elsewhere). Vanamonde93 (talk) 23:07, 18 February 2024 (UTC)[reply]
I think threaded opposes are what RfA voters perceive as toxicity. But as someone who had a controversial RfA I don't think the endless RfA back and forths matter much to the candidate - the hard part really is having 200+ people scrutinizing you (and every response to every question asked) and many people writing negative things about you (and it seems often, being able to cast aspersions and make personal attacks without anyone doing anything about it), and this doesn't really help with that. In fact I mostly appreciated the people who defended me in the oppose section of my RfA.
I wish honestly that people removed bad opposes if they are personal attacks/aspersions, rather than endlessly engaging with them, but I don't know if a rule can be made to solve this (other than encouraging more RfA clerking and enforcement of civility norms at RfA). Galobtter (talk) 06:42, 19 February 2024 (UTC)[reply]
Per Waltclipper and Vanamonde93. I think this proposal has "an" idea, but it's not sufficiently baked. It does not go far enough to remove threaded discussion (regardless of if those are positive or not) but also risks making following discussions impossible. Soni (talk) 14:36, 19 February 2024 (UTC)[reply]
Mainly per Kusma. It might accomplish what it's supposed to accomplish at ArbCom, but it absolutely makes many arb cases impossible for a passerby to follow. In an arbitration case, there are far fewer people talking and most of the discussion is for the sake of an even smaller number of people who have to judge what's said. At RfA, it's in every participant's interest to be able to understand what's being said, and most people aren't following the whole thing closely. — Rhododendritestalk \\ 16:29, 19 February 2024 (UTC)[reply]
As mentioned above, following a conversation would be near-impossible. This would probably decrease stress on opposers since they'll likely be badgered less but increase stress on the candidates by increasing the number of petty, POINTy, and poorly thought-out opposes. Sincerely, Novo TapeMy Talk Page19:39, 19 February 2024 (UTC)[reply]
Maybe something like this could be made to work, but I really believe that we should go in the direction of more discussion, not less. (Yes, I know that may sound strange, in the context of feeling that RfA discussions veer towards unpleasant piling on, as well as there being far too many "optional" questions.) If we want to curtail spurious arguments, we need to give the crats a basis to weigh different comments differently. --Tryptofish (talk) 19:56, 19 February 2024 (UTC)[reply]
Neutral (No threaded-discussion RfA trial)
On the one hand, I agree with Bilorv that almost anything is worth trying, and since it is a non-frivolous idea, I can't oppose it. But the idea itself I think has little possibility of success. RfA is not ArbCom. This proposal does not see any restrictions on how much one can say in discussions, so I imagine there will be something like "Oppose, see diff" and a long tirade about all ills that that candidate allegedly caused.
It may be a matter of bad taste to reply to that criticism, but the candidate should have that possibility regardless of customs around RfA. When there are 20-25 opposes to handle, it becomes too difficult to manage it in one section, plus, as commenters above said, the flow will be severely impaired. The structure is also incompatible with RfA's aims. It is important in ArbCom because it's easier to police individual users against excesses and it lets ArbCom understand what are the parties', amici and arb positions. RfA is more about discussing the way candidates would handle admin issues and not about the !voters or the positions of power users/accused parties/whatever. Structuring that by editors increases the risk of certain users "stealing the show" when what we should be doing is minimising it and making sure it's about assessing candidates on their merits. Szmenderowiecki (talk) 01:29, 19 February 2024 (UTC)[reply]
General discussion (No threaded-discussion RfA trial)
Two quick questions: this will be a 7-day RfA vote with immediate voting but with comments grouped by editor or it will be a ten-day RfA? Secondly, will the candidate be able to reply to a user's remarks in the user's section? Because unlike ArbCom cases, RfAs are dynamic, particularly if the outcome is close, and realistically even if 10% of the usual 200-ish users start their own discussion subsections, replies to each of the users will be very hard to track. Szmenderowiecki (talk) 15:28, 18 February 2024 (UTC)[reply]
The intention is that this trial will utilise the usual seven days. If both these proposals are trialled, then the intention is that there would be a discussion on how each went, and the positive aspects utilised permanently, so we could end up with a 10 day RfA without threaded-discussions.
Candidates would comment in their own section. While candidates are currently not discouraged from responding directly to vote comments in their RfA, it is generally regarded as not a good idea. When it is seen that a candidate might benefit from responding to a negative criticism, the usual thing is that someone will write a question inviting the candidate to respond. I would expect that practise to continue, and for candidates to confine themselves to answering questions in the question section. SilkTork (talk) 16:38, 18 February 2024 (UTC)[reply]
Also, it may very well be that one change doesn't make much difference but two in conjunction will, so if the discussion-only trial is a success, maybe let's not revert back and just see if adding threaded discussions further improves RfA? Szmenderowiecki (talk) 15:32, 18 February 2024 (UTC)[reply]
I think it would be acceptable to set this trial up after the RfC following Barkeep's trial. I did consider that initially, but what gave me pause was that people can become RfC weary when it involves the same topic. I think there may be some benefit in having just the one RfC after both trials, rather than having two RfCs - one after each trial. But it could work either way, and people may indicate their preference when they comment. SilkTork (talk) 16:38, 18 February 2024 (UTC)[reply]
The Spanish Wikipedia does something similar: votes can only have a short comment (15 words max), and all questions to the candidate and extended discussion happen on the talk page. I am still undecided on its effectiveness (after all, there was only one successful RFA in all of 2023), but it's a point to consider, and I have certainly noticed that the discussion focuses more on the candidate than the voters. –FlyingAce✈hello16:02, 18 February 2024 (UTC)[reply]
Let's say that, in my own comment in an RfA of this sort, I want to say something about what another editor has said. If I understand the proposal correctly, I would say that within my own comment, as opposed to saying it in a threaded reply to the other editor. If I think about how this format has worked at WP:AE, where it is also used, it often leads to walls of text that end up being limited when admins enforce a word limit, but it doesn't reduce the back-and-forth sniping. At ArbCom, the format works better because, in part, editors are required to address their comments to Arbs or clerks, not one another, which would not be workable at RfA. Also, both ArbCom and AE use individual sections for each editor, whereas there would have to be a hundred-plus sections if we were to do actual sections at RfA. --Tryptofish (talk) 22:05, 18 February 2024 (UTC)[reply]
Seems to me these proposals are all too complicated. The principle should be to discuss the candidate first and then vote after the discussion -- not during the discussion.
A sequence of events might be: (1) A nomination and seconds of the candidate to become an administrator followed by a statement by the candidate in which they tell us why they should be an administrator (with a maximum length of, say, 500 words). (2) Discussion of the candidate for, say, 5 days. Commentators may present pro or con evidence in favor of the candidate. "Evidence" is the key word here. You can't just say I don't like this candidate because they were mean to me; you have to present specific examples of said incivility or mistakes. Nor can you just say that the candidate is a good person; you have to present specific examples of what they have done that was good. The candidate and other people may respond, if they wish to address any of the comments. (3) Vote, for say 3 days. Support or oppose only. No comments allowed during the vote.
What that system would do would be to ensure that people have more information about the candidate before the vote begins. It would also encourage the candidate to participate directly in the discussion about their candidacy. Smallchief (talk) 00:14, 19 February 2024 (UTC)[reply]
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.
Hello there, Wiki changed the font on Thursday night but is there any way you are able to revert it back to the original font before the changes on Thursday. The new font changes on mobile look very ugly and I personally would much prefer the original font design. VileName8089289 (talk) 18:45, 18 February 2024 (UTC)[reply]
At least the browser I use allows me to choose the standard serif/non-serif fonts for rendering text in settings, which doesn't override Google's preferences but whatever is Wikipedia's default font is substituted by the font of your choice. I use Bahnschrift (essentially DIN 1451), but you can choose Comic Sans if you want.
As far as we are concerned, most of us cannot change it on a system level. You should first start with the technical part of the village pump, maybe they will have a better grasp on your issue (I noticed nothing tbh), and maybe they will ask you to add a ticket to Phabricator (a bit like Wikimedia's internal Github). It could also be that interface administrators tweaked something, though I heard nothing about it. If VPT doesn't help, ask the interface administrator noticeboard if they were tweaking anything lately that caused a change in fonts. Szmenderowiecki (talk) 19:17, 18 February 2024 (UTC)[reply]
Also, BEFORE YOU ASK ANYWHERE ELSE, make sure you didn't change your system font settings on your phone or tablet. Maybe you inadvertently did just that. Because I am on mobile and I cannot reproduce your problem. It looks OK. Szmenderowiecki (talk) 19:21, 18 February 2024 (UTC)[reply]
The font design changed to the new edition on Thursday night then it briefly reverted back to the original design and then permanently changed to the new design. The new design is much less appealing and I much prefer the original font design pre Thursday night. VileName8089289 (talk) 20:35, 18 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
Why do we have to use the British imperial style of writing in the English Wikipedia? Most native English speakers use the American style of writing. Furthermore, the British imperial style reminds a lot of people of colonial abuses. I certainly don't want to be reminded of any of that while editing an article. Wikipedia is a free, democratic wonderland to me, but having to learn "the King's English" reminds me of how many robberies, rapes, and murders it took to build that empire. This destroys my inspiration, my motivation. I would be happy to learn a new style that doesn't remind me of violence, however you like, but please, no more abuse. Citizen127 (talk) 11:47, 19 February 2024 (UTC)[reply]
And the Americans didn't rob, rape, and murder in building their 'empire' across the west? Just ask the Indians about that. But, seriously, EVERY empire ever built from the Persians, to Alexander the Great to the Romans to the Mongols the Spanish to the Japanese robbed, raped, and murdered their way to emperial 'glory'. To take it a step further, most empires also practiced genocide while expanding. So I don't see your point in singling out the Brits. Masterhatch (talk) 12:48, 19 February 2024 (UTC)[reply]
Just a side note to clear up a potential misunderstanding regarding Wikipedia being a "free, democratic wonderland"; in fact, it is not a democracy. It has processes which resemble democratic voting, but these are still generally consensus-based and subject to override (even straw polls such as RfA); and the institution itself is not wholly democratic, due to the site's relationship to the Wikimedia Foundation and effectively functioning as its volunteer arm. Duly signed,⛵ WaltClipper-(talk)13:42, 19 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Please revert font design on wiki to original design used before Thursday
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.A summary of the conclusions reached follows.
Don't badger us with the same requests over and over again - this will not increase your chances of addressing your concerns. The VPT thread is dealing with that, and you already got advice above (how you change fonts on your device/browser, rather than in Wikipedia, is device/browser-specific); no need to start more of these discussions. Szmenderowiecki (talk) 16:18, 19 February 2024 (UTC)[reply]
Hello there, Wiki changed the font on Thursday night but is there any way you are able to revert it back to the original font before the changes on Thursday. The new font changes on mobile look very ugly and I personally would much prefer the original font design. VileName8089289 (talk) 15:20, 19 February 2024 (UTC)[reply]
Asked and answered two sections up. Please stop posting this over and over, on this page and on the other pages you have been doing so. MrOllie (talk) 15:21, 19 February 2024 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Allowing editors to opt out of private information on XTools.
Option 2 at the least, as proposer. The current state of affairs does not seem like a good thing. Isn't automatically revealing more private information on XTools unsavoury at the very least? Users should at the minimum have the right to restrict more private data such as the timecards from appearing in the XTools analysis. As SlimVirgin wrote during a 2014 discussion on the issue, Even though the information is in theory publicly available, presenting it in this format is still a privacy issue. (Just because we all walk down the street doesn't mean we'd want CCTV cameras joining up our activities and someone posting it online.)🌺 Cremastra (talk) 20:10, 19 February 2024 (UTC)[reply]
Option 1 I do not think users should have any expectation that information extractable from WP logs won't be compiled, and would argue that allowing them to is (mildly) against WP:5P3Mach61 (talk) 20:21, 19 February 2024 (UTC)[reply]
Option 2. Option 3.Option 2.5. As I understand it, the devs only allow opting out of three areas: timecard, monthly counts, and top edits by namespace. My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. I agree with @Cremastra and @SlimVirgin. When you're editing on Wikipedia isn't private information per se, since anyone can take a look at someone's edit history. However, an easy-to-use tool that lets someone know when you're generally online and making edits can pose security risks (e.g., it can show when you're usually home and usually not at home; similarly, monthly counts can show what months you're generally on vacation or away from home). Regarding @Mach61's point that users should [not] have any expectation that information extractable from WP logs won't be compiled, the only tool that currently does that compiling is XTools, and I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. This should be disabled by default because new editors won't know that it exists, and anyone who knows enough to know that XTools exists would know how to opt in if they choose. voorts (talk/contributions) 20:44, 19 February 2024 (UTC), changed !vote 20:49, 19 February 2024 (UTC) and again 21:08, 19 February 2024 (UTC)[reply]
I doubt someone would go through the headache of creating, hosting, and maintaining a new tool in the event that en-wiki users are allowed to opt out. It's quite simple to write a quarry query doing all of this - it wouldn't look as nice, but the information would be there. BilledMammal (talk) 21:44, 19 February 2024 (UTC)[reply]
There already is at least one other tool that shows timecards and monthly counts (wikichecker), and I'm pretty sure that creating a new version of the xtools edit counter tool would be relatively trivial, since the source code is freely available. Firefangledfeathers (talk / contribs) 23:27, 19 February 2024 (UTC)[reply]
Fair enough. Xtools is fairly integrated into Wikipedia though, so I think removing that option creates an extra step for potentially malicious people to poke around. voorts (talk/contributions) 23:30, 19 February 2024 (UTC)[reply]
Option 1.5 - Mostly agree with Pppery and Mach61. Edits are public and transparent. If someone wants to gather our public edits and make a neat tool to show patterns in those edits, that's generally a good thing IMO. What's more, we have no real say, because we already agree to make edits on a public, transparent, free, and open wiki. It's 100% up to the developers what they want to do, and an RfC about opt-in/opt-out is really just a request. If the devs honor it, anyone else could just fork it and host the same thing elsewhere. For the most part, I don't think the devs should allow opt-out. Again, it's all public information and the tool is frequently useful. The only argument I find myself sympathetic with is the one about timecards per SlimVirgin/Cremastra. Although I just finished talking about how it's all public and up to the devs, to take it to an extreme, I think this community wouldn't take kindly to developers of a tool that, for example, processed the entire text of a user's contributions to produce a profile guessing at their real life identity. In short, if you run an RfC, be sure to separate the timecard from everything else or you'll get a bunch of people like me who sortakinda think the timecard should have an opt-out, but would oppose a blanket question. — Rhododendritestalk \\ 21:00, 19 February 2024 (UTC)[reply]
Comment - The info page on xtools says Your wiki should have had a local discussion showing consensus for these statistics to be allowed. Did that discussion ever happen, and if so when? If not, then en wiki needs to go back to hiding that info until that discussion happens (which would be this topic if/when it becomes an RFC). RudolfRed (talk) 21:09, 19 February 2024 (UTC)[reply]
Option 1 Your edit history is always publicly available and visible to anyone and everyone, and pretending otherwise is at best ineffective and at worst misleading and harmful to the transparency that Wikipedia tries to support. Even allowing opt-out for timecards is potentially harmful, as it gives the false impression that users can hide PII such as the times they are active. Finally, it seems somewhat silly to have all this handwringing about XTools when completely unaffiliated sites such as https://en.wikichecker.com/ exist. --Ahecht (TALK PAGE) 21:11, 19 February 2024 (UTC)[reply]
Option 2.5 (My !vote is to require users to affirmatively opt-in for timecard and monthly counts, but not top edits by namespace, which should not allow an opt-out. -- voorts) What harm can one do with someone's edit count and top edits? I can see an argument against time cards and monthly edits. Someone could always try to create a tool to replicate these functions in order to act maliciously, but there's no reason for us to facilitate their aims by providing a tool to do this.Sincerely, Novo TapeMy Talk Page21:17, 19 February 2024 (UTC)[reply]
Several purposes: they can help users in identifying sockpuppets, they can can help visualize when a user is likely to be active if you're waiting for feedback from them, and they can help make it obvious to editors that such an analysis is possible and that it is something they should be aware of if they are trying to keep their anonyminity. --Ahecht (TALK PAGE) 21:36, 19 February 2024 (UTC)[reply]
Option 1; scrutiny protects both the encyclopaedia and the user. Allowing some users to opt out would allow maleficent users to evade / delay proper scrutiny. If some editors' editing patterns are available, then all editors' editing patterns should be available. This data is not private like one's medical records or finances. Having said that, a warning to editors, say in the edit window, might not go amiss. The principle is simple; if you don't want your editing patterns available to all and sundry for scrutiny, then do not edit Wikipedia. Baffle☿gab21:30, 19 February 2024 (UTC)[reply]
Option 1; this won't improve privacy, all it will do is gate-keep it - more technically minded users will still be able to access it, while less technically minded users won't. I don't think that is a productive division. BilledMammal (talk) 21:33, 19 February 2024 (UTC)[reply]
The timecard should go. I see no reason for this data to be aggregated like this - what legitimate purpose does it serve? But the others, I see legitimate uses for them, and I don't see any good reason to allow opt-out. I think opt-out would possibly be harmful as mentioned by some responses above (ie, that it would make people think their edits are more private than they are). We've already given up that kind of privacy by editing here in the first place. -- asilvering (talk) 21:34, 19 February 2024 (UTC)[reply]
Comment Aside from all-important anonymity, Wikipedia is the most privacy-violating website that there is. It it a very easy convenient publicly searchable database of every edit that the editor ever made including the exact date and time that they made it. And there isn't a simple line between public and non public. Degree and ease of public access is important. Scratching your butt on your front lawn is technically public, as is your name and address, but if I take a telephoto video of you doing it and have it put on television and make a permanent searchable youtube video of it, I'm changing the degree of privacy and can't just say that I'm not because it's all public already. For example, if somebody outs you, anybody with no expertise can just click "edit count" can prepare a study on you in 30 seconds on how much editing you did when you were supposed to be at work and give it to your boss. I think that protecting anonymity is far more important than this proposed change, but I think that the proposed change is also a good idea. North8000 (talk) 21:44, 19 February 2024 (UTC)[reply]
Option 1. The privacy of editors is important, but we need to balance this against our goal of making an encyclopedia, which requires a degree of transparency in order to track sockpuppets and malicious editors; failing at that doesn't just hurt our mission, it has the potential to cause real-world harm even to people who haven't edited the encyclopedia, either because of BLP issues or because of harm caused when they try to rely on it. On the balance, these things are not a high privacy interest for most editors, while they are extremely valuable for identifying sockpuppets and COI editors. --Aquillion (talk) 22:02, 19 February 2024 (UTC)[reply]
Option 1. Status quo. The information proposed to be obfuscated doesn't seem particularly dangerous to me except maybe the timecard, and the timecard is an important tool for sock hunters. –Novem Linguae (talk) 22:53, 19 February 2024 (UTC)[reply]
Option 1. This is silly. It's all public information, and absolutely nothing is stopping me from forking xtools and/or developing a similar service and running it out of my personal website. -Fastily01:23, 20 February 2024 (UTC)[reply]
Here are some links I think it could include: (note that the information in the middle columns is mostly based on observation and guesswork, and only occasionally on documentation)
EBSCOhost and ProQuest unfortunately appear to be technically infeasible without some modifications. EBSCOhost requires a token in the URL alongside the query, and ProQuest sends the query in a POST request.
22:42, 13 January 2024 (UTC)[reply]
Done I presume LegoBot will do its thing and copy the new RfC text over. Ca talk to me! 16:56, 18 January 2024 (UTC)[reply]
