This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
RfC: Voluntary RfA after resignation
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.
There is clear consensus that participants in this discussion wish to retain the "Option 2" status quo. We're past 30 days of discussion and there's not much traffic on the discussion now. It's unlikely the consensus would suddenly shift with additional discussion. --Hammersoft (talk) 18:29, 16 January 2025 (UTC)[reply]
Option 1 – Require former administrators to request restoration of their tools at the bureaucrats' noticeboard (BN) if they are eligible to do so (i.e., they do not fit into any of the exceptions).
Option 2 – Clarify Maintain the status quo that former administrators who would be eligible to request restoration via BN may instead request restoration of their tools via a voluntary request for adminship (RfA).
Option 3 – Allow bureaucrats to SNOW-close RfAs as successful if (a) 48 hours have passed, (b) the editor has right of resysop, and (c) a SNOW close is warranted.
2, after thought. I don't think 3 provides much benefit, and creating separate class of RfAs that are speedy passed feels a misstep. If there are serious issues surrounding wasting time on RfAs set up under what might feel to someone like misleading pretenses, that is best solved by putting some indicator next to their RFA candidate name. Maybe "Hog Farm (RRfA)". CMD (talk) 14:49, 16 December 2024 (UTC)[reply]
best solved by putting some indicator next to their RFA candidate name. Maybe "Hog Farm (RRfA)" - I like this idea, if option 2 comes out as consensus I think this small change would be a step in the right direction, as the "this isn't the best use of time" crowd (myself included) would be able to quickly identify the type of RFAs they don't want to participate in. BugGhost🦗👻11:05, 17 December 2024 (UTC)[reply]
I think that's a great idea. I would support adding some text encouraging people who are considering seeking reconfirmation to add (RRfA) or (reconfirmation) after their username in the RfA page title. That way people who are averse to reading or participating in reconfirmations can easily avoid them, and no one is confused about what is going on. 28bytes (talk) 14:23, 17 December 2024 (UTC)[reply]
If we are differentiating three types of RFA we need three terms. Post-recall RFAs are referred to as "reconfirmation RFAs", "Re-RFAS" or "RRFAs" in multiple places, so ones of the type being discussed here are the ones that should take the new term. "Voluntary reconfirmation RFA" (VRRFA or just VRFA) is the only thing that comes to mind but others will probably have better ideas. Thryduulf (talk) 21:00, 17 December 2024 (UTC)[reply]
Of course they may request at RfA. They shouldn't but they may. This RfA feels like it does nothing to address the criticism actually in play and per the link to the idea lab discussion it's premature to boot. Barkeep49 (talk) 21:38, 15 December 2024 (UTC)[reply]
2 per my comments at the idea lab discussion and Queent of Hears, Beeblebrox and Scazjmd above. I strongly disagree with Barkeep's comment that "They shouldn't [request the tools back are RFA]". It shouldn't be made mandatory, but it should be encouraged where the time since desysop and/or the last RFA has been lengthy. Thryduulf (talk) 21:42, 15 December 2024 (UTC)[reply]
1 or 3. RFA is an "expensive" process in terms of community time. RFAs that qualify should be fast-tracked via the BN process. It is only recently that a trend has emerged that folks that don't need to RFA are RFAing again. 2 in the last 6 months. If this continues to scale up, it is going to take up a lot of community time, and create noise in the various RFA statistics and RFA notification systems (for example, watchlist notices and User:Enterprisey/rfa-count-toolbar.js). –Novem Linguae (talk) 21:44, 15 December 2024 (UTC)[reply]
Making statistics "noisy" is just a reason to improve the way the statistics are gathered. In this case collecting statistics for reconfirmation RFAs separately from other RFAs would seem to be both very simple and very effective. If (and it is a very big if) the number of reconfirmation RFAs means that notifications are getting overloaded, then we can discuss whether reconfirmation RFAs should be notified differently. As far as differentiating them, that is also trivially simple - just add a parameter to template:RFA (perhaps "reconfirmation=y") that outputs something that bots and scripts can check for. Thryduulf (talk) 22:11, 15 December 2024 (UTC)[reply]
I'm weakly opposed to option 3, editors who want feedback and a renewed mandate from the community should be entitled to it. If they felt that that a quick endorsement was all that was required then could have had that at BN, they explicitly chose not to go that route. Nobody is required to participate in an RFA, so if it is going the way you think it should, or you don't have an opinion, then just don't participate and your time has not been wasted. Thryduulf (talk) 22:20, 15 December 2024 (UTC)[reply]
Added option 3 above. Maybe worth considering as a happy medium, where unsure admins can get a check on their conduct without taking up too much time. theleekycauldron (talk • she/her) 22:11, 15 December 2024 (UTC)[reply]
2 – If a former admin wishes to subject themselves to RfA to be sure they have the requisite community confidence to regain the tools, why should we stop them? Any editor who feels the process is a waste of time is free to ignore any such RfAs. — Jkudlick ⚓ (talk)22:12, 15 December 2024 (UTC)[reply]
I would also support option 3 if the time is extended to 72 hours instead of 48. That, however, is a detail that can be worked out after this RfC. — Jkudlick ⚓ (talk)02:05, 16 December 2024 (UTC)[reply]
A further note: option 3 gives 'crats the discretion to SNOW close a successful voluntary re-RfA; it doesn't require such a SNOW close, and I trust the 'crats to keep an RfA open if an admin has a good reason for doing so. voorts (talk/contributions) 23:24, 16 December 2024 (UTC)[reply]
Option 2 (no change) – The sample size is far too small for us to analyze the impact of such a change, but I believe RfA should always be available. Now that WP:RECALL is policy, returning administrators may worry that they have become out of touch with community norms and may face a recall as soon as they get their tools back at BN. Having this familiar community touchpoint as an option makes a ton of sense, and would be far less disruptive / demoralizing than a potential recall. Taking this route away, even if it remains rarely used, would be detrimental to our desire for increased administrator accountability. – bradv22:22, 15 December 2024 (UTC)[reply]
2, distant second preference 3. I would probably support 3 as first pick if not for recall's rule regarding last RfA, but as it stands, SNOW-closing a discussion that makes someone immune to recall for a year is a non-starter. Between 1 and 2, though, the only argument for 1 seems to be that it avoids a waste of time, for which there is the much simpler solution of not participating and instead doing something else. Special:Random and Wikipedia:Backlog are always there. -- Tamzin[cetacean needed] (they|xe|🤷) 23:31, 15 December 2024 (UTC)[reply]
Option 1. No second preference between 2 or 3. As long as a former administrator didn't resign under a cloud, picking up the tools again should be low friction and low effort for the entire community. If there are issues introduced by the recall process, they should be fixed in the recall policy itself. Daniel Quinlan (talk) 01:19, 16 December 2024 (UTC)[reply]
Option 2, i.e. leave well enough alone. There is really not a problem here that needs fixing. If someone doesn’t want to “waste their time” participating in an RfA that’s not required by policy, they can always, well, not participate in the RfA. No one is required to participate in someone else’s RfA, and I struggle to see the point of participating but then complaining about “having to” participate. 28bytes (talk) 01:24, 16 December 2024 (UTC)[reply]
Option 3: Because it is incredibly silly to have situations like we do now of "this guy did something wrong by doing an RfA that policy explicitly allows, oh well, nothing to do but sit on our hands and dissect the process across three venues and counting." Your time is your own. No one is forcibly stealing it from you. At the same time it is equally silly to let the process drag on, for reasons explained in WP:SNOW. Gnomingstuff (talk) 03:42, 16 December 2024 (UTC)[reply]
Option 3 per Gnoming. I think 2 works, but it is a very long process and for someone to renew their tools, it feels like an unnecessarily long process compared to a normal RfA. Conyo14 (talk) 04:25, 16 December 2024 (UTC)[reply]
As someone who supported both WormTT and Hog Farm's RfAs, option 1 > option 3 >> option 2. At each individual RfA the question is whether or not a specific editor should be an admin, and in both cases I felt that the answer was clearly "yes". However, I agree that RfA is a very intensive process. It requires a lot of time from the community, as others have argued better than I can. I prefer option 1 to option 3 because the existence of the procedure in option 3 implies that it is a good thing to go through 48 hours of RfA to re-request the mop. But anything which saves community time is a good thing. HouseBlaster (talk • he/they) 04:31, 16 December 2024 (UTC)[reply]
I've seen this assertion made multiple times now that [RFA] requires a lot of time from the community, yet nowhere has anybody articulated how why this is true. What time is required, given that nobody is required to participate and everybody who does choose to participate can spend as much or as little time assessing the candidate as they wish? How and why does a reconfirmation RFA require any more time from editors (individually or collectively) than a request at BN? Thryduulf (talk) 04:58, 16 December 2024 (UTC)[reply]
I think there are a number of factors and people are summing it up as "time-wasting" or similar:
BN Is designed for this exact scenario. It's also clearly a less contentious process.
Snow closures a good example of how we try to avoid wasting community time on unnecessary process and the same reasoning applies here. Wikipedia is not a bureaucracy and there's no reason to have a 7-day process when the outcome is a given.
If former administrators continue to choose re-RFAs over BN, it could set a problematic precedent where future re-adminship candidates feel pressured to go through an RFA and all that entails. I don't want to discourage people already vetted by the community from rejoining the ranks.
The RFA process is designed to be a thoughtful review of prospective administrators and I'm concerned these kinds of perfunctory RFAs will lead to people taking the process less seriously in the future.
Because several thousand people have RFA on their watchlist, and thousands more will see the "there's an open RFA" notice on theirs whether they follow it or not. Unlike BN, RFA is a process that depends on community input from a large number of people. In order to even realise that the RFA is not worth their time, they have to:
Read the opening statement and first few question answers (I just counted, HF's opening and first 5 answers are about 1000 words)
Think, "oh, they're an an ex-admin, I wonder why they're going through RFA, what was their cloud"
Read through the comments and votes to see if any issues have been brought up (another ~1000 words)
None have
Realise your input is not necessary and this could have been done at BN
That they were former admins has always been the first two sentences of their RfA’s statement, sentences which are immediately followed by that they resigned due to personal time commitment issues. You do not have to read the first 1000+ words to figure that out. If the reader wants to see if the candidate was lying in their statement, then they just have a quick skim through the oppose section. None of this should take more than 30 seconds in total. Aaron Liu (talk) 13:15, 16 December 2024 (UTC)[reply]
Not everyone can skim things easily - it personally takes me a while to read sections. I don't know if they're going to bury the lede and say something like "Also I made 10,000 insane redirects and then decided to take a break just before arbcom launched a case" in paragraph 6. Hog Farm's self nom had two paragraphs about disputes and it takes more than 30 seconds to unpick that and determine if that is a "cloud" or not. Even for reconfirmations, it definitely takes more than 30 seconds to determine a conclusion. BugGhost🦗👻11:21, 17 December 2024 (UTC)[reply]
They said they resigned to personal time commitments. That is directly saying they wasn’t under a cloud, so I’ll believe them unless someone claims the contrary in the oppose section. If the disputes section contained a cloud, the oppose section would have said so. One chooses to examine such nominations like normal RfAs. Aaron Liu (talk) 18:47, 17 December 2024 (UTC)[reply]
Just to double check, you're saying that whenever you go onto an RFA you expect any reason to oppose to already be listed by someone else, and no thought is required? I am begining to see how you are able to assess an RFA in under 30 seconds BugGhost🦗👻23:08, 17 December 2024 (UTC)[reply]
Something in their statement would be an incredibly obvious reason. We are talking about the assessment whether to examine and whether the candidate could've used BN. Aaron Liu (talk) 12:52, 18 December 2024 (UTC)[reply]
@Thryduulf let's not confuse "a lot of community time is spent" with "waste of time". Some people have characterized the re-RFAs as a waste of time but that's not the assertion I (and I think a majority of the skeptics) have been making. All RfAs use a lot of community time as hundreds of voters evaluate the candidate. They then choose to support, oppose, be neutral, or not vote at all. While editor time is not perfectly fixed - editors may choose to spend less time on non-Wikipedia activities at certain times - neither is it a resource we have in abundance anymore relative to our project. And so I think we, as a community, need to be thought about how we're using that time especially when the use of that time would have been spent on other wiki activities.Best, Barkeep49 (talk) 22:49, 16 December 2024 (UTC)[reply]
Absolutely nothing compels anybody to spend any time evaluating an RFA. If you think your wiki time is better spent elsewhere than evaluating an RFA candidate, then spend it elsewhere. That way only those who do think it is a good use of their time will participate and everybody wins. You win by not spending your time on something that you don't think is worth it, those who do participate don't have their time wasted by having to read comments (that contradict explicit policy) about how the RFA is a waste of time. Personally I regard evaluating whether a long-time admin still has the approval of the community to be a very good use of community time, you are free to disagree, but please don't waste my time by forcing me to read comments about how you think I'm wasting my time. Thryduulf (talk) 23:39, 16 December 2024 (UTC)[reply]
I don't understand how your argument that it is not a good use of community time is any different from arguing that it is a waste of time? Thryduulf (talk) 09:08, 17 December 2024 (UTC)[reply]
Option 2 I don't mind the re-RFAs, but I'd appreciate if we encouraged restoration via BN instead, I just object to making it mandatory. EggRoll97(talk) 06:23, 16 December 2024 (UTC)[reply]
Option 2. Banning voluntary re-RfAs would be a step in the wrong direction on admin accountability. Same with SNOW closing. There is no more "wasting of community time" if we let the RfA run for the full seven days, but allowing someone to dig up a scandal on the seventh day is an important part of the RfA process. The only valid criticism I've heard is that folks who do this are arrogant, but banning arrogance, while noble, seems highly impractical. Toadspike[Talk]07:24, 16 December 2024 (UTC)[reply]
Option 3, 1, then 2, per HouseBlaster. Also agree with Daniel Quinlan. I think these sorts of RFA's should only be done in exceptional circumstances. Graham87 (talk) 08:46, 16 December 2024 (UTC)[reply]
Option 1 as first preference, option 3 second. RFAs use up a lot of time - hundreds of editors will read the RFA and it takes time to come to a conclusion. When that conclusion is "well that was pointless, my input wasn't needed", it is not a good system. I think transparency and accountability is a very good thing, and we need more of it for resyssopings, but that should come from improving the normal process (BN) rather than using a different one (RFA). My ideas for improving the BN route to make it more transparent and better at getting community input is outlined over on the idea labBugGhost🦗👻08:59, 16 December 2024 (UTC)[reply]
Option 2, though I'd be for option 3 too. I'm all for administrators who feel like they want/should go through an RfA to solicit feedback even if they've been given the tools back already. I see multiple people talk about going through BN, but if I had to hazard a guess, it's way less watched than RfA is. However I do feel like watchlist notifications should say something to the effect of "A request for re-adminship feedback is open for discussion" so that people that don't like these could ignore them. ♠JCW555(talk)♠ 09:13, 16 December 2024 (UTC)[reply]
Option 2 because WP:ADMINISTRATORS is well-established policy. Read WP:ADMINISTRATORS#Restoration of admin tools, which says quite clearly, Regardless of the process by which the admin tools are removed, any editor is free to re-request the tools through the requests for adminship process. I went back 500 edits to 2017 and the wording was substantially the same back then. So, I simply do not understand why various editors are berating former administrators to the point of accusing them of wasting time and being arrogant for choosing to go through a process which is specifically permitted by policy. It is bewildering to me. Cullen328 (talk) 09:56, 16 December 2024 (UTC)[reply]
Option 2 & 3 I think that there still should be the choice between BN and re-RFA for resysops, but I think that the re-RFA should stay like it is in Option 3, unless it is controversial, at which point it could be extended to the full RFA period. I feel like this would be the best compromise between not "wasting" community time (which I believe is a very overstated, yet understandable, point) and ensuring that the process is based on broad consensus and that our "representatives" are still supported. If I were WTT or Hog, I might choose to make the same decision so as to be respectful of the possibility of changing consensus. JuxtaposedJacob (talk) | :) | he/him | 10:45, 16 December 2024 (UTC)[reply]
Option 2, for lack of a better choice. Banning re-RFAs is not a great idea, and we should not SNOW close a discussion that would give someone immunity from a certain degree of accountability. I've dropped an idea for an option 4 in the discussion section below. Giraffer (talk) 12:08, 16 December 2024 (UTC)[reply]
Option 1 I agree with Graham87 that these sorts of RFAs should only be done in exceptional circumstances, and BN is the best place to ask for tools back. – DreamRimmer (talk) 12:11, 16 December 2024 (UTC)[reply]
Option 2 I don't think prohibition makes sense. It also has weird side effects. eg: some admins' voluntary recall policies may now be completely void, because they would be unable to follow them even if they wanted to, because policy prohibits them from doing a RFA. (maybe if they're also 'under a cloud' it'd fit into exemptions, but if an admins' policy is "3 editors on this named list tell me I'm unfit, I resign" then this isn't really a cloud.) Personally, I think Hog Farm's RFA was unwise, as he's textbook uncontroversial. Worm's was a decent RFA; he's also textbook uncontroversial but it happened at a good time. But any editor participating in these discussions to give the "support" does so using their own time. Everyone who feels their time is wasted can choose to ignore the discussion, and instead it'll pass as 10-0-0 instead of 198-2-4. It just doesn't make sense to prohibit someone from seeking a community discussion, though. For almost anything, really. ProcrastinatingReader (talk) 12:33, 16 December 2024 (UTC)[reply]
Option 2 It takes like two seconds to support or ignore an RFA you think is "useless"... can't understand the hullabaloo around them. I stand by what I said on WTT's re-RFA regarding RFAs being about evaluating trustworthiness and accountability. Trustworthy people don't skip the process. —k6ka🍁 (Talk · Contributions) 15:24, 16 December 2024 (UTC)[reply]
2 is fine. Strong oppose to 1 and 3. Opposing option 1 because there is nothing wrong with asking for extra community feedback. opposing option 3 because once an RfA has been started, it should follow the standard rules. Note that RfAs are extremely rare and non-contentious RfAs require very little community time (unlike this RfC which seems a waste of community time, but there we are). —Kusma (talk) 16:59, 16 December 2024 (UTC)[reply]
2, with no opposition to 3. I see nothing wrong with a former administrator getting re-confirmed by the community, and community vetting seems like a good thing overall. If people think it's a waste of time, then just ignore the RfA. Natg 19 (talk) 17:56, 16 December 2024 (UTC)[reply]
No individual is wasting their time participating. Instead the person asking for a re-rfa is using tons of editor time by asking hundreds of people to vet them. Even the choice not to participate requires at least some time to figure out that this is not a new RfA; though at least in the two we've had recently it would require only as long as it takes to get to the RfA - for many a click from the watchlist and then another click into the rfa page - and to read the first couple of sentences of the self-nomination which isn't terribly long all things considered. Best, Barkeep49 (talk) 22:55, 16 December 2024 (UTC)[reply]
I agree with you (I think) that it's a matter of perspective. For me, clicking the RFA link in my watchlist and reading the first paragraph of Hog Farm's nomination (where they explained that they were already a respected admin) took me about 10 seconds. Ten seconds is nothing; in my opinion, this is just a nonissue. But then again, I'm not an admin, checkuser, or an oversighter. Maybe the time to read such a nomination is really wasting their time. I don't know. TheWikiToby (talk) 23:15, 16 December 2024 (UTC)[reply]
2. This reminds me of banning plastic straws (bear with me). Sure, I suppose in theory, that this is a burden on the community's time (just as straws do end up in landfills/the ocean). However, the amount of community time that is drained is minuscule compared to the amount of community time drained in countless, countless other fora and processes (just like the volume of plastic waste contributed by plastic straws is less than 0.001% of the total plastic waste). When WP becomes an efficient, well oiled machine, then maybe we can talk about saving community time by banning re-RFA's. But this is much ado about nothing, and indeed this plan to save people from themselves, and not allow them to simply decide whether to participate or not, is arguably more damaging than some re-RFAs (just as banning straws convinced some people that "these save-the-planet people are so ridiculous that I'm not going to bother listening to them about anything."). And, in fact, on a separate note, I'd actually love it if more admins just ran a re-RFA whenever they wanted. They would certainly get better feedback than just posting "What do my talk page watchers think?" on their own talk page. Or waiting until they get yelled at on their talk page, AN/ANI, AARV, etc. We say we want admins to respect feedback; does it have to be in a recall petition? --Floquenbeam (talk) 23:44, 16 December 2024 (UTC)[reply]
What meaningful feedback has Hog Farm gotten? "A minority of people think you choose poorly in choosing this process to regain adminship". What are they supposed to do with that? I share your desire for editors to share meaningful feedback with administrators. My own attempt yielded some, though mainly offwiki where I was told I was both too cautious and too impetuous (and despite the seeming contradiction each was valuable in its own way). So yes let's find ways to get meaningful feedback to admins outside of recall or being dragged to ANI. Unfortunately re-RfA seems to be poorly suited to the task and so we can likely find a better way. Best, Barkeep49 (talk) 03:38, 17 December 2024 (UTC)[reply]
No hard rule, but we should socially discourage confirmation RfAs There is a difference between a hard rule, and a soft social rule. A hard rule against confirmation RfA's, like option 1, would not do a good job of accounting for edge cases and would thus be ultimately detrimental here. But a soft social rule against them would be beneficial. Unfortunately, that is not one of the options of this RfC. In short, a person should have a good reason to do a confirmation RfA. If you're going to stand up before the community and ask "do you trust me," that should be for a good reason. It shouldn't just be because you want the approval of your peers. (Let me be clear: I am not suggesting that is why either Worm or Hogfarm re-upped, I'm just trying to create a general purpose rule here.) That takes some introspection and humility to ask yourself: is it worth me inviting two or three hundred people to spend part of their lives to comment on me as a person?A lot of people have thrown around editor time in their reasonings. Obviously, broad generalizations about it aren't convincing anyone. So let me just share my own experience. I saw the watchlist notice open that a new RfA was being run. I reacted with some excitement, because I always like seeing new admins. When I got to the page and saw Hogfarm's name, I immediately thought "isn't he already an admin?" I then assumed, ah, its just the classic RfA reaction at seeing a qualified candidate, so I'll probably support him since I already think he's an admin. But then as I started to do my due diligence and read, I saw that he really, truly, already had been an admin. At that point, my previous excitement turned to a certain unease. I had voted yes for Worm's confirmation RfA, but here was another...and I realized that my blind support for Worm might have been the start of an entirely new process. I then thought "bet there's an RfC going about this," and came here. I then spent a while polishing up my essay on editor time, before taking time to write this message. All in all, I probably spent a good hour doing this. Previously, I'd just been clicking the random article button and gnoming. So, the longwinded moral: yeah, this did eat up a lot of my editor time that could have and was being spent doing something else. And I'd do it again! It was important to do my research and to comment here. But in the future...maybe I won't react quite as excitedly to seeing that RfA notice. Maybe I'll feel a little pang of dread...wondering if its going to be a confirmation RfA. We can't pretend that confirmation RfA's are costless, and that we don't lose anything even if editors just ignore them. When run, it should be because they are necessary. CaptainEekEdits Ho Cap'n!⚓03:29, 17 December 2024 (UTC)[reply]
In short, a person should have a good reason to do a confirmation RfA. If you're going to stand up before the community and ask "do you trust me," that should be for a good reason. It shouldn't just be because you want the approval of your peers. Asking the community whether you still have their trust to be an administrator, which is what an reconfirmation RFA is, is a good reason. I expect getting a near-unanimous "yes" is good for one's ego, but that's just a (nice) side-effect of the far more important benefits to the entire community: a trusted administrator.
The time you claim is being eaten up unnecessarily by reconfirmation RFAs was actually taken up by you choosing to spend your time writing an essay about using time for things you don't approve of and then hunting out an RFC in which you wrote another short essay about using time on things you don't approve of. Absolutely none of that is a necessary consequence of reconfirmation RFAs - indeed the response consistent with your stated goals would have been to read the first two sentences of Hog Farm's RFA and then closed the tab and returned to whatever else it was you were doing. Thryduulf (talk) 09:16, 17 December 2024 (UTC)[reply]
WTT's and Hog Farm's RFAs would have been completely uncontentious, something I hope for at RfA and certainly the opposite of what I "dread" at RfA, if it were not for the people who attack the very concept of standing for RfA again despite policy being crystal clear that it is absolutely fine. I don't see how any blame for this situation can be put on WTT or HF. We can't pretend that dismissing uncontentious reconfirmation RfAs is costless; discouraging them removes one of the few remaining potentially wholesome bits about the process. —Kusma (talk) 09:53, 17 December 2024 (UTC)[reply]
@CaptainEek Would you find it better if Watchlist notices and similar said "(re?)confirmation RFA" instead of "RFA"? Say for all voluntary RFAs from an existing admin or someone who could have used BN?
As a different point, I would be quite against any social discouraging if we're not making a hard rule as such. Social discouraging is what got us the opposes at WTT/Hog Farm's RFAs, which I found quite distasteful and badgering. If people disagree with a process, they should change it. But if the process remains the same, I think it's important to not enable RFA's toxicity by encouraging others to namecall or re-argue the process in each RRFA. It's a short road from social discouragement to toxicity, unfortunately. Soni (talk) 18:41, 19 December 2024 (UTC)[reply]
Option 3 (which I think is a subset of option 2, so I'm okay with the status quo, but I want to endorse giving 'crats the option to SNOW). While they do come under scrutiny from time to time for the extensive dicsussions in the "maybe" zone following RfAs, this should be taken as an indiciation that they are unlikely to do something like close it as SNOW in the event there is real and substantial concerns being rasied. This is an okay tool to give the 'crats. As far as I can tell, no one has ever accused the them of moving too quickly in this direction (not criticism; love you all, keep up the good work). Bobby Cohn (talk) 17:26, 17 December 2024 (UTC)[reply]
Option 3 or Option 2. Further, if Option 2 passes, I expect it also ends all the bickering about lost community time. A consensus explicitly in favour of "This is allowed" should also be a consensus to discourage relitigation of this RFC. Soni (talk) 17:35, 17 December 2024 (UTC)[reply]
Option 2: Admins who do not exude entitlement are to be praised. Those who criticize this humility should have a look in the mirror before accusing those who ask for reanointment from the community of "arrogance". I agree that it wouldn't be a bad idea to mention in parentheses that the RFA is a reconfirmation (watchlist) and wouldn't see any problem with crats snow-closing after, say, 96 hours. -- SashiRolls 🌿 · 🍥18:48, 17 December 2024 (UTC)[reply]
I know. I see a sizable amount of commenters here starting to say that voluntary re-RfAs should be encouraged, and your first sentence can be easily read as implying that admins who use the BN route exude entitlement. I disagree with that (see my reply to Thryduulf below). Aaron Liu (talk) 12:56, 18 December 2024 (UTC)[reply]
One way to improve the reputation of RFA is for there to be more RFAs that are not terrible, such as reconfirmations of admins who are doing/have done a good job who sail through with many positive comments. There is no proposal to make RFA mandatory in circumstances it currently isn't, only to reaffirm that those who voluntarily choose RFA are entitled to do so. Thryduulf (talk) 21:06, 17 December 2024 (UTC)[reply]
I know it's not a proposal, but there's enough people talking about this so far that it could become a proposal. There's nearly nothing in between that could've lost the trust of the community. I'm sure there are many who do not want to be pressured into this without good reason. Aaron Liu (talk) 12:57, 18 December 2024 (UTC)[reply]
Absolutely nobody is proposing, suggesting or hinting here that reconfirmation RFAs should become mandatory - other than comments from a few people who oppose the idea of people voluntarily choosing to do something policy explicitly allows them to choose to do. The best way to avoid people being pressured into being accused of arrogance for seeking reconfirmation of their status from the community is to sanction those people who accuse people of arrogance in such circumstances as such comments are in flagrant breach of AGF and NPA. Thryduulf (talk) 14:56, 18 December 2024 (UTC)[reply]
Yes, I’m saying that they should not become preferred. There should be no social pressure to do RfA instead of BN, only pressure intrinsic to the candidate. Aaron Liu (talk) 15:37, 18 December 2024 (UTC)[reply]
Whether they should become preferred in any situation forms no part of this proposal in any way shape or form - this seeks only to reaffirm that they are permitted. A separate suggestion, completely independent of this one, is to encourage (explicitly not mandate) them in some (but explicitly not all) situations. All discussions on this topic would benefit if people stopped misrepresenting the policies and proposals - especially when the falsehoods have been explicitly called out. Thryduulf (talk) 15:49, 18 December 2024 (UTC)[reply]
I am talking and worrying over that separate proposal many here are suggesting. I don’t intend to oppose Option 2, and sorry if I came off that way. Aaron Liu (talk) 16:29, 18 December 2024 (UTC)[reply]
Option 2. In fact, I'm inclined to encourage an RRfA over BN, because nothing requires editors to participate in an RRfA, but the resulting discussion is better for reaffirming community consensus for the former admin or otherwise providing helpful feedback. --Pinchme123 (talk) 21:45, 17 December 2024 (UTC)[reply]
Option 2WP:RFA has said "Former administrators may seek reinstatement of their privileges through RfA..." for over ten years and this is not a problem. I liked the opportunity to be consulted in the current RfA and don't consider this a waste of time. Andrew🐉(talk) 22:14, 17 December 2024 (UTC)[reply]
2 - If an administrator gives up sysop access because they plan to be inactive for a while and want to minimize the attack surface of Wikipedia, they should be able to ask for permissions back the quickest way possible. If an administrator resigns because they do not intend to do the job anymore, and later changes their mind, they should request a community discussion. The right course of action depends on the situation. JehochmanTalk14:00, 18 December 2024 (UTC)[reply]
Option 1. I've watched a lot of RFAs and re-RFAs over the years. There's a darn good reason why the community developed the "go to BN" option: saves time, is straightforward, and if there are issues that point to a re-RFA, they're quickly surfaced. People who refuse to take the community-developed process of going to BN first are basically telling the community that they need the community's full attention on their quest to re-admin. Yes, there are those who may be directed to re-RFA by the bureaucrats, in which case, they have followed the community's carefully crafted process, and their re-RFA should be evaluated from that perspective. Risker (talk) 02:34, 19 December 2024 (UTC)[reply]
Option 2 (status quo/no changes) per meh. This is bureaucratic rulemongering at its finest. Every time RFA reform comes up some editors want admins to be required to periodically reconfirm, then when some admins decide to reconfirm voluntarily, suddenly that's seen as a bad thing. The correct thing to do here is nothing. If you don't like voluntary reconfirmation RFAs, you are not required to participate in them. Ivanvector (Talk/Edits) 19:34, 19 December 2024 (UTC)[reply]
Option 2 I would probably counsel just going to BN most of the time, however there are exceptions and edge cases. To this point these RfAs have been few in number, so the costs incurred are relatively minor. If the number becomes large then it might be worth revisiting, but I don't see that as likely. Some people will probably impose social costs on those who start them by opposing these RfAs, with the usual result, but that doesn't really change the overall analysis. Perhaps it would be better if our idiosyncratic internal logic didn't produce such outcomes, but that's a separate issue and frankly not really worth fighting over either. There's probably some meta issues here I'm unaware off, it's long since I've had my finger on the community pulse so to speak, but they tend to matter far less than people think they do. 184.152.68.190 (talk) 02:28, 20 December 2024 (UTC)[reply]
Option 1, per WP:POINT, WP:NOT#SOCIALNETWORK, WP:NOT#BUREAUCRACY, WP:NOTABOUTYOU, and related principles. We all have far better things to do that read through and argue in/about a totally unnecessary RfA invoked as a "Show me some love!" abuse of process and waste of community time and productivity. I could live with option 3, if option 1 doesn't fly (i.e. shut these silly things down as quickly as possible). But option 2 is just out of the question. — SMcCandlish☏¢ 😼 04:28, 22 December 2024 (UTC)[reply]
Except none of the re-RFAs complained about have been RfA invoked as a "Show me some love!" abuse of process, you're arguing against a strawman. Thryduulf (talk) 11:41, 22 December 2024 (UTC)[reply]
It's entirely a matter of opinion and perception, or A) this RfC wouldn't exist, and B) various of your fellow admins like TonyBallioni would not have come to the same conclusion I have. Whether the underlying intent (which no one can determine, lacking as we do any magical mind-reading powers) is solely egotistical is ultimately irrelevant. The actual effect (what matters) of doing this whether for attention, or because you've somehow confused yourself into think it needs to be done, is precisely the same: a showy waste of community volunteers' time with no result other than a bunch of attention being drawn to a particular editor and their deeds, without any actual need for the community to engage in a lengthy formal process to re-examine them. — SMcCandlish☏¢ 😼 05:49, 23 December 2024 (UTC)[reply]
or because you've somehow confused yourself into think it needs to be done
Option 2. I see no legitimate reason why we should be changing the status quo. Sure, some former admins might find it easier to go through BN, and it might save community time, and most former admins already choose the easier option. However, if a candidate last ran for adminship several years ago, or if issues were raised during their tenure as admin, then it may be helpful for them to ask for community feedback, anyway. There is no "wasted" community time in such a case. I really don't get the claims that this violates WP:POINT, because it really doesn't apply when a former admin last ran for adminship 10 or 20 years ago or wants to know if they still have community trust.On the other hand, if an editor thinks a re-RFA is a waste of community time, they can simply choose not to participate in that RFA. Opposing individual candidates' re-RFAs based solely on opposition to re-RFAs in general is a violation of WP:POINT. – Epicgenius (talk) 14:46, 22 December 2024 (UTC)[reply]
There have been lots of re-RFAs, historically. There were more common in the 2000s. Evercat in 2003 is the earliest I can find, back before the re-sysopping system had been worked out fully. Croat Canuck back in 2007 was snow-closed after one day, because the nominator and applicant didn't know that they could have gone to the bureaucrats' noticeboard. For more modern examples, HJ Mitchell (2011) is relatively similar to the recent re-RFAs in the sense that the admin resigned uncontroversially but chose to re-RFA before getting the tools back. Immediately following and inspired by HJ Mitchell's, there was the slightly more controversial SarekOfVulcan. That ended successful re-RFAS until 2019's Floquenbeam, which crat-chatted. Since then, there have been none that I remember. There have been several re-RFAs from admins who were de-sysopped or at serious risk of de-sysopping, and a few interesting edge cases such as the potentially optional yet no-consensus SarekVulcan 3 in 2014 and the Rich Farmbrough case in 2015, but those are very different than what we're talking about today. GreenLipstickLesbian (talk) 00:01, 23 December 2024 (UTC)[reply]
Well thank you both, I've learned something new today. It turns out I was working on a false assumption. It has just been so long since a re-RfA that I assumed it was a truly new phenomenon, especially since there were two in short succession. I still can't say I'm thrilled by the process and think it should be used sparingly, but perhaps I was a bit over concerned. CaptainEekEdits Ho Cap'n!⚓16:47, 23 December 2024 (UTC)[reply]
Option 2 or 3 per Gnoming and CaptainEek. Such RfAs only require at most 30 seconds for one to decide whether or not to spend their time on examination. Unlike other prohibited timesinks, it's not like something undesirable will happen if one does not sink their time. Voluntary reconfirmation RfAs are socially discouraged, so there is usually a very good reason for someone to go back there, such as accountability for past statements in the case of WTT or large disputes during adminship in the case of Hog Farm. I don't think we should outright deny these, and there is no disruption incurred if we don't. Aaron Liu (talk) 15:44, 23 December 2024 (UTC)[reply]
Option 2 (fine with better labeling) These don't seem harmful to me and, if I don't have time, I'll skip one and trust the judgment of my fellow editors. No objection to better labeling them though, as discussed above. RevelationDirect (talk) 22:36, 23 December 2024 (UTC)[reply]
Option 1 because it's just a waste of time to go through and !vote on candidates who just want the mop restored when he or she or they could get it restored BN with no problems. But I can also see option 2 being good for a former mod not in good standing. Therapyisgood (talk) 23:05, 23 December 2024 (UTC)[reply]
Option 2 Just because someone may be entitled to get the bit back doesn't mean they necessarily should. Look at my RFA3. I did not resign under a cloud, so I could have gotten the bit back by request. However, the RFA established that I did not have the community support at that point, so it was a good thing that I chose that path. I don't particularly support option 3, but I could deal with it. --SarekOfVulcan (talk)16:05, 27 December 2024 (UTC)[reply]
Option 1 Asking hundreds of people to vet a candidate who has already passed a RfA and is eligible to get the tools back at BN is a waste of the community's time. -- Pawnkingthree (talk) 16:21, 27 December 2024 (UTC)[reply]
Option 2 I really don't think there's a problem that needs to be fixed here. I am grateful at least a couple administrators have asked for the support of the community recently. SportingFlyerT·C00:12, 29 December 2024 (UTC)[reply]
Option 2. Keep the status quo of any editor is free to re-request the tools through the requests for adminship process. Voluntary RfA are rare enough not to be a problem, it's not as though we are overburdened with RfAs. And it’s my time to waste. --Malcolmxl5 (talk) 17:58, 7 January 2025 (UTC)[reply]
Option 2 or Option 3. These are unlikely to happen anyway, it's not like they're going to become a trend. I'm already wasting my time here instead of other more important activities anyway, so what's a little more time spent giving an easy support?fanfanboy(blocktalk)16:39, 10 January 2025 (UTC)[reply]
Option 1 Agree with Daniel Quinlan that for the problematic editors eligible for re-sysop at BN despite unpopularity, we should rely on our new process of admin recall, rather than pre-emptive RRFAs. I'll add the novel argument that when goliaths like Hog Farm unnecessarily showcase their achievements at RFA, it scares off nonetheless qualified candidates. ViridianPenguin 🐧 ( 💬 ) 17:39, 14 January 2025 (UTC)[reply]
@Voorts: If option 2 gets consensus how would this RfC change the wording Regardless of the process by which the admin tools are removed, any editor is free to re-request the tools through the requests for adminship process. Or is this an attempt to see if that option no longer has consensus? If so why wasn't alternative wording proposed? As I noted above this feels premature in multiple ways. Best, Barkeep49 (talk) 21:43, 15 December 2024 (UTC)[reply]
I've re-opened this per a request on my talk page. If other editors think this is premature, they can !vote accordingly and an uninvolved closer can determine if there's consensus for an early close in deference to the VPI discussion. voorts (talk/contributions) 21:53, 15 December 2024 (UTC)[reply]
The discussion at VPI, which I have replied on, seems to me to be different enough from this discussion that both can run concurrently. That is, however, my opinion as a mere editor. — Jkudlick ⚓ (talk)22:01, 15 December 2024 (UTC)[reply]
@Voorts, can you please reword the RfC to make it clear that Option 2 is the current consensus version? It does not need to be clarified – it already says precisely what you propose. – bradv22:02, 15 December 2024 (UTC)[reply]
Question: May someone clarify why many view such confirmation RfAs as a waste of community time? No editor is obligated to take up their time and participate. If there's nothing to discuss, then there's no friction or dis-cussing, and the RfA smooth-sails; if a problem is identified, then there was a good reason to go to RfA. I'm sure I'm missing something here. Aaron Liu (talk) 22:35, 15 December 2024 (UTC)[reply]
The intent of RfA is to provide a comprehensive review of a candidate for adminship, to make sure that they meet the community's standards. Is that happening with vanity re-RfAs? Absolutely not, because these people don't need that level of vetting. I wouldn't consider a week long, publicly advertized back patting to be a productive use of volunteer time. -- Ajraddatz (talk) 23:33, 15 December 2024 (UTC)[reply]
Sure, but that logic could be used to justify any time sink. We're all volunteers and nobody is forced to do anything here, but that doesn't mean that we should promote (or stay silent with our criticism of, I suppose) things that we feel don't serve a useful purpose. I don't think this is a huge deal myself, but we've got two in a short period of time and I'd prefer to do a bit of push back now before they get more common. -- Ajraddatz (talk) 01:52, 16 December 2024 (UTC)[reply]
Except someone who has no need for advanced tools and is not going to use them in any useful fashion, would then skate through with nary a word said about their unsuitability, regardless of the foregone conclusion. The point of RFA is not to rubber-stamp. Unless their is some actual issue or genuine concern they might not get their tools back, they should just re-request them at BN and stop wasting people's time with pointless non-process wonkery. Only in death does duty end (talk) 09:05, 16 December 2024 (UTC)[reply]
I’m confused. Adminship requires continued use of the tools. If you think they’s suitable for BN, I don’t see how doing an RfA suddenly makes them unsuitable. If you have concerns, raise them. Aaron Liu (talk) 13:02, 16 December 2024 (UTC)[reply]
I don't think the suggested problem (which I acknowledge not everyone thinks is a problem) is resolved by these options. Admins can still run a re-confirmation RfA after regaining adminsitrative privileges, or even initiate a recall petition. I think as discussed on Barkeep49's talk page, we want to encourage former admins who are unsure if they continue to be trusted by the community at a sufficient level to explore lower cost ways of determining this. isaacl (talk) 00:32, 16 December 2024 (UTC)[reply]
In re the idea that RfAs use up a lot of community time: I first started editing Wikipedia in 2014. There were 62 RfAs that year, which was a historic low. Even counting all of the AElect candidates as separate RfAs, including those withdrawn before voting began, we're still up to only 53 in 2024 – counting only traditional RfAs it's only 18, which is the second lowest number ever. By my count we've has 8 resysop requests at BN in 2024; even if all of those went to RfA, I don't see how that would overwhelm the community. That would still leave us on 26 traditional RfAs per year, or (assuming all of them run the full week) one every other week. Caeciliusinhorto-public (talk) 10:26, 16 December 2024 (UTC)[reply]
What about an option 4 encouraging eligible candidates to go through BN? At the end of the Procedure section, add something like "Eligible users are encouraged to use this method rather than running a new request for adminship." The current wording makes re-RfAing sound like a plausible alternative to a BN request, when in actual fact the former rarely happens and always generates criticism. Giraffer (talk) 12:08, 16 December 2024 (UTC)[reply]
Discouraging RFAs is the second last thing we should be doing (after prohibiting them), rather per my comments here and in the VPI discussion we should be encouraging former administrators to demonstrate that they still have the approval of the community. Thryduulf (talk) 12:16, 16 December 2024 (UTC)[reply]
I think this is a good idea if people do decide to go with option 2, if only to stave off any further mixed messages that people are doing something wrong or rude or time-wasting or whatever by doing a second RfA, when it's explicitly mentioned as a valid thing for them to do. Gnomingstuff (talk) 15:04, 16 December 2024 (UTC)[reply]
If RFA is explicitly a valid thing for people to do (which it is, and is being reaffirmed by the growing consensus for option 2) then we don't need to (and shouldn't) discourage people from using that option. The mixed messages can be staved off by people simply not making comments that explicitly contradict policy. Thryduulf (talk) 15:30, 16 December 2024 (UTC)[reply]
This is not new. We've had sporadic "vanity" RfAs since the early days of the process. I don't believe they're particularly harmful, and think that it unlikely that we will begin to see so many of them that they pose a problem. As such I don't think this policy proposal solves any problem we actually have. UninvitedCompany21:56, 16 December 2024 (UTC)[reply]
This apparent negative feeling evoked at an RFA for a former sysop everyone agrees is fully qualified and trusted certainly will put a bad taste in the mouths of other former admins who might consider a reconfirmation RFA without first visiting BN. This comes in the wake of Worm That Turned's similar rerun. BusterD (talk) 23:29, 16 December 2024 (UTC)[reply]
I went looking for @Tamzin's comment because I know they had hung up the tools and came back, and I was interested in their perspective. But they've given me a different epiphany. I suddenly realize why people are doing confirmation RfAs: it's because of RECALL, and the one year immunity a successful RfA gives you. Maybe everyone else already figured that one out and is thinking "well duh Eek," but I guess I hadn't :) I'm not exactly sure what to do with that epiphany, besides note the emergent behavior that policy change can create. We managed to generate an entirely new process without writing a single word about it, and that's honestly impressive :P CaptainEekEdits Ho Cap'n!⚓18:18, 17 December 2024 (UTC)[reply]
Worm That Turned followed through on a pledge he made in January 2024, before the 2024 review of the request for adminship process began. I don't think a pattern can be extrapolated from a sample size of one (or even two). That being said, it's probably a good thing if admins occasionally take stock of whether or not they continue to hold the trust of the community. As I previously commented, it would be great if these admins would use a lower cost way of sampling the community's opinion. isaacl (talk) 18:31, 17 December 2024 (UTC)[reply]
If people decide to go through a community vote to get a one year immunity from a process that only might lead to a community vote which would then have a lower threshold then the one they decide to go through, and also give a year's immunity, then good for them. CMD (talk) 01:05, 22 December 2024 (UTC)[reply]
@CaptainEek I'm mildly bothered by this comment, mildly because I assume it's lighthearted and non-serious. But just in case anyone does feel this way - I was very clear about my reasons for RRFA, I've written a lot about it, anyone is welcome to use my personal recall process without prejudice, and just to be super clear - I waive my "1 year immunity" - if someone wants to start a petition in the next year, do not use my RRfA as a reason not to. I'll update my userpage accordingly. I can't speak for Hog Farm, but his reasoning seems similar to mine, and immunity isn't it. WormTT(talk) 10:28, 23 December 2024 (UTC)[reply]
@Worm That Turned my quickly written comment was perhaps not as clear as it could have been :) I'm sorry, I didn't mean to suggest that y'all had run for dubious reasons. As I said in my !vote, Let me be clear: I am not suggesting that is why either Worm or Hogfarm re-upped, I'm just trying to create a general purpose rule here. I guess what I really meant was that the reason that we're having this somewhat spirited conversation seems to be the sense that re-RfA could provide a protection from recall. If not for recall and the one year immunity period, I doubt we'd have cared so much as to suddenly run two discussions about this. CaptainEekEdits Ho Cap'n!⚓16:59, 23 December 2024 (UTC)[reply]
I don't agree. No one else has raised a concern about someone seeking a one-year respite from a recall petition. Personally, I think essentially self-initiating the recall process doesn't really fit the profile of someone who wants to avoid the recall process. (I could invent some nefarious hypothetical situation, but since opening an arbitration case is still a possibility, I don't think it would work out as planned.) isaacl (talk) 05:19, 24 December 2024 (UTC)[reply]
I really don't think this is the reason behind WTT's and HF's reconfirmation RFA's. I don't think their RFA's had much utility and could have been avoided, but I don't doubt for a second that their motivations were anything other than trying to provide transparency and accountability for the community. BugGhost🦗👻12:04, 23 December 2024 (UTC)[reply]
I don't really care enough about reconf RFAs to think they should be restricted, but what about a lighter ORCP-like process (maybe even in the same place) where fewer editors can indicate, "yeah OK, there aren't really any concerns here, it would probably save a bit of time if you just asked at BN". Alpha3031 (t • c) 12:40, 19 December 2024 (UTC)[reply]
Can someone accurately describe for me what the status quo is? I reread this RfC twice now and am having a hard time figuring out what the current state of affairs is, and how the proposed alternatives will change them. Duly signed,⛵ WaltClipper-(talk)14:42, 13 January 2025 (UTC)[reply]
Option 2 is the status quo. The goal of the RFC is to see if the community wants to prohibit reconfirmation RFAs (option 1). The idea is that reconfirmation RFAs take up a lot more community time than a BN request so are unnecessary. There were 2 reconfirmation RFAs recently after a long dry spell. –Novem Linguae (talk) 20:49, 13 January 2025 (UTC)[reply]
The status quo, documented at Wikipedia:Administrators#Restoration of admin tools, is that admins who resigned without being under controversy can seek readminship through either BN (where it's usually given at the discreetion of an arbitrary bureaucrat according to the section I linked) or RfA (where all normal RfA procedures apply, and you see a bunch of people saying "the candidate's wasting the community's time and could've uncontroversially gotten adminship back at BN instead). Aaron Liu (talk) 12:27, 14 January 2025 (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.
Using AI to write your comments in a discussion makes it difficult for others to assume that you are discussing in good faith, rather than trying to use AI to argue someone into exhaustion (see example of someone using AI in their replies "Because I don't have time to argue with, in my humble opinion, stupid PHOQUING people"). More fundamentally, WP:AGF can't apply to the AI itself as AI lacks intentionality, and it is difficult for editors to assess how much of an AI-generated comment reflects the training of the AI vs. the actual thoughts of the editor.
No. As with all the other concurrent discussions (how many times do we actually need to discuss the exact same FUD and scaremongering?) the problem is not AI, but rather inappropriate use of AI. What we need to do is to (better) explain what we actually want to see in discussions, not vaguely defined bans of swathes of technology that, used properly, can aid communication. Thryduulf (talk) 01:23, 2 January 2025 (UTC)[reply]
Note that this topic is discussing using AI to generate replies, as opposed to using it as an aid (e.g. asking it to edit for grammar, or conciseness). As the above concurrent discussion demonstrates, users are already using AI to generate their replies in AfD, so it isn't scaremongering but an actual issue.
WP:DGF also does not ban anything ("Showing good faith is not required"), but offers general advice on demonstrating good faith. So it seems like the most relevant place to include mention of the community's concerns regarding AI-generated comments, without outright banning anything. Photos of Japan (talk) 01:32, 2 January 2025 (UTC)[reply]
And as pointed out, multiple times in those discussions, different people understand different things from the phrase "AI-generated". The community's concern is not AI-generated comments, but comments that do not clearly and constructively contribute to a discussion - some such comments are AI-generated, some are not. This proposal would, just as all the other related ones, cause actual harm when editors falsely accuse others of using AI (and this will happen). Thryduulf (talk) 02:34, 2 January 2025 (UTC)[reply]
Nobody signed up to argue with bots here. If you're pasting someone else's comment into a prompt and asking the chatbot to argue against that comment and just posting it in here, that's a real problema and absolutely should not be acceptable. :bloodofox: (talk) 03:31, 2 January 2025 (UTC)[reply]
Thank you for the assumption of bad faith and demonstrating one of my points about the harm caused. Nobody is forcing you to engage with bad-faith comments, but whether something is or is not bad faith needs to be determined by its content not by its method of generation. Simply using an AI demonstrates neither good faith nor bad faith. Thryduulf (talk) 04:36, 2 January 2025 (UTC)[reply]
I'm one of those people who clarified the difference between AI-generated vs. edited, and such a difference could be made explicit with a note. Editors are already accusing others of using AI. Could you clarify how you think addressing AI in WP:DGF would cause actual harm? Photos of Japan (talk) 04:29, 2 January 2025 (UTC)[reply]
By encouraging editors to accuse others of using AI, by encouraging editors to dismiss or ignore comments because they suspect that they are AI-generated rather than engaging with them. @Bloodofox has already encouraged others to ignore my arguments in this discussion because they suspect I might be using an LLM and/or be a bot (for the record I'm neither). Thryduulf (talk) 04:33, 2 January 2025 (UTC)[reply]
Given your relentlessly pro-AI comments here, it seems that you'd be A-OK with just chatting with a group of chatbots here — or leaving the discussion to them. However, most of us clearly are not. In fact, I would immediately tell someone to get lost were it confirmed that indeed that is what is happening. I'm a human being and find the notion of wasting my time with chatbots on Wikipedia to be incredibly insulting and offensive. :bloodofox: (talk) 04:38, 2 January 2025 (UTC)[reply]
Funny, you've done nothing here but argue for more generative AI on the site and now you seem to be arguing to let chatbots run rampant on it while mocking anyone who doesn't want to interface with chatbots on Wikipedia. Hey, why not just sell the site to Meta, am I right? :bloodofox: (talk) 04:53, 2 January 2025 (UTC)[reply]
I haven't been arguing for more generative AI on the site. I've been arguing against banning it on the grounds that such a ban would be unclear, unenforceable, wouldn't solve any problems (largely because whether something is AI or not is completely irrelevant to the matter at hand) but would instead cause harm. Some of the issues identified are actual problems, but AI is not the cause of them and banning AI won't fix them.
I'm not mocking anybody, nor am I advocating to let chatbots run rampant. I'm utterly confused why you think I might advocate for selling Wikipedia to Meta (or anyone else for that matter)? Are you actually reading anything I'm writing? You clearly are not understanding it. Thryduulf (talk) 05:01, 2 January 2025 (UTC)[reply]
So we're now in 'everyone else is the problem, not me!' territory now? Perhaps try communicating in a different way because your responses here are looking very much like the typical AI apologetics one can encounter on just about any contemporary LinkedIn thread from your typical FAANG employee. :bloodofox: (talk) 05:13, 2 January 2025 (UTC)[reply]
No, this is not a everyone else is the problem, not me issue because most other people appear to be able to understand my arguments and respond to them appropriately. Not everybody agrees with them, but that's not an issue.
I'm not familiar with Linkedin threads (I don't use that platform) nor what a "FAANG employee" is (I've literally never heard the term before now) so I have no idea whether your characterisation is a compliment or a personal attack, but given your comments towards me and others you disagree with elsewhere I suspect it's closer to the latter.
AI is a tool. Just like any other tool it can be used in good faith or in bad faith, it can be used well and it can be used badly, it can be used in appropriate situations and it can be used in inappropriate situations, the results of using the tool can be good and the results of using the tool can be bad. Banning the tool inevitably bans the good results as well as the bad results but doesn't address the reasons why the results were good or bad and so does not resolve the actual issue that led to the bad outcomes. Thryduulf (talk) 12:09, 2 January 2025 (UTC)[reply]
In the context of generating comments to other users though, AI is much easier to use for bad faith than for good faith. LLMs don't understand Wikipedia's policies and norms, and so are hard to utilize to generate posts that productively address them. By contrast, bad actors can easily use LLMs to make low quality posts to waste people's time or wear them down.
In the context of generating images, or text for articles, it's easy to see how the vast majority of users using AI for those purposes is acting in good faith as these are generally constructive tasks, and most people making bad faith changes to articles are either obvious vandals who won't bother to use AI because they'll be reverted soon anyways, or trying to be subtle (povpushers) in which case they tend to want to carefully write their own text into the article.
It's true that AI "is just a tool", but when that tool is much easier to use for bad faith purposes (in the context of discussions) then it raises suspicions about why people are using it. Photos of Japan (talk) 22:44, 2 January 2025 (UTC)[reply]
LLMs don't understand Wikipedia's policies and norms They're not designed to "understand" them since the policies and norms were designed for human cognition. The fact that AI is used rampantly by people acting in bad faith on Wikipedia does not inherently condemn the AI. To me, it shows that it's too easy for vandals to access and do damage on Wikipedia. Unfortunately, the type of vetting required to prevent that at the source would also potentially require eliminating IP-editing, which won't happen. Duly signed,⛵ WaltClipper-(talk)14:33, 15 January 2025 (UTC)[reply]
You mentioned "FUD". That acronym, "fear, uncertainty and doubt," is used in precisely two contexts: pro-AI propagadizing and persuading people who hold memecoin crypto to continue holding it. Since this discussion is not about memecoin crypto that would suggest you are using it in a pro-AI context. I will note, fear, uncertainty and doubt is not my problem with AI. Rather it's anger, aesthetic disgust and feeling disrespected when somebody makes me talk to their chatbot. Simonm223 (talk) 14:15, 14 January 2025 (UTC)[reply]
That acronym, "fear, uncertainty and doubt," is used in precisely two contexts is simply
FUD both predates AI by many decades (my father introduced me to the term in the context of the phrase "nobody got fired for buying IBM", and the context of that was mainframe computer systems in the 1980s if not earlier. FUD is also used in many, many more contexts that just those two you list, including examples by those opposing the use of AI on Wikipedia in these very discussions. Thryduulf (talk) 14:47, 14 January 2025 (UTC)[reply]
That acronym, "fear, uncertainty and doubt," is used in precisely two contexts is factually incorrect.
FUD both predates AI by many decades (indeed if you'd bothered to read the fear, uncertainty and doubt article you'd learn that the concept was first recorded in 1693, the exact formulation dates from at least the 1920s and the use of it in technology concepts originated in 1975 in the context of mainframe computer systems. That its use, eve in just AI contexts, is limited to pro-AI advocacy is ludicrous (even ignoring things like Roko's basilisk), examples can be found in these sprawling discussions from those opposing AI use on Wikipedia. Thryduulf (talk) 14:52, 14 January 2025 (UTC)[reply]
Not really – I agree with Thryduulf's arguments on this one. Using AI to help tweak or summarize or "enhance" replies is of course not bad faith – the person is trying hard. Maybe English is their second language. Even for replies 100% AI-generated the user may be an ESL speaker struggling to remember the right words (I always forget 90% of my French vocabulary when writing anything in French, for example). In this case, I don't think we should make a blanket assumption that using AI to generate comments is not showing good faith. Cremastra (u — c) 02:35, 2 January 2025 (UTC)[reply]
Yes because generating walls of text is not good faith. People "touching up" their comments is also bad (for starters, if you lack the English competency to write your statements in the first place, you probably lack the competency to tell if your meaning has been preserved or not). Exactly what AGF should say needs work, but something needs to be said, and AGFDGF is a good place to do it. XOR'easter (talk) 02:56, 2 January 2025 (UTC)[reply]
Not all walls of text are generated by AI, not all AI generated comments are walls of text. Not everybody who uses AI to touch up their comments lacks the competencies you describe, not everybody who does lack those competencies uses AI. It is not always possible to tell which comments have been generated by AI and which have not. This proposal is not particularly relevant to the problems you describe. Thryduulf (talk) 03:01, 2 January 2025 (UTC)[reply]
Someone has to ask: Are you generating all of these pro-AI arguments using ChatGPT? It'd explain a lot. If so, I'll happily ignore any and all of your contributions, and I'd advise anyone else to do the same. We're not here to be flooded with LLM-derived responses. :bloodofox: (talk) 03:27, 2 January 2025 (UTC)[reply]
That you can't tell whether my comments are AI-generated or not is one of the fundamental problems with these proposals. For the record they aren't, nor are they pro-AI - they're simply anti throwing out babies with bathwater. Thryduulf (talk) 04:25, 2 January 2025 (UTC)[reply]
I'd say it also illustrates the serious danger: We can no longer be sure that we're even talking to other people here, which is probably the most notable shift in the history of Wikipedia. :bloodofox: (talk) 04:34, 2 January 2025 (UTC)[reply]
How is that a "serious danger"? If a comment makes a good point, why does it matter whether ti was AI generated or not? If it doesn't make a good point, why does it matter if it was AI generated or not? How will these proposals resolve that "danger"? How will they be enforceable? Thryduulf (talk) 04:39, 2 January 2025 (UTC)[reply]
Wikipedia is made for people, by people, and I like most people will be incredibly offended to find that we're just playing some kind of LLM pong with a chatbot of your choice. You can't be serious. :bloodofox: (talk) 04:40, 2 January 2025 (UTC)[reply]
"why does it matter if it was AI generated or not?"
Because it takes little effort to post a lengthy, low quality AI-generated post, and a lot of effort for human editors to write up replies debunking them.
"How will they be enforceable? "
WP:DGF isn't meant to be enforced. It's meant to explain to people how they can demonstrate good faith. Posting replies to people (who took the time to write them) that are obviously AI-generated harms the ability of those people to assume good faith. Photos of Japan (talk) 05:16, 2 January 2025 (UTC)[reply]
The linked "example of someone using AI in their replies" appears – to me – to be a non-AI-generated comment. I think I preferred the allegedly AI-generated comments from that user (example). The AI was at least superficially polite. WhatamIdoing (talk) 04:27, 2 January 2025 (UTC)[reply]
Obviously the person screaming in all caps that they use AI because they don't want to waste their time arguing is not using AI for that comment. Their first post calls for the article to be deleted for not "offering new insights or advancing scholarly understanding" and "merely" reiterating what other sources have written.
Yes, after a human had wasted their time explaining all the things wrong with its first post, then the bot was able to write a second post which looks ok. Except it only superficially looks ok, it doesn't actually accurately describe the articles. Photos of Japan (talk) 04:59, 2 January 2025 (UTC)[reply]
Multiple humans have demonstrated in these discussions that humans are equally capable of writing posts which superficially look OK but don't actually accurately relate to anything they are responding to. Thryduulf (talk) 05:03, 2 January 2025 (UTC)[reply]
But I can assume that everyone here is acting in good faith. I can't assume good faith in the globally-locked sock puppet spamming AfD discussions with low effort posts, whose bot is just saying whatever it can to argue for the deletion of political pages the editor doesn't like. Photos of Japan (talk) 05:09, 2 January 2025 (UTC)[reply]
True, but I think that has more to do with the "globally-locked sock puppet spamming AfD discussions" part than with the "some of it might be [AI-generated]" part. WhatamIdoing (talk) 07:54, 2 January 2025 (UTC)[reply]
All of which was discovered because of my suspicions from their inhuman, and meaningless replies. "Reiteration isn't the problem; redundancy is," maybe sounds pithy in a vacuum, but this was written in reply to me stating that we aren't supposed to be doing OR but reiterating what the sources say.
"Your criticism feels overly prescriptive, as though you're evaluating this as an academic essay" also sounds good, until you realize that the bot is actually criticizing its own original post.
The fact that my suspicions about their good faith were ultimately validated only makes it even harder for me to assume good faith in users who sound like ChatGPT. Photos of Japan (talk) 08:33, 2 January 2025 (UTC)[reply]
I wonder if we need some other language here. I can understand feeling like this is a bad interaction. There's no sense that the person cares; there's no feeling like this is a true interaction. A contract lawyer would say that there's no meeting of the minds, and there can't be, because there's no mind in the AI, and the human copying from the AI doesn't seem to be interested in engaging their brain.
The user's talk page has a header at the top asking people not to template them because it is "impersonal and disrespectful", instead requesting "please take a moment to write a comment below in your own words"
Does this look like acting in good faith to you? Requesting other people write personalized responses to them while they respond with an LLM? Because it looks to me like they are trying to waste other people's time. Photos of Japan (talk) 09:35, 2 January 2025 (UTC)[reply]
"Being hypocritical" in the abstract isn't the problem, it's the fact that asking people to put effort into their comments, while putting in minimal effort into your own comments appears bad faith, especially when said person says they don't want to waste time writing comments to stupid people. The fact you are arguing AGF for this person is both astounding and disappointing. Photos of Japan (talk) 16:08, 3 January 2025 (UTC)[reply]
It feels like there is a lack of reciprocity in the interaction, even leaving aside the concern that the account is a block-evading sock.
But I wonder if you have read AGF recently. The first sentence is "Assuming good faith (AGF) means assuming that people are not deliberately trying to hurt Wikipedia, even when their actions are harmful."
So we've got some of this (e.g., harmful actions). But do you really believe this person woke up in the morning and decided "My main goal for today is to deliberately hurt Wikipedia. I might not be successful, but I sure am going to try hard to reach my goal"? WhatamIdoing (talk) 23:17, 4 January 2025 (UTC)[reply]
Trying to hurt Wikipedia doesn't mean they have to literally think "I am trying to hurt Wikipedia", it can mean a range of things, such as "I am trying to troll Wikipedians". A person who thinks a cabal of editors is guarding an article page, and that they need to harass them off the site, may think they are improving Wikipedia, but at the least I wouldn't say that they are acting in good faith. Photos of Japan (talk) 23:27, 4 January 2025 (UTC)[reply]
In my mind, they are related inasmuch as it is much more difficult for me to ascertain good faith if the words are eminently not written by the person I am speaking to in large part, but instead generated based on an unknown prompt in what is likely a small fraction of the expected time. To be frank, in many situations it is difficult to avoid the conclusion that the disparity in effort is being leveraged in something less than good faith. Remsense ‥ 论05:02, 2 January 2025 (UTC)[reply]
Assume good faith, don't ascertain! Llm use can be deeply unhelpful for discussions and the potential for mis-use is large, but the most recent discussion I've been involved with where I observed an llm post was responded to by an llm post, I believe both the users were doing this in good faith. CMD (talk) 05:07, 2 January 2025 (UTC)[reply]
All I mean to say is it should be licit that unhelpful LLM use should be something that can be mentioned like any other unhelpful rhetorical pattern. Remsense ‥ 论05:09, 2 January 2025 (UTC)[reply]
The fact that everyone (myself included) defending "LLM use" says "use" rather than "generated", is a pretty clear sign that no one really wants to communicate with someone using "LLM generated" comments. We can argue about bans (not being proposed here), how to know if someone is using LLM, the nuances of "LLM use", etc., but at the very least we should be able to agree that there are concerns with LLM generated replies, and if we can agree that there are concerns then we should be able to agree that somewhere in policy we should be able to find a place to express those concerns. Photos of Japan (talk) 05:38, 2 January 2025 (UTC)[reply]
For instance, I am OK with someone using a LLM to post a productive comment on a talk page. I am also OK with someone generating a reply with a LLM that is a productive comment to post to a talk page. I am not OK with someone generating text with an LLM to include in an article, and also not OK with someone using a LLM to contribute to an article.
Most people already assume good faith in those making productive contributions. In situations where good faith is more difficult to assume, would you trust someone who uses an LLM to generate all of their comments as much as someone who doesn't? Photos of Japan (talk) 09:11, 2 January 2025 (UTC)[reply]
Given that LLM-use is completely irrelevant to the faith in which a user contributes, yes. Of course what amount that actually is may be anywhere between completely and none. Thryduulf (talk) 11:59, 2 January 2025 (UTC)[reply]
LLM-use is relevant as it allows bad faith users to disrupt the encyclopedia with minimal effort. Such a user posted in this thread earlier, as well as started a disruptive thread here and posted here, all using AI. I had previously been involved in a debate with another sock puppet of theirs, but at that time they didn't use AI. Now it seems they are switching to using an LLM just to troll with minimal effort. Photos of Japan (talk) 21:44, 2 January 2025 (UTC)[reply]
LLMs are a tool that can be used by good and bad faith users alike. Using an LLM tells you nothing about whether a user is contributing in good or bad faith. If somebody is trolling they can be, and should be, blocked for trolling regardless of the specifics of how they are trolling. Thryduulf (talk) 21:56, 2 January 2025 (UTC)[reply]
A can of spray paint, a kitchen knife, etc., are tools that can be used for good or bad, but if you bring them some place where they have few good uses and many bad uses then people will be suspicious about why you brought them. You can't just assume that a tool in any context is equally harmless. Using AI to generate replies to other editors is more suspicious than using it to generate a picture exemplifying a fashion style, or a description of a physics concept. Photos of Japan (talk) 23:09, 2 January 2025 (UTC)[reply]
WP:AGF is not a death pact though. At times you should be suspicious. Do you think that if a user, who you already have suspicions of, is also using an LLM to generate their comments, that that doesn't have any effect on those suspicions? Photos of Japan (talk) 21:44, 2 January 2025 (UTC)[reply]
So… If you suspect that someone is not arguing in good faith… just stop engaging them. If they are creating walls of text but not making policy based arguments, they can be ignored. Resist the urge to respond to every comment… it isn’t necessary to “have the last word”. Blueboar (talk) 21:57, 2 January 2025 (UTC)[reply]
That they've been banned for disruption indicates we can do everything we need to do to deal with bad faith users of LLMs without assuming that everyone using an LLM is doing so in bad faith. Thryduulf (talk) 00:33, 3 January 2025 (UTC)[reply]
No -- whatever you think of LLMs, the reason they are so popular is that the people who use them earnestly believe they are useful. Claiming otherwise is divorced from reality. Even people who add hallucinated bullshit to articles are usually well-intentioned (if wrong). Gnomingstuff (talk) 06:17, 2 January 2025 (UTC)[reply]
Yes I find it incredibly rude for someone to procedurally generate text and then expect others to engage with it as if they were actually saying something themselves. Simonm223 (talk) 14:34, 2 January 2025 (UTC)[reply]
I could support general advice that if you're using machine translation or an LLM to help you write your comments, it can be helpful to mention this in the message. The tone to take, though, should be "so people won't be mad at you if it screwed up the comment" instead of "because you're an immoral and possibly criminal person if you do this". WhatamIdoing (talk) 07:57, 3 January 2025 (UTC)[reply]
No. When someone publishes something under their own name, they are incorporating it as their own statement. Plagiarism from an AI or elsewhere is irrelevant to whether they are engaging in good faith. lethargilistic (talk) 17:29, 2 January 2025 (UTC)[reply]
Comment LLMs know a few tricks about logical fallacies and some general ways of arguing (rhetoric), but they are incredibly dumb at understanding the rules of Wikipedia. You can usually tell this because it looks like incredibly slick and professional prose, but somehow it cannot get even the simplest points about the policies and guidelines of Wikipedia. I would indef such users for lacking WP:CIR. tgeorgescu (talk) 17:39, 2 January 2025 (UTC)[reply]
That guideline states "Sanctions such as blocks and bans are always considered a last resort where all other avenues of correcting problems have been tried and have failed." Gnomingstuff (talk) 19:44, 2 January 2025 (UTC)[reply]
I blocked that user as NOTHERE a few minutes ago after seeing them (using ChatGPT) make suggestions for text to live pagespace while their previous bad behaviors were under discussion. AGF is not a suicide pact. BusterD (talk) 20:56, 2 January 2025 (UTC)[reply]
... but somehow it cannot get even the simplest points about the policies and guidelines of Wikipedia: That problem existed with some humans even prior to LLMs. —Bagumba (talk) 02:53, 20 January 2025 (UTC)[reply]
Yes Using a 3rd party service to contribute to the Wikipedia on your behalf is clearly bad-faith, analogous to paying someone to write your article. Zaathras (talk) 14:39, 3 January 2025 (UTC)[reply]
Its a stretch to say that a newbie writing a comment using AI is automatically acting in bad faith and not here to build an encyclopedia. PackMecEng (talk) 16:55, 3 January 2025 (UTC)[reply]
Comment Large language model AI like Chat GPT are in their infancy. The culture hasn't finished its initial reaction to them yet. I suggest that any proposal made here have an automatic expiration/required rediscussion date two years after closing. Darkfrog24 (talk) 22:42, 3 January 2025 (UTC)[reply]
No – It is a matter of how you use AI. I use Google translate to add trans-title parameters to citations, but I am careful to check for Google's output making for good English as well as reflecting the foreign title when it is a language I somewhat understand. I like to think that I am careful, and I do not pretend to be fluent in a language I am not familiar with, although I usually don't announce the source of such a translation. If an editor uses AI profligately and without understanding the material generated, then that is the sin; not AI itself. Dhtwiki (talk) 05:04, 5 January 2025 (UTC)[reply]
There's a legal phrase, "when the exception swallows the rule", and I think we might be headed there with the recent LLM/AI discussions.
We start off by saying "Let's completely ban it!" Then in discussion we add "Oh, except for this very reasonable thing... and that reasonable thing... and nobody actually meant this other reasonable thing..."
Do you want us to reply to you, because you are a human? Or are you just posting the output of an LLM without bothering to read anything yourself? DS (talk) 06:08, 7 January 2025 (UTC)[reply]
Most likely you would reply because someone posted a valid comment and you are assuming they are acting in good faith and taking responsibility for what they post. To assume otherwise is kind of weird and not inline with general Wikipedia values. PackMecEng (talk) 15:19, 8 January 2025 (UTC)[reply]
No The OP seems to misunderstand WP:DGF which is not aimed at weak editors but instead exhorts stronger editors to lead by example. That section already seems to overload the primary point of WP:AGF and adding mention of AI would be quite inappropriate per WP:CREEP. Andrew🐉(talk) 23:11, 5 January 2025 (UTC)[reply]
Yes. AI use is not a demonstration of bad faith (in any case not every new good-faith editor is familiar with our AI policies), but it is equally not a "demonstration of good faith", which is what the WP:DGF section is about.
It seems some editors are missing the point and !voting as if every edit is either a demonstration of good faith or bad faith. Most interactions are neutral and so is most AI use, but I find it hard to imagine a situation where AI use would point away from unfamiliarity and incompetence (in the CIR sense), and it often (unintentionally) leads to a presumption of laziness and open disinterest. It makes perfect sense to recommend against it. DaßWölf22:56, 9 January 2025 (UTC)[reply]
Indeed most kinds of actions don't inherently demonstrate good or bad. The circumspect and neutral observation that AI use is not a demonstration of bad faith... but it is equally not a "demonstration of good faith", does not justify a proposal to one-sidedly say just half. And among all the actions that don't necessarily demonstrate good faith (and don't necessarily demonstrate bad faith either), it is not the purpose of "demonstrate good faith" and the broader guideline, to single out one kind of action to especially mention negatively. Adumbrativus (talk) 04:40, 13 January 2025 (UTC)[reply]
Yes. Per Dass Wolf, though I would say passing off a completely AI-generated comment as your own anywhere is inherently bad-faith and one doesn't need to know Wiki policies to understand that. JoelleJay (talk) 23:30, 9 January 2025 (UTC)[reply]
Yes. Sure, LLMs may have utility somewhere, and it might be a crutch for people unfamiliar with English, but as I've said above in the other AI RfC, that's a competence issue. This is about comments eating up editor time, energy, about LLMs easily being used to ram through changes and poke at editors in good standing. I don't see a case wherein a prospective editor's command of policy and language is good enough to discuss with other editors while being bad enough to require LLM use. Iseult Δx talk to me01:26, 10 January 2025 (UTC)[reply]
No - anyone using a washing machine to wash their clothes must be evil and inherently lazy. They cannot be trusted. ... Oh, sorry, wrong century. Regards, --Goldsztajn (talk) 01:31, 10 January 2025 (UTC)[reply]
No - As long as a person understands (and knows) what they are talking about, we shouldn't discriminate against folks using generative AI tech for grammar fixes or minor flow improvements. Yes, AI can create walls of text, and make arguments not grounded in policy, but we could do that even without resorting to generative AI. Sohom (talk) 11:24, 13 January 2025 (UTC)[reply]
To expand on my point above. Completely AI generated comments (or articles) are obviously bad, but using AI should be thrown into the same cross-hairs as completely AI generated comments. Sohom (talk) 11:35, 13 January 2025 (UTC)[reply]
No. Don't make any changes. It's not a good faith/bad faith issue. The 'yes' arguments are most unconvincing with very bizarre analogies to make their point. Here, I can make one too: "Don't edit with AI; you wouldn't shoot your neighbor's dog with a BB-gun, would you?" Duly signed,⛵ WaltClipper-(talk)14:43, 13 January 2025 (UTC)[reply]
Extended content
I appreciate your concern about the use of AI in discussions. It is important to be mindful of how AI is used, and to ensure that it is used in a way that is respectful of others.
I don't think that WP:DGF should be amended to specifically mention AI. However, I do think that it is important to be aware of the potential for AI to be used in a way that is not in good faith.
When using AI, it is important to be transparent about it. Let others know that you are using AI, and explain how you are using it. This will help to build trust and ensure that others understand that you are not trying to deceive them.
It is also important to be mindful of the limitations of AI. AI is not a perfect tool, and it can sometimes generate biased or inaccurate results. Be sure to review and edit any AI-generated content before you post it.
Finally, it is important to remember that AI is just a tool. It is up to you to use it in a way that is respectful and ethical. |} It's easy to detect for most, can be pointed out as needed. No need to add an extra policy JayCubby
While I have no issue with the direction the linked discussion has taken, I agree with almost every contributor there: As a practice I have zero interest in generally allowing random editors closing outside their permissions. It might make DRV a more chatty board, granted. BusterD (talk) 15:02, 7 January 2025 (UTC)[reply]
Tamzin makes a reasonable case in their comment below. When we have already chosen to trust certain editors with advanced permissions, we might allow those folks to utilize them as fully as accepted practice allows. Those humans already have skin in the game. They are unlikely to act rashly. BusterD (talk) 19:32, 7 January 2025 (UTC)[reply]
To me, non-admin delete closes at any XfD have always seemed inconsistent with what we say about how adminship and discussion closing work. I would be in violation of admin policy if I deleted based on someone else's close without conducting a full review myself, in which case, what was the point of their close? It's entirely redundant to my own work. That said, I can't really articulate a reason that this should be allowed at some XfDs but not others, and it seems to have gone fine at CfD and TfD. I guess call me neutral. What I'd be more open to is allowing page movers to do this. Page movers do have the tools to turn a bluelink red, so it doesn't create the same admin accountability issue if I'm just cleaning up the stray page left over from a page mover's use of a tool that they were duly granted and subject to their own accountability rules for. We could let them move a redirect to some other plausible title (this would violate WP:MOVEREDIRECT as currently written but I think I'd be okay with making this a canonical exception), and/or allow moving to some draftspace or userspace page and tagging for G6, as we do with {{db-moved}}. I'll note that when I was a non-admin pagemover, I did close a few things as delete where some edge case applied that let me effect the deletion using only suppressredirect, and no one ever objected. -- Tamzin[cetacean needed] (they|xe|🤷) 19:07, 7 January 2025 (UTC)[reply]
I see that I was sort of vague, which is consistent with the statement that I hinted at allowing non-admin delete closures. My main concern is that I would like to see our guidelines and our practice made consistent, either by changing the guidelines or changing the practice. It appears that there is a rough consensus emerging that non-admin delete closures should continue to be disallowed in RFD, but that CFD may be a special case. So what I am saying is that if, in practice, we allow non-admin Delete closures at CFD, the guideline should say something vague to that effect.
I also see that there is a consensus that DRV can endorse irregular non-admin closures, including irregular non-admin Delete closures. Specifically, it isn't necessary for DRV to vacate the closure for an uninvolved admin to close. A consensus at DRV, some of whose editors will be uninvolved admins, is at least as good a close as a normal close by an uninvolved admin.
Also, maybe we need clearer guidance about non-admin Keep closures of AFDs. I think that if an editor is not sure whether they have sufficient experience to be closing AFDs as Keep, they don't have enough experience. I think that the guidance is clear enough in saying that administrator accountability applies to non-admin closes, but maybe it needs to be further strengthened, because at DRV we sometimes deal with non-admin closes where the closer doesn't respond to inquiries, or is rude in response to them.
Also, maybe we need clearer guidance about non-admin No Consensus closures of AFDs. In particular, a close of No Consensus is a contentious closure, and should either be left to an admin, or should be Relisted.
As for I can't really articulate a reason that this should be allowed at some XfDs, the argument is that more work is needed to enact closures at TfD and CfD (namely orphaning templates and emptying/moving/merging categories). Those extra steps aren't present at RfD. At most, there are times when it's appropriate to unlink the redirect or add WP:RCATs but those are automated steps that WP:XFDC handles. From my limited experience at TfD and CfD though, it does seem that the extra work needed at closure does not compensate for the extra work from needing two people reviewing the closure (especially at CfD because a bot that handles the clean-up). Consistency has come up and I would much rather consistently disallow non-admin delete closures at all XfD venues. I know it's tempting for non-admins to think they're helping by enacting these closures but it's not fair for them to be spinning their wheels. As for moving redirects, that's even messier than deleting them. There's a reason that WP:MOVEREDIRECT advises not to move redirects except for limited cases when preserving history is important. --Tavix(talk)20:16, 7 January 2025 (UTC)[reply]
@Tamzin: I do have one objection to this point of redundancy, which you are quite familiar with. Here, an AfD was closed as "transwiki and delete", however, the admin who did the closure does not have the technical ability to transwiki pages to the English Wikibooks, meaning that I, who does, had to determine that the outcome was actually to transwiki rather than blindly accepting a request at b:WB:RFI. Then, I had to mark the pages for G6 deletion, that way an admin, in this case you, could determine that the page was ready to be deleted. Does this mean that that admin who closed the discussion shouldn't have closed it, since they only have the technical ability to delete, not transwiki? Could I have closed it, having the technical ability to transwiki, but not delete? Either way, someone else would have had to review it. Or, should only people who have importing rights on the target wiki and admin rights on the English Wikipedia be allowed to close discussions as "transwiki and delete"? JJPMaster (she/they) 12:04, 8 January 2025 (UTC)[reply]
I do support being explicit when a non-administrator can close a discussion as "delete" and I think that explicitly extending to RfD and CfD is appropriate. First, there can be a backlog in both of these areas and there are often few comments in each discussion (and there is usually not the same passion as in an AfD). Second, the delete close of a non-administrator is reviewed by an administrator before action is taken to delete the link, or category (a delete close is a two-step process, the writeup and the delete action, so in theory the administrators workload is reduced). Third, non-admins do face administrator accountability for their actions, and can be subject to sanction. Fourth, the community has a role in reviewing closing decisions at DRV, so there is already a process in place to check a unexperienced editor or poor close. Finally, with many, if not most discussions for deletion the outcome is largely straight forward. --Enos733 (talk) 20:01, 7 January 2025 (UTC)[reply]
There is currently no rule against non-admin delete closures as far as I know; the issue is the practical one that you don't have the ability to delete. However, I have made non-admin delete closures at AfD. This occurred when an admin deleted the article under consideration (usually for COPYVIO) without closing the related AfD. The closures were not controversial and there was no DRV. Hawkeye7(discuss)20:31, 7 January 2025 (UTC)[reply]
The situation you're referring to is an exception allowed per WP:NACD: If an administrator has deleted a page (including by speedy deletion) but neglected to close the discussion, anyone with a registered account may close the discussion provided that the administrator's name and deletion summary are included in the closing rationale. --Tavix(talk)20:37, 7 January 2025 (UTC)[reply]
Bad idea to allow, this sort of closure is just busy work, that imposes more work on the admin that then has to review the arguments, close and then delete. Graeme Bartlett (talk) 22:05, 7 January 2025 (UTC)[reply]
(1) As I've also noted in the other discussion, the deletion process guidelines at WP:NACD do say non-admins shouldn't do "delete" closures and do recognize exceptions for CfD and TfD. There isn't a current inconsistency there between guidelines and practice. (2) In circumstances where we do allow for non-admin "delete" closures, I would hope that the implementing admin isn't fully reviewing the discussion de novo before implementing, but rather giving deference to any reasonable closure. That's how it goes with requested move closers asking for technical help implementing a "moved" closure at WP:RM/TR (as noted at WP:RMNAC, the closure will "generally be respected by the administrator (or page mover)" but can be reverted by an admin if "clearly improper"). SilverLocust💬08:41, 9 January 2025 (UTC)[reply]
Comment - A couple things to note about the CFD process: It very much requires work by admins. The non-admin notes info about the close at WT:CFD/Working, and then an admin enters the info on the CFD/Working page (which is protected) so that the bot can perform the various actions. Remember that altering a category is potentially more labour intensive than merely editing or deleting a single page - every page in that category must be edited, and then the category deleted. (There are other technical things involved, like the mess that template transclusion can cause, but let's keep it simple.) So I wouldn't suggest that that process is very useful as a precedent for anything here. It was done at a time when there was a bit of a backlog at CfD, and this was a solution some found to address that. Also - since then, I think at least one of the regular non-admin closers there is now an admin. So there is that as well. - jc3709:14, 9 January 2025 (UTC)[reply]
If the expectation is that an admin needs to review the deletion discussion to ensure they agree with that outcome before deleting via G6, as multiple people here are suggesting, then I'm not sure this is worthwhile. However, I have had many admins delete pages I've tagged with G6, and I have been assuming that they only check that the discussion was indeed closed as delete, and trust the closer to be responsible for the correctness of it. This approach makes sense to me, because if a non-admin is competent to close and be responsible for any other outcome of a discussion, I don't see any compelling reason they can't be responsible for a delete outcome and close accordingly. —Compassionate727(T·C)19:51, 9 January 2025 (UTC)[reply]
Some closers, and you're among them, have closing accuracy similar to many sysops. But the sysop can't/shouldn't "trust" that your close is accurate. Trustworthy though you are, the sysop must, at very minimum, check firstly that the close with your signature on it was actually made by you (signatures are easily copied), secondly that the close wasn't manifestly unreasonable, and thirdly that the CSD is correct. WP:DRV holds the deleting sysop responsible for checking that the CSD were correctly applied. G6 is for uncontroversial deletions, and if there's been an XFD, then it's only "uncontroversial" if the XFD was unanimous or nearly so. We do have sysops who'll G6 without checking carefully, but they shouldn't. Basically, non-admin closing XFDs doesn't save very much sysop time. I think that if your motive as a non-admin is to relieve sysops of labour, the place you're of most use is at RfC.—S MarshallT/C11:28, 12 January 2025 (UTC)[reply]
if your motive as a non-admin is to relieve sysops of labour, the place you're of most use is at RfC alternatively you should consider becoming an administrator yourself. Thryduulf (talk) 13:20, 12 January 2025 (UTC)[reply]
In all the cases I have dealt with, the admin's reason for deletion (usually copyvio) was completely different to the issues being debated in the AfD (usually notability). The closing statement was therefore something like "Discussion is now moot due to article being deleted for <reason> by <admin>". Hawkeye7(discuss)20:10, 14 January 2025 (UTC)[reply]
I think most all the time, experienced closers will do a great job and that will save admin time because they will not have to construct and explain the close from scratch, but there will be some that are bad and that will be costly in time not just for the admin but for the project's goal of completing these issues and avoiding disruption. I think that lost time is still too costly, so I would oppose non-admin delete closes. (Now if there were a proposal for a process to make a "delete-only admin permission" that would be good -- such motivated specialists would likely be more efficient.) Alanscottwalker (talk) 16:44, 12 January 2025 (UTC)[reply]
As I said at the "Non-Admin XFD Close as Delete" section, I support non-admins closing RfDs as Delete. If TfDs have been made an exception, RfDs can be too, especially considering RfD backlogs. Closing a heavily discussed nomination at RfD is more about the reading, analysis and thought process at arriving at the outcome, and less about the technicality of the subsequent page actions. I don't see a significant difference between non-admins closing discussions as Delete vs non-Delete. It will help making non-admins mentally prepared to advance to admin roles. Jay 💬14:53, 14 January 2025 (UTC)[reply]
The backlog at RFD is mostly lack of participation, not lack of admins not making closures. This would only be exacerbated if non-admins are given a reason not to !vote on discussions trending toward deletion so they can get the opportunity to close. RFD isn't as technical as CFD and TFD. In any case, any admin doing the deletion would still have to review the RFD. Except in the most obviously trivial cases, this will lead to duplicate work, and even where it doesn't (e.g. multiple !votes all in one direction), the value-add is minimal.
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.
i quit this will go no where im extremely embarassed and feel horrible i dont think ill try again
I would like to start this proposal by saying that this concept was a proposal in 2009 which failed for obvious reasons. But in this year, 2025, we need it as its happened a bunch. its already under personal attacks but this I feel and a couple other Wikipedians that it should be codified as their is precedent for blocking users who discriminate. Here’s a list of the things I want to include in this policy. edit: This policy is intended to target blatant and admitted instances of discrimination. If the intent behind an action is ambiguous, users should continue to assume good until the intent is.
Just as being a member of a group does not give one special requirements to edit, it also does not endow any special privileges.[a] One is not absolved of discrimination against a group just because one claims to be a member of that group.
Im aware that this never really happens but its good to go over
A user may not claim without evidence that a user is affected by/are any of the above (idk how to term this).
A user may not claim that users with these disabilities/beliefs/races/genders shouldn’t edit Wikipedia.
A user may not imply a user is below them based on the person.
calling people woke simply cause they are queer is discrimination.
Also I would like to propose a condition.
Over reaction to what you think is discrimination (accidental misgendering and wrong pronouns) and the user apologizes for it is not grounds for an entry at ani.
This should be used as a guideline.
discrimination is defined as acts, practices, or policies that wrongfully impose a relative disadvantage or deprivation on persons based on their membership in a salient social group. This is a comparative definition. An individual need not be actually harmed in order to be discriminated against. He or she just needs to be treated worse than others for some arbitrary reason. If someone decides to donate to help orphan children, but decides to donate less, say, to children of a particular race out of a racist attitude, he or she will be acting in a discriminatory way even if he or she actually benefits the people he discriminates against by donating some money to them.
Wikipedia article on discrimination
I would also like to say this would give us negative press coverage by right wing media and I’ll receive shit. But I don’t care i can deal with it •Cyberwolf•talk?16:37, 16 January 2025 (UTC)[reply]
This largely seems like behavior that already is sanctionable per WP:NPA and WP:UCOC (and the adoption of the latter drew complaints at the time that it in itself was already unnecessarily redundant with existing civility policy on en.wiki). What shortcomings do you see with those existing bodies of policy en force? signed, Rosguilltalk16:45, 16 January 2025 (UTC)[reply]
The fact that punishments should be a little more severe for users who go after a whole group of editors. As its not an npa its an attack on a group •Cyberwolf•talk?16:57, 16 January 2025 (UTC)[reply]
NPA violations are already routinely met with blocks and sitebans, often on sight without prior warning for the level of disparagement you're describing. Do you have any recent examples on hand of cases where the community's response was insufficiently severe? signed, Rosguilltalk17:07, 16 January 2025 (UTC)[reply]
Noting that I've now taken the time to read through the three cases listed at the top--two of them ended in NOTHERE blocks pretty quickly--I could see someone taking issue with the community's handling of RowanElder and Jwa05002, although it does seem that the discussion ultimately resulted in an indef block for one and an apparently sincere apology from the other. signed, Rosguilltalk17:13, 16 January 2025 (UTC)[reply]
I think the real problem is that in order to block for any reason you have to take them to a place where random editors discuss whether they are a "net positive" or "net negative" to the wiki, which in principle would be a fair way to decide, but in reality is like the work of opening an RFC just in order to get someone to stop saying random racist stuff, and it's not worth it. Besides, remember the RSP discussion where the Daily Mail couldn't be agreed to be declared unreliable on transgender topics because "being 'gender critical' is a valid opinion" according to about half the people there? I've seen comments that were blatant bigoted insults beneath a thin veneer, that people did not take to ANI because it's just not worth the huge amount of effort. There really needs to be an easy way for administrators to warn (on first violation) and then block people who harass people in discriminatory ways without a huge and exhausting-for-the-complainer "discussion" about it -- and a very clear policy that says discrimination is not OK and is always "net negative" for the encyclopedia would reduce the complexity of that discussion, and I think is an important statement to make.
By allowing it to be exhaustively debated whether thinly-veiled homophobic insults towards gay people warrant banning is Wikipedia deliberately choosing not to take a stance on the topic. A stance needs to be taken, and it needs to be clear enough to allow rapid and decisive action that makes people actually afraid to discriminate against other editors, because they know that it isn't tolerated, rather than being reasonably confident their targets won't undergo another exhausting ANI discussion. Mrfoogles (talk) 17:04, 16 January 2025 (UTC)[reply]
I agree that a blind eye shouldn't be turned against discrimination against groups of Wikipedia editors in general, but I don't see why we need a list that doesn't include social class but includes hobbies. The determining factor for deciding whether something is discrimination should be how much choice the individual has in the matter, which seems, in practice, to be the way WP:NPA is used. Phil Bridger (talk) 17:02, 16 January 2025 (UTC)[reply]
I agree hobbies doesn't need to be included. Haven't seen a lot of discrimination based on social class? I think this needs to be taken to the Idea Lab. Mrfoogles (talk) 17:06, 16 January 2025 (UTC)[reply]
@cyberwolf Strong support in general (see above) but I strongly suggest you take this to the idea lab, because it's not written as a clear and exact proposal and it would probably benefit a lot from being developed into an RFC before taking it here. In the current format it probably can't pass because it doesn't make specific changes to policy. Mrfoogles (talk) 17:08, 16 January 2025 (UTC)[reply]
Wait...does this mean I won't be able to discriminate against people whose hobby is editing Wikipedia? Where's the fun in that? Anonymous17:09, 16 January 2025 (UTC)[reply]
In general, I fail to see the problem this is solving. The UCoC and other policies/guidelines/essays (such as WP:NPA, WP:FOC, and others) already prohibit discriminatory behavior. And normal conduct processes already have the ability to lay down the strictest punishment theoretically possible - an indefinite ban - for anyone who engages in such behavior.
I do not like the idea of what amounts to bureaucracy for bureaucracy’s sake. That is the best way I can put it. At worst, this is virtue signaling - it’s waving a flag saying “hey, public and editors, Wikipedia cares about discrimination so much we made a specific policy about it” - without even saying the next part “but our existing policies already get people who discriminate against other editors banned, so this was not necessary and a waste of time”. I’ll happily admit I’m proven wrong if someone can show evidence of a case where actual discrimination was not acted upon because people were “concerned” it wasn’t violating one of those other policies. -bɜ:ʳkənhɪmez | me | talk to me!20:56, 16 January 2025 (UTC)[reply]
To clarify, all the comments about "why is this included" or "why is this not included" are part of the reason I'm against a specific policy like this. Any disruption can be handled by normal processes, and a specific policy will lead to wikilawyering over what is or is not discrimination. There is no need to try to define/specifically treat discrimination when all discriminatory behaviors are adequately covered by other policies already. -bɜ:ʳkənhɪmez | me | talk to me!22:27, 16 January 2025 (UTC)[reply]
We should be relating to other editors in a kind way. But this proposal appears to make the editing environment more hostile with more blocking on the opinion of one person. We do discrimonate against those that use Wikipedia for wrong purposes, such as vandalism, or advertising. Pushing a particular point of view is more grey area. The proposal by cyberwolf is partly point of view that many others would disagree with. So we should concentrate policies on how a user relates to other editors, rather than their motivations or opinions. Graeme Bartlett (talk) 20:50, 16 January 2025 (UTC)[reply]
I think this is valuable by setting a redline for a certain sort of personal attack and saying, "this is a line nobody is permitted to cross while participating in this project." Simonm223 (talk) 20:57, 16 January 2025 (UTC)[reply]
It is not possible for the content of a discussion to be "discriminatory". Discrimination is action, not speech. This proposal looks like an attempt to limit discourse to a certain point of view. That's not a good idea. --Trovatore (talk) 21:13, 16 January 2025 (UTC)[reply]
Cambridge says that discrimination is : "treating a person or particular group of people differently, especially in a worse way from the way in which you treat other people, because of their race, gender, sexuality, etc".
OK, look, I'll concede part of the point here. Yes, if I'm a dick to (name of group) but not to (name of other group), I suppose that is discrimination, but I don't think a discrimination policy is a particularly useful tool for this, because what I should do is not be a dick to anybody.
What I'm concerned about is that the policy would be used to assert that certain content is discriminatory. Say someone says, here's a reliable source that says biological sex is real and has important social consequences, and someone else says, you can't bring that up, it's discriminatory. Well, no, that's a category error. That sort of thing can't be discriminatory. --Trovatore (talk) 01:29, 17 January 2025 (UTC)[reply]
The examples you use show that we've been dealing effectively without this additional set of guidelines; it would be more convincing that something was needed if you had examples where the lack of this policy caused bad outcomes. And I can see it being used as a hammer; while we're probably picturing "as a White man, I'm sure that I understand chemistry better than any of you lesser types" as what we're going after, I can see some folks trying to wield it against "as a Comanche raised on the Comanche nation, I think I have some insights on the Comanche language that others here are overlooking." As such, I'm cautious. -- Nat Gertler (talk) 21:49, 16 January 2025 (UTC)[reply]
Not needed. Everything the proposal is talking about would constitute disruptive behavior, and we can block or ban someone for being disruptive already. No need to break disruption down into its component parts, and write rules for each. Blueboar (talk) 22:07, 16 January 2025 (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.
Repeated false retirement
There is a user (who shall remain unnamed) who has "retired" twice and had the template removed from their page by other users because they were clearly still editing. They are now on their third "retirement", yet they last edited a few days ago. I don't see any policy formally prohibiting such behavior, but it seems extremely unhelpful for obvious reasons. Anonymous17:13, 16 January 2025 (UTC)[reply]
Unless the material is harmful to Wikipedia or other users, users have considerable leeway in what they may post on their user page. Personally, I always take "retirement" notices with a grain of salt. If a user wants to claim they are retired even though they are still actively editing, I don't see the harm to anything but their credibility. If I want to know if an editor is currently active, I look at their contributions, not at notices on their user or talk page. Donald Albury22:07, 16 January 2025 (UTC)[reply]
I can't imagine that this calls for a policy. You're allowed to be annoyed if you want. No one can take that away from you. But I'm missing an explanation of why the rest of us should care. --Trovatore (talk) 22:13, 16 January 2025 (UTC)[reply]
This seems a little prickly, my friend. Clearly, the other two users who removed older retirement notices cared. At the end of the day, it's definitely not the most major thing, but it is helpful to have a reliable and simple indication as to whether or not a user can be expected to respond to any kind of communication or feedback. I'm not going to die on this hill. Cheers. Anonymous22:41, 16 January 2025 (UTC)[reply]
A "retirement notice" from a Wikipedia editor is approximately as credible as a "retirement notice" from a famous rock and roll band. Ignore it. Cullen328 (talk) 03:01, 20 January 2025 (UTC)[reply]
FWIW, those two other editors were in the wrong to edit another person's user page for this kind of thing. And the retired banner does indicate: don't expect a quick response, even if I made an edit a few days or even minutes ago, as I may not be around much. Valereee (talk) 12:28, 20 January 2025 (UTC)[reply]
I think it's kind of rude to edit someone else's user page unless there is an extreme reason, like reversing vandalism or something. On Wikipedia:User pages I don't see anything about retirement templates, but i do see it say "In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask." If someone wants to identify as retired but sometimes drop by and edit, that doesn't seem to hurt anything. GeogSage (⚔Chat?⚔) 03:56, 20 January 2025 (UTC)[reply]
Wikipedia is WP:NOTCOMPULSORY, so even a "non-retired" editor might never edit again. And if someone is "retired" but still constructively edits, just consider that a bonus. What's more problematic is a petulant editor who "retires", but returns and edits disruptively; in such case, it's their disruptive behavior that would be the issue, not a trivial retirement notice. —Bagumba (talk) 07:42, 20 January 2025 (UTC)[reply]
As far as Wikipedia is concerned it's just another userbox you can put on your userpage. We only remove userboxes and userspace material if they're claiming to have a right that they don't (ie. a user with an Administrator toolbox who isn't an admin). Retirement is not an official term defined in policy anywhere, and being retired confers no special status. Pinguinn🐧11:13, 20 January 2025 (UTC)[reply]
If you see a retirement template that seems to be false you could post a message on the user talk page to ask if they are really retired. I suppose it could be just a tiny bit disruptive if we cannot believe such templates, but nowhere near enough to warrant sanctions or a change in policy. Phil Bridger (talk) 13:39, 20 January 2025 (UTC)[reply]
What is the purpose of banning?
In thinking about a recent banned user's request to be unblocked, I've been reading WP:Blocking policy and WP:Banning policy trying to better understand the differences. In particular, I'm trying to better understand what criteria should be applied when deciding whether to end a sanction.
One thing that stuck me is that for blocks, we explicitly say Blocks are used to prevent damage or disruption to Wikipedia, not to punish users. The implication being that a user should be unblocked if we're convinced they no longer present a threat of damage or disruption. No such statement exists for bans, which implies that bans are be a form of punishment. If that's the case, then the criteria should not just be "we think they'll behave themselves now", but "we think they've endured sufficiently onerous punishment to atone for their misbehavior", which is a fundamentally different thing.
My understanding (feel free to correct me if I am wrong) is that blocks are made by individual admins, and may be lifted by an admin (noting that CU blocks should only be lifted after clearance by a CU), while bans are imposed by ARBCOM or the community and require ARBCOM or community discussion to lift. Whether block or ban, a restriction on editing should only be imposed when it is the opinion of the admin, or ARBCOM, or the community, that such restriction is necessary to protect the encyclopedia from further harm or disruption. I thinks bans carry the implication that there is less chance that the banned editor will be able to successfully return to editing than is the case for blocked editors, but that is not a punishment, it is a determination of what is needed to protect WP in the future. Donald Albury16:44, 20 January 2025 (UTC)[reply]
Good question. I'm interested in what ban evasion sources think about current policies, people who have created multiple accounts, been processed at SPI multiple times, made substantial numbers of edits, the majority of which are usually preserved by the community in practice for complicated reasons (a form of reward in my view - the community sends ban evading actors very mixed messages). What's their perspective on blocks and bans and how to reduce evasion? It is not easy to get this kind of information unfortunately as people who evade bans and blocks are not very chatty it seems. But I have a little bit of data from one source for interest, Irtapil. Here are a couple of views from the other side.
On socking - "automatic second chance after first offense with a 2 week ban / block, needs to be easier than making a third one so people don't get stuck in the loop"
On encouraging better conduct - "they need to gently restrict people, not shun and obliterate"
No comment on the merits of these views, or whether punishment is what is actually happening, or is required, or effective, but it seems clear that it is likely to be perceived as punishment and counterproductive (perhaps unsurprisingly) by some affected parties. Sean.hoyland (talk) 17:31, 20 January 2025 (UTC)[reply]
Blocks are a sanction authorized by the community to be placed by administrators on their own initiative, for specific violations as described by a policy, guideline, or arbitration remedy (in which case the community authorization is via the delegated authority to the arbitration committee). Blocks can also be placed to enforce an editing restriction. A ban is an editing restriction. As described on the banning policy page, it is a formal prohibition from editing some or all pages on the English Wikipedia, or a formal prohibition from making certain types of edits on Wikipedia pages. Bans can be imposed for a specified or an indefinite duration. Aside from cases where the community has delegated authority to admins to enact bans on their own initiative, either through community authorization of discretionary sanctions, or arbitration committee designated contentious topics, editing restrictions are authorized through community discussion. They cover cases where there isn't a single specific violation for which blocking is authorized by guidance/arbitration remedy, and so a pattern of behaviour and the specific circumstances of the situation have to be discussed and a community consensus established.
Historically, removing blocks and bans require a consensus from the authorizing party that removing it will be beneficial to the project. Generally, the community doesn't like to impose editing restrictions when there is promise for improved behaviour, so they're enacted for more severe cases of poor behaviour. Thus it's not unusual that the community is somewhat skeptical about lifting recently enacted restrictions (where "recent" can vary based on the degree of poor behaviour and the views of each community member). Personally I don't think this means an atonement period should be mandated. isaacl (talk) 18:33, 20 January 2025 (UTC)[reply]
I think that a block is a preventive measure, whereas a ban is where the community's reached a consensus to uninvite a particular person from the site. Wikipedia is the site that anyone can edit, except for a few people we've decided we can't or won't work with. A ban is imposed by a sysop on behalf of the community whereas a block is imposed on their own authority.—S MarshallT/C19:39, 20 January 2025 (UTC)[reply]
Seems to be addressed in WP:BMB, which explains that the criteria is not dependent upon an editor merely behaving with what appears to be "good or good-faith edits". A ban is based on a persistent or long-term pattern of editing behavior that demonstrates a significant risk of "disruption, issues, or harm" to the area in which they are banned from, despite any number of positive contributions said editor has made or is willing to make moving forward. As such, it naturally requires a higher degree of review (i.e. a form of community consensus) to be imposed or removed (though many simply expire upon a pre-determined expiration date without review). While some may interpret bans as a form of punishment, they are still a preventative measure at their core. At least that's my understanding. --GoneIn60 (talk) 12:59, 21 January 2025 (UTC)[reply]
Contacting/discussing organizations that fund Wikipedia editing
I have seen it asserted that contacting another editor's employer is always harassment and therefore grounds for an indefinite block without warning. I absolutely get why we take it seriously and 99% of the time this norm makes sense. (I'm using the term "norm" because I haven't seen it explicitly written in policy.)
In some cases there is a conflict between this norm and the ways in which we handle disruptive editing that is funded by organizations. There are many types of organizations that fund disruptive editing - paid editing consultants, corporations promoting themselves, and state propaganda departments, to name a few. Sometimes the disruption is borderline or unintentional. There have been, for instance, WMF-affiliated outreach projects that resulted in copyright violations or other crap being added to articles.
We regularly talk on-wiki and off-wiki about organizations that fund Wikipedia editing. Sometimes there is consensus that the organization should either stop funding Wikipedia editing or should significantly change the way they're going about it. Sometimes the WMF legal team sends cease-and-desist letters.
Now here's the rub: Some of these organizations employ Wikipedia editors. If a view is expressed that the organizations should stop the disruptive editing, it is foreseeable that an editor will lose a source of income. Is it harassment for an editor to say "Organization X should stop/modify what it's doing to Wikipedia?" at AN/I? Of course not. Is it harassment for an editor to express the same view in a social media post? I doubt we would see it that way unless it names a specific editor.
Yet we've got this norm that we absolutely must not contact any organization that pays a Wikipedia editor, because this is a violation of the harassment policy. Where this leads is a bizarre situation in which we are allowed to discuss our beef with a particular organization on AN/I but nobody is allowed to email the organization even to say, "Hey, we're having a public discussion about you."
I propose that if an organization is reasonably suspected to be funding Wikipedia editing, contacting the organization should not in and of itself be considered harassment. I ask that in this discussion, we not refer to real cases of alleged harassment, both to avoid bias-inducing emotional baggage and to prevent distress to those involved. Clayoquot (talk | contribs) 03:29, 22 January 2025 (UTC)[reply]
Let's say Acme Corporation has been spamming Wikipedia. If you post on Twitter "Acme has been spamming Wikipedia" is that harassment? How about if you write "@Acme has been spamming Wikipedia?" Should only Trust and Safety be allowed to add the @ sign? Clayoquot (talk | contribs) 15:43, 22 January 2025 (UTC)[reply]
What you post on Twitter isn't something Wikipedia can control. But contacting another editor's employer about that editor's edits has a dark history on Wikipedia.—S MarshallT/C15:49, 22 January 2025 (UTC)[reply]
The history is dark indeed. What I'm pointing out is that writing "@Acme has been spamming Wikipedia" on Twitter is contacting another editor's employer. Should you be indef blocked without warning for doing that? Clayoquot (talk | contribs) 15:56, 22 January 2025 (UTC)[reply]
You want an "in principle" discussion without talking about specific cases, so the only way I can answer that is to say: Not always, but depending on the surrounding circumstances, possibly.—S MarshallT/C16:11, 22 January 2025 (UTC)[reply]
Another issue is that it sometimes doing that can place another link or two in a wp:outing chain, and IMO avoiding that is of immense importance. The way that you posed the question with the very high bar of "always" is probably not the most useful for the discussion. Also, a case like this is almost always involves a concern about a particular editor or center around edits made by a particular editor, which I think is a non-typical omission from your hypothetical example. Sincerely, North8000 (talk) 19:41, 22 January 2025 (UTC)[reply]
I'm not sure what you mean by placing a link in an outing chain. Can you explain this further? I used the very high bar of "always" because I have seen admins refer to it as an "always" or a "bright line" and this shuts down the conversation. Changing the norm from "is always harassment" to "is usually harassment" is exactly what I'm trying to do.
Organizations that fund disruptive editing often hire just one person to do it but I've also seen plenty of initiatives that involve money being distributed widely, sometimes in the form of giving perks to volunteers. If the organization is represented by only one editor then there is obviously a stronger argument that contacting the organization constitutes harassment. Clayoquot (talk | contribs) 06:44, 23 January 2025 (UTC)[reply]
General reliability discussions have failed at reducing discussion, have become locus of conflict with external parties, and should be curtailed
The original WP:DAILYMAIL discussion, which set off these general reliability discussions in 2017, was supposed to reduce discussion about it, something which it obviously failed to do since we have had more than 20 different discussions about its reliability since then. Generally speaking, a review of WP:RSNP does not support the idea that general reliability discussions have reduced discussion about the reliability of sources either. Instead, we see that we have repeated discussions about the reliability of sources, even where their reliability was never seriously questioned. We have had a grand total of 22 separate discussions about the reliability of the BBC, for example, 10 of which have been held since 2018. We have repeated discussions about sources that are cited in relatively few articles (e.g., Jacobin).
Moreover these discussions spark unnecessary conflict with parties off wiki that harm the reputation of the project. Most recently we have had an unnecessary conflict with the Anti-Defamation League sparked by a general reliability discussion with them, but the original Daily Mail discussion did this also. In neither case was usage of the source a problem generally on Wikipedia in any way that has been lessened by their deprecation - they were neither widely-used, nor permitted to be used in a way that was problematic by existing policy on using reliable sources.
There is also some evidence, particularly from WP:PIA5, that some editors have sought to "claim scalps" by getting sources they are opposed to on ideological grounds 'banned' from Wikipedia. Comments in such discussions are often heavily influenced by people's impression of the bias of the source.
I think a the very least we need a WP:BEFORE-like requirement for these discussions, where the editors bringing the discussion have to show that the source is one for which the reliability of which has serious consequences for content on Wikipedia, and that they have tried to resolve the matter in other ways. The recent discussion about Jacobin, triggered simply by a comment by a Jacobin writer on Reddit, would be an example of a discussion that would be stopped by such a requirement. FOARP (talk) 15:54, 22 January 2025 (UTC)[reply]
The purpose of this proposal is to reduce discussion of sources. I feel that evaluating the reliability of sources is the single most important thing that we as a community can do, and I don't want to reduce the amount of discussion about sources. So I would object to this.—S MarshallT/C16:36, 22 January 2025 (UTC)[reply]
I don't thinks meant to reduce but instead start more discussions at a more appropriate level than at VPP or RSP. Starting the discussion at the VPP/RSP level means you are trying to get all editors involved, which for most cases isn't really appropriate ( eg one editor has a beef about a source and brings it to wide discussion before getting other input first). Foarp us right that when these discussion are first opened at VPP or RSP without prior attempts to resolve elsewhere is a wear on the process. — Masem (t) 16:55, 22 January 2025 (UTC)[reply]
Yeah I would support anything to reduce the constant attempts to kill sources at RSN. It has become one of the busiest pages on all of Wikipedia, maybe even surpassing ANI. -- GreenC19:36, 22 January 2025 (UTC)[reply]
Some confusion about pages here, with some mentions of RSP actually referring to RSN. RSN is a type of "before" for RSP, and RSP is intended as a summary of repeated RSN discussions. One purpose of RSP is to put a lid on discussion of sources that have appeared at RSN too many times. This isn't always successful, but I don't see a proposal here to alleviate that. Few discussions are started at RSP; they are started at RSN and may or may not result in a listing or a change at RSP. Also, many of the sources listed at RSP got there due to a formal RfC at RSN, so they were already subject to RFCBEFORE (not always obeyed). I'm wondering how many listings at RSN are created due to an unresolved discussion on an article talk page—I predict it is quite a lot. Zerotalk04:40, 23 January 2025 (UTC)[reply]
I fully agree that we need a strict interpretation of RFCBEFORE for the big "deprecate this source" RfCs. It must be shown that 1. The source is widely used on Wikipedia. 2. Removal/replacement of the source (on individual articles) has been contested. 3. Talk page discussions on use of the source have been held and have not produced a clear consensus.
We really shouldn't be using RSP for cases where a source is used problematically a single-digit number of times and no-one actually disagrees that the source is unreliable – in that case it can just be removed/replaced, with prior consensus on article talk if needed. Toadspike[Talk]11:42, 26 January 2025 (UTC)[reply]
The discussion above has spiralled out of control, and needs clarification. The discussion revolves around how to count episodes for TV series when a traditionally shorter episode (e.g., 30 minutes) is broadcast as a longer special (e.g., 60 minutes). The main point of contention is whether such episodes should count as one episode (since they aired as a single entity) or two episodes (reflecting production codes and industry norms).
The simple question is: when primary sources and secondary sources conflict, which we do use on Wikipedia?
The contentious article behind this discussion is at List of Good Luck Charlie episodes, in which Deadline, TVLine and The Futon Critic all state that the series has 100 episodes; this article from TFC, which is a direct copy of the press release from Disney Channel, also states that the series has "100 half-hour episodes".
The article has 97 episodes listed; the discrepancy is from three particular episodes that are all an hour long (in a traditionally half-hour long slot). These episode receive two production codes, indicating two episodes, but each aired as one singular, continuous release. An editor argues that the definition of an episode means that these count as a singular episode, and stand by these episode being the important primary sources.
The discussion above discusses what an episode is. Should these be considered one episode (per the primary source of the episode), or two episodes (per the secondary sources provided)? This is where the primary conflict is.
Multiple editors have stated that the secondary sources refer to the production of the episodes, despite the secondary sources not using this word in any format, and that the primary sources therefore override the "incorrect" information of the secondary sources. Some editors have argued that there are 97 episodes, because that's what's listed in the article.
WP:CALC has been cited; Routine calculations do not count as original research, provided there is consensus among editors that the results of the calculations are correct, and a meaningful reflection of the sources. An editor argues that there is not the required consensus. WP:VPT was also cited.
The same editor arguing for the importance of the primary source stated that he would have listed this as one episode, despite a reliable source[1] stating that there is 14 episodes in the season.
Wikipedia articles usually rely on material from reliable secondary sources. Articles may make an analytic, evaluative, interpretive, or synthetic claim only if it has been published by a reliable secondary source.
While a primary source is generally the best source for its own contents, even over a summary of the primary source elsewhere, do not put undue weight on its contents.
Do not analyze, evaluate, interpret, or synthesize material found in a primary source yourself; instead, refer to reliable secondary sources that do so.
Other quotes from the editors arguing for the importance of primary over secondary includes:
When a secondary source conflicts with a primary source we have an issue to be explained but when the primary source is something like the episodes themselves and what is in them and there is a conflict, we should go with the primary source.
We shouldn't be doing "is considered to be"s, we should be documenting what actually happened as shown by sources, the primary authoritative sources overriding conflicting secondary sources.
Yep, secondary sources are not perfect and when they conflict with authoritative primary sources such as released films and TV episodes we should go with what is in that primary source.
Having summarized this discussion, the question remains: when primary sources and secondary sources conflict, which we do use on Wikipedia?
Primary, as the episodes are authoritative for factual information, such as runtime and presentation?
Or secondary, which guide Wikipedia's content over primary interpretations?
As someone who has never watched Abbott Elementary, the example given at Abbott Elementary season 3#ep36 would be confusing to me. If we are going to say that something with one title, released as a single unit, is actually two episodes we should provide some sort of explanation for that. I would also not consider this source reliable for the claim that there were 14 episodes in the season. It was published three months before the season began to air; even if the unnamed sources were correct when it was written that the season was planned to have 14 episodes, plans can change. Caeciliusinhorto-public (talk) 10:13, 24 January 2025 (UTC)[reply]
Here is an alternate source, after the premiere's release, that specifically states the finale episode as Episode 14. (Another) And what of your thoughts for the initial argument and contested article, where the sources were also posted after the multiple multi-part episode releases? -- Alex_21TALK10:48, 24 January 2025 (UTC)[reply]
Vulture does say there were 14 episodes in that season, but it also repeatedly describes "Career Day" (episode 1/2 of season 3) in the singular as "the episode" in its review and never as "the episodes". Similarly IndieWire and Variety refer to "the supersized premiere episode, 'Career Day'" and "the mega-sized opener titled 'Career Day Part 1 & 2'" respectively, and treat it largely as a single episode in their reviews, though both acknowledge that it is divided into two parts.
If reliable sources do all agree that the one-hour episodes are actually two episodes run back-to-back, then we should conform to what the sources say, but that is sufficiently unexpected (and even the sources are clearly not consistent in treating these all as two consecutive episodes) that we do need to at least explain that to our readers.
In the case of Good Luck Charlie, while there clearly are sources saying that there were 100 episodes, none of them seem to say which episodes are considered to be two, and I would consider "despite airing under a single title in a single timeslot, this is two episodes" to be a claim which is likely to be challenged and thus require an inline citation per WP:V. I have searched and I am unable to find a source which supports the claim that e.g episode 3x07 "Special Delivery" is actually two episodes. Caeciliusinhorto-public (talk) 12:18, 24 January 2025 (UTC)[reply]
@Caeciliusinhorto-public: That's another excellent way of putting it. Plans change. Sources like Deadline Hollywood are definitely WP:RS, but they report on future information and don't really update to reflect what actually happened. How are sources like Deadline Hollywood supposed to know when two or more episodes are going to be merged for presentation? To use a couple of other examples, the first seasons for both School of Rock and Andi Mack were reported to have 13 episodes each by Deadline Hollywood and other sources. However, the pilot for School of Rock (101) never aired and thus the first season actually only had 12 episodes, while the last episode of Andi Mack's first season (113) was held over to air in the second season and turned into a special and thus the first season only had 12 episodes. Using School of Rock, for example, would we still insist on listing 13 episodes for the season and just make up an episode to fit with the narrative that the source said there are 13 episodes? No, of course not. It's certainly worth mentioning as prose in the Production section, such as: The first season was originally reported to have 13 episodes; however, only 12 episodes aired due to there being an unaired pilot. But in terms of the number of episodes for the first season, it would be 12, not 13. Amaury • 22:04, 24 January 2025 (UTC)[reply]
And what of the sources published later, after the finale, as provided, in which the producer of the series still says that there are 14 episodes? Guidelines and policies (for example, secondary sources vs primary sources) can easily be confused; for example, claiming MOS:SEASON never applies because we have to quote a source verbatim even if it says "summer 2016", against Wikipedia guidelines. So, if we need to quote a source verbatim, then it is fully support that there are 14 episodes in the AE season, or there are 100 episodes in the GLC series. All of the sources provided (100 episodes, 14 episodes) are not future information. What would you do with this past information? -- Alex_21TALK23:56, 24 January 2025 (UTC)[reply]
Nevertheless, the question remains: does one editor's unsourced definition of an episode outrule the basis sourcing policies of Wikipedia? -- Alex_21TALK23:58, 24 January 2025 (UTC)[reply]
If only we could divert all this thought and effort to contentious topics.Infoboxes cause a high proportion of Wikipedia disputes because they demand very short entries and therefore can't handle nuance. The solution is not to use the disputed parameter of the infobox.None of these sources are scholarly analysis or high quality journalism and they're merely repeating the publisher's information uncritically, so none of them are truly secondary in the intended meaning of the word.—S MarshallT/C13:11, 24 January 2025 (UTC)[reply]
Yes, secondary sources "contain analysis, evaluation, interpretation, or synthesis of the facts, evidence, concepts, and ideas taken from primary sources", that is correct. -- Alex_21TALK23:57, 24 January 2025 (UTC)[reply]
Request for research input to inform policy proposals about banners & logos
I am leading an initiative to review and make recommendations on updates to policies and procedures governing decisions to run project banners or make temporary logo changes. The initiative is focused on ensuring that project decisions to run a banner or temporarily change their logo in response to an “external” event (such as a development in the news or proposed legislation) are made based on criteria and values that are shared by the global Wikimedia community. The first phase of the initiative is research into past examples of relevant community discussions and decisions. If you have examples to contribute, please do so on the Meta-Wiki page. Thanks! --CRoslof (WMF) (talk) 00:04, 24 January 2025 (UTC)[reply]
@voorts: Planning for this initiative began several months ago. The banners and logo changes on Arabic Wikipedia were one factor in making this work a higher priority, but by no means the only factor. One of the key existing policies that relates to this topic is the Wikimedia Foundation Policy and Political Association Guideline. The current version of that policy is pretty old at this point, and we've found that it hasn't clearly answered all the questions about banners that have come up since it was last updated. We can also see how external trends, including those identified in the Foundation's annual plan, might result in an increase in community proposals to take action. Updating policies is one way to support decision-making on those possible proposals. CRoslof (WMF) (talk) 01:09, 25 January 2025 (UTC)[reply]
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputedviaa [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. Suitablevenues for doing so include the article'stalkpageand[[Wikipedia:Articles for deletion]].
+
A page can be [[Wikipedia:BLANKANDREDIRECT|blanked and redirected]] if there is a suitable page to redirect to, and if the resulting redirect is not [[Wikipedia:R#DELETE|inappropriate]]. If the change is disputed, such as by [[Wikipedia:REVERT|reversion]], an attempt should be made to reach a [[Wikipedia:Consensus|consensus]] before blank-and-redirecting again. The preferred venue for doing so is the appropriate [[WP:XFD|deletion discussion venue]] for the pre-redirect content, although sometimes the dispute may be resolved on the page's talk page.
As proposer. This reflects existing consensus and current practice. Blanking of article content should be discussed at AfD, not another venue. If someone contests a BLAR, they're contesting the fact that article content was removed, not that a redirect exists. The venue matters because different sets of editors patrol AfD and RfD. voorts (talk/contributions) 01:54, 24 January 2025 (UTC)[reply]
Summoned by bot. I broadly support this clarification. However, I think it could be made even clearer that, in lieu of an AfD, if a consensus on the talkpage emerges that it should be merged to another article, that suffices and reverting a BLAR doesn't change that consensus without good reason. As written, I worry that the interpretation will be "if it's contested, it must go to AfD". I'd recommend the following: This may be done through either a merge discussion on the talkpage that results in a clear consensus to merge. Alternatively, or if a clear consensus on the talkpage does not form, the article should be submitted through Articles for Deletion for a broader consensus to emerge. That said, I'm not so miffed with the proposed wording to oppose it. -bɜ:ʳkənhɪmez | me | talk to me!02:35, 24 January 2025 (UTC)[reply]
I don't either, but I see the wording of although sometimes the dispute may be resolved on the article's talk page closer to "if the person who contested/reverted agrees on the talk page, you don't need an AfD" rather than "if a consensus on the talk page is that the revert was wrong, an AfD is not needed". The second is what I see general consensus as, not the first. -bɜ:ʳkənhɪmez | me | talk to me!02:53, 24 January 2025 (UTC)[reply]
I broadly support the idea, an AFD is going to get more eyes than an obscure talkpage, so I suspect it is the better venue in most cases. I'm also unsure how to work this nuance in to the prose, and not suspect the rare cases where another forum would be better, such a forum might emerge anyway. CMD (talk) 03:28, 24 January 2025 (UTC)[reply]
Support, although I don't see much difference between the status quo and the proposed wording. Basically, the two options, AfD or the talk page, are just switched around. It doesn't address the concerns that in some cases RfD is or is not a valid option. Perhaps it needs a solid "yes" or "no" on that issue? If RfD is an option, then that should be expressed in the wording. And since according to editors some of these do wind up at RfD when they shouldn't, then maybe that should be made clear here in this policy's wording, as well. Specifically addressing the RfD issue in the wording of this policy might actually lead to positive change. P.I. Ellsworth , ed.put'er there17:26, 24 January 2025 (UTC)[reply]
Support the change in wording to state the preference for AFD in the event of a conflict, because AFD is more likely to result in binding consensus than simply more talk. Robert McClenon (talk) 01:04, 25 January 2025 (UTC)[reply]
Support. AfD can handle redirects, merges, DABifies...the gamut. This kind of discussion should be happening out in the open, where editors versed in notability guidelines are looking for discussions, rather than between two opposed editors on an article talk page (where I doubt resolution will be easily found anyways). Toadspike[Talk]11:48, 26 January 2025 (UTC)[reply]
Support firstly, because by "blank and redirect" you're fundamentally saying that an article shouldn't exist at that title (presumably either because it's not notable, or it is notable but it's best covered at another location). WP:AFD is the best location to discuss this. Secondly, because this has been abused in the past. COVID-19 lab leak theory is one example; and when it finally reached AFD, there was a pretty strong consensus for an article to exist at that title, which settled a dispute that spanned months. There are several other examples; AFD has repeatedly proven to be the best settler of "blank and redirect" situations, and the best at avoiding the "low traffic talk page" issue. ProcrastinatingReader (talk) 18:52, 26 January 2025 (UTC)[reply]
The section in question is about pages, not articles. If the proposed wording is adapted, it would be suggesting that WP:BLAR'd templates go to AfD. As I explained in the previous discussion, that's part of the reason why the proposed wording is problematic and that it was premature for an RfC on the matter. --Tavix(talk)17:35, 24 January 2025 (UTC)[reply]
considering the above discussion, my vote hasn't really changed. this does feel incomplete, what with files and templates existing and all that, so that still feels undercooked (and now actively article-centric), hence my suggestion of either naming multiple venues or not naming any consarn(speak evil)(see evil)23:28, 24 January 2025 (UTC)[reply]
Agree. I'm beginning to understand those editors who said it was too soon for an RfC on these issues. While I've given this minuscule change my support (and still do), this very short paragraph could definitely be improved with a broader guidance for up and coming generations. P.I. Ellsworth , ed.put'er there23:38, 24 January 2025 (UTC)[reply]
If you re-read the RFCBEFORE discussions, the dispute was over what to do with articles that have been BLARed. That's why this was written that way. I think it's obvious that when there's a dispute over a BLARed article, it should go to AfD, not RfD. I proposed this change because apparently some people don't think that's so obvious. Nobody has or is disputing that BLARed templates should go to TfD, files to FfD, or miscellany to MfD. And none of that needs to be spelled out here per WP:CREEP. voorts (talk/contributions) 00:17, 25 January 2025 (UTC)[reply]
If you want to be fully inclusive, it could say something like "the appropriate deletion venue for the pre-redirect content" or "...the blanked content" or some such. I personally don't think that's necessary, but don't object if others disagree on that score. (To be explicit neither the change that was made, nor a change to along the lines of my first sentence, change my support). Thryduulf (talk) 00:26, 25 January 2025 (UTC)[reply]
Exactly. And my support hasn't changed as well. Goodness, I'm not saying this needs pages and pages of instruction, nor even sentence after sentence. I think us old(er) farts sometimes need to remember that less experienced editors don't necessarily know what we know. I think you've nailed the solution, Thryduulf! The only thing I would add is something short and specific about how RfD is seldom an appropriate venue and why. P.I. Ellsworth , ed.put'er there00:35, 25 January 2025 (UTC)[reply]
I'm going to back down a bit with an emphasis on the word "preferred". I agree that AfD is the preferred venue, but my main concern is if a redirect gets nominated for deletion at RfD and editors make purely jurisdictional arguments that it should go to AfD because there's article content in its history even though it's blatantly obvious the article content should be deleted. --Tavix(talk)01:22, 25 January 2025 (UTC)[reply]
this is a big part of why incident 91724 could become a case study. "has history, needs afd" took priority over the fact that the history had nothing worth keeping, the redirect had been stable as a blar for years, and the ages of the folks at rfd (specifically the admins closing or relisting discussions on blars) having zero issue with blars being nominated and discussed there (with a lot of similar blars nominated around the same time as that one being closed with relatively litte fuss, and blars nominated later being closed with no fuss), and at least three other details i'm missing
as i said before, if a page was blanked relatively recently and someone can argue for there being something worth keeping in it, its own xfd is fine and dandy, but otherwise, it's better to just take it to rfd and leave the headache for them. despite what this may imply, they're no less capable of evaluating article content, be it stashed away in the edit history or proudly displayed in any given redirect's target consarn(speak evil)(see evil)10:30, 25 January 2025 (UTC)[reply]
As I've explained time and time again it's primarily not about the capabilities of editors at RfD it's about discoverability. When article content is discussed at AfD there are multiple systems in place that mean everybody interested or potentially interested knows that article content is being discussed, the same is not true when article content is discussed at RfD. Time since the BLAR is completely irrelevant. Thryduulf (talk) 10:39, 25 January 2025 (UTC)[reply]
if you want to argue that watchlists, talk page notifs, and people's xfd logs aren't enough, that's fine by me, but i at best support also having delsort categories for rfd (though there might be some issues when bundling multiple redirects together, though that's nothing twinkle or massxfd can't fix), and at worst disagree because, respectfully, i don't have much evidence or hope of quake 2's biggest fans knowing what a strogg is. maybe quake 4, but its list of strogg was deleted with no issue (not even a relisting). see also quackifier, just under that discussion consarn(speak evil)(see evil)11:03, 25 January 2025 (UTC)[reply]
I would think that as well, but unfortunately that's not reality far too often. I can see this new wording being more ammo for process wonkery. --Tavix(talk)02:49, 25 January 2025 (UTC)[reply]
Unless a note about RfD being appropriate in any cases makes it clear that it strictly limited to (a) when the content would be speedily deleted if restored, or (b) there has been explicit consensus the content should not be an article (or template or whatever), then it would move me into a strong oppose. This is not "process wonkery" but the fundamental spirit of the entire deletion process. Thryduulf (talk) 03:35, 25 January 2025 (UTC)[reply]
See what I mean this attitude is exactly why we are here. I've spent literal years explaining why I hold the position I do, and how it aligns with the letter and spirit of pretty much every relevant policy and guideline. It shouldn't even be controversial for blatantly obvious the article content should be deleted to mean "would be speedily deleteable if restored", yet on this again a single digit number of editors have spent years arguing that they know better. Thryduulf (talk) 03:56, 25 January 2025 (UTC)[reply]
both sides are on single digits at the time of writing this, we just need 3 more supports to make it 10 lol
ultimately, this has its own caveat(s). namely, with the csd not covering every possible scenario. regardless of whether or not it's intentional, it's not hard to look at something and go "this ain't it, chief". following this "process" to the letter would just add more steps to that, by restoring anything that doesn't explicitly fit a csd and dictating that it has to go to afd so it can get the boot there for the exact same reason consarn(speak evil)(see evil)10:51, 25 January 2025 (UTC)[reply]
oppose, though with the note that i support a different flavor of change. on top of the status quo issue pointed out by tavix (which i think we might need to set a period of time for, like a month or something), there's also the issue of the article content in question. if it's just unsourced, promotional, in-universe, and/or any other kind of fluff or cruft or whatever else, i see no need to worry about the content, as it's not worth keeping anyway (really, it might be better to just create a new article from scratch). if a blar, which has been stable as a redirect, did have sources, and those sources were considered reliable, then i believe restoring and sending to afd would be a viable option (see purple francis for an example). outside of that, i think if the blar is reverted early enough, afd would be the better option, but if not, then it'd be rfd for this reason, i'd rather have multiple venues named ("Suitable venues include Articles for Deletion, Redirects for Discussion, and Templates for Discussion"), no specific venue at all ("The dispute should be resolved in a fitting discussion venue"), or conditions for each venue (for which i won't suggest a wording because of the aforementioned status quo time issue) consarn(speak evil)(see evil)17:50, 24 January 2025 (UTC)[reply]
I know it's not really in the scope of this discussion but to be perfectly honest, I'm not sure why BLAR is a still a thing. It's a cliche, but it's a hidden mechanism for backdoor deletion that often causes arguments and edit wars. I think AfDs and talk-page merge proposals where consensus-building exists produce much better results. It makes sense for duplicate articles, but that is covered by A10's redirection clause. J947 ‡ edits03:23, 25 January 2025 (UTC)[reply]
BLARs are perfectly fine when uncontroversial, duplicate articles are one example but bold merges are another (which A10 doesn't cover). Thryduulf (talk) 03:29, 25 January 2025 (UTC)[reply]
I didn't say, or intend to imply, that every BLAR is related to a merge. The best ones are generally where the target article covers the topic explicitly, either because content is merged, written or already exists. The worst ones are where the target is of little to no (obvious) relevance, contains no (obviously) relevant content and none is added. Obviously there are also ones that lie between the extremes. Any can be controversial, any can be uncontroversial. Thryduulf (talk) 18:20, 25 January 2025 (UTC)[reply]
I am confident that I can get a knowledgeable answer here quickly. There is a Deletion Review in progress, where the AFD was held in December 2023, and no one participated except the nominator, even after two Relists. After two relists, the closer closed it as a Redirect, which was consistent with what the nominator had written. In Deletion Review, the appellant is saying that the article should be restored. I understand that in the case of a soft delete, the article should be restored to user or draft space on request, but in this case, the article is already present in the history. So: Does the appellant have a right to have the article restored, or should they submit it to AFC for review, or what? I don't care, but the appellant does care (of course). Robert McClenon (talk) 20:44, 24 January 2025 (UTC)[reply]
Without a second participant, an uncontested AfD is not a discussion and so there is no mandated outcome and the redirect in question can be undone by any editor in good standing, and can be then taken to AfD again by any editor objecting to it. Draft isn't typically mandated in policies, because it's a relatively new invention compared to our deletion policies and isn't referenced everywhere it might be relevant or helpful to specify. Jclemens (talk) 07:04, 25 January 2025 (UTC)[reply]
Uninvolved opinion: While I agree with Jclemens that the DR appellant can simply revert the redirect within policy, I have not looked at this specific article and it likely makes more sense to restore to draftspace. I believe the appellant can do this themselves and does not need to go through a DR to copy the contents of the article from its history to draftspace. Alternatively, they can revert the BLAR and move to draftspace. The only difference is that if/when the article is moved back from draft to mainspace, a histmerge might be needed. Toadspike[Talk]11:56, 26 January 2025 (UTC)[reply]
WP:NOQUORUM indicates that such a close should be treated as an expired WP:PROD, which states that restoration of prodded pages can be done via admin or via Requests for undeletion - there's no identified expectation/suggestion that prods should go to DRV. WP:SOFTDELETE states that such a deleted article "can be restored for any reason on request", ie: restoration to mainspace is an expected possibility. It also states that redirection is an option since BLAR can be used by any editor if there are no objections. Putting those together, it's reasonable for a restoration from redirect to be treated as a belated objection, and this can be done by any editor without seeking permission (though it would be nice if valid issues identified in the original AFD were fixed as part of the restoration to avoid a second AFD). ~Hydronium~Hydroxide~(Talk)~12:08, 26 January 2025 (UTC)[reply]
Psychological research
In recent years, psychological research on social media users and its undesirable side effects have been discussed and criticized. Is there a specific policy on Wikipedia to protect users from covert psychological research? Arbabi second (talk) 00:22, 25 January 2025 (UTC)[reply]
No there is not. Wikipedia provides easy ways for anyone including the general public to examine your contributions, and offers researcher-friendly licence terms to enable them to do so.—S MarshallT/C09:13, 25 January 2025 (UTC)[reply]
I've enabled the gadget that pops up a micro-summary of an article whenever I mouse over a link to it. Unfortunately, it's not working properly with redirects. For example, if visit Serial comma#Mainly British style guides opposing typical use, I'm given the following text: I dedicate this book to my parents, Martin Amis, and JK Rowling. If I mouse over the first link, I get a picture of Amis and this text:
Sir Martin Louis Amis (25 August 1949 – 19 May 2023) was an English novelist, essayist, memoirist, screenwriter and critic. He is best known for his novels Money (1984) and London Fields (1989). He received the James Tait Black Memorial Prize for his memoir Experience and was twice listed for the Booker Prize (shortlisted in 1991 for Time's Arrow and longlisted in 2003 for Yellow Dog).
However, if I mouse over the second link, I get this text:
JK Rowling ⋅ actions ⋅ popups Redirects to J. K. Rowling ⋅ actions
Is there a way to change this, so that the popup shows the target of the redirect (as if the link went to the target), rather than the redirect itself? I can't imagine a reason why we should care whether it's an article or a redirect. The documentation suggests that identifying pages as redirects helps people fix them, but You probably don't want to "fix" such links every time you come across them, and WP:NOTBROKEN actively prohibits changing those redirects without some alternate reason, e.g. it's fine to replace "JK Rowling" with "J. K. Rowling" if we want the full stops and space to appear in the article, but not good to edit the article just to change [[JK Rowling]] to [[J. K. Rowling|JK Rowling]]. If there are any legitimate uses for distinguishing redirects from articles with this tool, that's different, but as far as I can see, it merely gets in the way of using this tool. Nyttend (talk) 22:12, 19 January 2025 (UTC)[reply]
@Nyttend: The first time I hover over a redirect like JK Rowling after loading or reloading a page, I see text from the target below the text you quoted. If I come back to hover over the same link, I only see what you quoted. PrimeHunter (talk) 23:58, 19 January 2025 (UTC)[reply]
Can confirm I'm seeing the same thing - on first mouseover it loads the redirect section, pauses a second or so, and loads the popup for the final target page below that. Subsequent mouseovers (including of the same link elsewhere on the page) just get the redirect section. I think in the past the behaviour was slightly different - it would always load the popup for the final target page below the redirect section - but I couldn't swear to that. Andrew Gray (talk) 20:48, 24 January 2025 (UTC)[reply]
Contributions by CIDR range plus date range
I'm tracking a LTA account who frequently IP hops within the same session eg. they might switch IP 6 or 7 times within 30 minutes. However they appear to be limited to certain A or B classes which in theory makes tracking possible. But in practice anything bigger than a C is hard. For example class C Special:Contributions/5.90.7.* is doable but class B Special:Contributions/5.90.* is not, and certainly not class A 5.* .. (I have "JavaScript-enhanced contributions lookup 0.2 enabled", your results may look different from mine.)
Question: is there a tool to filter Class A or Class B based on time frame eg. show all edits within this Class A between 10:40 and 12:40 on Jan 20 on Enwiki. -- GreenC15:03, 21 January 2025 (UTC)[reply]
I've long thought that the CIDR gadget is pretty much deprecated since the functionality was built in to the contributions page (there are probably still a couple of niche uses, but not many). The contributions page allows you to filter by range and date... For this /16 range the link looks like [2] (there are no contributions on the 20th and it won't filter by exact time). Won't that suffice? -- zzuuzz(talk)15:14, 21 January 2025 (UTC)[reply]
Thanks John. Start is end. End is start. The docs mention this but somewhat confusingly. The default is |ucdir=older, which requires ucstart to be higher than ucend. The original will work with |ucdir=newer enabled: [3] .. probably |ucdir=newer should be the default because counting backwards is.. backwards. -- GreenC01:22, 22 January 2025 (UTC)[reply]
Some table classes yet to be adapted for Dark Mode
An example can be found at Javanese script, where each cell features a white background with invisible transliteration:
Some Javanese letters and their Balinese equivalents
ha
ꦲ
na
ꦤ
ca
ꦕ
ra
ꦫ
ka
ꦏ
a
ꦄ
ā
ꦄ
i
ꦆ
ī
ꦇ
u
ꦈ
ū
ꦈꦴ
ᬳ
ᬦ
ᬘ
ᬭ
ᬓ
ᬅ
ᬆ
ᬇ
ᬈ
ᬉ
ᬊ
Does this imply that all classes labeled letters-* haven't been updated for Dark Mode yet?
I would like to get a list of urls to all class B articles. I know programming. But from what I could figure out up to now, it seems quite tedious to go to Category:B-Class_articles and do all subcategories in a recursive manner and change targets from talk pages to the actual articles. Is there any easier way to do it?
thanks for your response. I think I got a toolforge account. So I will try to quarry the database. The reason why I want to work with such a list is my mediawiki2latex program. I want to run it on all class B articles to try if a PDF is created in every case and fix the cases where it does not happen.
now PetScan works again. The results seem very similar to the one I got with the database query below. But good to know that the two methods of obtaining the solution generate roughly the same results. Dirk Hünniger (talk) 13:32, 25 January 2025 (UTC)[reply]
thanks a lot for you query 90084 example. I am not really used to SQL, but this was a nice opportunity for me to practice SQL. I came up with a modified version of your query, that seems to do what I need quarry:query/90125. I exported it to csv and built a set of the lines, which resulted in 151299 elements, which is the right order of magnitude.
For my purpose it is good enough, I just need a set of Wikipedia articles with not too short content, that I can use as test data for my mediawiki2latex program.
Retrieving multiple property values in one call of Module:wd
I am trying to retrieve multiple property values from wikidata (using Module:wd) in one call but it is ignoring the other properties I give so I only ever get one property value. I must not be giving things in the correct order but none of the Module examples help me. For example, given a mountain name, I want to retrieve the elevation, prominence, mountain range, coordinates and the first ascent significant event. I can get all the values if I code one call per property but how do I code it so I can get all the properties in one call?
So given this:
P2044 = elevation
P2660 = prominence
P4552 = mountain range
P625 = coordinates
P793 = significant event; Q1194369 = first ascent; P585 = point in time
how do I get all the property values in one call?
{{#invoke:wd|property|P2044|P2660|P4552|P625|property|qualifier|P793|Q1194369|P585|page=Mount Robson}} RedWolf (talk) 19:10, 22 January 2025 (UTC)[reply]
The documentation for the "property" command says "Returns the requested property – or list of properties". Yet, I see no example or syntax of how to specify this list of properties. RedWolf (talk) 22:35, 22 January 2025 (UTC)[reply]
Incomprehensible error message
Hi, near the bottom of Anglo-German Fellowship is the giant red error message "Lua error in Module:Navbox at line 604: attempt to concatenate field 'argHash' (a nil value)." Does this mean anything to anybody? And, more importantly, can anyone make it go away? Thank you, DuncanHill (talk) 19:40, 22 January 2025 (UTC)[reply]
"Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value)." Is it WP:THURSDAY? Hawkeye7(discuss)20:08, 22 January 2025 (UTC)[reply]
Obviously this is beyond the scope of Wikipedia, but it seems to be impossible to find snapshots of new links that can be archived at the moment. It simply produces an error message such as "Fail with status: 498" or "We're sorry — something's gone wrong. Our team has been notified." This is a nuisance as archiving links via the Wayback Machine is important. Are other people having this problem? ♦IanMacM♦(talk to me)20:03, 22 January 2025 (UTC)[reply]
Parent categories
An editor has requested a change to the way we display categories in the Category: namespace. The existing system, which looks approximately like this:
This sort of sounds like it would be an overall general improvement - that is not something special for only the English Wikipedia, and for only users with their interface language in en. If so, this should be requested upstream. — xaosfluxTalk01:56, 23 January 2025 (UTC)[reply]
I think it'd be better to do this locally, where it's been requested. If it seems to be a net improvement, we could always suggest it for widespread use (which would require re-translation of the string for all 300+ languages – not something that can happen quickly). WhatamIdoing (talk) 03:44, 23 January 2025 (UTC)[reply]
Nonsense redlink
Twice in the past three days, AnomieBOT has created the entirely unpopulated maintenance category Category:Articles lacking reliable references from 2025-01-19 from January 2025, which has in turn generated a nonsense redlink for Category:Monthly clean-up category (Articles lacking reliable references from 2025-01-19) counter — but since YYYY-MM-DD is not part of our naming format for either "Articles lacking reliable references" or "monthly clean-up category" maintenance categories, neither of these are categories that should ever exist at those names at all. But when I deleted the referencing category as both nonsense and empty earlier today in order to blow up the monthly clean-up redlink, the bot came along and recreated it again a few hours later even though it's still both nonsense and empty.
Could somebody look into this and figure out how to make it stop? I haven't deleted the category again this time, though I have wrapped the template in {{suppress categories}} since the redlinked parent still needed to go away regardless. Thanks. Bearcat (talk) 01:29, 23 January 2025 (UTC)[reply]
If that was the cause of this, then why was it not in the category I asked about, either time that it appeared at WantedCategories? I found that other category by perusing the edit history of an individual editor whom I was able to figure out had some connection to the issue after asking about this here, but it was never, ever filed inCategory:Articles lacking reliable references from 2025-01-19 from January 2025 at all, so how can it possibly have cascaded into the creation of a parent category it was never in? Bearcat (talk) 16:18, 24 January 2025 (UTC)[reply]
Did you check the link that I provided? If you do so, and go to the categories box at the very bottom, the first cat shown - a redlink - is Articles lacking reliable references from 2025-01-19. This means that the article was in that category, between 22:16, 19 January 2025 (UTC) (the time of the first of that pair of edits) and 01:51, 20 January 2025 (UTC), which is when this corrective bot edit was applied. --Redrose64 🌹 (talk) 00:35, 25 January 2025 (UTC)[reply]
asterisks
List item
Second level list item
Third level list item if there's a line separating this from the previous list item
^^ Why is this the default behavior for multiple asterisks? Does anybody ever actually want every asterisk to render as an additional dot? Why isn't *** by default just a twice indented bulletpoint, even if not immediately preceded by a once indented bulletpoint? This silliness is why many people wind up starting lines with e.g. :*:::: or :::::*, which if I recall correctly isn't ideal for accessibility. At minimum, given the ubiquity of unordered lists in wiki discussion pages, shouldn't indents be the default behavior (with perhaps some template for anyone with a weird multi-bullet use case)? — Rhododendritestalk \\ 03:46, 23 January 2025 (UTC)[reply]
Because any ‘lists’ with newlines between them are not actually one united list. See MOS:LISTBREAK. Sadly MediaWiki does not make this obvious enough, if anything, but both are bad for accessibility. Editors should be advised not to insert blank lines between list items, or at least to insert them as blank lines with indentation (*** <blank>), as that would generate a hidden empty list item that would unite the markup. stjn04:59, 23 January 2025 (UTC)[reply]
It becomes immediately obvious when using hashes to make an ordered list:
List item
Second level list item
Third level list item if there's a line separating this from the previous list item
Notice the lack of an item numbered 2. This is such a long-established feature of the MediaWiki software that it's unlikely to be changed. But you can use CSS to highlight the problematic markup. Here's a quick-and-dirty rule that draws a thick dashed red line in the gap of the first example above:
I actually have a user style called user:stjn/linter.css (in Russian Wikipedia) that highlights a bunch of accessibility/markup-related issues like this, including one mentioned here. I mostly advertised it on Discord, though. (Recently I’ve been thinking of turning it into a user script that can then provide more refined suggestions, since CSS can have too many false positives if you try to write, for example, a rule specifically for a list containing only another list.) — stjn00:33, 24 January 2025 (UTC)[reply]
Your style does something entirely different: instead of highlighting incorrect code, it just styles discussions a certain way. stjn16:15, 26 January 2025 (UTC)[reply]
Yes, that's what I said. As a side effect, it makes it easy for me to see problems in list nesting levels, but doesn't highlight them. isaacl (talk) 17:06, 26 January 2025 (UTC)[reply]
Hi, For PetScan, when launched, it shows
Error: This web service cannot be reached. Please contact a maintainer of this project.. Needed to run an hour ago and still fails. Will check again later today. Regards, JoeNMLC (talk) 14:32, 23 January 2025 (UTC)[reply]
It only accepts bug reports on github, where there is bug 187 open now. Github isn't really good for operational bugs, just software ones... This is another project with a lack of active onwiki volunteers unfortunately. — xaosfluxTalk15:31, 23 January 2025 (UTC)[reply]
@Xaosflux - Thank you for digging into this issue. PetScan really is a great tool for category filtering of articles. I regularly use to find Unreferenced + Orphan articles combination. For now, "Plan B" is to search thru just the old Unref. articles. Yes, it would be great to find an expert to: 1. Identify what is broken; 2. Fix it. There are some Bots that occasionally fail off & need to be restarted. Cheers, JoeNMLC (talk) 17:41, 23 January 2025 (UTC)[reply]
LDAP shows that Magnus Manske is the only maintainer. Since this is a very important tool, I think the Wikimedia Cloud team can help restart the web service if Magnus is not available. – DreamRimmer (talk) 18:04, 23 January 2025 (UTC)[reply]
As of now PetScan is running Okay, and seems to be faster. Hoping it continues processing requests. Will give it a few days before tag with "Done". Cheers! JoeNMLC (talk) 19:46, 24 January 2025 (UTC)[reply]
I don't get an interstitial when I click the action=edit or action=submit links above. Maybe I have a preference set that takes me to the edit window directly. – Jonesey95 (talk) 01:12, 24 January 2025 (UTC)[reply]
Not seeing it logged in, as I have have ever once answered that popup. Even logged out, once you answer it - subsequent loads will bypass it. — xaosfluxTalk10:21, 24 January 2025 (UTC)[reply]
Forgot what you call this. But every page on top has a little updated notice on how many views, etc. have been on that page. This is not browser specific, in my case. I have three browsers, and it's the same on all of them. Now I see a little left-hand dot moving back and trying to load the page stats. But it just keeps going back and forth with no results. — Maile (talk) 23:31, 23 January 2025 (UTC)[reply]
Whatever it's called, it is working perfectly now. To the left of it, is a little colored "Assessment" button. I just discovered that if I click on it, it takes me directly to XTools. — Maile (talk) 00:12, 24 January 2025 (UTC)[reply]
The assessment is working fine as not all XTools components are down. Without going through and checking individually, it's at least edit counter, page history, and authorship that are down. CNC (talk) 14:57, 24 January 2025 (UTC)[reply]
Rest assured, any downtime with XTools is relayed to maintainers automatically, and usually a flood of pings gets sent my way as well ;) I was traveling during this outage, but the Cloud Services team graciously came to my aid. All should be fine now.
The assessment is working fine as not all XTools components are down.
I think what happened here is the API server (which the gadget queries) was restarted successfully, while the main app server was stuck in a reboot loop. — MusikAnimaltalk08:46, 26 January 2025 (UTC)[reply]
By "semi" I mean I only have to click "log in" to get back in, not fill in my password or anything. But still annoying to have Vector2022 constantly flash onto my screen. This has been happening last three days or so, sometimes as often as every ten minutes. Cremastra (talk) 23:52, 23 January 2025 (UTC)[reply]
Please see "Page top edit counter down" above. I just noticed today that once again I cannot access my own XTools and keep getting "Wikimedia Cloud Services Error/ This web service cannot be reached. Please contact a maintainer of this project." Seems to me this is all related to some snafu at Wikimedia Cloud Services. — Maile (talk) 13:45, 24 January 2025 (UTC)[reply]
Agree with Cryptic - in case it's any help, I've just run a query across all of 2024 and after removing a couple of redirects for T (magazine), I make it 10676 views for all ~100 pages starting T:, combined - so about 30 hits per day among the whole lot. A quarter of those are T:TDYK. Andrew Gray (talk) 21:09, 24 January 2025 (UTC)[reply]
Issue with Binary Tree Display in Dark Mood
I'm experiencing an issue with the "dark mode" theme. When using this theme, certain elements, such as the binary tree in articles (e.g., ), become barely visible as they blend into the background. This makes it challenging to view the content clearly. The same issue occurs with any outlined transparent images.
Is there a way to fix this issue or improve the visibility of such elements in dark mode? A possible solution could be to add a white background to these elements, ensuring they remain visible when dark mode is enabled. Lunar Spectrum96 (talk) 23:07, 24 January 2025 (UTC)[reply]
@Lunar Spectrum96 For me, the SVG given appears fine. There's the screen's black background, and then the SVG's white one. I cam see the numbers fine. Could you perhaps provide a screenshot of how it looks to you? Cremastra (talk) 23:56, 24 January 2025 (UTC)[reply]
Cremastra, not your likely gadget dark mode, the one that comes native with Vector 22 and Minerva, where the image displays without a background, meaning the text is black on dark grey.
Suppose I come across some template like {{No Internet}}. Would it be fine to just replace [[User:{{ROOTPAGENAME}}|{{ROOTPAGENAME}}]] in its message parameter to {{#ifeq:{{NAMESPACE}}|Template|(Your name will automatically go here)|{{ROOTPAGENAME}}}} as in at {{Off and On WikiBreak}} so as to make "(Your name will automatically go here)" appear instead of template's name on the example at the template page? I am asking this as I don't have any experience in template editing at that level. Thanks, 𝓔xclusive𝓔ditorPing Me🔔20:08, 25 January 2025 (UTC)[reply]
[[People's Park (Berkeley)#May 15, 1969: "Bloody Thursday"|Bloody Thursday]]
However, turns out that the encoding that follows the section marker, #, isn't really encoding. It's exactly like % encoding, but with the percent signs switched to dots. This issue is fairly widespread, see [5] where I'm searching for the pattern .28[...].29, for a matching set of parens which would normally be encoded as %28[...]%29. I get about 8.5K hits, which includes some unrelated things, but that indicates the scale of the issue.
1) Does someone know the cause of such half-garbled links? Or can investigate to find it/have some insights? Most incidents I can find seem to have been added in the mid 2010s, e.g. [6]
2) Bot cleanup is likely needed on this. I haven't made a WP:BOTREQ yet, but bot/script coders and technical people might want to chime in on what might be involved for cleanup here. Even a better / more comprehensive regex search would be useful here. I've used round brackets for my search, but quotes (%22), ndash/mdashes, slashes/backslashes, and other %-encoded characters would likely be fruitful.
The cause is that that's what MediaWiki used to generate. It was an XHTML4 thing that the anchor targets were "officially" restricted to a subset of ASCII characters, so "percent encoding with % changed to ." was used to turn section titles into valid anchor targets. Once MediaWiki switched to HTML5, anchor targets could contain basically any UTF-8.I don't know that cleanup is really needed. The encoded targets are still also output so as to not break old links (as long as the target is still there at all). Unless MediaWiki devs have indicated that they plan to turn that off? Anomie⚔13:30, 26 January 2025 (UTC)[reply]
BTW, note that the dot-encoding isn't necessarily trivially reversible. For example, while == 0% == produce an XHTML4-style anchor of "0.25", so does == 0.25 == because the dot itself is not encoded. Anomie⚔14:13, 26 January 2025 (UTC)[reply]
That argument sounds very much WP:COSMETICBOT. Why should a bot go through these specifically, rather than letting people do it manually in cases like that article (or bots do it as general fixes along with a more substantive edit) as we do for other cosmetic things? While someone could argue that the changed fragment in the rendered link is (barely) non-cosmetic under the first bullet, since readers do see the fragment if they follow the link, you're not making that argument. Anomie⚔14:32, 26 January 2025 (UTC)[reply]
I'm making the argument that this is extremelyeditor-hostile wikitext, and should be fixed to something sane, much like AWB already does for properly %-encoded links. Manual cleanup of this would be very, very tedious and error prone. Headbomb {t · c · p · b}14:45, 26 January 2025 (UTC)[reply]
@Anomie: There's no such thing as XHTML4. There's XHTML 1.0, and there's HTML 4.0, with considerable overlap between the two specs, but with one being more restrictive than the other in certain areas. Prior to HTML5, our servers produced XHTML 1.0 pages. The relevant parts of the specs are C.8. Fragment Identifiers in XHTML 1.0 and the ID token in HTML 4.0, from which it is clear that the restriction prohibiting the percent sign was not with the URL fragment, but what it pointed to in the served page. --Redrose64 🌹 (talk) 17:07, 26 January 2025 (UTC)[reply]
Checking ref 15 in 1452/1453 mystery eruption I found that it was a bad link. I then checked it in the wayback machine and found that although the most recent copy on 2 April 2022 is also a bad link, there is a good copy dated 22 February 2003 at [7]. I ran the article through Analyse a page and it archived the recent bad copy, so the ref now has both the original and archived copies bad. Is this a weakness in 'Analyse a copy' and is there any way round it? Dudley Miles (talk) 14:15, 26 January 2025 (UTC)[reply]
Why does pinging without a signature not work
Why does pinging without a signature not work?
What is the technical limitation that requires a signature?
Wouldn't it be easy for a bot to follow an EventStream and notify people of failed pings?
My understanding is that it's a heuristic used to identify new comments, in order to avoid sending a notification when someone copy edits a comment, or moves a comment to a new location, for instance. isaacl (talk) 17:12, 26 January 2025 (UTC)[reply]
Transclusion of peer reviews to article talk pages
Hello,
First time posting here.
I would like to propose that peer reviews be automatically transcluded to talk pages in the same way as GAN reviews. This would make them more visible to more editors and better preserve their contents in the article/talk history. They often take a considerable amount of time and effort to complete, and the little note near the top of the talk page is very easy to overlook.
This also might (but only might!) raise awareness of the project and lead to more editors making use of this volunteer resource.
I posted this suggestion on the project talk page yesterday, but I have since realized it has less than 30 followers and gets an average of 0 views per day.
So far this proposal has only support, both here and at the Peer review talk. Absent objections, is there a place we can request assistance with implementation? I have no idea how to do this. Thanks! --Patrick (talk) 17:23, 13 January 2025 (UTC)[reply]
It might be useful to have a bot transclude the reviews automatically like ChristieBot does for GAN reviews. AnomieBOT already does some maintenance tasks for PR so, Anomie, would this task be a doable addition to its responsibilities? Apart from that, I don't think any other changes need to be made except to selectively hide or display elements on the review pages with <noinclude>...</noinclude> or <includeonly>...</includeonly> tags. —TechnoSquirrel69 (sigh) 17:28, 13 January 2025 (UTC)[reply]
Since ChristieBot already does the exact same thing for GAN reviews, it might be easier for Mike Christie to do the same for peer reviews than for me to write AnomieBOT code to do the same thing. If he doesn't want to, then I'll take a look. Anomie⚔22:41, 13 January 2025 (UTC)[reply]
I don't have any objection in principle, but I don't think it's anything I could get to soon -- I think it would be months at least. I have a list of things I'd like to do with ChristieBot that I'm already not getting to. Mike Christie (talk - contribs - library) 22:54, 13 January 2025 (UTC)[reply]
Support, I've submitted a couple of articles for peer review and wondered when I first did it why it wasn't done on a sub-page of article's talks the same way GAN is. TarnishedPathtalk02:24, 16 January 2025 (UTC)[reply]
Support. This would be very, very helpful for drafts, so discussions can be made in the Talk pages to explain a problem with a draft in more detail rather than only showing the generic reason boxes. Hinothi1 (talk) 12:56, 18 January 2025 (UTC)[reply]
Good Article visibility
I think it would be a good idea to workshop a better way to show off our Good, A-class and Featured articles (or even B-class too), and especially in the mobile version, where there is nothing. At present, GA icons appear on the web browser, but this is it. I think we could and should be doing more. Wikipedia is an expansive project where page quality varies considerably, but most casual readers who do not venture onto talk pages will likely not even be aware of the granular class-based grading system. The only visible and meaningful distinction for many readers, especially mobile users, will be those articles with maintenance and cleanup tags, and those without. So we prominently and visibly flag our worst content, but do little to distinguish between our best content and more middling content. This seems like a missed opportunity, and poor publicity for the project. Many readers come to the project and can go away with bad impressions about Wikipedia if they encounter bad or biased content, or if they read something bad about the project, but we are doing less than we could to flag the good. If a reader frequents 9 C-class articles and one Good Article, they may simply go away without even noticing the better content, and conclude that Wikipedia is low quality and rudimentary. By better highlighting our articles that have reached a certain standard, we would actually better raise awareness about A) the work that still needs to be done, and B) the end results of a collaborative editing process. It could even potentially encourage readers who become aware of this distinction to become editors themselves and work on pages that do not carry this distinction when they see them. In this age of AI-augmented misinformation and short-attention spans, better flagging our best content could yield benefits, with little downside. It could also reinject life and vitality into the Good Article process by giving the status more tangible front-end visibility and impact, rather than largely back-end functionality. Maybe this has been suggested before. Maybe I'm barking up the wrong tree. But thoughts? Iskandar323 (talk) 15:09, 11 January 2025 (UTC)[reply]
With the big caveat that I'm very new to the GA system in general and also do not know how much technical labor this would require, this seems like a straightforwardly helpful suggestion. The green + sign on mobile (and/or some additional element) would be a genuinely positive addition to the experience for users - I think a textual element might be better so the average reader understands what the + sign means, but as it stands you're absolutely right, quality is basically impossible to ascertain on mobile for non-experts, even for articles with GA status that would have a status icon on desktop. 19h00s (talk) 16:43, 11 January 2025 (UTC)[reply]
While GA articles have been approved by at least one reviewer, there is no system of quality control for B class articles, and no system to prevent an editor from rating an article they favor as B class in order to promote or advertise it. A class articles are rare, as Military History is the only project I know of that uses that rating. Donald Albury17:16, 11 January 2025 (UTC)[reply]
I totally agree we should be doing more. There are userscript that change links to different colours based on quality (the one I have set up shows gold links as featured, green as GA, etc).
@Thebiguglyalien: Is that feedback discussion alive, dead, or just lingering in half-life? It's not obviously archived, but has the whole page been mothballed? So basically, there's community consensus to do something, but the implementation is now the sticking point. Iskandar323 (talk) 04:57, 12 January 2025 (UTC)[reply]
Basically, most of the progress made is listed on that feedback page and the project has moved on from it. There were a few options, like the visibility one, where it was agreed upon and then didn't really go anywhere. So there are some ideas there, but we'd basically need to start fresh in terms of implementation. Thebiguglyalien (talk) 05:16, 12 January 2025 (UTC)[reply]
You're barking up exactly the right tree, Iskandar323. Regarding showing the icons on mobile, that's a technical issue, which is tracked at phab:T75299. I highlighted it to MMiller (WMF) when I last saw him at WCNA, but there's ultimately only so much we can push it.Regarding desktop, we also know the solution there: Move the GA/FA topicons directly next to the article name, as was proposed in 2021. The barrier there is more achieving consensus — my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean. The best counterargument to that would be some basic user research, and while ideally that would come from the WMF, anyone could try it themselves by showing a bunch of non-Wikipedian friends GAs/FAs and asking if they notice the symbols and know what they mean. Once we have that, the next step would be running another RfC that'd hopefully have a better chance of passing. Sdkbtalk06:50, 12 January 2025 (UTC)[reply]
It's great that I've got the right tree, since I think that's a village pump first for me. It seems that the proposer of that original 2021 discussion already did some basic research. Intuitively, it also seems just obvious that an icon tucked away in the corner, often alongside the padlocks indicating permission restrictions, is not a high visibility location. Another good piece of final feedback in the GA project discussion mentioned earlier up this thread by TBUA is that the tooltip could also been improved, and say something more substantial and explanatory than simply "this is a good article". On the subject of the mobile version and the level of priority we should be assigning to it, we already know that per WP:MOBILE, 65% of users access the platform via mobile, which assuming a roughly even spread of editors and non-editors, implies that 2/3 of contemporary casual visitors to the site likely have no idea about the page rating system. Iskandar323 (talk) 07:31, 12 January 2025 (UTC)[reply]
my reading of that discussion is that, while it came close, the determining factor of why it didn't ultimately pass is that some portion of editors believed (wrongly, in my view) that most readers notice/know what the GA/FA symbols mean This is not my reading of the discussion. To me it looks as though a major concern among opposers is that making GA/FA status more prominent for readers is likely to mislead them, either by making them think that GAs/FAs are uniformly high-quality even for those which were assessed many years ago when our standards were lower and have neither been maintained or reassessed, or by making them more doubtful about the quality of articles which have never gone through the GA/FA process but are nonetheless high quality. By my count at least ten of the 15 oppose !voters cite this reason either explicitly or "per X" where X is someone else who had made this point. Caeciliusinhorto (talk) 16:18, 12 January 2025 (UTC)[reply]
I've also encountered a fair few instances of older, lower standard GA articles. But I also think greater visibility (effectively also transparency) could also benefit in that area as well. If GA status is more prominent, it provides greater cause to review and reassess older GAs for possible quality issues. Also, most of the worst GAs I have seen have come from around 2007, so it seems like one sensible solution would be for GA status to come with a sunset clause whereby a GA review is automatically required after a decade. Maybe I'm getting a little sidetracked there, but this sort of concern is also exactly what I mean by greater visibility potentially reinjecting life and vitality into the process. Iskandar323 (talk) 17:15, 12 January 2025 (UTC)[reply]
I think you're right about that being the most major source of opposition, but most major is different than determining — I don't think those !voters will be open to persuasion unless the quality of GAs/FAs improves (which, to be fair, it definitely has somewhat since 2021). But the "they already know" !voters might be more persuadable swing !voters, and it would have passed with their support. Sdkbtalk19:02, 12 January 2025 (UTC)[reply]
@Sdkb: So, is there any way to poke the mobile issue a little harder with a stick? And do you think it is worth re-running the 2021 proposal or a version of it? What format should such a discussion take? Is there a formal template for making a proposal more RFC-like? Iskandar323 (talk) 12:59, 20 January 2025 (UTC)[reply]
@Sdkb: I see that it got moved to "Incoming" after you flagged it to Miller, but then it got sent back to the "Freezer", and yesterday shunted altogether: Per the web team's quarterly grooming, these tasks are being removed from the team's backlog.Iskandar323 (talk) 12:46, 24 January 2025 (UTC)[reply]
I think that's a fair reading of the discussion. But, I suppose the best way to be more transparent is to tell a user that it has been rated GA after a peer review, but that doesn't mean that the article is perfect... Which is what GA (and FAs) also say. Lee Vilenski(talk • contribs)19:54, 12 January 2025 (UTC)[reply]
It is a watered-down process from an FA, but it is also the first rung on the ladder for some form of peer-review and a basic indicator of quality. Not every subject has the quality sources, let alone a volunteer dedicated enough, to take it straight from B-class to Featured Article. Iskandar323 (talk) 17:17, 12 January 2025 (UTC)[reply]
I propose that most[a] transclusions of redirects to {{Use mdy dates}} and {{Use dmy dates}} be replaced by bots with the full template name.
Part of the purpose of {{Use mdy dates}} is to indicate to editors what they should do. Thus, readability is important. I propose all of these redirects be replaced with their target which is:
More easily understood even the first time you see it.
Standardized, and thus easier to quickly scan and read.
The specific existing redirects that I suggest replacing are:
^I would probably leave alone the redirects that differ only in case, namely {{Use MDY dates}} and {{Use DMY dates}}, which are sufficiently readable for my concerns.
In principle I like this idea (noting my suggestion to bring it here). My only concern would be about watchlist spam, given that, while this may not technically be a cosmetic edit, it's only a hair above one. But there's only a few thousand transclusions of these redirects, so if the bot goes at a rate of, say, one per minute, it'd be done in a few days. -- Tamzin[cetacean needed] (they|xe|🤷) 21:09, 18 January 2025 (UTC)[reply]
It looks like most or all of these are already listed at Wikipedia:AutoWikiBrowser/Template redirects, so whenever anyone edits an article with AWB, they'll already be replaced. No strong view about doing so preemptively.
However, if our goal is to ensure that these templates are actually meaningfully used, then we have some bigger fish to fry. First of all, even the written-out form isn't sufficiently readable/noticeable — many newcomers may not know what it means, and many experienced editors may miss it if they aren't happening to look at the top of the article. Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.
Second of all, roughly 2/3 of all articles still don't have a date tag, so we need to figure out better strategies for tagging en masse. There are surely some definable groups of articles that are best suited to a particular format (e.g. all U.S. municipality articles I'd think would want to use MDY) that we could agree on and then bulk tag. Sdkbtalk21:50, 18 January 2025 (UTC)[reply]
Ideally, we would either offer to correct the date format if anyone enters the incorrect one via mw:Edit check (task) or we'd include it in an editnotice of some sort.This could also feasibly be done with a regex edit filter, which is better than Edit check in that specific case as the latter doesn't work with the source editor as far as I know. Chaotic Enby (talk · contribs) 07:01, 20 January 2025 (UTC)[reply]
However it's done technically, it will need human supervision as some instances shouldn't be change, e.g. in quotes and the titles of sources. Thryduulf (talk) 07:08, 20 January 2025 (UTC)[reply]
A filter could only flag an issue, not fix it. And any time a user gets a warning screen when they click "publish", there is a significant chance they will abandon their edit out of confusion or frustration, so we should not be doing that for a relatively minor issue like date format. -- Tamzin[cetacean needed] (they|xe|🤷) 07:11, 20 January 2025 (UTC)[reply]
I do believe that just flagging it would be better than giving an explicit warning (that might scare the user) or automatically fixing it (which, like Thryduulf mentioned, might not be optimal for direct quotes and the likes). Chaotic Enby (talk · contribs) 07:17, 20 January 2025 (UTC)[reply]
Concur with Tamzin — the main point of Edit Check is to introduce an option to alert an editor of something without requiring a post-edit warning screen, which is all edit filters can do. The ideal form would be a combo of a flag and an automatic fix — for instance, dates not detected to be within quotes would be highlighted, clicking on it would say "this article uses the MDY date format; would you like to switch to that? learn moreconvert". Sdkbtalk16:38, 20 January 2025 (UTC)[reply]
To be doubly sure I'm accurately understanding the behavior y'all are trying to promote, @Sdkb, can you please give the below a read and share what I might be missing/misunderstanding?
Many Wikipedia articles include templates that specify the format that dates present within them are written in. To increase the likelihood that people follow these guidelines (on a per article basis), we propose that when people fail to format dates in the way the consensus specifies, Edit Check presents them with a suggestion that invites them to convert the date they've written into the desired format.
It's definitely a cosmetic edit, in that it only changes the wikitext without changing anything readers see. But consensus can decide that any particular cosmetic edit should be done by bots. As proposed, there are currently 2089 transclusions of these redirects, 1983 in mainspace. Anomie⚔14:21, 19 January 2025 (UTC)[reply]
Agree with this. Also regarding many newcomers may not know what it means (in reference to the full template names): as a reminder, we do have to opt in to display maintenance categories, many of which are far less scrutable to the uninitiated. Categories can be clicked on for explanation.As to the proposal itself, I don't really see the value in bypassing a bunch of redirects. Redirects exist to be used, and there's nothing wrong with using them. Blowing up people's watchlists for this type of change seems inconsiderate.Articles without a prescribed date format are a non-issue. There's no need to implement any standard format at every article, and I augur that an attempt to do so would create far more problems than it would solve. Folly Mox (talk) 16:15, 21 January 2025 (UTC)[reply]
It is a problem (albeit a small one) if an article has some dates MDY and others DMY or YMD, per MOS:DATERET, since it introduces inconsistency. Tagging the article with its preferred format helps retain it, so it's something we should ultimately strive for (particularly at GAs/FAs, but also in applicable categories as I suggested above). Sdkbtalk17:14, 21 January 2025 (UTC)[reply]
Knowing how much each is transcluded, and relative to the most-used cousins, would be a valuable point to include in this discussion.
The more valuable change of sorts with respect to these templates is that they're clearly metadata. It would be great if we could move them over to mediawikiwiki:MCR, though IDK how much effort it would take to get that done. (And perhaps along with the settings for citations and English variety.) Izno (talk) 22:32, 23 January 2025 (UTC)[reply]
Forbid Moving an Article During AFD
There is currently a contentious Deletion Review, at Wikipedia:Deletion_review/Log/2025_January_19#Raegan Revord, about an article about a child actress, Raegan Revord. Some editors think that she is not biographically notable, and some editors think that she is biographically notable. There is nothing unusual about such a disagreement; that is why we have AFD to resolve the issue. What happened is that there were a draft version of her biography and a mainspace version of her biography, and that they were swapped while the AFD was in progress. Then User:Liz reviewed the AFD to attempt to close it, and concluded that it could not be closed properly, because the statements were about two different versions of the article. So Liz performed a procedural close, and said that another editor could initiate a new AFD, so that everyone could be reviewing the same article.
This post is not about that particular controversy, but about a simple change that could have avoided the controversy. The instructions on the banner template for MFD are more complete than those on the banner template for AFD. The AFD template says:
Feel free to improve the article, but do not remove this notice before the discussion is closed.
The MFD template says:
You are welcome to edit this page, but please do not blank, merge, or move it, or remove this notice, while the discussion is in progress.
Why don't we change the banner template on an article that has been nominated for deletion to say not to blank, merge, or move it until the discussion is closed? If the article should be blanked, redirected, merged, or moved, those are valid closes that should be discussed and resolved by the closer. As we have seen, if the move is done in good faith, which it clearly was, it confuses the closer, and it did that. I have also seen articles that were nominated for deletion moved in bad faith to interfere with the deletion discussion.
I made the suggestion maybe two or three years ago to add these instructions to the AFD banner, and was advised that it wasn't necessary. I didn't understand the reason then, but accepted that I was in the minority at the time. I think that this incident illustrates how this simple change would prevent such situations. Robert McClenon (talk) 06:06, 20 January 2025 (UTC)[reply]
Thank you for the information, User:Some1. Both my example and yours are good-faith, but taking unilateral bold action while a community process is running confuses the community. I have also, more than once, seen bad-faith moves of articles during AFD. An editor who is probably a COI editor creates an article that is poorly sourced or promotional. A reviewer draftifies it. The originator moves it back to draft space. Another reviewer nominates it for deletipn, which is the proper next stop after contested draftification. The originator then moves it back to draft space so that the AFD will be stopped. Sometimes an admin reverses the move, but sometimes this stops the discussion and leaves the page in draft space. I think that any renaming should be considered within the AFD. Robert McClenon (talk) 06:52, 20 January 2025 (UTC)[reply]
"Renaming" and "draftifying" may be technically the same operation, but they are quite different things. I don't mind outlawing draftify during AFD, as it pre-empts the outcome, but fixing a nontrivial typo or removing a BLP-noncompliant nickname from a page title should be done immediately by anyone who notices the problem, independent of whether the page is at AFD or not. —Kusma (talk) 09:15, 20 January 2025 (UTC)[reply]
Oppose. Improving an article during AfD is encouraged and we must resist anything that would make it harder. Following the proposal would have meant a cut and paste move/merges would have had to happen in order to use the existing draft, making the situation more difficult to understand than a clear page swap. —Kusma (talk) 06:49, 20 January 2025 (UTC)[reply]
Support, the AfD deals with notability, and moving can impact the scope and thus the notability. In that specific case, during the AfD, sources from both could've been considered, as AfD is about the sources that exist rather than the current content of the article. Not sure how a merge would've made it more difficult to understand than what actually happened. Chaotic Enby (talk · contribs) 06:55, 20 January 2025 (UTC)[reply]
When merging, the other article's history should be linked in the edit summary for attribution anyway. The benefit of avoiding the massive confusion for the closer (and the later deletion review) far outweighs the need for a few more clicks to find the history. Chaotic Enby (talk · contribs) 07:41, 20 January 2025 (UTC)[reply]
If people are discussing version A before 13 January and version B after 13 January, this may result in confusion for the closer. But the confusion arises from people discussing two different versions of the article. I am all for clearly stating in the AFD when anything like moving or merging has happened, but outlawing moves is not solving the unsolvable problem that articles can change during an AFD. —Kusma (talk) 09:11, 20 January 2025 (UTC)[reply]
Inclined to support as a draft swap seems rare, and seems somewhat at odds with the stated principle that AfD is about notability, which would not differ between a mainspace article and a draft article. In situations when there is a draft, the AfD could come to consensus to use the draft, or to keep on the topic and the draft can be moved in post-AfD. That said, regarding blanking, I have seen articles at least partially blanked due to BLP or copyright concerns. Those seem correct actions to take even during an AfD, and I suspect other instances of blanking are rare enough, and likely to be reverted if disruptive. CMD (talk) 09:31, 20 January 2025 (UTC)[reply]
Weak oppose forbidding the kind of move made here. We encourage improving an article during the AFD, and separately it is often said during AFDs that an article should be TNT'ed and started over. Replacing the article with a new version, whether through moving a draft or simply rewriting it in place, is a valid (if hamhanded) attempt to do both of those things to save an article from deletion. Support forbidding moving the article to a new title with no content changes, as that could be disruptive (you'd have to move the AFD for one, and what if it gets reverted?). Pinguinn🐧10:57, 20 January 2025 (UTC)[reply]
You do not have to move the AFD (and you should not, it is unnecessary and causes extra work). All you need is to make a note on the AFD what the new page title is. Of course you should almost never suppress the redirect while moving a page that is at AFD. —Kusma (talk) 14:06, 20 January 2025 (UTC)[reply]
I can see the benefit of forbidding moving between namespaces, but this proposal would also catch simple renames. I've seen plenty of deletion discussions for articles with simple typos or spacing errors in their titles, where the nominating user has not corrected things before nominating. We should not forbid moving them to the correct title. Phil Bridger (talk) 13:49, 20 January 2025 (UTC)[reply]
I don't see the benefit of retaining poorly worded article titles for seven days or more. I'd support against moving namespaces during an AfD, but not all renaming.
This could actually cause an issue if someone was to move an article to a title that someone else wants to move an article to (in case of an obvious PRIMARY TOPIC/Dab change). Lee Vilenski(talk • contribs)14:57, 20 January 2025 (UTC)[reply]
Oppose There are some rare cases this is a problem, but I have seen many/most cases it is helpful. In the given example, let's say the move was disallowed and the article was deleted. Now wait a few weeks and make the article again with the new content. People will complain no matter what. You've got to be reasonable. If there was a major effort to redo the article it should be discussed during the AfD. -- GreenC18:27, 20 January 2025 (UTC)[reply]
Based on the comments above I think the best we can get will be a policy that requires any change of title be clearly and explicitly noted in an AfD, supplemented by a guideline that discourages controversial and potentially controversial changes in title while discussion is ongoing. Any change that would alter the scope of the article or which has been rejected by discussion participants (or rejected previously) is potentially controversial. On the other hand, a suggested change that has significant support and no significant objection among discussion participants is usually going to be uncontroversial. Thryduulf (talk) 19:02, 20 January 2025 (UTC)[reply]
How about we limit such moves to admins? If there is an overriding good reason to move a page as part of editing and improvement of the encyclopedia, it should be movable. BD2412T22:20, 20 January 2025 (UTC)[reply]
Not sure that restricting editorial/content choices to the discretion of admins is a good thing. While it will definitely help in case of overriding good reason, it also means an individual admin can enforce a potentially controversial choice of page title for their own reasons, and can't be reverted by another editor. And, of course, there's the wheel-warring aspect to that.An alternative could be to limit such moves to closing the discussion with a consensus to move – that way, we still limit spurious moves even more, but the editorial choices are still made by the community. Chaotic Enby (talk · contribs) 22:29, 20 January 2025 (UTC)[reply]
Would the described swap be possible without special tools? I know that the title of this thread is "move", but that was more (and much harder or impossible for a regular editor to undo) than a move. North8000 (talk) 22:34, 20 January 2025 (UTC)[reply]
Comment. I would be chary of preventing this completely. There are quite a few cases where it rapidly emerges that the article is clearly at the wrong title (eg a transliteration error or a woman who exclusively publishes under another form of her name) so that the results of searches for sources are completely different between the two titles; moving the article even mid-AfD might be a good response in such cases. Espresso Addict (talk) 05:33, 21 January 2025 (UTC)[reply]
I note that the text of the AfD notice used to read "Feel free to improve the article, but this notice must not be removed until the discussion is closed, and the article must not be blanked. For more information, particularly on merging or moving the article during the discussion, read the guide to deletion." until it was shortened in March 2021 by Kusma and then further shortened by Joe Roe in October 2023. Espresso Addict (talk) 05:47, 21 January 2025 (UTC)[reply]
If you can find a concise replacement for the text that actually gives pertinent information, please do edit the notice. —Kusma (talk) 08:31, 21 January 2025 (UTC)[reply]
Given that the current basis for the recommendation against moving is the relatively weak wording in WP:AFDEQ (While there is no prohibition against moving an article while an AfD or deletion review discussion is in progress, editors considering doing so should realize such a move can confuse the discussion greatly), highlighting this specifically in the template seems out of proportion. Perhaps we could revisit that if the consensus here is to strengthen the guidance, which would also allow us to be more concise (i.e. "do not move this page"). – Joe (talk) 18:37, 21 January 2025 (UTC)[reply]
It might be beneficial to tighten up that wording; something like An article should not generally be moved while an AfD or deletion review discussion is in progress, as it can confuse the discussion greatly. However articles may exceptionally be moved if a clear consensus emerges during the discussion to change the title.Espresso Addict (talk) 00:09, 22 January 2025 (UTC)[reply]
Oppose. Moving an article to a new title can be confusing during an AfD, but otherwise good edits are good edits. In particular rewrites or replacements by drafts to address concerns raised in the discussion shouldn;t wait because they can make clear that a reasonable article can be (because it has been) created. Eluchil404 (talk) 06:09, 21 January 2025 (UTC)[reply]
Weak support I think this should be formally discouraged, but I don't think we should ban it entirely. Certainly some moves during an AfD may be tendentious. SportingFlyerT·C06:11, 21 January 2025 (UTC)[reply]
Strong support This has been a problem for years. The solution is simple, there is no requirement to make such moves during an AfD duration, there is no downside to this proposal. Andy Dingley (talk) 19:30, 21 January 2025 (UTC)[reply]
Oppose as a blanket rule, and strongly oppose this wording. Even if it is not intended as a blanket rule, and even if there are "obvious exceptions" as detailed above, wording like this will cause people to interpret it as one even when those "obvious exceptions" apply. "Well damn looks like the New York Times just reported that the shooting of Dudey McDuderson was a hoax, but sorry, we can't fix the title, template says so." (Example chosen since it's a plausible WP:NOTNEWS AfD.) Gnomingstuff (talk) 19:46, 21 January 2025 (UTC)[reply]
If it's that clear and obvious that something needs to be fixed, then obtain consensus for it at the AfD (and if you can't, then it's not "clear and obvious"), speedy resolve it (close and re-open as needed, or even some sort of partial consensus for one aspect) and then do it. But we still can't do renames when we don't yet have agreement as to need and new target. Andy Dingley (talk) 20:12, 21 January 2025 (UTC)[reply]
What I am saying is that wording like "please do not blank, merge, or move it, or remove this notice, while the discussion is in progress" will result in people arguing "the template says don't move it so don't move it, no exceptions allowed." Gnomingstuff (talk) 00:08, 22 January 2025 (UTC)[reply]
The problem is less moving things during an AfD as moving them unilaterally, without consensus. We can surely demonstrate that during an AfD, or quickly, in order to resolve and close it, if it's that clear. Andy Dingley (talk) 12:03, 22 January 2025 (UTC)[reply]
Yes, I agree. But that's not what the proposed wording says. The wording proposed is "please do not blank, merge, or move it, or remove this notice, while the discussion is in progress" (bolding mine), not "please do not move it unless you have consensus or it's obvious." There are no carve-outs in the wording and so the wording is bad. Gnomingstuff (talk) 01:37, 26 January 2025 (UTC)[reply]
Oppose (except as to unilateral draftification). Renaming should be left to editors' judgment. This includes their judgment of whether the new name is likely to be controversial, or whether any past or present discussion is actually related to the new name and shows opposition to it. In other words, ordinary principles of WP:BOLDMOVE apply. There should not be a general prohibition or consensus-in-advance requirement, nor should editors revert moves solely "procedurally" because of AFD. (Editors can of course revert if they disagree on the merits of the name.) Reader-facing improvement efforts should not be held back by an overriding concern for internal administrators' confusion. That's getting priorities backward. Adumbrativus (talk) 01:21, 22 January 2025 (UTC)[reply]
Hard cases make bad law. I don't know if that's always true, actually, but this discussion does strike me as an overreaction to an extremely unusual set of facts. --Trovatore (talk) 04:44, 22 January 2025 (UTC)[reply]
Qualified support. I generally agree that editors who move pages in the middle of a consensus-building discussion should be trouted, but there can be good reasons to perform such a move. We should prohibit only controversial moves during an AfD/RM/etc., while allowing uncontroversial moves. This is the same framework used at WP:RM/TR, where it works well. Toadspike[Talk]09:13, 24 January 2025 (UTC)[reply]
Definitely and most emphatically not. I have addressed deletion concerns by renaming and refactoring articles during discussion many times over the past two and a bit decades, and as the person who wrote much of the guidelines on this stuff, including helping on the AFD notices, I can report that it is perfectly fine and a practice that has worked for decades. It has happened many times, entirely uncontroversially, and not just when done by me (although I've often wikignomed the links in the AFD discussions to follow the page moves, as people forget that part).
Years ago, I used to put a horizontal rule and a small note when doing rewrites and refactors, to mark the point in the discussion where the article changed. But I reduced to just the horizontal rule and sometimes stopped doing even that when people started recognizing my name and stopped checking things for themselves once my name came up. (The name recognition might have dropped off a bit, nowadays. I could probably get away with the horizontal rules again.) I recommend that others simply mark where a rewrite or a page move has happened, in the discussion. I didn't have trouble with that before the name recognition set in, and you probably will not either. And please make my life (on AFD patrol) and those of closing administrators easier by remembering to fix the page title links in the discussions, because the real problems for closing administrators are what the target edit history to delete or not delete is, which remains clear as long as the discussion continues to point to the same edit history that it pointed to at nomination. Edit histories are not titles, and it is the edit history that gets deleted with the administrator deletion tool.
Proposal to prohibit the creation of new "T:" pseudo-namespace redirects without prior consensus
Around this time last year in 2024, the phabricator ticket T363757 created a brand new alias for the template namespace. From this point on, it is possible to get to any template by appending the letters "TM:" to any search. If I wanted to reach the centralized discussion template, I could always type TM:CENT and it works like a charm, for all templates on the site. Back in the day though, typing in 8 characters to reach a page became somewhat exhausting, especially for titles that might need to be navigated to frequently. As a helpful tool, a pseudo-namespace called "T:" was deployed, to quickly let people reach pages in the template namespace. (Nevermind the fact that "T" apparently ALSO stands for the talk namespace (T:MP) and template talk namespace (T:DYKT)). Regardless, in practice, pseudo-namespaces are great tools for navigation, but they have a flaw in the fact that the software does not really support them. All pseudo-namespace redirects occupy mainspace, which means that any PNRs which exist should be maintained with care and diligence, to avoid interfering with regular readers searching for articles.
Anyway, among the four PNRs currently in use today, "T:" has been, by-and-large, the most controversial among the rest. While CAT:, P:, and H: all have some usage in different circumstances, according to WP:Shortcut#Pseudo-namespaces, "T:" titles are for "limited and specific uses only". Generally speaking, the only reason to justify the creation of a T: title, is for a template that sees regular use and maintenance by members of the project. If it's not a template one would need to return to on a regular basis, there's no need to occupy mainspace with a "T:" title, further adding to the obfuscation of other genuine articles that also start with "T:", such as T:kort, T: The New York Times Style Magazine, and many others according to Special:PrefixIndex/T:.
In regards to controversy, T: titles have been the subject of persistent RfDs since 2009, with variable results. Several RfCs have been held relating to pseudo-namespace redirects, including one from 2014 that suggests that "new T: titles should be generally discouraged", in Wikipedia:Village pump (policy)/Archive 112#RFC: On the controversy of the pseudo-namespace shortcuts. Yet, despite the multiple RfCs and RfDs, new "T:" titles continue to crop up regardless. Whether that be from people who mis-interpret or misunderstand pseudo-namespaces, or for anyone that might not've noticed WP:Shortcut saying "T:" titles are for "limited uses only", these are frequently monitored and the number always grows.
In any case, with the advent of the [[TM:]] alias, there is little to no need for new "T:" titles. It is not important enough to shrink a two-letter namespace, into a one-letter namespace, so there's really no reason to have NEW titles that start with "T:". In 2022, the "WikiProject:" pseudo-namespace was added to the disallow-list for new article titles. I don't think that "T:" as a starter should be added to such a list, but I don't think there should be any new ones of this type now that [[TM:]] is a safer alternative that works for 100% of all templates, and doesn't affect mainspace searches.
I propose that on WP:Shortcut, "T:" is moved to a new classification indicating that new titles should not be created without prior consensus, and/or that "new titles do not enjoy broad community support", i.e. the category that the WikiProject prefix is listed at currently. (For that matter, I think that the WikiProject prefix should be removed from Shortcuts because no pages contain that prefix anywhere on Wikipedia; at least not any from the last 3 years). I also propose that "T:" be removed from the shortlist on WP:PNR, because I feel that contributes to the creation of new T: titles, and we should not encourage the creation of T: titles when TM: now exists. Utopes(talk / cont)22:17, 20 January 2025 (UTC)[reply]
Support I've always found "T:" titles confusing. In particular, I never understood why sometimes it worked (i.e. T:DYK) and sometimes it didn't (T:Cite journal). At some point I gave up trying to figure it out and just resigned myself to typing out "template" all the time (and occasionally typing "templare" by accident). I wasn't even aware that TM: existed.It's absurd that there should be namespaces, aliases, pseudo-namespaces, all of which have slightly different behaviors (not to mention Help:Transwiki). You should be able to understand what something is by looking at it, i.e. if it has a ":" after it, it's a namespace. So yeah, I wholeheartedly support getting rid of T. Getting rid of the existing T links may be painful, but it's pain we will endure once and be done with. That's better than continuing to have something that's inconsistent and confusing forever.
I ran into this recently when writing some code that handles matching template names. It turns out that if I give you a link foo:bar, you can't know if the "foo" part is case sensitive or not if you don't know what namespaces are configured on the particular wiki it came from. That's just stupid. RoySmith(talk)16:25, 21 January 2025 (UTC)[reply]
PS, as a follow-up to You should be able to understand what something is by looking at it, I suggest people watch Richard Feynman's comments on this subject. When I'm seeking wonder and amazement at discovering a deeper understanding of the world around me, I can turn to quantum mechanics. I'd prefer wiki-syntax to be a bit less wonderous. RoySmith(talk)16:49, 21 January 2025 (UTC)[reply]
Support – if we already have TM: as a perfectly functional pseudonamespace alias that automatically redirects to Template:, we don't need to encourage the use of T: which only works for hardcoded redirects and adds another level of confusion. After the moratorium, we can leave DYK some additional time to shift to TM: if needed. (edited 15:14, 22 January 2025 (UTC): mixed up alias and pseudonamespace again) Chaotic Enby (talk · contribs) 17:10, 21 January 2025 (UTC)[reply]
Oppose. "TM:" is not an intuitive redirect for "template", and longstanding usage - which I use frequently - is for "T:", e.g. T:ITN, T:DYK etc. If need be, we should tell the software to use "T:" universally for templates rather than "TM:". Using it for "Talk:" doesn't really make sense either, it's very rare to need a shortcut to a talk page, whereas templates are frequent targets. We should also add "TT:" for template talk. Editors drive how we work on the project, not suits at the Wikimedia Foundation. — Amakuru (talk) 19:49, 21 January 2025 (UTC)[reply]
Even the code patch was written by a enwiki volunteer and the deployment was done by another volunteer developer lol. The claim of suits at the Wikimedia Foundation has no basis here. Literally nobody from the WMF was involved in this. Sohom (talk) 06:15, 23 January 2025 (UTC)[reply]
What one person finds intuitive isn't always necessarily what another person finds intuitive. But the link Chaotic Enby posted above shows there's a consensus that TM: is a suitable alias, so I don't think we should reinvigorate that debate. The question here isn't whether we like TM, it's whether we should get rid of T now that we have TM. Cremastra (talk) 20:56, 21 January 2025 (UTC)[reply]
Support. As Utopes points out, the advantage from writing "t" compared to "tm" is one character, however, the cons far outweigh them. Gonnym (talk) 09:22, 22 January 2025 (UTC)[reply]
Support: T: had a historical reason to exist, but whether a shortcut would exist or not was always frustratingly inconsistent. Now that there is a clean & reliable replacement, we ought to stop adding to that historical baggage! Mlkj (talk) 23:35, 23 January 2025 (UTC)[reply]
Support per nom. There's no reason to keep using this janky workaround. Removal of exisiting T: shortcuts should be discussed at RfD, since some of them are heavily used, but prohibiting the creation of new ones is a no-brainer. Toadspike[Talk]08:59, 24 January 2025 (UTC)[reply]
Just so I understand the technical issues here, let's assume this were to go all the way to it's logical conclusion and we decide to eliminate "T:" completely. What would that mean? Is there some entry in a config file somewhere which makes "T:" exist, or is it purely convention that people have adopted? RoySmith(talk)15:28, 24 January 2025 (UTC)[reply]
Support - while it may just be me, as an abbreviation for template, TM seems more intuitive than T. There can be such a thing as too much abbreviation. In any case, I agree entirely with the reasoning behind the proposal. arcticocean ■15:39, 24 January 2025 (UTC)[reply]
Haven't read the comments above but I will support the prohibition of T: indefinitely. It has since been superseded by the new shortcut prefix, so it will really be pointless to create a pseudo redirect in the mainspace to the template namespace. To enforce such change, the T: prefix should be title blacklisted, as with Wikiproject: pseudo redirects in 2022. ToadetteEdit (talk) 12:15, 25 January 2025 (UTC)[reply]
Oppose title blacklist, let's not confuse people when they want to create reasonably titled articles starting with T:. I agree with the proposal not to create new T: shortcuts for template space, but current shortcuts that are in use and have been used in edit summaries should be kept working for a few years. —Kusma (talk) 12:29, 25 January 2025 (UTC)[reply]
Please see my comment below this one. There are multiple T: redirects and there will be such redirects in the future, which are not pseudo-namespace redirects, but are regular content redirects. —Alalch E.20:08, 25 January 2025 (UTC)[reply]
Title blacklisting would be unfeasible, I agree. However, an edit filter that applies when:
Therefore, "T:" can stand for "T-", "Terminator:", "Tribes:", "Turbo:", "Thief:", et cetera. There is a strong possibility of such future titles.—Alalch E.17:46, 25 January 2025 (UTC)[reply]
I would think it would be good enough to make a filter which looks for any title starting with "T:" and tags it for review. I imagine this will be a rare enough event that getting a human in the loop to deal with any problems would be all we need, and simple to implement. RoySmith(talk)01:43, 26 January 2025 (UTC)[reply]
You can create a title blacklist item purely for creation of new titles, and in this case, it would be idea to temporarily (say, for 2 years) to prohibit their creation for non-admins so that people are aware that this shouldn’t be done. Any legitimate titles can always be created by an admin, which, given from your list, there aren’t a lot of. stjn16:12, 26 January 2025 (UTC)[reply]
To clarify, there were, as of 14:44, 26 January 2025, 252 redirects from main-space to template-space, of which 55 had the T: prefix. – wbm1058 (talk) 16:33, 26 January 2025 (UTC)[reply]
The table has the "Senate 1828/29" elections and the "House 1828/29" elections and both of those comprise multiple elections for the Senate and the House some of which occurred in 1828 and the rest of which occurred in 1829, so "Senate 1828/29" denotes the "Senate 1828 elections" and the "Senate 1829 elections". Therefore, it is incorrect to say that the table doesn't have entries for 1829 elections, it does. —Alalch E.17:46, 26 January 2025 (UTC)[reply]
@RoySmith: Likely possible; just a matter of figuring out the SQL to do it. But (see discussion with Alalch E. above), you can start with List of elections in the United States, which has hundreds of links to [[:Category: rather than an article on the topic, which likely either exists or is a redirect to a template. Sorry, I didn't mean to open a can of worms here, this proposal should be focused on the 55 mainspace redirects to the T: prefix, not the ~200 mainspace redirects to template namespace that aren't T: prefix – that's another discussion that could potentially disrupt this discussion. – wbm1058 (talk) 19:14, 26 January 2025 (UTC)[reply]
Support. The pseudo-namespaces overall should be deprecated, as these pages bring nothing but future technical debt, but especially in case where the community agreed on a similar alias, the existing pages should just be fixed to match it and ideally removed altogether. I would note that the Big WMF does not actually prohibit T: prefix for template namespace, as it already exists fine in Russian Wikipedia (but we thankfully never adopted enWP’s practice of solving namespace aliases with futile manual labour, so we never had to deal with something like phab:T363538). stjn16:09, 26 January 2025 (UTC)[reply]
Replace links to twitter / "X"
Would it be a good idea to build a scraper and a bot that scrapes tweets and then replaces the link to the tweet to a link to a site populated with scraped tweets? That way we don't send traffic to Twitter or whatever its called these days. Polygnotus (talk) 00:38, 22 January 2025 (UTC)[reply]
@Jéské Couriano: I do not know (I am not a lawyer). I do know Google cache and the Wayback Machine and various other services that would also infringe on copyright, if that is copyright infringement. If the Wayback Machine can archive tweets, we could ask it to index every tweet and then remove every direct link to twitter. Maybe meta:InternetArchiveBot can do this and we only have to supply a list of tweets and then replace the links? Polygnotus (talk) 00:52, 22 January 2025 (UTC)[reply]
Google Cache is defunct and to avoid copyright issues the Wayback Machine removes archives on request. It also no longer works with Twitter. PARAKANYAA (talk) 22:51, 23 January 2025 (UTC)[reply]
No. Wikipedia is not the place to try to attempt to voice your concerns with Elon Musk. Unless or until the site becomes actually harmful itself, more than others (i.e. scraping user data or similar), then there is no need to replace those links. Nobody is advocating for replacing links to Reuters, which requires you to sign up for an account and accept email ads/etc. to read articles for free. -bɜ:ʳkənhɪmez | me | talk to me!01:00, 22 January 2025 (UTC)[reply]
until the site becomes actually harmful itself, more than others It is already, right? WP:RGW is about WP:OR and WP:RS, so it is unclear why you linked to it and it appears to be offtopic. Reuters, which requires you to sign up for an account and accept email ads/etc. to read articles for free. It does? I have never seen that (but I am using ublock and pihole and various related tools). Polygnotus (talk) 01:05, 22 January 2025 (UTC)[reply]
Why should Wikipedia be concerned what websites get traffic? If it's about the political views or actions of its owner or its userbase, then that's absolutely against the spirit of "righting great wrongs" in a literal sense, even if it's not what's specifically covered in WP:RGW. Thebiguglyalien (talk) 05:00, 23 January 2025 (UTC)[reply]
We already do apply, and for a long time have applied, this concept of concerning ourselves about the behaviour of the target site, to external hyperlinks that lead to copyright violating WWW sites. See Project:External links#Restrictions on linking. So the question becomes one of whether we should start concerning ourselves with behaviours other than copyright violation, spam, and harassment. I think that the answer is that no, we should not start concerning ourselves with sending traffic, especially as we had that discussion years ago when MediaWiki was changed to tell WWW browsers to not automatically pre-load the targets of external hyperlinks. Rather we should concern ourselves with whether we should be hyperlinking to Twitter posts, copied elsewhere or no, at all. That is a source reliability issue, and we already have the answer at Wikipedia:Reliable sources/Perennial sources#Twitter. Given that the blue checkmark is no longer a marker of account verification, and that it is possible to impersonate people who have since left Twitter since wholly deleted account names become available for re-use, what is said there about the problems confirming the identity of the author is now an even greater factor in source unreliability than it was a few years ago. Then there's what has been pointed out in this discussion about archiving services being unable to archive much of Twitter now. Uncle G (talk) 09:56, 25 January 2025 (UTC)[reply]
~~Agree that it's better not to send traffic to Twitter, but I don't know if Twitter is exactly getting a lot of traffic through Wikipedia, and in any case linking to the actual tweet (the actual source) is important.~~ Other users suggested archives. I oppose replacing links with links to a scraper, but I wouldn't oppose replacing links with links to the Internet Archive, for example -- something reputable. Mrfoogles (talk) 21:22, 22 January 2025 (UTC)[reply]
Personally I'm not sure it's a good idea, but I don't think it's just "virtue signaling". Obviously the effect will not be enormous, but it will help slightly (all the subreddits together, even though they're small, have some effect) and it's good to have sort of statements of principle like this, in my opinion. As long as the goal is to actually not tolerate Nazism, rather than appear to not tolerate Nazism, I don't think it's virtue signaling. Mrfoogles (talk) 20:48, 23 January 2025 (UTC)[reply]
So our express political purpose is anti-Musk then? Because that would confirm what he says about us in that way. Or what other reason do we have to do this? PARAKANYAA (talk) 02:15, 24 January 2025 (UTC)[reply]
@Polygnotus what is the specific reason you are suggesting this is something that should be implemented? I'm a terrible mind reader, and wouldn't want to make presumptions of your motives for you. TiggerJay(talk)01:21, 23 January 2025 (UTC)[reply]
There is clear and obvious value in ensuring all {{cite twitter}} or {{cite web}} URLs have archive URLs, what with Musk's previously shortly-held opinion about the value of externally accessible URLs. Other than that, I see little reason to "switch" things. Izno (talk) 22:23, 23 January 2025 (UTC)[reply]
There is also the fact that for the past two and a bit years there has been a movement amongst erstwhile Twitter users to delete all of their posts. So ignoring whether the URLs become walled off behind a forced site registration, there's the fact that they might nowadays point to posts that no longer exist, the same issue that we have with link rot in general. And others have observed in this discussion that archiver services do not ameliorate this, as they have various difficulties themselves with Twitter, which they themselves report. Twitter militates against archive services. In the end, I doubt that any sort of newly grown archiving service could do better, as it would be quickly discovered and countered by Twitter as the existing ones already are. Uncle G (talk) 09:56, 25 January 2025 (UTC)[reply]
Most archiving services don’t work with Twitter anymore. Archive.org doesn’t and archive.is does it poorly. The only one that works consistently is GhostArchive which has been removed before over copyright concerns. For similar reasons, existing Twitter mirrors like Nitter are either defunct or broken. This would amount to removing all Twitter links then. PARAKANYAA (talk) 22:35, 23 January 2025 (UTC)[reply]
There is already tight guidelines on where and how tweets can be used in articles, and I don't think that it is any more prevalent than it is from any other primary source website. While the use of such primary sources need to be closely monitored in any article, there are places where its inclusion is appropriate and helpful, but it certainly is on the rare side of things. I also would proffer that if the main reason to prevent having links directly to twitter is some sort of virtue signaling we're going to get into a world of problems as the values and moralities of people in Wiki differ greatly. Should we then drop all links to Russian websites to support Ukraine? What about when it comes down to PIA issues or other areas of great contention? This would be murky waters that is best avoided all together. TiggerJay(talk)22:47, 23 January 2025 (UTC)[reply]
Having to build and maintain our own scraping service would have high costs in terms of software engineers to build the service, then software engineers to maintain it forever. We'd also basically be reinventing the wheel since FOSS organizations like Internet Archive already do scraping. Would recommend continuing with the status quo, which is linking to Twitter, and having Internet Archive do the scraping in case the main link dies. –Novem Linguae (talk) 00:34, 24 January 2025 (UTC)[reply]
Note what is written above about archivers not working with Twitter. Various archiving services themselves have warning about their greatly limited abilities or even outright inability to archive Twitter nowadays. See Blumenthal, Karl. "Archiving Twitter feeds". archive-it.org. for one example, where an archive services notes that it is greatly limited to archiving only what can be seen by people without Twitter accounts. Uncle G (talk) 09:56, 25 January 2025 (UTC)[reply]
I think we need to be taking a harder line on citations and external links to Tweets, but not because of any recent actions by its owner. I rarely come across citations/links to tweets that aren't flagrant violations of WP:RSPTWITTER, WP:SPS, WP:ABOUTSELF and WP:TWITTER-EL. If recent events give impetus to a crackdown on overuse of tweets, I won't be opposed to it. But scraping and changing links, when there's not yet been any indication of an urgent need to do so (unlike, say, with THF), then I think that would be a bit overkill. --Grnrchst (talk) 10:36, 25 January 2025 (UTC)[reply]
OK, so this is a little bit of a long read, and for some, a history lesson. So, most of my time on Wikipedia, I've been involved in our dispute resolution processes, including MedCab, talk page mediation and other works. Back in June of 2011, I created the dispute resolution noticeboard, which I proposed in this discussion. I designed this as a lightweight process to make dispute resolution more accessible to both volunteers and editors, providing a clearer entry point to dispute resolution, referring disputes elsewhere where necessary.
For a time, this was quite effective at resolving content disputes. I stayed involved in DR, eventually doing a study on Wikipedia and our dispute resolution processes (WP:DRSURVEY), and out of that, high level, we found that too many forums for dispute resolution existed, and dispute resolution was too complex to navigate. So, out of that, a few changes were made. Wikipedia:Dispute resolution requests and the associated guide was created to help editors understand the forums that existed for resolving disputes, and a few forums were closed: Wikiettiquite assistance was closed in 2012, and as many now found MedCab redundant to the lighter-weight DRN and formal mediation, it sparked a conversation on the MedCab talk page and Mediation Committee talk page in favour of closing. This is something, as one of the coordinators of MedCab at the time, that I supported. It truly was redundant to DRN and there was some agreement at the time that more difficult cases could be referred to MedCom.
However, back in 2018, MedCom was closed as the result of a proposal here, with the thought process that it was perhaps too bureaucratic and not very active/did not accept many cases, and it's effectiveness was limited, so it was closed. While RFCs do exist (and can be quite effective), the remaining dispute resolution forum (DRN) was never designed to handle long, complex disputes, and had to be shifted elsewhere. This has, in some ways, required DRN to morph into a one-size fits all approach, with some mediations moved to talk pages (Talk:William Lane Craig/Mediation, Wikipedia:Dispute resolution noticeboard/Autism) among others. The associated complexity and shift away from its lightweight original structure and ease of providing assistance on disputes has had an impact on the amount of active volunteers in dispute resolution, especially at DRN.
So, my thoughts boil down to a review of Wikipedia dispute resolution and where some sort of structured process, like mediation could work. My initial thoughts about how content DR could work is:
Third opinion - content issue between 2 editors on a talk page, limited responses on the talk page by a third party
Mediation: Complex content disputes where assistance from a DR volunteer/mediator can help resolve the issues, or on occasion, frame the issues into a few cohesive proposals for further community input / consensus building
WP:RFC: Where broader community input is required, generally on a well defined proposal (and the proposal may have come organically, or formed as a result of another dispute resolution process)
The idea would be that DRN would be returned to its lightweight, original format, which could encourage it's use again (as there's been feedback that DRN is now also too bureaucratic and structured, which may discourage editors and potential volunteers alike) and informal mediation (or MedCab - name I'm not decided on at this stage) could take on the more complex issues. While RFCs have value, not every dispute is suitable for an RFC, as guidance on some disputes is needed to form cohesive proposals or build consensus. Having mediation as an option, historically, was a benefit, with many successes out of the processes. I think it's time for us to consider reviving it. StevenCrossinHelp resolve disputes!09:57, 25 January 2025 (UTC)[reply]
Oppose. The proposal is unclear and DRN is already the dispute resolution venue based on the idea that "assistance from a DR volunteer/mediator can help resolve the issues, or on occasion, frame the issues into a few cohesive proposals for further community input / consensus building".—Alalch E.17:23, 25 January 2025 (UTC)[reply]
The header on DRN was changed over time with little discussion. It was originally quite barebones, and is one of the items that will be changed back to how it was originally (see User:Steven Crossin/DRNHeader for an example. I’d encourage you to read over the history of informal mediation (MedCab) as it will give some context to how it worked (it was closed quite some time ago). The proposal is to simplify DRN to its original design - lightweight with simple processes and minimal structure, and re-establish our informal mediation process. MedCab was quite successful as a process back in the day, but DRN performs the role of complex dispute resolution poorly - a noticeboard was never going to be the best way to handle these sorts of disputes (and as such, is why DRN was intended to be lightweight). StevenCrossinHelp resolve disputes!23:19, 25 January 2025 (UTC)[reply]
Support as a working mediator at DRN. This idea can be seen as defining two tracks for content disputes, a lightweight track and a somewhat more formal track for more difficult disputes. I do not really care whether we have one name for the forum for the two weights of content disputes or two names, but I think that it will be useful to recognize that some cases are simpler than others. It is true that the parties and the volunteer may not know until starting into a dispute whether it is simple or difficult, so maybe most content disputes should start off being assumed to be simple, but there should be a way of changing the handling of a dispute if or when it is seen to be complex. This proposal is a recognition that content disputes are not one size, and one-size-fits-all dispute resolution is not available. Robert McClenon (talk) 03:58, 26 January 2025 (UTC)[reply]
Support per Steven and Robert. My outsider's perspective of DRN is that it is very bureaucratic, but also not great at handling complex, intractable cases, especially where animosity has built up between involved editors. (Please correct me if this assessment is inaccurate.) I think it makes sense to "split" it into two venues as proposed. Toadspike[Talk]09:48, 26 January 2025 (UTC)[reply]
I do see that it can be perceived as a bit bureaucratic, yes, and can struggle with some more difficult disputes. It used to be much more simple and less rules focused - ideally re-establishing MedCab would allow DRN to return to it simple origins, perhaps even allowing DRNs simplified structure to be more conducive to new volunteers participating. A possible style of how a dispute at DRN could look, with perhaps even less structure, is Wikipedia:Dispute resolution noticeboard#Jehovah's Witnesses (which, full disclosure, is one that I handled and is an example of my style of dispute resolution). StevenCrossinHelp resolve disputes!09:58, 26 January 2025 (UTC)[reply]
How you handled that dispute does not require a new project page for a new process. Everything can take place at the existing WP:DRN. The DRN volunteers can opt for the less or more formal process upon their discretion. Just like you did here. —Alalch E.13:04, 26 January 2025 (UTC)[reply]
No, it didn’t. This is a simple one. But disputes like Talk:William Lane Craig/Mediation and some others that were forked/moved away from previous DRN discussions would benefit from this revived forum (as a noticeboard is not conducive to dispute resolution for drawn out, complex issues. How disputes are handled on DRN is open for interpretation by the volunteers, but there’s agreement among at least Robert and I (two of the main DRN volunteers) that having distinct dispute resolution process for simple versus complex disputes would be of benefit. StevenCrossinHelp resolve disputes!13:10, 26 January 2025 (UTC)[reply]
I agree that the dispute that was processed there was a complex one, but so is Wikipedia:Dispute resolution noticeboard/Autism. So, here, we are discussing two approaches to resolving complex disputes. The approach exhibited in your example is like a three-sided peer review (similar to Wikipedia:Peer review, except it isn't just the requester and the reviewer, there's also the "other side"; but the reviewer does indeed break content down sentence by sentence as in a peer review, and make editorial assessments), and the approach taken by Robert McClenon is more like a formal debate. Do you think there's something wrong with the ongoing autism dispute resolution? Can both methods not coexist as different approaches to problems of similar complexity? —Alalch E.14:11, 26 January 2025 (UTC)[reply]
Oppose, I guess? Frankly, I don't think structured mediation works on Wikipedia. What I have seen work (constantly) is: 1) talk with the other editor, but not uncommonly people will just have fundamentally different views. 2) if so, advertise to a noticeboard to get more editors to weigh in. If a specialised noticeboard captures the dispute, then any of: WP:FTN, WP:NPOVN, WP:BLPN, etc; otherwise WP:3O. That seems to work for most small to medium trafficked articles. 3) Failing that, WP:RFC.I can't remember when I last saw a dispute that mediation resolved. I mean, here's a random DRN archive: Wikipedia:Dispute_resolution_noticeboard/Archive_252. The discussion closures are: "opened by mistake", "premature", "withdrawn by filer", "not an issue for DRN", "closed - RFC is being used", "closed - not discussed in the proper forum", "participation declined by one editor, withdrawn by filer", "closed - one participant is an IP editor with shifting IPs", "closed as abandoned", "closed due to lack of response", "filed in wrong venue", "closed - pending at ANI", "closed as pending at WP:RSN", "closed as DRN can't be helpful here", "other editor hasn't replied", "apparently resolved - one editor has disappeared", "premature", "wrong venue", ... I kid you not, I haven't skipped any sections out, I just went off the top of the archive. Given this, it's hard to seriously say that mediation works. And it sort of lines up with my anecdotal experiences: it's pretty common for editors to never really come to a compromise agreement that all parties are happy with. Ultimately, a lot of content disputes are decided by '(maybe some compromise) and majority wins' or 'one participant disappears / gives up' or 'some compromise and universal agreement'. Though, the cases where 'some compromise and universal agreement' works appears so much like a discussion that we wouldn't even call it a dispute, and I think any cases that could be successful through mediation, the editors could've just figured it out among themselves anyway. ProcrastinatingReader (talk) 18:16, 26 January 2025 (UTC)[reply]
I wish mediation would work more effectively in more complex disagreements on English Wikipedia. Unfortunately, as I discussed elsewhere, it doesn't scale up well to handle disputes with a lot of participants (in the real world, the mediation participants are limited to representatives for the relevant positions), and it requires sustained participation over a substantial period of time, which doesn't work well with Wikipedia's volunteer nature. For mediation to work, the community has to be willing to change something in its decision-making approach to overcome these challenges. For better or worse, I don't see sufficient signs of desire to change in this manner. isaacl (talk) 18:41, 26 January 2025 (UTC)[reply]
Idea lab
The prominence of parent categories on category pages
The format of category pages should be adjusted so it's easier to spot the parent categories.
I can see the Subcategories. Great. I can see the Pages in the category. Great. No parent categories. That's a shame --- discovering the parent categories can be as helpful as discovering the subcategories.
Actually, the parent categories are there (well, I think they are --- I'm not sure because they're not explicitly labelled as such). But I don't notice them because they're in a smaller font in the blue box near the bottom of the page:
Categories: Water | Chemical processes | Technology by type
I think the formatting (the typesetting) of the parent categories on category pages should be adjusted to give the parent categories the same prominence as the subcategories. This could be done by changing:
Categories: Water | Chemical processes | Technology by type
to:
Parent categories: Water | Chemical processes | Technology by type
and increasing the size of the font of `Parent categories', or, perhaps better, by having the parent categories typeset in exactly the same way as the subcategories. D.Wardle (talk) 22:21, 22 December 2024 (UTC)[reply]
The purpose of an article page is to give a clear exposition of the subject. Having a comprehensive presentation of the categories on such a page would be clutter --- a concise link to the categories is sufficient and appropriate.
The purpose of a category page is to give a comprehensive account of the categories. A comprehensive presentation of the categories would not clutter the subject (it is the subject).
Therefore, I do not expect the parent categories to be presented the same on article and category pages --- if they are presented the same, that only reinforces my opinion that some change is necessary. D.Wardle (talk) 20:15, 27 December 2024 (UTC)[reply]
I think the purpose of a category page is to help you find the articles that are in that category (i.e., not to help you see the category tree itself). WhatamIdoing (talk) 21:40, 27 December 2024 (UTC)[reply]
I don't think so, though I asked a WMF staffer to pull numbers for me once, which proved that IPs (i.e., readers) used categories more than I expected. I had wondered whether they were really only of interest to editors. (I didn't get comparable numbers for the mainspace, and I don't remember what the numbers were, but my guess is that logged-in editors were disproportionately represented among the Category: page viewers – just not as overwhelmingly as I had originally expected.) WhatamIdoing (talk) 22:43, 27 December 2024 (UTC)[reply]
I'm fine with parent categories being displayed the same way on articles and categories but I think it's a problem that parent categories aren't displayed at all in mobile on category pages, unless you are registered and have enabled "Advanced mode" in mobile settings. Mobile users without category links probably rarely find their way to a category page but if they do then they should be able to go both up and down the category tree. PrimeHunter (talk) 15:39, 28 December 2024 (UTC)[reply]
Am I missing something? Is there a way of seeing the category tree (other than the category pages)?
Now there are three words I would like to see added to every category page. As well as `parent' prefixing `categories' in the blue box (which prompted this discussion), I would also like `Category tree' somewhere on the page with a link to the relevant part of the tree (for example, on:
I can only reiterate that I think I'm typical of the vast majority of Wikipedia users. My path to Wikipedia was article pages thrown up by Google searches. I read the articles and curious to know how the subject fitted into wider human knowledge, clicked on the category links. This led to the category pages which promised so much but frustrated me because I couldn't find the parent categories and certainly had no idea there was a category tree tool. This went on for years. Had the three additional words been there, I would have automatically learned about both the parent categories and the category tree tool, greatly benefitting both my learning and improving my contributions as an occasional editor. Three extra words seems a very small price to pay for conferring such a benefit on potentially a huge fraction of users. D.Wardle (talk) 03:43, 30 December 2024 (UTC)[reply]
I've looked at what you've done (and hopefully understood). MediaWiki:Pagecategories puts some of the words in the blue box at the bottom of all category pages. But what code makes the category pages (what code calls MediaWiki:Pagecategories)? I think the changes I'm suggested should be made to that calling code... D.Wardle (talk) 23:35, 9 January 2025 (UTC)[reply]
I looked at the MediaWiki Help and Manual. How the formatting of namespaces is controlled might be discussed somewhere, but, at the very least, it's not easy to find (I didn't find it). I've requested this be addressed (https://www.mediawiki.org/wiki/Help_talk:Formatting#The_formatting_of_namespaces) but, thus far, no one has volunteered.
Returning to the issue here, my inference is that `normal' Wikipedia editors would not be able to implement the changes I'm suggesting (adding the word `parent' and a link to the category tree) assuming the changes were agreed upon. I therefore also conclude that the changes I'm suggesting do need to go to Village_pump_(proposals). Do you agree? D.Wardle (talk) 23:29, 17 January 2025 (UTC)[reply]
You are right that PrimeHunter's solution works but (not wishing to criticize PrimeHunter in any way --- I'm grateful for their input) I don't think it's the right way to do it. To explain: When an editor adds a section to an article, the edit box is initially blank. There is no code to specify e.g. the font, the size of the font, the colour of the font, the indentation from the margin, etc. These things must be specified somewhere but they are hidden from the editor. And that's a good feature (it enables the editor to do their work without having to wade through a whole heap of code specifying default formatting which isn't relevant to them). PrimeHunter's solution goes against that principle --- it's adding formatting code to the editor's box. You might argue that it's only a very small piece of code, but, if changes are routinely made in this way, over time the small pieces of code will accumulate and the editor's boxes will become a mess. D.Wardle (talk) 21:00, 18 January 2025 (UTC)[reply]
Agreed. And (I think you already understand this) that is because PrimeHunter's edit of testwiki:MediaWiki:Pagecategories affects all pages on https://test.wikipedia.org.
...at the bottom of the edit window (my apologies --- it's not actually in the edit window) --- this is not helpful for novice editors --- they could be confused and/or deterred by it --- it should be hidden from them.
The en.wikipedia page has nothing analogous to the just mentioned text, suggesting that PrimeHunter's solution might not actually work in en.wikipedia.
If editors can't see the list of categories that the page is in, how will they add or remove the categories?
On the testwiki page, the example has only one category, so this is what you see in wikitext:
[[Category:Root category]]
The analogous text in the en.wikipedia page you link is this:
[[Category:Creative Commons-licensed websites]]
[[Category:Online encyclopedias| ]]
[[Category:Virtual communities]]
[[Category:Wikimedia projects]]
[[Category:Wikipedia categories named after encyclopedias]]
[[Category:Wikipedia categories named after websites]]
I thought your concern was about what readers see. You said "But I don't notice them [i.e., the parent categories] because they're in a smaller font in the blue box near the bottom of the page: Categories: Water | Chemical processes | Technology by type".
To begin again, I think it would be a good idea if all category pages had:
a heading `Parent categories' similar to `Subcategories' (the current `Categories' in the blue box is ambiguous and too inconspicuous).
a small link near the bottom of the page, the link having text `Category tree' and target the category's entry in the category tree.
I don't have the technical competence to make either of these changes. Also, given that they would affect every category page (which is a large part of the encyclopedia), before making the changes it would be prudent to check others agree (or, at least, that there is not strong opposition).
The middle option is definitely a step in the right direction so if you could implement it that would be great.
With regard to the third option (and also the link to the category tree), maybe the desirability of these could be put forward for discussion at a meeting of senior Wikipedians (and if they are deemed desirable but difficult to implement maybe that difficulty of implementation could also be discussed --- if the MediaWiki software does not allow desirable things to be done easily, it must have scope for improvement...)
PrimeHunter's solution has only been created in the testsite. Nobody has ever posted it here.
You do not need to be autoconfirmed to see what's in the edit box. You just need to scroll down past the explanation about not being able to change what's in the edit box.
That said, I suggest that you stop looking at the complicated page of 4x4 type square, and start looking at a very ordinary category page like testwiki:Category:Command keys, because (a) it does not have a bunch of irrelevant stuff in it and (b) anyone can edit that cat page. WhatamIdoing (talk) 23:33, 20 January 2025 (UTC)[reply]
Maybe I'm naive, but I think it must be easy to do the two things I'm suggesting. There is a piece of code somewhere that takes the content entered by a Wikipedian using `Edit' and creates the category page. It's just a case of modifying that code to add one word and two words which are also a link. It must be similar to changing a style file in LaTeX or a CSS in html.
Again, maybe I'm naive, but it would seem to me appropriate to move this discussion to Village pump (proposals). Any objection? D.Wardle (talk) 21:07, 4 January 2025 (UTC)[reply]
We should still have an RFC before changing something for everyone, so a formal proposal sounds like a good idea. Otherwise it may be reverted on the opinion of one person. Graeme Bartlett (talk) 21:41, 22 January 2025 (UTC)[reply]
@D.Wardle I looked at your original request and it reminded me that Commons has a gadget (optional user preference) to move the categories box to the tops of all pages. That gadget is at c:MediaWiki:Gadget-CategoryAboveAll.js, and I've found it quite useful when working with files there. It's not quite what you're asking for, but it feels like it might help and be quite an easy win?
Hi Andrew, thanks very much for the info but it doesn't quite address the point I'm making: If Wikipedia is perfectly designed, complete newcomers to the site should discover all the useful features rapidly and by accident (without having to read help pages or similar). At the moment, that's true for the category pages. (A newcomer starts with an article. At the end of the article is `Categories'. Curious, they click on it and discover the category pages.) From the category pages they rapidly discover subcategories. But they are unlikely to discover parent categories (the parent categories being relegated to a small, ambiguous heading at the end of the page). And they certainly won't discover the category tree tool (it being missing all together). So, from my perspective, it's what newcomers see that needs to be changed, not what I see. D.Wardle (talk) 21:25, 23 January 2025 (UTC)[reply]
Implemeting "ChatBot Validation" for sentences of Wikipedia
Hi, I propose to define a "Validation process" using Chatbots (e.g. ChatGPT) in this way:
The editor or an ordinary user, presses a button named "Validate this Sentence"
A query named "Is this sentence true or not? + Sentence" is sent to ChatGPT
If the ChatGPT answer is true, then tick that sentence as valid, otherwise declare that the sentence needs to be validated manually by humans.
I think the implementation of this process is very fast and convenient.
I really think that "ChatBot validation" is a very helpful capability for users to be sure about the validity of information of articles of Wikipedia. Thanks, Hooman Mallahzadeh (talk) 10:34, 6 January 2025 (UTC)[reply]
While it would certainly be convenient, it would also be horribly inaccurate. The current generation of chatbots are prone to hallucinations and cannot be relied on for such basic facts as what the current year is, let alone anything more complicated. Thryduulf (talk) 10:48, 6 January 2025 (UTC)[reply]
Is Wikipedia hallucinations or ChatGPT is hallucinations?
This type of validation (validation by ChatGPT) may be inaccurate for correctness of Wikipedia, but when ChatGPT declares that "Wikipedia information is Wong!", a very important process named "Validate Manually by Humans" is activated. This second validation is the main application of this idea. That is, finding possibly wrong data on Wikipedia to be investigated more accurately by humans. Hooman Mallahzadeh (talk) 11:02, 6 January 2025 (UTC)[reply]
The issue is, ChatGPT (or any other LLM/chatbot) might hallucinate in both directions, flagging false sentences as valid and correct sentences as needing validation. I don't see how this is an improvement compared to the current process of needing verification for all sentences that don't already have a source. Chaotic Enby (talk · contribs) 11:13, 6 January 2025 (UTC)[reply]
If there was some meaningful correlation between what ChatGPT declares true (or false) and what is actually true (or false) then this might be useful. This would just waste editor time. Thryduulf (talk) 11:15, 6 January 2025 (UTC)[reply]
@Chaotic Enby@Thryduulf Although ChatGPT may give wrong answers, but it is very powerful. To assess its power, we need to apply this research:
Give ChatGPT a sample containing true and false sentences, but hide true answers
There are many examples of people doing this research, e.g. [8] ranks ChatGPT as examples accurate "88.7% of the time", but (a) I have no idea how reliable that source is, and (b) it explicitly comes with multiple caveats about how that's not a very meaningful figure. Even if we assume that it is 88.7% accurate at identifying what is and isn't factual across all content on Wikipedia that's still not really very useful. In the real world it would be less accurate than that, because those accuracy figures include very simple factual questions that it is very good at ("What is the capital of Canada?" is the example given in the source) that we don't need to use ChatGPT to verify because it's quicker and easier for a human to verify themselves. More complex things, especially related to information that is not commonly found in its training data (heavily biased towards information in English easily accessible on the internet), where the would be the most benefit to automatic verification, the accuracy gets worse. Thryduulf (talk) 11:38, 6 January 2025 (UTC)[reply]
Factual questions are where LLMs like ChatGPT are weakest. Simple maths, for example. I just asked "Is pi larger than 3.14159265?" and got the wrong answer "no" with an explanation why the answer should be "yes":
"No, π is not larger than 3.14159265. The value of π is approximately 3.14159265358979, which is slightly larger than 3.14159265. So, 3.14159265 is a rounded approximation of π, and π itself is just a tiny bit larger."
Any sentence "validated by ChatGPT" should be considered unverified, just like any sentence not validated by ChatGPT. —Kusma (talk) 11:28, 6 January 2025 (UTC)[reply]
I get a perfect answer to that question (from the subscription version of ChatGPT): "Yes. The value of π to more digits is approximately 3.141592653589793… which is slightly larger than 3.14159265. The difference is on the order of a few billionths." But you are correct; these tools are not ready for serious fact checking. There is another reason this proposal is not good: ChatGPT gets a lot of its knowledge from Wikipedia, and when it isn't from Wikipedia it can be from the same dubious sources that we would like to not use. One safer use I can see is detection of ungrammatical sentences. It seems to be good at that. Zerotalk11:42, 6 January 2025 (UTC)[reply]
It's a good example of the challenges of accuracy. Using a different prompt "Is the statement pi > 3.14159265 true or false?", I got "The statement 𝜋 > 3.14159265 is true. The value of π is approximately 3.14159265358979, which is greater than 3.14159265." So, whatever circuit is activated by the word 'larger' is doing something less than ideal, I guess. Either way, it seems to improve with scale, grounding via RAG or some other method and chain of thought reasoning. Baby steps. Sean.hoyland (talk) 11:51, 6 January 2025 (UTC)[reply]
I do not think we should outsource our ability to check whether a sentence is true and/or whether a source verifies a claim to AI. This would create orders of magnitude more problems than it would solve... besides, as people point out above, facts is where chatbots are weakest. They're increasingly good at imitating tone and style and meter and writing nicely, but are often garbage at telling fact from truth. Cremastra (u — c) 02:22, 7 January 2025 (UTC)[reply]
Writing a script that would automatically give a "validation score" to every article—average probability of True vs. False across all sentences—would be helpful. (Even if it completely sucks, we can just ignore it, so there's no harm done.) Go ahead and do it if you know how! However, WMF's ML team is already very busy, so I don't think this will get done if nobody volunteers. – Closed Limelike Curves (talk) 04:41, 11 January 2025 (UTC)[reply]
Using ChatBots for reverting new edits by new users
Even though the previous idea may have issues, I really think that one factor for reverting new edits by new users can be "the false answer of verification of Chatbots". If the accuracy is near 88.7%, we can use that to verify new edits, possibly by new users, and find vandalism conveniently. Hooman Mallahzadeh (talk) 13:48, 6 January 2025 (UTC)[reply]
Even if we assume the accuracy to be near near 88.7%, I would not support having a chatbot to review edits. Many editors do a lot of editing and getting every 1 edit out of 10 edit reverted due to an error will be annoying and demotivating. The bot User:Cluebot NG already automatically reverts obvious vandalism with 99%+ success rate. Catalk to me!14:11, 6 January 2025 (UTC)[reply]
instead of an inventor, this sentence wrongly declares that he was an engineer. Can User:Cluebot NG detect this sentence automatically as a wrong sentence?
So I propose to rewrite User:Cluebot NG in a way that it uses Chatbots, somehow, to semantically check the new edits, and tag semantically wrong edits like the above sentence to "invalid by chatbot" for other users to correct that. Hooman Mallahzadeh (talk) 14:22, 6 January 2025 (UTC)[reply]
Can Cluebot detect this sentence automatically as a wrong sentence? No. It can't. Cluebot isn't looking through sources. It's an anti-vandalism bot. You're welcome to bring this up with those that maintain Cluebot; although I don't think it'll work out, because that's way beyond the scope of what Cluebot does. SmittenGalaxy|talk!19:46, 6 January 2025 (UTC)[reply]
I think you, Hooman Mallahzadeh, are too enamoured with the wilder claims of AI and chatbots, both from their supporters and the naysayers. They are simply not as good as humans at spotting vandalism yet; at least the free ones are not. Phil Bridger (talk) 20:46, 6 January 2025 (UTC)[reply]
The number of false positives would be too high. Again, this would create more work for humans. Let's not fall to AI hype. Cremastra (u — c) 02:23, 7 January 2025 (UTC)[reply]
The User:Cluebot NG does not check any semantics for sentences. These semantics can only be checked by Large Language Models like ChatGPT. Please note that every Wikipedia sentence can be "semantically wrong", as they can be syntacticly wrong.
But LLMs are not good at checking the accuracy of information, so Cluebot NG would not be more accurate, and in being less accurate would behave in a more BITEY manner to new editors. -- LCU ActivelyDisinterested«@» °∆t°17:24, 7 January 2025 (UTC)[reply]
Maybe ChatGPT should add a capability for "validation of sentences", that its output may only be "one word": True/False/I Don't know. Specially for the purpose of validation.
Validation is not a binary thing that an AI would be able to do. It's a lot more complicated than you make it sound (as it requires interpretation of sources - something an AI is incapable of actually doing), and may require access to things an AI would never be able to touch (such as offline sources). —Jéské Courianov^_^vthreadscritiques17:37, 7 January 2025 (UTC)[reply]
(edit conflict × 4) For Wikipedia's purposes, accuracy is determined by whether it matches what reliable sources say. For any given statement there are multiple possible states:
Correct and supported by one or more reliable sources at the end of the statement
Correct and supported by one or more reliable sources elsewhere on the page (e.g. the end of paragraph)
Correct and self-supporting (e.g. book titles and authors)
Correct but not supported by a reliable source
Correct but supported by a questionable or unreliable source
Correct according to some sources (cited or otherwise) but not others (cited or otherwise)
Correct but not supported by the cited source
Incorrect and not associated with a source
Incorrect and contradicted by the source cited
Incorrect but neither supported nor contradicted by the cited source
Neither correct nor incorrect (e.g. it's a matter of opinion or unproven), all possible options for sourcing
Previously correct, and supported by contemporary reliable sources (cited or otherwise), but now outdated (e.g. superceded records, outdate scientific theories, early reports about breaking news stories)
Both correct and incorrect, depending on context or circumstance (with all possible citation options)
Previously incorrect, and stated as such in contemporary sources, but now correct (e.g. 2021 sources stating Donald Trump as president of the US)
Correct reporting of someone's incorrect statements (cited or otherwise).
Predictions that turned out to be incorrect, reported as fact (possibly misleadingly or unclearly) at the time in contemporary reliable sources.
And probably others I've failed to think of. LLMs simply cannot correctly determine all of these, especially as sources may be in different languages and/or not machine readable. Thryduulf (talk) 17:44, 7 January 2025 (UTC)[reply]
I believe someone else had a working implementation of a script that would verify whether a reference supported a claim using LLMs - I think I saw it on one of the Village Pumps a while back. They eventually abandoned it because it wasn't reliable enough, if I remember correctly. — Qwerfjkltalk16:46, 20 January 2025 (UTC)[reply]
It probably struggles to understand meaning. On the other hand, I reckon you could get a working implementation to look for copyvio. CMD (talk) 18:02, 20 January 2025 (UTC)[reply]
Even professional-grade plagiarism detectors are poor at that, generating both false positives and false negatives. That's fine in the environment where they are used with full understanding of the system's limitations and it is used only as one piece of information among multiple sources by those familiar with the topic area. Very little of that is true in the way it would be used on Wikipedia. Thryduulf (talk) 18:49, 20 January 2025 (UTC)[reply]
AfD's taking too long
I've noticed that a lot of AfD's get relisted because of minimal participation, sometimes more than once. This means that in the instance where the article does get deleted in the end, it takes too long, and in the instance where it doesn't, there's a massive AfD banner at the top for two, sometimes three or more weeks. What could be done to tackle this? How about some kind of QPQ where, any editor that nominates any article for deletion is strongly encouraged to participate in an unrelated AfD discussion? -- D'n'B-📞 -- 06:59, 7 January 2025 (UTC)[reply]
The banners signal to a reader that there's something wrong with a page - in the case of an AfD there may well not be. -- D'n'B-📞 -- 06:30, 8 January 2025 (UTC)[reply]
There's often a concern, and all relisted nominations seem to have reason to debate that concern, whether because someone registered an objection or the article was already nominated in the past. Aaron Liu (talk) 12:25, 8 January 2025 (UTC)[reply]
We already have WP:NOQUORUM which says that if an AfD nomination has minimal participation and meets the criteria for WP:PROD, then the closing admin should treat it like an expired PROD and do a soft deletion. I remember when this rule was first added, admins did try to respect it. I haven't been looking at AfD much lately—have we reverted back to relisting discussions? Mz7 (talk) 08:10, 7 January 2025 (UTC)[reply]
Okay, and I'm talking about encouraging that discussion to actually happen rather than fizzle out - so we're on the same page here? -- D'n'B-📞 -- 08:58, 12 January 2025 (UTC)[reply]
In my experience relisting often does lead to more comments on the AFD, in practice. So the system works, mostly -- as long as the nominator doesn't have to stick around for the whole time, I don't think there's a problem. And if the page is well-frequented enough for the banner to be a problem, the AFD will probably be relatively well-attended. Mrfoogles (talk) 20:40, 23 January 2025 (UTC)[reply]
Is it possible to start the process of sunsetting the "T:" pseudo-namespace?
In the sense that, with the creation of the [[TM:]] alias in early 2024 from T363757, I can't think of a single reason why a new "T:" space redirect would ever need to exist.
The difference is though, now we have the TM: alias. Just as it makes little sense to foster a "W:" shortcut for "WP:" titles, it really does not make sense to keep "T:" around when "TM:" is just another character more. H for Help and P for Portal don't have that luxury of an alias at this time, but templates do. There's hardly anything left on Special:PrefixIndex for T: titles. And I don't think we should necessarily delete everything at once. But it might be nice to make a hard rule that we don't need any more T: titles, especially so when TM: is the vastly preferable option at this time, from my POV.
I would suggest this as a proposal, but wanted to get feedback to see what else might need to happen in order to start sunsetting? Many of these have little to no links, but a lot of them do. Should these be replaced? Would it be worth the editing cost? I think the payoff is phenomenal - allowing easier navigation to actual articles that start with "T:", of which there are several. Utopes(talk / cont)16:00, 9 January 2025 (UTC)[reply]
For sure. As it happens, T:CENT only has 112 incoming links which almost entirely consist of archives, and it seems like there could be a bot (or a person, honestly) who could run through and fix the links to TM:CENT instead. Because this would be a sunset, I predict that really the only two functions that might actually want to hold onto these for a bit would be DYK and ITN. But even then, I don't necessarily want to delete every single T: title we have right now, but maybe slowly over time we could get to that point. In the interim, anything that T: does, TM: does better in a less harmful way, as TM: works for 100% of templates while T: works for 0%. Creating a note in WP:Shortcut#Pseudo-namespaces that "Newly created T: titles from the years 2025 and later are no longer permissible / are against consensus" could be a start. If it's indeed true that that is the case, of course, I have no idea. Hence a proposal to see where people are at re: T: titles. Utopes(talk / cont)00:54, 10 January 2025 (UTC)[reply]
Regarding DYK, it currently has a few different T: shortcuts for the preps and queues as well. A sunset might have to exclude potential fiddling in this area. CMD (talk) 19:05, 20 January 2025 (UTC)[reply]
Better methods than IP blocks and rangeblocks for completely stopping rampant recurring vandals
So, I intend for this thread to be about the discussion of various theoretical methods other than IP blocks / rangeblocks that could be used to mitigate a persistent vandal highly effectively while causing little to no collateral damage.
Some background
Wikipedia was founded in 2001, a time when a good majority of residential IP addresses were relatively all static, due to the much lesser number of internet users at that time. IP blocks probably made a lot of sense at that time due to that fact - you couldn't just reboot your modem to obtain a new IP address and keep editing, and cell phones pretty much had no usable web browsing capability at the time.
Today, the only type of tool used to stop anonymous vandals and disruptors, despite dynamic IP addresses and shared IPs being very common, is still the same old IP address blocks and range blocks. While IP block are effective at stopping the "casual" / "one-off" type of vandals from editing again, when it comes to the more dedicated disruptors and LTAs, IP blocks simply don't seem to hinder them at all, due to the highly dynamic IP address nature. Okay, but range blocks exist, right? Well, unfortunately not all IP address allotment sizes are the same, and it varies a lot from ISP to ISP - some ISPs just seem to put literally all their customers on one gigantic (i.e. /16 or bigger for IPv4, /32 or bigger for IPv6) subdivision, making it straight up impossible to put a complete stop to the LTA vandal without also stopping all those thousands and thousands of innocent other people from being able to edit.
I've always had these thoughts in my mind, about what the Wikimedia team could potentially do / implement to more accurately yet effectively put a complete halt to long-term abusers. But I felt like now's the time we really could use some better method to stop LTAs, as there are just sooooo many of them today, and soooo much admin time/effort is being spent trying to stop them only for them to come back again and again because pretty much the only way to stop them is to literally block the entire ISP from editing Wikipedia.
The first thing that might come to one's mind, and probably the most controversial method too, is disabling anonymous editing entirely and making it so only registered editors can edit English Wikipedia. Someone pointed out to me before that the Portuguese Wikipedia is a registration-only wiki. I tried it out for myself, and indeed when you click the edit button while not logged in, you are brought to an account login page. I'm guessing ENwiki will never become like this because it would eliminate a large and thriving culture of "casual" type of editors who don't want to register an account and just simply want to fix a typo, update a table's data or add a small sentence. It's probably not 100% effective either, as a registered-only wiki still wouldn't stop someone from creating a whole bunch of throwaway accounts to keep vandalising, and account creation blocks on IP addresses could still be dodged by, you know, the modem power plug dance or good ol' proxies/VPNs.
I've noticed some other language wikis like the German Wikipedia have "pending changes" type protection pretty much enabled on every single page. I imagine this isn't going to work on the English Wikipedia because of the comparatively high volume of edits from anonymous editors compared to DEwiki, as it would overload the pending changes review queue and there just will never be enough active reviewers to keep up with the volume of edits.
Now here are some of my original thoughts which I don't think I've seen anyone discuss here on Wikipedia before. The first of which, is hardware ID (HWID) bans or "device bans". The reason why popular free-to-play video games like League of Legends, Overwatch 2, Counter-Strike 2 etc aren't overrun with non-stop cheaters and abusers despite them being free-to-play is because they employ an anti-cheat and abuse system that will ban the serial numbers of the computer, rather than just simply banning the user or their IP address. Now, I have heard of HWID spoofing before, but cheating isn't rampant in these games anyway so I guess they are effective in some form. Besides replacing hardware, one could theoretically use a virtual machine to evade the HWID ban, but virtual machines don't provide the performance, graphics acceleration and special features needed to get a modern multiplayer video game to work. However though, I could see virtual machines as being a rather big weakness for Wikipedia HWID bans, as a web browser doesn't need a dedicated powerful video card and any of those special features to work; web browsers easily run in virtualised environments. But I guess not a great deal of LTAs are technologically competent enough to do that, and even if they did, spinning up a new VM is significantly slower than switching countries in a VPN.
The second, and probably the most craziest one, is employing some form of mandatory personal ID system. Where, even if you're not going to sign up and only edit anonymously, you will be forced to enter a social security number or passport number or whatever ID number that is completely unique to you, to be able to edit. In South Korea, some gaming companies like Blizzard make you enter a SSN when signing up for an account, which makes it virtually impossible for a person to go to an internet cafe ("PC bang") and make a whole bunch of throwaway accounts and jump from computer to computer when an account/device becomes banned to keep on cheating (see PC bang § Industry impact). One could theoretically get the IDs of family members and friends when they become "ID banned", but after all there are only going to be so few other people's IDs they will be able to obtain, certainly nowhere near on the order of magnitude as the number of available IP addresses on a large IP subnet or VPN. I'm guessing this method isn't going to be feasible for English Wikipedia either, as it completely goes against the simple, "open" and "anonymous" nature of Wikipedia, where not only can you edit anonymously without entering any personal details, but even when signing up for an account you don't even have to enter an email address, only just a password.
A third theoretical method is that what if, the customer ID numbers of ISPs were visible to Wikimedia, and then Wikimedia could ban that ISP customer therefore making them completely unable to edit Wikipedia even if they jump to a different IP address or subnet on that ISP? Or maybe how about the reverse where the ISP themselves ban the customer from being able to access Wikipedia after enough abuse? Perhaps ISPs need to wake up and implement such a site-level blocking policy.
Here's a related "side question": how come other popular online services like Discord, Facebook, Reddit, etc aren't overly infested with people who spam, attack, or otherwise make malicious posts on the site everyday? Could Wikimedia implement whatever methods these services are using to stop potential "long-term abusers"? — AP 499D25(talk)13:29, 12 January 2025 (UTC)[reply]
I just thought of yet another theoretical solution: AI has gotten good enough to be able to write stories and poems, analyse a 1000 page long book, make songs, realistic pictures, and more. Wikipedia already uses AI (albelt a rather primitive and simple one) in the famous anti-vandal bot User:ClueBot NG. What if, we deploy an edit filter based on the latest and greatest AI model, to filter out edits based on past vandalism/disruption patterns? — AP 499D25(talk)13:37, 12 January 2025 (UTC)[reply]
I'll preface this by saying that I have quite a few problems with this idea (although I may be biased because I'm strongly opposed to the direction that modern AI is going); but I'd like to hear why and how you think this would work in more detail. For instance, would the AI filter just block edits outright? Would they be flagged like with WP:ORES? What mechanisms would the hypothetical AI use to detect LTA? How would we reduce false positives? And so on. Thanks, /home/gracen/ (they/them) 17:24, 13 January 2025 (UTC)[reply]
The AI idea I have in mind is a rather "mild" form of system, where it only works on edits based on past patterns of disruption. Take for example, MAB's posts. They are quite easily recognisable from a distance even with the source code obscuring that makes it impossible for traditional edit filters to detect the edits. Maybe an AI could perform OCR on that text to then filter it out?
The AI will not filter out new types of vandalism, or disruptive edits that it isn't "familiar" with. There will be an "input text file" where admins can add examples of LTA disruption for the AI to then watch for any edits that closely resemble those examples. It will not look for, or revert edits that aren't anywhere near as being like those samples. That way I think false positives will be minimised a lot, and of course there shall be a system for reporting false positives much like how there exists WP:EFFP. — AP 499D25(talk)22:44, 13 January 2025 (UTC)[reply]
Ah, thanks! I'm immediately hesitant whenever I hear the word "AI" because of the actions of corporations like OpenAI, among others. However, given what you've just said, I actually think this might be an interesting idea to pursue. I'm relatively new to WP and I've never looked at WP:SPI, so I'd rather leave this to more experienced editors to discuss, but this does seem like a good and ethical application of neural networks and is within their capabilities. /home/gracen/ (they/them) 16:16, 14 January 2025 (UTC)[reply]
The second, and probably the most craziest one, is employing some form of mandatory personal ID system. Where, even if you're not going to sign up and only edit anonymously, you will be forced to enter a social security number or passport number or whatever ID number that is completely unique to you, to be able to edit.
This means that editors will have to give up a large amount of privacy, and the vast majority of people casually editing Wikipedia aren't ready to give their passport number in order to do so. Plus, editors at risk might be afraid of their ID numbers ending in the wrong hands, which is much more worrying than "just" their IP address.
Here's a related "side question": how come other popular online services like Discord, Facebook, Reddit, etc aren't overly infested with people who spam, attack, or otherwise make malicious posts on the site everyday?
They are, it's just that the issue is more visible on Wikipedia as the content is easy to find for all readers, but it doesn't mean platforms like Discord or Reddit aren't full of bad actors too. Chaotic Enby (talk · contribs) 13:38, 12 January 2025 (UTC)[reply]
WMF Legal will reject any sort of privacy invasion similar to requiring a real-world identity check for a person. A HWID ban might be legally feasible (i.e., I've never heard them say that it's already been considered and rejected). It would require amending the Privacy Policy, but that happens every now and again anyway, so that's not impossible. However, I understand that it's not very effective in practice (outside of proprietary systems, which is not what we're dealing with), and the whole project involves a significant tradeoff with privacy: Everything that's possible to track a Wikipedia vandal is something that's possible to track you for advertising purposes, or that could be subpoenaed for legal purposes. Writing a Wikipedia article (in the mainspace, to describe what it is and how it works) about that subject, or updating device fingerprint, might actually be the most useful thing you could do, if you thought that was worth pursuing. If a proposal is made along these lines, then the first thing people will do is read the Wikipedia article to find out what it says.
I understand that when Wikipedia was in its early days, a few ISPs were willing to track down abusive customers on occasion. My impression now is that basically none of them are willing to spend any staff time/expense doing this. We can e-mail their abuse@ addresses (they should all have one), but they are unlikely to do anything. A publicly visible approach on social media might work in a few cases ("Hey, @Name-of-ISP, one of your customers keeps vandalizing #Wikipedia. See <link to WP:AIV>. Why don't you stop them?"). However, if the LTA is using a VPN or similar system, then the ISP we claim they're using might be the wrong one anyway. WhatamIdoing (talk) 03:58, 13 January 2025 (UTC)[reply]
I dont know exactly what is meant by hardware id (something like [9]?), but genrrally speaking most things that come under that heading require you to be using a native app and not a web browser. Web Environment Integrity is a possible exception but was abandoned. Bawolff (talk) 00:13, 14 January 2025 (UTC)[reply]
We do not have access to the MAC addresses when a user is accessing from a web browser. For mobile apps you generally need special permissions to access it, and I suspect our app would be rejected from the app store if we tried. Bawolff (talk) 13:04, 24 January 2025 (UTC)[reply]
Web browsers (Chrome, Edge, Firefox) do not allow a site to access your HWID information. That would be a huge invasion of privacy.
Submitting IDS, SSN, etc is a massive invasion of privacy as well and will make people not want to use wikipedia. Why submit your ID every single time you enter a session on Wikipedia? Not to mention that its very inconvienent. Its also ineffective as you can use fake IDS, unless you want to check everything which would cost millions to employ recognition software, make a request to the databases, wait for a response, and then authorize editing. Manual checking is even worse.
Advanced artificial intelligence to scan wikipedia pages for vandalism, trained on previous vandalism incidents could work but it would be very ineffective. The site is coming on 7 million wikipedia articles, now to give you leniency, lets say that only pages with no protection or auto-confirmed protection are scanned. That would still be the majority of articles and it would cost billions yearly to constantly check each page for vandalism. Abuse filters already cover a lot of common vandalism (replacing words with swear words, blanking, spamming the article with letters, etc) and volunteers go by and check pages to see if vandalism has occurred and revert it.
Registration only editing is not a good idea. Trolls that are even mildly dedicated only need a couple minutes to sign up and vandalize the page again.
Browsers will not hand over MAC address info.
Getting ISP's to block a user just because they vandalized a page is only going to cause controversy. It would be a huge invasion of privacy, "why is wikipedia reaching across their site and attacking me and invading privacy?" would likely be the response. Also VPNs are a thing and ISPs dont want to waste money tracking down a petty vandalizer.
Even with all that in mind, I still think the least we could do is implement an OCR-based edit filtering system where it performs OCR on the output text rather than checking the source code of the edit against regular expressions. Some of the non-stop vandalism that happens on this site everyday involves using strange text or Unicode characters to circumvent what a traditional regex-based edit filter can do. I'm not sure if you have seen an LTA called 'MAB' but they are a vandal responsible for making just about every centralised discussion page and noticeboard on Wikipedia semi-protected. Edit filters simply don't seem able to stop them.
"it would cost billions yearly to constantly check each page for vandalism" - why would it cost billions of dollars for an AI to scan every edit? — AP 499D25(talk)04:23, 25 January 2025 (UTC)[reply]
Part of what motivated me to make this VPIL post is this:
As someone who does recent changes patrolling from time to time and spends a quite a bit of wiki-time in general fighting out LTAs and sockpuppets, I am getting quite tired of vandal-fighting in general - the more and more I do it, the more it feels like I'm a "man fighting a machine" and not someone actually stopping another person's destructive actions. In this present-day world of highly dynamic IP addresses, it's become very difficult to fight a lot of vandals that edit using IPs, as a lot of the time when you block a singular IP address they'll come back and vandalise using another IP address, sometimes within hours or even mere minutes.
Rangeblocks exist as a further solution I already know, and I make rangeblock calculations on the regular when reporting certain IP-hopping editors, but you probably already know the issue with them - the accuracy - both in terms of how much it actually stops the malicious editor, and in terms of how much other constructive editors in that range are affected. The accuracy of rangeblocks varies wildly from ISP to ISP. When they're actually feasible (i.e. the person's different IPs used are all in a range where there's little to none legitimate editors tipping the scale) they work great, but when they're not practicable due to high potential of collateral damage, it becomes a huge pain in the rear, as then you have yet another IP range to monitor the contributions of on your 'watchlist'.
As for page protections, they are conveniently practical when the person is only attacking one page or a small number of pages. But what if they are regularly disrupting dozens/hundreds of different pages every day? I've also never really been a big fan of page protections in general - semi-protection shuts out pretty much every newbie and 'casual' types of editors, who make up a significant percentage of the Wikipedia editor base. I remember seeing some statistic where the number of new editors joining Wikipedia has significantly dropped over the last 20 years. It certainly doesn't help with that. Excluding these groups of editors from editing pages also further contributes to the already bad systemic bias we have on Wikipedia. Furthermore, have you not seen how pages like the Teahouse, Help desk, and all the various admin help noticeboards (e.g. WP:AN) are protected seemingly every day? All caused by one person hopping from proxy to proxy and circumventing edit filters with special characters. If that wasn't bad enough, take a look at their talk pages. All in all, in other words: page protection comes with its own "collateral damage" much like shared IP range blocks. — AP 499D25(talk)04:52, 25 January 2025 (UTC)[reply]
The solution to that is probably better character normalization for the regexes. Not OCR. OCR would probably be easier to trick than the current system. Bawolff (talk) 08:05, 26 January 2025 (UTC)[reply]
An interesting idea I saw on the internet (Which is probably not viable here, but interesting nonetheless) is https://github.com/zk-passport/openpassport which the blockchain people have been working on. Essentially blockchain stuff has a similar problem where they worry about people having sockpuppets. They've devised a system where you can use your passport to prove that you don't have any sockpuppets without revealing any private data from the passport. Its hard to imagine that gaining traction here, but its one of the first genuinely new ideas to solve the sockpuppet problem that I have heard in a long time. Bawolff (talk) 13:48, 26 January 2025 (UTC)[reply]
Give patrollers the suppressredirect right?
As part of New Page Patrol, a lot of articles are draftified, which is done by moving the it to the Draft: or User: namespace. The problem is that without page mover rights, patrollers are forced to leave redirects behind, which are always deleted under speedy deletion criterion R2. Giving patrollers the suppressredirect right would make the process easier and reduce workload for admins. What do you think? '''[[User:CanonNi]]''' (talk • contribs)11:02, 13 January 2025 (UTC)[reply]
Draftifying is happening far too much. But the idea has merit, as then the last log entry will say the page was moved, rather than a redirect deleted. Graeme Bartlett (talk) 11:11, 13 January 2025 (UTC)[reply]
The other option would be to not have it automatically given, but to make it easy to grant to new page reviewers frequently doing draftifications, and encourage them to apply. Chaotic Enby (talk · contribs) 15:36, 13 January 2025 (UTC)[reply]
I don't think this is a good idea. Suppressing the redirect right away (whether you're an admin or not) makes it harder for people to find the page they were editing. WhatamIdoing (talk) 18:52, 13 January 2025 (UTC)[reply]
Opening up the page will show the log entry that the page was moved (allowing people to easily find it). Current policy does not place a time limit on when to delete pages that qualify for WP:R2 (beyond the standard wait an hour before draftifying). Once that happens, it's nominated for speedy deletion if the patroller isn't a page mover or an admin. R2s are usually dealt with immediately, so it's not like forcing people to nominate them for speedy deletion is going to accomplish much other than make their workflow slightly longer. Clovermoss🍀(talk)23:18, 17 January 2025 (UTC)[reply]
I also oppose bundling it with anything else beyond pagemover, per both Pppery and WAID. I'm also minded to agree with Graeme Bartlett that drafifying is happened too often (but I realise that it's been a while since I looked at this in detail). Nobody should be granted the suppressredirect right without it being clear they understand the policy surrounding when redirects should and should not be suppressed specifically. Thryduulf (talk) 14:21, 14 January 2025 (UTC)[reply]
I agree with JJPMaster that NPPers that qualify for the right don't much trouble gaining it. I think each case should be examined individually because draftifying on a frequent basis isn't required to be a new page patroller. User right requests also provide a chance to double check that such drafticiations are actually being done correctly. Clovermoss🍀(talk)23:25, 17 January 2025 (UTC)[reply]
I think each case should be examined individually because draftifying on a frequent basis isn't required to be a new page patroller. Fully agree. I have both NPP and pagemover but I rarely (never?) draftify, so NPP would've been a terrible reason for me to request pagemover. I am not a prolific reviewer, but it proves Clovermoss's point. Toadspike[Talk]11:17, 26 January 2025 (UTC)[reply]
Just give reviewers with a good track record of draftifying the pagemover right. The G2 deletions can be used as evidence for the good track record. —Kusma (talk) 11:40, 26 January 2025 (UTC)[reply]
Using a Tabber for infoboxes with multiple subjects
There are many articles that cover closely related subjects, such as IPhone 16 Pro which covers both the Pro and Pro Max models, Nintendo Switch which covers the original, OLED, and Lite models, and Lockheed Martin F-35 Lightning II which covers the A, B, C, and I variants. Most of these articles use a single infobox to display specifications and information about all of the covered subjects, leading to clutter and lots of parentheticals.
I propose that a tabber, like Tabber Neue, be used to instead create distinct infobox tabs for each subject. This would allow many benefits, such as clearly separating different specifications, providing more room for unique photos of each subject, and reducing visual clutter. An example of good use of tabs is one of my personal favorite wikis, https://oldschool.runescape.wiki, which uses tabs effectively to organize the many variants of monsters, NPCs, and items. A great example is the entry for Guard, a very common NPC with many variants. It even uses nested tabs to show both the spawn location grouped by city, and the individual variants within each city. While this is an extreme example in terms of the raw number of subjects, it provides a good look at how similar subjects can be effectively organized using tabs. Using Wikipedia's system instead, it would be substantially more cluttered, with parentheticals such as: Examine: "He tries to keep order around here" (Edgeville 1, Edgeville 2, Falador (sword) 1...) If you tried to save space using citations, it becomes very opaque: Examine: "He tries to keep order around here" [1][2][7][22]...
Overall I think this would make infoboxes more easily readable and engaging. It encourages "perusing" by clicking or tapping through the tabs, as opposed to trying to figure out what applies where. DeklinCaban (talk) 18:42, 16 January 2025 (UTC)[reply]
That would be an interesting idea! To go back to you iPhone 16 Pro example, a lot of information gets repeated in both tabs – maybe there could be a way to have it so that it only has to be added to the article in one place (even if shown in both tabs) to make them easier to keep in sync? Chaotic Enby (talk · contribs) 18:46, 16 January 2025 (UTC)[reply]
If it can print and display without JS effectively. From my testing under these environments, Tabber(Neue) makes these awkward line/paragraph-breaks that don't display the header at all. $wgTabberNeueUseCodex may be promising, but at least with the examples at wmdoc:codex/latest/components/demos/tabs.html, it's even worse: the tabs don't expand for the printing view at all, and the info under the other tabs will just be inaccessible on paper. Aaron Liu (talk) 20:21, 16 January 2025 (UTC)[reply]
A couple points at first blush: first, having a tabbed infobox seems like it's a usability nightmare. Secondly, it seems to be doing an end run around the overarching problem, which is that the infobox for iPhone 16 Pro is terrible. Software and tech articles are often like this (bad) where they try and cram an entire spec sheet into the infobox, and that's a failing of the infobox and the editors maintaining it. Trying to create a technical solution rather than the obvious one (just edit what's in the infobox to the most important elements) seems like a waste of everyone's time. Der Wohltemperierte Fuchstalk20:33, 16 January 2025 (UTC)[reply]
I suspect that our users would not even realise that they could click the tabs to see other info. So it will make it harder for our readers. Alternatives are to have multiple infoboxes, but this does take up space, particularly on mobile. Another way is to use parameter indexing as in the Chembox. Parameters can have a number on the end to describe variations on related substances in the one infobox. Graeme Bartlett (talk) 20:37, 16 January 2025 (UTC)[reply]
Tabs are widely used even on amateur wikis like 90% of Fandom Wikia. I'm sure readers know how to use them. (In fact, the "Article/Talk" "Read/Edit/View history" thing on the top is a tab.) Aaron Liu (talk) 21:27, 16 January 2025 (UTC)[reply]
Readers and potential editors don't know what the protection, good article, featured article, and other icons mean. I'm just one person but I'd never heard of tabs like that until I read this. CambridgeBayWeather (solidly non-human), Uqaqtuq (talk), Huliva01:35, 17 January 2025 (UTC)[reply]
For contentious pages, from what I can tell, there is no way in Wikipedia to come to a consensus when both camps are not making a good faith effort, and maybe even then. My proposal is: an expert could start an alternative page for one that he thinks is flawed, and have the same protections from further editing as the original? Then there could be a competition of narratives Iuvalclejan (talk) 19:32, 17 January 2025 (UTC)[reply]
Honestly, the consensus system works especially well on contentious pages, even if the discussions can sometimes get heated. Having content forks everywhere would not really be preferable, as, not only would you not have a single place to link the reader to, but you would quickly end up with pages full of personal opinions or cherry-picking sources if each group was given its own place to write about its point of view. A competition of narratives could be interesting as a website concept, but it would be pretty far from an encyclopedia. Chaotic Enby (talk · contribs) 19:43, 17 January 2025 (UTC)[reply]
The competition would not be the last step. Selection of alternatives could happen by votes, with some cutoffs: if a fork does not get votes above a cutoff, it is eliminated. That would prevent proliferation of narratives. Or you could have the selction criteria be differential instead of absolute: if one narrative gets 2x (for example) more votes than another, the other one is eliminated. Consensus does not work if pages become protected but the disagreement is still strong. Iuvalclejan (talk) 19:48, 17 January 2025 (UTC)[reply]
Honestly, the consensus system works especially well on contentious pages, I'd agree, but I'd also say we don't actually use the consensus system for contentious pages in practice—the more controversial the topic, the more I notice it devolving into straight voting issue-by-issue. (Even though that's the situation where you actually need to identify a consensus that all sides can live with.) – Closed Limelike Curves (talk) 21:42, 20 January 2025 (UTC)[reply]
Interestingly, it's been theorized ([10], pg 101) that we already have a "community of dissensus" whereby contentious and poorly-supported claims are weeded out from our articles until only that which can be verified remains. signed, Rosguilltalk19:45, 17 January 2025 (UTC)[reply]
The problems I see are not due to poorly supported claims. They are due to a biased reporting, that is technically correct (e.g. "hostilities erupted", rather than side A attacked side B), or outright omissions (e.g. the leader of said group is not mentioned because of his shady associations with Nazis, whereas the leader of the other group is mentioned many times). Iuvalclejan (talk) 20:29, 17 January 2025 (UTC)[reply]
In that case, we should stick to what sources say, rather than making multiple versions trying to please each editor. If sources mention the names of both leaders, then we should have them both in the article, rather than hiding one in a separate article. Chaotic Enby (talk · contribs) 20:36, 17 January 2025 (UTC)[reply]
So that addresses one issue, but evern there, if the page is protected, you can't "mention them both". What about the way of presenting a phenomenon, that while technically correct, is misleading by omission of important details? Iuvalclejan (talk) 20:42, 17 January 2025 (UTC)[reply]
For both cases: page protection doesn't mean that no one can propose any changes, it just means that you have to go to the talk page and discuss them with other editors (usually, to avoid someone else coming just after you and reverting it). If you feel like the discussion isn't going anywhere, we have channels for Wikipedia:Dispute resolution. Chaotic Enby (talk · contribs) 20:49, 17 January 2025 (UTC)[reply]
That said, there are special restrictions on articles related to Palestinian–Israeli conflicts, and you shouldn't attempt to edit them or discuss them until you have made 500+ edits elsewhere. This will give you a chance to learn our processes, jargon, and rules in a less fraught context. WhatamIdoing (talk) 08:13, 21 January 2025 (UTC)[reply]
I think the jump from 4 days and 10 edits to 30 days and 500 edits is far too extreme and takes a really long time to do it when there are many editors with just 100, 200 edits (including me) that are not vandals, they do not have strong opinions on usually controversial opinions and just want to edit. Which is why I want the possibility for more user levels to be created. For example one for 200 edits, and 15 days that can be applied whenever vandalism happens somewhat, in that case normally ECP would be applied however I that is far too extreme and a more moderate protection would be more useful. Vandals that are that dedicated to make 200 edits and wait 30 days will be dedicated enough to get Extended Confirmed Protection. Though I want to see what the community thinks of sliding in another protection being ACP and ECP. 2 levels should suffice to bridge the gap between 4 edits and 500 edits would allow low edit count editors to edit while still blocking out vandalism. This is surprisingly not a perennial proposal. SimpleSubCubicGraph (talk) 02:19, 21 January 2025 (UTC)[reply]
It's more that editors who have 500/30 generally have been in enough situations to hold Wikipedian knowledge that's in-depth enough. That doesn't necessarily hold true for those you've proposed. Time is part of the intention. Aaron Liu (talk) 02:28, 21 January 2025 (UTC)[reply]
possibility for more user levels to be created I had thought about this before and think more levels (or at least an additional level with tweaks to the current ones) would be a good idea. Something along the lines of:
1. WP:SEMI - 7 days / 15 edits
2. WP:ECP - 30 days / 300 edits
3. WP:??? - 6 months / 750 edits (reserved for pages with rampant sockpuppetry problems, such as those in the WP:PIA topic area). Some1 (talk) 02:50, 21 January 2025 (UTC)[reply]
@Aaron Liu Yes, that may be apart of the intention but I feel like there are editors with under 500 edits who can make just a good enough edit to not get it instantly reverted. Also protection is there mainly for vandalism, if we lived in a perfect society anyone could edit wikipedia pages without needing accounts and making tons of edits.
@Some1 I think 180/750 would be far too harsh, not even the most divisive topics and controversial issues get vandalized often with ECP.
My idea generally was keeping ECP the same but inserting another type of protection level in-between for mildly controversial topics and pages that are vandalized infrequently. SimpleSubCubicGraph (talk) 03:25, 21 January 2025 (UTC)[reply]
Can you give some specific examples of "controversial topics and pages that are vandalized infrequently"? Is there a particular article you want to edit but are unable to? Some1 (talk) 03:29, 21 January 2025 (UTC)[reply]
SimpleSubCubicGraph, if this is regarding Skibidi Toilet (per the comments below), then under my proposed ECP level requirements (30 day/300 edits), you would be able to edit that article. Some1 (talk) 12:35, 21 January 2025 (UTC)[reply]
There is not too much utility to creating a variety of new levels, as it generally gets clunky trying to define everything, and it makes the system less easy to grasp. What differentiates 100 edits from 200 from 300? ECP is not usually for vandalism, it is deployed for topics that receive particular levels of non-vandalistic (WP:VAND is very narrow) disruption. These are topics where experience is usually quite helpful, where editors who just want to edit are more likely to get in trouble. However, it is also a very narrow range of topics, apparently only affecting 3,067 articles at the moment, or less than 0.05% of articles. CMD (talk) 03:39, 21 January 2025 (UTC)[reply]
@Espresso Addict even though there are 3,000 articles that have ECP protection, many articles are often upgraded to ECP in light of infrequent vandalism (once a day, few times a week, etc). I know Skidibi Toilet was upgraded to ECP when the page was vandalized a few times. It was quite hilarious but it demonstrates a wider problem with liberally putting ECP on everything that gets even remotely vandalized. SimpleSubCubicGraph (talk) 07:06, 21 January 2025 (UTC)[reply]
Now, are there that many people that care for Skidibi Toilet? No. But it is also liberally applied to other wiki pages that are infrequently vandalized and editors can be there, wanting to edit, but they have to wait until an admin removes the protection which can vary depending on how active they are. It can be a day, to a week, and up to a month if you are really unlucky and the article is not that well known/significant. Which is why another type of protection can allow these editors to edit their favorite subject while still preventing vandalism. There are very few ECP users and that is with counting alternate accounts. So this change will affect a lot with how wikipedia works. SimpleSubCubicGraph (talk) 07:09, 21 January 2025 (UTC)[reply]
ECP is not liberally applied. Admins are usually very cautious about applying it, and if there is a particular case where you think it is no longer needed, raise it and it will very likely be looked at. CMD (talk) 08:11, 21 January 2025 (UTC)[reply]
Editors who make it to about ~300 edits without getting blocked or banned usually stick around (and usually continue not getting blocked or banned). So in that sense, we could reduce it to 300/30 without making much of a difference, or even making the timespan a bigger component (e.g., 300 edits + 90 days). But it's also true that if you just really want to get 500, then you could sit down with Special:RecentChanges and get the rest of your edits in a couple of hours. You could also sort out a couple of grammar problems. Search, e.g., on "diffuse the conflict": diffuse means to spread the conflict around; it should say defuse (remove the fuse from the explosive) instead. I cleaned up a bunch of these a while ago, but there will be more. You could do this for anything in the List of commonly misused English words (so long as you are absolutely certain that you understand how to use the misused words!). WhatamIdoing (talk) 08:36, 21 January 2025 (UTC)[reply]
[to SimpleSubCubicGraph] Sorry, I must have missed the various RfCs that extended the use outside contentious topics. SimpleSubCubicGraph, if you finding pages that could safely be reduced in protection level, and that don't fall within contentious topics, then you should ask the protecting admin to reduce the level on their talk page. But if you have an urge to edit Skibidi Toilet then the simplest thing to do is make small improvements to mainspace for a couple of hundred edits. If you don't have a topic you are interested in that isn't protected just hit random article a few times or do a wikilink random walk until you find something that you can improve. Espresso Addict (talk) 08:47, 21 January 2025 (UTC)[reply]
For anyone who wants to run up their edit count: Search for "it can be argued that", and replace them with more concise words, like "may" ("It can be argued that coffee tastes good" → "Coffee may taste good"). WhatamIdoing (talk) 00:27, 22 January 2025 (UTC)[reply]
I'm one of those affected by it, and I'm all for an open encyclopedia, but I'd honestly say that the 500/30 ECP makes sense. There is a great depth to this project, from the philosophy (e.g. standards for inclusion, notability, reliability) and practice (a million gray areas in PAG) of building an encyclopedia, to the philosophy (e.g. idea darwinism and convergence to a good result) and practice (the heavy bureaucracy and politics) of running a productive wiki project. If an editor comes in unfamiliar with these ideas, encountering and absorbing them organically takes time. spintheer (talk) 06:20, 25 January 2025 (UTC)[reply]
Ways to further implement restricting non-confirmed users from crosswiki file uploading
I don't know if this is technically feasible or not (advice sought) but would it be possible to create a shortcut for disambiguation? Something like [[Joseph Smith (general)!]] where the bang causes it to display as Joseph Smith rather than having to write [[Joseph Smith (general)|Joseph Smith]] which can be error prone. (I am not attached to the form in the example, it is the functionality I am interested in.) Hawkeye7(discuss)21:33, 21 January 2025 (UTC)[reply]
I have an idea: What if there was a more concrete way to let users set their pronouns, e.g. for users who use multiple pronouns like me? This would go beyond what is in WP prefs (feminine, masculine, neuter terms) and allow users to specifically set their pronouns and allow for multiple (e.g. she/they he/xem, he/they/she, etc.)? This data could be used by user scripts and could be displayed on a user's user page/talk page. thetechie@enwiki (she/they | talk) 03:48, 24 January 2025 (UTC)[reply]
That's probably not the best task for that. The existing preference is to let MediaWiki know things like "if the software needs to reference you to someone who has their user interface set to German, should it refer to you with 'Benutzer' or 'Benutzerin' or possibly 'Benutzer/in'?". To avoid making things unnecessarily complicated for translators, adding more values to that preference should only be done if it would further that goal. Past discussions like phab:T61643 have largely been a huge mess because some people can't seem to accept that that specifically is the use case rather than signalling gender identity.If you want to have a way to specify your pronouns and/or gender identity as a preference (rather than just using a userbox or other wikitext on your user page), you'd probably do better to ask for one or more new preferences to hold that information, explicitly separate from the existing "How should MediaWiki refer to you?" preference.Also, keep in mind that if you're really hoping scripts might actually use these (versus just display the preference to a human), just saying "xe/xem" is probably insufficient. You'd also need to specify for the script whether the person uses "xyr" or "xir" for the possessive, and whether "xyrs"/"xirs" is used (compare "his" versus "their"/"theirs"), and whether they use "xyrself"/"xirself" or "xemself", and possibly whether it's morphosyntactically plural (compare "they are" rather than "they is"). And that's just for English, I don't know what considerations there might be if you want it to be usable for other languages too. Anomie⚔13:29, 24 January 2025 (UTC)[reply]
Since there may be no limit on what users may desire, and the main use of pronouns is by other users, the best way is just to explain the wished for pronoun use on the user page. My POV is that it is up to the language user, and not the subject of discussion, but that we should be kind and respectful to others. So "they" is less respectful than someone's wish to be called "she" or "he". Inventing new words for pronouns is disrespectful for everyone. And I think I should not tell others what pronouns I desire. Graeme Bartlett (talk) 04:32, 25 January 2025 (UTC)[reply]
If someone has expressed a preference that people use certain pronouns when referring to them, it is generally regarded as respectful to use those pronouns when referring to them. It would certainly be useful to make it easy to discover that someone has expressed such a preference without having to remember to visit their userpage and hunting for the existence of a declaration that may be in almost any format in almost any location on the page. {{they}} and related templates (e.g. {{they|TheTechie}} → she) has some of this functionality but it is limited to just three options. Thryduulf (talk) 05:01, 25 January 2025 (UTC)[reply]
If the user has explicitly mentioned there pronouns in their signature (without '/'they them) then those should be used to reply them wherever possible. But for most users who do not put it in their signature, finding out each time what pronouns they prefer on their user page could be tedious especially when replying to a club of users. Although some may not find it that difficult, there surely are others who will. Additionally different cultures might see pronouns differently. Using they/ them to person may disrespectful in somebody's zone, and a friendly greeting in others. Creating complex rules for these may itself be unfriendly to a few.
I however think that this task could be easier for automated messages, and a custom character-limited pronoun is a good idea. For where the grammar is unclear as said by Anomie, we can use gender neutral pronouns, but then some may debate this inconsistency as unfriendly itself. ExclusiveEditor🔔 Ping Me!06:13, 25 January 2025 (UTC)[reply]
I wonder whether we could/should create a more flexible pronoun infrastructure. If every user who cares has a /pronoun subpage of their userpage, we could have {{they}} or a variant check that page and output the correct pronoun. Basically {{they|Kusma}} could transclude User:/Kusma/pronoun or, if that page does not exist, just default to its current behaviour. —Kusma (talk) 20:01, 25 January 2025 (UTC)[reply]
The following discussion has been closed. Please do not modify it.
Its obvious and open that all mainstream media is bought out by billionaires who support the democrat party. This may not seem like a big issue at first, but theres this tiny thing called "ESG" and "DEI" that is very common in workplaces. Due to this, news media will lean heavily liberal and broadcast left wing politics. This is further amplified by the fact that these news sources are owned by billionaires who lean to the democrat party and therefore force left wing politics to be the "highlight" of the media when they talk about politics. I think we should ban mainstream media from being used as citations as they are not reliable. Only nonpartisan, moderate news sources that are not funded by big corporations or billionaires or governments should be used as news sources. SimpleSubCubicGraph (talk) 03:55, 25 January 2025 (UTC)[reply]
You have a USA-centric view there, and there are other POVs even in the USA such as FOX. Anyway we just have to take biases in whatever media into account. Non-mainstream will also have biases, but they mey not be so well known. Graeme Bartlett (talk) 04:22, 25 January 2025 (UTC)[reply]
@Graeme Bartlett Fox news is one conservative media out of all the other mainstream ones that all lean liberal. There needs to be more reliable sources as the billionaires openly control the narrative. Look what they did to all of the republican candidates, slandered them, defamed them, made up false lies, compared them to nazis and more. All of those are fake and is a demonstration of the dirty tactics billionaires will use to further their own interest. SimpleSubCubicGraph (talk) 17:54, 25 January 2025 (UTC)[reply]
"nonpartisan,... that are not funded by big corporations or billionaires or governments" may themselves have their own biases. In multiple parts of the world, you see such small media to be biased to their local area, portraying them better compared to other areas, where there audience doesn't lie, something like audience-centered bias, and because the writers work locally they are not be able to provide strong coverage beyond their own locality without seeking information from the large media outlets you seek to ban. There are so many biases, if we deselect all of them then we may have only a handful of news outlets left, whose future biases will directly shape Wikipedia. ExclusiveEditor🔔 Ping Me!06:24, 25 January 2025 (UTC)[reply]
@ExclusiveEditor But their biases are not as extreme compared to left wing liberal bought out media. Sure they may favor their own place, present it better than others. But in the grand scheme of things, they are far better than billionaires who donate to kamala and who own the media. Which one is more likely to be biased? Obviously the big news corporation. SimpleSubCubicGraph (talk) 17:51, 25 January 2025 (UTC)[reply]
@Chaotic Enby@Phil Bridger More billionaires have donated to left wing politics than to right wing ones (republican party). From what I recall, about 70 billionaires donated to Kamala, 50 to Trump. As it just so happens, those billionaires control most of the media. SimpleSubCubicGraph (talk) 17:52, 25 January 2025 (UTC)[reply]
Why are you talking about Kamala and Trump (it was your choice to use the first name for one and the surname for the other)? Less than 5% of the world's population could vote for either of them. Phil Bridger (talk) 18:31, 25 January 2025 (UTC)[reply]
The opposite is also possible – the Wikipedia community knows that most sources are biased, and our policy on this is that biased sources are acceptable provided that they're reliable and correctly attributed when needed. You should either show that some of the "mainstream" sources are not only biased but actually unreliable (you can take a look at Wikipedia:Reliable sources/Noticeboard), or, like said above, start a discussion to disallow biased sources in general. Chaotic Enby (talk · contribs) 18:25, 25 January 2025 (UTC)[reply]
@ExclusiveEditor@Chaotic Enby There is proof that the media lies, slanders, and is biased. I don't know how the wikipedia community could accept it. I've seen many articles on post 1992 US politics that are wrong but whenever I try to do something about it I get struck down. SimpleSubCubicGraph (talk) 18:46, 25 January 2025 (UTC)[reply]
If you have actual example of fabricated stories or lies, you can put it at the talk page of the article in question, or, if it is a recurring pattern for a news source, you can post it at Wikipedia:Reliable sources/Noticeboard so it can be reevaluated. Again, bias alone is not unreliability, and multiple sources can and will often present the same facts with different spins on them without any of them outright lying. Chaotic Enby (talk · contribs) 19:45, 25 January 2025 (UTC)[reply]
I was a bit surprised last night to discover that WP:CRITICISM is "only" an essay. I see people try to follow it on a somewhat frequent basis for best practices and was under the impression that it must be a guideline. But it's not. Should it be? I've never tried to "upgrade" the status of something before and I'm assuming to some extent that would be controversial, but input would be welcome. I'm assuming some things might need to be finetuned if it does get that extra status. Clovermoss🍀(talk)17:31, 26 January 2025 (UTC)[reply]
Regarding the process, Wikipedia:Policies and guidelines § Life cycle describes the process of establishing consensus for guidance to be designated as a guideline or policy. Before having a request for comment discussion, it would probably be good to have a discussion reviewing its current content and establishing consensus amongst interested editors, before moving to a broader sampling of the community in an RfC. isaacl (talk) 17:46, 26 January 2025 (UTC)[reply]
Maybe put a pointer on the talk page for Wikipedia:Criticism then? The idea lab page is usually more for brainstorming than establishing consensus, but probably not a big deal if the discussion happens here or, say, the miscellaneous village pump, as long as they're pointers at the other places. isaacl (talk) 18:10, 26 January 2025 (UTC)[reply]
I don't think the talk page has that many watchers. I came here for brainstorming and wider community input. I thought that's was what one should do before even attempting an rfc. It seems to fit exactly with the stated purpose of this page. Clovermoss🍀(talk)18:15, 26 January 2025 (UTC)[reply]
Sure; I gave my brainstorming thoughts that it would probably be good to have a discussion to do that finetuning you described to ensure that the page was a good representation of in-practice consensus, before having an RfC. A village pump is a fine place to have a discussion. I was just suggesting that it might be helpful to attract interested editors with pointers on the corresponding talk page and the miscellaneous village pump, since the idea lab typically discusses less fully-formed ideas, and so its set of page watchers might not cover enough of the desired audience. isaacl (talk) 18:24, 26 January 2025 (UTC)[reply]
I think your instinct is correct; Special:PageInfo says that 9 editors who have the page on their watchlist looked at the WP: page during the last 30 days, and 10 of them looked at the talk page. That's not a lot.
(edit conflict) X 2. Often too much notice is made of which word an essay, guideline or policy has at the top. How much it is binding depends more on how widely it is accepted rather than its formal status. Having said that, I would follow Isaacl's advice before "upgrading" anything. Phil Bridger (talk) 18:12, 26 January 2025 (UTC)[reply]
I would support a process to bring CRITICISM to at least a guideline. This might mean an initial stage to review and revise the text to make it appropriate for a guideline before bringing an RFC to make it a guideline. Masem (t) 18:42, 26 January 2025 (UTC)[reply]
WMF
Wikimedia Foundation Bulletin December Issue
Here is a quick overview of highlights from the Wikimedia Foundation since our second November issue. This will be the final bulletin for 2024 and we'll be back in late January 2025 with the next issue. Please help translate.
Upcoming and current events and conversations Talking: 2024 continues
Celebrating Chabota and his contributions to the movement.
Tech News: Chart extension is now available on Commons and Testwiki; a new version of the standard wikitext editor-mode syntax highlighter will be available as a beta feature; Edit Check will be relocated to a sidebar on desktop. More updates from tech news 50, 49, and 48.
Wikipedia 2024 Year in Review:Wikipedia 2024 Year in Review launched, showcasing the collective impact of Wikipedia and Wikipedia contributors in the last calendar year. The iOS App also released a personalized Year in Review to Italy and Mexico, with insights based on reading, editing, and donation history.
Wikipedia Android App: The Android team has launched the Rabbit Holes feature in the final release of the year as part of Wiki Experiences 3.1. Currently being tested in Sub-Saharan Africa and South Asia, this feature suggests a search term and a reading list based on the user's last two visited articles. For more details or to share feedback, visit the project page.
Annual Goals Progress on Equity See also a list of all movement events: on Meta-Wiki
WikiCelebrate: From Challenges to Change-Making: We Wikicelebrate Chabota Isaac Kanguya, a passionate contributor from Zambia, whose journey through the Wikimedia movement embodies resilience, collaboration, and a commitment to representing underrepresented voices.
Conference: Announcing Central Asian WikiCon 2025 which will be hosted at Diplomat International School on April 19–20, 2025, in Tashkent, Uzbekistan.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
Taking stock of the new Community Wishlist process
Over on the Meta talk page of the new Community Wishlist process I've done a post taking stock of the changes so far. Followers of this page may be interested in that discussion. Best, Barkeep49 (talk) 17:48, 7 January 2025 (UTC)[reply]
WMF annual planning: How can we help more contributors connect and collaborate?
Hi all - the Wikimedia Foundation is kicking off our annual planning work to prepare for next fiscal year (July 2025-June 2026). We've published a list of questions to help with big-picture thinking, and I thought I'd share one of them here that you all might find interesting: We want to improve the experience of collaboration on the wikis, so it’s easier for contributors to find one another and work on projects together, whether it’s through backlog drives, edit-a-thons, WikiProjects, or even two editors working together. How do you think we could help more contributors find each other, connect, and work together?KStineRowe (WMF) (talk) 20:27, 10 January 2025 (UTC)[reply]
"The UK announces that, as of July, any site that allows adult content — including social media sites — will have to age/identity verify all users, or face enforcement action by the British government." - [11]
Nothing new here. Virginia's had this for a couple of years. I'm unaware of any jurisdiction that's pursued Wikipedia over this, if it's concern over that that motivated this thread. Largoplazo (talk) 14:45, 19 January 2025 (UTC)[reply]
(edit conflict) Texas's is at least a bit more limited. It seems the UK wants age verification for any site where a child might possibly see something "harmful to children", including any site where users can post content (even if no "harmful" content is ever posted), while Texas's law (which is already in force, BTW, but is being challenged) is only for sites where over 1/3 of the content is pornographic. Anomie⚔14:57, 19 January 2025 (UTC)[reply]
What's the UK's definition of "adult content"? The article makes it clear that the main concern is about kids watching pornography, and it's not clear how they're planning on implementing anything. signed, Rosguilltalk16:58, 19 January 2025 (UTC)[reply]
Thanks, that page seems to be even more explicitly focused on "pornography", so this may not end up impacting us based on what I can see. signed, Rosguilltalk17:52, 19 January 2025 (UTC)[reply]
from one of the PDFs linked there, "Pornographic content is defined in the Act as “content of such a nature that it is reasonable to assume that it was produced solely or principally for the purpose of sexual arousal.”". Which WP immediately would not be in violation since we specifically do not allow for such images and moderate those off. — Masem (t) 17:59, 19 January 2025 (UTC)[reply]
There is certainly some instances of erotic photography that would meet an encyclopedic need, but I do think that category appears to be used for ppl just dropping their personal erotic photos in there, and probably should be dealt with. Masem (t) 18:17, 19 January 2025 (UTC)[reply]
Keep in mind that the inclusion criteria for Commons isn't that the media meets an encyclopedic need, but an educational need. An image could be inappropriate for Wikipedia's needs, but could still be useful, for instance, in a class on erotic photography as part of an MfA photography program. Photos of Japan (talk) 23:28, 19 January 2025 (UTC)[reply]
Usually people upload first and only discuss the educational merit of media if its nominated for deletion. Out of scope explicitly excludes low quality pornographic content, but I'm not sure how the community evaluates what constitutes that. My comment though was mostly concerning how it's a wiki faux pas to imply being unsuitable for Wikipedia makes something OOS for Commons. Photos of Japan (talk) Photos of Japan (talk) 03:46, 20 January 2025 (UTC)[reply]
We live in the real world, not some sort of libertarian utopia (or dystopia). Part of being one of the top sites on the Internet is that we have to take our reponsibilities seriously within the law. The WMF has done that in India and other places (in my view sometimes in the wrong way), and will do so in the UK. Just please nobody propose [redacted per WP:BEANS]. I hope that the WMF will take legal advice, but make the final decision themselves on whether to follow it. Phil Bridger (talk) 18:49, 19 January 2025 (UTC)[reply]
How to request user talk page access revocation
What's the approved way to request the removal of a blocked user's access to their talk page when you see them using it only to rant, carrying on the behavior that got them blocked in the first place? Largoplazo (talk) 00:59, 20 January 2025 (UTC)[reply]
I'm not sure where is best to ask about this, but as someone who works on film articles and participates on their talk pages, I am seeing a lot of comments that seem AI-generated, being lowercase and half-nonsensical. I detail this more here: Wikipedia talk:WikiProject Film § AI-generated comments? Any thoughts from anyone, or recommendation of another page to post about this? Erik (talk | contrib) (ping me)22:38, 20 January 2025 (UTC)[reply]
Those don't seem AI-generated to me. If you see stuff like that, just revert it. If it continuously comes from one IP, then you can raise that at WP:AIV or WP:AN/I. It looks like this is all from the same IP range. CMD (talk) 02:18, 21 January 2025 (UTC)[reply]
They're probably not "AI" in the LLM sense. But they do fall into a category of unconstructive drive-by talk page edits that started in 2022. Some are AI prompts, some appear to be text-to-speech or Siri/Alexa/etc prompts, some seem to be bot-generated (which these seem to be.)
When you see them nuke them on sight (which the Wikipedia policy WP:NOTFORUM allows) and nuke them ASAP because if they go into the archive (which is out of people's control, everything is bot-archived nowadays) then people will yell at you for following policy. Gnomingstuff (talk) 20:34, 22 January 2025 (UTC)[reply]
After seeing years worth of (what I believe to be) misuse of WP:RECENTISM as an essay, I've created an essay for responding to it, WP:CRYRECENTISM. Hopefully it speaks for itself, but my core problem is that RECENTISM is sometimes used in a way that allows people to completely dismiss all sourcing on something recent, which doesn't reflect what RECENTISM says (it doesn't even describe recentism as a bad thing!) and contradicts WP:NPOV. Obviously we have to be cautious about giving undue weight to recent events, and sometimes it's true that something recent is so undue relative to the topic as a whole that it should be included entirely - but these arguments ultimately have to be made using sources (or the limitations and lack thereof), not just by bludgeoning people with all-caps links to essays. It feels like WP:RECENTISM has become a go-to argument for anyone who wants anything recent excluded for any reason, which isn't really constructive because it doesn't reflect policy, provides no real room for discussion or compromise, and implicitly allows people to just ignore any degree of coverage in a way that contradicts WP:NPOV's requirement to use sourcing as the basis for weight. --Aquillion (talk) 18:30, 22 January 2025 (UTC)[reply]
Not a bad essay… but it leaves me with a question: would you say that RECENTISM could be a valid argument for temporary omission rather than exclusion? ie, arguing that it is too soon to add some bit of material, and that we simply need to wait a bit - so that we can properly determine how much (if any) weight to give it. Blueboar (talk) 19:17, 22 January 2025 (UTC)[reply]
Sometimes? But it has to engage with the sources on some level. I've sometimes said "there's not enough sourcing yet, let's swing back later", which is certainly a fair argument. My problem with WP:RECENTISM is that it's frequently used as an argument that ignores current sourcing entirely, which I don't think is appropriate (or policy-compliant.) The main point of the essay, I think, is that WP:NPOV means you have to engage with the sourcing somehow, even if it's just to say "sorry, this requires a very high threshold and these sources aren't enough"; there has to be a level and type of sourcing that would allow for immediate inclusion, otherwise we're deciding article content based on our guts. Arguing for temporary omission without regard for the sources would still have the same problem. --Aquillion (talk) 19:37, 22 January 2025 (UTC)[reply]
"Insisting that a recent event should be excluded simply for being recent, without further explanation or analysis, is not helpful to building an encyclopedia."
The problem with this essay is that strawmans WP:RECENTISM. Recentism addresses a real issue: certain subjects are perennially in the news and every news spike of them leads to content added to their article until they are inundated with material that is of no lasting interest to the reader. Recentism doesn't reject content just because it is recent, it asks people to provide justification for including content beyond just the fact that it was covered by a flurry of news sources. Photos of Japan (talk) 02:27, 23 January 2025 (UTC)[reply]
Universal Code of Conduct annual review: provide your comments on the UCoC and Enforcement Guidelines
I am writing to you to let you know the annual review period for the Universal Code of Conduct and Enforcement Guidelines is open now. You can make suggestions for changes through 3 February 2025. This is the first step of several to be taken for the annual review.
Read more information and find a conversation to join on the UCoC page on Meta.
"1987 [[SFRY|Yugoslavia]] film": Short description of related articles, tried wikilink /mobile/
Related articles at Lepa Brena has second item 'Hajde da se volimo (film series)' with description below: "1987 [[SFRY|Yugoslavia]] film".
I could not find a source for tried wikilinking, while the article itself has no short description template and Wikidata description was not good ("1987 film by Aleksandar Đorđević"; now changed to "1987–1990 Yugoslav film series"). Expect refreshed import from Wikidata in a while, and/or find where exactly is "1987 [[SFRY|Yugoslavia]] film"? 5.43.67.103 (talk) 03:50, 25 January 2025 (UTC)[reply]
Please, remove unwikilinked text for proper display below the item 'Hajde da se volimo (film series)' that is "1987–1990 Yugoslav film series" (current description at Wikidata). 5.43.67.103 (talk) 12:38, 26 January 2025 (UTC) [e][reply]
It sounds like only an old revision of the file will be deleted. The file itself (the current revision) will be kept. I imagine that's probably an acceptable outcome. –Novem Linguae (talk) 09:36, 26 January 2025 (UTC)[reply]
Resolved
), become barely visible as they blend into the background. This makes it challenging to view the content clearly. The same issue occurs with any outlined transparent images.
.jpg)
wikimedia.org know if you have any feedback or suggestions for improvement!
