The policy section of the village pump is intended for discussions about already-proposed policies and guidelines, as well as changes to existing ones. Discussions often begin on other pages and are subsequently moved or referenced here to ensure greater visibility and broader participation.
If you wish to propose something new that is not a policy or guideline, use Village pump (proposals). Alternatively, for drafting with a more focused group, consider starting the discussion on the talk page of a relevant WikiProject, the Manual of Style, or another relevant project page.
For questions about how to apply existing policies or guidelines, refer to one of the many Wikipedia:Noticeboards.
If you want to inquire about what the policy is on a specific topic, visit the Help desk or the Teahouse.
This is not the place to resolve disputes regarding the implementation of policies. For such cases, consult Wikipedia:Dispute resolution.
Addition: "Administrators may choose to further delay running in an RRFA or administrator election by up to 6 months after the recall petition is closed: they will be temporarily desysopped in the interim upon declaring such an intention. The temporary desysop will be reversed if they retain adminship within 6 months by the means described below: otherwise it is made permanent."
Removal: "; they may grant slight extensions on a case-by-case basis"
Additional background: A recent recall petition and the administrator's subsequent request to be allowed to run in the next administrator election, which would start outside the 30-day window specified in the policy, led to this extensive thread at the bureaucrat's noticeboard. I see no clear consensus there as to whether the specific delay in this instance is permissible, or as to how to handle this situation in the future. Rehashing this conversation for each subsequent recall seems to me to be undesirable. Vanamonde93 (talk) 19:55, 25 October 2025 (UTC) Addendum: it has been brought to my attention that in this instance there appears to be 'crat consensus to permit an extension. Vanamonde93 (talk) 04:05, 26 October 2025 (UTC)[reply]
Support, as proposer. As I noted at BN, the community clearly intended for administrator elections to be a path for retaining adminship. However, only offering it to those admins recalled within the arbitrary window of 30 days before each call for candidates feels inequitable. Given the tendency for regular candidates for adminship to choose EFA over RFA, I suspect this matter will come up again, and we will have further lengthy discussions about how much delay is permissible, which this proposal will eliminate. It also gives recalled admins more time to choose their path and reconsider their approach before asking to retain the tools, while simultaneously restricting them from taking bad admin actions. Vanamonde93 (talk) 19:55, 25 October 2025 (UTC)[reply]
Noting that the emergence of 'crat consensus to allow UtherSG an extended timeframe to run in the coming admin elections only strengthens my desire to enact this, because it highlights the potential for difficulty with longer delays, and creates the possibility that an administrator's popularity will affect the community's perception of the delay. Obviating the need for an extension is the most equitable solution. Vanamonde93 (talk) 04:05, 26 October 2025 (UTC)[reply]
Oppose Per the maxim Justice delayed is justice denied, it seems best to act expeditiously rather than spin things out. Six months seems quite a long time and I don't like the idea that an RfA candidate would retain the right to a discount on the % required for success for so long when other candidates, who hadn't given cause for complaint, were not given this advantage. If someone is too busy to attend to an RfA then they can just resign and try a regular RfA later at a time of their choosing.
Note also that there's a procedural problem with this RfC. WP:RFC states "There is no technical limit to the number of simultaneous RfCs that may be held on a single talk page, but to avoid discussion forks, they should not overlap significantly in their subject matter." This RfC obviously overlaps significantly with the Recall check-in RfC above. Tsk.
Oppose I supported reconfirmation by election to avoid the confusion of an admin that preferred WP:AELECT needing to resign to access it during their temp desysop. However, like many expressed in the initial approval of this option, we should not extend the admin's lenience at RRFA and AELECT just to ensure an election occurs within their limbo. If someone really prefers elections, they can pursue it like any other user. ViridianPenguin🐧 (💬) 22:26, 25 October 2025 (UTC)[reply]
Mostly support. Recall only works when it is fair to all parties, and allowing someone to wait until the next admin election is fair. Allowing crats discretion to extend is fair. Sticking to rigid arbitrary deadlines is not - why would we penalise someone for starting an RFA on the 31st day vs the 29th day due to personal circumstances? Thryduulf (talk) 22:27, 25 October 2025 (UTC)[reply]
Weak support (prefer 3 months) I understand and don't oppose the general idea of giving an admin some additional flexibility around the timing of their RRfA. That said, 6 months is a long time; I would support a shorter window for this extension as a first preference. 2601:540:200:1850:CC47:61C6:19C6:6028 (talk) 22:55, 25 October 2025 (UTC)[reply]
If the goal is to allow admins to use the election process to RRfA, perhaps that could be spelled out as an exemption to a 3-month limit: "The temporary desysop will be reversed if they retain adminship within 3 months by a Request for Adminship (RfA) or at the next regularly-scheduled Administrator Election, regardless of date: otherwise it is made permanent." 2601:540:200:1850:CC47:61C6:19C6:6028 (talk) 23:02, 25 October 2025 (UTC)[reply]
That's a fair concern. I chose 6 months to ensure the window would always encompass an admin election. EFAs are supposed to be held every 5 months, plus some wiggle room with scheduling. Vanamonde93 (talk) 23:02, 25 October 2025 (UTC)[reply]
Support for 2 reasons. First the community has been uniformly happy with giving administrators the option to reconfirm via election. This proposal prevents that from being an empty option 4/5th of the time. Second, it gives an admin the option to step back, address a concern, show some personal growth from the process and then reapply for adminship. The current system of a RRFA in the immediate shadow of a petition-generating controversy feels difficult to pass, and transforms 25 signatures from a statement of concern to a de facto permanent desysop. As a pleasant side effect, this should also give clarity to the crats, who would otherwise have hard decisions anytime a candidate wanted an extension for running in an election.Tazerdadog (talk) 23:27, 25 October 2025 (UTC)[reply]
Support, though I agree with S Marshall that "until the next election" is probably the better way to phrase this. We should make it as painless as possible recalled admins, and this is a step towards that goal. The admin is desyopped in the interim, so there is no chance of further misconduct with the tools. HouseBlaster (talk • he/they)01:44, 26 October 2025 (UTC)[reply]
Support Although I agree with S Marshall and House that until the next election is the better wording. This is a reasonable proposal that will enact the communities will to allow ALECT for recall by giving more flexibility for Admins to stand at the next election. GothicGolem29 (talk) 03:27, 26 October 2025 (UTC)[reply]
Oppose. Six months is a long time on the internet, and would allow whatever issues that led to the recall petition to quietly fade from memory. They of course would still be welcome to run in an election, they would just have to follow the same rules as us normal folk. ~~ Jessintime (talk) 03:50, 26 October 2025 (UTC)[reply]
Support, for either RRFA or AELECT, with the temp desysop. Worried that the petition makes admins do RfAs at an inconvenient time? This solves that! Worried that the petition was started by a bunch of bad faith socks? Now you've got potentially 6 more months to prove that, bring the evidence to the community, and watch some SPI blocks get dropped before they show up to RfA. Worried that your favourite vandal and sock blocking admin had gotten too jaded and wish there was an option between having them ignore community concerns and removing them permanently? Then Vanamonde's administrative leave plan may be just the thing you're looking for! More seriously, I do get the concerns around giving somebody desysopped for cause more time for the community to forget (lol, we're Wikipedians, we dig up books from the 1930s about abandoned settlements for fun), and I really do understand that there's an inherent unfairness in turning away a potential new recruit who hit 65% approval rating while letting somebody who was desysopped for cause 180 days ago sail through at 55%, which I really don't like, - but at the end of the day, I don't actually want to desyop admins. I want good admins. I believe that incentivizing a long period of reflection and a period of time without tools, where you have to run every single admin action past your peers instead of cutting corners, can only be a good thing. GreenLipstickLesbian💌🦋04:19, 26 October 2025 (UTC)[reply]
Support for both RRFA and AELECT. This was proposed in the earlier discussion, and I wholeheartedly endorse this. This proposal retains accountability for the admins (they lose their bits) while reducing the "temperature" of RECALL. If an admin is sufficiently flawed, the voters will inevitably bring out their mistakes anyway. But this allows any good admins having a "bad time" to have a gap to improve their behaviour and prove themselves to the community. If passed, I also think this should retroactively apply to every admin who resigned instead of RRFA in the last 6 months. Soni (talk) 04:32, 26 October 2025 (UTC)[reply]
Very weak support for AELECT I agree with S Marshall that it should be "until the next election." I oppose for RRfA unless it's only 2-3 months, in which case it would also be a very weak support. fanfanboy(blocktalk)05:06, 26 October 2025 (UTC)[reply]
Weakish Support - This feels like tinkering around the edges of a bad system, but anything is better than nothing in this case. This definitely should not preclude other changes or indeed getting rid of the whole mess of an RRFA system. FOARP (talk) 06:07, 26 October 2025 (UTC)[reply]
Support per many others, especially GLL. I'm not sure if the "next election" wording is better than a hard limit (6 months), since the former varies with time, which is a criticism of the current system. It would also mean the time limit for an RfA and AELECT could be different, which is odd. Toadspike[Talk]02:09, 27 October 2025 (UTC)[reply]
Musing on your final point, does it matter if the RFA and AELECT deadlines are different (this is genuine question)? You've also got me thinking about the minimum times between petition closure and the stand/don't stand decision deadline. I'll put my comments about that in the discussion section below. Thryduulf (talk) 02:49, 27 October 2025 (UTC)[reply]
Support. I think there probably needs to be some tinkering after the fact to make it more concise and flow better with already there since it's weird to say you have 30 days and then at the end of the paragraph say that actually, it's effectively 6 months (presumably if declared within the 30 days?). I would honestly just make it opt-out instead of opt-in if the point of this is to make it easily for recalled admins to "rehabilitate" themselves to use a criminal justice term. It gives the admin time to schedule a potentially busy week for an RFA/admin election so they can put their best foot forward on how to address the inevitable questions and allows sentiments to cool off for both the admin and by the community. It also allows the admin time to continue to edit and show that they're addressing the issues raised in the recall (e.g. tagging and declining CSDs properly if overzealous CSD deleting was an issue). Maybe if memory is an issue, just make it a link to the recall petition mandatory. -- Patar knight - chat/contributions06:46, 27 October 2025 (UTC)[reply]
Support principle but not for 6 months until RRFA. It's reasonable to allow the re-appointment discount for a little longer, giving the admin time to consider what happened, whether they want the bit and how to go about it. But per S Marshall and others, only until the next election if choosing AELECT and only for 3 months, not 6, for an RRFA. We do, after all, want memories of the events, discussions and petition to be reasonably fresh and comparatively accurate (which may favour the candidate or may not). Three months also happens to be a little more than the average time from a petition passing to the next AELECT, on current timing. NebY (talk) 16:41, 27 October 2025 (UTC)[reply]
See my comments below about "until the next election" - that could be just under 6 months away, it could be minutes, it could be anywhere in between. Thryduulf (talk) 17:32, 27 October 2025 (UTC)[reply]
Yes, I'd seen those comments. That's three months on average, but I also note Vanamonde's comment above, "EFAs are supposed to be held every 5 months, plus some wiggle room with scheduling.". NebY (talk) 17:43, 27 October 2025 (UTC)[reply]
"On average" is fine in the abstract but not when it comes to an individual administrator. What matters then is how long there is until the actual next election - if nominations close imminently that's very very different to the next election being 2-5 months away. Thryduulf (talk) 17:55, 27 October 2025 (UTC)[reply]
Perhaps you haven't read my full support comment. I do support allowing the discount at the next AELECT. However, I don't support allowing the discount for an RRFA for up to 6 months and support up to 3 months instead, for the reasons I stated. I then noted - and it's regrettable if my noting it misled you as to the previous points - that 3 months is also (a little more than) the average discount period created by allowing the discount at the next AELECT. NebY (talk) 18:07, 27 October 2025 (UTC)[reply]
I have read your full comment, and I still think that you're missing the point that I'm making. I cannot think how to say what I've been saying any differently though, so I'm just going to hope someone else can. Thryduulf (talk) 18:18, 27 October 2025 (UTC)[reply]
I view this as largely academic (since starting with 25 opposes dooms a RRFA from the start, and I suspect that's by design); but it doesn't make sense for there to be a longer possible wait time if you choose to use the venue that, so far, has always resulted in much less scrutiny. —Cryptic16:48, 27 October 2025 (UTC)[reply]
Support per Tazerdadog. This gives all recalled administrators the option of running in the next WP:AELECT rather than being forced to go use WP:RFA as their reconfirmation process unless they get lucky, and it also lets both the recalled admin and the community take a step back, reflect, and approach the RRfA after some introspection, rather than being forced to do it immediately after some controversy. Mz7 (talk) 04:53, 28 October 2025 (UTC)[reply]
To avoid confusion regarding whether or not the admin is being elected or re-elected when their first request used the open viewpoint process, personally I suggest staying with the term re-request for adminship, which can proceed either through the open viewpoint process, or the election (or secret ballot) process. isaacl (talk) 00:44, 29 October 2025 (UTC)[reply]
I would say the best way to avoid confusion is to have REELECTS the term for admin elections and RRFA be the term for RFA. This is because it matches each process better with RRFA referring to the process involving RFA and REELECT referring to the process with the Admin Elections. GothicGolem29(talk)15:53, 29 October 2025 (UTC)[reply]
Yes, but that isn't a compelling reason to reduce accountability. RfA will be difficult whether it happens sooner or later. Delaying it only serves to remove it from the reasons Recall was initiated and certified and those reasons should be a key component of those processes. Iggy pop goes the weasel (talk) 14:57, 29 October 2025 (UTC)[reply]
those reasons should be a key component of those processes. Yes and no. They should be a component of the processes, but only in the context of their adminship as a whole. "Occasional mistakes are entirely compatible with adminship" is an oft-repeated principle at arbitration, but finding 25 signatories to a petition in the immediate aftermath of an isolated controversial decision is likely going to be very easy, so there needs to be a period to allow tempers to cool and ensure that the ReRFA is a fair reflection of the admin not just of one incident. However, it is equally likely that the cause for a petition is ongoing chronic inappropriate adminning (with or without an easily-pinpointable final straw), and in that case there shouldn't be too long a gap between petition and ReRFA. This means that the timescale needs to be a balancing act between these competing directions and also remain fair to both petitions and the admin. I don't think 30 days is long enough, but contra WAID I do think a year is too long. If admin elections were not a thing, I'd probably be suggesting 3 months, but admin elections are a thing and the community consensus was strongly in favour of both a 5-month schedule and allowing admins who are the subject of a certified recall petition to choose to stand in an election. We cannot control when petitions are certified relative to the admin election schedule, so to ensure that the community consensuses are respected without unfairly forcing admins to stand immediately after a petition closes we have to allow the election interval plus circa three weeks, which in round numbers is 6 months. Thryduulf (talk) 15:37, 29 October 2025 (UTC)[reply]
Nothing under the current system prevents the context of their adminship as a whole being discussed or taken into account at RRfA or AElect, two processes by which all are able to identify their support or lack thereof. The discussion sections of Recalls have proven this. Iggy pop goes the weasel (talk) 19:39, 29 October 2025 (UTC)[reply]
It's correct that nothing currently prevents that, but it does discourage that. The discussion sections of recall are irrelevant by design. Thryduulf (talk) 19:48, 29 October 2025 (UTC)[reply]
Oppose - six months is too long, and enough with coddling troublemaker admins. They can run for RFA anytime they want, and they can stand in any election. 30 days at a reduced threshold is already a lot of leeway. Nobody else whose perm gets pulled gets this kind of indulgence. Levivich (talk) 16:01, 29 October 2025 (UTC)[reply]
I am proposing a window of up to 6 months during which the admins will no longer be admins. That's not coddling in any sense of the word. Vanamonde93 (talk) 16:18, 29 October 2025 (UTC)[reply]
It's coddling because they get the benefit of the lower pass thresholds six months later instead of just 30 days later. I appreciate that the proposal would prohibit tool use during the six months, I think that aspect is good of course, but still, six months is too long. If an admin wants to run six months after their recall petition is certified, they can just do so, at the normal thresholds. I think it's coddling because you're giving them a six month window for a full community review of their actions while enjoying the lower threshold privilege. Nobody gets this. I didn't get to delay any of the arbcom cases where I was a party by six months to a time that was convenient for me. The last one happened over Christmas and New Years, nobody gave a crap that this was bad timing. I get having a little leeway like 30 days, but I don't see why admins should get so much leeway as six months. Imagine an ANI thread and the reported editor says "can we talk about this in six months? I promise not to edit the article in the meantime." Nobody gets this privilege on Wikipedia, no reason to give it to admins. Levivich (talk) 16:59, 29 October 2025 (UTC)[reply]
It isn't accurate to say nobody gets this "privilege": I can think of at least three admins who received similar grace periods, when desysop cases were opened by ARBCOM and suspended until such a time as the admin chose to resume them. It's not accurate to say we don't extend the privilege to editors either. We have certainly closed noticeboard reports based on a voluntary commitment to stay away from a particular conflict. Now maybe you think that's coddling too, and I won't argue with that. But there's certainly precedent. And I will emphasize for anyone following along at home that the "privilege" is only the lower passing threshold, not a retention of the mop. Indeed the proposal will likely reduce the length of time that an admin can hang on to the tools after a successful recall petition, by obviating the scenario we just had and limiting that grace period to 30 days plus the length of RRFA/AELECT. Vanamonde93 (talk) 19:21, 29 October 2025 (UTC)[reply]
Oppose I don't believe that AELECT has proven itself to be fit for the task of the recall system. It produces admins, but I don't really think the evidence is there that the marked lack of scrutiny isn't a problem. Affixing two new systems to each other isn't a good idea. Stick with 30 days for an RFA. Parabolist (talk) 22:35, 29 October 2025 (UTC)[reply]
@Parabolist: AELECT is already an option. But only if the 30-day window after the closure of a recall petition overlaps with the call for candidates of an AELECT or - as happened this week - the bureaucrats grant a discretionary delay. I am seeking to abolish that discretionary delay, which is primed for inequities. Vanamonde93 (talk) 00:47, 30 October 2025 (UTC)[reply]
Right, but extending this window essentially guarantees the choice of AELECT. The inequity is that poorly timed (by my personal standard) recalls can allow for less scrutiny in how the tools are reconfirmed. So this solution does solve that, but by making everyone have the worse outcome. For the record, I'm against the crats allowing the extension they're allowing in this case, so I'm at least consistent! Parabolist (talk) 00:58, 30 October 2025 (UTC)[reply]
Acknowledging that our data about AELECT is still limited, I genuinely do not think admins would necessarily choose to participate in AELECT over RFA. As I see it the major difference is in voter anonymity. It's an open question whether editors would be more likely to support a recalled admin if they are anonymous. I suspect it depends on the popularity of the admin and the nature of their transgressions. You're entitled to your opinion of course. Vanamonde93 (talk) 16:37, 30 October 2025 (UTC)[reply]
Support mainly because if I had had the chance, I'd have chosen an administrator election instead of the classical RfA process, and because I'd prefer a re-election to a re-RfA. Whether this can be discounted as a biased vote with a conflict of interest, or given additional weight as one made with experience others lack after having experienced both RfA and ACE, I don't know. ~ ToBeFree (talk) 01:38, 30 October 2025 (UTC)[reply]
If they want the lower threshold for success that the community consensus says they are entitled to, then they can only do this if an admin election happens to be scheduled within about 30 days of the petition being certified. As elections only happen every 5 months, that's only a (very approximately) 20% chance. Thryduulf (talk) 04:06, 30 October 2025 (UTC)[reply]
Though given the level of discretion hasn't been said fully as far as I know that does mean the 20% figure you gave could change a fair ammount(to the point where I would say there isn't a percent even very aproximately given the level it could change.) GothicGolem29(GothicGolem29 Talk)16:37, 30 October 2025 (UTC)[reply]
The level of discretion is not formally bounded, but given the comments at BN regarding the current case I'd be very surprised if it were extended much further. For the sake of argument, if we assume that the crats said an extra 20 days was acceptable but 21 days was not (I think this is more generous than it would be in reality) then that gives a 50-day window during which admins can nominate themselves for AELECT with the reduced threshold. The duration of the nomination window is not specified in the policy but it has been 7 days every time so far. So the 50-day and 7-day windows need to overlap, and let's generously assume that every part of the 50 days is equally useful (in reality it won't be due to real life commitments, not having prepared a nomination statement in advance, etc). The 50 day window can occur at any time, the 7-day window occurs only once every 5 months - so a maximum of three times a year.
If my maths is correct (and I'd really like someone to double check if it is) then there are 414 possible 50-day windows with at least 1 day in a non-leap year. Only 21 of those overlap with a nomination window, which is actually very slightly over 5% - and thats with very generous assumptions. Thryduulf (talk) 17:49, 30 October 2025 (UTC)[reply]
Oppose and propose instead that any admin who receives 25 signatures for RECALL is immediately desysopped, and prevented from running for admin again until 6 months has passed, after which they may run again for admin (with no reduced pass threshold). Tewdar 15:01, 30 October 2025 (UTC)[reply]
Oppose per Levivich. The current system does not need amendment. If a former admin wants to request re-adminship after 30 days, they are welcome to do so at RfA (under the regular thresholds). Ajpolino (talk) 19:07, 1 November 2025 (UTC)[reply]
Oppose. If you prefer AELECT over RfA, then you can wait, just like everyone else. If not having admin rights for a few months is unacceptable for you, then you should not be an admin. Thebiguglyalien (talk) 🛸02:13, 2 November 2025 (UTC)[reply]
Sorry, I could've been clearer. My opinion is that a desysopped admin, even "temporarily", is just a regular editor and I've yet to be convinced that special considerations need to be given. Thebiguglyalien (talk) 🛸16:22, 2 November 2025 (UTC)[reply]
Support One of the pluses of RfA is you can choose when it happens. RfA is one of the most stressful things I ever did (on par with taking the bar exam). This is a volunteer project afterall, and we are struggling to recruit and keep editors. Giving folks a little more leeway to choose a time that fits their life best is humane and sensible. CaptainEekEdits Ho Cap'n!⚓20:45, 2 November 2025 (UTC)[reply]
Support I find it a little weird that whether admins get to run in an election with the lower threshold depend solely on whether they happened to be recalled at the right time. While I'm not suggesting anyone has done so, it could easily lead to concerns an editor has chosen to start the recall precisely at a time to prevent an admin chosing election. More significantly, one of the concerns expressed by those opposed to the way recalls are currently working is that a successful recall means that the admin is going to be permanently desysoped in part because their chances are already low and in so much as they might have a chance with the reduced threshold, the stress of doing so when the former admin is effectively required to run an RRfA in an emergency rather than at a time of their choosing means the reduced threshold is basically pointless. Frankly, I'd prefer an immediate desysop upon successful recall and the admin then getting 6 months to decide whether to try to confirm their adminship than the current system (by which I mean they have to start an RfA or enter an election). While I appreciate even under the proposed change if the timing is off an admin might still have to run an election in an emergency which isn't ideal it strikes a decent balance although I wouldn't be opposed to extending it to 9 months to give an admin the chance to not have to run for an election in an emergency. Although I appreciate this does mean memories of the problems with an admin will be less fresh, I still feel it's a decent balance noting also most recalls seem to have been for longer term problems. Nil Einne (talk) 13:26, 10 November 2025 (UTC)[reply]
Support Allows admins an additional choice in how to proceed. If actions that led to a recall petition are very problematic, there are other options we have as a community. --Enos733 (talk) 16:43, 17 November 2025 (UTC)[reply]
Support Having an explicit procedure in place for the extension is better than the approach used for the most recent recall petition. I prefer 30 days or the next admin election, whichever comes later per Mr. Starfleet Command below to a blanket six-month period. mdm.bla02:54, 19 November 2025 (UTC)[reply]
As Stifle pointed out, specific proposals got a bit lost there, as tends to happen with a general temperature-taking exercise. This proposal isn't limited to AELECT though. Vanamonde93 (talk) 18:30, 26 October 2025 (UTC)[reply]
I don't fully understand the implications. Are admins that have been defrocked by recall barred from future RfA if they are not re-confirmed within the time window? If not, what would be the purpose of the additional phrasing regarding temporary etc.? It sounds needlessly complicated. ~2025-31522-63 (talk) 20:01, 22 November 2025 (UTC)[reply]
Thanks for elaborating, Mr. Starfleet Command. I read your comment below and on reflection, with every compassion I have, I'm increasingly leaning towards what I said above - let me elaborate further: that (1) recall should be solidly designed in such a way that (2) we don't feel we need to give failed admins soft landings, and (3) we, as a community, commit to promoting admins that can act and communicate better than the ones that have been recalled. Perhaps more importantly, incentivising quick re-application takes away the time for reflection that the recalled person may need. ~2025-35544-03 (talk) 22:52, 24 November 2025 (UTC)[reply]
In the voting section, several editors have commented about setting the next admin election as the deadline for an admin who is the subject of a certified petition to decide whether to initiate a new RFA/AELECT with the reduced passing percentage versus a fixed deadline (whether that is the current 30 days or something longer). The next election could be as long in the future as almost 6 months (nominations closed just before the petition is certified) or as short as (in theory) minutes but more realistically a few hours - all of which could be in the middle of the night in the subject's timezone or during some other period where they are unable to look at Wikipedia. This means an admin could go from being in apparent good standing to desysopped with little or even no warning at all. Obviously in extreme cases the crats would uncontroversially use their discretion and not insist on the literal meaning of "next election" (doubly so if there was any indication of gaming the timing of the petition or its closure). However given the ongoing discussion about discretion in UtherSRG's case, if we're going down the movable deadline we need to put some guidelines in place for the minimum time before the deadline. Hopefully even those who see nothing wrong with the current system can agree that 5 days or less is unarguably not fair on the admin, but what if the close of nominations is 29 days after the petition was certified? If those choosing RFA get up to 6 months, does that mean that's the minimum someone choosing AELECT gets? With the possible exception of those opposed to any recall procedure in principle, I can't see anyone agreeing that 11 months (6 months minimum, plus up to 5 further months for the next election) is within the spirit of the process. Where in the middle of the extremes does consensus lie though? It needs to be long enough to enable the admin to make a considered decision and, if they choose to stand, to write a good nomination statement but not so long that an admin who is actually and actively causing harm to the project can be reasonably curtailed. I should stress that this is explicitly not trying to influence consensus either way regarding this option, I'm literally just surfacing questions that need answers before it could be implemented. Thryduulf (talk) 03:22, 27 October 2025 (UTC)[reply]
It is largely to avoid these sorts of questions that I proposed an unchanging six month window that should always encompass an admin election that's more than a few hours after recall. Vanamonde93 (talk) 04:48, 27 October 2025 (UTC)[reply]
AELECT is too young a process to know how often it will end up running over time.
Thryduulf, I might be able to support a year-long window. It might be nice if de-sysopped folks took a little while to reflect on what went wrong and whether they want to re-commit to a community that just rejected them. A decision made while emotions are still running high might not be the best for anyone. WhatamIdoing (talk) 06:28, 27 October 2025 (UTC)[reply]
Small point: it might be better not to frame recall petitions as rejection by the community; formally speaking at any rate, that would come at an RFA or AELECT. Seeing a petition that way might even be making emotions run higher. Otherwise yes, taking time to take stock should be encouraged, assisted and if possible normalised. NebY (talk) 12:49, 27 October 2025 (UTC)[reply]
How about this: the deadline is 30 days or the next admin election, whichever comes later. That way, an admin is always guaranteed at least 30 days time to initiate an RRFA, but also has the option to stand for AELECT if they so choose. Desysopping would still occur after just 30 days. Mr. Starfleet Command (talk) 00:21, 18 November 2025 (UTC)[reply]
I would accept this idea over the status quo, but it's still more complex wording than what I suggest, and has the effect of making the timing of an RRFA contingent on the timing of an EFA. Vanamonde93 (talk) 22:18, 19 November 2025 (UTC)[reply]
I don't understand what this would accomplish: since the editor would be desysopped after 30 days, they'd be a non-admin editor entitled to run during the next AELECT like any other editor even without this change in wording. Schazjmd(talk)22:49, 19 November 2025 (UTC)[reply]
@Schazjmd: The difference would be that, with this wording, they would be able to run with the lower passing threshold, whereas otherwise they would be subject to the normal threshold. Whether this is desirable is a separate question, and IMO should be the main topic of discussion here. Mr. Starfleet Command (talk) 01:10, 20 November 2025 (UTC)[reply]
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
Marked historical as unneeded, unenforced or lacking consensus?
If C or D are adopted, the following guidance at WP:NCPLACE#Belgium would be removed: The Brussels naming conventions should be used for articles related to Brussels.
If C or D are adopted, a discussion would be opened to determine the status of the Brusselsname talk page template.
This page was marked as a guideline 2009 by Oreo Priestafter discussion on the talk page and a much more substantial discussion at Talk:Brussels-Capital Region. For those who are not familiar with the subject matter, Brussels is now a majority francophone city, but historically was Dutch-speaking. Place names in the city are thus the subject of controversy. As shown in the discussion, this topic area seems to have been subject to a substantial dispute on Wikipedia prior to the creation of this page. More than a decade has passed, and the dispute is mostly forgotten. Recently, twoeditors have removed the guideline tag, saying that it should be properly situated as a Wikiproject advice page. To come to a consensus about what we should do with this page, I have opened this RfC. Yours, &c.RGloucester — ☎06:43, 31 October 2025 (UTC)[reply]
B – This page is useful, and served to quiet a long-standing dispute over place names in Brussels. However, the page itself is not suitable as a standalone guideline, because it provides no original guidance. Instead, it explains how editors came to a consensus in this topic area based on our other policies and guidelines. It is not suitable as a Wikiproject advice page either, though, because it is currently referenced at the WP:NCPLACE#Belgium guideline, which specifies that editors should follow its guidance. Therefore, I think the best option is to retain the page, break it off from the Wikiproject, and make it an explanatory supplement to NCPLACE. Yours, &c.RGloucester — ☎06:43, 31 October 2025 (UTC)[reply]
B – An INFOPAGE is reflective of both its content and its unclear level of consensus. It might be worth looking at Category:Wikipedia naming conventions, which only has the main category for guidelines and a subcategory for proposals, so doesn't provide a place for supplementary pages.--Trystan (talk) 13:54, 31 October 2025 (UTC)[reply]
Option D its a solution for a problem that isn't needed. We are already supposed to use English names or the names used in English WP:USEENGLISH so we don't need another policy that largely states the same thing but with an odd caveat that objects without Wikipedia articles should ignore that and instead use a dual name. We already have too many pointless precise guidelines when general guidelines already suffice. Traumnovelle (talk) 08:40, 10 November 2025 (UTC)[reply]
This page was marked as a guideline 2009 by Oreo Priest after discussion on the talk page and a much more substantial discussion at Talk:Brussels-Capital Region I cannot see discussion about marking this page as a guideline on either of those talkpages; could you link to an actual discussion rather than an entire talkpage? Caeciliusinhorto-public (talk) 11:01, 31 October 2025 (UTC)[reply]
This was an informal process of consensus making, which is why I linked the whole talk page, though sections 1, 2, 3 and 4 are the most relevant. The page was drafted by a variety of editors from WikiProject Belgium in 2009. If you are asking for a specific discussion that resulted in the guideline tag being added, that would probably be the Wikipedia talk:WikiProject Belgium/Brussels naming conventions#In conclusion section, which was immediately followed by Oreo Priest's action. If you are looking for a discussion that meets the current expected standard, i.e. WP:PROPOSAL, there is none. Yours, &c.RGloucester — ☎12:15, 31 October 2025 (UTC)[reply]
Which is to say, there was no discussion about marking it as a guideline. There were only comments from people who assumed that of course it was going to be a guideline. WhatamIdoing (talk) 19:01, 31 October 2025 (UTC)[reply]
Wikipedia:Naming conventions (Cyrillic) is not a Wikiproject advice page, but an information page, outside of any Wikiproject's control. It is not normal for a guideline to prescribe that editors should follow Wikiproject advice without any obvious consensus, because Wikiprojects are not rule-making organisations, per WP:PJ. Guidelines may sometimes link to Wikiproject pages as a reference, but that is different from prescribing that one should follow a given project's internal strictures.
Keep in mind, the removal of the guideline tag in this case was premised on 'simplifying our policies and guidelines'. Think of a random editor that encounters the guidance at WP:NCPLACE, or the talk page template above, which prescribes that one should follow the guidance at Wikipedia:WikiProject Belgium/Brussels naming conventions, but then, one arrives at the page and encounters a template that says that its contents are the mere 'opinion' of a Wikiproject that has not been vetted by consensus. This is beyond confusing, and one will be left wondering, should this guidance be followed or not? This is the opposite of simplification, it is confounding. Yours, &c.RGloucester — ☎00:15, 1 November 2025 (UTC)[reply]
Nope. I removed the {{guideline}} tag, and I did so not out of any desire to 'simplify our policies and guidelines', but solely because tagging it as a guideline was a violation of both the WP:PROPOSAL policy and the WP:PROJPAGE guideline.
It's true that I found the list of violations over at that WikiProject's talk page, but that was only a matter of where I happened to see it; I'd have done the same thing no matter when or where I found out about it. WhatamIdoing (talk) 00:59, 1 November 2025 (UTC)[reply]
I see. What I would point out to you again, as I have done before, is that merely removing or changing a tag without considering the impact of that change on adjacent articles, guidelines, and policies is not very helpful, if the end result is to make our guidelines even more confusing. The point of this RfC is to tidy up what is admittedly a mess, and ensure that there is a clear consensus for any result. No matter which option is adopted, the end result will be a simplification, a clarification, and that is something I think that even you should find laudable. I long for your constructive participation here, as your many years of experience in the topic area will be of great value in reaching a well-reasoned consensus. Yours, &c.RGloucester — ☎01:16, 1 November 2025 (UTC)[reply]
What I would point out to you again, as I have done before, is that changing this tag has no effect whatsoever on any guidelines or policies.
Wikipedia:Policies and guidelines#Content says "Policies and guidelines may contain links to any type of page, including essays and articles". Almost nobody is actually confused when they see that a guideline has linked them to an essay page, probably because almost all experienced editors have banner blindness, and those who don't are used to our practices.
For example, the introduction to WP:V has links to two essays (both of the "supplement" variety), and its first section has links to two "information pages" that "may reflect differing levels of consensus and vetting". The next section has links to four ordinary Wikipedia articles and two essays (one ordinary and one of the "supplement" variety). This happens in almost all of our policies and guidelines, and people are not confused by it. If you're genuinely confused by it, then you're confused by basically every policy we have. WhatamIdoing (talk) 01:42, 1 November 2025 (UTC)[reply]
As for reaching consensus: I don't actually care what the page's title ends up being or what it gets tagged with – so long as it isn't a {{guideline}} that implies it's WP:OWNED by any WikiProject.
IMO the only actual {{guideline}} that can have "WikiProject" in its name is WP:PROJGUIDE, and that's because WP:COUNCIL is a bit more like a weird meta-noticeboard for people trying to organize groups than like a real WikiProject. (Even then, if PROJGUIDE got moved to another title, that wouldn't break my heart.) WhatamIdoing (talk) 01:48, 1 November 2025 (UTC)[reply]
I agree with you entirely that Wikiprojects should not have any control over any guidelines, and this is a position I have consistently held in any discussion on the subject. However, there is nothing to be gained from narrowly focusing on the title of the page or procedural concerns without considering the page's actual value or function. As for 'links', yes, many guidelines and policies link or reference essays, as I said above. The issue is not a link or reference, but the guidelines' current prescription that editors should follow what is now tagged as a 'Wikiproject advice' page. This is clearly irregular, as it is basically delegating rule-making authority to a Wikiproject, something that is out of line with WP:CONLEVEL. Yours, &c.RGloucester — ☎04:13, 1 November 2025 (UTC)[reply]
It is appropriate and helpful to take corrective action and remove the guideline template from any page which is not a guideline. Recognition must be denied to the status quo to begin with. That is because a lack of consensus to "demote" the false guideline is not an acceptable outcome. Instead, the falsehood that a given page is a guideline needs to be addressed, and then the same page may be made into a guideline, or it may not become a guideline, and both of these outcomes are acceptable—whereas maintaining the falsehood that a page that is not a guideline is a guideline because of a lack of consensus to correct the falsehood is not acceptable. —Alalch E.13:32, 1 November 2025 (UTC)[reply]
I agree with Alalch, and I add that it's not "clearly irregular" to recommend good advice, no matter where it's found. For example, Wikipedia:Manual of Style/Medicine-related articles recommends advice pages from three different WikiProjects, and the absence of the exact word should in those sentences in no way lessens the recommendation about where to find the specialist advice. WhatamIdoing (talk) 17:29, 1 November 2025 (UTC)[reply]
If a guideline tag has been stable for more than ten years, that in and of itself is a form of consensus, per WP:EDITCON, though as WP:PROPOSAL says the tag itself does not grant guideline status. Whether the community wants the page to actually be a guideline or not can only properly assessed in an RfC, and that is what is being done here. This incredibly narrow focus on the tag itself is bizarre, because Wikipedia is not a bureaucracy. You say that it is not 'irregular' to recommend 'good advice', but have not bothered to consider whether this page actually is 'good' advice, never mind that the page is written as if it were a guidleine, and never mind that an actual guideline references the page not merely as a recommendation, but as almost mandatory, excluding the usual IAR exceptions, and that numerous Brussels-related pages currently have a talk page template that specifies that editors should follow this page. I understand what you are trying to do, but please consider the impact on actual articles. This is an encyclopaedia, and these sorts of pages don't exist in a vacuum. They only exist in as much as they help us build an encyclopaedia, and that is where your thoughts should go, not to some legalistic understanding of the meaning of the word 'guideline'. Yours, &c.RGloucester — ☎04:25, 2 November 2025 (UTC)[reply]
The word should does not mean "almost mandatory".
I am not particularly concerned about whether this page offers good advice. I assume that it does, but I don't really care whether it does, and I will not spend my time figuring out whether it does.
What I care about is whether the process for tagging the page was improper (answer: yes) in a way that misleads ordinary editors into thinking that it was actually vetted by the community (answer: yes) instead of being advice put together by a small group of editors (answer: yes). I fixed the misleading and procedurally improper parts. You may find it better to describe my focus in this process as bureaucratic rather than bizarre.
If you want to make a WP:PROPOSAL or otherwise pick an arrangement that is procedurally proper and results in a non-misleading status for the page, then be bold! But my chosen role doesn't extend to that point. I'm here for the "not wrongly marked as a community-wide guideline" part. What it ends up getting marked as is not important to me, so long as the result is not wrongly marked as a community-wide guideline.
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.
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
This request for comment proposes deprecating the Associated Press Stylebook as a naming authority within WP:USPLACE. The current guideline ties certain U.S. city article titles to whether the AP Stylebook lists them as not requiring a state name, a practice that dates back to Wikipedia’s early years. However, this external dependency conflicts with Wikipedia’s self-governed policy hierarchy and with the way other countries’ naming conventions are structured. No other national convention relies on an outside publication to determine article titles. This discussion invites editors to consider whether Wikipedia should instead base U.S. city naming solely on internal principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC, supported by verifiable usage data such as pageviews and clickstreams.
Proposal
Deprecate the Associated Press Stylebook as a naming authority within WP:USPLACE. Future decisions about the inclusion or omission of state names in U.S. city article titles should be based solely on Wikipedia’s internal policies and verifiable usage evidence.
Replace the existing paragraph:
"Cities listed in the AP Stylebook as not requiring the state modifier in newspaper articles have their articles named 'City' unless they are not the primary topic for that name."
with:
"Cities are titled by the most common and unambiguous name used by readers and reliable sources, in accordance with WP:TITLE and WP:PRIMARYTOPIC. The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides.""
Add an explanatory note:
"References to the AP Stylebook in earlier versions of this guideline are deprecated. Wikipedia naming conventions should rely on internal policy and verifiable data, such as reader behavior or reliable source usage, rather than on external editorial manuals."
Background
The current wording of WP:USPLACE incorporates the Associated Press Stylebook as part of its reasoning for which United States cities are exempt from the “Placename, State” format. This reliance on an external publication is unusual within Wikipedia’s system of self-contained policies and guidelines. Other country-specific naming conventions (for example WP:UKPLACE, WP:CANPLACE, WP:NCAUST, WP:NCIND) rely only on internal policy principles such as WP:TITLE, WP:COMMONNAME, and WP:PRIMARYTOPIC.
Rationale
The AP Stylebook was created for journalistic brevity, not encyclopedic clarity. Wikipedia’s naming standards are designed for reliability and reader intent, not for newspaper copy.
No other country’s naming convention cites an external editorial manual as authority. The United States should not be an exception.
The AP list of cities without state modifiers is dated and arbitrary, reflecting mid-20th-century newspaper familiarity rather than modern global recognition.
Wikimedia’s pageview and clickstream data provide transparent, empirical evidence of what readers mean when they search for a city name.
This change aligns WP:USPLACE with WP:TITLE and WP:PRIMARYTOPIC, ensuring that the same principles apply worldwide.
Intended outcome
Consensus to remove or deprecate references to the Associated Press Stylebook from WP:USPLACE and clarify that U.S. city naming follows the same internally governed, data-based principles used for other countries. TrueCRaysball💬|✏️18:07, 10 November 2025 (UTC)[reply]
I strongly oppose something as broad as The inclusion or omission of a state name is determined by actual disambiguation need, not by external style guides. While I may agree with the principle that we needn't rely specifically on only the AP for which cities have standalone names, I believe nearly all US cities should still include the state name in the title, even if the city is the primary topic for that name or disambiguation isn't needed. Even if we could retain our discretion to deviate from the AP in particular in some circumstances, I see no issue with the current practice and this method helps avoid pointless move debates while maintaining consistency. I'd rather extend this practice of including a state name in the title to other countries, rather than the other way around. Reywas92Talk18:31, 10 November 2025 (UTC)[reply]
Isn’t that the entire point of a Village Pump discussion? To craft something better that we can all agree to through consensus? The AP standard is written for journalists, not encyclopedias, and in my view it has no place in our naming conventions. TrueCRaysball💬|✏️19:21, 10 November 2025 (UTC)[reply]
I've shared my opinion, others are welcome to contribute. I see no strong reason to change the current consensus, and even if the wording were changed not to prioritize just the AP, I strongly believe we should not start proposing to remove state names from other titles, which would be a huge waste of effort over something that works fine as it is. Reywas92Talk19:31, 10 November 2025 (UTC)[reply]
Oppose per Reywas. This reads like a solution in search of a problem. I have no objection to deviating from the AP in individual cases if someone can demonstrate a benefit from doing so, but as a general rule everything is working fine as it stands and I see no benefit to changing it after this many years without problems. Thryduulf (talk) 19:51, 10 November 2025 (UTC)[reply]
Oppose – There is no evidence of a problem with the existing scheme. It is clear, a long-standing consensus, and based on a reliable source. Implementing this change will result in the need to reconsider the article titles of thousands of pages, for no good reason, resulting in a waste of valuable editor time. See WP:TITLECHANGES and WP:BROKE. What will the reader gain from this change? As far as I can see, nothing. If the text of the guideline needs to be rewritten, that can be arranged: WP:CONSISTENT is one element of our article titles' criteria. As mentioned above, it is already possible to deviate from this guideline when consensus exists. Yours, &c.RGloucester — ☎00:32, 11 November 2025 (UTC)[reply]
Oppose Regardless of its intent, the AP Stylebook is still reputable, and our usage of it to help inform our guidelines, as others have stated, has not caused any issues as far as I'm aware. Lazman321 (talk) 04:08, 11 November 2025 (UTC)[reply]
Comment - Several of the opposes here rely on "if it ain’t broke, don’t fix it" reasoning or the assumption that editors can already make exceptions. However, that ignores the reality of how this actually functions in practice.
Every city move discussion in the United States is automatically opposed or SNOW-closed on the basis of WP:USPLACE, even when strong evidence and consensus-building attempts are presented. That means editors cannot meaningfully discuss exceptions. The policy itself shuts down the conversation before it can happen. My own RM of Orlando, Florida from last year is one of many examples.
Additionally, the claim that "it works fine" does not hold up when data says otherwise. Clickstream analytics show that thousands of readers type terms like "Orlando" expecting to reach the Florida city, only to land on a disambiguation page and have to click through. That is, by definition, a navigation failure. It proves the system is broken for readers. Not just editors.
The workload objection is also a red herring. A simple "grandfather clause" could apply: existing titles remain until a discussion is individually initiated. No one is proposing a mass retitling campaign.
Finally, the AP Stylebook is written for journalists, not encyclopedias. Its inclusion in our naming conventions has no policy basis and should not function as an unchallengeable authority. We have robust internal guidelines like WP:COMMONNAME and WP:PRIMARYTOPIC that already handle naming consistently and logically without relying on external style manuals. TrueCRaysball💬|✏️04:46, 11 November 2025 (UTC)[reply]
That your proposed move was rejected does not indicate that anything is amiss with the guideline. What it means was that you failed to provide persuasive evidence of a 'good reason' to change the article title per WP:TITLECHANGES. In fact, in that RM, you failed to provide any evidence to support your claims, at all. I can see that you are now engaging with empirical data, such as Clickstream analytics. If you think you can make a better case now per WP:PRIMARYTOPIC, you are free to open a new RM discussion. Yours, &c.RGloucester — ☎05:46, 11 November 2025 (UTC)[reply]
I think the current guidelines would suggest that the proper RM if you're right about PTOPIC would be Orlando → Orlando (disambiguation), with Orlando turned into a redirect to Orlando, Florida. That way all the readers expecting to reach the city will get there right away, and a hatnote at the city page could send confused readers back to the dab page. It looks like this was last discussed here in May and there was consensus that the city is not the primary topic. Firefangledfeathers (talk / contribs) 14:29, 11 November 2025 (UTC)[reply]
Replying here since I realize my oppose was a little snippy and I think this comment makes it clearer what you are getting at. My understanding is that you feel that WP:USPLACE is causing undue knee-jerk opposes to RMs like Orlando, Florida -> Orlando that you think would benefit the wiki. But the actual RFC reads like you asked ChatGPT "write me an RFC that will stop wiki editors from using WP:USPLACE to oppose my RM". That's probably why this RFC is getting so many opposes - we don't like having our time wasted. It would be more helpful to present clearer arguments at your RM next time (maybe share some of this clickstream data you mention). -- LWGtalk17:32, 14 November 2025 (UTC)[reply]
Oppose I think there is benefit from nearly all US places having the state added. We also benefit from not discussing (too often) which cities should or shouldn't be exempted, which would definitely happen more if we pull in the list locally. I'd be more likely to support removing the AP list exemption and move the 29 cities to names with states. As mentioned above, primary redirects could still exist for cities whose names are the primary topic for that term. Skynxnex (talk) 19:10, 11 November 2025 (UTC)[reply]
One, no one is suggesting removing the "city, state" format. I suggested moving the standard to internal review/consensus for which use the state and which don't instead of relying on an external style guide. Two, the latter suggestion only makes sense if you're gonna do that with every country that also is broken down into counties or states, or even just a simple "city, country" format. Consistency is key here and is the entire premise of my starting this RfC. TrueCRaysball💬|✏️20:33, 11 November 2025 (UTC)[reply]
I never said anyone was proposing removing the City, State format. But given we have only 29 localities special cased currently (DC is its own thing), to me the implication is very strongly that this proposal is to allow more places to be named by just their name without state added.
I don't think that all countries need to have consistent rules for populated places. I think the US model might be good to apply to places like Canada and Australia (maybe others?) where the state-level subdivision matters more than in some countries. But in some places I believe it's generally seen as less of a part of the identity/name of the populated place. I think consistency within a country is more important and why I idly mentioned as both a reason to oppose this and maybe weigh people's willingness to rename things like Cleveland to Cleveland, Ohio. I doubt that is likely at this time.
I think you providing some examples of specific US place article titles that would be improved by this change may be helpful. But Myceteae's comment describing reasons why the status quo is probably better helps make specific examples somewhat unneeded. Skynxnex (talk) 01:57, 12 November 2025 (UTC)[reply]
Oppose. The current guidance is not broken and does not need fixing. Appealing to an external style guide is not inherently at odds with WP policy and practice. Much of the content in our naming conventions and MOS reflects and is consistent with external style guides and accepted conventions, even when these are not explicitly cited. Furthermore, consensus to adopt a particular external standard is valid. We do this explicitly in several places, such as (the admittedly controversial) MOS:FRENCHCAPS, and numerous naming conventions that refer to specific authoritative bodies to source appropriate article such as WP:NCFILM and WP:MEDTITLE. The whole section WP:USPLACE does incorporate local (US) customs, as does the entirety of Wikipedia:Naming conventions (geographic names). This does result in discrepancies between how cities in different countries are handled, especially in English-speaking regions where WP:ENGVAR considerations prevail. The AP Style guidance is authoritative, appropriate, and represents a specific application of broader guidance like WP:COMMONNAME to a particular subject area. Referring to a respected external source simplifies decision-making, harmonizes article titles, and prevents endless battles about when to drop the state. —Myceteae🍄🟫 (talk) 00:06, 12 November 2025 (UTC)[reply]
This RfC fundamentally misunderstands how USPLACE operates. I don't know if it is a misreading of the guideline or something to do with an llm, but it is backwards. USPLACE ignores WP:PRIMARYTOPIC, setting the standard as "Place, State". The AP-exceptions are the only place where WP:PRIMARYTOPIC is considered. The proposed change leads to the opposite impact that the rationale seems to want, so I suggest the RfC is closed as it cannot as proposed actually lead to a consensus for change. CMD (talk) 04:09, 12 November 2025 (UTC)[reply]
Oppose I agree with RGloucester that this would lead to a waste of editor time for little to no benefit to readers, with Myceteae that there is no procedural problem with the current situation, and with CMD that this RFC doesn't seem to have a coherent purpose. -- LWGtalk16:00, 14 November 2025 (UTC)[reply]
Sympathize. I agree that the AP Stylebook is a pretty arbitrary way to determine which U.S. cities play by WP:PRIMARYTOPIC and which are exempt. I don't recall how I've !voted in the past, but it does seem like a cleaner solution would be to strike the AP stylebook, and either (1) apply WP:PRIMARYTOPIC as normal, or (2) require City, State for every U.S. city. If the argument is that "City, State" is the dominant convention, then there is no reason to have Baltimore coexist with Nashville, Tennessee. It should be Baltimore, Maryland, with Baltimore as a WP:PRIMARYREDIRECT. Or, allow Nashville as an article title (since it already redirects there). Either way would go a long way to eliminate the perennial move requests and RfCs like this one. The status quo is inherently unstable. But it's also very ingrained in Wiki-world. Dohn joe (talk) 21:49, 14 November 2025 (UTC)[reply]
Oppose. Wikipedia follows usage in reliable sources. Sometimes usage is unclear but in this case the AP list provides explicit guidance for usage in U.S. RS for U.S. cities. It’s unusual but not a problem. That said, I’ve long held US city article titles should be treated like all others: disambiguate only when necessary. The name of any city is just its name, not including the state name. It’s misleading and endlessly confusing to include the state name when it’s not needed for disambiguation. Redirecting a base name of any US city to a title disambiguated by state name sets a contradictory and confusing standard, leading to countless unnecessary conflicts and debates. Thankfully, most other topic-area-specific naming conventions have been refined to disambiguate only when necessary, but USPLACE remains an unfortunate exception. —В²C☎13:08, 16 November 2025 (UTC)[reply]
I understand the impetus to do away with WP:PRIMARYTOPIC, but I think most proponents overlook a key benefit of the policy. The benefit is what it communicates to users about common usage. For example, our article on Paris being at Paris, rather than at Paris, France, conveys the useful information that the term "Paris", alone, normally refers to that city in English. Nobody says, "I'm going to Paris, France in July"; they say, "I'm going to Paris in July". Despite other common uses of the term, including the Greek god, the film, many other cities including the one in Texas, the way we refer to the city in France is justParis. To put it at Paris, France would be misleading about common usage in English. That's what Primary Topic is about; convey common English usage accurately. Let's not lose that. --В²C☎04:07, 20 November 2025 (UTC)[reply]
Oppose While I see why you think this should be locally determined by principle, this isn't something that actually really matters that much in my opinion. The main importance is to avoid editors spending huge amounts of time arguing about it, and using an external resource solves that problem perfectly. As long as we have a decision that's ok it doesn't need to be perfect. Mrfoogles (talk) 16:59, 5 December 2025 (UTC)[reply]
RFC on the notability of corporate goods and services
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
WP:NCORP presently states that it is to help "determine whether an organization (commercial or otherwise), or any of its products and services, is a valid subject for a separate Wikipedia article"
Agree - NCORP is meaningless as a standard if it can simply be avoided by turning whatever WP:PROMO article it is you wish to write into a list of the goods/services of the company concerned. It simply does not make sense that you should be able to write a article listing the goods and services of a company (so basically an article about the company) based on local coverage, trade-press, primary news coverage based on press-releases and company announcements, when you are barred from doing so about the company itself or individual goods and services. Basically, there's no reason why we should be able to have an article entitled List of pizzas sold by Phil's Pizza Shop based entirely on press-releases, local news coverage, and trade-press, when Phil's Pizza Shop would be non-notable under such WP:SIRS-failing coverage. Even a straight-forward reading of NCORP, which states that it applies to "any" of an organisation's goods and services, indicates that it was always intended to means lists of the same. FOARP (talk) 11:05, 15 November 2025 (UTC)[reply]
Disagree. NCORP is unambiguously about prose articles, the relevant standard for lists is WP:NLIST. Multiple people have told you this in multiple different discussions, it's time to drop the stick. Thryduulf (talk) 12:09, 15 November 2025 (UTC)[reply]
Sure, if Phil’s isn’t notable then their pizzas will not be notable. However, what if Phil’s is considered notable? At that point you have to consider why Phil’s is notable.
IF they are notable for their pizza, then a list of their pizzas might be appropriate. However, they might be notable for (say) the architecture of their building… or for some other factor. In which case a list of pizzas is inappropriate.
Apparently this thread was inspired by lists of airline destinations, where the airlines themselves are considered notable (so NCORP is not the issue). The next question is, why are these airlines notable? Are they notable for their destinations? Are they notable for the type of planes they fly? Are they notable for the luxury of their first class service? Etc. Blueboar (talk) 13:23, 15 November 2025 (UTC)[reply]
I think you are confusing two different types of "notable for their food". A restaurant may be notable for having good food, but that doesn't mean that the individual items on their menu are notable and deserving of a listing here. However, a restaurant may be notable for having a "super giant pizza challenge", "world's largest cheeseburger", etc. These sorts of things could be worthy of mentioning in the restaurant's article. To take your airline example, the fact that a hypothetical "Flybynite Airlines" exists and has flights to 37 different countries could be notable, but that those flights include an Ottumwa, Iowa to Bamberg, Germany flight is not. At least not within the parameters of this site. --User:Khajidha (talk) (contributions) 16:31, 17 November 2025 (UTC)[reply]
Disagree The concern that we will have a list of products of non-notable companies is completely hypothetical. It also has an easy compromise solution, allow a list of products of company X only if the company itself passes WP:NCORP. Ultimately, we should prioritize the readers in such discussions. A significant part of them use mobile and benefit from shorter and more to-the-point articles. Stand-alone lists are useful so they don't need to spend additional time navigating the parent article. The readers also won't benefit if we remove most of the entries in Category:Lists of products. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)[reply]
Partial agree Given that NLIST doesn't necessary require notability of the "products made by company X" be a notable topic nor company X to be notable if the list is, we still want WP:SIRS (sourcing requirements) from NCORP to be respected if we're just creating a list where individual products may be notable. Even if company X is NCORP-notable, a full list of their offered product or services without SIRS-type sourcing will still be a problem in failing the goal of NCORP, which is to avoid using WP for promotion or business purposes. If there is SIRS-type sourcing for every product, great (this to me would be a case for something like Apple iPhones which absolutely do not go unnoticed by the general media). But if such a list is heavily relying on only press releases or similar first-party, dependent material, that's not acceptable. Masem (t) 13:34, 15 November 2025 (UTC)[reply]
Close this in favor of Wikipedia:Village pump (policy)/Airport destination lists Do we really need even more wikilawyering from people fighting over that topic? As for the question at hand, WP:NLIST seems the appropriate guideline to follow. If there's any reason that lists of a corporation's products and services can't effectively be handled by WP:NLIST, I doubt we'll find it buried in the airport destination list mess. Anomie⚔15:15, 15 November 2025 (UTC)[reply]
Bad RFC While I appreciate that the proposer does note below what induced them to start this, this feels like a roundabout form of forum shopping to get an answer to one question that he can apply to a different one. This question is a bit vague and does not include a specific proposal regarding language on that page. Anomie makes the right points, though I'll note that airport destination sections are very different from standalone airline destination lists in how they're presented and constructed. Anyway, I disagree and don't think the pages in Category:Lists of products or those the proposer has been nominating necessarily need to be deleted under these grounds. If a corporation is notable, it often makes sense to provide what makes them notable, be that what they manufacture or where they operate. We are generally able to address this kind of listcruft already without this RFC. Reywas92Talk17:05, 15 November 2025 (UTC)[reply]
It is reasonable for a notable company to describe the types of products or services they offer as described by third-party sources. This is not the same as supporting a list of every product or service offered, unless that full list can be supported by third-party sources. Otherwise, that's likely violating NCORP and definitely violating NOTCATALOG. Masem (t) 20:05, 15 November 2025 (UTC)[reply]
But it does square with WP:SUMMARY. These lists of products are properly thought of as sub-articles created as spin outs of the company articles as the list, even if well-curated to avoid becoming a catalog, would be too long for the main article. Can't knee-jerk judge these. oknazevad (talk) 21:55, 15 November 2025 (UTC)[reply]
There's no issue with a curated list of products that have been discussed to some depth in secondary sources (not necessarily enough for a standalone article but more than a simple name drop). But the implication here is a complete list of products or services as a separate list, and that's where NOTCATALOG can be a problem. Masem (t) 02:20, 16 November 2025 (UTC)[reply]
Agree A partial and generalized list of products a company offers should be included in the main company article. I see no reason why there should be a separate list that's essentially acting as a company version of WP:FANCRUFT to include every single product the company offers. And if you are going to have one, it absolutely needs to adhere to minimum WP:NCORP requirements. Wikipedia is not a product directory, though it appears some would like it to be some sort of catalogue of all goods and services that exist. That is not what an encyclopedia is for. SilverserenC21:57, 15 November 2025 (UTC)[reply]
Partial agree In general, I think that the standards of NCORP apply to lists of goods and services. I am not sure to what degree this should also apply to any specific circumstance (such as airline destination lists). — Preceding unsigned comment added by Enos733 (talk • contribs) 00:41, 16 November 2025 (UTC)[reply]
No bold, as I'm not quite sure where my comment would fall. NLIST would seem to be appropriate, but if a company fails NCORP I can't see how a list of their products could be notable. I could also see a list of products being covered by WP:NOTPROMO unless there's independent sourcing. -- LCU ActivelyDisinterested«@» °∆t°
Disagree Wikipedia isn't a shop. Does it say we are shop anywhere? We not in the business of listing a catalogue of goods. That has been understood for more than 2 decades. Its been long established consensus since 2016-2017 years that companies don't list their products unless the product is standalone notable per WP:GNG and the company is notable per WP:NCORP. They it can get seperate article that is sourceable to secondary sources. Before that the company had to be notable per WP:GNG before the product could get an article. There was a reason for this, simply that Wikipedia was flooded by company brochure articles that had reams of products listing. Are we looking to go back to that. It was always understood that product listing were WP:PROMO and needed to be removed. They had to pass WP:GNG to be notable on their own before inclusion. NCORP does not apply to list of goods. It was written specifically for company entities only. How is corporate notability applicable to a product? If the company fails WP:NCORP the product isn't notable. scope_creepTalk07:12, 5 December 2025 (UTC)[reply]
This RfC is another episode in the saga about airline destination lists. Most of the recent AfDs regarding them were initiated by FOARP[2]. Earlier this year, the community expressed their doubts about whether WP:NOT applies to them[3]. Now, the issue is being pressed from the WP:NCORP perspective. The change discussed here was boldly added to the guideline[4] and was reverted[5]. In response, we got this RfC.FOARP himself notes, we still have listings of airline services that don't pass either WP:NLIST or WP:NCORP.[6] So why do we even need to subject the lists to WP:NCORP? In my opinion, to make the discussion more focused, it's better to stick to WP:NLIST. Kelob2678 (talk) 13:26, 15 November 2025 (UTC)[reply]
"why do we even need to subject the lists to WP:NCORP" - to avoid WP:PROMO content based entirely on press-releases, local coverage, trade-press etc., just simply written as a list rather than as a prose-article. FOARP (talk) 15:04, 15 November 2025 (UTC)[reply]
Hi, we were indeed discussing it, but it doesn’t look like there was enough participation since only you and I contributed to the discussion there which was why VPP is probably a better forum. FOARP (talk) 08:27, 16 November 2025 (UTC)[reply]
The core question here is the “group or set” requirement of NLIST… are airline destinations as a set notable? To answer that, we need to ask: Are there independent reliable sources that discuss the concept of airline destinations as a set? Blueboar (talk) 14:03, 15 November 2025 (UTC)[reply]
The "discussed as a group" requirement does not have wide agreement in the community about what it means. Mostly, people seem to think that of course it supports "my" general view on the deletionism–inclusionism spectrum, whatever that view is. WhatamIdoing (talk) 23:09, 15 November 2025 (UTC)[reply]
This reminds me of the discussion that led to ongoing development of the Wikipedia:Directory articles proposal. As a product meeting the standards for having an article does not automatically mean that the associated organization meets the standards, theoretically there could be a company with a list of products that have articles, while the company does not. I don't know if there are current examples in mainspace that we could examine, though. (User:Theleekycauldron/List of projects by Complexly is an example given in the directory articles proposal, though Complexly has a mainspace article.) isaacl (talk) 19:55, 15 November 2025 (UTC)[reply]
Thinking about that example further, I guess privately-held, small-shop companies could be a typical use case. A one-person (or small number of people) company could create one or more video or audio channels, for example. The channels could meet the standards of having an article while the company does not, as there often isn't much available public information about small private companies for secondary sources to write about. isaacl (talk) 20:06, 15 November 2025 (UTC)[reply]
I came across an example a couple of months back that I unfortunately cannot remember the name of when writing a disambiguation page - a small (Indian iirc) motorcycle manufacturer that makes/made 2-3 unambiguously notable models but is not themselves notable as nobody has written anything in-depth about the company (at least in English). Thryduulf (talk) 20:53, 15 November 2025 (UTC)[reply]
That seems so very backwards to me. If a company makes multiple notable products, than that company is notable. WP:NOTINHERETED is a downstream thing, not upstream (like actual inheritance). It is and remains true that just because a product is made by a notable company, doesn't mean the product is inherently sufficiently independently notable for an article. But a notable product does confer notability on the company making it, as the company is notable as the manufacturer of a notable product.
That's exactly how I've always used it and how many of our notability requirements use it. WP:NAUTHOR is entirely about how producing notable works makes the author notable. Similarly with scientists, their notability is based on producing notable research. NOTINHERITED applies to things at a lower level than the thing in question. SilverserenC22:00, 15 November 2025 (UTC)[reply]
I only mentioned English as that's the only language I searched for sources in. NOTINHERITED does work both ways, otherwise the parents of notable children would be automatically notable, holding companies would be automatically notable if any subsidiaries are notable, an author of a notable book would be automatically notable, record companies of notable artists would be automatically notable, etc. That's obviously not the case - the subjects of articles need to have coverage in multiple independent reliable sources. Thryduulf (talk) 22:11, 15 November 2025 (UTC)[reply]
Books have their own notability standard. What we are discussing is that inherited notability upward does occur in specific topics, such as for authors. If you write books that are notable, that notability is conferred on you, hence WP:NAUTHOR. Which is why generally in discussions about author notability, we require 3 RS reviews of an author's books to say they are notable for having written notable books. Because 3 reviews is the minimum standard for book notability even if a book article hasn't been written yet. SilverserenC23:41, 15 November 2025 (UTC)[reply]
Authors are notable through WP:SNG. If the notability were inherited, there would be no need for the SNG at all. But since it is better for the encyclopedia to have articles on academics, the special exception was made for them. No such thing has happened to commercial organizations. Kelob2678 (talk) 13:15, 16 November 2025 (UTC)[reply]
True, but I think that when we parse company vs CEO vs products vs subsidiaries, we're overlooking the value of a merged-up article that covers all of these. We don't want an article title like Bob, blue-green widgets, and Big Business, Inc., but we do want a page that lets us write not just about the motorcycles but also a paragraph about their manufacturer.
For CORP in particular, this should probably be called out as an explicitly desirable outcome. CORP articles are particularly at risk of someone saying "Well, the title is just Big Business, Inc., but half the sources are about Bob and blue-green widgets, and what's left isn't quite enough to count as SIGCOV IRS in my opinion, so I'm taking it to AFD." WhatamIdoing (talk) 00:18, 16 November 2025 (UTC)[reply]
If there's nothing more to say about a production company than "it produces YouTube channel A since XXXX, B since YYYY, and podcast C since ZZZZ", then I can appreciate an argument that a list article is sufficient for the company, and that it does not otherwise meet the standards for having an article. Nowadays, anyone can privately finance a production company and not make any significant public revelations. isaacl (talk) 22:50, 15 November 2025 (UTC)[reply]
Having taken part in a few AFDs of video game studios, I'll second that it is not a popular interpretation of NOTINHERITED at AFD – even if a studio has multiple notable games, AFD consensus is that just the games are notable, not the developers. Nil🥝22:22, 17 November 2025 (UTC)[reply]
WP has no concept of inherited notability in general. Some of the SNGs, like WP:CREATIVE, do give the credence that if the creator has multiple notable works that the creator is presumed to be notable, but that does not extend to companies at all (though I do think for companies that are involved in creative product creation, we should have something in this aspect, but this is not the place for that discussion. Masem (t) 02:23, 16 November 2025 (UTC)[reply]
What we do have is wide latitude to decide how to cover a given topic... In one context it will make sense to have the stand alone article be about the work with a subsection about the creator, in another the creator with a subsection about the work, and in a third both could merit stand alone articles. Horse Eye's Back (talk) 03:48, 16 November 2025 (UTC)[reply]
Having participated in some of the many discussions regarding airline (and airport) destination lists, I think the question is not so much whether NCORP as a whole applies to lists of a company's products and services, but whether NCORP's sourcing criteria, primarily WP:SIRS, should be applied to such lists. If the items on the lists are individually notable then such a requirement would be moot, but does an article listing products or services that are not individually notable require SIRS-level sources covering the list as a whole and/or all items on the list? I think the answer is yes, strict sourcing criteria should apply in such cases, particularly if the list is intended to be comprehensive. Rosbif73 (talk) 15:44, 17 November 2025 (UTC)[reply]
This is an absolutely terrible RFC. Badly thought out in an attempt to usurp 20 years of thinking on corporate notability. Its takes no cognizance of the reasons for NPP/AFC, the storm of UPE company articles between 2008-2018, (mostly brochure and native advertising articles with lots of products listings) the promotional aspect of UPE article nor the reasons for the failure of WP:NORG and the reasons for eventually bringing in WP:NCORP, which are all there to read in the archives. scope_creepTalk07:12, 5 December 2025 (UTC)[reply]
I don't know of a guideline. I prefer repeating the content to using "ditto marks", to help readers who may be unfamiliar with that symbol, but both are acceptable to me. I think leaving the cell blank is a terrible idea. Though I can see how this would make sense to a TV editor (because the tracks are in chronological order), it was not obvious to me that blank cells matched the preceding episode, and I fear many readers will be similarly confused. Toadspike[Talk]11:06, 24 November 2025 (UTC)[reply]
True, but 1) other articles using a particular formatting doesn't always make it the most valid option, and 2) the example provided allows for minimalism, e.g. linking Max Martin and Oscar Holter at their first occurrence, then simply listing them by their surname afterwards; that's not available for episode title names.
I am not aware of any guidance regarding ditto marks. However:
You have not actually implemented the usage of ditto marks. You have used a double prime template {{''}} which produces ″ (←yes, that was it). The second sentence at the ditto mark article to which you linked tells us, The mark is made using a pair of apostrophes; ... the symbol " (quotation mark)..., but the double-prime template produces a teeny, black, slanted blotch that inspires me to clean my display. The template you've used is for displaying a number of minutes.
I had to zoom up my display to verify that there were two strokes there. As such, it is not recognizable as a ditto mark.
My preference to even actual ditto marks ( ", for example) would be the style in use at Doctor Who series 11#Soundtrack (repeating the previous cell, without linking). It's the only one that's clear.
I would think that ditto marks may present an accessibility issue, as it may not be clear when read by a screen reader which data it is referring to. We could have a template that adds the original text as an HTML attribute, but I think just repeating the text is clearer. --Ahecht (TALK PAGE)18:40, 25 November 2025 (UTC)[reply]
I like your suggestion. Ditto marks simplify visually, but a template could provide the data for a screen reader. Substituting "(same) as above" may be the best and simplest option, especially if the dittos are original to a source listing. --Edwin Herdman (talk) 19:45, 25 November 2025 (UTC)[reply]
Implementing rowspans into the track listing template would also prevent the need for ditto marks or repeated information, and are still accessible to screen-readers. -- Alex_21TALK21:38, 25 November 2025 (UTC)[reply]
I prefer dittos for simple cases, not for complicated ones (like that Weeknd album). They affirm the list was checked and something belongs there. Dittos can prevent file bloat and errors (like accidentally copying to the wrong row), while making things easier to understand at a glance.
Blank fields should be reserved for actually blank fields in a mostly blank list. "Music Inspired by Doctor Wot" could have all original music, except for tracks 17-21 being suites from an Episode. The table would be all blank except for 17) Flying Tarragon of Vega, followed by dittos for tracks 18-21, and then a return to blank space until the end of the listing (incidentally, "vega" is a flying eagle). --Edwin Herdman (talk) 19:43, 25 November 2025 (UTC)[reply]
Obvious a good thing to have, but shouldn't this also address what to do when one sees a likely LLM based content, as well as any possible advice where LLM could be used at as only a starting point for writing out by hand? Feels unnecessary fir literally a one sentence guideline when much more can be written. Masem (t) 14:11, 24 November 2025 (UTC)[reply]
These very obvious, crucial deficiencies are among the reasons I and others opposed making this a guideline. The close does note among other strong caveats that In particular we need community consensus on (a) How to identify LLM-generated writing and (b) How to deal with it when it does occur. and it has to be construed conservatively and narrowly for the time being. Until the community has decided on a test of what constitutes an LLM-generated contribution, the threshold is consensus; and this means that we have to treat an edit as human-generated until there's consensus otherwise. (emphasis in the original). Thryduulf (talk) 14:26, 24 November 2025 (UTC)[reply]
I was opposed to it. You could drive a bus through it, as it's so badly written that most editors who decide to use LLM's in a professional manner (UPE's) will completely ignore it, even though at same time, they are following the stricture exactly. It is early days though and it will be expanded soon enough I'd imagine. scope_creepTalk01:54, 1 December 2025 (UTC)[reply]
One can only hope. I was delighted to hear that there was a new guideline addressing this dire problem -- I'd say that over half the threads on the noticeboards now are LLM-related -- until I read it, and shook my head at how weak it was. So as long as the LLM edit isn't a new article creation, it's just dandy? Ravenswing 15:02, 2 December 2025 (UTC)[reply]
Technically it doesn’t even ban that; the lack of clarity about what “from scratch” means you could easily interpret it to mean that creating a new article with an LLM is perfectly fine so long as you feed it information first. In other words, you cannot ask an LLM to generate an article “from scratch”. ~2025-37989-52 (talk) 16:21, 2 December 2025 (UTC)[reply]
This guideline is the way it is because more nuanced proposals kept getting stonewalledrejected, so eventually things got boiled down to what was effectively "AI yes/no?". With that said, there is currently RFCBEFORE in progress on promoting Qcne's proposal to a guideline, as well as many potential expansions/improvements to WP:NEWLLM, if any of you are interested. :) -- LWGtalk15:21, 2 December 2025 (UTC)[reply]
The proposals didn't get "stonewalled", they got rejected or ended up as no consensus because they were flawed in some key way. Its incredibly disheartening that the same wasn't true of the NEWLLM discussion despite how clearly and frequently all the flaws with it that are now causing problems (and some that haven't yet) were pointed out before it was adopted. Writing policies and guidelines is hard at the best of times, and the issues with LLMs that are not simple violations of existing policies and guidelines are hard to actually define (and in some cases hard for people who see such issues to explain why they are actually problematic). Thryduulf (talk) 22:06, 2 December 2025 (UTC)[reply]
Apologies, perhaps stonewalled was too strong a word. I do understand and respect your position in these discussions, even though I think your refusal to allow the bulk of the community who prefers a different path to move forward is a big part of what got us to WP:NEWLLM. -- LWGtalk05:20, 4 December 2025 (UTC)[reply]
It's far from just me who regard badly written policies and guidelines that have a very strong likelihood of consequences like biting newbies as worse than using existing policies and processes that can and do do the job without requirement for unnecessary subjective guesses about whether AI was or was not used. Thryduulf (talk) 13:44, 4 December 2025 (UTC)[reply]
Well sure, there's near unanimous agreement on everything in that sentence up to can and do do the job, at which point you are firmly in the minority as far as I can tell. -- LWGtalk16:51, 4 December 2025 (UTC)[reply]
Agreed. Unfortunately for newcomers who don't know, the community's prevailing attitude towards LLMs appears to be "kill it with fire". I think the best way to keep newbies from being bitten is to explicitly warn them that a large portion of this community despises LLMs and LLM-generated content and will remove it on sight. I have made comments like these before (example) and I feel they are more helpful than a standard {{uw-ai1}} template. SuperPianoMan9167 (talk) 17:00, 4 December 2025 (UTC)[reply]
We appear to have different views about what constitutes a minority then. I agree that there are a lot of vocal editors in these discussions who want to kill everything even remotely related to AI with fire, but regardless of whether that is desirable or not it is simply not practical and doesn't represent a consensus of editors - otherwise there would be a policy or guideline to that effect already. Thryduulf (talk) 17:21, 4 December 2025 (UTC)[reply]
Is there a contradiction between two core policies, NPOV and OR? WP:FRINGESUBJECTS says "Any inclusion of fringe or pseudoscientific views should not give them undue weight. The fringe or pseudoscientific view should be clearly described as such. An explanation of how experts in the relevant field have reacted to such views should be prominently included", while WP:SYNTH says "Do not combine material from multiple sources to state or imply a conclusion not explicitly stated by any of the sources. Similarly, do not combine different parts of one source to state or imply a conclusion not explicitly stated by the source."
Obviously there's no problem with reconciling the two in the main article about a fringe topic, but where fringe theories are discussed in the context of another article it may get trickier. Example: Wikipedia:Fringe theories/Noticeboard#Reform UK. A section of Reform UK discusses their climate policies and views, which are fringe. The discussion is about balancing the presentation of Reform's side with mainstream reactions. I thought that should be done using reactions in reliable sources specifically about Reform to avoid improper synthesis, but it has been suggested that sources that don't mention Reform could be used to satisfy NPOV. Is there a clash and, if so, how can the policies be reconciled? Fences&Windows21:19, 25 November 2025 (UTC)[reply]
It is common practice on Wikipedia to identify pseudoscience/misinformation otherwise many fringe-focussed articles would be given a 'free hit' to expound un-countered misinformation. For example for the propaganda film Died Suddenly, it is pointed out that COVID vaccines don't suddenly kill you contrary to the film's narrative. Likewise if a view in an article is being aired that climate change somehow "isn't real" (be it Reform UK or anywhere else) it should be indicated that this is not the scientific consensus. There may be an discussion to be had about whether this is WP:NOTSYNTHESIS (probably it is), but it would be moot since NPOV is explicitly the non-negotiable policy pillar. I'd have no objection adding an explanation to WP:SYNTH to avoid any possible confusion.Wikipedia is not in the business of "balancing the presentation of Reform's side with mainstream reactions" as this would be textbook WP:FALSEBALANCE. We are obliged to describe fringe ideas "in their proper context concerning established scholarship and the beliefs of the wider world" for NPOV. Bon courage (talk) 00:33, 26 November 2025 (UTC)[reply]
SYNTH is not policy, it's part of a policy against original research. And that policy states:
when incorporating research into an article, editors must provide context for this point of view by indicating how prevalent the position is and whether it is held by a majority or minority.
The problem is bad drafting, which encourages editors to view SYNTH in isolation. Which is probablty why WP:NOTSYNTH exists, and band-aid exhortations like "Because these [core content] policies work in harmony, they should not be interpreted in isolation from one another". Bon courage (talk) 02:27, 26 November 2025 (UTC)[reply]
If a major organization holds an official stance, it is okay to state that they hold that stance. Simply stating "_________ has stated that they believe Russia is not a real place" is fine. You could link the page for Climate change, but as long as we aren't using Wikivoice to endorse their stance or refute it, there isn't a contradiction. If a source later comes out and refutes the claim the organization made specifically, we could state "_________ has stated that they believe Russia is not a real place. _______ has described these views as "out of touch with reality"." We've seen this ALOT on the Martin Kulldorff page. Specifically, the text:
In December 2021, Kulldorff published an essay for the Brownstone Institute in which he argued against children receiving vaccination against COVID-19, falsely claiming that influenza was a greater risk to children than COVID-19. In a critical response published in Science-Based Medicine, Jonathan Howard noted errors and factual inaccuracies in Kulldorff's essay, pointing out that while influenza was responsible for only one child death in the 2020/21 season – while public health mitigation of COVID-19 was in place – COVID-19 killed more than 1,000. In addition to this, Kulldorff's essay omitted that children who are infected with COVID-19 are at risk for rare but serious conditions, such as MIS-C, with 8,862 confirmed cases of children with MIS-C by March 2023.
In December 2021 Kulldorff published an error-laden essay for the Brownstone Institute in which he falsely claimed that influenza was more hazardous to children than COVID-19, and on that basis illogically argued against children receiving COVID-19 vaccination. In reality, influenza had been responsible for one child death in the 2020/21 season, while public health mitigation of COVID-19 was in place – COVID-19 had, in contrast, killed more than 1,000. In addition to this, Kulldorff's essay omitted that children who are infected with COVID-19 are at risk for rare but serious conditions, such as MIS-C, with 8,862 confirmed cases of children with MIS-C by March of 2023.
The trouble is that stating fringe ideas (like why the Holocaust was a hoax, or how black people are less intelligent than white people, or how tylenol causes autism) and just waving them through without comment, is a violation of NPOV and NOR. Which is why it isn't done on Wikipedia, Similarly for the MAHA crew's many erroneous statements about human health, as with Kulldorff. However since for Kulldorff there is good sourcing that focuses on his errors, it is really irrelevant to the issue at hand here, which is about when corrective sources are not specific to the named topic of the article. Bon courage (talk) 02:42, 26 November 2025 (UTC)[reply]
I had to fight pretty hard to get that section to focus on the corrective source. Stating "___________ has stated they believe the holocaust is a hoax" could link the page Holocaust denial, which will likely do a fairly good job of contextualizing it. We don't have to avoid saying that a person or organization thinks wrong things, we just shouldn't endorse or refute them with Wikivoice. Excluding the wrong thing that a person or organization thinks is a form of Wikiturfing. Readers can conclude that the person or organization spouting Holocaust denialism is factually incorrect, but not stating they believe the thing might make them appear more reasonable. In Kulldorffs case, "In December 2021 Kulldorff published an error-laden essay for the Brownstone Institute in which he falsely claimed that influenza was more hazardous to children than COVID-19, and on that basis illogically argued against children receiving COVID-19 vaccination" was uncited, and therefore it was Wikivoice stating the essay was error-laden, making false claims, and employing illogical arguments. In the updated version, we rely on Jonathan Howard to assert that the claims were in fact false. GeogSage (⚔Chat?⚔) 03:29, 26 November 2025 (UTC)[reply]
Per NPOV, "The fringe or pseudoscientific view should be clearly described as such" (my underlne). Any editor removing such qualifications about Holocaust denial I would expect to be sanctioned for fringe POV-pushing. Again, Kuldorff is irrelevant to this case but it's good neutral writing to point out people's fringe proclivities in Wikivoice; that David Duke is a conspiracy theorist who promotes holocaust denial is not in doubt, and Wikipedia duly asserts it, to be neutral. Bon courage (talk) 03:50, 26 November 2025 (UTC)[reply]
Giving context in an article is not SYNTH, but simply part of writing an article. You shouldn't put the entire history of the England into the article of one of it's villages. But you could include a sentence to give context to it's founding if it's historically relevant. If it was founded in 1140 due to the devastation of several other villages, a sentence giving the context of The Anarchy would be appropriate and not SYNTH. -- LCU ActivelyDisinterested«@» °∆t°07:00, 26 November 2025 (UTC)[reply]
I don't see how this would not be synth. You are using sources unrelated to a topic to say things that no RS has ever said about the topic. PARAKANYAA (talk) 17:48, 27 November 2025 (UTC)[reply]
Generally, if no RS about the article topic says "X," Wikipedia shouldn't say "X." If no RS writing about the topic thought that "X" was necessary or helpful context to include for its readers, then "X" is unlikely to be necessary or helpful context, and Wikipedia editors who think that "X" is necessary or helpful context are almost certainly wrong. Wikilinks can be used to provide additional context to readers. This general rule should be open to case-by-case exceptions (WP:IAR), particularly for barely-notable topics where there are scant RS. But if 1,000 reliable books have been written about "Topic A" and none of them mention "Fact X," then the Wikipedia article about Topic A shouldn't mention Fact X, either. That's what WP:No Original Research is all about. This is a hallmark of "forward editing" ("here are three RSes about the topic, let's summarize what they say") vs. "backward editing" ("here's what the article should say, now let's find RS to support it"). Levivich (talk) 16:52, 30 November 2025 (UTC)[reply]
Climate Change as an article doesn't need the Reform UK's point of view on it. This is what the guidance about Fringe is all about. The Reform UK's article should have their point of view on Climate change on it (assuming it's a significant part of their platform, has drawn media coverage and discussion, etc), and GeogSage provides good guidance on how it should be done. Denaar (talk) 20:30, 30 November 2025 (UTC)[reply]
Agree with Anne drew, Parakanyaa, and Levivich. If an editor pulls from sources that don't even mention the article's subject, they're effectively deciding that they know better than the sources on what to include. Thebiguglyalien (talk) 🛸16:49, 1 December 2025 (UTC)[reply]
I disagree. The "subject of the article" isn't always the subject of the paragraph. If the subject of the Wikipedia article is a book, and the subject of the book is a false claim that HIV doesn't cause AIDS, then sources discussing HIV/AIDS are fine for placing the book's subject in context. You don't necessarily need a source that says "The exact book HIV is Harmless and Doesn't Cause AIDS by Ima Dummi is wrong to engage in HIV/AIDS denialism by saying that HIV is harmless and doesn't cause AIDS". You cannot present Wikipedia:Fringe theories without providing appropriate context. The appropriate context in that case is that HIV isn't harmless and actually does cause AIDS. If you can do that with a WP:PARITY source that mentions the book by name, then great! And if you can't, then do it with the best source for the statement that HIV denialism is scientifically stupid that you can get your hands on. If you need to call this "common sense and the occasional exception" to feel like it's justified by the rules, then do that. If you need to remember that Wikipedia:Ignore all rules is a policy equal to all others, then do that. But don't set up barriers to appropriate, encyclopedic, accurate content: Wikipedia:Wikipedia is not a game of Mother, May I?, and before writing appropriate, encyclopedic, accurate content, editors do not need to be endlessly asking "Policy, may I? May I really do what's right by the reader and the article?" WhatamIdoing (talk) 01:53, 2 December 2025 (UTC)[reply]
WP:NoDisclaimers - rationale, purpose and exceptions?
WP:Disclaimer highlighted instances of unacceptable disclaimers, and provided the following reasoning:
"All articles are already covered by the Wikipedia disclaimers [... and in every] Wikipedia page [there] includes, right at the bottom, a link to the [general disclaimer]"
"...Warnings are often redundant with the standard Wikipedia disclaimers. Were they to be permitted, they could create a false sense of security, by creating a misleading impression that all potentially problematic content is flagged, and therefore that articles without disclaimers are inherently "safe"."
Which... is like saying (1 "we're doing our bare minimum to fulfill our legal duties", and (2 "it's the users' responsibility to find and read the disclaimer, which is available as a hyperlink among the legal-fineprints at the bottom of the page". Which I find to be absurd. We designed our website in a way that visitors are unlikely to ever stumble across the disclaimer, ever, (I never did,) even in scenarios where it is important to show it to the reader - articles containing traumatizing and egregiously graphical depictions of violence, for example, the Japanese war crimes where IP users complained about being disturbed by the article.
I struggle to understand what we risk of losing by having a disclaimer upfront here. The aforequoted "to avoid the harm of giving a sense of security, we never warn about any harm" rationale might stand in some cases, but does it overweight the cons in all cases, when on the other side of the table sits a bunch of nightmare fuels?
To bypass the "false sense of safety" problem, how about this for a disclaimer: "This article contains graphical depictions of violence." A statement with less subjectivity. Or that we create an alternate Wikipedia header that puts the disclaimer link on the top of the page - and have the relative sections highlighted. (Jeez typing out this sentence made me feel like a corporate ars[censored]).
Saying "This article contains graphical depictions of violence." doesn't bypass the false sense of security for other articles where there is no such notice. If you read five articles which do have that notice, then Japanese war crimes which doesn't for whatever reason, it would be reasonable to assume there are no graphical depictions of violence in that article. You would need to make sure every article has a disclaimer covering all breaches of all cultural norms and maintain that full coverage at all times. ~2025-37040-20 (talk) 15:10, 28 November 2025 (UTC)[reply]
I think it's reasonable to debate the scope of "graphical depictions of violence", but I also think there's a line beyond which all contents are unambiguously graphical / violent by mere common sense. E.g., "We can't clearly define the boundary for underage exploitation materials, but some definitely is." 海盐沙冰 / aka irisChronomia / Talk11:28, 30 November 2025 (UTC)[reply]
You still have to decide where to draw that line, and you will get complaints from people who would draw the line in a different place. For example if was decided that the mousetrap example above was not a graphical depiction of violence (perhaps because the subject of the violence is not human) but the others were. Then you get complaints from a reader who is angry/upset/appalled/whatever that they (or their child or school class etc) were exposed to a display of what they regard graphic violence because there was no warning - especially when they found that something as (in their view) completely harmless and non-violent as a medical procedure was preceded by a warning. A reader with a different religious and/or cultural background, even in the same part of the same country, could very well take the exact opposite view about what is and is not "graphic violence" and would complain in exactly the same terms if a different decision had been made.
It's also worth point out here that graphic violence is easier to define than something like nudity (another commonly requested category). Thryduulf (talk) 11:58, 30 November 2025 (UTC)[reply]
But even then, so what? It's not like by ignoring the problem less people are going to get offended. And extending this all-or-nothing rationale vice versa ad absurdium, a person can reason that "Wikipedia never warns me about any offensive materials, therefore all of their contents are potentially dangerous to me".
Just because we can't put a landmine warning in front of every mine fields doesn't mean we don't place them anywhere at all. By not providing a false sense of security, we're instead providing a false sense of danger - that behind every wikilink may be a source of mental distress, and that it's better not to navigate the Wikipedia. 7:37p, edited 7:41p 海盐沙冰 / aka irisChronomia / Talk11:37, 30 November 2025 (UTC)[reply]
Wikipedia never warns me about any offensive materials, therefore all of their contents are potentially dangerous to me. This is correct, see the Wikipedia:Content disclaimer which starts with a big, all-caps heading stating Wikipedia contains content that might be objectionable. Thryduulf (talk) 12:02, 30 November 2025 (UTC)[reply]
I know. I know that this is legally good-enough as a disclaimer. But if we're really asking the users to take it literally, we will stop being such a popular site.
And shouldn't we apply this way of thinking to the "do add content warning" argument, too? That "we never promise that all content that may be objectionable would receive a warning, so don't expect we protect you from everything". 海盐沙冰 / aka irisChronomia / Talk12:39, 30 November 2025 (UTC)[reply]
Wikipedia became a popular site using this approach, so I don't understand the claim that this approach will suddenly make it unpopular. (Of course, I don't understand the mindset of someone who goes to an article on war crimes and is surprised that the information and images are upsetting either.) Schazjmd(talk)15:35, 30 November 2025 (UTC)[reply]
There are euphemistic styles to cover a topic, and we don't do that here. But we might want to point out this fact, up front, sometimes. It's unlikely that a new user would stumble across WP:Euphemism.
A lot of people laughes at a lot of people, indeed. People have expectations about Wikipedia, some of them wrong. It's just through what method we tell them they're wrong - upfront or by the harsher way. 海盐沙冰 / aka irisChronomia / Talk18:11, 30 November 2025 (UTC)[reply]
I think the bigger problem is that content warnings don't work. In some contexts (though perhaps not reading a website), a small number of readers are actually harmed by these content warnings (e.g., because they take the warning as evidence that the contents are so scary that they're not expected to be able to cope, and they live down to the expectations [idiom meaning: they behave worse than ordinary, because they think we expect or want them to behave poorly]). Also, banner blindness is a thing. WhatamIdoing (talk) 02:28, 2 December 2025 (UTC)[reply]
I understand.
I'd say we should try to do something about these articles; we're kind of at analysis paralysis here because we deem all solutions so far not good enough.
After the discussions, I'm thinking about "Showing new viewers (since we have temporary account and cookie now) a pop-up with a TLDR for Wikipedia's content policy" instead. And we include "WP is not censored" there. 海盐沙冰 / aka irisChronomia / Talk09:18, 2 December 2025 (UTC)[reply]
We shoudl try to do something see the politician's syllogism, just because some people (and in this discussion that's basically only you) think there is a need to do something that doesn't mean that every possible something is a good idea. Specifically regarding popups, the more popups you show people the less likely they are to read them. The longer the popups you show people the less likely they are to read them. Thryduulf (talk) 14:09, 2 December 2025 (UTC)[reply]
The solution here is to write image captions that accurately describe the images, then concerned users can use one of the options here to selectively view only the images they want to see. -- LWGtalk14:26, 2 December 2025 (UTC)[reply]
Thanks, that seems much more nuanced than a pop-up.
But just one last question, should we put a small option to hide images at the top of the page instead of having the reader to go to settings themselves?
But in any case, I see the point now. Thank you all for the comments. :)
I think it's probably fine to let the few people who want this feature find it and set it up themselves rather than clutter up the interface for everyone. -- LWGtalk06:18, 5 December 2025 (UTC)[reply]
I have a few suggested changes to discuss before implementing them on the global rights policy:
Should we add images of global user groups within their respective sections? Some sections can be excluded if they do not have their own user global user group image such as staff, system administrators, ombuds, etc. The Chinese Wikipedia's global rights policy had done this before.
Should we add a short introduction for some of the global user groups (of what they are and what they do)? One example is located below.
For global user groups that are allowed to view temporary account IP addresses globally, should we add a new sentence provided they comply with the WMF's policy? It would be: In addition, [global user group members] can view temporary account IP addresses and use the IP Information tool, provided they comply with the Wikimedia Foundation's Access to Temporary Account IP Addresses Policy.
I propose that we add a section for abuse filter maintainers:
Abuse filter maintainers are users who are permitted to view, and where appropriate, modify edit filters on all wikis. By default, they may use their rights on the English Wikipedia, provided they have not previously had the administrator or edit filter manager right removed involuntarily, other than procedurally for inactivity. If such a removal has previously occurred, they must request and be granted administrator and/or edit filter manager access locally prior to using this access. Furthermore, any English Wikipedia administrator can ask an abuse filter maintainer to stop using their global privilege if what they deem to be misuse occurs, and the abuse filter maintainer must comply with such a request. Such a decision by an administrator can be appealed to the wider community.
On the English Wikipedia, abuse filter maintainers can only perform non-controversial maintenance to edit filters, such as making changes to prevent a filter from breaking due to upcoming changes to the AbuseFilter extension itself. Notes should be left in the filter description explaining why the change was needed, and listing the relevant Phabricator tasks if applicable. It is recommended that abuse filter maintainers should inform the edit filter noticeboard before or after making changes to filters.
In addition, abuse filter maintainers can view temporary account IP addresses and use the IP Information tool, provided they comply with the Wikimedia Foundation's Access to Temporary Account IP Addresses Policy.
All of these changes sound sensible. The images would be especially helpful for folks from other projects who may not know the English terminology to identify the sections they're looking for. Toadspike[Talk]09:34, 28 November 2025 (UTC)[reply]
I do not know who came up with it or why but suddenly we have a billion new users on every even slightly contentious page, all of whom have no history but who have very clearly edited *very* extensively in the past, making disruptive changes with absolutely no means of controlling it because we've just given them a billion fake IDs Snokalok (talk) 13:13, 3 December 2025 (UTC)[reply]
Hot take: the giant, scary “YOUR IP WILL BE VISIBLE” sign was actually a really great deterrent against the NOTHERE. Now that’s gone, they have a different account for each device they’re on, and if they want another one, just clear cookies. Snokalok (talk) 13:29, 3 December 2025 (UTC)[reply]
I tend to agree that this change has supercharged contentious editing, and made it exponentially more difficult for the average editor to identify individual abuses of multiple local IP addresses. BD2412T13:40, 3 December 2025 (UTC)[reply]
Honestly even allowing IPs imo was a deep and costly compromise between wikipedia’s ideals and the practical reality of keeping the project nice. Temp accounts just surrender the project entirely to chaos. Snokalok (talk) 16:27, 3 December 2025 (UTC)[reply]
I don't really understand the need to allow IP editors or temp accounts at all. Maybe early in the project, but accounts are already pseudo-anonymous, free, and easy to create. Reddit, Facebook, and other Websites that depend on user generated content tend to require an account to participate, I don't see why Wikipedia doesn't. My experience has mostly been real editors using them as sock puppets or disruptive edits that are either intentional vandalism or clueless. GeogSage (⚔Chat?⚔) 18:34, 3 December 2025 (UTC)[reply]
It’s an idealism thing. Wikipedia doesn’t formally swear by any political ideology, but if one was to assign a label to its ideals, its principals would very swiftly fit the model of anarcho-communism. And that means, among other things, that everyone has a voice and everyone can contribute and decide on content.
Obviously in practice it just ends up being the equivalent of the articles of confederation, where there’s not enough centralized authority or etc, but the ideal built wikipedia in the first place - and it wouldn’t be a small thing to go back on that.
But even so, I think the temp accounts have just emboldened disruptive editors that were previously deterred by having their IP be public. Snokalok (talk) 22:22, 3 December 2025 (UTC)[reply]
And the temp accounts also have emboldened constructive editors that were previously deterred by having their IP be public. Most unregistered users are not vandals. SuperPianoMan9167 (talk) 22:47, 3 December 2025 (UTC)[reply]
I’ve sort of noticed, as the project gets older, generational divides form amongst editors. Like on GENSEX topics, most of the editors who really strongly push anti-trans povs are those who joined in like the mid-2000s - proper old guard; while those who push the other way are usually those who joined in the 2010s. The 2020s so far have been an even split. Snokalok (talk) 00:04, 4 December 2025 (UTC)[reply]
How true is a statement like the biggest problem is our stagnant editor base? It's unclear without seeing the statistical evidence, but for the Arab-Israel conflict contentious topic area it does not appear to be the case. We looked at related issues as part of the ARBPIA5 case. At least in that topic area it is possible to say that, while the unique actor count is pretty steady (Meme check #1), younger accounts appear to play an important role (Meme check #2). So, I'm guessing that if there is some form of stagnancy, it is likely quite heterogeneously distributed across the project. Sean.hoyland (talk) 10:42, 4 December 2025 (UTC)[reply]
The idea an IP address was a privacy nightmare is hard to parse. All it establishes is a general area of some kind of user at that time. However having the easy ability to check an IP made it extremely easy for the average experienced user to find out if this is the same person causing more issues via a slightly different location.
@Rambling Rambler, back in the 1990s, if you looked up my IP address, WHOIS would give you my exact home address. I think "a privacy nightmare" is a fair description of that setup. While most ordinary people, editing from their homes or phones, are not going to be in that situation, there still are people for whom the IP address is identifying, and millions more for whom a permanently recorded IP address is one short subpoena to an ISP away from being the next Asian News International v. Wikimedia Foundation case. WhatamIdoing (talk) 21:48, 3 December 2025 (UTC)[reply]
It is unlikely IPs would be doing edits that are controversial enough to get sued. The constructive IPs are mostly doing basic fixes and fighting vandalism themselves. Anything more than that and the IP would be incentivized to create an account to get credit for their work. Mikeycdiamond (talk) 12:04, 4 December 2025 (UTC)[reply]
On 4 August 2025, the Wikimedia Foundation announced compliance with local Portuguese court orders and subsequently removed content from the Wikipedia articles related to DePaço on both the English and Portuguese Wikipedia projects. Additionally, the IP and email addresses of eight involved Wikipedia editors were disclosed to DePaço, who stated that he would pursue further legal action against the editors.
Only if all eight of those users had used temporary accounts rather than registered accounts, and the temporary accounts were old enough. Anomie⚔13:32, 4 December 2025 (UTC)[reply]
I realize that now. I had assumed that IP editors were involved. I was largely incorrect in my conclusion.
The point is that it's weirdly inconsistent to treat IP addresses as sensitive personal data when they belong to registered accounts but simultaneously say that they aren't sensitive at all when they belong to unregistered users. SuperPianoMan9167 (talk) 19:37, 4 December 2025 (UTC)[reply]
I've requested too. But I agree with User:Snokalok's original assertion that the whole temp account thing seems like not a very good idea. Was there ever an RfC or some equivalent on this topic? NickCT (talk) 17:04, 3 December 2025 (UTC)[reply]
No, it was forced on us by the WMF. Possibly due to Legal, GDPR etc. etc. This is not a great solution at all and hopefully tools will improve or TAIV be granted more liberally.~212.70~ ~2025-31733-18 (talk) 17:30, 3 December 2025 (UTC)[reply]
I'm a bit confused by the acrimony against the change, given that TAIV exists. Is the new issue just that new editors without TAIV are filing shot-in-the-dark reports against TAs that need further legwork by admins/TAIVs to respond to? signed, Rosguilltalk18:01, 3 December 2025 (UTC)[reply]
For me the issue is that it creates an enormous overhead for normal anti-vandal/anti-abuse work. To be thorough one has to check the history of the editor, so instead of looking at the single IP contribs page, or a /64 for an IPv6, I have to open the temp account contribs, the IP temp account contribs, and the IP legacy edits. This is already suboptimal on a desktop and adds to the time it takes to investigate, but when editing from a phone it's downright horrible. There are ~12,000 blocks a month, the overwhelming majority of them from AIV/TB2. Adding additional time to processing the reports from those noticeboards eats up a huge amount of limited volunteer time. Add to that the large number of vandals that I've seen making a couple edits and either deleting their cookies or opening a new incognito window to grab a new TA with a blank user page which abuses the escalating warnings before blocking method we use and it's a pretty significant headache. ScottishFinnishRadish (talk) 18:11, 3 December 2025 (UTC)[reply]
But doing anything from a phone that involves a keyboard is downright horrible, especially with my fat fingers. At least the IP legacy edits will reduce in importance with time. Phil Bridger (talk) 21:16, 3 December 2025 (UTC)[reply]
I primarily edit from my phone, so the extra steps are a significant issue. We also need to get hip to (that's what the kids say, right?) the fact that most people access the internet with mobile devices. Making a shitty system even shittier for mobile editors isn't helping us. ScottishFinnishRadish (talk) 22:14, 3 December 2025 (UTC)[reply]
Why not write a user script that acts as a better autoblock for TAs (since a regular autoblock is fixed to 24 hours)?
Here's what I'm thinking of:
When blocking a TA, a mobile-friendly dialog comes up that says "Block the TA's IP?"
If it is checked, once the block is placed, the script would perform a normal IP block (anon. only, account creation blocked) on the TA's IP, with the same block duration as the original block, but with a vaguer, generic block summary, such as "abuse from TAs on this range". The only exception would be that an indefinite TA block would result in a 90-day IP address block.
This acts essentially like regular autoblock: the abuser has to change both their IP address and their TA to evade a block. The only differences are that it lasts for longer than 24 hours and that it only applies to one IP address or range. It wouldn't work against proxy abusers but IP blocks don't work on proxy abusers anyway.
It also saves having to open a new tab to block the underlying IP and thus reduces tediousness by automating the IP block. Yes, this exposes a TA's IP address automatically, but that's allowed by policy: admins are allowed to make blocks that, by their timing, imply a connection between an account and an IP. The block summary for the IP is made vague to avoid violating the IP disclosure policy.
Of course, any IPv6 block would automatically extend to cover the /64.
Maybe a template similar to {{CheckUser block}} could be used in the edit summary--{{TAIV block}} might work.
Why is it necessary to check the IP every time? Why not just block the TA? My idea is that an admin would block the IP for the same duration as the TA block using this tool for every single TA block, eliminating the need to check the IP at all. I think non-admin TAIVs doing the TA tracking work instead of admins would work out better.SuperPianoMan9167 (talk) 00:15, 4 December 2025 (UTC)[reply]
Because very often there are multiple TAs on the address, and without looking at the history, including legacy IP edits, you won't know the appropriate length for the block. ScottishFinnishRadish (talk) 00:22, 4 December 2025 (UTC)[reply]
Then what would be a good idea to reduce this tediousness and prevent disruption besides "require registration" or "ditch temporary accounts", as the WMF has shown no signs of entertaining either idea? SuperPianoMan9167 (talk) 00:28, 4 December 2025 (UTC)[reply]
I don't believe the WMF really has a say on if we require an account to edit. Portuguese Wikipedia requires an account. As for alternatives, hash IP addresses instead of using temporary accounts. Permanently assign IP addresses account names as they edit. There's a lot of ways to hide IP addresses that doesn't create a huge burden on editors and admins. ScottishFinnishRadish (talk) 00:35, 4 December 2025 (UTC)[reply]
Hashing won't work. IP addresses are fixed identifiers. Given enough large enough data set of hashed up addresses and the corresponding IP addresses, one can either reverse the hash or build a rainbow table connecting the two. – robertsky (talk) 05:24, 4 December 2025 (UTC)[reply]
Seems more secure than the TAIV permission which any potential malicious bad actor could circumvent with time.
With temporary accounts, all IP information is discarded after 90 days, and the temporary account's name still remains as an identifier. If we used IP hashes to identify unregistered editors, we'd be keeping that (obscured) IP information forever within the identifier. jlwoodwa (talk) 02:16, 5 December 2025 (UTC)[reply]
@Rosguill according to the policy around using TAIV every use of it is logged. Previously as a lay user I could simply check the IP, look for recent activity from that same address, and if questionable take it to AIV/SPI.
Now however if I were to acquire the tool and examine TAs and I'm wrong, it feels like I'd have a cloud over me because that record could be questioned at any point by a CheckUser.
That makes sense, although personally I think that absent guidance mandating specific limitations on TAIV use, "any mildly suspicious edit or edit made in the vicinity of such edits" should be considered fair game good faith use of the tool. signed, Rosguilltalk19:00, 3 December 2025 (UTC)[reply]
@Rosguill but then that needs to be either guideline or preferably policy, that there's a very strong presumption of innocence in usage and it's for those believing it to be misused to have to demonstrate clear malicious usage.
Nobody cares how often you look at the IP address. Look at every single one of them, all day long, if that floats your boat.
It's logged so that if an "anonymous" social media account posts "Hey, world, just creating a permanent record so we'll always know that ~2025-12345-67 is IP 192.0.2.0, and ~2025-23456-78 is 198.51.100.255 and...", then they can figure out who looked at those and, um, provide you with an opportunity to stop doing that. WhatamIdoing (talk) 21:57, 3 December 2025 (UTC)[reply]
@Rambling Rambler, please don't worry too much about this when you're reporting to SPI. We know everyone's still getting used to it, and it's very easy for us to revdel any accidental disclosures. I assure you that clerks won't get too mad about it (they've seen worse) and CUs have way better things to do with our time than chase down someone who revealed an IP for no reason other than because they got curious. -- asilvering (talk) 05:01, 5 December 2025 (UTC)[reply]
One issue is that its a rfp, all the language around this makes me really scared that if I mess up or misinterpret a policy, i could get blocked. Plus, the policy is hosted on a wmf domain, so I cant even read it bc my school blocks all wmf domains. MetalBreaksAndBends (talk) 15:49, 5 December 2025 (UTC)[reply]
@Toadspike I'm aware of that tool existing. However I have been reticent to apply for it because it seems there's just a massive amount of policy bear traps created around both using it and then how you refer to it once you've used it that feels like I'm the one who'd be under more scrutiny for examining a TA than the actual TA.
Also the fact we have that tool just feels like a giant admittance by WMF that TA are basically pointless, because if we're allowed to view IP with extra steps then it's not really dealing with any of the "fear of Wikipedians safety" that WMF claimed was the justification for the change. Rambling Rambler (talk) 18:51, 3 December 2025 (UTC)[reply]
Personally, I've decided not to click the button to enable TAIV for myself because I have no interest in working out what the CheckUser-lite policies around it allow and don't allow. Easier to leave it to admins who are into that sort of thing. Anomie⚔23:37, 3 December 2025 (UTC)[reply]
For what it’s worth, the interface itself drives temp users towards churning and burning accounts if they don’t want to create an account. There’s a giant grey “you need to log in, this is a temp account” banner on the top of every single page that only disappears when you “exit session”. The result is that browsing while “logged into” a temp account is more annoying than creating the account and immediately throwing it away. I went from having one IP account to creating one for each comment I make. Including this one, haha. ~2025-38292-55 (talk) 19:07, 3 December 2025 (UTC)[reply]
As I mentioned elswhere, the temporary account implimention will proove to be a disaster. This idea should've gotten community imput, as to whether or not to implement. GoodDay (talk) 18:09, 3 December 2025 (UTC)[reply]
It's one of the worst technical misfires the WMF has ever made and they're justifying it, as Fram and Aaron Liu wrote about here, on an incompent misreading of editing statistics at the Portuguese Wikipedia before and after they switched off anonymous editing. Everyone involved with the decision needs to grow up and accept that the days in which it was appropriate for unregistered users to edit the project are long gone. — Hex•talk19:42, 3 December 2025 (UTC)[reply]
Agree, it's a complete mess. Masking IP addresses was absolutely necessary, but this particular implementation is a disaster. It's hard on unregistered users (their contribution history is scattered to the wind even if their IP is static, and their apparent username changes constantly so they're constantly accused of sockpuppetry), it's a disaster for registered users (instead of interacting with one IP address or a few that displayed obvious patterns, now we have to try to converse with what is no more legible than a QR code), it's a pain in the ass for enforcement (if your TA is blocked you can easily just make a new one, far easier than changing your IP), and let me tell you it's absolute horseshit for checkuser (private checkuser reasons). If this is the best solution the devs can come up with, it would solve the problem much more reliably to just disable logged-out editing and force all editors to create an account; registered accounts are already very well protected by privacy policies and have been for a very long time. Ivanvector (Talk/Edits) 19:44, 3 December 2025 (UTC)[reply]
One would hope that this mess would push the WMF towards what has for a long time been the only obvious solution, which is mandatory registration; however, since in the past the disruption of workflows for editors and admins has been something that the WMF clearly couldn't give a shit about, I doubt if this is going away any time soon. Black Kite (talk)19:59, 3 December 2025 (UTC)[reply]
I'm sure I'll get roasted for this, but when was the last time anyone here was able to submit any content of any sort to any website, besides Wikipedia, without creating an account first? Ivanvector (Talk/Edits) 20:55, 3 December 2025 (UTC)[reply]
The last place I saw using non-account registration outside Wikipedia was the Gawker network of sites.
Funnily enough it led to an endless wave of harassment via spamming gore and torture images that meant they basically hide most of their comments away unless you were given "trusted" status. Of course vandals there just immediately got trusted status on one account and then just used it to make their vandalism content visible. Rambling Rambler (talk) 22:09, 3 December 2025 (UTC)[reply]
Nearly all of them accept fake phone numbers and fake e-mail addresses, though occasionally I'll run across one that will reject an @mailinator.com address. Almost none of them actually verify that the e-mail address is functional. But giving them a way to contact me isn't the same as creating an account. WhatamIdoing (talk) 01:19, 5 December 2025 (UTC)[reply]
It is the same. They are linking your comment to a specific ID, in that case an email address. Whether that email address is functional is irrelevant to this, usernames never have email functionality. (They are probably also creating a profile through other data, which we do not.) CMD (talk) 03:04, 5 December 2025 (UTC)[reply]
Well indeed, a full account creates an additional layer of privacy. Outside of GDPR territories, I expect most companies devote much less attention to this than we do. CMD (talk) 03:43, 5 December 2025 (UTC)[reply]
There's some forums I have heard of (econ job market rumors - which has led to a culture of bigotry) but you're right that it's not common. Katzrockso (talk) 08:40, 4 December 2025 (UTC)[reply]
I have frequently been critical of the WMF, but I find it difficult to find fault with them in this case. Politically they had to do something about exposing IP addresses to anyone who cares to look. The only choices were to have something like the current temporary account procedure or to require registration. Phil Bridger (talk) 21:23, 3 December 2025 (UTC)[reply]
I've been saying this for years. In 2001, creating an account might have been a barrier to entry and it made sense to allow instant editing as we sought to rapidly expand the editor base. But these days the public expects this, there aren't many sites out there that don't require you to open an account. IP addresses were bad because of privacy and also easy socking if you IP hop, but temp accounts are even worse. It's now perfectly legitimate and very easy to edit under a new handle every day. Let's move to requiring log in please. — Amakuru (talk) 23:48, 3 December 2025 (UTC)[reply]
Unfortunately I think the problem is that it's no longer the internet of even the early 2000s where it required some base level of skill and Wikipedia was still unknown.
The original WikiWikiWeb was an agile tool for a community of practice - created in 1995, long before agile software development - where many of the participants knew each other, and frictionless contribution without a need to register was beneficial and unproblematic. For a long time, anyway (I was there). This project's explosive growth took it beyond that in a very short time, but the people who operate it are libertarian technocrats, and libertarian technocrats suffer from the mindset where the answer to a social (behavioral) problem is always "we can code our way out of it". Instead of what actually works, which is rules that are effectively enforced. An example of such a rule is "editing requires an account", which is enforceable with zero additional software. Back on the WikiWikiWeb we had a maxim for things like this: do the simplest thing that could possibly work. — Hex•talk16:11, 4 December 2025 (UTC)[reply]
Instead we'll die by having pitiful mobile support preventing the majority of internet users from contributing while simultaneously increasing the workload on a declining admin corps through poor implementation of hiding IP addresses. For the same technical effort we could have had not the worst possible mobile experience for editors, added an account requirement, and grown the user base. ScottishFinnishRadish (talk) 00:09, 4 December 2025 (UTC)[reply]
That creates even more work and allows more disruption. The additional work isn't just for admins either, it's for anyone who has to deal with the disruption. It also increases the chances that vandalism and other disruption doesn't get reverted. ScottishFinnishRadish (talk) 00:18, 4 December 2025 (UTC)[reply]
It sounds like every time you get a vandalism report for a temp account, you check Special:Contributions for the temp account (easy), past contribs for the IP, and for any other temp accounts using that IP.
Your goal is to block them all (if needed) and to revert any problematic edits by any/all of them, instead of just blocking the individual identified problem.
I think it should be possible to create a streamlined tool for CUs and Stewards that automatically pulls up contribs for all of these (@Vermont, does that sound plausible to you, or am I obviously wrong?). But I'd guess that it would first be built by a volunteer who designed it for desktop use, which wouldn't really help you when you're working from a smartphone. WhatamIdoing (talk) 01:32, 5 December 2025 (UTC)[reply]
SFR, I have a lot of sympathy for you, but "for the same technical effort" isn't true. A good mobile interface is difficult, especially since what's needed isn't just core MediaWiki features but also the add-on tools that were built by volunteers for use on large screens.
I don't want either of those things, @WhatamIdoing, no. But I think this implementation of temporary accounts might cause even worse damage by limiting our ability to deal with disruption, so I see mandatory registration as the lesser evil.—S MarshallT/C00:25, 4 December 2025 (UTC)[reply]
But how would the identifier stay static? Would it be tied to an IP address? If so, that would reintroduce confusion about multiple people on the same IP address (which I think is one of the largest benefits from temporary accounts being tied to a browser cookie, even if that does create other problems). The WMF admits that TAs are not intended to solve any anti-abuse problems and mentions device fingerprinting as one of three solutions:
Can't an abuser just clear cookies? Yes, they can. Temporary accounts are not intended to solve any anti-abuse problems.
We know the problem of abusers making edits through a pool of changing IPs while masking browser agent data. This cannot be solved through temporary accounts. This is not a design goal for this project either. Otherwise, we would need to use trusted tokens, disabling anonymous edits, or fingerprinting, all of which are very involved, complicated measures that have significant community and technical considerations.
We have adapted tools to ensure that trusted functionaries can safely and efficiently navigate the bidirectional mappings between temporary accounts within the last 90 days and IPs. However, abuse from a user who clears cookies may become difficult or impossible to detect and mitigate for users without advanced permissions, or if some of the edits involved are more than 90 days old.
I don't care how many people are using a single IP, I care about the behavior from that IP. There's no problem there to be solved. As for the anti-abuse issue, it actively makes it worse and costs an enormous amount of additional time. ScottishFinnishRadish (talk) 00:58, 4 December 2025 (UTC)[reply]
I am of the mindset that you should not have to pick a username that: is unique and not used by any other user; represents you as an individual person; does not include your real name if you are a minor; does not only contain the names of companies, organizations, websites, musical groups or bands, teams, clubs, creative groups, or organized events; does not only describe a particular role, title, position, department, or a group or team of people within a parent organization or group that can be represented or held by multiple people or by different people; is not promotional in nature, and does not appear intended to advertise, promote, sell, gain support, or increase the attention or user-base audience of any person, company, market, product, channel, website, or other good or service; does not imply that your user account will be shared between more than one person; is not offensive, profane, violent, threatening, sexually explicit, or disruptive, and does not advocate or encourage any such behavior (including criminal or illegal acts); does not contain statements that are libelous, contentious, or disparaging, or that disclose any private or non-public information about somebody else (either another editor, or a notable living person); is not deliberately deceptive, confusing, misleading, unnecessarily long, too similar to the username of other accounts, or an attempt to impersonate or falsely represent somebody else (another editor, a notable living person, an "official" Wikimedia Foundation account, etc.) in bad faith; does not imply that the account has explicit ownership of any articles, content, or topic areas, or any kind of "power" or "authority" over other editors, a different application of Wikipedia's policies and guidelines (such as implying that certain policies do not apply to them), or that the account has any administrative or "moderator" access levels or user rights; does not imply the intent to troll, vandalize, disrupt, advertise on, or spam Wikipedia; does not imply the intent to personally attack, harass, or threaten other Wikipedia users; and does imply that you are not here to build an encyclopedia or will use Wikipedia for purposes that it was not created for, just to fix one small typo on a page.
(The point is that you shouldn't have to read any policies or guidelines before contributing to Wikipedia. Requiring registration basically requires any prospective contributor to read the lengthy username policy (of which I have included only the summary) before contributing at all, or else they may be immediately blocked without any chance to contribute due to a bad username. And that doesn't even include choosing "a unique password that you are not using on any other website".) SuperPianoMan9167 (talk) 02:30, 4 December 2025 (UTC)[reply]
If picking a username is such a big hurdle, then there could be an option to register under an randomly generated username, like the current TA system. Of course, this would add a lot of burden to WP:CHU but if TAs are such a big problem as some claim, it could be the lesser evil. novovtalkedits08:07, 4 December 2025 (UTC)[reply]
You could do something similar to the temp account style, though without the ~2025 at the start (we blocked all creation of usernames beginning that way a couple of years ago, the minute the team decided to prefix the temp accounts with the year of creation). I'd suggest finding a Correct horse battery staple generator instead of doing numbers, though if you do a lot of multilingual or cross-wiki editing, numbers are almost universally readable across most scripts.
If the understanding the numbering scheme would help anyone, it's this: ~YYYY-12345-67: It starts with the year, so when you look at an edit, you'll be able to know if that account is long dead. There are seven digits right now because that's approximately the number we expect to need this year (though it can expand more or less infinitely: ~YYYY-12345-67890-12345-678, etc.). It's in groups of five, because groups of four look like credit card numbers, and groups of six look like SMS account verification codes (which I find difficult to read without my glasses on). WhatamIdoing (talk) 08:33, 4 December 2025 (UTC)[reply]
The problem with Correct horse battery staple is ensuring that none of the randomly generated usernames are offensive or derogatory in any culture or when translated to any language. I went through this issue with WP:IRC help disclaimer, where even with the small number of rotating options, I had several complaints about people objecting to being called a dog, or a gorilla, or a cow, or a whale, or black. I had complaints about leaving white, red and yellow in the rotation too, although I ultimately ignored those. --Ahecht (TALK PAGE)14:55, 4 December 2025 (UTC)[reply]
Variants of that problem have been solved over and over again by different organizations, and there's no reason why the WMF couldn't open its creaking coffers to specifically pay people to do it again. Also, this is the English Wikipedia. Eliminating words that accidentally come across as rude in "any language" is out of scope as well as impractical. — Hex•talk15:40, 4 December 2025 (UTC)[reply]
Perhaps we should more obviously advertise that usernames can be changed later. On some websites they can't, so it isn't a default expectation. CMD (talk) 05:35, 5 December 2025 (UTC)[reply]
The very least that should be done is to remove the 'ditch this account and dodge all blocks and warnings' button that has been inexplicably included in the drop down menu of user options for all TAs. CMD (talk) 02:52, 4 December 2025 (UTC)[reply]
My guess is that there's a legal issue behind that, though it could be pressure from the Growth team to try to push temp accounts into registering. But perhaps it could be made less irritating. WhatamIdoing (talk) 07:43, 4 December 2025 (UTC)[reply]
A couple of years ago, I asked editors at one of the Village pumps whether they had contributed as an IP. It was about half and half. Less anecdotally, the logs show a lot of editors first making their first edit as an IP, and then creating an account. Perhaps a "Wow, that worked – I want to do more of it" effect? WhatamIdoing (talk) 01:38, 5 December 2025 (UTC)[reply]
We could have the edit button redirect to the login page. The constructive people will make an account, and then we could redirect them again back to the edit page. Most people will understand an account requirement, especially for a project as important as Wikipedia -- possibly increasing our credibility with our critics. An account requirement could serve as a filter for the constructive and unconstructive editors; it wouldn't get rid of them completely, but not as many people would vandalize Wikipedia if it wasn't as easy. The people who refuse to make an account are an extremely small minority. Why should we waste the time of and alienate our current editors when the alternative is creating an extremely small barrier of entry that could filter out some of the unconstructive editors? Mikeycdiamond (talk) 02:26, 5 December 2025 (UTC)[reply]
Unconstructive editors will just as easily make an account and vandalize if they are really intent on disrupting Wikipedia. Those who want to vandalize could easily take the extra 20 seconds to register. SuperPianoMan9167 (talk) 02:33, 5 December 2025 (UTC)[reply]
Like I said, it wouldn't filter all of them. A large amount of vandalism that I've seen is idiotic stuff that was most likely made by a bored teenager/preteen. If we place a barrier, any barrier, we would remove the fun from vandalism. This could cut out a large percentage of vandalism, which would save hours of editor time. Mikeycdiamond (talk) 02:39, 5 December 2025 (UTC)[reply]
The constructive people will make an account Not necessarily. There are plenty of sites where, when they've given me a "you must sign up to continue", I say "maybe later" and go elsewhere. Anomie⚔02:46, 5 December 2025 (UTC)[reply]
It's awful and was an awful idea from its inception. I understand the reason for it and the solution has always been requiring someone to create a free account. Just like literally every website in the past two decades. Requiring someone to make an account does not change the "encyclopedia anyone can edit" mantra in the slightest. SilverserenC01:05, 4 December 2025 (UTC)[reply]
You can find 18 people who disagree with anything. My humble opinion is that a lot of the (former) IP editors were making a big deal of not registering because they liked being a rebel. If they had to register, they would have and would have quickly have got over their "I'm different" glow. Johnuniq (talk) 05:13, 4 December 2025 (UTC)[reply]
I talked to one a few years ago who said that he used a lot of different devices, so staying logged in to anything was a hassle. I don't think it was an oppositional motivation; I think he was just doing a rational cost/benefit analysis: If it's easy enough to report the bug, he'd do so; if it wasn't, then he wouldn't bother. WhatamIdoing (talk) 07:47, 4 December 2025 (UTC)[reply]
I edit across three devices, -- two autologs, one non-autolog -- it isn't that big of a deal. If you enable autolog, you don't even have to login each time. Mikeycdiamond (talk) 19:19, 4 December 2025 (UTC)[reply]
How out of the way is spending 10 seconds logging in? If you didn't want to do it every time, you could spend the 1 extra second to click the remember this device button. Mikeycdiamond (talk) 02:13, 5 December 2025 (UTC)[reply]
Anyone want to start a community-wide RfC about this? I believe the WMF will have the final say on whether to disable temporary account editing on the English Wikipedia (and I highly doubt they'll get rid of temp accounts), but it'll still be interesting to see what percentage of the community actually supports requiring an account to edit. I might be in the minority (or majority, who knows), but I don't think temporary accounts are a stupid idea at all. Some1 (talk) 02:18, 4 December 2025 (UTC)[reply]
Also, I agree with you about temporary accounts. They have flaws, but implementing them is better than requiring registration IMO as registration creates barriers to good-faith contributors who don't want to or can't make an account. For example, a significant barrier in creating an account (the same one which kept me from having an account for about four months, in fact) is picking a unique, fully username policy-compliant username. SuperPianoMan9167 (talk) 02:42, 4 December 2025 (UTC)[reply]
I think this is a mountain out of a molehill. The username policy is very common sense, and any mistake someone does make can be very quickly rectified with a rename request or just making a new account moments later. I put exactly 0 thought into my username when making my account. Athanelar (talk) 14:38, 4 December 2025 (UTC)[reply]
Yes, but I think many new users (myself included, when I made my account) get anxious about picking a username when they see Your username is public and cannot be made private later. They might read this as prohibiting username changes and/or not allowing for mistakes, when of course neither of those things is actually true. SuperPianoMan9167 (talk) 17:14, 4 December 2025 (UTC)[reply]
Here's more of my opinions: I think ~2025-12345-67 is easier to understand and remember than 2601:402:680:1270:35FA:C71F:B07D:944 (this was one of my IP addresses). If an IP user was on IPv6, there'd be no guarantee that you'd even be able to communicate with them as their "username" changed so frequently. You'd have to hope that you got the most recently used address in the /64. SuperPianoMan9167 (talk) 02:51, 4 December 2025 (UTC)[reply]
Yeah I don't understand the complaints that temporary accounts change frequently -- that was already a huge problem, every IPv6 account was functionally a burner. Gnomingstuff (talk) 03:19, 4 December 2025 (UTC)[reply]
Yup. Temp accounts only change if you clear cookies or don't use cookies. IPv6 addresses change daily and there's basically no way to stop it other than switching to a static IPv4. (Unrelated: I went ahead and made WP:LLM an information page instead of an essay. Do you think that was a good idea?) SuperPianoMan9167 (talk) 03:23, 4 December 2025 (UTC)[reply]
The difference between an IPv6 edit and a TA edit is that it is trivial to add /64 to the IPv6 and see if any related IPs are active. Adding /64 doesn't require a formal opt-in or a promise (punishable by banishment) to be good. Many people without any privilege (including IPs) have reported an IP range for vandalism—that saves time. Johnuniq (talk) 06:23, 4 December 2025 (UTC)[reply]
Trivial for users who know how IP address ranges work and who know that a /64 subnet usually represents a single household. Many users that are less technologically inclined don't know either of those things and got super confused trying to follow around an IPv6 user. SuperPianoMan9167 (talk) 17:17, 4 December 2025 (UTC)[reply]
Disabling temporary accounts and requiring registration to edit are different. Even if we adopt the pt.wiki precedent of requiring registration to edit articles, TAs will still be used to edit talkpages. CMD (talk) 02:55, 4 December 2025 (UTC)[reply]
Description from the file: This graph shows a decline in new registered users from about 160K in 2018 to about 80K in 2025. Yep. And to add to my comment above, I would oppose requiring registration to edit the English Wikipedia mainspace (or any other namespaces, for that matter). From what I've seen on this site, there are more constructive unregistered editors than there are unconstructive ones. Not to mention, Wikipedia is already facing a "drastic" decline in account creation since 2020.[7] IMHO, requiring registration to edit (which includes banning temporary accounts or unregistered users from editing the mainspace) will just accelerate the decline of this project. Some1 (talk) 04:39, 4 December 2025 (UTC)[reply]
Another way for decline to accelerate would be to have content creators swamped with rubbish from throw-away temporary accounts. Johnuniq (talk) 06:26, 4 December 2025 (UTC)[reply]
Is there evidence of that happening? I see the complaint that admins who focus on blocking vandals need some more efficient (and mobile-friendly) tools, but how would a "throw-away temporary account" be any worse for a content creator than someone using a VPN or even just posting one comment at home, one on the school bus, one from school, another on the school bus home, etc.?
A couple of years ago, I checked what mobile editing might be like in my neighborhood. I can go for a five-minute walk and have five different unrelated IP addresses from three different ISPs. You can't use a /64 option to connect those IPs. But under temp accounts, that would be all one temp account number. WhatamIdoing (talk) 08:19, 4 December 2025 (UTC)[reply]
What I meant was that content creators are driven away by rubbish, whether from IPs or TAs. That is another way for this project to decline. There will always be plenty of vandal fighters because that's easy and fun and productive. Good content creators are rare and need to be protected. Persisting with the old open-door policy might have bad consequences as it becomes harder to deal with disruption, not to mention AI slop and interference from governments and megacorporations. Johnuniq (talk) 08:53, 4 December 2025 (UTC)[reply]
I agree that vandal fighters appear when there is obvious rubbish to be reverted, and that they disappear when the need lessens. But I'm not sure why a good content creator would be deterred by the existence of vandals. After all, it didn't deter us in the pre-ClueBot days, when vandalism persisted on pages much longer. WhatamIdoing (talk) 01:43, 5 December 2025 (UTC)[reply]
I have to agree with Some1 and SuperPianoMan9167 that disabling unregistered users from contributing would be a horrible idea. There are way more constructive IPs than vandals, we just pay more attention to vandals because they're the ones who require action. I dislike the recent trend of requiring people to create accounts to see certain contents or contribute to a site (it recently caught onto Twitter, Tumblr, and even Fandom, and it's made me look up all three significantly less), and I do not want Wikipedia to fall into that trap; speaking from personal experience, the primary reason why I even started editing here was because I was able to do so without needing an account, and I would not want to take that experience away from other people. Unnamed anon (talk) 06:42, 4 December 2025 (UTC)[reply]
Seconded from me. There are more good IPs than bad ones and it's a pain in the butt for an innocent potential editor to be turned away because they need to create an account. Toby(t)(c)(rw)06:46, 4 December 2025 (UTC)[reply]
Agreed -- bad edits might be up, but _all_ edits are up. I've seen way more talk interaction from readers since we stopped making them sacrifice privacy to communicate with us. Feoffer (talk) 15:05, 4 December 2025 (UTC)[reply]
November edits in 2025 are down compared to November edits in 2024. Total edits to non-content pages were 1.819 million in November 2024 and 1.1859 in November 2025. That's a 2% increase, which is probably random variation. I don't see a way there to count only the Talk: namespace. That'd probably require help from Wikipedia:Request a query. WhatamIdoing (talk) 05:26, 5 December 2025 (UTC)[reply]
And the active users has jumped to 300k. I think TA should be excluded from it because one user can have multiple TA (because they may edit on different devices) Before last month, i think we had 120k active users. JuniperChill (talk) 10:47, 5 December 2025 (UTC)[reply]
I don't think we should disable unregistered users. I think the project suffers in some ways for not doing so, but I don't think it should actually be done. But temp accounts are just a license to vandalize. Snokalok (talk) 02:29, 5 December 2025 (UTC)[reply]
Earlier this year, I took a look at TA and came to the conclusion that they are a far greater privacy threat than IP editing ever was. I described the details in T388320. The ticket is not public because WP:BEANS, but if you have a phab account and a need to know, I'll be happy to subscribe you. The most gaping exposure has since been fixed, but the concept is still valid and easy to exploit by any semi-sophisticated bad actor. RoySmith(talk)13:39, 5 December 2025 (UTC)[reply]
There either currently is a dispute at WP:ANI about writing on another user's user page, or is at WP:ANI a record of such a dispute: Wikipedia:Administrators'_noticeboard/Incidents#Harassment_by_CarterDillard. As can be seen, at least two editors, including myself, told the editor who made the note on another editor's user page that modifying another user's user page is highly irregular in Wikipedia culture. The editor who modified the user page then replied: I was not aware of the policy on user pages (if it's just culture, it should be made a policy). I looked at the user page policy, and I didn't find a statement that explicitly discourages making an entry on another user's user page.
The user who made the questionable post appears to be seeking to right great wrongs, but that is not the issue here. They didn't know that writing on another user's user page is improper, because there is no written rule saying that it is improper.
It's under WP:USERTALKSTOP. "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." GeogSage (⚔Chat?⚔) 20:27, 3 December 2025 (UTC)[reply]
We certainly should not make a brightline rule about this. There are lots of good reasons for editing a userpage that is not your own. — xaosfluxTalk20:56, 3 December 2025 (UTC)[reply]
^This. If editing someone else's talk page were the user in question's only issue, it could easily be resolved by a simple conversation with them, pointing them at WP:USERTALKSTOP and explaining things. It's all the other stuff that made this situation in particular rise to the level of an ANI report. Hard cases make bad law and all that. Writ Keeper⚇♔20:59, 3 December 2025 (UTC)[reply]
(edit conflict) I think no; bad cases make bad policy. It seems to me that the problem here wasn't that the user wrote on another user's user page, it was what they wrote and would have been a problem had they written it anywhere. Writing on another user's user page isn't inherently problematic, and I don't think this is a good reason to add policy language suggesting that it is. I say this as someone whose user page has been semiprotected since 2016, though. Ivanvector (Talk/Edits) 21:03, 3 December 2025 (UTC)[reply]
Seems to me an unnecessary extension of policy; a huge amount of what we do is done through convention, guidelines, and generally good faith. In particular in this matter, many user pages have other (not the specific editor) watchers who often will intervene and remove stuff not needed. On mine own page, for example, i count seven or eight assorted editors who have removed vandalism or "personal" comments ~ not to mention the times i have done so myself (including sixty consecutive edits by one person; simply a matter of a couple of clicks to revert all of them). In the case of actually vile attacks (which i am too gnomic to be the recipient of), we have other policies against them, and anyone who is of a mind to make such an edit is going to anyway, despite another policy against it ~ LindsayHello12:00, 5 December 2025 (UTC)[reply]
If someone else edited my userpage, I'd feel a bit intruded on, as if someone had come into my garden and poked around. By itself editing someone's userspace isn't a major transgression, but it's intrusive and somewhat controlling. There are certainly circumstances where a sysop or someone duly elected to enforce conduct issues and behavioural norms might need to edit userspace and I don't object to appropriate edits; but I'm very much not a fan of the self-appointed userspace police.—S MarshallT/C12:09, 5 December 2025 (UTC)[reply]
RfC: Replace text of Wikipedia:Writing articles with large language models
The new draft guideline defines an LLM, strongly advises editors not to use LLMs to add content to Wikipedia, and describes how to handle LLM-generated content that is already present.
Support, per a lot of the arguments made in the previous RfC. I quibble with "unreviewed", but regardless it’s a big improvement on the current policy. 'Perfection' is not required, even an incremental improvement is constructive, and future RfCs can always address quibbles. Kowal2701 (talk) 12:43, 4 December 2025 (UTC)[reply]
Support Consistent with current practice. I'd like future RfCs on mandating LLM-use disclosures and clarifying acceptable limited uses like source-searching and copyediting. Catalk to me!13:29, 4 December 2025 (UTC)[reply]
That's one reason why a little bit longer RFCBEFORE might have been helpful, as I know I for one strongly supported the previous version but frankly don't have time to keep up with the pace of this conversation. -- LWGtalk16:29, 4 December 2025 (UTC)[reply]
Don't beat yourself up about it; there's a decent support base here. I think a fair amount of us are tired of endless workshopping and RFCBEFORE and just want to get things over the line. There's never going to be something perfect which will satisfy everyone and cover all the bases, and we can always modify once it's in place (which is literally what we're doing currently with NEWLLM, so...) Athanelar (talk) 14:45, 5 December 2025 (UTC)[reply]
"tired of endless workshopping" and "we can always modify once it's in place" are directly contradictory. Tired of workshoppibg, but we can always workshop more later? Have you considered just stopping? NEWLLM is only two weeks old, it doesn't need to be expanded so quickly. If this RFC doesn't succeed, consider just walking away from the whole issue for six months or a year. If editors who have worked on this are tired of working on it, consider stopping working on it, rather than "just want to get things over the line". Levivich (talk) 15:53, 5 December 2025 (UTC)[reply]
No need to apologize. I'm more frustrated with a large part of the community that is allowing their anti-AI dogma to force us to rush decisions that ought to be made deliberately. The gudieline as it currently exists, for example, is so vague as to be useless, but it was nonetheless forced through because editors felt the need to "do something" without thinking about what it is we're trying to accomplish. We are shooting ourselves in the foot by encouraging PAGs that are hostile to LLMs and will result in people being rude and dismissive towards new editors who might innocently, but improperly, use an LLM. voorts (talk/contributions) 15:06, 5 December 2025 (UTC)[reply]
Discussion was ongoing for 2 weeks with 100s of comments, it's challenging to make a single proposal for an RfC because people with strong and polar opinions engage more while the majority that are moderate don't. People being rude can be dealt with by our current policies. It's not a coincidence that the most hard-line opposition to LLM-use comes from NPP, AFC, and LLMN/AINB, it's not right that people defend LLM-use but don't engage in any clean-up. Kowal2701 (talk) 15:27, 5 December 2025 (UTC)[reply]
To be fair, I haven't done a ton of NPP recently. I still think we can deal with incompetent AI use without banning good AI use. To paraphrase myself from one of the discussions at the new gudieline talk page, it's fantasy to think that banning LLM use will stop new editors and bad actors from misusing AI (which is already a CIR issue); all it will do is bar productive AI use and result in litigation about whether AI was used, rather than focusing on whether its use was disruptive. voorts (talk/contributions) 17:09, 5 December 2025 (UTC)[reply]
The community isn't really rushing if anything it took Wiki a long time to get a guidline on AI(and personally I think while the current one can be improved it is not useless but beneficial and long overdue.) GothicGolem29(Talk)22:03, 5 December 2025 (UTC)[reply]
Oppose The "Do not use an LLM to add unreviewed content" section is self-contradictory about what is and is not allowed. The guideline as whole makes no mention of disclosure, per Ca needs to mention accepted uses, not relying on machine detection and (sadly) also needs to be explicit about assuming good faith and not harassing editors. Thryduulf (talk) 13:54, 4 December 2025 (UTC)[reply]
@Thryduulf Since you replied to me below: what exactly do you find contradictory? That section disallows a bunch of stuff, but I don't see where it explicitly allows anything, so I'm not seeing any contradiction. Toadspike[Talk]02:05, 5 December 2025 (UTC)[reply]
The section starts off by saying "Don't Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one." which is contradicted by nearly everything else in the section which is more nuanced and implicitly allows stuff. It also contradicts other policies and guidelines that (implicitly or explicitly) allow AI in some circumstances.
If multiple people see a section as self-contradictory (which they do) and multiple other people read the exact same words and don't see that (also apparently true), then that's evidence that the text is not clear enough to be a useful guideline. Thryduulf (talk) 02:30, 5 December 2025 (UTC)[reply]
Oppose - first, that RFCBEFORE was open for like 12 hours. That's not enough time. Substantively, I oppose "do not use LLMs..." as overly broad, totally unenforceable, and just a bad idea overall, like saying "Do not use a word processor...". We want to prohibit people from cutting-and-pasting LLM output wholesale onto Wikipedia (in articles or on talk pages); we do not want to prohibit people from using LLMs for any reason or in any way. If I want to use an LLM to start a draft and then I personally edit that draft to improve it, fact check it, etc., nobody on the internet will ever know I did that and, assuming my output is policy-compliant, there is absolutely no reason to prohibit me from doing it. You all have no idea if I started this comment with an LLM, or had an LLM write it. Or if I asked an LLM to check the grammar, or suggest improvements. Frankly, LLMs write better than some people write on their own; for some, an LLM-written comment is better than one written without the help of an LLM. We don't want to discourage people from using LLMs in any way, because they are useful. They can be used as dictionaries, thesauruses, search engines... wholesale copy-and-pasting articles/comments isn't the only way to use them. Additionally, A large language model (LLM) means any program that can generate natural-language text either in response to prompts or by transforming existing text. is not what a large language model is; see the Wikipedia article for a definition. Please, please, please, not yet another Wikipedia guideline that redefines words to mean something different on Wikipedia than they do in the real world. If you want to expand the existing guideline (which should be expanded), say "do not copy-and-paste without checking..." (it doesn't need to be said three times, just once is fine) and then have the "handling LLM-generated content" part (the word "existing" is unhelpful, because it would apply to "new" LLM-generated content as well as existing content). Levivich (talk) 14:50, 4 December 2025 (UTC)[reply]
V3 was posted 22:37 Dec 3 according to Special:Diff/1325583018. Was it posted somewhere else on Nov 24? Best practice, especially for site-wide new rules, is to announce the intent to end the RFCBEFORE and launch the RfC, and ask if anyone objects, and then wait at least a day, preferably more than one, for any objections. "Are we going to categorically prohibit all usage of LLMs on Wikipedia" is a question the community has already answered with "no" in prior RFCs, and should probably be asked on its own before we try to write guidelines that implement such a major change. Levivich (talk) 15:03, 4 December 2025 (UTC)[reply]
I'm sure I speak for everyone when I say no apologies necessary, we all make mistakes :-) Another thing on the substantive draft: the reason that the current WP:NEWLLM guideline is so short, almost comically so, is because that's all that we've got consensus for so far. But that guideline, those words, are what has consensus. And it says, Large language models (LLMs) can be useful tools..., so to rewrite the guideline into an absolute prohibition runs contrary to that consensus statement. LLMs can be useful, which is why their use should be permitted within certain boundaries. The current guideline continues ... but they are not good at creating entirely new Wikipedia articles. That has consensus, too; almost everyone will agree that having an LLM write an entirely new article, and copying-and-pasting it onto Wikipedia, is disruptive because of the high risk of error. An expansion of WP:NEWLLM needs to build upon that foundation, not try to re-write it into an absolute prohibition. A better approach to expanding the guideline would be a "LLM Do's and Don'ts"-style guide, that teaches people the proper and improper ways of LLM use--when are they useful and when are they disruptive. It should explain why the "don'ts" are "don'ts," and suggest better "do's". Levivich (talk) 15:14, 4 December 2025 (UTC)[reply]
It's worth reading through the RFCBEFORE if you haven't already, as much of this has already been discussed there. Namely, a few of us pointed out concerns with carving out acceptable use cases in a guideline that is essentially fundamentally designed to prohibit, not to permit. The goal is to tell people what they shouldn't do. If you include a section explicitly detailing the acceptable uses, then anyone who gets accused of using them unacceptably is just going to claim they were doing one of the acceptable things (I've already seen it happen; "oh, I didn't generate my comment with an LLM, I just used Grammarly on it and that's why it sounds like LLM prose")
This also really isn't an absolute prohibition; it still provides a carveout in the language of "unreviewed" content. It says you "should not" use an LLM to generate content for Wikipedia, not that you "must not." The only thing it absolutely prohibits is generating new articles from scratch with LLMs, which is (from what I see) generally interpreted as the meaning of WP:NEWLLM anyway, so there's no change there. Athanelar (talk) 16:58, 4 December 2025 (UTC)[reply]
I disagree with "a guideline that is essentially fundamentally designed to prohibit, not to permit. The goal is to tell people what they shouldn't do." - the guideline should be designed to guide, meaning to instruct, which means both prohibitions and permissions, what they should and shouldn't do.
I disagree with "anyone who gets accused of using them unacceptably is just going to claim they were doing one of the acceptable things". This is an old argument on Wikipedia that I've seen raised many times, and I think it's bad advice, contrary to the fundamental purpose of guidelines, which is to teach. The notion that we shouldn't outline what is acceptable because people who do unacceptable things will claim it's acceptable is nonsensical to me.
I disagree with "It says you 'should not' use an LLM to generate content for Wikipedia, not that you 'must not.'" That is the exact reason why "should" shouldn't be used in policies and guidelines. "Must" and "may" are clear; "should" is ambiguous. It's too bad that many of our policies and guidelines use "should" go mean both a requirement and a suggestion. We must not continue this practice.
Basically, I disagree with you on the fundamentals for what makes a good guideline, and what the purpose of the LLM guideline ought to be. Fundamentally, you want a clear rule you can use to take action against people who do something you think shouldn't be done. That's not how rules on Wikipedia work, or should work. Our rules are not laws, they are guides and descriptions of practice (descriptive, not prescriptive). Levivich (talk) 17:33, 4 December 2025 (UTC)[reply]
Completely agree, and frankly I don't understand the justification for keeping important background information out of the guidelines. Guidelines aren't information pages. We have plenty of information already about why using LLMs is usually a bad idea at WP:LLM. is the reason given for why NEWLLM does not justify itself. I disagree. Guidelines are absolutely information pages. If we don't explain why we don't want articles to be generated with LLMs, it gives the impression that their use is banned based only on Wikipedians' opinions.
If WP:LLM is the page that explains why using LLMs is a bad idea, that should be the guideline, not another entry in a series of incremental restrictions on LLM use. Making such incremental restrictions is more confusing to newbies then just explaining everything in one place.
I prefer to read NEWLLM not as a ban on LLM-generated articles, but as a piece of generally accepted advice saying "LLMs are bad at writing Wikipedia articles, so it's generally not a good idea to use them." Although a significant number of editors read NEWLLM as "LLM-generated articles are prohibited and subject to deletion."
Confession: Other, experienced editors already pointed out the problems with vague guidelines in the RfC. I argued against them. I now understand why they opposed. SuperPianoMan9167 (talk) 20:20, 4 December 2025 (UTC)[reply]
Support per my previous reasoning, which I'm just going to copy-paste because it remains unchanged: "Having no policy effectively is encouraging LLM use. The longer we remain in that state, the longer we are encouraging LLM use, and the longer it accumulates on Wikipedia [...] Going three years [without] AI policy has done substantial damage to the integrity of Wikipedia, and frankly we're probably near the precipice where that damage becomes irreversible." To this I will add: the longer we remain in this state, the longer the project is fundamentally misleading bordering on lying to our readers, given the huge advertising in the past few months about how Wikipedia is the human alternative to AI. Gnomingstuff (talk) 15:05, 4 December 2025 (UTC)[reply]
@Gnomingstuff This is not proposing to adopt a policy but to replace one guideline with a different guideline. I'm also going to have to ask for a citation for pretty much all of your justifications, particularly Going three years [without] AI policy has done substantial damage to the integrity of Wikipedia. Thryduulf (talk) 15:27, 4 December 2025 (UTC)[reply]
First, stop pinging me.
Second, I know what this is a proposal for. My view is that we need a policy but in the absence of that a guideline is the next best thing, and that this guideline is the improvement.
Most of the justifications should speak for themselves, but regarding the advertising push I am referring to stuff like [11] (which, among other things claimed that Wikipedia had AI guidelines when it didn't at the time) Gnomingstuff (talk) 15:47, 4 December 2025 (UTC)[reply]
Not exactly. The article you link to says "In all cases, volunteers create and enforce guidelines for responsible use of AI tools...", that was on Nov. 10, and by then WP:NEWLLM had already been created and was in the middle of the RFC to promote it to a guideline. I am also curious why you think that "substantial damage to the integrity of Wikipedia" has occurred in the last three years due to the lack of an AI guideline. Can you point to an example of a false statement in a Wikipedia article introduced by LLM usage that remained in mainspace for a significant amount of time, that wouldn't have remained if we had had an AI guideline? Levivich (talk) 16:12, 4 December 2025 (UTC)[reply]
Not to speak on @Gnomingstuff's behalf, but from my point of view the lack of guideline has meant that disruptive use of LLMs by editors has meant protracted discussions at ANI and other noticeboard while editors and admins um and ahh over what to do about it. qcne(talk)16:28, 4 December 2025 (UTC)[reply]
As far as damage to the integrity of the encyclopedia: I refer you to your previous stance here:
We don't know how many [need to be dealt with]. But even if a mere 10% are bad -- 9,000 articles -- PRODing 10 a day would take 3 years. And if it's higher than 10%, if it's 50% bad, then we're talking over a decade to PROD them all. To go through them case-by-case is totally impossible, in my view.
Substitute "PRODing them all" with "fact-checking them all" (fact-checking being much more time-consuming than PROD), and "9,000 articles" with "some unspecified but large amount of edits" (edits being much more numerous than articles).
As a data point, there are currently around 4,376 drafts identified and/or declined as likely AI-generated in the past 6 months, not counting anything deleted for being older than that, and around 3,900 articles identified as possibly containing AI-generated text, not counting anything already fixed or still undetected. Are we at 93,000 unreviewed AI-generated edits? I think we're easily on track for that in the next couple of years. Gnomingstuff (talk) 17:11, 4 December 2025 (UTC)[reply]
Support I think this is a very reasonable (and workable) proposal. I also think if future edits are desired, this structure is a good base. --Enos733 (talk) 16:04, 4 December 2025 (UTC)[reply]
Oppose this gutted version, support version 2 from the RFCBEFORE As much as this would be an improvement on WP:NEWLLM, in it's current state it's just going to require an immediate RFC to strengthen it, and I'm tired of spending all my Wikipedia time on AI issues. Specifically we need these sentences back in the guideline:
Define appropriate scope: LLMs, if used at all, should assist with narrow, well-understood tasks such as copyediting. New editors should not use LLMs when editing Wikipedia.
Clearly state what CIR looks like for LLMs: If the editor cannot confidently check and correct the output, they should not use an LLM for that task. LLMs should not be used for tasks in which the editor has little or no independent experience.
Set an expectation of disclosure: Editors should disclose LLM assistance in the edit summary (e.g. "copyedited with the help of ChatGPT 5.1 Thinking"). This helps other editors understand and review the edit.
I also support Thryduulf's suggestion of adding something about AGF and biteing, since that is a common concern raised about stronger AI guidelines. -- LWGtalk16:45, 4 December 2025 (UTC)[reply]
WP:LLM would need changes if it became a guideline, which brings back the original issue: there is no agreement on the changes. --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 19:43, 4 December 2025 (UTC)[reply]
I would prefer to use @Qcne's proposal as a basis for a guideline than WP:LLM, which I find bloated. If we can resolve the contradictory language and section header, and potentially incorporate some of LWG's suggestions, I think we can get something pretty strong approved! NicheSports (talk) 19:58, 4 December 2025 (UTC)[reply]
How is WP:LLM bloated? Aren't guidelines meant to educate? The rules are not intended to be laws. I don't think "you can't use LLMs because Wikipedians say so" is a good approach to a guideline. SuperPianoMan9167 (talk) 20:02, 4 December 2025 (UTC)[reply]
Oppose as not strong enough. This isn't even an improvement on the status quo, so I see no reason to support this.The weakest of weak supports this version is a little tougher than previous versions, and it is a faint improvement of the status quo of no guidance at all. Nonetheless! – AI-generated text isn't appropriate for a human encyclopedia, period. Re Ca and Thryduulf: there are no accepted uses. Cremastra (talk·contribs) 16:48, 4 December 2025 (UTC)[reply]
Oppose with disappointment and some frustration. Agree with Thryduulf on Do not use an LLM to add unreviewed content" section is self-contradictory which was the exact feedback I gave at the RFCBEFORE, which @Qcne didn't engage with. I would enthusiastically support this interpretation but it is not clear from the language in the current proposal that this is what is intended. As written this contradictory language will cause significant confusion "in the field" especially for newer editors. Minor changes could have resolved this. The RFCBEFORE should have gone on longer to address this type of feedback. NicheSports (talk) 16:49, 4 December 2025 (UTC)[reply]
I know it's faux pas to modify a guideline during RfC, but would your vote change if we changed the section header like so;
−
Do not use an LLM to add unreviewedcontent
+
Do not use an LLM to add content to articles without thorough human review, or to create new articles
I think this brings the section header in line with the body of the guideline and the spirit of its intent, and should I think be relatively uncontroversial as a result.
No. In addition to not addressing most of my points this just demonstrates it's still very unstable and thus not ready to be considered for adoption. Thryduulf (talk) 17:16, 4 December 2025 (UTC)[reply]
I think it'd be better as "Do not use an LLM to modify or add content to Wikipedia articles, or to create new articles." --not-cheesewhisk3rs ≽^•⩊•^≼ ∫ (pester) 17:19, 4 December 2025 (UTC)[reply]
No, but I would support "Do not use an LLM to add content to articles without thorough human review." It should also say something about how we are responsible for what we publish on this website regardless of what tools we used to draft the text, so the review should be as "thorough" as is necessary to ensure compliance with policies, because if the text is not compliant, the editor will be held accountable for it. I wouldn't support the whole proposed guideline just with this one change, as I still don't support other parts of it, but it would bring me a step closer. Levivich (talk) 17:25, 4 December 2025 (UTC)[reply]
This doesn't address the contradictory language at all. I can draft something later that would, but unfortunately the RFC is already open. Bah. NicheSports (talk) 17:35, 4 December 2025 (UTC)[reply]
LWG's changes are basically just returning to V2 of Qcne's proposal, which was controversial during the RFCBEFORE.
Ultimately, there's no pleasing everyone here. The LLM hardliners like me won't be pleased by more permissive language, and the permissive ones won't be pleased by more restrictive language. I think this version really is the best middle ground. Athanelar (talk) 18:08, 4 December 2025 (UTC)[reply]
I'm not opposing because this is too strict or too permissive, I'm opposing because it is contradictory. We need to stop rushing LLM PAG RfCs. Agree with Kowal2701, let's remove the RFC tag and work out this issue. But I can't do that because I have !voted. Qcne can, or an uninvolved editor. NicheSports (talk) 18:24, 4 December 2025 (UTC)[reply]
Oppose - It contradicts itself in a few places as pointed out above. Also explicitly states it should not be used in general and that is just wrong. It can be used, but it needs to be reviewed and verified, which is a huge difference. ~2025-38536-45 (talk) 19:43, 4 December 2025 (UTC)[reply]
Support - this proposed guideline is still insufficiently strong, but it is a step in the right direction, and we should take it, even if we need to fix a wording here and there later, and even if we have to immediately hold a follow-up to try and strengthen it further. Tazerdadog (talk) 21:52, 4 December 2025 (UTC)[reply]
Support – I have some qualms about the specifc wording, but this is a massive improvement. Thank you, Qcne. We should be listening to folks like him who have reviewed tens of thousands of AfC drafts, not nerds like me who spend too much time yapping on noticeboards like this one. Toadspike[Talk]22:02, 4 December 2025 (UTC)[reply]
Support - the right approach, and we will certainly continue to tweak. FWIW, I think AGF is implicit and nothing here undermines it so shouldn't need to be spelled out. —Rutebega (talk) 22:22, 4 December 2025 (UTC)[reply]
It shouldn't need to be spelled out, but experience has tells us that it absolutely does need to be. There are far too many editors who believe that a suspicion (correct or otherwise) of using AI is an automatic declaration of bad faith and thus they are free to respond in kind. Thryduulf (talk) 23:11, 4 December 2025 (UTC)[reply]
Support I'd prefer stricter but, after a pretty thorough discussion this version satisfies most of the issues raised in the previous rfc, and no policy is ever going to be perfect. So let's not fall for the perfect solution fallacy and pass incrementally better versions instead of failing the imperfect. Also, Randy in Boise might actually realize he cannot simply paste what ChatGPT says about the Peloponnesian War. ~ Argenti Aertheri(Chat?)23:45, 4 December 2025 (UTC)[reply]
Perfect is indeed the enemy of good, but I do not believe that something that is self-contradictory and has other issues (as noted above by multiple people) can be accurately described as "good" nor as "better" (incrementally or otherwise) than what preceded it (as that does not contradict itself). Thryduulf (talk) 00:47, 5 December 2025 (UTC)[reply]
Oppose as insufficiently clear. This ambiguity will not permit good decision-making and will just cause issues - more time workshopping this proposed guideline would have been appreciated. Katzrockso (talk) 02:45, 5 December 2025 (UTC)[reply]
Support as clearly better than the current guideline. We need to have a guideline that will clearly discourage the use of any unreviewed LLM created material in any article, not just in articles created from scratch as at present, and this draft does that. It may be that the guideline needs rephrasing in places (and in particular the first sentence of the "Do not use an LLM to add unreviewed content" section should be rephrased to make it clearer that only raw or lightly edited LLM content is being forbidden here), but we shouldn't let that stop us implementing this guideline as it is, since we can always improve it later. Dionysodorus (talk) 08:00, 5 December 2025 (UTC)[reply]
Oppose. I share Thryduulf's concern that the do not use an LLM to add unreviewed content section is contradictory. The section itself only mentions not using LLM's to generate content it does not reference reviewed content or give examples of reviewed content that would be acceptable. GothicGolem29(Talk)14:20, 5 December 2025 (UTC)[reply]
Oppose. This is poor guidance that prevents legitimate uses of LLMs:
Editors should not use an LLM to add content to Wikipedia, whether creating a new article or editing an existing one. Do not use an LLM as the primary author of a new article or a major expansion of an existing article, even if you plan to edit the output later.
Sure. As one example, someone might notice information is missing from an article, use AI to draft a paragraph with that information, comb through it to correct errors or policy/guideline violations (if any), and include it in the article with appropriate sourcing.
But this is a general-purpose technology - there are innumerable valid uses of AI, from research, to copyediting, to finding errors in articles. The important part is that any AI-generated content must be rigorously reviewed and corrected by a human editor. I would be glad to support a guideline emphasizing this. Anne drew (talk · contribs) 22:23, 5 December 2025 (UTC)[reply]
Legitimate uses:
Human-reviewed article improvement suggestions
Human-reviewed ideas for new articles
Human-reviewed analysis of diffs and usernames for RCP patrolling
Oppose per Levivich, who seems to sum up the issues well. The word processor analogy is a good one - in the right hands, with due care an attention, an LLM can be a useful tool in helping to produce better-quality prose and basic sanity checking of what you've written. And clearly in the wrong hands, LLM use is very dangerous - it gives editors the ability to churn out lots of material if questionable accuracy. The current guideline has an advantage that it is very short and to the point, it's very easy to see what it prohibits. I would support an expansion of that to (equally succinctly) prohibit new unreviewed LLM content of any flavour rather than just "new articles from scratch", but I certainly wouldn't support a change that restricts legitimate LLM use more generally, or makes it more wordy and therefore harder to point new users at the hard rules about what they can and can't do. With thanks to the OP for wading into this difficult debate and attempting to make progress, I unfortunately do find the proposal too wordy (as well as potentially contradictory, as per Thryduilf) to be an a improvement for us. Cheers — Amakuru (talk) 17:41, 5 December 2025 (UTC)[reply]
Support. I am unclear of proper protocol for this support message, as this is my first time supporting. I agree with pester and Kowal2701. Parameci (talk) 18:12, 5 December 2025 (UTC)[reply]
Support. Good step in the right direction. There's definitely a faction of editors that want to continue allowing some LLM use. Forbidding "raw or lightly edited LLM output", while not explicitly forbidding "all" LLM use, is what this RFC does, and is in my opinion a good compromise. –Novem Linguae (talk) 23:31, 5 December 2025 (UTC)[reply]
P.S. To address the issues raised above of "Editors should not use an LLM to add content to Wikipedia" (absolute prohibition) being out of sync with "Editors should not Paste raw or lightly edited LLM output" (prohibition of most LLM use), I'd be OK with deleting the sentences that give absolute prohibitions. Just delete that first paragraph of "Do not use an LLM to add unreviewed content" and leave the bullets. Worth it to get this passed. –Novem Linguae (talk) 23:37, 5 December 2025 (UTC)[reply]
Can we all just slow down and try to discuss what the essential components of a comprehensive LLM guideline should be before !voting on one? NEWLLM passed less than two weeks ago. SuperPianoMan9167 (talk) 23:37, 4 December 2025 (UTC)[reply]
I had been following that talk page, saw there was a new draft but didn't have enough time to fully form any thoughts before I saw a message that there was a RfC here.
What Thryduulf and Katzrockso said - I have a day job, you know, and can't be counted on to log in to Wikipedia every week, much less digest thousands of bytes of text from a variety of viewpoints and formulate a well-considered, clearly-articulated response. Plus I have to dedicate at least some of my Wiki-time to content-space contributions or I will lose my mind and quit the project forever. I think these AI conversations are really important and fairly urgent, but on a timescale of weeks or months, not days. -- LWGtalk21:50, 5 December 2025 (UTC)[reply]
Doing per WP:SILENCE... Codename Noreste (discuss • contribs) 22:38, 4 December 2025 (UTC)
Done, see Special:PermanentLink/1325746684. Codename Noreste (discuss • contribs) 23:00, 4 December 2025 (UTC)
Comment: Would vastly prefer this as well... GeogSage (⚔Chat?⚔) 23:25, 3 December 2025 (UTC)
