This is the Village pump (all) page which lists all topics for easy viewing. Go to the village pump to view a list of the Village Pump divisions, or click the edit link above the section you'd like to comment in. To view a list of all recent revisions to this page, click the history link above and follow the on-screen directions.
Discussions older than 7 days (date of last made comment) are moved to a sub page of each section (called (section name)/Archive).
Policy
Adding checkuser-temporary-account to rollbackers and NPP folks
Do folks think it would be a good idea to preemptively give rollbackers and NPP users access to the ability of CheckUser temporary accounts ? (The rights do not do anything at the moment, but they should allow folks with the rights to figure out if two temporary accounts are from the same IP once the rollout of the Temporary Accounts feature) Sohom (talk) 18:54, 8 June 2025 (UTC)[reply]
@Voorts My reading of the policy was the user needs to be in a group that has the safeguards outlined in the policy ? (As opposed to explicitly requiring that folks follow the process all over again) I would consider rollbackers and NPP folks to have met and exceeded all of criteria mentioned there. (cc @SGrabarczuk (WMF) who was involved in the tech-migration side of the project) Sohom (talk) 19:14, 8 June 2025 (UTC)[reply]
Hmm, I'm not sure that's true. I've definitely granted rollback to accounts less than 6 months old or with less than 300 edits before. The guideline for rollback is 200 mainspace edits, see WP:Rollback#Requesting rollback rights, and WP:NPPCRITERIA says 90 days and 500 undeleted mainspace edits. Both of these are less restrictive than the 6 months + 300 edits WMF requirement. Mz7 (talk) 20:55, 8 June 2025 (UTC)[reply]
Going forward, we could make the requirements for NPP/rollback the same as the minimum/whatever additional requirements we impose for temporary accounts access. voorts (talk/contributions) 21:35, 8 June 2025 (UTC)[reply]
Hello @Sohom Datta. @Voorts is correct. The right may not be automatically granted to a group of users. It can be granted manually to those who require this specific access in accordance with the access policy. This right carries requirements that may be different from rollbacker or NPP users. There is also an expectation for the user who gets this right to agree to the terms of use given this right grants the user access to private data (IP addresses). I hope this helps. -- NKohli (WMF) (talk) 11:15, 10 June 2025 (UTC)[reply]
@NKohli (WMF) Could you explain why this cannot be bundled ? I'm still at a loss why we cannot update our policies to meet the minimum, filter out folks in the groups to meet the official criteria and give them temporary-account CU privileges. To my understanding, they will still need to click through and agree to the terms of use even if the right is granted post-facto. Creating a requirement for granting two rights while requesting one will create a unnecessary overhead and bureaucracy on the side of admins and folks who are engaged in good-faith vandalism reversion. Sohom (talk) 11:39, 10 June 2025 (UTC)[reply]
@Sohom Datta to clarify - as long as the user who is getting this right is explicitly applying for it, and meets the requirements, they can be granted the right. This is the second criteria as listed under the policy: Submit an access request to local administrators, bureaucrats where local consensus dictates
@NKohli (WMF) I understand that the policy exists. I am asking for a rationale why the policy demands that we do things in this idiosyncratic way (this is non-standard compared to almost every permission grant I've seen in the last four years, and frankly seems like completely unnecessary bureaucracy). Were local-wiki administrators consulted before this global policy was instituted (if so could you link to the consultation/notes from it) ? Was there a global RFC, phabricator discussion or mailing list discussions about the policy that I can look at to understand it's context ? Sohom (talk) 12:45, 10 June 2025 (UTC)[reply]
Everyone always has to apply for user rights; this one is no different. The only rights granted automatically are auto and extended confirmed. Given that WMF legal wrote this policy and it's intended to comply with GDPR amongst other laws, I doubt this will change. voorts (talk/contributions) 16:00, 10 June 2025 (UTC)[reply]
@Voorts MediaWiki rights (for example, edituserjson as opposed to groups WP:INTADMIN) are typically bundle-able (and the norm is to allow for them to be bundled together for related activities). I don't particularly mind that this isn't allowed tho. What I'm asking for is primarily public documentation and reasoning for why this is the case. (That being said, based on some offwiki conversation I have had, I now have a better idea now of why the policy is what it is) Sohom (talk) 22:40, 10 June 2025 (UTC)[reply]
@Sohom Datta I think notifications to WP:AN and NPP talk page (not sure where RBers gather to discuss matters) would be prudent as this change may affect workloads of these group of editors at the very least. – robertsky (talk) 17:11, 9 June 2025 (UTC)[reply]
I see the benefit for NPP, in that they may have to figure out if various temporary accounts are the same person and IP addresses may help with that. However, I am not seeing as clear a link to rollback. Rollback is essentially a way to simplify reversions, while digging into IP data is sounds like it complicates vandal-reversion. CMD (talk) 02:38, 10 June 2025 (UTC)[reply]
Things like checking if an IP is in the same city as another one, if an IP is from a proxy, or all changes from a certain range like /64. I commonly use various online IP tools when I do anti-vandalism work, losing that ability wouldn't be nice. win8x (talk) 12:37, 10 June 2025 (UTC)[reply]
Temporary accounts will be browser-based. Using a different browser on same device, or clearing the history and starting over again will each create a new temporary account. So, you could act like multiple different persons with minimal effort even on the same IP/device/browser. For those involved in anti-vandal work, it will be essential to check if they all come from the same source or not. —CX Zoom[he/him](let's talk • {C•X})02:22, 11 June 2025 (UTC)[reply]
Temporary accounts (i.e. IP editors in old money) will not be able to create new pages, right? So how would this be useful to NPP? – Joe (talk) 12:32, 11 June 2025 (UTC)[reply]
Proposed requirements for temporary account IP addresses user right
"[a]gree[ing] to use the IP addresses in accordance with these guidelines, solely for the investigation or prevention of vandalism, abuse, or other violations of Wikimedia Foundation or community policies, and understand[ing] the risks and responsibilities associated with this privilege".
I propose that we maintain the minimum requirements, and add a requirement that editors show a need for access. I also propose that we up the minimum requirements for NPP and rollback to match this right and make editors apply for this right simultaneously (and that we consider having those rights as showing a need for access). voorts (talk/contributions) 21:46, 8 June 2025 (UTC)[reply]
Support - I'm up for these requirement (until we figure out if we can bundle temporary account IP addresses into the rights). Sohom (talk) 23:25, 8 June 2025 (UTC)[reply]
Ummmm We should not force someone that wants to do anti-vandalism to also be required to apply for 2 additional groups that they may not want. — xaosfluxTalk23:45, 8 June 2025 (UTC)[reply]
Also #3, #4 are already built in to the interface - we don't need to require that. #1 is already the minimum, so this is making the local requirement be "ask for it"??? — xaosfluxTalk23:46, 8 June 2025 (UTC)[reply]
1-4 are all of the requirements, as the line immediately preceding that list notes: The minimum requirements per the access policy are. My suggestion is that editors applying for this right independently should also have to explain how they would use the right, but I guess that's a necessary part of submitting in application. voorts (talk/contributions) 23:51, 8 June 2025 (UTC)[reply]
OK, so the only part for the local project to decide is if we want more than 6/300, or additional requirements. As far as "show a need for access" being a local requirement, do you have a proposed test for this - or just if you can convince any admin you have a need? — xaosfluxTalk00:36, 9 June 2025 (UTC)[reply]
Convincing an admin that you have a need would be fine. That's part of why I proposed bundling it with NPP/rollback; both of those groups will generally have a need for the right. voorts (talk/contributions) 00:39, 9 June 2025 (UTC)[reply]
I wasn't suggesting that RB should be required to apply for NPP or vice versa. I was suggesting that NPP and RB should meet the same requirements and we should just give the temp-IP right when we give out those other two rights. voorts (talk/contributions) 23:49, 8 June 2025 (UTC)[reply]
Support: Sounds good, but I highly prefer bundling it with NPP and rollback as well. Once this rolls out completely, figuring out abuse by multiple anonymous editors will become extremely more difficult that it already is with IP ranges. Regardless, I think we can trust holders of NPP and rollback to have access to IP data, if we can trust them with reviewing new pages and mass reverting edits respectively. ~/Bunnypranav:<ping>04:04, 9 June 2025 (UTC)[reply]
I have no problem with bundling it as per Bunny, provided there is no room for discretionary variance below the 90 day threshold under WP:NPRCRITERIA. Currently, the guidelines for granting say "90 days" registration is "generally speaking" a prerequisite; if we bundle, this should be made a hard minimum to ensure logged IP data has eclipsed before a potentially malevolent new account was able to register and attain access to masked address information. Chetsford (talk) 14:28, 9 June 2025 (UTC)[reply]
Support minimum requirement as stated with RfP/Temporary account IP viewers page for #2. Oppose bundling with NPP or rollbacker. My point of view is that rollbacker is (or at least it was when I first started out) a relatively easy right to get to help new editors to demonstrate that they can on more rights and responsibilities before moving on to other user rights, while those who are interested in NPP may not be interested in doing anti-vandalism work. – robertsky (talk) 14:43, 9 June 2025 (UTC)[reply]
A rollbacker without the see IP permission would be effectively toothless and while NPP folks don't strictly do anti-vandalism, there are scenarios (for example overturned BLARs, AFC drafts or repeatedly recreated page where it makes sense for folks to have access to IP data) Sohom (talk) 16:15, 9 June 2025 (UTC)[reply]
@Robertsky NPP work sometimes also occasionally requires looking at the creator the articles, and now with temp accounts, a potential sock masters life has become very easy to create similar multiple problematic articles if one gets deleted. If NPR has access to IP data, it should be much easier to spot such attempts (of course creating multiple actual accounts is a thing, but I don't think we should make sock masters' life any easier.)
Regarding rollback, yes I agree it may make it a bit harder, but what is the general edit count when people get rollback? Guidelines state 200 as a suggestion, but I don't think many people can come up to the activity level of RB before passing 200. (I don't have any data, this is just my assumption) ~/Bunnypranav:<ping>16:15, 9 June 2025 (UTC)[reply]
If a pattern of similar multiple problematic articles can be established even without the IP address access, is there really a need? Likewise for repeated BLARs or repeated recreations. Isn't it the same as us assessing multiple newly registered accounts doing the same thing? – robertsky (talk) 16:55, 9 June 2025 (UTC)[reply]
I'm assuming WP:ACPERM still applies (i.e., we won't grant temporary accounts autoconfirmed status) so I don't really see the utility of this for NPP. I'll apply for it if I'm made to, of course, but I don't really see myself using it much. Alpha3031 (t • c) 04:04, 11 June 2025 (UTC)[reply]
Also bundling the rights will require revocation requirements (1 year of inactivity) to be added if there is none. (It is a positive. Just a reminder.) – robertsky (talk) 16:59, 9 June 2025 (UTC)[reply]
Support. Maybe to alleviate concerns temporary (trial run) granting of these right don't include this new userright, but once its indef granted, then its bundled in? I'd be okay with it either way personally. JackFromWisconsin (talk | contribs) 16:27, 9 June 2025 (UTC)[reply]
GDPR has been around for close to a decade now; IP masking, as I understand it, is more about the fear of future legislation rather than current policies. We have a clear third option, follow other projects and turn off IP editing, instead of creating additional levels of bureaucracy. -- GuerilleroParlez Moi19:31, 9 June 2025 (UTC)[reply]
Even TVTropes requires sign-in-to-edit. But way back when this was repeatedly proposed, the WMF repeatedly said "not just no, but snook no". Maybe they've changed in the last decade or so but trust me, a large number of editors have wanted SITE for a long time, and it hasn't happened; it's unlikely to happen now, for better or for worse. - The BushrangerOne ping only23:01, 9 June 2025 (UTC)[reply]
Comment I'm an active NPP'er and also a rollbacker (which I seldom find to be useful and rarely use). Also it would not be too hard for a government / agency that wants to investigate posts by a temporary account to get NPP rights which also defeat one of the purposes of temporary accounts and thus also give a false sense of security to temporary accounts in which case the temporary account might do more harm than good. I think that granting it to all rollbackers is an even lower bar making those problems even worse. Sincerely, North8000 (talk) 19:53, 9 June 2025 (UTC)[reply]
Also it would not be too hard for a government / agency that wants to investigate posts by a temporary account to get NPP rights which also defeat one of the purposes of temporary accounts They would also be able to apply for the IP right outside of those things, so I'm not quite sure why that's a relevant consideration. I think that granting it to all rollbackers is an even lower bar As noted above, the minimum requirements for this particular right (as set by WMF legal) is 300 edits + 6 months with an account, and as noted, bundling the right with rollback would require increasing the requirement for rollback. voorts (talk/contributions) 20:44, 9 June 2025 (UTC)[reply]
Support bundling the application process for NPP and rollback with the temporary account addresses user right. Make granting of NPP or rollback contingent on being eligible and granted the account addresses user right. We should make this coupling of the two applications as simple as possible for applicants--that's where I'm struggling a bit. For current NPP/rollbackers, require application for temp account addresses right as soon as their account meets the requirements. Suspend NPP/rollbacking right on those accounts whose users are eligible for and do not successfully apply for the addresses user right. Consider suspending NPP/rollbacking right on those accounts ineligible for the addresses user right. Take headache relievers consistently, as I see a giant migraine coming on with these changes and the complications herein. — rsjaffe🗣️01:51, 10 June 2025 (UTC)[reply]
Note the use of the word "suspend". As soon as a user with a suspended NPP/rollbacking right that is suspended due to not having addresses right successfully receives addresses right, the linked NPP/rollbacking right would be reinstated without need for a new application. — rsjaffe🗣️01:54, 10 June 2025 (UTC)[reply]
The "minimum account age of 6 months and 300 edits" provides to some extent another automatic user right layer (give or take the applying system), it would be better to align it as much as possible with existing rights. In this case, it perhaps should line up with the WP:EXTENDED right as much as possible, ie. 6 months and 500 edits. CMD (talk) 02:43, 10 June 2025 (UTC)[reply]
Support for NPP, oppose for rollback. I don't get the arguments here that rollbackers are "toothless" without the ability to view IPs -- rollback is supposed to apply to edits that are obviously unconstructive. If you need to investigate someone's IP address to determine whether an edit is unconstructive then it isn't obvious. Gnomingstuff (talk) 04:43, 10 June 2025 (UTC)[reply]
Strong Support for Rollback & Support for NPP. It's a bit obvious that vandalism fighters may require this right to check if two different vandal accounts are actually used by same person.Ɔþʱʏɾɪʊs⚔07:46, 10 June 2025 (UTC)[reply]
Strong oppose bundling with either NPP or rollback; a decision to double or triple the experience level for a user group should be done on its own merits, not snuck in as a technical criterion, and this would cause the NPP backlog to explode. And I'm not convinced by Sohom Datta's claims, especially since logged-out users can't even create articles so it should be completely orthogonal to NPP status. And while he has more of a point for rollbacker; people of all levels of experience will patrol vandalism and while it may be more effective with temp account access there's no reason whatsoever to forcibly prohibit people who don't meet the temp account view criteria from using Huggle, for example. If specific people find that this access would be helpful, they can request it. * Pppery *it has begun...16:11, 10 June 2025 (UTC)[reply]
Oppose mandatory bundling. We may have editors who don't want this permission but want to be able to patrol new pages/redirects and/or have rollback. Updating the instructions, once the masking is live here, to encourage editors applying for NPP or rollback who meet the 6/300 requirement to also ask for it as part of the request could be useful. Or admins suggesting it as part of the process of reviewing the permission requests for NPP and rollback if they feel the editor would be a good one to have that additional tool. Skynxnex (talk) 21:39, 10 June 2025 (UTC)[reply]
In T388320 (not publicly accessable), I pointed out what I believed to be a serious flaw in the Temporary Account system which could lead to significant leakage of personal information (in excess of what we have now with IP edits). One of the things I argued for in that ticket is requiring the TA user right to be explicitly granted, and I'm glad that this was done. So I'm firmly in opposition to any attempt to walk that back.
As for granting this to all NPP and RB holders, consider that when those rights were granted to people, the granting admin evaluated whether they trusted the user to use the particular powers being granted. To say that "Because some admin last year thought you wouldn't abuse rollback, we're now going to automatically add in some other unrelated right which will allow you to do far more dangerous things" seems absurd. If you want the TA IP viewer bit, ask for it. I don't imagine there will be a very high bar to giving it out, but keeping a human in the permission granting loop is essential. RoySmith(talk)16:08, 12 June 2025 (UTC)[reply]
Revocation of rights
Does anyone know if the requirement to make an edit or perform a logged action is enforced automatically by the MediaWiki software? That is, if you have been inactive for 365 days, you won't have access even if you hold the right by virtue of your group memberships? isaacl (talk) 01:44, 9 June 2025 (UTC)[reply]
Even if it is not removed automatically, we can deal with it manually like we do for some rights, like adminstrators, autopatrollers, etc. Although preferably there should be a way to autoexpire the user group membership given that it is a Foundation-mandated requirement. However, from the way I read the access policy, we should also take into account that local community consensus can be achieved to increase the minimum threhold for retention. If [sic] local community consensus dictates removal, then stewards or local administrators and bureaucrats are authorized to terminate access.– robertsky (talk) 14:14, 9 June 2025 (UTC)[reply]
Sure. I asked because I think that affects the decision to bundle the right with an existing group. If I understand correctly, this wouldn't be feasible if we need to manually remove access from those who have been inactive for a year. Alternatively, the groups would need to have the same inactivity requirements (in addition to the criteria listed in the "Proposed requirements" section, in which my comment was originally placed). isaacl (talk) 16:48, 9 June 2025 (UTC)[reply]
NPP has 1 year inactivity requirement. Rollback does not have any. It is feasible to do so manually. If I am not mistaken, there are admins who have been tracking which accounts to remove which rights. I don't work in this venue often, so correct me if I am wrong. I took the liberty to break it out to a separate section as your question was at the same indent level and the newer entries are getting disjointed. Feel free to move back indent accordingly. – robertsky (talk) 17:07, 9 June 2025 (UTC)[reply]
Yes, I agreed it is feasible to manage manually if the group itself has a matching activity requirement. It's something that would have to be added to the requirements to continue to hold the rollback right, and then the tracking process implemented. (If the answer to my initial question is "yes", then of course this extra work can be skipped.) Thanks for adding the note regarding the additional requirement to the "Proposed requirements" section. isaacl (talk) 17:34, 9 June 2025 (UTC)[reply]
Right criteria and functions
So, the comment by Pppery has made me think about this. I feel that a separate right should be made. I am proposing a separate right, TAIV(obviously an acronym). The following would be criteria and functions. We can discuss the changes & improve it per consensus.
Criteria
The editor should be a registered Wikipedia user who has been editing for 6 months.
The editor should have made at least 300 overall edits with 200 edits in the mainspace.
The editor should have no behavioral blocks (including partial blocks) or 3RR violations for a span of 6 months prior to applying.
The editor should have shown experience in patrolling vandalism or new pages.
@Voorts I know that it's from the WMF policy & not your criteria. I said "The 4th criteria by voorts" to quickly clarify that 4th principal from that criteria is being referred. Ɔþʱʏɾɪʊs⚔04:24, 11 June 2025 (UTC)[reply]
The comment from NKohli (WMF) indicates that the right cannot be bundled with an existing group, since access to it must be requested individually. Unless that viewpoint changes, then there has to be a separate group. isaacl (talk) 18:02, 10 June 2025 (UTC)[reply]
My proposal is that we tie together the application process, so both groups are applied for at the same time. Each application is evaluated separately, but the NPP/Rollback application approval is predicated upon the IP addresses approval. This is administrative simplification of the two applications, not a bundling of the groups. — rsjaffe🗣️18:10, 10 June 2025 (UTC)[reply]
I was responding to Ophyrius's proposal. In essence a new group is the only way to go if the right can't be bundled. The community can of course set more stringent criteria if it wishes. isaacl (talk) 00:44, 11 June 2025 (UTC)[reply]
We can make people apply for the new right if they apply for NPP/rollback. What we can't do is automatically give the right to all current editors with NPP/rollback unless they separately apply. voorts (talk/contributions) 18:10, 10 June 2025 (UTC)[reply]
Is there really a need to require everyone who applies for NPR or Rollback to also apply for TA IP viewer right? I don't see how this is critical to the function of those and can't be separate, even if IPs are not going to be available to NPRs/rollbackers without the right, that doesn't affect the process of reverting vandalism or reviewing pages severely. Moreover, I imagine this would significantly affect the majority of valid requests at WP:PERM/R and WP:PERM/NPR to a lesser extent. Tenshi! (Talk page) 19:13, 10 June 2025 (UTC)[reply]
Sure; that's something different than Ophyrius's proposal. I think I agree with Tenshi Hinanawi though—I think editors should be able to request the rights separately, depending on their interest. As per rsjaffe, the request process can be unified so applicants can request all rights in which they are interested at once. isaacl (talk) 00:44, 11 June 2025 (UTC)[reply]
@Isaacl: Well, per Mz7, I support a separate perm page for Taiv. As for the comment by @Tenshi Hinanawi:, I believe that existing rollbackers/Vandalism fighters, should receive this tool as it would help by checking if 2 IPs are of same range/ used by sane user and what to be reported. Ɔþʱʏɾɪʊs⚔04:42, 11 June 2025 (UTC)[reply]
Sure, it can be useful, but I don't believe it should be at the expense of being required to wait 4-5 more months as a new user so you can have both Rollback and TA IP viewer at the same time when you only want Rollback, likewise with NPR. — Tenshi! (Talk page) 17:48, 11 June 2025 (UTC)[reply]
Yes, that's why TAIV should be a separate usergroup that has rollback & reviewer bundled with it (if consensus reached) rather than it being bundled with others. Ɔþʱʏɾɪʊs⚔15:38, 12 June 2025 (UTC)[reply]
RfC proposal
This is a proposal. Please do not !vote. Are there any suggestions for changes?
Background: The WMF is removing public access to IP addresses and replacing them with temporary accounts. The WMF has also created a new user right for access to temporary account IP addresses. The minimum criteria for that user right are:
minimum account age of 6 months and 300 edits;
applying for access;
opting in for access via Special:Preferences; and
"[a]gree[ing] to use the IP addresses in accordance with these guidelines, solely for the investigation or prevention of vandalism, abuse, or other violations of Wikimedia Foundation or community policies, and understand[ing] the risks and responsibilities associated with this privilege".
Question 1: What should the minimum account age and edit count be? Option A: 6 months/300 edits Option B: 6 months/500 edits Option C: Something else
Question 2: Should we adopt additional requirements, such as a specified time period without blocks/bans prior to requesting the right, experience with counter-vandalism work, knowledge of relevant policies and guidelines, etc.?
Question 3 isn't really a binary, the options I think may be plausibly supported are:
All three rights come as a bundle - everyone who has one has them all
All three have the same requirements, but they are independent rights and an editor may have any combination
All three have the same requirements, but only NPP is bundled with IP viewer, rollback remains independent
All three have the same requirements, but only rollback is bundled with IP viewer, NPP remains independent
Rollback is bundled with IP viewer, NPP remains independent and the requirements for it are unchanged
NPP is bundled with IP viewer, rollback remains independent and the requirements for it are unchanged
No change to the status quo.
If anyone wants to bundle NPP and rollback but not IPviewer, with or without changes to the requirements, then I think that should be proposed separately. Thryduulf (talk) 01:58, 11 June 2025 (UTC)[reply]
why make it complicated? Let's just treat it as a standalone user group like we do for all the other user groups, and at the most, word the RfP pages that those who are requesting for NPP or RB may want to request for TAIV separately. – robertsky (talk) 05:03, 11 June 2025 (UTC)[reply]
Given that we need to address question 1/2 before implementation of the new user right, I think we should go forward with that as RfC. The other questions can be addressed going forward. In the interim, editors can continue to apply for rollback and patroller separately. I'm proposing the following question:
Should we maintain the minimum standards or adopt heightened standards? If the latter, please specify.
I've taken up Voorts' musing about Q2 and separated it out for discussion.
My first question is: what are the risks of handing out the privilege? Are there any high-risk scenarios? If not, I don't see a need for further restrictions. If yes, I'd like to see a restriction that weeds out applicants that would be more likely involved in the high-risk scenario.
I agree with this question. It's hard to discuss what potential extra measures may be warranted/necessary without considering specific problems that are foreseen. I think it would be worse to make the criteria unnecessarily high, as it would potentially prevent users who would benefit from the access from having it, and if history tells, it's much less likely for the requirements to be lowered in the future.My initial thought is this: the WMF is doing this for two potential reasons - to increase anonymity, and potentially to stall or prevent future legal concerns over the information being publicized. If the WMF felt higher access requirements were necessary to meet those goals, they would've required it when allowing the information to be accessed by editors other than Checkusers. Since they did not, it suggests that there is not any need for additional restrictions. In other words, beyond the restrictions the WMF is requiring, why should we not maintain the status quo for decades that users can view the IP information of users without an account? -bɜ:ʳkənhɪmez | me | talk to me!02:22, 11 June 2025 (UTC)[reply]
I've been musing on some potential ways to improve this question. I think it should be simpler - While the requirements above are the minimum we can adopt per the WMF, we can also adopt additional requirements if we choose. What other considerations (not specific criteria) would you support being had to permit someone to apply for and/or receive this role? - with the specific criteria to be worked out later. In other words, basically make this two steps - first is there a consensus for any individual consideration to be made into a criteria, and then work out that extra criteria. For example, people may support "some level of antivandalism work" and also support "recent activity" - but they may not support a criteria of "has made at least 10 anti-vandalism reversions in the past 6 months". I think it's going to get very unwieldy very fast if we are all allowed to just propose whatever other specific criteria we think fit, and it will become difficult, if not impossible, to find consensus for any of them. Hence why I think this needs to be the "ask the community for the scenarios they want to see addressed" question, and then the "what should the specific criteria (singular or plural) be that best addresses these concerns" at a later date. -bɜ:ʳkənhɪmez | me | talk to me!02:41, 11 June 2025 (UTC)[reply]
I agree with you. I think apart from the minimum requirement, the rest should be open for administrator's discretion. They'll obviously make sure that a malicious actor not hold the right. —CX Zoom[he/him](let's talk • {C•X})02:58, 11 June 2025 (UTC)[reply]
I think the question should be Option A: Peg to the minimum criteria as required by WMF, then B1, B2... exploring higher restrictions. —CX Zoom[he/him](let's talk • {C•X})02:57, 11 June 2025 (UTC)[reply]
This would be better than the current, imo. But I worry it will become unwieldy with B1 - 100 edits in past 6 months, B2 - 200 edits in past 6 months, B3 - 100 edits in past 12 months, C1 - 10 anti-vandalism/patrolling edits in past 6 months, C2 - must be "active" in anti-vandal work (without being defined), C3 - must show activity in new page patrolling, D1 - should not be actively blocked or banned at all (including topic bans)... etc, etc. That's why I think gauging community consensus on some requirement (for each "category") before workshopping the specific requirement is likely better. -bɜ:ʳkənhɪmez | me | talk to me!19:41, 11 June 2025 (UTC)[reply]
I wonder how much blocks and bans restrict the ability to view IP logs ? I think it would definitely make sense to restrict the right to users in good standing potentially with a requirement for 6 months of activity without blocks or bans. (partially because the ability to view temporary account IPs enhances your ability to ban evade in the first place) Sohom (talk) 16:35, 11 June 2025 (UTC)[reply]
Do we really need to spell out that editors who have active blocks/bans shouldn't receive the user right? That seems obvious to me and I don't think other user right guidelines explicitly say that. voorts (talk/contributions) 19:48, 11 June 2025 (UTC)[reply]
I think Sohom may be getting at an automatic removal if someone is blocked/banned after already having the right, since the technical limitation only prevents a sitewide blocked user (or, I guess, a globally locked user since they can't log in) from accessing the info. For example, a topic banned user with 5 p-blocks from various talk pages would still be able to access the info from their main account if they had the userright. As a comparison, WP:ROLLBACK and WP:PERM/R make no mention of not assigning it to someone with blocks/bans, nor of whether it should be (or must be) automatically removed if someone is p-blocked/topic banned/etc. I don't know if that is standard process or not, but it should probably be explicitly stated. -bɜ:ʳkənhɪmez | me | talk to me!19:53, 11 June 2025 (UTC)[reply]
What @Berchanhimez said, I think we are a fair bit more open to giving folks rollback than we should be with CU-TA which will be able to give folks a leg up in AE areas (which is where a lot of topic bans, i-bans and p-blocks come from in the first place). I think making it explicit that any block or ban preclude folks from receiving the right is a good line in the sand to draw to point out that CU-TA will require a higher level of trust. Sohom (talk) 21:56, 11 June 2025 (UTC)[reply]
Question 3 discussion
I think the key question to discuss is whether or not the checkuser-temporary-account right is a necessary prerequisite for new page patrol, or for rolling back edits. (I know that the rollback right is used to provide access to certain tools, but editors can still request it solely for making rollback simpler, by some measure.) I think answering this will answer whether or not being approved for checkuser-temporary-account right should be a necessary requirement to be approved for new page patrol or rollback. isaacl (talk) 02:20, 11 June 2025 (UTC)[reply]
I'm interested to see thoughts on this, because as you say there are use cases for the other rights that wouldn't require or even benefit from having this access. I wouldn't support this basically becoming a "new criteria" to get one of those rights if it's not absolutely necessary for the use of those rights. For example, the WMF isn't even requiring administrators to opt in to this - which suggests that this is not necessary for those (or any) part of the admin toolkit. -bɜ:ʳkənhɪmez | me | talk to me!02:25, 11 June 2025 (UTC)[reply]
I think this is very important to the framing though. The question needs to be worded in a way that it's clear what it's proposing. My best idea is to change it to something like Do any other advanced rights that can currently be assigned (such as rollback or patroller) require access to temporary account IP addresses to perform those roles? If not, should access to this user right still be required to be considered for access to those roles? The problem is that this doesn't break out any roles individually. But it makes clear that A -> B, but that we could also decide to do B even without A, if there's a good reason for it. -bɜ:ʳkənhɪmez | me | talk to me!02:36, 11 June 2025 (UTC)[reply]
I thought that's what we were doing here was workshopping the potential RfC. If, on the other hand, you're suggesting that a more full/structured workshop would be necessary for those questions, I would tend to agree - I don't particularly care whether it happens before or after an RfC, but I do think that my proposed questions would allow the RfC to gauge consensus for some roles (ex: there may be a consensus that administrators must be able to be trusted with this role, even if they don't want/use it) and more clearly show which (if any) others should have further discussion. -bɜ:ʳkənhɪmez | me | talk to me!19:23, 11 June 2025 (UTC)[reply]
I think the original question was to give TAIV to everyone who has RB/NPP (TAIV dependent on RB/NPP). This proposed question fundamentally reverses the original question, it makes RB/NPP dependent on TAIV. —CX Zoom[he/him](let's talk • {C•X})03:06, 11 June 2025 (UTC)[reply]
Whether the right is a necessary prerequisite for NPP or rollback is the same question as whether or not being approved for [the] right should be a necessary requirement for NPP or rollback. voorts (talk/contributions) 02:25, 11 June 2025 (UTC)[reply]
I think the framing is important, to put emphasis on the different scopes of tasks that different volunteers undertake. I'm not sure everyone considers these two questions equivalent (even if we do). isaacl (talk) 02:29, 11 June 2025 (UTC)[reply]
The difference I intended is that the current question 3 is written from an approval process perspective, while my question is about the workflows of new page patrollers or rollbackers. As I think the answer to question 3 is a direct consequence of the answer about the workflows, my personal preference is to just directly ask the workflow question. But I appreciate that it's likely most people will consider the underlying question. isaacl (talk) 02:42, 11 June 2025 (UTC)[reply]
Well, if rollback and reviewer is combined with Taiv, it will be better as Rollback & reviewer are almost used together by everyone. It'll be helpful against vandalism. Also, most of the patrollers are also rollbackers. Since, IPs can't create pages the Taiv isn't that much required for NPP as I have never seen an IP being revealed of a sock or it's sockpuppeteer. Ɔþʱʏɾɪʊs⚔04:33, 11 June 2025 (UTC)[reply]
Peeps regularly edit logged out to perform bad-hand-good-hand sockpuppetry. Also, as I mentioned somewhere, NPP folks regularly deal with un-BLARing and have the ability to approve AFC drafts both of which often require knowing about IP ranging (I know a particular Ipv6 range really used to like unblarring CASTE articles). Sohom (talk) 16:38, 11 June 2025 (UTC)[reply]
Actually, that raises a interesting question, could AFC reviewing (without NPP) seen as a "demonstration of need" ? Sohom (talk) 16:39, 11 June 2025 (UTC)[reply]
This is a complete red herring. I don't dispute your claim that in some scenarios TAIV access will be useful when new page or recent changes patrolling. But that doesn't mean you must force every new page or recent changes patroller to have that access; some will follow your logic and find themselves wanting it, others won't. * Pppery *it has begun...04:22, 14 June 2025 (UTC)[reply]
I still think having AFC, NPP or rollback is a demonstration of a need for TAIV, but yeah based on your statements, 2,4 and 5 are probably what what I'll be supporting. Sohom (talk) 08:39, 17 June 2025 (UTC)[reply]
General discussion
Note the new right also requires that the user make an edit or a logged action in the last 365 days in order to retain the right. This should be listed as one of the minimum requirements. isaacl (talk) 02:05, 11 June 2025 (UTC)[reply]
That's a reason for revoking the right, not a requirement to grant it. An editor doesn't have to use the right once granted, but if they don't use it once per year, they lose it. voorts (talk/contributions) 02:27, 11 June 2025 (UTC)[reply]
My reading of the policy page is that they do not ever have to use the right - they simply can't have been wholly inactive (no edit or logged action in any log) for a year and keep it. -bɜ:ʳkənhɪmez | me | talk to me!02:29, 11 June 2025 (UTC)[reply]
I think it would be helpful to mention, though, so people can keep it in mind when considering if holding the right should be a requirement to be a rollbacker. (My understanding is also that its an activity requirement, not a requirement to use the right occasionally.) isaacl (talk) 02:45, 11 June 2025 (UTC)[reply]
The MW page has too much information that could be overwhelming for the average RfC participant. The RfC should include the most important points about how temporary accounts differ from current IP system in one or two paragraphs, because I do think that most people do not know the differences. Thanks! —CX Zoom[he/him](let's talk • {C•X})02:31, 11 June 2025 (UTC)[reply]
Hey everyone, I wanted to share that I'm reading the discussion, but I'm not active here because the discussions on wikis where we may/will deploy later this month take precedence. Other people on the team also focus on work needed to be wrapped before these deployments. But in July, we should be more available for you. Thanks for understanding.
Thank you for this, it was definitely useful. I can think of a few things that may need to be covered in the help page:
1. Global abuse-filter-manager and abuse-filter-helper are entrusted with TAIV by default, are the local EFMs and EFHs not covered or is it a mistake?
2. If someone begins a browser session on an IP, and later changes the IP, will it create a new TA or the old TA be updated with later IP?
3. When IPs get blocked, will the log and block reason be visible to non-TAIVs?
4. Will a block on an IP to restrict only the temporary accounts also restrict access to permanent accounts on that range?
5. Will users who voluntarily uncheck the Special:Prefs setting to remove TAIV need to request an admin to return the right to get it back, or re-checking the setting will enable it? If the latter, what if they became inactive (no edits/logs in 1 year) post-removal of TAIV?
@CX Zoom: I can actually answer number 1, it appears intentional. It is worth noting though that EFMs/EFHs do have access to edit filters with IPs in them, as they have abusefilter-access-protected-vars. They would also almost certainly be eligible for TAIV, since most EFM/EFHs heavily exceed the minimum requirements, the only real difference would be that the global versions have ipinfo-view-full and checkuser-temporary-account-auto-reveal. The former gives more information about IPs (which can ultimately just be looked up via any number of off-wiki services), and the latter just allows revealing the IPs of all temporary accounts in a page for a set duration, which can be accomplished manually. I would though, be interested in whether SGrabarczuk (WMF) would be able to comment on whether WMF has a stance on whether ipinfo-view-full can be granted to other groups (ie: local EFH/EFM), or whether it is strictly for sysops/bureaucrats. EggRoll97(talk) 02:31, 19 June 2025 (UTC)[reply]
1. Global abuse-filter-manager and abuse-filter-helper are entrusted with TAIV by default, are the local EFMs and EFHs not covered or is it a mistake?
A: No strong reasons behind this decision. Like @EggRoll97 says, EFMs and EFHs should generally qualify for TAIV based on the granting criterion. We were err-ing on the side of caution when designing the policy (granting the right to those who definitely need it rather than all privileged editors). If you think EFMs and EFHs should have this access, can you please articulate why this is useful?
2. If someone begins a browser session on an IP, and later changes the IP, will it create a new TA or the old TA be updated with later IP?
A: The temporary account will not change if the IP address changes. Temporary accounts are tied with a browser cookie. They will persist until the browser cookie expires or 90 days pass (whichever is earlier).
Further, one temporary account can map to multiple IP addresses. It is not a 1:1 relation. Users with the correct permissions will be able to see all IP addresses associated with a given temporary account.
3. When IPs get blocked, will the log and block reason be visible to non-TAIVs?
A: Yes. No change will be made to the visibility of log and block reasons for IPs. You can see examples of this on nowiki where temporary accounts have been live since November 2024.
4. Will a block on an IP to restrict only the temporary accounts also restrict access to permanent accounts on that range?
A: Blocks on an IP that are soft blocks (do not target logged in users) will affect temporary accounts and will not affect permanent accounts. Blocks on an IP that are hard blocks (do target logged in users) will continue to affect permanent accounts as before and will also affect temporary accounts.
5. Will users who voluntarily uncheck the Special:Prefs setting to remove TAIV need to request an admin to return the right to get it back, or re-checking the setting will enable it? If the latter, what if they became inactive (no edits/logs in 1 year) post-removal of TAIV?
A: Users who voluntarily uncheck the preference to give up TAIV will be able to simply re-check it to gain it back. If users who have been manually granted access do not make any edits or logged actions within a year, they will lose TAIV and will have to re-apply for the right through the local community process. This limitation of 1 year of inactivity will be technically implemented so the community does not need to worry about monitoring and taking away these rights after a year of inactivity. NKohli (WMF) (talk) 10:41, 19 June 2025 (UTC)[reply]
Further, one temporary account can map to multiple IP addresses. It is not a 1:1 relation. Users with the correct permissions will be able to see all IP addresses associated with a given temporary account. This is the key thing which makes TAIP so dangerous. Imagine a scenario where I sequentially edit from my home, my school, my church, my local sex toy and cannabis emporium, and my secret lover's home. And all of those locations are served by free WiFi service with highly detailed mappings in the WHOIS, DNS and geolocation databases. Being able to connect all those locations to a single user (and that user's editing history) is frightening. This is why we need to be careful who we give this permission to. RoySmith(talk)13:19, 19 June 2025 (UTC)[reply]
We perhaps ought to make it explicit to editors that temporary accounts will reveal their real-world location (in some cases as precisely as an individual building) to a (potentially) large number of people, but for permanent accounts this information is available only to a very small number of highly trusted individuals who may access it only in specific circumstances. Thryduulf (talk) 13:51, 19 June 2025 (UTC)[reply]
No. What RoySmith is describing is a possibility not a certainity, most geolocation and ASN mappings are fuzzy enough that you'll know that I live in a specific region of North Carolina, not the exact house/cannibis emporium/starbucks/fast food restaurant I edit from. Educational institutions might have their own self-identifying ASNs (I know NC State has one), but a laptop (which I assume is the device in question, since it has a stable TA cookie but is roaming around) is rarely assigned a stable IP that is able to narrow it down to a single building. (TLDR: I think in 90% of cases you will not reveal any more data than what you would already have done through IP editing). Sohom (talk) 14:15, 19 June 2025 (UTC)[reply]
@Sohom Datta You are correct that the severity of sorts of exposures vary. But, I would expect you in particular (based on the data security articles I've seen you write) to understand how the ability to cross-correlate multiple data sets exacerbates the problem. It's one thing to know that you're in a region of North Carolina. But what if I can connect that to knowing which university you go to, what brand of coffee you like to drink, what brand of car you drive (based on the IP you pick up while you're sitting in the dealership waiting for your oil change), which brand of phone you use, which mobile data carrier you use, which airline you fly on, which countries you've visited, etc. By cross-correlating all that (and more), you can really start to narrow the set of people who could possibly be using a TA. There's one LTA I track (as a checkuser) who I know is a student (or employee, I guess) of a particular university half a country away from where they live. There's another who I managed to narrow down to one of a couple of hundred people by seeing when they showed up in an unusual location where a wikipedia event was being held. The ability to make these kinds of correlations should not be handed out lightly. RoySmith(talk)14:41, 19 June 2025 (UTC)[reply]
I agree with your characterization of the danger (and I am more-than familiar with the problems associated deanonymization through privacy leaks :). The major thing I wanted to address was Thyduulf's comment of framing the user-facing message as "this information will reveal who you are to us" vs "the information that you give us could be used to track you down to a terrifying close approximate of who you are". We should definitely have a explainer page in the Wikipedia namespace describing what can happen (and potentially link it from a notice), but we should also make it clear to folks that this is a possible attack scenario and not something that is exposed to users by default (and needs investigation/work on the part of the users tracking the TA to accomplish). Sohom (talk) 15:19, 19 June 2025 (UTC)[reply]
We can (and should) publish warnings like that, but realistically, nobody is going to read them. As for the potential limit of resolution being an individual building, consider the possibility of a university which provides wired internet service to all their dorm rooms and sets up their DNS with names like room307.random-hall.residential.big-university.edu. Don't laugh; that's exactly how we did it when we rolled out internet service to our dorms when I worked at big-university. That was a long time ago, when we were all a lot more naive about privacy issues. I would hope nobody's doing that these days, but you never know.
Keep in mind that edits are timestamped. So not only does TAIP give you a list of places a person has been at, it gives you some hints about when they've been at those places. There's far more frightening things you can do by cross-correlating this kind of data, but I'm not going to mention those in public. RoySmith(talk)14:19, 19 June 2025 (UTC)[reply]
@NKohli (WMF): Sorry, I should have been slightly clearer, I'm asking whether the WMF has a stance on whether the ipinfo-view-full right can be added to privileged local groups that are not sysops or bureaucrats, given that it doesn't actually give temporary account access if someone does not have the TAIV group, but only gives more information in IPInfo about a temporary account. For example, all autoconfirmed users have the ipinfo-view-basic right, which gives very basic information about an IP address (I believe the version, approximate location, and ISP, though not data through Spur/MaxMind), while the ipinfo-view-full right gives more extensive information. The right itself is redundant without access to TAIV, but would provide more information for users who might not be in a sysop/bureaucrat group locally, but may also be benefitted from this additional information being given. I can think of other groups of people, such as SPI clerks, who might benefit from the right being added to other local groups. EggRoll97(talk) 23:08, 19 June 2025 (UTC)[reply]
On the proposed RFC questions in general, I think that the question should be one (not multiple), and that it should be simplified. Basically, we want to ask "Do we want the default standard?" and then explain that "the default standard" is to comply with the requirements set by WMF Legal (300 edits, 6 months, not blocked, must personally request the user right, etc.). We would set up a page similar to Wikipedia:Requests for permissions/Rollback, and individual admins will either accept or reject the applications and assign the user right.
Editors who oppose the default approach should comment on what they'd like to see. We'll have another RFC to choose between suggested higher options.
This is simpler because "just do it the normal way" (a common result) doesn't involve answering multiple questions that ultimately may not be relevant. WhatamIdoing (talk) 02:55, 15 June 2025 (UTC)[reply]
Well, I'm neither opposing nor supporting this for now. But, we may require more than 1 question to approach a consensus clearly. If I had to make an addition, I'd also ask a question if we should add the more criteria similar to Rollback & if (rollback), (reviewer) or (patroller)should be bundled. Ɔþʱʏɾɪʊs⚔05:28, 15 June 2025 (UTC)[reply]
As I understand things, it can't be added to an existing group because it needs to be asked for specifically, so it can't be bundled in that way. However I've not seen anything to suggest that if someone asks for and is given TAIV that they can't also be given other rights they didn't specifically ask for at the same time as long as they meet the criteria for those other rights. Thryduulf (talk) 01:57, 17 June 2025 (UTC)[reply]
@WhatamIdoing I'm not referring to TAIV being combined with others, but others being with it. The rule is it can't be added to other groups, not that others can't be combined in this group, just like sysops having all the tools along with the tools others don't have like (protect). Ɔþʱʏɾɪʊs⚔06:34, 17 June 2025 (UTC)[reply]
This sounds like hairsplitting.
According to the comment above, the user right must be requested, assigned, and accepted separately. Whether we "add TAIV to Rollback" or "Add Rollback to TAIV" doesn't make any actual difference for the purpose of this apparent rule. WhatamIdoing (talk) 07:11, 17 June 2025 (UTC)[reply]
The main difference is that rollback has a less strict criteria because of which it's easier to obtain for newcomers, while TAIV isn't. So, it's one of he reasons why TAIV can't come with rollback. But, TAIV will be more required for vandal fighting so I proposed adding rollback to TAIV than vice-versa. Still, it's just a proposal and not necessary rule. It's for the community to decide, if it's required or not. Ɔþʱʏɾɪʊs⚔08:04, 17 June 2025 (UTC)[reply]
So, as users not having TAIV can't see IP address, then I wonder if we should set up a page, where other users can request if 2 temporary accounts are linked just like Sockpuppet investigations as TAIV user would be like a half checkuser? Ɔþʱʏɾɪʊs⚔10:53, 18 June 2025 (UTC)[reply]
Narrowed RfC proposal
Are there any objections to proceeding on this RfC?
I've taken a look at the various documentation put together by the WMF, as well as the comments in the discussion above, and I've condensed the question about minimum standards and determined that we need to answer the following questions fairly immediately so that we can begin granting the right when it rolls out:
Question 1: Should we adopt the minimum or heightened standards for TAIV? If the latter, please specify. Question 2: Should we authorize any of the following actors to request revocation of TAIV upon evidence of misuse of the right?
Option A: the Arbitration Committee or its delegates
Option B: a consensus of (i) functionaries, (ii) 'crats, or (iii) admins
Option C: individual (i) functionaries, (ii) 'crats, or (iii) admins
I think we should continue discussing the NPP/rollback issue, which might involve a broader discussion of those rights in general and should require notice to NPP, anti-vandalism pages, etc.
The WMF is removing public access to IP addresses and replacing them with temporary accounts (this will not affect historic IP addresses). Temporary accounts are tied to browser cookies, which are set to expire three months from the first edit. This means that they will be different across web browsers and devices. The WMF has determined that temporary accounts are necessary to protect user privacy, comply with legal requirements, and maintain the ability to edit Wikimedia sites anonymously.
The WMF has also created a new user right for access to temporary account IP addresses, which has come to be known as temporary account IP-viewer (TAIV). The minimum criteria for editors (other than functionaries, 'crats, and admins) seeking the user right are:
minimum account age of 6 months and 300 edits;
specifically applying for access;
opting in for access via Special:Preferences; and
"[a]gree[ing] to use the IP addresses in accordance with these guidelines, solely for the investigation or prevention of vandalism, abuse, or other violations of Wikimedia Foundation or community policies, and understand[ing] the risks and responsibilities associated with this privilege".
By "historic IP addresses", I assume you mean IP addresses already in the edit history? ("Historic" makes me think of legendary IP addresses ;-) If so, perhaps the text could be reworded? isaacl (talk) 05:23, 19 June 2025 (UTC)[reply]
In the discussion above, the only new requirements that were proposed were boosting the edit count to 500 and not allowing blocked/banned users. I highly doubt anyone will come up with other requirements that will have any kind of chance of gaining any kind of consensus. voorts (talk/contributions) 19:19, 19 June 2025 (UTC)[reply]
Inclusion of supranational unions, blocs or regions in country GDP lists
So, I just happened to chance upon the end of an AfD on a certain forked list, which, incidentally seemed to be created a couple of days after a suggestion that I think may have been misinterpreted (as an aside, I think a takeaway here could be that one should be possibly excessively specific when suggesting to new users they create an article). In any case, this seems to be a dispute that has been something that pops up every so often (see, RfC on the idea 3 years ago and the rest of that archive page for that matter). As Fram mentions, we do have a number of various GDP lists, of which the per capita lists (nominal, PPP) notably have had the EU included (I haven't checked the history or the other lists or anything). While I don't think another RfC would actually settle things for good, I feel like it might be worth a try to decide on a consistent format, for example, always excluding entirely, creating the series as part of a separate "supranationals" page, including in a separate section. Alpha3031 (t • c) 16:42, 11 June 2025 (UTC)[reply]
The TL;DR is I suppose I'd like to solicit opinions on what the best way to represent supranational bodies in these financial lists is, so that we can have some best practices to refer to. This specific discussion being a bit of a pre-RfC discussion to workshop potential options, form and scope, etc. Alpha3031 (t • c) 16:48, 11 June 2025 (UTC)[reply]
The EU is a unique political structure, not easy to compare to other supranational bodies, and simplifying the question to including it alongside a hodgepodge of other supranational bodies, which are not monolithic with relevance to GDP either would not be beneficial. As for a wider scope, it would be premised on the idea that the inclusion criteria of every GDP-related list is the same, which I wouldn't take as a given. CMD (talk) 16:50, 11 June 2025 (UTC)[reply]
Why restrict this to GDP lists? If the source we're using for a list of countries by X includes one or more supranational unions then it seems to make sense to include it/them in the list. If the source doesn't include any such entities, then obviously our lists shouldn't either.
I'm looking at GDP lists mostly because that was the dispute that ended up at AfD. There are also apparently some pretty weirdly written lists in there (e.g. List of countries by GDP sector composition, with multiple changing criteria in each of the sublists) Also, I just realised I posted this at WP:VPP instead of WP:VPR where I was meaning to... oops? Probably should not have done this as the last thing in my day. I do agree, re CMD, that the EU could be seen very differently from most other supranational bodies or regions, which means that (assuming I/we don't end up deciding to drop one or the other) it might need to be an RFC with two (or more) sections... I'd definitely want to spend some time on workshoping so it doesn't end up being a mess. Alpha3031 (t • c) 17:04, 11 June 2025 (UTC)[reply]
Over the years statistical lists frequently appear at AfD; the key differential is the sourcing and how the lists are constructed. Where the sourcing is secondary analysis speaking of the class, then NLIST is usually satisfied. Where the list contents are extracted directly from a database, then it's usually a case of original research and/or synth. I would be less worried about a general rule regarding the subject of the data (supranational bodies etc), and more focussed on whether reliable secondary sources speak of the class. Regards, Goldsztajn (talk) 00:23, 15 June 2025 (UTC)[reply]
Pre-RFC workshop: Expected sourcing requirements for list of works
This recently was an issue of discuss at WT:ITN but appears representative of a larger scale lack of consistency, in how we are expecting the sourcing in a list of works for a biographical subject to be presented for a quality article when it comes to processes like ITN and other main page items as well as FA/GA.
For ITN, when we have recent deaths, many creative persons that are nominated on their death have what's been considered substandard because their filmography or discography or other list of works lack sourcing for most of the entries. This generally prevents the death from being included on the Recent Death line (recent example Guy Klucevsek), and has been a point of consternation at the talk page because it seems too impermissive for many bio articles. But then today, with Brian Wilson's death, it was noticed by one user after it was posted that the list of works there too lacked sourcing, and it was likely posted too quickly to be noticed given the rest of the article appeared to be in good shape. (Since its posting someone has been searching to fill out the necessary refs for the filmography). And then it was pointed out in the same discussion that today's FA, Mariah Carey, which was reviewed as a FA in Dec 2024, also lacks sources for the list of works, both on her bio page and on the separate list of work pages. So clearly the entire project doesn't seem on board with what seems to be the appropriate level of sourcing that should be applied to lists of works.
The one place where there is some advice is at MOS:LISTOFWORKS which says Complete lists of works, appropriately sourced to reliable scholarship (WP:V), are encouraged, particularly when such lists are not already freely available on the internet. If the list has a separate article, a simplified version should also be provided in the main article. The word "encouraged" is a far cry from "required" so its hard to say that the MOS forces this. One could also add BLP and WP:V here, where removal of unsourced information is generally encouraged, but that usually is reserved for contentious content and not things that are likely factually true but just need a source.
Note that I am only focusing on what we are considering to be quality articles, and not articles in progress. Ideally, editors will improve biographies to meet what is determined to be the expected quality prior to taking an article to GA/FA or any other process that requires a quality article, but until the GA/FA or other process is actually started, these can still be considered works in progress and we should not be trying too hard to force such corrections.
So there's a potential RFC here, but I don't know what the framing is. Right now, I think its best to ask this in several questions to determine what the next steps are, if an RFC is even needed or what question(s) it might need to be about (Using subsections so each point can be addressed). If you think there are additional questions to these, please feel free to add them as a separate subsection. Masem (t) 00:40, 12 June 2025 (UTC)[reply]
Does each item in a list of works need to be sourced?
Does each item in a list of works need to be sourced? (See next question as to what qualifies as a source). Note that I would consider a single reliable source that supports the bulk of the list to be acceptable for use as a header line into such a list or table (eg text like "Unless otherwise noted, sourcing for works is based on this source."), so that we aren't repeating one source 40 or 50 times over, but satisfying the need to source each work. --Masem (t) 00:40, 12 June 2025 (UTC)[reply]
Thanks Masem for starting this discussion. Since I first raised this issue a year ago, I've changed my stance. I'm now more of the school that for the vast bulk of uncontentious items in a list of published works we do not need a source. To quote Chubbles: A published work proves its own existence. It is a strange irony that we can use an album to verify the details of a song or songs (for example see List of songs recorded by Kylie Minogue or The Queen is Dead) but would require a source to verify the album itself on a different list of works. Since that discussion a year ago, I've had this wording saved as a possible start point for changed guidelines at MOS:LISTOFWORKS:
In general, a published work verifies its own existence and therefore an inline citation is not necessary for basic information in lists of works. To allow for easy verification, editors should provide as much identifying information for the work as possible such as year of publication, publisher, ISBN or record catalogue number. Manuscripts, obscure publications or limited editions which are not widely available in libraries or catalogues may benefit from a reliable source for verification. For additional information that is not found in the published work itself such as sales numbers, awards, uncredited appearances or other details that are likely to be challenged, an inline citation to a reliable source is appropriate.
ISBNs work for books, because they can be linked to {{ISBN}}, which leads to a database where the source's existence can be verified. Would audio/video sources use something like {{Cite AV media}}, and would providing one of the identifier parameters provide something similar? A non-subject matter expert should be able to verify that, yes, this work was produced by this person. For comparison, a sports bio is not allowed to assume that a reader knows where to go to verify a player's unsourced statistics, and a link under "External links" is not accepted. —Bagumba (talk) 07:37, 12 June 2025 (UTC)[reply]
Re record catalogue numbers: these seem to be a rarity for musician articles. In fact, usually swept away if they appear in infoboxes. Currently ITN/RD postings are often held up by demands for every record to be supported by a WP:RS source i.e. discogs.com not allowed. Martinevans123 (talk) 08:41, 13 June 2025 (UTC)[reply]
Each item should be cited. In my experience, bulk citations do not tend to earn the presumption that they support the bulk of the list (to say nothing of what threshold indicates "the bulk"). The other thing is that the list can grow after the citation is added, with no review whatsoever as to if the works are cited. I would personally put the threshold for ITN at something like 80%, and it is the rare single source that supports that much of a list. GreatCaesarsGhost12:42, 12 June 2025 (UTC)[reply]
I don't think we should have to have an independent citation where authorship is verifiable from the work itself -- e.g. if someone is credited as an author on the cover of a book, or named in the cast in the credits of a film. Where there's some complicating factor (e.g. the work was published anonymously or pseudonymously), then we need a second source to mediate. This is in line with MOS:FICTION, where plot summaries of fictional works do not need independent citation, because it is reasonably assumed that they are cited to the work itself and make no claims other than those that can be verified using only that work. UndercoverClassicistT·C13:17, 12 June 2025 (UTC)[reply]
I never understood how MOS:FICTION carved out that exemption. I don't see football matches being allowed to be unsourced because there is game footage, or a political debate allowed to be sourced solely to video. If I look at Wikipedia:WikiProject Books/Non-fiction article, it seems the ISBN would be, at a minimum, under release details. —Bagumba (talk) 07:20, 13 June 2025 (UTC)[reply]
I think it's because if you are reading Alice's Adventures in Wonderland#Plot, and you wonder whether the book supports it, you can walk into basically any library or bookstore in the world with the information in the first sentence of the article, and they know exactly how to find the book in question. With a game, it's unclear whether game footage exists (sometimes yes, sometimes no; obviously more often yes for professional games), and it's unclear how you would find it. WhatamIdoing (talk) 23:48, 16 June 2025 (UTC)[reply]
In general, no, I don't think published works need independent references to prove their existence. Although ideally there would be some method of verification (such as ISBNs or a published catalog). Of course, it's another matter entirely for unpublished works, unreleased recordings, and other cryptic or apocryphal material. These would require sourcing. And the mere existence says nothing about notability of either the work itself or of the person or entity that made the work. older ≠ wiser12:15, 13 June 2025 (UTC)[reply]
I want to add to this that we need to consider not just "easy" cases where we're talking the author of a book or the musician on their album. A very common case is when we have actors that do guest/one-time roles on television series. That is something you cannot simply look at the TV series itself and immediately identify the role. Masem (t) 12:41, 13 June 2025 (UTC)[reply]
As I understand it, the distinction being proposed is that credited roles (which I imagine we would define as named in the credits within the work can be cited to the work; uncredited or pseudonymous roles would need a secondary source. UndercoverClassicistT·C13:39, 13 June 2025 (UTC)[reply]
This requires that the work has easily verifiable credits. A book you can verify the author by looking at the cover, a TV programme you need to get access to (which might not be possible) and watch to wherever the relevant credit is (which might be the start, the end or the point at which they make their first appearance). We also need to be able to distinguish between roles that are verified as appearing in the credits to the work, roles which are not so credited and have not been verified in secondary sources, and roles for which verification has not been attempted. To take a random example, how do I determine whether Michael Sheard is listed in the on-screen credits of Remembrance of the Daleks? Thryduulf (talk) 14:35, 13 June 2025 (UTC)[reply]
I don't see a difference between this and verifying other sources -- how do I know that any sentence on Wikipedia is genuinely supported by the cited source? I have to check, or find someone who can. The policy reminds us that Do not reject reliable sources just because they are difficult or costly to access. Some reliable sources are not easily accessible. For example, an online source may require payment, and a print-only source may be available only through libraries. Rare historical sources may even be available only in special museum collections and archives. If Remembrance were a lost episode, we might say that a secondary source were needed, but this seems like an edge case to me. UndercoverClassicistT·C14:40, 13 June 2025 (UTC)[reply]
I was meaning how can I tell whether a role without an accompanying source is verified in the credits to the show, not verified in the credits to the show (and thus in need of a secondary source but not explicitly tagged as such) or whether nobody has determined whether or not it is verified in the credits? Thryduulf (talk) 14:52, 13 June 2025 (UTC)[reply]
This is where WP:V comes into play that we should not make it excessive work on the reader to find verifiable information. Just as we would not source a fact taken from a 1000-pg book without actually mentioning a narrower section or explicit page for that information, telling the reader to go find a specific episode and read through its credits is not helpful either. This is compounded at times that some roles go uncredited, as well as for a recurring character, the specific episodes are not usually named in our biographical articles. Masem (t) 12:51, 14 June 2025 (UTC)[reply]
Can we require some "proof" that the work is merely difficult/costly to access vs. being non existent? There are certainly many early movies and television shows that no longer "exist." Vandals could create fake ones that could not be proven or disproven. Can something unattainable except by illegal means like the The Mysterious Benedict Society (TV series) cite itself? GreatCaesarsGhost16:29, 16 June 2025 (UTC)[reply]
Film and television have either opening or closing credits (I suppose there are avant-garde exceptions) so its not the same as citing the entirety of a 1000-page book and expecting people to find a short passage. We already have {{Cite AV media}}, after all. Lost media or uncredited appearances are the exact type of thing that would need an independent source for verification - which I think I covered in my wording above. If an item is challenged or cannot be verified it should be removed or an independent source found as per editing in any other area. TV, film and, I suppose, radio/podcasts do present some issues as lists of works usually will list an entire series rather than individual credited performances. Vladimir.copic (talk) 00:56, 18 June 2025 (UTC)[reply]
However, even in a film article, we do not presume acting credits per the movie itself, we use reliable sources (eg, WP:FILM's FA example is The Dark Knight). Maybe during the development of an article not sourcing credits (both on a bio page and on a works page) is reasonable because of the self-obviousness, but when we talk quality, which is the focus here, sourcing doesn't seem to be optional. Masem (t) 02:46, 18 June 2025 (UTC)[reply]
I was never clear how comprehensive FA and FL were w.r.t. MOS, e.g. does WP:FACR only include the MOS items at 2a, 2b, 2c, or MOS in its entirety? For example, I've seen FAs and FLs that fail MOS:ACCESS, but I've never followed up with WP:FAR or WP:FLCR. —Bagumba (talk) 03:52, 18 June 2025 (UTC)[reply]
They should adhere to ACCESS, but as with other MOS it's probably easier to just fix it or post on the talkpage, FAR/FLCR I'd save for something more serious. CMD (talk) 04:13, 18 June 2025 (UTC)[reply]
FAR/FLCR I'd save for something more serious: Agree, what I meant was that I was never sure if MOS:ACCESS and other MOS areas were under the purview of the FA/FL, and haven't followed up. —Bagumba (talk) 04:29, 18 June 2025 (UTC)[reply]
I still believe that asking the reader to go find a film and watch the credits to validate is not a good approach to sourcing. It leads to 1) editors adding every minor actor that had a role in the film, eg "Man in crowd"-type credits. and 2) can lead to editors sneaking in false info that no one will bother to check for less known persons. However, film and television pages are less the problem compared to what the expectation is for sourcing on a biography page, which is the focus of this discussion. Its why, as alluded to a question lower down, that we shouldn't rely on what is reported at a blue-linked work, because a reader isn't going to find the source there either. Masem (t) 04:15, 18 June 2025 (UTC)[reply]
I also see that the FA examples were all promoted over 10 years ago, so it's possible that consensus has changed re: sourcing in that time. That said, WP:OTHERSTUFFGENERAL might apply, even for FAs. —Bagumba (talk) 04:33, 18 June 2025 (UTC)[reply]
I mean...perhaps. But by the same measure, nobody has challenged them in ten years. Here's one promoted in December 2023: October 1 (film). Asking someone to look at a credit sequence is probably less onerous than asking someone to read a book or article. (The words move for you. No need to turn pages!) If there is an accessible written source - well add it! I don't think anyone is arguing you shouldn't if you want to. I just think this particular argument regarding cast lists in film articles doesn't hold water. I can see more of an issue with television or radio credits for lists of works concerning actors etc. Vladimir.copic (talk) 05:00, 18 June 2025 (UTC)[reply]
I think if we go back to your proposed wording of (emphasis added) To allow for easy verification, editors should provide as much identifying information ..., I can live with being able to quickly verify that this work exists, and AGFing that Joe Smith is somewhere in the credits. That's akin to how we deal with offline sources. But are there equivalents to ISBN for other media where verification of the work's existence can be easily achieved? —Bagumba (talk) 05:18, 18 June 2025 (UTC)[reply]
Asking someone to look at a credit sequence is probably less onerous than asking someone to read a book or article. (The words move for you. No need to turn pages!): That's where I expect page numbers or time stamps. —Bagumba (talk) 05:21, 18 June 2025 (UTC)[reply]
I think there is a difference between lists of works where the person in question is the author or sole author and lists of works where someone is making an appearance or a co-author in a collective work. The former is a lot simpler (I'm assuming you would not expect a page reference to the front cover of a book or album?); the latter is more complex - though still pretty easily verifiable by looking at the work itself (credits, liner notes, contents page) and is currently practiced all over the project. In terms of unique identifiers, published albums and singles usually have catalogue numbers. As far as I know, not so much for movies - when books reference movies in-text they usually just follow a Title (year) format, sometimes listing the director too. Chicago says: Name of director, Title, Location, Production Company, Year of release. Vladimir.copic (talk) 05:56, 18 June 2025 (UTC)[reply]
For movies, there's certainly more AGF possible with English box-office releases. How to handle smaller productions that are harder to verify, or non-English titles that many en.wp editors are not as familiar with. For quality standards, would it be systemic bias to scrutinize the works differently? —Bagumba (talk) 06:15, 18 June 2025 (UTC)[reply]
I think that wp:ver provides good guidance (except for it's missing sentence). Inclusion on a list is an implicit statement that it is one of their works. (Only) if challenged, a source for that implicit statement must be provided. Otherwise not. The missing sentence in wp:ver is that challenges should be based on and include an expression of concern about verifiability/veracity. Not just sealioning to knock out something that somebody doesn't want covered. Sincerely, North8000 (talk) 13:13, 14 June 2025 (UTC)[reply]
Meh… if someone sealions, just plop in a citation. Much quicker and less stressful than arguing that a source isn’t required. Blueboar (talk) 13:30, 14 June 2025 (UTC)[reply]
@Blueboar: That's not really responding to what I said. Which would be just a process expectation to express a good faith concern when doing that. No need to argue the concern, and in any event that would then be irrelevant.....WP:Ver would strictly and simply apply. And BTW, it's usually not as simple as you say because, sealioning is often used in synergy with wikilawyering against thesource that is then provided. And even that is fine if there is good faith concern expressed. North8000 (talk) 19:41, 19 June 2025 (UTC)[reply]
What is considered an appropriate source?
Most of the time, we look to have a normally reliable source be the source to support an item on a list of works, like a biographic article or obituary. But we also allow for some unique cases, like for any published book, the ISBN number is usually sufficient, as from my understanding, because Wikicode makes this point to WorldCat which is considered an authority, and authorship is directly obvious from there. Same with most published journal articles with items like DOI numbers. But when we get to films, music, and other media forms, that type of database doesn't seem to exist. Eg: IMDB is not a reliable source for films despite that being the industry's standard per WP:IMDB and there is not anything professionally maintained like WorldCat.
Related to that, for works that are independently notable (blue-linked), where the person's role is self-evident from the blue link, is that sufficient? By self-evident, we're talking the information you'd find on the proverbial cover - Its self-evident that Michael J Fox and Christropher Lloyd starred in Back to the Future II (it is spelled on the film's poster and the article lede), but you'd have to dig to say that Elijah Wood also was in the film, so that would not be a case of self-evidence for a blue-link. Is this appropriate for these self-evidence blue-likes (which can simply a lot of issues with these lists), or are we violating "Don't use Wikipedia itself as a citation" when we rely on blue links? --Masem (t) 00:40, 12 June 2025 (UTC)[reply]
Relying solely on the presence of a blue link is counter to WP:CIRCULAR:
Do not use articles from Wikipedia (whether English Wikipedia or Wikipedias in other languages) as sources, since Wikipedia is a user-generated source ... Content from a Wikipedia article is not considered reliable unless it is backed up by citing reliable sources. Confirm that these sources support the content, then use them directly.
Yes, but one hopes both that experienced editors will do the right thing themselves (i.e., add sources) and also that they don't make a spectacle of themselves by pretending that they can't possibly determine whether basic facts about Back to the Future II are verifiable because there's "only" a link to a Wikipedia article and no little blue clicky number in this article. In such cases, if refs are wanted in this article, there's nothing stopping you from adding a citation to the film yourself. WhatamIdoing (talk) 23:57, 16 June 2025 (UTC)[reply]
Sure, WP:PRESERVE is a policy. I wasn't advocating to make a spectacle. A volunteer might decide to tag it, an alternative to deletion, but similarly nobody should demand that they fix it themselves instead. —Bagumba (talk) 05:53, 17 June 2025 (UTC)[reply]
While I sometimes find and add a reliable source for unsourced content I come across, if I went off on a (often fruitless) search for a reliable source for every unsourced item I see, I would never have time to do anything else. I try to avoid deleting unsourced content unless I am fairly sure it is untrue or irrelevant to the article, but if it is something I think sounds plausible but I cannot confirm from my personal library or a reasonable I-net search, then I will leave a content needed tag in hopes that someone will have a clue on where to find a reliable source supporting the content. Donald Albury14:30, 17 June 2025 (UTC)[reply]
Does sourcing need to be in the main article for list of selected works if there's a separate, full list of works that is properly sourced?
If we have a separate list of works from the main bio article, should the main article have sourcing when selected works are repeated there? Similar to the above question, can we rely on the blue link to the full list of works, presumed to be properly sourced to the degree we expect, or should the selected works be sourced appropriately too, which often can be done just by reusing those sources? --Masem (t) 00:40, 12 June 2025 (UTC)[reply]
I am not aware of any summary style that is immune from sourcing requirements. EG: if I am summarizing a spin-off article in the one it originated from, I'm still bound to include the sources to support it. Which is why I think that in this scenario, sourcing from the split list needs to be reused in the main. Masem (t) 12:45, 12 June 2025 (UTC)[reply]
Yup… remember that Wikipedia is dynamic… articles can and do change. So, while X might be mentioned (and cited) in “another article” today, future edits to that “other article” might result in X (and/or its citation) being removed. Thus, it is important to repeat the citation in every article where X is mentioned. Blueboar (talk) 13:07, 12 June 2025 (UTC)[reply]
That's a 2024 discussion, so it looks ok to start this here. Feel free to note any significant points from there that are not already in the MOS. —Bagumba (talk) 06:26, 12 June 2025 (UTC)[reply]
The "Reactions/Responses" section
One of the most useless sections of articles about a (usually recent) event is the "Reactions/Responses" section. No one wants to know that the leader of some uninvolved country had "expressed condolences" for an XYZ event. I propose that there should be a MOS that prevents the addition of the reactions/responses (i.e., a tweet on x or whatever govt website a country uses) from countries uninvolved/irrelevant to the event. It's just bloat 𐩣𐩫𐩧𐩨Abo Yemen (𓃵)11:50, 13 June 2025 (UTC)[reply]
I completely agree that routine condolences from random famous people are utterly useless bloat but responses in the form of concrete actions taken as a result of the incident can be encyclopaedic. The essay Wikipedia:Reactions to... articles (written by Fences and windows) however suggests that the community is not united in this view. Thryduulf (talk) 12:02, 13 June 2025 (UTC)[reply]
One of the worst things that has been added for any event, particularly when most of the reactions are along the lines of "thoughts and prayers" and not in any way of any actions or commitment for action made in response (eg along the lines Thyduulf is saying). We should be writing for a long-term point of view, so just listing non-action reactions, or at least not distilling these into brief lists (eg "The attack was condemned by many nations, including X, Y, and Z" is far better than sentence after sentence) is not encyclopedic, and better at a Wikinews article than en.wiki. Masem (t) 12:15, 13 June 2025 (UTC)[reply]
That's the thing. This section thing should be treated in the same way we treat the "Supported by" param of the infobox: Consensus must be reached in every article to include that section 𐩣𐩫𐩧𐩨Abo Yemen (𓃵)15:19, 13 June 2025 (UTC)[reply]
I don't generally oppose Reactions/Responses sections, but I would support guidance against including routine condolences/condemnations/statements of support, especially when it ends up being a bulleted list that seems to attract flagcruft. Firefangledfeathers (talk / contribs) 15:24, 13 June 2025 (UTC)[reply]
It's a pretty classic result of WP:RECENTISM, as various reactions are going to be in a lot of immediate news content. It is usually bloat. However, it's also usually not worth fighting against. Like other aspects of current event articles, it's easier to treat it as something to take a new look at down the line. CMD (talk) 15:26, 13 June 2025 (UTC)[reply]
We have a larger problem that editors write breaking news articles as if we're a newspaper rather than an encyclopedia, these reaction sections are just part of that problem. We really do need to try to get back to writing current events as encyclopedic summaries, and if editors really want to write to the level of detail of news, that Wikinews is a far better venue for that. Masem (t) 02:57, 14 June 2025 (UTC)[reply]
I agree, there just hasn't seemed to be a great solution to the problem. Who knows, it may even be something that draws in editors. CMD (talk) 07:29, 14 June 2025 (UTC)[reply]
This strikes me as something that is best to deal with on an article by article basis. In historical articles, such sections are very useful. For example, today's TFA contains a section mostly devoted to contemporary reaction, here--Wehwalt (talk) 15:47, 13 June 2025 (UTC)[reply]
I think the issue is less the abstract concept of covering reactions, and more the usual bulletpoint newsline that tends to grow in current event pages. CMD (talk) 16:27, 13 June 2025 (UTC)[reply]
If someone was born in 1610 in the Duchy of Lorraine, we should not say they were born in France (although we might say where they were born is now France), or if they were born in an area of Silesia in Germany in 1935, we should not say they were born in Poland. We should reflect the political reality of the time. I think this also generally means we should call places Rhodesia/Dahomey/Gold Coast/Burma/Siam/Ceylon when those were their recognized names. I am not sure the date Burma becomes Myanmar is as clear as the others. However we would use Pinyn Romanization for places at a time when most in the west were using the Wade-Giles system. In some cases it is useful to tell the reader where a location is now, or what the place is now called (the later comes up a lot with educational institutions), but we still should acknowledge the contemporary name of the place. We would not say someone was "born in Cathay" though. Even though at one time people in the west used the term. We would say the person was born in China.John Pack Lambert (talk) 17:50, 13 June 2025 (UTC)[reply]
I wouldn't call the "Reactions/Responses" sections themselves useless, but some of the content in them (e.g. reactions from random, uninvolved politicians, celebrities, companies, etc.) is indeed irrelevant and should be removed. Some1 (talk) 00:05, 14 June 2025 (UTC)[reply]
I agree with Some1. "There was an earthquake, and the President of Ruritania said something socially appropriate" is as useless as saying a grant-dependent scientist saying that Further research is needed. But there are things that can be useful and appropriate, like "There was an earthquake, and Ruritania sent refrigerated tanker trucks full of milk" or "There was an earthquake, and Ruritania thought the resulting confusion made a great opportunity to invade the country". WhatamIdoing (talk) 00:01, 17 June 2025 (UTC)[reply]
Reaction bloat should be removed but it would be better to pick battles worth winning. When something dramatic occurs, reactions are informative even if we are pretty sure it's just a tweet written by a PR hack. I would like a hidden template that activates in three months to say "Please remove WP:UNDUE bloat in this section". However, my advice would be to not fight plausible me-too additions when an event is current and everyone is excited. We rely on volunteers who come in all shapes and sizes and bludgeoning them with rules is not productive in the long run. Johnuniq (talk) 00:11, 18 June 2025 (UTC)[reply]
The problem starts because editors are adding every reaction they can find in the immediate wake of an event. Per NOTNEWS and RECENTISM, this is not necessary. Short-term reactions should be limited to actual actions or call to actions (eg a country leader offering their financial or manual support to help in the wake of a disaster), and avoid any of those that are just "feelings". In the long-term, if there is sufficient evidence and weight that the "feelings"-type reactions are important, then they should be added. We should be encouraging editors to be far more selective off the bat. Masem (t) 00:15, 18 June 2025 (UTC)[reply]
These sections resemble the "In popular culture" sections. When not effectively curated, such a section can attract trivial references or otherwise expand in ways not compatible with Wikipedia policies such as what Wikipedia is not and neutral point of view. Their inclusion should reflect their prominence in relevant literature. Hawkeye7(discuss)00:32, 18 June 2025 (UTC)[reply]
The most efficient long-term method we can use is to stop the creation of articles about every news story and cover developments in existing articles where all of the information can be maintained in once place. The vast majority of the time, we don't need an article about a bridge collapse when we can have a section on the collapse in the article about the bridge itself. That would make it much easier to manage bloat where integrating it into the article is already part of the editing process and it's more clearly undue. All we need is a simple "hi, thank you for creating the article about this event, we've moved the information to the article about that place". There. No bite, no bloat, no big deal. Thebiguglyalien (talk) 🛸00:47, 18 June 2025 (UTC)[reply]
I still need to get my larger discussion on trying to get us back to respecting NOTNEWS, particularly in the current climate today, but this is absolutely a problem, part of it being an implicit desire to have article ownership and be the one to create a new article, rather than add to an existing one. It makes editors run to create articles on every event before its clear whether it makes good sense for a standalone. Flooding such articles with pointless reaction sections is a way to make the event look more significant than it is. A bridge collapse without any significant damage or death toll is exactly the type of event that's better covered in the article about the bridge (eg: I-35W Mississippi River bridge, Tacoma Narrows Bridge) Masem (t) 04:20, 18 June 2025 (UTC)[reply]
... part of it being an implicit desire to have article ownership and be the one to create a new article ... I don't think it's usually a case of WP:OWN, per se, but there is a certain satisfaction in seeing "my" article. See the number of users displaying a list of their created pages. —Bagumba (talk) 06:02, 18 June 2025 (UTC)[reply]
I think I do manage to separate my desire for recognition for what I have done from exercising ownership over that work. That does require me to ocassionally bite my tongue. More to the current point, I spend days or longer (and in one case, 11 years) in developing new articles. I have, many years ago, started articles the same day I read something about the topic, but I now think that is a bad way to approach Wikipedia, and probably would support some way to slow down the process. As a wild idea, why not require new articles to be in Draft space or a user's sub-page for at least a day before moving to main space? That would force coverage of breaking news into existing articles for the first day. Donald Albury14:01, 18 June 2025 (UTC)[reply]
Hello, I've raised a question here about GFDL and was wondering if someone at Wikipedia could answer. I originally asked on the Main Page talk but was referred to here. Thank you! 2005-Fan (talk) 16:51, 14 June 2025 (UTC)[reply]
Non-free images should be permissible in draft space
Our current Wikipedia:Non-free content criteria prohibits the use of non-free content outside of article space, including in draft space. I think this is an error in law and practice, and that the policy should be changed to permit relevant non-free images in draft space to the same extent that it is permissible in article space.
Drafts are created for the purpose of eventually becoming articles, and ideally allow the entire article to be constructed, including images, so that it can be properly evaluated for suitability as an article. It is something of an annoyance that non-free images relevant to a draft currently can not be uploaded to Wikipedia at all until after the draft has been moved to mainspace.
With respect to intellectual property concerns, our prohibition on the use of non-free media derives from the limiting factors in the copyright doctrine of fair use, but that calculation does not militate against the use of such content in draft space, precisely because drafts are less visible to the public readership, and therefore present much less of a possibility for public presentation of copyrighted content. Because drafts are intended to become articles, they serve no less of an educational or journalistic purpose than published articles. I therefore think that our policy should specifically be amended to permit the use of non-free images in draft space to the same extent as they are permitted to be used in article space. BD2412T22:02, 16 June 2025 (UTC)[reply]
Ips and unconfirmed users - the only ones forced to use draftspace by the software (rather than just encouraged) instead of being able to create directly in mainspace - can't upload files locally either. Are you proposing to change that too? —Cryptic22:13, 16 June 2025 (UTC)[reply]
The relevant CSD criterion (F5. Orphaned non-free use files) contains the clause Reasonable exceptions may be made for images uploaded for an upcoming article. without any definition or examples of what constitutes a "reasonable exception" or "upcoming article".
If this proposal is successful then other parts of the criterion will need to be reworded from "article" to "article or draft" but that should be uncontroversial, especially as I'm about to alert WT:CSD to this discussion. Thryduulf (talk) 22:32, 16 June 2025 (UTC)[reply]
I oppose this proposal. There is enough content in draftspace already, and much of it is frequently deleted by WP:G13 or at WP:MfD. Allowing non-free images to be uploaded for drafts would increase the burden of maintenance on administrators, who would have to delete more non-free images when drafts containing them are deleted, and Files for discussion participants who would have to discuss the images when their draftspace use is disputed, for very little benefit that I can see. For this proposal to be beneficial, there would have to be a convincing case made that uploading and adding non-free images after an article has been moved to mainspace from draftspace is somehow inconvenient or otherwise undesirable, and I do not see a compelling case here. If someone really feels the need to have an image ready right now, users are free to save one to their personal device with notes on where it came from and your rationale, and put it to Wikipedia when the article is ready. silviaASH(inquire within)23:32, 16 June 2025 (UTC)[reply]
Suppose I save an image on my hard drive as you propose, and then work for months on a project-based draft like one of the MCU characters, and then once the draft is published as an article and I upload the image, someone contests the usability of that image in that article. Isn't it better to have the image vetted earlier, so that if it turns out to be unusable, there is time to find an alternative before the article is published? BD2412T23:47, 16 June 2025 (UTC)[reply]
If you really feel the need to make sure an image is suitable for the article, then you can go ask someone and link them to the image in question. However, generally speaking, fair use images uploaded by experienced editors are rarely contested, so I just don't see this realistically being an issue, especially for such a standard use case as showing what a character looks like in the infobox. This proposal feels like a solution in search of a problem. silviaASH(inquire within)00:33, 17 June 2025 (UTC)[reply]
@SilviaASH "If you really feel the need to make sure an image is suitable for the article, then you can go ask someone and link them to the image in question.", Why would a new editor submitting a draft think to ask (where?) about a non-free image? They'd (at best) follow our existing guide to upload it locally, and at worse upload it to wikimedia commons. JackFromWisconsin (talk | contribs) 03:58, 18 June 2025 (UTC)[reply]
Well, I don't know. But this isn't a new editor proposing this policy change, it's an established editor and administrator who explicitly asked, Suppose I save an image on my hard drive as you propose, and then work for months on a project-based draft like one of the MCU characters and I responded to their question saying what I personally think they should do. I would recommend the same to a new editor, probably, but I wouldn't expect a new editor to know, which is of course why I'd tell them. silviaASH(inquire within)04:20, 18 June 2025 (UTC)[reply]
For files used elsewhere linking should suffice, might still be good to write the justification in advance could be converted by script when the page is accepted. For the more common case of a file that is only suitable for use on that one page, yeah that's thornier. One could tweak F5 to make any images linked on a draft covered under the upcoming article exception, but ultimately the nonfree images could sit in limbo for quite some time, which is rather undesirable.
Well, if an article is entirely unsuitable for the encyclopedia (a notability or NOT fail) without a picture, how can a picture make it suitable? And vice versa, if an article topic is notable, and not otherwise barred, won't that be judged by the text and sources, not a picture? (As an aside, we already practically publish drafts in main space, in that they are likely to be further edited, sometimes continuously edited long after publication.) Alanscottwalker (talk) 22:43, 16 June 2025 (UTC)[reply]
For that inquiry, it doesn't matter whether the work is in draft space or article space (with unsuitable things being created in article space all the time). In image, at least, demonstrated the degree to which the subject can be illustrated. BD2412T23:31, 16 June 2025 (UTC)[reply]
It may or it may not -- the 'wrong' image won't show that, under eg. irrelevance, misinformation, disinformation, misleading, confusing, or otherwise poor image selection/placement. And in draft space there are fewer editors to catch it. -- Alanscottwalker (talk) 14:10, 17 June 2025 (UTC)[reply]
What we clearly don't want is the allowance to have non-free images in draft space articles that never progress to main space, even if there was good faith intention to get it there and the editor lost track/left Wikipedia/host of other reasons. This is clearly set by the intent of the WMF resolution from 2008 on non-free content use. But I can understand the desire to have a brief period where the article is one or two steps away from going to mainspace to upload and populate non-frees before its moved to make sure that other factors (like facing, sizing, etc.) I don't know if we can set it up with the bots, but to allow a 7-day period for a non-free to be used in a draft (with the bot adding necessary warnings on the talk page), after which the bot can remove the non-free from the draft, and if that's the only use, to start the 7-day speedy deletion timer on the non-free content itself (effectively giving a 14-day window). We'd need to have the non-free rational included to what the target main page is and the bot smart enough to check a draft-space version if the mainspace article doesn't exist or just a redirect. But this all requires that the bot(s) can be set up to do this. Masem (t) 00:32, 17 June 2025 (UTC)[reply]
I would be okay with this. I still don't see myself ever taking advantage of this if it were implemented, but this sounds like a fair way to implement this without any significant increase in maintenance overhead. silviaASH(inquire within)00:38, 17 June 2025 (UTC)[reply]
Not having looked at the source for the bot which removes nonfree images from drafts (courtesy ping its owner), I'd say it'd probably be relatively easy to get it to only remove an image if it shows up on the same non-mainspace page for seven daily runs in a row, or however frequently it runs. That's not the problem.The problem is what to do when the draft's author immediately puts it back in, which will happen, and will happen very very frequently. Do you just not deal with it and wait another seven runs? Then the grace period for having non-free images on drafts is infinity days instead of seven. Take it off again the next run? Then you have to keep track, forever, of which images have been removed from which drafts, detect when it's a different image or draft that just happens to have the same name, etc, which starts being not so easy pretty fast, plus now your bot is effectively edit-warring. Log it for the bot op to deal with manually? Then you still have to keep track of it forever, plus the bot op has to deal with it manually, which isn't what he signed up for. —Cryptic01:58, 17 June 2025 (UTC)[reply]
If someone is going to game the system that way, a way to verify what's going on is to make sure the bot logs all such draft image identifications, ideally tallying how many times an otherwise unused non-free image is being added to a draft. If that goes above 2 or 3 times, that should be flaggd to an admin to see if the user is actually gaming the system or if there's a legit reason for this, and take appropriate action. Masem (t) 03:11, 17 June 2025 (UTC)[reply]
I'm going to stary by saying I 100% understand our NFCC and the legal basis for them. That said, I tend to agree with OP that there is no legal distinction between a "draft" and an articlespace article. If an image qualifies as fair use in legal terms does not depend on where it's used. It depends on the circumstances of that use. I would be shocked if a court determined that an image would be fair use on a website but not on the same website just because of how that website internally calls that page. As such, I don't see any legal reason to prohibit NFCC from being expanded to allow it to be used on at least one article or draft article. That all said, my view here is obviously based on there being no WMF legal objection to this, since ultimately it's their lawyers that would have to defend anything. -bɜ:ʳkənhɪmez | me | talk to me!03:37, 17 June 2025 (UTC)[reply]
Its less of a legal issue in this case and more the explicit instructions from the WMF resolution that non-free should only be used for encyclopedic content (for the purposes of minimizing non-free use and supporting the idea that WP is a freely-licensed work), which is why we've always limited it to use in main space (no user spaces, no talk pages, etc.) Draftspace is not mainspace, but because the content is intended to eventually go into main space, there are some reasons to make allowances for it, but at the same time, draft space also frequently ends up as a graveyard for unfinished articles, so we don't want non-frees sitting there unused. Masem (t) 12:42, 17 June 2025 (UTC)[reply]
Yes, but non frees if not used in mainspace are to be deleted in a far shorter time frame (7 days normally). Plus one could game this by touching the draft every 5.9 months. If we are going to allow nonfrees in drafts for purposes of finalization before a move to mainspace, their use must be strictly limited to that purpose and thus a need to have nots help assist here (or not allow it all, the current situation) Masem (t) 17:11, 17 June 2025 (UTC)[reply]
The non-free content criteria are fairly horrible and have long needed an overhaul. We're here to build an encyclopaedia. We're not here to provide a library of free content for scrapers and reusers, that's Wikimedia Commons' business.
As a matter of principle, any file that we can legally and ethically use to build an encyclopaedia, should be allowable anywhere in the encyclopaedia. The NFCC should be rewritten to delete any rule that obstructs this goal.—S MarshallT/C08:53, 17 June 2025 (UTC)[reply]
Until the WMF changes their stance on non-free content use, we can't change NFCC that way. And using NFC is antithesis to the idea that WP is the encyclopedia that anyone can use and importantly, modify and redistribute. Masem (t) 12:39, 17 June 2025 (UTC)[reply]
You're right to say we can't get all the way there because of WMF obstructionism, but we can certainly push back the free content maximalists and swing the balance more in favour of the people who're actually here to write an encyclopaedia. Wide latitude to publish fair use images, where it's ethical and lawful to do so, in draft space would be a helpful step along the way.—S MarshallT/C13:28, 17 June 2025 (UTC)[reply]
Except that the WMF has said non free images can only be used with encyclopedic content, and while the content remains in draft space, draft articles technically are part of the encyclopedia. (for the same logic that drafts made in user space would also be a problem). I'm all for a short term allowance for non frees in draft space as long as their is a good faith attempt to bring the article to main space on a prompt manner, but a reality is that many drafts linger up to the six month limit without any effort after an initial burst to improve for mains pace. Hence allowing the use of nonfrees for a short time enforced with the help of bots seems a possible route. Masem (t) 13:42, 17 June 2025 (UTC)[reply]
No (resolution was 2008), but we did have the common practice of drafting in user space. And keep in mind en.wiki had established the NFC before the resolution was made, as early as 2005, established that non free should only be used in mainspace [1]. Masem (t) 16:04, 17 June 2025 (UTC)[reply]
Completely agree with S Marshall's comment above, and I disagree that it's important that the encyclopedia be freely modifiable and redistributable -- it should be "free as in beer" not "free as in liberty." I've never thought that letting anyone modify and use the content for any purpose should be a goal of Wikipedia.
But that aside, I think fair use in draftspace is a non-starter for legal reasons: one of the requirements of fair use is that use has to be limited, and allowing fair use content in draftspace would probably not be limiting enough. The difference between draftspace on Wikipedia, and a person's offline draft, is that Wikipedia's draftspace is published (on the web). There really isn't any need for images in draftspace at all -- placeholder images are a perfectly fine substitute -- so it's probably hard if not impossible for fair use images in draftspace to meet the "necessary" or "minimal use" requirements of fair use law. I don't think WMF Legal would ever allow it for this reason. (If they did, then fine, let's do it.) Levivich (talk) 16:11, 17 June 2025 (UTC)[reply]
It's less of a WMF legal than the main WMF board position that all works they host support reuse and redistribution outside en.wiki, so seeking to reduce the reliance on non free contents aids on making the work as reusable as possible. The specfics on how we document non free is more to bolster the fair use defense that would be a legal issue if challenged. Masem (t) 17:06, 17 June 2025 (UTC)[reply]
@Levivich: I have practiced intellectual property law since 2005, nearly as long as Wikipedia itself has existed. I am very confident that no court would ever look at content on Wikipedia and say that it would be fair use in mainspace, but not in draftspace. That is not a distinction of any legal weight at all. If anything, draftspace is less susceptible to copyright infringement claims because it is not indexed, and therefore cannot be found through regular search engine usage. I would also note that in its now-decades of existence, virtually all legal challenges to Wikipedia's use of images have centered on images asserted by Wikimedia to be in the public domain, and by the other party (whether a national museum or just a man who set up a camera for a monkey to take pictures) to be covered by copyright. BD2412T01:25, 18 June 2025 (UTC)[reply]
Right, between the WMF resolution and the NFC and existing enforcement, we are very unlikely to see out non free image use challenged on copyright infringement.
The factor that focusing on the legal side skips is the goal in WP to be a freely reusable and redistributable encyclopedia, and the use of non free endangers that. That's the essence of the WMF resolution. (it's why we call it a non free content policy to put emphasis on the licensing issues, a fair use policy which would be towards the legal side). Because of that goal, we purposely limit when non free can be used to prevent abuse of non free images not associated with encyclopedic content. Masem (t) 13:16, 18 June 2025 (UTC)[reply]
Exactly so, and obviously, the purpose of this discussion is to establish whether that rather extreme level of free content maximalism still enjoys consensus, or whether in the alternative the community might feel we could allow encyclopedic images in draft space where it would be lawful and ethical to do so.—S MarshallT/C15:30, 18 June 2025 (UTC)[reply]
And to stress, I would be willing to allow such use in draft space for a very limited time frame (a week) with the good faith assumption this is to prepare for moving to main space. Masem (t) 16:25, 18 June 2025 (UTC)[reply]
Not taking a stance one way or the other on what is legal or optimal, but I will note one point of frustration that this is likely to cause: Articles For Creation. A person with a conflict of interest who is using that system cannot tell how long it will be between the editing and the approved moving into article space, anmd even the last-minute adding of NFC before submission could have the images disappear before approval. Then if the page is approved, restoring the NFC presents COI problems. -- Nat Gertler (talk) 16:18, 19 June 2025 (UTC)[reply]
As I have indicated, I don't think the "suitability" argument is very good, as suitability will be judged by text and sources. But balancing that against the apparent desire to do it and the credible claim that a 'completed' draft that is 'good' does not run afoul of 'fair use' in almost all cases, how about an 'intended to be published 'in main space within 48 hours' (to be enforced by a bot if possible or ordinary editing enforcement) while maintaining the ban in draft-BLPs (just because less eyes will be on a draft). Alanscottwalker (talk) 12:49, 18 June 2025 (UTC)[reply]
One example where something like this would be helpful is when an article has to be re-created after being blanked for copyvio reasons. Files which are quite legitimately used in the deleted article get deleted in the time it takes to re-create the article in draft/temp space. An example is No. 144 Squadron RAF - The main article was blanked on 11 May 2013, was recreated on a sub page on 12 May 2013, but was not reviewed by an admin and returned to mainspace until July that year, by which time the non-free image used in the original article had been deleted. While this was a considerable time ago, would this still occur, and would this proposal avoid the problem?Nigel Ish (talk) 17:54, 19 June 2025 (UTC)[reply]
Eliminate the term "scientific evidence"; it only promotes fringe
It's helpful to provide evidence when proposing a huge change to policy. In any event, your proposal will never be adopted. Policy and guidelines are meant to provide broad rules for how to edit. They are not generally used to ban particular turns of phrase.
If there are issues in particular articles, you can feel free to boldly edit that article or discuss it on the article talk page. If editors are being disruptive, go to the appropriate noticeboard. voorts (talk/contributions) 18:47, 19 June 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Nearly every time that the term "scientific evidence" appears in an article, it is being used disingenuously to imply that another kind of evidence exists (or might exist) when in fact there is no such possibility. The almost universal implication when someone writes "no scientific evidence" is "... but I have a fringe theory to promote; just look at the attractive non-evidence available from various sources!".
In rare situations, "scientific evidence" could be used legitimately, for example to distinguish it from evidence presented in court or some other real category, in an article where such a distinction is relevant; that should be an exception to what I'm proposing.
My proposal is that the term "scientific evidence" be deprecated on all of Wikipedia, to be replaced by the single word "evidence" (with the exception I already mentioned for making a legitimate distinction between science and law, or other fields in which the word "evidence" really does have a separate meaning, if there are any). I especially DO mean that medical topics should get a wholesale replacement of the words "scientific evidence" with just "evidence". (Alternative medicine does not have its own kind of evidence - either it uses the scientific kind or it uses none.)
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.
Technical
Simple summaries: editor survey and 2-week mobile study
PROJECT ON HOLD
The WMF has heard the strongly negative feedback from editors, put the project on hold, and responded a few times further below. Let's move discussion down to those smaller subsections. —Ganesha811 (talk) 19:03, 13 June 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Hi everyone! I'm writing on behalf of the Web Team. Over the past year, the team has been exploring ways to make the wikis more accessible to readers globally through different projects around content discovery. One of the ideas we’ve been discussing is the presentation of machine-generated, but editor moderated, simple summaries for readers. These summaries take existing Wikipedia text, and simplify it for interested readers. Readers will show interest by opting into the feature and clicking to open the summary on pages where it is available. As part of our exploration into this idea, in the next two weeks we will be launching:
1. An editor survey on English, Spanish, French, and Japanese Wikipedias. This survey will ask editors on their preferences for generating, editing, and moderating summaries, as well as their thoughts on the project overall. We will use the data from this survey to propose the initial moderation workflows for a future version of a summary feature.
2. A two-week experiment on the mobile website. This experiment will allow a small set (10%) of readers to opt into and open pre-generated summaries on a set of articles for two weeks. After two weeks, we will turn the experiment off and use the data collected to determine whether users are interested in summaries and open them frequently, as well as whether summaries aid the overall experience.
After the completion of these two steps, we’ll be publishing our results on the project page and reaching out to discuss whether to proceed with building this feature and provide some options for its associated workflows for editors. You are welcome to leave questions around the project here or on the project talk page. EBlackorby-WMF (talk) 18:20, 2 June 2025 (UTC)[reply]
@EBlackorby-WMF But seriously. I'm grinning with horror. Just because Google has rolled out its AI summaries doesn't mean we need to one-up them.
I sincerely beg you not to test this, on mobile or anywhere else. This would do immediate and irreversible harm to our readers and to our reputation as a decently trustworthy and serious source. Wikipedia has in some ways become a byword for sober boringness, which is excellent. Let's not insult our readers' intelligence and join the stampede to roll out flashy AI summaries. Which is what these are, although here the word "machine-generated" is used instead
You also say this has been "discussed" which is thoroughly laughable as the "discussion" you link to has exactly one participant, the original poster, who is another WMF employee. Cremastra (u — c) 22:04, 2 June 2025 (UTC)[reply]
What a coincidence! I had just read this article (https://www.theverge.com/news/676933/gmail-ai-summaries-workspace-android-ios) a day ago and wondered if there would be a similar feature on Wikipedia. As long as this machine/AI-generated summary feature is opt-in, I don't see any downsides to having it available for interested readers. The attention spans of the younger generations are shrinking, and some would rather read a short summary of the World War II article than a 13,033-word long article; this feature would be useful and beneficial for them. Some1 (talk) 22:43, 2 June 2025 (UTC)[reply]
All right, they're a reasonably short summary. In any case, even in articles with longer leads like Romeo and Juliet it is possible to skim over or ignore the parts that disinterest me and still extract valuable information. Cremastra (u — c) 22:51, 2 June 2025 (UTC)[reply]
AI-generated simple summary of Dopamine The lead of Romeo and Juliet isn't as long as the lead of World War II, which I'd linked. It seems like these AI-generated simple summaries are ~5 sentences long, which is much shorter (and more digestible) than the average leads of (non-stub) articles. Some1 (talk) 02:28, 3 June 2025 (UTC)[reply]
Also, concerns about this feature should focus on the "This summary has not been checked for verifiable accuracy" part, not because "it's AI". Some1 (talk) 02:39, 3 June 2025 (UTC)[reply]
The first paragraph is generally the digestible summary of the summary. This is enforced technologically in mobile views, which is where most of the view of the above-maligned younger generations are going to be coming from, as only the first paragraph is shown before the infobox. For World War II, that is six sentences. CMD (talk) 04:58, 3 June 2025 (UTC)[reply]
@Some1 I only have experience with the beautifully named c4ai-aya-expanse-32b but I'd describe it as almost "on the level of OpenAI". Which is where a lot of companies are at. It refuses to tell me that I am wrong, even when I am intentionally saying stuff that is clearly incorrect. It says things like You're right; the poem I generated does indeed draw inspiration from the well-known and beloved "duck poetry" genre. Polygnotus (talk) 03:10, 4 June 2025 (UTC)[reply]
Some1, summarizing contentious articles and how that will almost certainly be exploited and weaponized by partisan actors is something that interests me too. For interest, see this recent query from a reader, where they appear to either a) assume that we control Google knowledge panels and/or b) that we should amend the wording to ensure the part they regard as important fits into the summary. It is the first time that I have seen something like this. Sean.hoyland (talk) 07:54, 4 June 2025 (UTC)[reply]
@Some1 For what it's worth, we can in fact see how Aya summarized the Zionism article, because it's in the set of summaries that readers would have seen. You may be asking yourself, how did one of the most contentious geopolitical topics in existence get into the summary set that "[made] an effort to exclude controversial, inappropriate or legally libelous material"? Great question!
Theodor Herzl started the Zionist movement in the late 1800s, dreaming of a Jewish state. Zionism wanted Jews to have their own land, free from European persecution. They chose Palestine, an area important in Jewish history. At first, they considered other places, but settled on Palestine, which was then part of the Ottoman Empire. This led to the Israeli-Palestinian conflict. The goal was to create a Jewish majority in Palestine, and after Israel's independence in 1948, Zionism became its national ideology. Zionism has different groups with varying views, but all support a Jewish homeland in Palestine. Some see it as a return to their ancient home, while others criticize it as colonialist.
Leaving aside any other issues here: Does that first sentence seem weird to you? That's because the LLM has confused the article caption with the actual article. Gnomingstuff (talk) 20:40, 10 June 2025 (UTC)[reply]
Thanks for the link, Gnomingstuff. That Zionism summary doesn't look too bad for an AI-generated simple summary imo. Some1 (talk) 22:46, 10 June 2025 (UTC)[reply]
@Some1 Well the first sentence is wrong. Herzl didn't "start" Zionism. "This led to the Israeli-Palestinian conflict" is wrong, because there are about 48 trillion factors that led to that conflict. It also leaves out some of the most important stuff (Balfour).
"creating a Jewish majority" is a weaselword for what many would describe as a genocide.
"Some see it as a return to their ancient home, while others criticize it as colonialist." is an oversimplification of an incredibly difficult topic where people have many opinions, usually stupid ones.
@EBlackorby-WMF Hi! As you can tell, your proposal does not align with what the community actually wants.
As you may or may not be aware, the WMF and the Wikipedia community have a very difficult and tense relationship.
It sounds like you guys already did a lot of work, without getting input from the community.
You link to this with the text we’ve been discussing but that must've been an internal WMF discussion because no one responded to that post.
Perhaps the Movement Communications team forgot to actually communicate with the movement?
I recommend stopping, and in the future asking for feedback at a far far earlier stage (but of course I know you won't).
There are many people here who are happy to help you by saying why we dislike certain ideas. But you need to involve those people at an early stage (during brainstorming), otherwise it is difficult to change course and you've wasted a lot of time and energy.
The WMF as a whole makes this same mistake over and over and over again. If you want to hear all the downsides and problems with a proposal, you can ask me on my talkpage. Polygnotus (talk) 05:15, 3 June 2025 (UTC)[reply]
Did a lot of work even go into this? It takes all of 5 minutes to set up the world's 327482th ChatGPT wrapper claiming to be a brand new feature. It feels slapdash and easy for them to throw up and it's such an insult to the community. 🌸wasianpower🌸 (talk • contribs) 04:20, 4 June 2025 (UTC)[reply]
The replies above may be missing the point. Imagine you were a WMF staffer. Would you want to fix boring bugs or would you want to work on AI for your CV? Johnuniq (talk) 05:49, 3 June 2025 (UTC)[reply]
Imagine you were a WMF staffer. Would you want to fix boring bugs? Hell yes I would. Have you seen my contributions here on en.WP? All I do is fix boring bugs so that our readers and editors get the pages, links, text, and images that they expect, with a minimum of errors. The WMF needs more gnome developers. – Jonesey95 (talk) 12:56, 3 June 2025 (UTC)[reply]
@Polygnotus: The joke in my reply is that I did work for the WMF from 2012 to 2020, and fixing boring bugs and working on the Action API are things I did. I also worked on Scribunto, TemplateSandbox, TemplateStyles, Special:ApiSandbox, and a bunch of other stuff. But eventually I wound up with a manager who seemed primarily interested in trying to climb the management ladder (yay kiss up kick down), and in general office politics became a bigger and bigger requirement, and eventually they fired me, no real reason given. Even if they'd be willing to rehire me, I hear the office politics have continued to get worse since so I still might not fit in anymore. Anomie⚔00:03, 4 June 2025 (UTC)[reply]
I would want to fix longstanding bugs too, and while as a volunteer I'm probably not as dedicated as Jonesey95 I actually did apply for a job with the Wikimedia Foundation and got an interview but was turned down. * Pppery *it has begun...15:31, 3 June 2025 (UTC)[reply]
"While we were impressed with your qualifications and experience, we have decided to proceed with other candidates". No other detail, and I didn't ask. I don't think "by whom" is a useful question to ask; the email I got was from a member of the recruiting team but I'm sure she wasn't the one actually making the decision. * Pppery *it has begun...15:37, 3 June 2025 (UTC)[reply]
Cui bono? Is there some financial incentive to make this decision which, from our point of view, doesn’t make any sense? I mean for the foundation as a whole, not any individual working there. I’m trying to understand where the pressure to do this is coming from. 3df (talk) 02:45, 4 June 2025 (UTC)[reply]
@3df, believe it or not, there are people out there who think this kind of thing is useful, and a great many of them work in development. No ulterior or secret motive is necessary to explain it. -- asilvering (talk) 02:47, 4 June 2025 (UTC)[reply]
@Asilvering Agreed. Although it would be very very beneficial for the AI company to have people correcting the output of their AI for free. They normally have to hire people to do that job. Polygnotus (talk) 02:50, 4 June 2025 (UTC)[reply]
Nope, I don't want an additional floating window of content for editors to argue over. Not helpful or better than a simple article lead. ꧁Zanahary꧂06:36, 4 June 2025 (UTC)[reply]
Keep AI out of Wikipedia. That is all. WMF staffers looking to pad their resumes with AI-related projects need to be looking for new employers. Carrite (talk) 16:01, 3 June 2025 (UTC)[reply]
I'm glad that WMF is thinking about a solution of a key problem on Wikipedia: most of our technical articles are way too difficult. My experience with AI summaries on Wikiwand is that it is useful, but too often produces misinformation not present in the article it "summarises". Any information shown to readers should be greenlit by editors in advance, for each individual article. Maybe we can use it as inspiration for writing articles appropriate for our broad audience. —Femke 🐦 (talk) 16:30, 3 June 2025 (UTC)[reply]
But 99% of the AI consumers knowingly interact with is trained on Wikipedia, so they don't need wikipedia.org for that. So the WMF is proposing making a shittier version of something that already exists. Polygnotus (talk) 16:49, 3 June 2025 (UTC)[reply]
It would be good if we had our own version of it, where we could control what is shown and how it is shown, instead of having a for-profit company modify our content as they please with no way for anyone to do anything about it, and no free and open alternative. Matma Rextalk17:39, 3 June 2025 (UTC)[reply]
That appears to be based on a bunch of incorrect assumptions. It is not like a nuke, we don't need to have it just because others do.
we could control what is shown and how it is shown Being able to set a system prompt is not control, you'd have to train your own model, which means either copyright violations on a massive scale or training on model exclusively on Wikipedia data, meaning it would be completely inferior to what is available.
instead of having a for-profit company modify our content as they please with no way for anyone to do anything about it Have you read WP:REUSE? This is what you signed up for.
and no free and open alternative What are you talking about? Anyone can download ollama. https://ollama.com/ The WMF does not have the money and brainpower required to develop a serious alternative to the existing models, and if they try that is a clear indication that they don't understand their role. But the screenshot says that the name of the model is Aya. Aya is a family of models by Cohere Labs. https://cohere.com/research/aya Which is a for profit company. Polygnotus (talk) 18:10, 3 June 2025 (UTC)[reply]
@Polygnotus Your comparison to nuclear bombs seems out of proportion.
Being able to set a system prompt is not control I don't mean a system prompt, I mean the user interface around the summary (see the mockup earlier in the thread, with ample warnings and notes, and compare it to the summary in Google or whatever else) and I mean the editorial control to hide or override these summaries if they're egregiously wrong, which I hope will be available if this experiment becomes a real feature.
Have you read WP:REUSE I think it's a bit rude of you to imply I don't know what I'm talking about. Anyway, have you seen how the content is actually presented by the various LLM companies? They don't generally cite content as they should (and not just from Wikipedia), and as far as I can tell no one yet has managed to force them to do it.
What are you talking about? Anyone can download ollama Famously, everyone on the planet has a computer able to run large language models, and will not mind waiting several seconds or minutes for the results to come out. Oh, wait. Local models are only a viable alternative for a small group of people.
I don't think you replied to what I said, only to things you imagined I said. I'm happy to argue for a bit, but please slow down. Matma Rextalk21:01, 3 June 2025 (UTC)[reply]
They don't generally cite content as they should (and not just from Wikipedia), and as far as I can tell no one yet has managed to force them to do it. DuckDuckGo does these days. Izno (talk) 21:06, 3 June 2025 (UTC)[reply]
I mean the user interface around the summary (see the mockup earlier in the thread, with ample warnings and notes, and compare it to the summary in Google or whatever else) and I mean the editorial control to hide or override these summaries if they're egregiously wrong, which I hope will be available if this experiment becomes a real feature. People do not read banners and warnings, see Banner blindness. You can never make a banner big enough to force people to read it. override these summaries if they're egregiously wrong Even the example they provided is already egregiously wrong, of course they will be. Having humans override the after the fact is not a reasonable solution to a giant problem.
I don't think WP:REUSE is a very popular page, and there are tons of people who don't realize that basically anyone can copy anything from Wikipedia, and no one does anything about it, even if they do not follow the terms of the license.
have you seen how the content is actually presented by the various LLM companies? They don't generally cite content as they should (and not just from Wikipedia), and as far as I can tell no one yet has managed to force them to do it. Yes, I have, which is why my opinion is what it is.
Local models are only a viable alternative for a small group of people. agreed. You talked about no free and open alternative which is why I mentioned Ollama.
please slow down I mean if they really do this I think we've lost the war and I'll just leave Wikipedia. Or set up an alternative and then leave. Polygnotus (talk) 21:13, 3 June 2025 (UTC)[reply]
What war? Whose against whom? And what does MAD has to do with this discussion? Do you think we're building Skynet here or something? I am baffled and at a loss as to how to reply to this. Matma Rextalk21:18, 3 June 2025 (UTC)[reply]
You wrote what does MAD has to do with this discussion? in response to me writing The nuke thing is a famous example of game theory, see Mutually Assured Destruction for more. which was my reponse to Your comparison to nuclear bombs seems out of proportion in response to me writing It is not like a nuke, we don't need to have it just because others do.
One of the reasons many prefer chatGPT to Wikipedia is that too large a share of our technical articles are way way too difficult for the intended audience. And we need those readers, so they can become future editors. Ideally, we would fix this ourselves, but my impression is that we usually make articles more difficult, not easier, when they go through GAN and FAC. As a second-best solution, we might try this as long as we have good safeguards in place. —Femke 🐦 (talk) 18:32, 3 June 2025 (UTC)[reply]
@Femke You seem to ignore this comment where I explained that the WMF can't compete with AI companies whose core business is to develop AI models, the fact that a model trained exclusively on Wikipedia data would be far inferior to a model trained on a far far larger dataset, and the fact that they are using Aya. as long as we have good safeguards in place What do you mean? Polygnotus (talk) 18:37, 3 June 2025 (UTC)[reply]
As in: moderation before something is put to readers, rather than after the fact. Which would in practice restrict the feature to high-priority technical articles, given that we have limited editor time for this. I don't know enough about the specifics of Aya to comment intelligently there. —Femke 🐦 (talk) 18:42, 3 June 2025 (UTC)[reply]
@Femke I think you know that is not what the WMF is proposing. So your comments make no sense. we might try this They are not proposing that we try anything. They are proposing giving the most important screen real estate we have (the WP:LEAD) of every article to a for-profit company.Polygnotus (talk) 18:45, 3 June 2025 (UTC)[reply]
In the comment above, they say that the moderator workflow is still to be determined. You're probably right they don't have a 'check first' workflow in mind, but if there is consensus to implement this (and it seems from this discussion so far that there probably isn't), I imagine the community would only be okay with this with extremely strong moderation in place. Like, the CMD example below is something that needs to be avoided at all costs.
Perhaps, it's time to start a Wikiproject and some type of contest to fix the problem identified and ensure we write articles that people can actually understand. My Challenges seem not to work as an encouragement. —Femke 🐦 (talk) 18:52, 3 June 2025 (UTC)[reply]
You think people are lining up to check the work of an AI model? Especially when summarizing complicated technical topics most people don't even understand? Polygnotus (talk) 18:58, 3 June 2025 (UTC)[reply]
Just to be clear, I oppose the test of unverified AI summaries as is slated for next week to 10% of mobile editors (phab:T393940). The foundation cannot dictate content. —Femke 🐦 (talk) 06:49, 4 June 2025 (UTC)[reply]
A truly ghastly idea. In other words: Yuck. Since all WMF proposals steamroller on despite what the actual community says, I hope I will at least see the survey and that—unlike some WMF surveys—it includes one or more options to answer "NO". Yngvadottir (talk) 17:02, 3 June 2025 (UTC)[reply]
It sure looks like they are planning to ask casual readers who use the mobile app. And if you ask them, their answer would probably be "yes". But that doesn't mean that it is a good idea. And introducing AI summaries would probably lead to a fork and an exodus. I would honestly be shocked if AI is not the final straw in the relationship between the WMF and the community. Polygnotus (talk) 17:17, 3 June 2025 (UTC)[reply]
The survey linked below was much as I expected: almost nowhere to express disapproval of the whole putrid idea. Bonus: video without closed captions. Of text. On YouTube. Classy and inclusive. Yngvadottir (talk) 23:24, 3 June 2025 (UTC)[reply]
@Yngvadottir I really enjoyed the question about a An AI-powered dashboard that shows the quality and metrics for summaries for my wiki.
What is an AI-powered dashboard??? This was clearly written with someone who is unfamiliar with the capabilities and limitations of AI technology.
Also my wiki shows that they want to dump this trash on multiple wikis, despite the fact that everyone who speaks languages other than English and English knows how much worse the experience in another language is, compared to English. Polygnotus (talk) 01:57, 4 June 2025 (UTC)[reply]
Yea I saw that too. The survey that I did had nowhere for me to say that it was a bad thing. In fact there were even worse ideas listed there too, such as edits to summaries might not even be listed anywhere unlike edits to normal pages. 2007GabrielT (talk) 12:17, 4 June 2025 (UTC)[reply]
Laudable goal, but if it is to go through, it should be only if established editors, i.e. extended confirmed editors, decide if the generated summary can supercede the current lead, or decide that the generated content requires modifications before using. – robertsky (talk) 19:03, 3 June 2025 (UTC)[reply]
@Robertskyif the generated summary can supercede the current lead That is not what they are proposing at all... if established editors, i.e. extended confirmed editors, decide that is also not what they are proposing decide that the generated content requires modifications before using that is also not what they are proposing. Polygnotus (talk) 19:06, 3 June 2025 (UTC)[reply]
@Polygnotus, The lead is supposed to be the summary of the article. Why have another machine generated summary if the lead is doing the job? editor moderated is what they are proposing, and they asked for editors' preferences for generating, editing, and moderating summaries. So I am suggesting as such. – robertsky (talk) 19:17, 3 June 2025 (UTC)[reply]
@RobertskyWhy have another machine generated summary if the lead is doing the job? Are you asking me that? That is the WMFs proposal, and I am saying it is a bad idea...
Look at the screenshot. It shows both the current lead and the AI summary that contains multiple errors.
My brother in Zeus, Cohere Labs is worth billions. Do you want Wikipedia volunteers to work for them for free??? You do realize that AI companies hire people to do the work you seem to think should be done by unpaid volunteers?
A note that the WMF has begun requesting responses to surveys via the QuickSurveys extension, so some (like me) should get a prompt inviting you to the survey if enabled. Some of the questions... aren't great if I'm honest. – Isochrone (talk) 20:45, 3 June 2025 (UTC)[reply]
Since the WMF is willing to be this sneaky, I don't think we should feel guilty if we fill in the survey a couple hundred times. Polygnotus (talk) 21:04, 3 June 2025 (UTC)[reply]
Let's intentionally skew the results! The WMF intentionally skewed it by picking who to show it to; the community should skew the results to tell the WMF to stop trying to put AI in Wikipedia! Polygnotus (talk) 21:14, 3 June 2025 (UTC)[reply]
And then the legitimate consensus among the people who took the survey will probably be thrown out, requiring us to rely even further on RfCs and other community headaches. ⫷doozy (talk▮contribs)⫸23:20, 3 June 2025 (UTC)[reply]
If this were to actually happen, some or many readers would just glance at the summary instead of reading the article. Since the summary will form the glancers' entire impression of the subject, it needs to be extremely accurate. I suspect it is often not. Even if editor moderation helps this problem, you may as well just go to Simple English Wikipedia and get the same thing but actually made by humans. ⫷doozy (talk▮contribs)⫸20:54, 3 June 2025 (UTC)[reply]
Haven’t we been getting good press for being a more reliable alternative to AI summaries in search engines? If they’re getting the wrong answers, let’s not copy their homework. 3df (talk) 21:16, 3 June 2025 (UTC)[reply]
Oppose. We already have summaries of our encyclopedia articles: the lead sections of our encyclopedia articles are the summaries of the article. Also, Wikipedia is already a massive collection of great summaries, because writing an encyclopedia (tertiary source) is the skill of summarizing secondary sources such as newspapers and books. Also, our leads (summaries) are so good that Google and other search engines use them in their knowledge panels. Wikipedia and AI are in the same business (summarizing) and we humans at Wikipedia are better at it than AI. I see little good that can come from mixing in hallucinated AI summaries next to our high quality summaries, when we can just have our high quality summaries by themselves. –Novem Linguae (talk) 22:12, 3 June 2025 (UTC)[reply]
Thanks! So a planned deployment to 1% of readers on Monday 9 June, and then expanding to 10% of readers on Tuesday 10 June, and a possible further expansion on Monday 16 June. CMD (talk) 04:35, 4 June 2025 (UTC)[reply]
@Novem Linguae Do you happen to have access to that stuff hosted on Google?
Are we for real?? Just last week I noted to staff that any rollout of LLM content would be unacceptable to the community, and now we're suggesting integrating it into a core aspect of content? Leads are already a shortened version of a page. The best leads have been carefully crafted by dozens of editors and represent some of the best content in the world. Using LLMs to generate what is effectively a worse lead will only amplify problems like at Sambhaji (angry readers read a lead but not the body). Devs, please realize that we are not going to accept integrated LLMs, and stop wasting time on such boondoggles. I will strongly oppose the integration of this feature into EnWP or any other Wiki. Our reputation is on the line here. CaptainEekEdits Ho Cap'n!⚓23:09, 3 June 2025 (UTC)[reply]
Oh, and to be clear: I absolutely, categorically, totally oppose the 2-week testing period. I support removing it via site CSS, or just blacking out the site. Or better yet, the Foundation can back down from this foolish course of action. CaptainEekEdits Ho Cap'n!⚓23:22, 3 June 2025 (UTC)[reply]
I feel like people seriously underestimate the brand risk this sort of thing has. Wikipedia's brand is reliability, traceability of changes and "anyone can fix it". AI is the opposite of these things. Public sentiment (among some corners) is reacting against the AI trend quite harshly. Projects like this threaten the brand good-will that Wikipedia has based on its unique strengths. The current climate gives Wikipedia a unique opportunity to be the answer to the AI-ification of everything. Why are we throwing that away? Bawolff (talk) 00:17, 4 June 2025 (UTC)[reply]
I am going to join the chorus of editors saying that this is a uniquely bad idea. But I'll focus on one thing from the survey: generic readers should not be the ones who decide whether the AI summary is "helpful". If I come to Wikipedia because I want to know who founded the Roman Empire, and AI tells me it was Tiberius, I would be eternally grateful... until I find out that it was Augustus. I don't doubt that this was created with the best of intentions, but I really hope that the WMF spends its resources elsewhere (for example, fixing the remaining mobile communication bugs). HouseBlaster (talk • he/they)01:10, 4 June 2025 (UTC)[reply]
The use of AI today comes with a caveat that the "AI can be wrong" and "AI should not be trusted 100%". I am not saying that Wikipedia is 100% right, but Wikipedia should remain to be more reliable than whatever Grok or ChatGPT can write up. If we use AI, we would go down into their level of reliability, which I didn't think to be the best way to go. We have seen many people, both with good and bad intentions, have criticized the reliability of Wikipedia. Going down the AI route will only reduce our "perceived reliability" even more. ✠ SunDawn ✠Hail Me!01:20, 4 June 2025 (UTC)[reply]
Wikipedia’s perceived reliability has been climbing in recent years. To implement LLMs or similar generative AI would mean a massive decline in that perceived reliability we have tried so hard to build up. To add to you saying “AI can be wrong”, it is made to give different replies even when asked the same question. I don’t believe the replies should differ, it should give me what it believes to be most likely correct. It probably would be a part of each page that doesn’t change each time you visit unless it’s edited, but the actual generation is what I worry about. I would like to point out however that I already dislike AI in most contexts, and so am probably only considering half the argument. I am however trying to be sincere, as a casual reader of Wikipedia who relies on it for those random facts you find nowhere else, AI should not be used. 2601:985:4003:7E20:4DF9:E16A:EB9E:4BB9 (talk) 04:40, 9 June 2025 (UTC)[reply]
Copying my comment from Village pump (WMF), I believe it is better here:I feel like Simple Article Summaries (SAS) are contrary to a lot of things readers want in an encyclopedia. Readers come to the site trusting that we can give them all the information they want, while (crucially!) substantiating everything we say with sourcing and adhering to NPOV. While other readers could feel differently than I when I decided to join this community, without these two things, Wikipedia would be just another site.I've experimented with using AI on an encyclopedia. I've had it review my writing. I've asked it to write, with the intention to find shortcomings in my own ideas (if I forgot to say something). Just today, I delt with a user who has made over a thousand edits who cited sources that have never existed, at what appears to be the direction of a LLM. There is absolutely no evidence I've seen, either lived or in my line of work at an AI company, which would lead me to believe that an LLM can stick to the facts. Even the output in your survey is fraught with hallucinations.Likewise, using LLMs in my line of work, I've noticed the personality fluctuate in dramatic ways with model updates. I've tried my very hardest to correct it with a custom prompt, instructing it to use prose and maintain a neutral, skeptical perspective, but even this has not worked. There is absolutely no evidence I've seen, either lived or in my line of work at an AI company, which would lead me to believe an LLM can write neutrally. The most obvious example is WP:NOTCENSORED, whereas LLMs very much are.Yes, human editors can introduce reliabilty and NPOV issues. But as a collective mass, it evens out into a beautiful corpus. With Simple Article Summaries, you propose giving one singular editor with known reliabilty and NPOV issues a platform at the very top of any given article, whist giving zero editorial control to others. It reenforces the idea that Wikipedia cannot be relied on, destroying a decade of policy work. It reenforces the belief that unsourced, charged content can be added, because this platforms it. I don't think I would feel comfortable contributing to an encyclopedia like this. No other community has masterered collaboration to such a wonderous extent, and this would throw that away. Scaledish! Talkish? Statish.01:44, 4 June 2025 (UTC)[reply]
Every article on Wikipedia has a WP:LEDE which summarizes the article. We do not need another summary to summarize that summary above the summary. This is a solution looking for a problem. I won't necessarily disagree that some article ledes are overly technical, but the solution to that is to address it among the communities of editors which oversee those articles. Furthermore, if a possible Wikipedia reader is daunted by the language in a lede and is too incurious or thoughtful to try and understand the language presented, they can always use an AI tool on their own time to summarize it. Adding our own AI summary only serves as a barrier to understanding, and is not an improvement in any way. I cannot state strongly enough how much I oppose any implementation of generative AI on Wikipedia. A Cynical Idealist (talk) 02:01, 4 June 2025 (UTC)[reply]
Oh god no. What a horrible way to damage Wikipedia's brand image right when we need to be emphasizing it the most. Think of the signal you'd be sending to everyone on the internet who is currently thinking "at least Wikipedia is still written by humans". -- asilvering (talk) 02:12, 4 June 2025 (UTC)[reply]
Count me as a "yuck". I've been experimenting quite a lot with useful applications of LLMs in my professional work, and naturally also tried some Wikipedia-themed experiments. I've even specifically tried to generate leads for my GAs. The AI-generated leads are terrible and I have never used a word of one! Even if they were of acceptable quality, I agree with others that any use of AI to generate user-visitor content will torpedo Wikipedia's current reputation as the last bastion of actual facts on the internet. Leads are already supposed to provide an accessible, brief overview of the article. If the WMF feels they too rarely achieve that goal, they could fund an editathon with prizes like the World Destubathon. ~ L 🌸 (talk) 02:27, 4 June 2025 (UTC)[reply]
Another crucial consideration: this cannot be treated as "just" a test. Wikipedia will become the "main character" of social media for a day, as a villain. Thousands of people will hear about the feature, not examine it for themselves, conclude that Wikipedia doesn't care about fact-checking any more, and never learn that the test ended. Anything that is implemented as user-facing on English Wikipedia must be treated as a fully complete feature that en-wiki fully endorses. (Also, apologies for so many instances of "staircase wit" -- it just keeps seeming worse the more I think about it.) ~ L 🌸 (talk) 02:46, 4 June 2025 (UTC)[reply]
Going to expand on my early "yuck" a bit, since I'm a bit dumbfounded nobody's brought this up yet. The limiting factor on the English Wikipedia - which is the Foundation's primary revenue source - is the time of good-faith volunteer editors. This is extremely reminiscient of short descriptions: generate simplified summaries of articles by some automated off-wiki process, find out they're inevitably terrible, foist them off on the "infinite supply of volunteers" to fix. This was, I'm not even sure when, sometime before March 2017 at the very least, and we're only now starting to catch up. At least then, someone, somewhere, thought the descriptions would be usable as-is. You don't have that excuse this time, and we're not going to put up with it again. —Cryptic03:14, 4 June 2025 (UTC)[reply]
Gross. If this happens on Wikipedia, I'm done. What makes Wikipedia unique in 2025 is we don't accept unedited AI garbage. If a non-wiki-editable process is responsible for showing content on Wikipedia, you have successfully killed the website. Its "Wiki"pedia for goodness sake. JackFromWisconsin (talk | contribs) 03:34, 4 June 2025 (UTC)[reply]
@JackFromWisconsin, fwiw, they do appear to be planning on allowing editors to edit it. In my opinion, this is even worse, because then they're generating a huge and completely unnecessary cleanup problem for volunteers to handle, but there you are. -- asilvering (talk) 03:36, 4 June 2025 (UTC)[reply]
I saw that on the survey. Just a completely unnecessary use of AI. Our backlogs are log enough as is. We don't need a "check AI summaries" backlog too. If a new gadget were to be developed to show human-made summaries, that'd okay. (But arguably unnecessary, that's what the LEAD is for!) But any moment AI gets involved, it will completely ruin the process. There are only so much volunteer hours. JackFromWisconsin (talk | contribs) 03:40, 4 June 2025 (UTC)[reply]
@JackFromWisconsin Think of the poor multi-billion dollar AI company who now has to pay up to 2 dollars an hour for people to correct the output of their model! They really deserve our help, for free. Polygnotus (talk) 03:42, 4 June 2025 (UTC)[reply]
One of the options on the survey said that these edits might not even be listed (so no edit history). Do we want it to be easer for people vandalize something already likely to be a false AI hallucination? 2007GabrielT (talk) 12:21, 4 June 2025 (UTC)[reply]
I'm curious about what Thryduulf and WhatamIdoing's thoughts are on all this. They've been advocates for AI in past Village Pump discussions, so it'd be interesting to hear from a different perspective. Some1 (talk) 03:54, 4 June 2025 (UTC)[reply]
I don't advocate for AI. I advocate against creating unenforceable policies and guidelines about AI, and I advocate against editors making unproveable accusations that others are wrongly using AI, especially when those people are not native English speakers.
For myself, I'd never enable something like this. In fact, I turn it off at every opportunity. If anyone reading this happens to have a contact at DuckDuckGo, please tell them that I'd like a way to turn off their AI that persists even in a private/incognito window. WhatamIdoing (talk) 04:30, 4 June 2025 (UTC)[reply]
@Some1 just as you did with WAID you have misstated my position: I do not advocate for AI, I advocate against policies and guidelines related to AI that are based on hypoerbole, misinformation and assumptions rather than facts and evidence. I advocate against allowing (let alone encouraging) personal attacks on editors based on unprovable (and frequently incorrect) assumptions.
As for the actual subject of this discussion, the idea of a non-technical ~5 sentence summary of a long article is a good one, iff that summary is always both accurate and neutral. Based on the evidence presented in this discussion, the current implementation of this idea does not consistently meet those requirements. Given that some of our articles are tagged as having disputed accuracy and/or disputed neutrality, I am not sure that it is possible to meet both requirements. Thryduulf (talk) 10:35, 4 June 2025 (UTC)[reply]
While we are on this subject I should thank you for this erstwhile thankless task — lately I have been disturbed by the apparent willingness of many people to just say stuff about this subject, seemingly with no concern whatsoever for whether it is true or false, on the general idea that it owns the libs/cons/bros/sises/etc. jp×g🗯️13:33, 5 June 2025 (UTC)[reply]
I received the invitation to take the survey and was quite displeased when I saw what it was about. I have major concerns regarding the reliability of LLM-generated summaries, the extra workload maintaining their accuracy would create for human editors, and the emissions/environmental impact of LLMs. I don't think any of the potential benefits outweigh the costs here and would urge any WMF staff reading this to reconsider this idea. Ethmostigmus 🌿 (talk | contribs) 04:09, 4 June 2025 (UTC)[reply]
The view of the Wikimedia Foundation on Wikipedia is evident in the framing of this survey. The first two suggestions for adding "simple summaries"—indeed, an obfuscation of the significant role that artificial intelligence wields in this process—suppose that administrators should be responsible for managing simple summaries. At best, that is a dangerously negligent perspective; at worst, it is woefully scornful of a community that has persisted for nearly a quarter century without the idea that administrators should supercede content. What has been proposed is a box that is invisible to many editors who have not opted to use Vector 2022 and which appears to be difficult to edit. elijahpepe@wikipedia (he/him)04:39, 4 June 2025 (UTC)[reply]
Good point, I also found the proposals that admins could be responsible for the AI tasks to be alarming and almost shocking. "Admin effort" is one of our most precious resources, and it shows a real lack of understanding about en-wiki's needs and priorities to propose inventing a new task for admins to deal with, let alone one so spirit-killing as AI cleanup. ~ L 🌸 (talk) 04:55, 4 June 2025 (UTC)[reply]
I just got the survey, responded to it (I hate the idea with a burning passion and made sure to share my opinion in the survey) and immediately searched for the discussion because I knew there'd be one. There are so many problems with this whole idea, and they all boil down to "AI that we as editors of the website can't directly control". Of course, directly controlling an AI to output a specific summary defeats the purpose of using an AI. Also, from MOS:INTRO: The lead section should briefly summarize the most important points covered in an article, in such a way that it can stand on its own as a concise version of the article. So we already have a "simple summary", and it's one that we can directly edit, thus maintaining both the quality of the encyclopedia and the trust those who use Wikipedia have in us. Why do we need a second one? Side note: When I did the survey, the order of responses, which ranged from "Good" on the left to "Bad" on the right for the first few pages, got switched so "Bad" was on the left and "Good" was on the right on the last page. I'm glad I happened to glance (without even really meaning to) at those responses or I wouldn't have even noticed the (accidental?) switcheroo.—Gestrid (talk) 05:44, 4 June 2025 (UTC)[reply]
LLMs are notoriously bad at summarising. Abusing vulnerable people (mobile visitors) as guinea pigs for an experiment which is unlikely to collect any useful information is, at best, rude. The WMF should stick to its better ideas about LLMs, which are about using them for anything but prose generation. For example, instead of presenting a summary of the article as if it were true, you could pick some sentences from the article and quote them verbatim, possibly ask some questions about them. Nemo06:08, 4 June 2025 (UTC)[reply]
'Opppose in the strongest of all possible ways. Are y'all (by that, I mean WMF) trying to kill Wikipedia? Because this is a good step in that way. We're trying to keep AI out of Wikipedia, not have the powers that be force it on us and tell us we like it. - The BushrangerOne ping only06:05, 4 June 2025 (UTC)[reply]
I can't help feeling that what this would create is a duplicate lead that editors would not just have to verify but also moderate and curate. The lead of some articles is the result of potentially long-winded discussion, this risks requiring all that work again. These would also require oversight to ensure they are not targeted by vandals or POV pushers, as they would be highly visible. The leads if many articles should be shorter and less cluttered, but something that would in effect duplicate the lead (and the work required to maintain the lead) doesn't seem like the greatest idea. -- LCU ActivelyDisinterested«@» °∆t°06:21, 4 June 2025 (UTC)[reply]
These kind of discussions are common inside and outside of contentious topic areas. Even seemingly simple articles may have had weeks of discussion on how to correctly summarise the article in the lead. -- LCU ActivelyDisinterested«@» °∆t°10:15, 4 June 2025 (UTC)[reply]
Absolutely not, all of the work that countless people put into these articles being thrown away in favour of LLMs we don't even really understand. Besides that, we have simple for a reason. Weirdguyz (talk) 06:30, 4 June 2025 (UTC)[reply]
Absolutely not This duplicates the existing summary function of our article leads. If readers find that an article lead poorly summarizes its content, that is one of many avenues by which we hope to recruit them into editors improving the content they care about. As HouseBlaster notes, when other LLMs ask for thumbs up/down feedback, they are assessing whether you liked the response, not whether you double-checked its accuracy. To implement that here will train models to reinforce reader preconceptions, rather than accurately summarize our articles. As CMD demonstrates below, even the dopamine example demonstrates hallucinations that will severely diminish our reliability, so even a mobile trial is untenable. ViridianPenguin🐧 (💬) 06:52, 4 June 2025 (UTC)[reply]
Very bad idea. First, LLMs have inherent reliabilty issues (as demonstrated above, the summary in the demo video used to promote the idea is wrong). The effort to correct summaries would need people willing to check the article in detail; it would swallow up editor time that could better be spent on improving article leads. Second, it would do a lot of damage to Wikipedia's brand. On social media, people are praising the existence of WP as something that has not turned into AI slop. Even if AI were only used for small summaries, it would raise suspicions and upset people.OsFish (talk) 07:26, 4 June 2025 (UTC)[reply]
So in a world where Wikipedia is one of the only respected bastions against hallucinated bullshit information by LLMs, our response is to implement them onto the project??? Not a hope in hell. ser!(chat to me - see my edits)07:53, 4 June 2025 (UTC)[reply]
I have my doubts that trying to duplicate Google's work (or "work") or the efforts editors writing leads engage in is worthwhile. Having AIs that can read an article and write a WP:LEAD compliant lead would be something actually useful, as it can be fairly difficult for people. Or AIs that you feed sources to and write or expand articles with them, that would be even better. One should avoid the tendency to develop AIs in imitation/inspiration of existing efforts, because chances are you are duplicating existing work/reinventing the wheel for no good reason. Jo-Jo Eumerus (talk) 08:34, 4 June 2025 (UTC)[reply]
In my opinion, this would be a gross overstep of the bounds we typically expect the Foundation to adhere to. We are not paid, obviously, but if this is implemented over the objection of the community, the Foundation would effectively be signalling intent for Wikipedia to become one more publication that has fired their editors, in part or in whole, in order to put out AI slop. Alpha3031 (t • c) 10:49, 4 June 2025 (UTC)[reply]
Oppose - the lead exists for a reason. AI summaries are extremely unreliable (as this thread constantly mentions), and it would ruin Wikipedia's reliability. VERIFIABILITY is one of our core policies - AI just hallucinates, leaves stuff out, and makes shit up. This is proof that the WMF does not care about the community of volunteers that work this website. PhoenixCaelestis (Talk · Contributions) 11:25, 4 June 2025 (UTC)[reply]
Strong oppose, including the trial. This is utter disrespect to both readers and editors, and dangerous to the point where we risk losing plenty of both. AI generated stuff is not only inaccurate and unreliable, it is also cheap and therefore almost worthless (since you can get it everywhere nowadays). Even the trial is highly problematic as it sends the wrong signal to the users (namely that Wikipedia became enshittified), and can therefore irreversibly damage Wikipedia's reputation. Let's keep Wikipedia AI-free – that's a strength, not a weakness. --Jens Lallensack (talk) 11:37, 4 June 2025 (UTC)[reply]
Oppose - Making AI generated summaries is exactly none of our business. Google are already on top of that with their AI Overview nonsense -- let's leave that stuff to them. DJ-Aomand (talk) 11:55, 4 June 2025 (UTC)[reply]
I don't understand the point. A piece of text is generated, which in best-case scenarios is duplicating already existing text, then editors review it and edit for quality? If they're going to be manually edited afterwards anyway, what's the purpose of automatically generating them? 207.11.240.2 (talk) 12:22, 4 June 2025 (UTC)[reply]
I'm very uncomfortable with both this proposal and with the direction of travel it suggests. This is either going to wastefully duplicate what's already there, or require scarce editor time to fix it up. Even if this is not affecting the underlying article content, it is generative AI material being presented to a reader under our name, and that is a line we should not cross. Andrew Gray (talk) 12:53, 4 June 2025 (UTC)[reply]
Oppose any movement towards the integration of generative AI on Wikipedia. This is a volunteer project based on community effort, always has been. We're the last best place on the internet because we're built on love, not automation. Don't ruin our reputation by falling victim to the craze for dumbing down everything to the lowest possible attention span - and then add insult to injury by doing it with generative AI. ♠PMC♠ (talk)14:02, 4 June 2025 (UTC)[reply]
Volunteers have spent tremendous amounts of time both crafting the lead sections of articles, and trying to keep chatbot-generated junk out of articles in general. Now, here's this proposal, to flip a middle finger at both efforts, and say "Hey, we'll put some chatbot-generated junk above the actual leads the volunteers worked so hard on building consensus for!". I do not believe I have the words to express how disgusted I am at this proposal. SeraphimbladeTalk to me14:07, 4 June 2025 (UTC)[reply]
Very strongly opposed to this. LLMs are nothing but unethical, mindless plagiarism-machines built with the stolen work of actual humans. Keep this techbro bubble out of Wikipedia. -- kazerniel (talk | contribs) 15:31, 4 June 2025 (UTC)[reply]
What the hell? No, absolutely not. Not in any form or shape. Not on any device. Not on any version. I don't even know where to begin with everything that is wrong with this mindless PR hype stunt. — HELLKNOWZ∣TALK15:59, 4 June 2025 (UTC)[reply]
No, no, no This will destroy whatever reputation for accuracy we currently have. People aren't going to read past the AI fluff to see what we really meant. --SarekOfVulcan (talk)17:14, 4 June 2025 (UTC)[reply]
Validation issues An experiment seems reasonable as our articles can often seem inpenetrable. And it's good to develop expertise and experience with AI tech as it is becoming omnipresent. But the idea of human validation may be difficult. One issue is that our articles may change frequently and so the summary and validation would need to be redone frequently too. Another issue is that every page has a disclaimer saying that our content is not guaranteed to be valid and so an assertion of validity would be sending a mixed message. Andrew🐉(talk) 18:17, 4 June 2025 (UTC)[reply]
To say publicly what I wrote in the survey: from a structural standpoint, an AI-generated summary seems pointless. The one paragraph summary of the article is the lead paragraph. The multi-paragraph summary is the entire lead. If AI can write a better one-paragraph summary than the lead paragraph, then that paragraph should just be the lead paragraph. Why have two summaries at the top of an article, especially if one is worse than the other?
A better deployment for AI here would be to have AI write a summary of the article and then compare its summary to the existing lead, and post the differences/analysis on the article's talk page, essentially an AI edit suggestion. Human editors can then review the suggestion and implement it (or not) as appropriate. AI could do this not just for the lead but for entire articles. Of course, this hinges on an AI that has sufficient accuracy to the point where it's suggestions are actually useful.
A next-level deployment would be for AI to read the sources of the article, summarize those, and then compare its summary to the written article, and post suggestions for changes on the talk page.
A next-next-level deployment would be for AI to suggest new sources for the articles, or to read and summarize sources that aren't in the article, and then post edit suggestions to the talk page. AFAIK AI isn't ready for this level yet, but the first two suggestions above could probably be done today with reasonable accuracy using large and small language models.
+1. AI that helps editors address problems with Wikipedia is welcome (if it works). We already use it, in various places, to varying degrees of success, and to relatively little pushback. -- asilvering (talk) 19:25, 4 June 2025 (UTC)[reply]
I would not be in support of large AI-suggested edits. To properly evaluate what an AI writes takes a lot of brainpower. In my opinion it takes the same or more brainpower as just reading the sources/article yourself and writing it without AI. I think an AI that posts suggested edits on talk pages would just distract editors or get ignored, and reminds me of Microsoft trying to have AI write patches and post them on GitHub. There is a thread on Reddit called "My new hobby: watching AI slowly drive Microsoft employees insane" making fun of how terrible AI has been at writing software patches (7,000 upvotes in r/ExperiencedDevs). It would be sad if Wikipedia got into a similar situation. –Novem Linguae (talk) 20:08, 4 June 2025 (UTC)[reply]
I think Of course, this hinges on an AI that has sufficient accuracy to the point where it's suggestions are actually useful. covers that already. That's a big ask. -- asilvering (talk) 20:13, 4 June 2025 (UTC)[reply]
The problem is that many people do think that LLM is useful and it can be good for certain low-hanging fruit but it can also be dangerously wrong with no way to know. Andre🚐21:42, 4 June 2025 (UTC)[reply]
Please don't do AI summaries. I go to Wikipedia because I can generally trust it not to hallucinate. And I can already read. I am sick and tired of seeing AI summaries everywhere. Yuck. Deliamturner (talk) 18:02, 11 June 2025 (UTC)[reply]
I'm not sure what value any of this adds.
I love Wikipedia, ever since its creation, and have been a faithful monthly donor to support the one source of information that has been a steadfast anchor.
I am a steadfast believer in tech, and I personally use the current generation of Generative AI and LLM's on the daily, but I do not think it is reliable enough to add value to Wikipedia. The lack of reliability and unpredictable hallucinations make it potentially harmful to people looking for real information. Additionally, to check the output would just result in reading the article anyways. Lastly, anyone looking for an AI summary of a Wikipedia page instead of reading would most likely just be asking ChatGPT externally with Search/Research functionality turned on.
As an occasional donor, I will stop donating if Wikipedia moves to AI summaries. I mean, seriously? Why the hell would you waste my money on that? This is not a good use case for LLMs; you're essentially duplicating the lead of the article and inevitably introducing errors. So not only does this not add any value, but it actively removes it.
(Could Wikipedia use LLMs to rewrite the leads of some articles? Sure (and undoubtedly some editors are already doing this). However, you'd need to go through each and every one in order to make sure that they're accurate and not introducing hallucinations.) 24.212.207.82 (talk) 15:05, 12 June 2025 (UTC)[reply]
I don't know if you are familiar with what copyright is, but there is no such thing as a "copyright infringing material", and this phrase is facially nonsense -- the materials do not themselves infringe copyright by existing. Even in the case where you mean "material obtained without permission from copyright holders", it does not infringe copyright to write text based on having previously read text in violation of copyright. As far as I am aware, there is no legal precedent whatsoever saying that having a computer read a book establishes any subsequent creation as a derivative work of the original.
I sent an email was directed to post here. As Wikipedia is one of the few remaining online resources for accurate information written by human beings, I would like to make clear that my continued support as a donor of this organization will cease if the use of LLMs or other such generative Ai is implemented onto the website. 2600:1015:A030:8DB2:7DE3:8A29:303:7F68 (talk) 15:06, 12 June 2025 (UTC)[reply]
Why would I want you to create a summary of my work that might be wrong? That defeats the entire purpose of my being editor which is to inform people. Hammy (talk) 22:36, 12 June 2025 (UTC)[reply]
No gen AI. Ever. Aside from the legal, moral, and ethical issues, a major contributor to the wiki's success is that it does not chase the latest trends. In my opinion, this "exploration" violates the principle that the WMF does not edit Wikipedia content. The misleading title and unilateral nature of the "experiment" demonstrate bad faith on the part of the foundation. James (talk/contribs) 23:00, 12 June 2025 (UTC)[reply]
Thank-you for engaging with the community.
Why does the WMF development process engage with the community after development?
Can you confirm that this has no links to Knowledge/Google? The Google AI summary is receiving criticism because the summaries are poor. By having editors check the output then that accuracy could increase. To improve this and other LLMs, AI companies are paying people to provide feedback. The concern would be that we are doing work for Alphabet
Would it reduce people clicking through to Wikipedia, and a small percentage becoming editors?
How many articles are we talking about? Is this only in en? The concern is how much editor time would be needed.
Concern is whether it a good time with the DC attorney general issue. Even if he is not approved, then the next one will ask the same questions
WMF has been concerned that enWP editor's white male and American. As LLMs have a cultural bias do you see this as increasing WMF's perception of a white male American bias? My big concern is that it takes the fun part out of editing, and creates a Readers Digest Condensed book of the lede , which is our summary of the article, which is a summary of others peoples summaries. But if there was an editor toolbar that allowed editors to create a lede as part of their process, or to use the AI in an integrated way (create a table based on these paragraphs), or to check a page for errors, then you might get traction Wakelamp d[@-@]b (talk) 05:33, 5 June 2025 (UTC)[reply]
it takes the fun part out of editing. Indeed, and not only that: having to correct the output of an AI that makes the same mistakes again and again may be the quickest way to burnout. Yes, the most important thing, in the end, is to have fun. It's not about maximising clicks, which is what the WMF seems to be interested in. If it were, much more of us would spend much more time on core content rather than our highly specialised pet topics. Introducing AI to Wikipedia looks like an attempt to "optimise" us or our work to get more clicks – even though that's not even the principal goal for most of us personally. Interacting with AI is quite the antithesis of "having fun". I am here because I want to collaborate with humans to build something great together, and to help others becoming better writers. That is meaningful to me and makes it worthwhile – interacting with AIs is just not. --Jens Lallensack (talk) 17:30, 7 June 2025 (UTC)[reply]
Well, it's easy enough to test, so I asked AI to summarize a Wikipedia article in one paragraph and then to compare its summary with Wikipedia's summary, and to tell me the differences between the two summaries. I did this for Today's Feature Article, 1880 Republican National Convention, using the TFA blurb as the example of Wikipedia's one-paragraph summary (although one could just as easily use the lead paragraph, or entire lead). I figure TFA is a good proxy for top-quality one-paragraph article summary written by Wikipedia volunteers. I asked ChatGPT and Gemini to "summarize https://en.wikipedia.org/wiki/1880_Republican_National_Convention in one paragraph", and then to "compare these two paragraphs and tell me what's different between them". Here are their responses:
TFA one-paragraph summary
The 1880 Republican National Convention (June 2 to 8, 1880, Chicago) resulted in the nominations of James A. Garfield of Ohio and Chester A. Arthur of New York as the Republican Party candidates for U.S. president and vice president. Leaders in the early balloting at the convention, which deadlocked for several days, were former president Ulysses S. Grant, Senator James G. Blaine of Maine, and John Sherman, the treasury secretary. After the 35th ballot, Blaine and Sherman switched their support to a new "dark horse", Garfield, a congressman from Ohio, who had nominated Sherman. On the 36th ballot, Garfield won the nomination. After Arthur won the vice presidential nomination on the first ballot, the longest-ever Republican National Convention adjourned. The Garfield–Arthur Republican ticket narrowly defeated Democrats Winfield Scott Hancock and William H. English in the 1880 presidential election.
ChatGPT's one-paragraph summary
The 1880 Republican National Convention, held from June 2 to 8 in Chicago, was marked by intense factionalism and a prolonged deadlock. The leading contenders were former President Ulysses S. Grant, backed by the Stalwart faction favoring patronage; Senator James G. Blaine, supported by the Half-Breeds advocating civil service reform; and Treasury Secretary John Sherman, representing a more moderate stance. After 35 ballots failed to produce a nominee, a compromise emerged when Blaine and Sherman shifted their support to James A. Garfield, a congressman from Ohio not initially in the running. Garfield secured the nomination on the 36th ballot. To balance the ticket and appease the Stalwarts, Chester A. Arthur of New York was nominated for vice president. The Garfield-Arthur ticket narrowly defeated Democrats Winfield Scott Hancock and William Hayden English in the 1880 presidential election. Tragically, Garfield was assassinated in 1881, leading to Arthur's succession to the presidency.
ChatGPT's comparison of its summary ("Paragraph 1") with the TFA blurb ("Paragraph 2")
Here are the key differences between the two paragraphs:
Tone and Style:
Paragraph 1 is more narrative and descriptive, using phrases like “marked by intense factionalism” and “a compromise emerged.”
Paragraph 2 is more concise and encyclopedic, structured more like a historical summary.
Emphasis on Factions:
Paragraph 1 details the factions backing each candidate (Stalwarts, Half-Breeds, etc.).
Paragraph 2 omits faction names and focuses on the individuals.
Garfield’s Role:
Paragraph 1 mentions Garfield was “not initially in the running.”
Paragraph 2 notes Garfield “had nominated Sherman,” subtly emphasizing his presence at the convention before his surprise nomination.
Vice Presidential Nomination:
Paragraph 1 explains Arthur’s nomination as a move to “appease the Stalwarts.”
Paragraph 2 simply states Arthur won on the first ballot, omitting strategic context.
Convention Description:
Paragraph 1 highlights the prolonged deadlock with rich detail.
Paragraph 2 mentions it was the “longest-ever Republican National Convention” but without elaboration.
Garfield’s Assassination:
Paragraph 1 includes it and its consequence (Arthur’s presidency).
Paragraph 2 omits it entirely.
In summary, Paragraph 1 is more detailed and interpretive; Paragraph 2 is more formal and fact-focused.
Gemini's one-paragraph summary
The 1880 Republican National Convention, held in Chicago, Illinois from June 2 to June 8, 1880, saw the nomination of James A. Garfield of Ohio for president and Chester A. Arthur of New York for vice president. Despite Ulysses S. Grant, James G. Blaine, and John Sherman being strong contenders, Garfield ultimately secured the nomination after multiple ballots, with Arthur as his running mate. The Garfield–Arthur ticket went on to narrowly win the 1880 presidential election against Democrats Winfield Scott Hancock and William Hayden English.
Gemini's comparison of its summary ("Paragraph 1") with the TFA blurb ("Paragraph 2")
The two paragraphs describe the 1880 Republican National Convention, but Paragraph 2 provides more specific details and additional information compared to Paragraph 1.
Here are the key differences:
Format of Dates and Location: Paragraph 1 states "held in Chicago, Illinois from June 2 to June 8, 1880," while Paragraph 2 uses a more concise parenthetical format: "(June 2 to 8, 1880, Chicago)".
Detailed Nomination Process:
Paragraph 1 generally states, "Garfield ultimately secured the nomination after multiple ballots, with Arthur as his running mate."
Paragraph 2 offers much more detail, mentioning "Leaders in the early balloting at the convention, which deadlocked for several days," and specifies the "35th ballot," how "Blaine and Sherman switched their support to a new 'dark horse', Garfield," and that Garfield "had nominated Sherman." It also mentions "On the 36th ballot, Garfield won the nomination."
Arthur's Vice Presidential Nomination:
Paragraph 1 briefly notes "with Arthur as his running mate."
Paragraph 2 adds that "After Arthur won the vice presidential nomination on the first ballot."
Convention Duration/Length: Paragraph 2 explicitly states that "the longest-ever Republican National Convention adjourned," a detail not present in Paragraph 1.
Full Name of Democratic Vice Presidential Candidate: Paragraph 1 refers to "William Hayden English," while Paragraph 2 shortens it to "William H. English."
Helpful? I think so. It would probably be better if the prompt were improved to instruct it write an encyclopedia-style summary, or even a Wikipedia-style lead. Novem's probably right that posting these on talk pages, particularly in volume, could be overwhelming, but it would be easy to create a toolforge-hosted python script that uses the AI APIs to perform these two steps for any given article, and thus generate "AI suggestions for improvement" on-demand for any given article... as long as somebody pays the API credits. But WMF has hundreds of millions of dollars and could afford to foot that bill, at least up to some reasonable cap. Levivich (talk) 21:51, 4 June 2025 (UTC)[reply]
If we're just going to ask the AI to write in the style of a Wikipedia lead, what's the use in having the AI? Wikipedia-style leads are already present.The Morrison Man (talk) 22:05, 4 June 2025 (UTC)[reply]
@The Morrison Man: The use of the AI is that the AI may have good suggestions for improvement. For example, ChatGPT's comparison above identifies the following possibilities for improving the TFA blurb:
name the factions backing each candidate (Stalwarts, Half-Breeds, etc.)
explicitly state that Garfield was not initially in the running
explicitly state that Arthur's nomination was a move to appease the Stalwarts
mention that Garfield was assassinated the following year, making Arthur president
Editors can debate whether any of these changes are, in fact, improvements to the TFA blurb, but it seems to me to be a pretty helpful list of things to consider when thinking about how to improve the TFA blurb. And it took less than one minute -- way less time than it would have taken me to read the article and the TFA blurb and figure out suggestions for improvement. That's what AI can do, today. Levivich (talk) 22:26, 4 June 2025 (UTC)[reply]
Well first, that's flat not true. The lead doesn't have the third or fourth bullet points. Second, none of it is in the lead paragraph. Third, duh, reading the 4-paragraph lead would give more info than the 1-paragraph TFA blurb, and reading the article would certainly have all that info, but this demonstration is about improving the 1-paragraph TFA blurb, so pointing out that some of this info is in the lead isn't really relevant. Levivich (talk) 22:39, 4 June 2025 (UTC)[reply]
Agreed with your comments above -- this is a thoughtful way to build good tools for editors, rather than automating anything that shows up directly for readers. In theory leads are a good arena in which to explore such editor-facing tools, as anything in them should appear elsewhere in the article. And an internally-consistent way to think about "improving the reader experience" is to identify editor backlogs and improve how we work through them [because almost every editor backlog is about improving the reader experience!]
I also tested it with a few articles I know well, and if asked to keep the summary short it generally did well. Longer "summaries" meant more hallucinations, though. Cremastra (u — c) 21:55, 4 June 2025 (UTC)[reply]
An informal test does not prove the absence of hallucinations. They are insidious and they may appear in unpredictable places. Andre🚐22:40, 4 June 2025 (UTC)[reply]
This is a bad idea. While AI generated summaries of Wikipedia content are potentially useful and, given our free licensing, ultimately inevitable, there is no reason for the Foundation to be generating or hosting them. The primary role of the Foundation should be assisting volunteers in the creation and curation of content. Since it's free delivery in digestible packets mostly takes care of itself. Eluchil404 (talk) 00:05, 5 June 2025 (UTC)[reply]
I see below that the WMF has already decided to pause the idea. However, I really think it should just be scrapped altogether rather than "reformatted", and I believe that any attempts by the WMF to push through with it in any capacity, despite community opposition, will not end well. Generative AI is already very fond of hallucinating, even when trained on proper data, and promoting technology that encourages such things would only hurt the project's reputation. I get the idea, I understand that there are good intentions behind it, and I do think that AI has its use cases (not on-wiki though). But now is not the right time, and until AI gets past its hallucinations, I don't think it ever will. Narutolovehinata5 (talk · contributions) 01:59, 5 June 2025 (UTC)[reply]
? A question about accessibility. When I watched the demo video, it looks like the default position for the "simple summary" was collapsed. For our visually impaired readers and editors who use screen readers to access Wikipedia, would this summary be available to them/us. Because in order to view and/or hear the summary, it requires interaction (clicking on it to open it), which obviously screen readers are not capable of. And per our guidelines at MOS:COLLAPSE, content in an article (if this summary is to be considered content), should never be collapsed by default. So how would this feature be beneficial to our visually impaired readers/editors if it is not accessible? We have alternative text for images, so has there been any consideration given by the develpers for alt text for this feature if it is to remained collapsed by default?Isaidnoway(talk)07:47, 5 June 2025 (UTC)[reply]
As is the survey, but I would still like to hear their response. Wikipedia already has enough problems with accessibility issues, so adding another one is not ideal.Isaidnoway(talk)08:39, 5 June 2025 (UTC)[reply]
@Isaidnoway Regarding your first question. Screen readers are capable of interacting with collapsed interface elements, as long as it's implemented correctly, e.g. that button elements are marked as interactive and respond to keyboard actions and not just mouse clicks. For example, if you're using the "Reply" button to reply in this conversation, the reply tool has an "Advanced" button following the comment box, which should be fully compatible with your screen reader, and which should reveal some additional options when used. In MediaWiki development we use libraries called Codex and OOUI, which make this easy to do or even do it automatically, so I would expect any new features to be accessible by default. Matma Rextalk15:35, 5 June 2025 (UTC)[reply]
I think this would be a quite bad idea for a first step towards integrating a new technology — especially one that many people passionately hate (whether for intelligent reasons or nonsensical/false/superstitious ones). Essentially, the pitch here is the lead: essentially to supplant the single most important, visible, sensitive and contentious part of the entire article! Surely, if a surgeon comes up with a new parkour move, you don't want them trying it out for the first time on your aorta. Can't we, like, try this on something that doesn't instantly kill us in the event of an error? jp×g🗯️13:16, 5 June 2025 (UTC)[reply]
No. Just no. – Every reason why this would be a catastrophic decision has already been said above, based on the fact that it is just a conceptually terrible idea. We need help from the WMF regarding LLM-generated content, but to fight it back, not to include it in the most prominent spot of every article. Choucas0 🐦⬛⋅💬⋅📋08:37, 6 June 2025 (UTC)[reply]
Strong oppose. AI-generated content does not have any place in articlespace and I am coming around to the idea that it doesn't have any place in project discussions either. LLMs are not reliable sources, and so this is as clear a WP:5P2 violation as it gets. It is also very likely to plant a seed for legal questions (is this going to be on BLPs? edit 6/7 -- articles on BLPs seem to have been filtered out, but not articles that contain statements about them) and almost certain to result in immediate and massive public backlash when the media gets wind of it. I also have reservations about the experiment from which this terrible idea sprung. This is based on the opinion of eight (8) people. Are those eight people in the room with us right now? There seems to be a strong and near-unanimous consensus against this from far more than eight people. It seems to also be based on this presentation at Wikimania 2024, the quality of which is unclear because no one bothered to upload the slides despite it being almost a year. Gnomingstuff (talk) 17:56, 6 June 2025 (UTC)[reply]
Oppose The first and only thing I ever learned from machine-generated summaries is to close my eyes on sight and hit the page-down key, even at the cost of skipping some first info paragraphs. --CiaPan (talk) 06:14, 9 June 2025 (UTC)[reply]
With all due compassion and respect for the WMF people who I'm sure are trying to be innovative and responsive to trends, Heck No. The potential benefit to our readers is minimal since every major search engine already provides these summaries generated from our content. The potential harm to the project is great both in alienating those of us who have invested thousands of human-hours of editing into building this resource, and in damaging the reputation and quality of our content. I don't claim any authority over WMF nor do I claim to speak for the entire community, but want to make it clear in the strongest possible terms that if the WMF incorporates AI-generated summaries into Wikipedia articles they will do so in blatant disregard of the wishes and counsel of myself and many others. -- LWGtalk02:57, 11 June 2025 (UTC)[reply]
Not in a million years. Both for the test AND any future use of generative AI on this site. Ethical, legal, and environmental concerns aside, LLMs are incapable of producing anything but inaccurate slop. "Hallucination" is just a fancy word to hide the fact their technology is garbage. I won't so much as edit a typo again if Wikipedia ever implements this. AmityBlamity (talk) 18:11, 11 June 2025 (UTC)[reply]
Sure: here is one about the "environmental concerns", here is one about the "copyright concerns". I don't know how to address the claim that literally every LLM, past and future, is "incapable of producing anything but inaccurate slop" -- is there any definition of what this means, or is it an unfalsifiable expression of opinion? jp×g🗯️14:10, 12 June 2025 (UTC)[reply]
Completely agree. Even just for the shady way that training data is used without permission (and in completely non-transparent way), LLMs should never be used in Wikipedia. Let alone the fact that they are completely unreliable Ita140188 (talk) 12:45, 12 June 2025 (UTC)[reply]
Strong oppose AI has no place in Wikipedia, in any form. It threatens to poison the whole project and it should not be used at all. AI is unreliable, non-free, non transparent, controlled by corporations, biased, and partly based on Wikipedia itself (thus introducing a dangerous feedback). Using it is an affront to all the contributors that put all the effort to actually create new content instead of the regurgitations of language models.--Ita140188 (talk) 07:22, 12 June 2025 (UTC)[reply]
Oppose. Some articles are (unfortunately) controlled by spammers, so ironically AI summaries wouldn't be much worse for those articles, but we already have summaries (in the form of article leads) and this is an insult to the hard-working volunteers who write for free! And this is stupid, because we already spend much effort cleaning up AI hallucinations and copyvios!WMF, please listen to the community for once! AI will vomit up crap and tarnish our reputation! Thanks. 123957a (talk) 19:54, 12 June 2025 (UTC
Oppose, Oppose, and Oppose again We contribute one way or another to Wikipedia because it is fun. If WMF decides to dumb it down by using AI summeries it may as well shut up shop. Take the fun away and we go away.
I have an oven with a WiFi facility. That, too, is a solution looking for a problem. Apparenlty I can leave my cold, raw food in it all day going quietly rancid, and use my phone to switch it in when I am on my way home, thus poisonimng all who eat the (now cooked) food. 🇵🇸🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦🇵🇸 20:11, 12 June 2025 (UTC)[reply]
@Timtrent I think the idea is that you can remotely preheat the oven so that it's ready for your frozen pizza when you get home (although I do remember reading a couple of years ago about someone who was making an oven with a built-in refrigerator). --Ahecht (TALK PAGE)20:25, 12 June 2025 (UTC)[reply]
@Ahecht Such scope for misuse! And this is the route WMF wants us to go down. But my oven manual says I can leave my lasagne in it to await my command to cook it for when I get home! Perhaps I should thaw the pizza I my WiFi enabled tumble dryer, another solution looking for a problem, and then use the robot vacuum cleaner to transport it to the oven. 🇵🇸🇺🇦 FiddleTimtrentFaddleTalk to me 🇺🇦🇵🇸 20:42, 12 June 2025 (UTC)[reply]
Hell no. No AI. No AI summaries, no AI translations. We fight to keep AI slop out of Wikipedia, so why is WMF trying to push it in? If AI is allowed we will loose reputation, we will loose readers, we will loose editors and with that we will loose the whole project. Also WMF should keep out of content generation in general. --Lupe (talk) 20:32, 12 June 2025 (UTC)[reply]
Absolutely agree. The problem is that most of the WMF does not really care about the project in the long term, and does not even understand the community behind it, because they were never really part of it. This needs to stop. The only way is to massively cut funding to the WMF. Running servers is <10% of the current budget, and that's what the WMF should stick to. Proceeds from the Endowment Fund should be enough to run the servers without further donations necessary for the foreseeable future. Ita140188 (talk) 20:53, 12 June 2025 (UTC)[reply]
Oppose I'm tired of AI being pushed into everything these days. AI can be a useful tool in certain, specific situations, but this is not one of them. Google has become nearly unusable for me because of those AI-generated summaries, and I'd hate to see Wikipedia head in the same direction. Keep Wikipedia human please. Paprikaiser (talk) 22:06, 12 June 2025 (UTC)[reply]
So the plan is to make an AI that writes a new lead, but needs to be moderated by humans, where humans have presumably already written a lead. This is something existing AIs can already do. So I'm not seeing the cost/benefit there where it's worth spending volunteer time on. This looks a bit like starting with the desire to integrate AI, and then working backward to find a place to fit it in. GMGtalk14:17, 13 June 2025 (UTC)[reply]
Now now... are y'all planning on replacing your volunteer editors with AI 🙄? Y'all do realize that we contribute here for free, no? 𐩣𐩫𐩧𐩨Abo Yemen (𓃵)16:49, 13 June 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Simple summaries: editor survey and 2-week mobile study (cont.)
Reply WMF
Hey everyone! This is Olga, the product manager who is working on the summary feature at WMF. I just wanted to let you all know that we’re following the conversation here closely and will be getting back to you with some thoughts and next steps we can discuss later today. OVasileva (WMF) (talk) 07:37, 4 June 2025 (UTC)[reply]
Please abandon this idea, Olga. The community doesn't want to integrate AI into Wikipedia, and in future our AI-skepticism will become an ethical anchor for everything we do -- and also a major selling point for Wikipedia.—S MarshallT/C07:35, 5 June 2025 (UTC)[reply]
The only way forward is to abandon this project and resign, since even thinking that including AI in Wikipedia was a good idea makes someone unfit for this role Ita140188 (talk) 07:25, 12 June 2025 (UTC)[reply]
Further up on this page someone told us he apply for a jon at Wikimedia. That leds to the question which consequenses will follow for the people responsible for this waste of resources? --Bahnmoeller (talk) 15:30, 12 June 2025 (UTC)[reply]
@OVasileva (WMF) I am very concerned about the degradation of cognitive abilities caused by AI use, across large swaths of humanity.
People are lazy. In a hunter-gatherer environment, this laziness is adaptive: it motivates people to think up ways to reduce physical labour. This reduces caloric expenditure and injuries, promoting survival. In our civilization too, it has promoted progress.
Tools that reduce cognitive effort enable mental laziness. Mental laziness has no redeeming quality. And it is habit-forming, as is all laziness.
Research on the impact of widely available AI has barely begun. In time, I feel certain that researchers will correlate the amount that one uses AI tools to a corresponding reduction in one's cognition and judgement.
Wikipedia is an educational resource. Our objective should be to help people improve themselves, not stunt their growth. Nor should we coddle people. Living systems need exercise. Without it, they atrophy. Human brains are no exception.
A simplified English Wikipedia already exists. It aids children, foreign language speakers, and the mentally challenged. It is a stepping stone to the full thing. No doubt, some people progress no further, out of laziness or inability. But they are aware of this.
Contrarily, an AI tool will be treated as a final destination. I have myself observed this amongst people I know: they ask an AI and, whatever the answer, they are satisfied. Why waste further effort, when the answer appears convincing? And LLMs are nothing, if not convincing. After all, that is the primary criterion in their development.
I am not defending badly written Wikipedia articles. But the answer is for human editors to apply knowledge, skill, good judgement, and effort to improve those articles. Even if an AI tool were offered only to editors, to "aid" us without exposing readers to hallucinations, the very fact that the AI reduces effort will lead to the atrophying of Wikipedians. This is a harm in itself. But also, over time, it will lead to less accurate or less informative articles. And it is a slippery slope.
Inevitably, third parties will build tools that "help" users digest Wikipedia articles. Whether intentionally or in ignorance, these developers will contribute to the dumbing down of our civilization. We should not collaborate in this process. We should resist! —Black Walnuttalk18:28, 16 June 2025 (UTC)[reply]
Dopamine is a neurotransmitter, a chemical messenger that carries signals between brain cells. It plays a vital role in several brain functions, including emotion, motivation, and movement. When we experience something enjoyable or receive a reward, our brain releases dopamine, creating a sense of pleasure and reinforcement. This neurotransmitter also helps us focus and stay motivated by influencing our behavior and thoughts. Dopamine imbalance has been associated with various disorders, such as depression and Parkinson's disease, highlighting its importance in maintaining overall brain health and function.
The first sentence is in the article. However, the second sentence mentions "emotion", a word that while in a couple of reference titles isn't in the article at all. The third sentence says "creating a sense of pleasure", but the article says "In popular culture and media, dopamine is often portrayed as the main chemical of pleasure, but the current opinion in pharmacology is that dopamine instead confers motivational salience", a contradiction. "This neurotransmitter also helps us focus and stay motivated by influencing our behavior and thoughts". Where is this even from? Focus isn't mentioned in the article at all, nor is influencing thoughts. As for the final sentence, depression is mentioned a single time in the article in what is almost an extended aside, and any summary would surely have picked some of the examples of disorders prominent enough to be actually in the lead.
So that's one of five sentences supported by the article. Perhaps the AI is hallucinating, or perhaps it's drawing from other sources like any widespread llm. What it definitely doesn't seem to be doing is taking existing article text and simplifying it. CMD (talk) 18:43, 3 June 2025 (UTC)[reply]
As someone who has tested a lot of AI models; no AI technology that is currently available to the public is reliably able to make an accurate summary of a complicated article. We may get there at some point, but we aren't there yet. Polygnotus (talk) 18:47, 3 June 2025 (UTC)[reply]
CMD makes some good points but maybe the WMF is not using a good AI. I tried asking Gemini 2.5 Pro to summarise the article "in one paragraph using English suitable for a general readership." The result was as follows:
Dopamine is a chemical messenger that plays several vital roles in the body. In the brain, it acts as a neurotransmitter, sending signals between nerve cells, and is particularly known for its role in the brain's reward system, with levels increasing in anticipation of rewards. Many addictive drugs affect dopamine pathways. Beyond the brain, dopamine also functions as a local messenger. Imbalances in the dopamine system are linked to several significant nervous system diseases, such as Parkinson's disease and schizophrenia, and many medications for these conditions work by influencing dopamine's effects.
This seems a reasonable summary as all the points it makes appear in the article's lead and so there's no hallucination. Note that Gemini lists its sources and it only lists the Wikipedia article so it presumably was just working from that. The language is still not easy as you have to understand concepts like "pathways" but it seems reasonably free of the technical jargon which makes the article's lead quite difficult. Andrew🐉(talk) 18:39, 4 June 2025 (UTC)[reply]
@Andrew Davidson Yeah but now do it a thousand times. Or ten thousand. The hallucinations will creep in. Note that Gemini lists its sources and it only lists the Wikipedia article so it presumably was just working from that. That is not how that works. The language is still not easy as you have to understand concepts like "pathways" but it seems reasonably free of the technical jargon which makes the article's lead quite difficult. If the problem is that the leads of the articles are difficult to understand, one solution could be direct people to simple.wiki. Another idea is to set up a taskforce/wikiproject whatever. Another idea is to use available Readability-tools (via some API):
Average Reading Level Consensus
Automated Readability Index
Flesch Reading Ease
Gunning Fog Index
Flesch-Kincaid Grade Level
Coleman-Liau Readability Index
SMOG Index
Original Linsear Write Formula
Linsear Write Grade Level Formula
FORCAST Readability Formula
Combine that with the pageview data (pageviews.wmcloud or the dump) and then check which are the hardest and try to improve those. There are thousands of ways to deal with this perceived problem ethically and uncontroversially. Polygnotus (talk) 18:51, 4 June 2025 (UTC)[reply]
Running things ten thousand times would be a significant experiment and that's what the WMF are proposing. The results are unlikely to be perfect but the starting point here is that the current human-generated article leads are far from perfect. It would be good to gather statistics on just how bad the current situation is using readability tools and other consistency checks. We'd then have a baseline for assessing potential improvements. Andrew🐉(talk) 20:09, 4 June 2025 (UTC)[reply]
maybe the WMF is not using a good AI I share this concern as well. The WMF is using Aya, and while I understand the choice of using an open-source multilingual LLM, I question whether Aya's accuracy is good enough, and whether it's better than ChatGPT, Gemini, or other LLMs. If the accuracy is worse, why would we use it? Why we re-create what is already available? The only way this makes sense is if the LLM used produced a better summary than what Google is already showing users with Gemini. I question whether any LLM on the market today has sufficient accuracy. Levivich (talk) 19:09, 4 June 2025 (UTC)[reply]
I question whether any LLM on the market today has sufficient accuracy. No need to question that, there is no sufficiently accurate AI for this task. Polygnotus (talk) 19:13, 4 June 2025 (UTC)[reply]
maybe the WMF is not using a good AI is not really the problem with hallucination. LLMs are inherently stochastic and will hallucinate sometimes if you run the model enough times. Just because you got better results with a test run of one model doesn't imply you'll always get that. Dan Leonard (talk • contribs)19:16, 4 June 2025 (UTC)[reply]
I don’t like that it’s not in wikivoice, either. Or that it’s loaded with AI words to watch. Seriously disheartening, and disrespects all of the amazing work that AICLEAN users have been doing to keep these issues out of articles. This is exactly the kind of text we are searching for to remove.
How do we clean this? Do we need to plan ahead with templates like, “the above AI summary contains the following errors”? What if these summaries appear on top of meticulously planned CTOP leads like Donald Trump, which are built on dozens of established and coded consensuses, down to the precise words chosen? 3df (talk) 01:15, 4 June 2025 (UTC)[reply]
I had to draftify a pretty ridiculous percentage of new articles as AI-generated articles during the recent WP:NPP backlog drive. To have this now shoved onto Wikipedia anyway is incredibly disheartening, and if it went through, I'd genuinely consider quitting editing altogether. 🌸wasianpower🌸 (talk • contribs) 04:18, 4 June 2025 (UTC)[reply]
I had the opportunity to see a generated summary for the dopamine article, shown by another editor since I am not part of the roll-out myself. It was not quite the same, but equally if not even more dreadful to read. The very first words called it a "special molecule" and I almost lost it then and there. Let's put and end to this madness early. Choucas0 🐦⬛⋅💬⋅📋09:00, 6 June 2025 (UTC)[reply]
Dopamine is a special chemical in our bodies, like a messenger between brain cells. It's mostly known for making us feel good when we do something fun, but it's also about motivation and wanting rewards. It helps us move, focus, and even controls some hormones.
In the brain, dopamine is like a traffic light, directing how cells communicate. When we expect something good, dopamine levels rise. Drugs that affect dopamine can change how we feel and act, which is why some are used to treat health issues like Parkinson's disease or ADHD.
A two-week experiment on the mobile website seems to be the most immediate hazard; such an experiment would harm readers and negatively affect our reputation as a fairly reliable, non-AI source of information. Instead of freaking out, we should come up with some plan to persuade the WMF that this not a good idea and to stop them from rolling this out at any level.
Should the Wikipedia community do something to prevent or protest this "experiment", and if yes, what can/should we do? Cremastra (u — c) 21:25, 3 June 2025 (UTC)[reply]
@Cremastra We should blast this survey link to everyone and anyone, and have them fill it out. Start an RFC with it. Spread it on Discord and IRC and post it on Village Pumps et cetera.
I already filled out the survey through the usual method. People are welcome to fill out the survey but I don't think we should submit multiple responses each. Something like an open letter to the WMF would be more effective than screwing around with their data. Also, if in reality the survey is an overwhelming "no", intentionally skewing the results would compromise their legitimacy. Cremastra (u — c) 21:30, 3 June 2025 (UTC)[reply]
@Cremastra The legitimacy the survey had was already zero, because they are intentionally choosing not to actually ask the community about it. Because we don't use surveys on Wikipedia, we use talkpages and RfCs and Village Pump discussions and the like. So the fact that they are intentionally evading our consensus building mechanisms makes that survey null and void already. Polygnotus (talk) 21:33, 3 June 2025 (UTC)[reply]
@Scaledish No, the survey results are hidden. So unless you hack their account or the Qualtrics database you have to trust them when they report the results. But the fact that they use an external survey service instead of the normal ways to get consensus on Wikipedia, and that I had to search through their JavaScript to find the link, shows that they did not want us to voice an opinion and did not want me to share this link... Polygnotus (talk) 02:00, 4 June 2025 (UTC)[reply]
@Polygnotus Thank you for finding the link. I tried for a good 10 minutes to be presented with the survey that is being given to editors and I was never given it. A/Bing that survey is gross. Scaledish! Talkish? Statish.02:02, 4 June 2025 (UTC)[reply]
@Scaledish Yeah if this survey was above board and an honest way to gauge consensus, why hide the link? Why not invite everyone to voice their opinion? I am no conspiracy theorist, but this seems fishy. Polygnotus (talk) 02:06, 4 June 2025 (UTC)[reply]
I mean, there's nothing wrong with that policy-wise, if they did actually insist on it, but it might be a tad extreme. Cremastra (u — c) 21:37, 3 June 2025 (UTC)[reply]
If some random user implemented this – adding an AI summary to every article – after this discussion made it clear there was no consensus to do that, that user would be cbanned even if the summaries were accurate. 3df (talk) 23:27, 3 June 2025 (UTC)[reply]
In the world of community-WMF squabbling, our standard playbook includes an open letter (e.g. WP:OPENLETTER2024), an RfC with community consensus against whatever the WMF wants to do (e.g. WP:FR2022RFC) or in theory some kind of drastic protest like a unilateral blackout (proposed in 2024) or an editor strike. My preference in this case is an RfC to stop the silliness. If the WMF then explicitly overrides what is very clear community consensus, we're in new territory, but I think they're unlikely to go that far. Cremastra (u — c) 21:36, 3 June 2025 (UTC)[reply]
@Cremastra Maybe you can start an RfC on a very visible place? Something like:
The WMF has started a survey to ask if we want to put an AI summary in every article's lead section.
I took the survey. Its questions are confusing, and watch out for the last question: the good-bad, agree-disagree direction for the response buttons is REVERSED. Sloppy survey design. – Jonesey95 (talk) 21:40, 3 June 2025 (UTC)[reply]
I just hit this survey in the wild so to speak, so I did fill it out due to seeing it there. That last question switcheroo totally threw me, I don't think those results will be usable. CMD (talk) 02:54, 4 June 2025 (UTC)[reply]
I noticed that too. I'm not convinced it wasn't on purpose. In any case, I wouldn't trust the results of that last part. DJ-Aomand (talk) 11:39, 4 June 2025 (UTC)[reply]
As I said at the top, I think our immediate concern should be the actual proposed experimentation, not the survey.
I was thinking something along the lines of
The WMF has proposed testing AI-generated summaries appended in front of article leads (example). Does the community approve of this use of AI, or is this inappropriate and contrary to Wikipedia's mission? Cremastra (u — c) 21:42, 3 June 2025 (UTC)[reply]
They will use the survey as a weapon and pretend it gives them free reign to do whatever they want. A lot of people here will simply leave the second they see such an implementation of AI on a Wikipedia page, because that goes against everything we stand for. Getting those people back will be near impossible. Polygnotus (talk) 21:44, 3 June 2025 (UTC)[reply]
If the WMF feels like acting with impunity, they'll do so. There has been little to no response from the WMF on this page, which suggests to me they're just going to roll ahead with their fingers in their ears. Which as thebiguglyalien points out above, may remind you of a certain guideline. Cremastra (u — c) 21:46, 3 June 2025 (UTC)[reply]
I am certain @EBlackorby-WMF: is not doing this because they are evil, I honestly believe these are goodfaith people who do not understand what they are saying, and what the consequences of their words are.
If I say things like They are proposing giving the most important screen real estate we have (the WP:LEAD) of every article to a for-profit company. they haven't looked at it that way, because that is not how they think.
I do not think they should be banned/blocked, I think they should be educated. But we must stop them from doing more damage, one way or the other. Polygnotus (talk) 21:51, 3 June 2025 (UTC)[reply]
No one here thinks the WMF or any of their employees are "evil"; that is a ludicrous word to be using. If the WMF would respond to the feedback on this page (which is overwhelmingly against the proposal), it would reasssure me and many others. The present state of silence is what worries me. Cremastra (u — c) 21:53, 3 June 2025 (UTC)[reply]
Yes, some people here honestly think the WMF is evil. Seriously. I even had to defend them in the context of the ANI vs WMF courtcase thing. They were falsely accusing the WMF of throwing those editors under the bus and abandoning them. Complete nonsense of course. But yeah some people do harbor an irrational hatred against the WMF. Polygnotus (talk) 21:56, 3 June 2025 (UTC)[reply]
Y'all, please take a look at Special:Log/newusers/EBlackorby-WMF and do the math. She's been around for three (3) weeks. She very likely has no input into the design of any of this. You could make her job easier by just filling out the survey and encouraging everyone else to do the same.
That said, we need to keep in mind that "what readers think" and "what readers want" has very little overlap with what editors want. For example: We write complex texts that take half an hour or more to read; readers usually spend less than 10 seconds on the page. We provide dozens or even hundreds of inline citations; readers don't click on any of them for 299 out of 300 page views, and on the 1/300th case, they only click through to one (1) source. We usually have zero or one images in an article; readers would like a dozen or more. We (well, some of us) worry about Wikipedia's reputation; a surprising percentage of readers don't actually remember that they're reading Wikipedia. In other words, it's entirely possible that many readers would be completely happy with this, even though the core community will hate it. WhatamIdoing (talk) 04:41, 4 June 2025 (UTC)[reply]
@WhatamIdoingYou could make her job easier by just filling out the survey and encouraging everyone else to do the same. If they wanted us to fill in the survey, why didn't they post the link?
it's entirely possible that many readers would be completely happy with this Good news for them, most search engines already include AI fluff that you explicitly have to opt-out of, so they can get their AI hallucination fix on any topic faster (and more conveniently) than they can reach Wikipedia. Polygnotus (talk) 04:45, 4 June 2025 (UTC)[reply]
And perhaps one based solely on the Wikipedia article, instead of Wikipedia plus who knows what else, would actually be an improvement for these readers. It doesn't interest me, but I'm not going to tell other people what they're allowed to read. WhatamIdoing (talk) 05:00, 4 June 2025 (UTC)[reply]
@Polygnotus, Matma said it nicely earlier. Let me say it a little less nicely: Tone it down, now. You are being needlessly antagonistic and on top of that bludgeoning this discussion. Find something else to do for a while. Izno (talk) 21:55, 3 June 2025 (UTC)[reply]
I was under the impression that discussion was broader and of the type that spends three months hammering out a wording. This is focused on a quick response to a specific issue. Cremastra (u — c) 21:43, 3 June 2025 (UTC)[reply]
Yes, I agree that's the impression, but I don't think that you can demonstrate consensus to do anything about this discussion without showing consensus in that discussion, without your own separate RFC. Izno (talk) 21:57, 3 June 2025 (UTC)[reply]
Even though (as mentioned above) that discussion is about AI development as a whole, a few WMF employees actually discuss Simple Summaries in a bit of detail over there, so it may be worth reading through. —Gestrid (talk) 06:26, 4 June 2025 (UTC)[reply]
If we can't, we will have to add a note that is displayed on every single article that tells readers to ignore the summary (and perhaps hide that note on desktop). —Kusma (talk) 10:58, 4 June 2025 (UTC)[reply]
I am just about the least qualified editor here, but I'd think spreading the survey and participating in the current AI development RfC should come before anything drastic. ⫷doozy (talk▮contribs)⫸21:52, 3 June 2025 (UTC)[reply]
I suggest starting an RfC at the VPProposals page with a simple question ("Should English Wikipedia articles offer AI-generated summaries?" or something like that) and a link to the mediawikiwiki:Reading/Web/Content Discovery Experiments/Simple Article Summaries project page. Keep it simple. I predict that 99% of the users will !vote to oppose the feature, but at least with an RfC, the WMF will know where the "community" stands on this specific project. Some1 (talk) 22:49, 3 June 2025 (UTC)[reply]
Interface administrators have access to gadgets, user scripts, and sitewide JavaScript and CSS, not extension installation and configuration. Extension installation and configuration is done by WMF folks using a different process (patches and deploys of the operations/mediawiki-config repo in Gerrit). –Novem Linguae (talk) 07:58, 4 June 2025 (UTC)[reply]
Likely they could add CSS or JS to remove or hide the box with the AI content. Remember WP:Superprotect? That was added back in 2014 when German Wikipedia was doing much the same to hide MediaViewer. I don't think they'd try to bring back superprotect to fight back if we did it, but they might do other things. Anomie⚔12:12, 4 June 2025 (UTC)[reply]
Nope. I was just making the point that interface administrators do not have direct control of MediaWiki extensions. As mentioned by some others, it's possible to break some things using hacks (in this case the hack would probably be an edit to MediaWiki:Mobile.css or MediaWiki:Common.css or similar). This would be similar to what Portuguese Wikipedia did to block IP addresses from editing. We should think very carefully before crossing that bridge though. That would be a major escalation with the WMF. –Novem Linguae (talk) 17:15, 4 June 2025 (UTC)[reply]
I will note that I've asked folks at the WMF to reconsider this decision. There probably needs to be a wider discussion (both internally and potentially onwiki) about the rules around what can and cannot be A/B tested (stuff like, "hey should we have a bigger donate button" doesn't require consensus, but this feels closer to a pseudo-deployment). I think it also might make sense to potentially spin this tool in a different direction, say as an LLM that highlights hard technical language text on the lede that the user can then fix. (I think the core problem here still definitely needs addressing) Sohom (talk) 13:10, 4 June 2025 (UTC)[reply]
I don't think we can begin to discuss spinning such a feature in the direction of highlighting "hard" or "technical" language without clearly defining what that threshold should be. What reading level are we aiming for across ENWiki? Grabbing a quote from the mediawiki page on the usability study for Simple Article Summaries:
"Most readers in the US can comfortably read at a grade 5 level,[CN] yet most Wikipedia articles are written in language that requires a grade 9 or higher reading level. Simple Summaries are meant to simplify and summarize a section of an article in order to make it more accessible to casual readers."
A grade 5 level would mean that all lede sections would need to be completely understandable for a 10-11 year old. I fear simplifying text to this degree will end up reducing the nuance present in articles (which, per its nature, is already reduced in the lede). The Morrison Man (talk) 13:23, 4 June 2025 (UTC)[reply]
I think it's fine for editor-facing tooling to be wrong at times, (assume a lower grade/have the grade be configurable) primarily cause editors have the ability to make judgement calls and not show parts of the text, something that readers can't. Sohom (talk) 14:30, 4 June 2025 (UTC)[reply]
I personally find it very problematic that we cannot do 2 week experiments. Experimentation is the basis of learning, of evolving of knowing where to go from where you are. If a two week experiment is this problematic, I think we should question the longevity of the project (on a generational scale). If people want to give input, they should give input, but that shouldn't block a 2 week experiment. —TheDJ (talk • contribs) 13:27, 4 June 2025 (UTC)[reply]
@TheDJ I think the problem here isn't so much experimentation (which imo is fine), but rather the fact that this "feels like a deployment". Peeps who would see such a experiment would assume that Wikipedia is going the AI way (when it is not in fact doing that and is actively discouraging people from using AI in their writing). If the experimentation had community buy-in, I think we would have a completely different story. Sohom (talk) 13:32, 4 June 2025 (UTC)[reply]
Experiments are fine, when they are conducted ethically. That is especially true of experiments involving human subjects. In this case, it was proposed that we present potentially misleading AI content to readers, who would not be aware of, nor had consented to being, test subjects. For things like minor UI changes, such unknowing A/B type testing may indeed be ethical, but not for some massive change like that. Readers to Wikipedia do not expect to receive AI-generated material; indeed, one of the things I love most about Wikipedia is that it's written by people, and does not use any "algorithm" or the like to try to shove something in anyone's face. You just get the article you pull up, and if from there you want a different one, you choose which one you read next. Now, if there were an opt-in process for people to consent to being part of such an experiment and provide feedback, that might be a different story. SeraphimbladeTalk to me16:48, 4 June 2025 (UTC)[reply]
@TheDJ Let's not pretend that the community reacts like this because it is a 2 week experiment. That is the mother of all strawmen.
The whole thing is clear proof that the WMF is completely out of touch, does not understand its own role, and has no respect for the volunteers, or the readers. Polygnotus (talk) 18:27, 4 June 2025 (UTC)[reply]
It's not "proof". It's not close to "proof". It doesn't resemble proof in any way. Maybe it is confirmation of something for some people, but confirmation is weak. Sean.hoyland (talk) 04:44, 7 June 2025 (UTC)[reply]
At the same time as this underhanded attempt to sneak AI slop into the content, they are also making a request on meta to run test donation banners more often exclusively on enwiki. Starting at the extreme so as to work backwards, I suggest revoking all donation banner permissions until such time as everyone employed by or elected to WMF and affiliate roles with generative AI COI or positive views towards the same are terminated and prohibited from holding elected office. Competence is required. Awareness of community norms is required for anyone holding an elevated role on enwiki. Hold WMF to the same standards as you hold admins and contributors. Recall the WMF. 216.80.78.194 (talk) 20:08, 4 June 2025 (UTC)[reply]
This is a prime reason I tried to formulate my statement on WP:VPWMF#Statement proposed by berchanhimez requesting that we be informed "early and often" of new developments. We shouldn't be finding out about this a week or two before a test, and we should have the opportunity to inform the WMF if we would approve such a test before they put their effort into making one happen. I think this is a clear example of needing to make a statement like that to the WMF that we do not approve of things being developed in virtual secret (having to go to Meta or MediaWikiWiki to find out about them) and we want to be informed sooner rather than later. I invite anyone who shares concerns over the timeline of this to review my (and others') statements there and contribute to them if they feel so inclined. I know the wording of mine is quite long and probably less than ideal - I have no problem if others make edits to the wording or flow of it to improve it.
Oh, and to be blunt, I do not support testing this publicly without significantly more editor input from the local wikis involved - whether that's an opt-in logged-in test for people who want it, or what. Regards, -bɜ:ʳkənhɪmez | me | talk to me!22:55, 3 June 2025 (UTC)[reply]
I mostly agreed with the thrust of your statement formulation before, but unfortunately this case makes it seem too weak. Bluntly, whether we are informed is somewhat of a moot point here. The issues with the example should have been caught internally, far before they made it to the craft-a-custom-youtube-video-for-a-survey phase, and far before they would need to inform communities. In the survey linked above, the tool blatantly and obviously fails on its own merits for its own purpose. To be at the two-week live test phase now, with the tool as it is? Informing us is not the issue. CMD (talk) 02:17, 4 June 2025 (UTC)[reply]
Another approach would be to no longer allow the WMF to monetize the work of Wikipedians, and instead run our own banners to collect money for a new war chest. The WMF will never take the community seriously as long as they are the only possible provider of what we need. If there is a viable alternative that will change. Polygnotus (talk) 02:26, 4 June 2025 (UTC)[reply]
Proposals to create an alternate WMF are not going to be helpful to this discussion. We are an existing community trying to work with the WMF, forking is a distraction. CMD (talk) 02:56, 4 June 2025 (UTC)[reply]
In the technical sense, we are capable of doing that as is. In practical and logistical senses, it would take moving some mountains which lie far outside the scope of this discussion. CMD (talk) 03:02, 4 June 2025 (UTC)[reply]
I think we should start thinking seriously about forking, and hosting the project in a more transparent and hands-off way (and possibly not in the US). The WMF has been showing hostility and disregard towards the community for many years, and it's only a matter of time before the community loses control of the project completely. Ita140188 (talk) 07:37, 12 June 2025 (UTC)[reply]
Cool down y'all, threatening forking is not constructive. I would encourage y'all to find other more constructive ways of adding to the conversation. Sohom (talk) 12:51, 12 June 2025 (UTC)[reply]
How is it not constructive? The WMF has been willing to interfere in destructive ways into the work of the community without really taking into account any feedback. Previous cases show that controversial projects are paused only temporarily when there is an uproar, just to be later reinstated in disregard of the comments when things cool down. The includion of LLMs would be an extinction-level event for our community of volunteers and for the project. Many (including me) would choose to stop contributing altogether if any AI was included in Wikipedia content. When LLMs are free to add content, the whole project would be tainted by false or misleading information that would be difficult to rectify, bias that would be impossible to detect, and at a scale that would be impossible to deal with by human volunteers. In this situation, a fork would be the only way to save this community and the Wikipedia project from destruction. Ita140188 (talk) 12:59, 12 June 2025 (UTC)[reply]
Threaten it/Do it when the "extinction-level" event comes to pass, not when the WMF appears to be taking the feedback to heart. For now, find other avenues to contribute to the discussion other than threatening forking. Sohom (talk) 13:05, 12 June 2025 (UTC)[reply]
It does not seem to be that they are "taking the feedback to heart". They are not even cancelling this mess, they are merely pausing it. This shows to me a complete contempt for the community, which is overwhelmingly opposed to this idea (and nobody ever asked for it before). All this while they have shown very little interest to work on actual problems that the community highlighted over the years, from the chart library that has been broken for two years (only to be replaced this month by an half-assed alternative, see mw:Extension_talk:Chart#An_example_of_all_that_is_wrong_with_this_extension) to the community wishlist (meta:Talk:Community_Wishlist), which has by now become a joke by how slow and ineffective it has become. Ita140188 (talk) 13:23, 12 June 2025 (UTC)[reply]
Fair point. I would say "almost-complete contempt". Presumably, it will be complete in a couple of months when this "experiment" is likely resumed. Ita140188 (talk) 13:30, 12 June 2025 (UTC)[reply]
@Ita140188, You do realize that everything that you mentioned on the Charts page are fixes that, while they might seem simple to you require significant effort to fix ? If you feel like you can do them faster and more efficiently than the WMF, feel free to help out by writing the software for it. I see pausing as a step in the right direction over steamrolling the community and proceeding with the the changes as intended. (No notes on the Communiy Wishlist, but I believe I did something of the effect that the WMF is planning on putting in some effort to fix it soonish) As I've mentioned somewhere else in the thread the overarching project is the simplification of articles, not necessarily the usage of AI. It would make sense for them to continue this workstream without specifically using AI. Sohom (talk) 13:31, 12 June 2025 (UTC)[reply]
I am very aware of the effort needed to bring these kinds of project to production, since I work on this stuff all the time. Obviously it's not something that single volunteer can do alone, nor I implied that. That's why there is a huge team of paid developers at the WMF whose job should be to do this. If at my company we had a critical vulnerability discovered that forced us to disable a central tool used in hundreds of pages, we would rush to find a solution and put the resources necessary to fix it within weeks, not years. The WMF has more than enough resources to do this (and to maintain the tools over time, since the original problem was the Vega extension had not been updated for years). Instead they prefer to focus their resources on projects like this AI summary tool, that are way more complex, controversial, and that nobody asked for. Ita140188 (talk) 13:44, 12 June 2025 (UTC)[reply]
We may need to start another RfC that says something like: "The WMF is not allowed to use secret surveys and has to use the conventional Wikipedia consensus building methods (talkpages, RfCs, et cetera)." Polygnotus (talk) 02:19, 4 June 2025 (UTC)[reply]
Hm. Originally I thought this was some kind of A/B test and we should let the experiment play out without interference...for science! But now that I've seen the questions, this is not an A/B test. This is trying to gauge community support. It is trying to be an RfC. It should not have been hidden and doled out randomly. It should have been a public survey. Consider me suitably outraged. Toadspike[Talk]03:21, 4 June 2025 (UTC)[reply]
It might be more worrying that editors don't grasp the point of random sampling. Public surveys, and even quasi-private ones, tend to get a lot more responses from certain types of contributors (e.g., editors with >30K edits) than others. If you want to know what everyone thinks, then posting the link to a page where mostly highly active editors will see it (and only a tiny fraction of them – only 1 in 500 registered editors ever posts to the Village pumps, and even if you look only at WP:EXCON editors, it's just one in six of them) is not a way to go about it. Surveying a biased sample set is exactly the kind of bad behavior by survey operators that we see at Wikipedia:Fringe theories/Noticeboard all the time, so we shouldn't be advocating for using it here. WhatamIdoing (talk) 04:57, 4 June 2025 (UTC)[reply]
@WhatamIdoing As someone whose second-favourite book is about lying with statistics... any choice you make is wrong, and it is about choosing the lesser of a bunch of evils. This was a terrible choice. Polygnotus (talk) 05:01, 4 June 2025 (UTC)[reply]
If your goal is to get an accurate understanding of the sentiment in a given population, and you believe that 100% responses are unlikely, then proper random sampling is not "the lesser of a bunch of evils"; it is the right choice.
If your goal is to show off that you subscribe to some non-scientific human values (e.g., "transparency!" or "following our conventional consensus-building methods"), then of course you wouldn't want to do things in a statistically sound manner. Instead, you'd want to take a leaf from the marketing manuals. I could suggest a model that I believe would work, except that (a) I don't think marketing-led software development is the right approach for Wikipedia, and (b) I don't want to provide a manual on how to do it. WhatamIdoing (talk) 05:12, 4 June 2025 (UTC)[reply]
@WhatamIdoing You are invited to come read the book. It has an entire chapter that deals with problems such as this (and ethics more broadly).
The idea that this is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuff has historically been proven to be a bad one. You most likely know a bunch of examples.
Who cares about a statistically sound manner of doing research when someone is proposing to give the best screen real estate we have, the lead sections of our articles, to some multi-billion dollar AI company, and to use the volunteers as free labour?
Sorry, I can't pretend that there is a discussion to be had about survey methodology instead of one about incompetence and disrespect for the volunteers. Polygnotus (talk) 05:21, 4 June 2025 (UTC)[reply]
Random sampling is neither "bad" nor "unethical". NB that I'm talking about your suggestion above that "The WMF is not allowed to use secret surveys and has to use the conventional Wikipedia consensus building methods (talkpages, RfCs, et cetera)." and not about whether AI is desirable in general, or this proposed use is desirable in practice. WhatamIdoing (talk) 20:29, 4 June 2025 (UTC)[reply]
It sure looks like you did: "The idea that this [random sampling and proper statistical standards] is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuff". WhatamIdoing (talk) 20:35, 4 June 2025 (UTC)[reply]
I wrote: The idea that this is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuff has historically been proven to be a bad one.
You wrote: It sure looks like you did: "The idea that this [random sampling and proper statistical standards] is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuff".
Square brackets are a convention in the English language to identify words that have been added as a clarification by an editor. You might have run across that in academic sources in the past.
I am using this convention to tell you what I understood the Antecedent (grammar) of the pronoun "this" in your sentence to mean. A typical response to such a statement sounds like one of these two:
'I apologize for being unclear. When I wrote "The idea that this is somehow science...", I didn't mean statistics; I meant "The idea that [fill in the blank with, e.g., 'AI' or 'marketing' or whatever is somehow science..."', or
'Yes, you understood me correctly. I think it's wrong to consider random sampling and proper statistical standards to be any type of science. Instead, I think statistics should be considered a [fill in the blank with, e.g., 'non-science like fine artwork' or 'a pseudoscience like Time Cube']."
The idea that this is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuffhashistoricallybeenproventobeabadone.
+
The idea that this [random sampling and proper statistical standards] is, somehow, "science", and that therefore we can do all kinds of bad/unethical stuff
Another shady and sneaky way to muddy the waters and get what they want against overwhelming consensus here against this idea. Non-transparent polls with misleading and biased questions like these have no place in this community Ita140188 (talk) 13:28, 12 June 2025 (UTC)[reply]
A decade ago, work-me ran one of these surveys. We offered an on-wiki version and an off-wiki (Qualtrics) version. We got about 500 (yes, five hundred) responses in Qualtrics and just two (2) on wiki. People voted with their feet, and I've no reason to believe that it would be any different for any other survey. You might not approve of their choices (it's ever so much easier to argue with people who give the 'wrong' answer if it's on wiki, with their username right there...), but these are the choices people make, and I'd rather get 500 responses in Qualtrics than just two (or even ten) on wiki. WhatamIdoing (talk) 04:49, 4 June 2025 (UTC)[reply]
Speaking of evil, I noticed as I landed on the last page that the order of good and bad responses had been switched at one point during the survey. Can't help but feel like they did this intentionally. LilianaUwU(talk / contributions)05:19, 4 June 2025 (UTC)[reply]
There are indeed benefits to random sampling. Asking "do you like this new feature or not" is fine. But the survey asks several questions about who should moderate this new content which would certainly be subject to community approval later anyways, which is weird. Toadspike[Talk]10:19, 4 June 2025 (UTC)[reply]
I also was thrown off by the switch from "agree"/"disagree" to "unhelpful"/"helpful" and it almost caused me to vote in favor of AI usage. Whether from deception or incompetence, it renders the results of last set of questions completely useless as there's no way to know how many people voted incorrectly. Dan Leonard (talk • contribs)19:27, 4 June 2025 (UTC)[reply]
Do we have a list of the questions that were in the survey, since it is not available anymore? (talking about transparency...) Ita140188 (talk) 14:11, 12 June 2025 (UTC)[reply]
To answer the question asked in the section title. No.
Lets tone down the the witch hunt. (Also yes, the number of tasks mentioning AI might be more, but Tone Check and Simple Article Summaries are the only two WMF led ones planned for now). Sohom (talk) 11:48, 4 June 2025 (UTC)[reply]
@Sohom Datta @Polygnotus Similar to summaries, WMF already started experimenting pushing raw machine translaton as articles in non-Engllish languages. This is also labeled as experiment, targetted for smaller languages. So you won't hear much voice from those our small wikis. https://phabricator.wikimedia.org/T341196. As far as I can tell both these experiments are similar and unethical. MT output from ML models for smaller languages are unusable without human edits and attempts to replace editors in smaller wikis. 2405:201:F009:9906:F2EE:64D9:BD6F:E8FB (talk) 08:42, 5 June 2025 (UTC)[reply]
Unfortunately, I have to pick my battles. And I don't speak any of those languages so I have no clue how to judge the translations. I just know that when I talk to any AI in a language other than English the quality degrades substantially and noticably. Polygnotus (talk) 12:48, 5 June 2025 (UTC)[reply]
I'll take a look at this later, but to my understanding reading the related Phabricator tasks, the content that is auto-translated is fairly well marked as being a auto translation and the button is at the end (not at the start) of articles (and feature prominent call to actions to improve and add the translations to the Wikipedia articles). Given the state of many language editions I see this as a net positive for smaller wikis and not necessarily a attempt to "replace editors". Sohom (talk) 16:58, 6 June 2025 (UTC)[reply]
Hey everyone, this is Olga, the product manager for the summary feature again. Thank you all for engaging so deeply with this discussion and sharing your thoughts so far.
Reading through the comments, it’s clear we could have done a better job introducing this idea and opening up the conversation here on VPT back in March. As internet usage changes over time, we are trying to discover new ways to help new generations learn from Wikipedia to sustain our movement into the future. In consequence, we need to figure out how we can experiment in safe ways that are appropriate for readers and the Wikimedia community. Looking back, we realize the next step with this message should have been to provide more of that context for you all and to make the space for folks to engage further. With that in mind, we’d like to take a step back so we have more time to talk through things properly. We’re still in the very early stages of thinking about a feature like this, so this is actually a really good time for us to discuss here.
A few important things to start with:
Bringing generative AI into the Wikipedia reading experience is a serious set of decisions, with important implications, and we intend to treat it as such.
We do not have any plans for bringing a summary feature to the wikis without editor involvement. An editor moderation workflow is required under any circumstances, both for this idea, as well as any future idea around AI summarized or adapted content.
With all this in mind, we’ll pause the launch of the experiment so that we can focus on this discussion first and determine next steps together.
We’ve also started putting together some context around the main points brought up through the conversation so far, and will follow-up with that in separate messages so we can discuss further.
With all this in mind, we’ll pause the launch of the experiment so that we can focus on this discussion first and determine next steps together. Wonderful. Thank you very much. Cremastra (u — c) 13:36, 4 June 2025 (UTC)[reply]
Concurring with the other editors below. Thank you very much for pausing, but I think the next steps should be an agreement to not go forward with this at all. It doesn't take an admin to see that there is overwhelming consensus here against this proposal, and this website operates by consensus. This proposal should be treated as any other, from any editor, but in this case it has been clearly rejected by the community. Cremastra (u — c) 15:00, 4 June 2025 (UTC)[reply]
Thank you for listening to the community on this one - but may I suggest simply scrapping the whole idea? I fail to see any way it will ever be acceptable to the vast majority of editors. CoconutOctopustalk14:12, 4 June 2025 (UTC)[reply]
@CoconutOctopus I think there are valid ways of implementing this idea, perhaps as a stand-alone browser extension, or maybe even as a tool that highlights technically worded or hard to understand text for editors or for that matter, maybe a tool that popups up relevant related articles to look at for definitions of technical terms. I would not call for scraping this line of work, but I would definitely call for caution since it can be easy to accidentally erode trust with readers. Sohom (talk) 14:27, 4 June 2025 (UTC)[reply]
Glad to hear this. Please keep in mind that while it's true that editor involvement is essential, volunteer time is our most precious resource, and a lot of us are already spending a lot of that time cleaning up AI-generated messes. -- asilvering (talk) 14:17, 4 June 2025 (UTC)[reply]
Good reminder about the influx of AI garbage at AfC and NPP as a key context here. I think this proposal felt particularly misguided because it was actively counter to editors' most pressing needs re: AI, namely, anything that could help us spend fewer hours of our precious youth carefully reading content that no human took the time to write. ~ L 🌸 (talk) 17:16, 4 June 2025 (UTC)[reply]
Indeed. AI tools that help editors identify which articles are most likely to be most in need of a more simplified lead? That could be hugely useful. AI tools that give us more shit to shovel, while dealing possibly irreparable harm to our current image as "the last best place on the Internet"... I'll pass. -- asilvering (talk) 17:26, 4 June 2025 (UTC)[reply]
I think I'm with CoconutOctopus on this one. What you're seeing here isn't like the initial opposition to Visual Editor (where it wasn't yet fit for purpose, but one day might be, and indeed after more effort was put into it, it was and it was then pretty readily accepted). This is primarily opposition to the proposal altogether, that AI-generated material would ever be presented as article content. I do not see any way that such a thing could ever be acceptable, regardless of what was done with it. SeraphimbladeTalk to me14:30, 4 June 2025 (UTC)[reply]
Echoing the other editors. There is absolutely zero way in which I would ever be comfortable with presenting readers with AI generated content. Your step back is a little win, but I definitely don’t like the implication that you will return in the future. Scaledish! Talkish? Statish.14:54, 4 June 2025 (UTC)[reply]
Thank you very much for listening to the needs of the community! The idea did get me thinking: while there is strong opposition to AI-generated content, I haven't seen as much discussion about the other part of the idea, namely, bringing summaries to articles. While, in most articles, it would be redundant with the lead, a "simple summary" could be interesting to consider for articles with a long and technical lead. The infrastructure for this project can definitely be used to work on an implementation of volunteer-written summaries on technical articles, if the community and the WMF are both interested! Chaotic Enby (talk · contribs) 15:09, 4 June 2025 (UTC)[reply]
I'm realizing that it could be done with a template (maybe a reskin of a collapsible box) and would not necessarily need WMF involvement, although their help would still be welcome for some technical aspects like Visual Editor integration and for A/B testing variants of the format once the idea has community consensus (if that happens). Also thinking that, since these summaries would be user-editable, it might be neat to have a gadget to edit them directly (like Wikipedia:Shortdesc helper and the lead section edit link). Chaotic Enby (talk · contribs) 15:31, 4 June 2025 (UTC)[reply]
Indeed, and a tool that would help editors with these might be useful, as opposed to creating new layers of summaries. CMD (talk) 19:01, 4 June 2025 (UTC)[reply]
Infoboxes are yet another type of summary. And the proposed feature seems rather like Page Previews which are another existing type of article summary. Wikipedia has a problem of proliferating complexity -- see feature creep. Andrew🐉(talk) 22:16, 4 June 2025 (UTC)[reply]
Grateful for a) the editors that spoke up here, and b) WMF for recognizing community concerns and agreeing that this needed to be paused. Just adding my voice to say - with no ill will toward the teams that developed it - this seems like an extremely bad idea on its face. 19h00s (talk) 15:39, 4 June 2025 (UTC)[reply]
To reiterate what others have said, I do not see any scenario in which I support any readers or editors, ever, viewing AI-generated content on Wikipedia. This project is fundamentally against the Wikipedia ethos and should be done away with entirely. —Ganesha811 (talk) 16:44, 4 June 2025 (UTC)[reply]
@OVasileva (WMF): I hope the WMF will use randomly-selected surveys of editors and readers to gather feedback rather than self-selected surveys, because
self-selected surveys (like comments on wiki talk pages) will always result in skewed feedback. Those of us who want the WMF to keep iterating, experimenting, and testing may not be as vocal as others but we may be more numerous, who knows. Levivich (talk) 17:03, 4 June 2025 (UTC)[reply]
I think there are a lot of contexts where I would agree with this sentiment - that is the comments are a form of elite that are not representative of a bigger group. However, in this case where there is going to be an explicit need for editor moderation, a discussion with 85 participants probably does have some degree of representativeness of the kinds of people who would then do that moderation. Best, Barkeep49 (talk) 18:52, 4 June 2025 (UTC)[reply]
A bit late to this conversation, but I agree with the "Yuck" sentiments. I think that a pause on development on this feature is insufficient, and a cancellation is the minimum acceptable response here, and ideally should include better communication so wee don't ever get 2 weeks away from something like this again. Do we need a RFC now to give our interface admins preclearance to remove these summaries if the WMF ever does roll them out? Tazerdadog (talk) 20:34, 4 June 2025 (UTC)[reply]
I'll have to agree with everyone else: it shouldn't be a pause on development, it should be an outright cancellation. We're the last mainstream website without AI being continually rammed down our throats, and it should remain that way. LilianaUwU(talk / contributions)22:11, 4 June 2025 (UTC)[reply]
Hi all (ping @Polygnotus and @Geni). I’m Marshall Miller, working with Olga (but in a different timezone!) Thanks for noting this — the survey is still running. It’s too late in the day for the team to turn it off from a technical perspective — tomorrow is the soonest we can do it. And I understand your concern — we don’t want this survey to accidentally convey that we are definitely building/deploying this feature broadly. I’m hopeful that by the time we can turn it off, there will be enough data collected for us to be able to look at informative results together (staff and volunteers). MMiller (WMF) (talk) 02:10, 5 June 2025 (UTC)[reply]
I’m hopeful that by the time we can turn it off, there will be enough data collected for us to be able to look at informative results together (staff and volunteers). Note that the survey is incredibly flawed in a bunch of ways, so it is impossible to draw conclusions from it. Also note that surveys are not how we make decisions here, the Wikipedia community has discovered that our consensus-based model is superior to simple voting. It would be very good to have a retrospective where we can discuss what went wrong and how we can avoid making similar mistakes in the future. Also, I am pretty sure that the community wants assurances that something like this won't happen again. They are already drafting up ways to tell the WMF to stop doing this.
As a nerd I like AI stuff and I use AI every day, but as a Wikipedian I know how careful we gotta be if we want to use AI properly on Wikipedia. Polygnotus (talk) 02:25, 5 June 2025 (UTC)[reply]
Actually, I think the survey results could be very interesting. If they are based on the dopamine summary, how many people picked up on its flaws? Some would be quite obvious just reading the lead. If they did not, they that's an interesting signal of how much what we (Wikipedia) show people is trusted implicitly. There has been research that readers never view sources etc., perhaps that's because they believe we have vetted things. Maybe they assume the same for these summaries. CMD (talk) 04:22, 5 June 2025 (UTC)[reply]
Using AI to generate content should be a bright red line. One thing that might be helpful is a tool on talk pages that identifies useful sources for the article in question (excluding sources already in the article) Kowal2701 (talk) 09:32, 5 June 2025 (UTC)[reply]
I think you'd be hard-pressed to find anybody who would interpret interested wikis as anything but "wikis whose volunteer communities have expressed interest in taking part in the development of this project". It is technically not the case that this came completely out of the blue as some claim on this page (so I'd have some sympathy if you felt accused of things you didn't do), but if you took the lack of response to the thread as an indication not that enWP was not interested and the project was unwelcome, but that you could proceed with it without more consultation with the community, then I think that encapsulates the disconnect between WMF and the community expressed here really well. Nardog (talk) 13:02, 5 June 2025 (UTC)[reply]
I look forward to going over this conversation a decade hence and following up with all the people who said that this or that computer thing will a priori "never" be able to do this or that task — historically the record has not been great on these predictions. Does anyone remember a couple years ago when a bunch of people considered it a knock-down refutation to say Stable Diffusion couldn't draw fingers, and that it would never ever ever be possible for a computer to draw fingers? jp×g🗯️13:44, 5 June 2025 (UTC)[reply]
It's possible (and even likely) that AI will get better - and I tend to think that summarization of existing content is an AI strength, as opposed to creating new content, which is a definite weakness. But that misses the point. In a world which will increasingly be dominated by AI-generated content, from AI slop on up, Wikipedia can and should be different. We should lean into the fact that we are a human project, written and managed by volunteers. Wikipedia is already one of the last bastions of AI-free content online while the world turns into an echo chamber of LLMs regurgitating material at one another. —Ganesha811 (talk) 13:57, 5 June 2025 (UTC)[reply]
Whether or not LLMs are capable of becoming reliable sources in the future, they aren't reliable sources right now, and so they shouldn't be used to generate reader-facing content until and/or if that happens. Gnomingstuff (talk) 18:13, 6 June 2025 (UTC)[reply]
If I wanted to read LLM-generated content, I would just go to an LLM and ask it to generate some content. I'll definitely never contribute (financially or otherwise), nor use, an LLM-generated wiki. Humans are experts at writing. We love writing. If you become an LLM-farm, you're removing any reason to ever visit this site. The whole internet just becomes one LLM app. I'm not interested. Pattmayne (talk) 20:37, 11 June 2025 (UTC)[reply]
A proper step back?
I may be wrong, but it seems to me that the deployment of AI for article descriptions is a bit of a solution in search of a problem. It looks like people want to use AI and then think this is a good way. Can we think about what the problems are on Wikipedia and how to solve them instead? Perhaps the answers involve AI, perhaps they do not. In the case at hand:
Is it true that lead sections are often too technical?
If yes, is there a way to identify which lead sections are too technical?
If yes, how can we improve these lead sections?
AI could possibly help with these things, but not by replacing our human written leads with AI generated ones. That is what software companies do who do not have an army of highly intelligent and opinionated volunteers working for them for free. (Google or Facebook might do these things, because they are technology based, but there is absolutely no reason for a human-based place like Wikipedia to replace human output by machine output; it is antithetical to the way we work). Any deployment of AI on Wikipedia must be subordinate to the humans, not replace them. So anyway, could we do the process the right way around: first identify a problem that needs solving, then discuss how to approach the problem and what tools to best use for it. —Kusma (talk) 19:03, 4 June 2025 (UTC)[reply]
Well put! I'm not 100% against any interaction between AI tools and Wikipedia - but they must be deployed judiciously on the back end to solve specific problems, not suddenly rolled out to 10% of all mobile users in a "test" in order to replace the work of human editors. —Ganesha811 (talk) 21:52, 4 June 2025 (UTC)[reply]
Yes, thank you for this. I see the implementation of AI—at least right now—similarly to putting WiFi in toothbrushes. Is it "the latest tech-y thing"? Yes. Does it make our lives easier? No. Relativity ⚡️02:48, 5 June 2025 (UTC)[reply]
@Relativity As someone who is strongly against this proposal I should say that using AI can truly be beneficial. They completely missed the mark on the Five Ws and how to communicate and all that, but the technology in itself isn't uniformly bad. I am using AI when I edit Wikipedia in ways that are beneficial and non controversial.
For example, Claude just wrote a script for me that shows the currently active surveys on my userpage. So if the WMF has another bad idea I will know about it.
And I have also used AI for things like detecting typos, missing words and other small imperfections. Ultimately, I take the decision and the responsibility, and the AI sometimes says a bunch of nonsense, but it can be a useful tool, if you know how to work with it. Polygnotus (talk) 02:55, 5 June 2025 (UTC)[reply]
@Polygnotus: I'm not saying that AI can't be useful—it can be, and I've used it before for different things. I use AI-powered tools all the time for work. Perhaps I should have reworded my earlier comment—I'm saying that it would not make our lives easier in Wikipedia in what is being proposed to be done. The new proposal may be adding AI to our pages for the same reason we'd put WiFi in toothbrushes. Relativity ⚡️17:01, 5 June 2025 (UTC)[reply]
You use AI well to suggest edits, and commit those you agree are improvements. I also used tools in that way, though I'm not sure I'd call them AI. That's a wholesome and beneficial use of AI but, as you say, not all of its suggestions are helpful and it does need a human filter. Certes (talk) 21:06, 6 June 2025 (UTC)[reply]
Hi @Kusma, you raise a lot of important questions. We agree with you that discussing the problem itself should take precedence over any specific solution. Thank you for starting this topic. While this may not have been super clear in our previous communications, different teams at the Wikimedia Foundation have been doing research in this area for the last few years before we started exploring possible solutions. I wanted to share some of this earlier research that originally made us curious about this problem space in case it's helpful and so we can discuss further:
This work started with a wider initiative to address knowledge gaps by the Research team at the WMF. One of the things this initiative focused on was improving the readability (how easy it is to read and understand a written text) of articles (Multilingual Readability Research). Some of their findings were also published in this public journal article https://arxiv.org/abs/2406.01835
I also find the background research page really valuable since it includes lists of other research done on this topic from within and outside of the WMF and within a variety of different contexts and topics. It includes different studies of how readable, accessible, and understandable Wikipedia content is over time and in different scenarios.
In general, content simplification has also been an area that many editors have also been interested in. This led to the rise of projects like Simple English Wikipedia, as well as the Basque Txikipedia (Wikipedia for kids). These projects have been successful, but they are only available in a few languages and have been difficult to scale.(Meaning, reader traffic as well as editor activity on these pages is much lower compared to, respectively, English Wikipedia and Basque Wikipedia.) In addition, they ask editors to rewrite content that other editors have already written. Our thinking was that there might be a way to make some part of this process easier. I’d be curious to hear of other options around this as well that could streamline simplification-type initiatives.
I'm curious what do others here think about this research, and the questions you raised about the technicality of lead sections? Do you see this as a problem impacting readers? OVasileva (WMF) (talk) 09:58, 5 June 2025 (UTC)[reply]
@OVasileva (WMF) Above you wrote: We’re still in the very early stages of thinking about a feature like this, so this is actually a really good time for us to discuss here. and here you write different teams at the Wikimedia Foundation have been doing research in this area for the last few years before we started exploring possible solutions.
Which is it? Is this the result of years of work, or did you just start thinking about this? Neither is a good answer of course, but at least the situation would be easier to understand if this was a friday afternoon rushjob. If not, then the problem is more fundamental than we feared. Polygnotus (talk) 10:09, 5 June 2025 (UTC)[reply]
From what I understand, the second statement refers to more generic research before exploring possible solutions (in that case, the Simple Summaries feature). Chaotic Enby (talk · contribs) 10:16, 5 June 2025 (UTC)[reply]
@Chaotic Enby That seems likely. But a team which has done years of research should be able to identify that this idea and approach were, ehm, sub-optimal. And you wouldn't expect them to push such a halfbaked rushjob to prod. And what I don't see is evidence that they understand the problem, which would be helpful if we want to move forward. Polygnotus (talk) 10:19, 5 June 2025 (UTC)[reply]
Probably a bad idea to respond only to 1 comment, the only comment that is not critical but asks about the underlying stuff. We are kinda waiting for a response to the other stuff. Polygnotus (talk) 12:12, 5 June 2025 (UTC)[reply]
@OVasileva (WMF): Thank you for being willing to respond to community feedback. I would like to add my voice to the chorus of people strongly opposed to the idea of AI summaries. For the English Wikipedia specifically, one option to consider for readability would be to advertise the Simple English Wikipedia more prominently. However, AI is simply too unreliable and unpopular among editors to consider at this point in time. QuicoleJR (talk) 12:44, 5 June 2025 (UTC)[reply]
I agree with the 100+ other people categorically rejecting pursuing this idea (AI-generated summaries) in any form. I am also very confused why seemingly at no point was there any "research" done on the fundamentals of Wikipedia editing and its community processes? Is no one in the research team an active, regular editor? I just can't see how this got as far as c. 5 days from test deployment without anyone realizing:
How unbelievably poorly this would be received among editors; anyone who was even marginally involved in the en.WP editing community would have anticipated the overwhelming negative sentiment exhibited above and nixed this immediately.
Do different WMF research teams not talk to each other? Surely the backlash against a vaguer AI-focused WMF "strategy" was communicated among employees?
That any wikipedia article summary must summarize the text actually in the article rather than whatever is in the LLM corpus; as @Chipmunkdavis demonstrated, the "dopamine" summary is both egregiously incorrect in its facts and divorced from what the article actually says.
That this is exactly the type of "increase clicks over quality" enshittification WP has been robust to for two decades because it was never intended to be a money-making platform dependent on page visits in the first place. I don't buy for a second that this project is just being funded to address "knowledge gaps". The WMF sees the hysteria over the TikTok generation having a 10-second attention span and the mass adoption of ChatGPT for topic overviews as an existential threat to its bloated budget, none of which even goes toward the people making its singular product (except WikiLibrary, thank you for that). If there was actual interest in closing "knowledge gaps" the WMF would fund digitalization and permanent storage of offline media from underrepresented countries/languages so that editors could use them as sources.
That expanding administrative duties, as suggested in the survey, is an incredibly intrusive overreach and absolutely should not have been floated without input from admins.
That the WMF's apparent expectation (and the obvious necessity) that volunteers will ultimately have to fine-tune and correct any AI hallucinations in these summaries utterly eliminates the provided reason for using AI in the first place (efficiently scaling up simplification efforts and expanding them to other languages) as the bottleneck will still be editor time and competency. Except now, rather than leads created through a self-selected collaboration of editors who are generally knowledgeable on the topic, we'd have potentially millions of error-ridden summaries that not only have to be evaluated by a human, but require an editor with expertise in the topic to read the entire article to ensure summary fidelity. And the intent is to deploy this for the topics that are currently written "too technical", i.e. the topics that are so complex or niche that very few editors are capable of editing them. And this is supposed to be the first (read: majority of the time, only) content a reader will encounter on the topic.
Thank you, this is very well put. As a still relatively new editor who sometimes has trouble understanding the almost automatic skepticism about any WMF initiative, this kind of debacle is really not helping to prevent me going in this direction as well. Choucas0 🐦⬛⋅💬⋅📋09:20, 6 June 2025 (UTC)[reply]
- Do different WMF research teams not talk to each other? Surely the backlash against a vaguer AI-focused WMF "strategy" was communicated among employees? Product teams and the Wikimedia Research teams are typically different teams and do not have a lot of overlap outside of the planning process. In the case of research teams, it is often desirable to explicitly not have folks who are insiders in the community since having insider knowledge has the potential to introduce subtle biases in the research. (See also, Observer bias)
- If there was actual interest in closing "knowledge gaps" the WMF would fund digitalization and permanent storage of offline media from underrepresented countries/languages so that editors could use them as sources. There are efforts in this realm on Wikisource, particularly those Wikisource Loves Manuscripts and amongst various affiliates who are indirectly funded by the WMF through grants!
- That expanding administrative duties, as suggested in the survey, is an incredibly intrusive overreach and absolutely should not have been floated without input from admins. Floating a idea of administrative oversight and gathering feedback on the same idea does not typically require a consensus discussion to happen before the idea is floated. This is not a intrusive overreach in any sense since the intention was to have a discussion at a later date about moderation strategies (as outlined in their roadmap for the now paused feature) Sohom (talk) 10:21, 6 June 2025 (UTC)[reply]
I really appreciate your taking the time to inform us all on WMF procedure!How would having familiarity with Wikipedia processes introduce (harmful, measurable) bias? I would think it would be far better to have people who actually understand how WP works interpreting data; the research landscape is in fact cluttered with irredeemably poor articles about Wikipedia (like this one that somehow arrived at the exact opposite conclusion from what the data showed).I've been pointed toward that WikiSource manuscript effort before, but from what I've read it seems it is focused on digitizing primary manuscripts, which would have limited use in our articles? Regarding the admin thing, by "floated" I meant "got to the stage where a pilot study was run", which is pretty far along. Why not gauge the reception by the communities that will actually be implementing the proposal before funding pilot studies and mobile tests? JoelleJay (talk) 16:23, 6 June 2025 (UTC)[reply]
Yeah I saw that linked up above, but that seemingly came after their pilot study.We will come back to you over the next couple of weeks with specific questions and would appreciate your participation and help. Did this happen? JoelleJay (talk) 17:03, 6 June 2025 (UTC)[reply]
Just as WMF has performed research before that came to conclusions that support their point of view (without my opinionating on whether that was deliberate), so too could someone who is deep-in-the-know design research that supports a "Wikimedian" point of view a priori. It's not a concern (or at least, the framing here isn't about it) about the interpretation of data, it's about which data is looked for to begin with. Izno (talk) 16:57, 6 June 2025 (UTC)[reply]
I understand that over-familiarity could influence the choice in which research to pursue, which is why it would be best to have a team with a mix of insiders and outsiders. Or have insider consultants to evaluate proposals after an experimental design has been hashed out by outsiders. At the very least, they would have learned much much earlier that an LLM-based approach to this problem was absolutely out of the question and could have put their resources into something more productive. JoelleJay (talk) 17:09, 6 June 2025 (UTC)[reply]
@OVasileva (WMF) Have been doing some background reading of the pages that you mentioned, while I do see a fairly strong indication of the need for the simplification of article text in the research studies, I see almost no studies claiming that large language models are the correct approach to solving this problem. The closest thing I could find in relation to a AI/ML technique was in the most recent survey by Trokhymovych et al. where the authors proposed a machine-learning model based on previous work by Lee and Vajjala et al. to use a BERT model to detect and score the readability of Wikipedia articles. The article does not explicitly make any recommendations on how this problem could be fixed. (Honestly, I am sad to see that the tool built by the researchers was not advertised more widely!)
On the other hand there has been a fair amount of research into the text generation characteristics on LLMs, particularly pointing out that they are prone to hallucination (as shown by multiple pieces of research cited in the Wikipedia article about the topic) and are prone to becoming unaligned even when explicity trained to be aligned (Carlini 2023). Additionally, while there has some research into using a variety of grounding techniques, most papers still concede that their methods lower the rate of hallucinations but do not eliminate the risk of hallucinations completely. (Elaraby et al., Li et al. ) This makes them unsuitable for a reader-focused unmoderated test as you had proposed here. While theoretically, moderation tooling could have helped, the fact that a majority of the more complex technical articles receive very little viewership or editorship means that a lot of the articles would still be left unmoderated and prone to misinformation or false information, potentially exacerbating the knowledge gap for the person(s) that received the wrong information instead of closing it. (not to mention that it might cause the person to cultivate a distrust towards content on Wikipedia which would contrary to the goal here). Sohom (talk) 10:04, 6 June 2025 (UTC)[reply]
I am especially curious what their entailment score was for, e.g., the dopamine summary, given that it seemed to summarize material that was not mentioned or not emphasized in the original text. How did that happen? JoelleJay (talk) 17:12, 6 June 2025 (UTC)[reply]
The model's output will consist of: i) a readability score ranging from negative (easy to read) to positive (difficult to read), ii) a predicted grade level (i.e. roughly capturing the number of years of education generally required to understand this text).Polygnotus (talk) 17:32, 6 June 2025 (UTC)[reply]
I'm not sure if the tool is properly maintained at the moment to be very honest, but the idea of the tool would be nice to have, available working and free of major bugz. Sohom (talk) 21:59, 6 June 2025 (UTC)[reply]
I have tested a bunch of articles (chemistry articles vs US presidents) and it looks like this model simply thinks that a longer text is more difficult to read, and does not take into account factors like using chemistry jargon that people who know nothing about chemistry (like myself) have never heard of. Sure, I can guess what some of them mean, but I have no clue what enediol is, or furan, or lactone. Polygnotus (talk) 22:16, 6 June 2025 (UTC)[reply]
Please do not even investigate this route. There are bound to be some really crass mistakes and it will damage our reputation for ages. It is a particularly poor proposal for the more technical topics, which someone complains are difficult to grasp from the lead. Such topics often are inherently difficult to grasp, and AI will therefore likely make mistakes in summarising them. JMCHutchinson (talk) 10:21, 5 June 2025 (UTC)[reply]
@OVasileva (WMF) Thank you, I like to provide my thoughts on the research results. Note that in en-wp, we have clear guidelines towards comprehensibility, explained in WP:MTAU. This is our ideal, and I think it is a good one. Importantly, we aim to strike a balance: First, we try to be as accessible as possible, but without overdoing it, without oversimplifying. Second, there is the "one step down" approach (we determine the target audience of a particular article and write for an audience one education level below that). Therefore, our (ideal) approach will differ a lot from article to article, depending on the topic and target audience. An automated approach, as proposed here, does not make such important differentiation.Many of our articles have indeed a problem with comprehensibility. This is because we lack the manpower to bring them to "featured article" status (which would ensure that all those guidelines are met). Comprehensibility problems are usually only one of many problems an article has. The way to address this is to rework the article, which takes volunteer time. It is dangerous to use an AI to summarize articles that are poor in multiple ways, because garbage in, garbage out applies. To improve on this (and other) issues, we should strengthen our editor base and make editing easier, such as by fixing all the software bugs and wishes that have been open for years and are a real pain especially for newbies. Using gen-AI for content creation is not a viable solution here. --Jens Lallensack (talk) 11:03, 5 June 2025 (UTC)[reply]
This is because we lack the manpower to bring them to "featured article" status No, it is because explaining stuff often requires a lot of underlying information. If I say that Maven is a build automation tool that uses an XML to store dependency information. then that is meaningless mumbo jumbo unless you know what those words mean in this context. What is build automation? What is XML? What are dependencies? And the answer to those question also build upon underlying information. XML is a markup language but what is "markup"? Et cetera. And Wikipedia articles either underestimate the reader (which would be boring) or overestimate (which means that understanding a single sentence requires reading at least the lead section of 3 other articles) them. But they are almost never at the precise level the reader is at. I can read computer related articles fine, but I struggle with chemistry related articles. For someone else, that might be the opposite. Polygnotus (talk) 11:54, 5 June 2025 (UTC)[reply]
When I wrote "problems with comprehensibility", I was referring to problems that can and should be addressed according to our guidelines such as WP:MTAU. I was not talking about problems that go beyond what our guidelines recommend. In my opinion, our guidelines are already sufficient and strike a nice balance; it is just that many articles are not following them. If people disagree they are sufficient, we should maybe first talk about those guidelines, otherwise we might not know what our actual goal really is here. --Jens Lallensack (talk) 12:15, 5 June 2025 (UTC)[reply]
So what should the goal be, precisely? I do not quite understand what the problem is that you are pointing out that is not addressed by the current guidelines. Yes, the reader might lack the context to understand your example sentence about "Maven", but we already have wikilinks to provide that context, no? (And, after all, WP:MTAU also endorses in-text explanations of terms to make sentences understandable in rough terms). So what precisely is it? If you have personalised output in mind (e.g., that takes your degree of knowledge in chemistry into account), then I think that should be implemented in a separate app that is decoupled from Wikipedia, alone because of data privacy issues. --Jens Lallensack (talk) 13:42, 5 June 2025 (UTC)[reply]
I'm not saying the AI should simplify the text, I've been very vocally against that. I'm saying that it could be used to identify where text could be simplified, something within the capabilities of current models. -- LCU ActivelyDisinterested«@» °∆t°09:33, 6 June 2025 (UTC)[reply]
I gave Claude the lead section of a Wikipedia article and asked: "how can i simplify this text, give instructions like change x into y".
It changed the meaning of some things, changed scientific terms to non-scientific terms and WP:COMMONNAMEs to alternatives, and seemingly at random removed important bits of information while it left others in (that I would judge as roughly equally important).
When you say could be used to identify where text could be simplified that can mean instructions like the ones above of specific adjustments, or that it should give a "readability score" for example, so I am not sure how to interpret that. I also opened two tabs and asked Claude "give this a readability score" with the same piece of text. Claude presented me with 2 different readability scores. Polygnotus (talk) 09:54, 6 June 2025 (UTC)[reply]
@Zanahary Yeah, and I responded to that by explaining that conventional LLMs (I used Claude, but I believe others would be similar or worse):
A: are unable to actually figure out what to do in order to simplify a text (casting doubt on their ability to determine whether simplification is required/possible)
B: produce nonsensical results if you ask them to produce a readability score.
Elsewhere I showed that a model trained by the WMF creates output that doesn't match human expectations (it seems to consider long texts difficult to read, but not text with words that are very rarely used and only in the vocabulary of people who know the field.)
Maybe I am weird but if even a model specifically trained by the WMF to gauge readability (I tried a few different chemistry related articles and compared them to articles about US presidents) sucks at it, and if a "normal" model sucks at simplifying text and is unable to determine how difficult a piece of text is, then maybe using LLMs to identify leads that require simplification is just a bad idea, you know? Unless someone can show me a model that is actually good at that task? Polygnotus (talk) 22:13, 6 June 2025 (UTC)[reply]
How many times do they need to say "I do not think this is a good idea" before you stop responding with "But you're wrong -- it is a BAD idea"? jp×g🗯️23:39, 7 June 2025 (UTC)[reply]
Checking the previous test
At mw:Reading/Web/Content Discovery Experiments/Simple Article Summaries#Browser extension experiment, we learn that without actual knowledge of the enwiki editors, a limited test was conducted showing machine-generated content to actual enwiki readers, with 825 summaries (total, not necessarily distinct ones) being read by our readers. Can this, perhaps on testwiki or some beta, please be replicated so we can see what it was that you have actually shown? It normally isn't the intention that content is shown which isn't written by or at least explicitly selected by enwiki editors (the last time this happened, AFAIK, was with the Wikidata short descriptions which have been then rejected by enwiki after much opposition and sabotage by the WMF), and I wonder what has really been shown behind our backs and who would have taken responsability for problematic content (say, BLP violations, wrong or unwanted medical advice, or POV summaries of contentious topics). Basically, you were toying with the reputation of enwiki and its editors, even though the WMF doesn't do content.
So, long rant, TLDR: please put the summaries you used in that previous experiment somewhere online, so we can see what was used beyond that pre-selected "dopamine" summary with all its errors. Fram (talk) 13:41, 5 June 2025 (UTC)[reply]
Seconding Fram's comment, and linking phab:T381253 which may have more information on the topic. I see that there is a Google Docs with more detailed results – while I don't expect to see all of it for privacy reasons, giving the community access to the detailed anonymized data would be great. Chaotic Enby (talk · contribs) 13:45, 5 June 2025 (UTC)[reply]
There's this. I will skip over the baby food Hypatia summary, though it is extremely funny (Her death made a lot of people very sad, and she became famous for standing up for what she believed in.), and focus on the full summary. I do not know much about this subject area but already I see some concerns.
In general there are some strange inclusions and omissions in the summary, which give disproportionate importance to trivia -- I don't think Hypatia's menstrual blood story is the main part of her legacy -- and create implications of cause and effect that were not in the original text. For instance, the summary makes it seem like Synesius's letter to Hypatia was the inciting event for Cyril closing synagogues, etc.
The text makes some logical leaps in regard to dates. For instance, it states that the monk Ammonius was killed in the year 414 after a riot. Maybe he actually was killed in the year 414, but the article text quoted does not link that event to that year.
The AI latches onto some words like "co-opted" without considering the context. In the original text it is being used to point out the irony of Christians coming to admire someone whose followers were anti-Christianity, but the summary applies it to everyone in a way that sounds inadvertently POV-pushing: "Her legacy has been co-opted by various groups over the centuries, including Christians, Enlightenment thinkers, and feminists."
The summary describes "apatheia" as "emotional liberation"; the text describes it as "complete liberation from emotions and affections." To a layperson -- and certainly to the intended audience here -- the summary makes it sound like "apatheia" means being free to be emotional, which is the exact opposite of what's in the text.
The summary states that Theophilus "opposed Neoplatonism." The actual article states that he was "opposed to Iamblichean Neoplatonism." Iamblichean Neoplatonism is a sub-school of Neoplatonism (as the article states elsewhere) and the summary suggests that Theophilus opposed the whole thing.
And so on. So, no major hallucinations, nothing that strays too far from the original text, and nothing that isn't a mistake a human could make, but a lot of small inaccuracies and a weird sense of what's important and what's not. Gnomingstuff (talk) 02:43, 7 June 2025 (UTC)[reply]
Initial thoughts looking at the extension itself, it feels hastily put-together, almost tech demo-esque rather than thought through feature that was near deployment. This should have never been anywhere close to being deployed on a live site. Sohom (talk) 20:23, 7 June 2025 (UTC)[reply]
This appears to be the filtering that is being used, although it seems like manual filtering is on the table as a fallback, and these appear to be the quality assessment criteria. As of May 29 this is apparently not yet a production-level service (nor has it been requested as such (which is somewhat at odds with how it was presented here, but whatever). Gnomingstuff (talk) 21:04, 7 June 2025 (UTC)[reply]
Note for anyone crosschecking that list: "Sorry, we had to truncate this directory to 1,000 files. 4,342 entries were omitted from the list. Latest commit info may be omitted.". #The full summary list below, which I found and posted independently of Sohom, includes a better link. * Pppery *it has begun...19:46, 7 June 2025 (UTC)[reply]
Here is an easier-to-view version of that -- I had trouble loading anything after "Bobby" -- that also includes what seems to be the original text, for comparison. Gnomingstuff (talk) 20:13, 7 June 2025 (UTC)[reply]
some quick takeaways:
obviously these have very little to do with the article itself, and a lot of markdown headers left in (even in the non-truncated set) that speak volumes about what this is actually generating: Lemons: A Sour Powerhouse
a few CTRL-F terms to spot embarrassing stuff: "we're," "cool," "it's important," "it's like," exclamation points. (update: double spaces inserted after a period also seem to be a flashing signal for incoming slop) This movement is why we have earthquakes, volcanoes, and mountains. It's like Earth is a giant, slow-moving conveyor belt!
the model seems to have refused to summarize some articles entirely, but not all (Donald Trump seems excluded, for instance, but Project 2025 is summarized)
Thank you all for the time and effort you’ve put into sharing your concerns and ideas here. I’m writing to reiterate that the project is paused, and that the survey is now closed. We’d like to take some time to digest all of your thoughts, and we'll return to this conversation early next week. -- MMiller (WMF) (talk) 22:58, 5 June 2025 (UTC)[reply]
Thanks a lot for listening to the community on this one. It must not have been the easiest couple of days for you, and I'm happy that you nonetheless took the feedback into consideration. Really wishing you and your team the best of luck. Chaotic Enby (talk · contribs) 23:15, 5 June 2025 (UTC)[reply]
Frankly, the very obvious outcome from this discussion is "the community does not want LLM-generated summaries or anything like it", so if next week we're just going to hear from the WMF again something regarding yet another plan to implement LLM models on Wikipedia, we'll be back to square one. Narutolovehinata5 (talk · contributions) 23:33, 5 June 2025 (UTC)[reply]
Thanks for the update. One reason the community reacted particularly strongly is the idea that this was about to be tested *right away* - showing this AI content to 10% of mobile users within a week. That creates a sense of crisis. In general, editors are supportive of the WMF coming up with new ideas, proposing software tweaks, and building tools that make Wikipedia better for readers and editors. A useful principle to adopt going forward: anything AI-related should be extensively discussed with the community before *ever* becoming visible to readers. —Ganesha811 (talk) 23:51, 5 June 2025 (UTC)[reply]
I've no idea if anybody has already proposed an AI tool to summarise long discussions at The Village Pump, because I can't parse it all. ? - Roxy thedog05:56, 6 June 2025 (UTC)[reply]
@Roxy the dog Shockingly, someone has! Nothing came of it because the AI did not make a good summary (it just described the chronology and POVs, but didn't highlight the bits that were worth reading). Polygnotus (talk) 05:59, 6 June 2025 (UTC)[reply]
I feel like something that sorts comments by POV could still be helpful as an alternate way of getting a quick overview of a discussion thread. You could read all supportive comments then all opposing comments, for example. Alpha3031 (t • c) 14:21, 8 June 2025 (UTC)[reply]
@Alpha3031 How would that work when people make points and counterpoints? I think that would be very confusing because if someone responds to someone you'd lack the context that is often required. I went another direction, see User:Polygnotus/Scripts/Timeline.js. The slider allows you to travel through time through a discussion which can be helpful in long and complicated discussions. Polygnotus (talk) 14:24, 8 June 2025 (UTC)[reply]
I'm thinking of possibly using it as an alternate view that you can switch to and from, not completely supplanting the semi-automatic threaded discussion view we have by default. For example, you can skim over a pros and cons view and (since nowadays signed comments also have individual anchors like #c-Polygnotus-20250608142400-Alpha3031-20250608142100) use it to jump around to comments you want to look at further. Maybe have both up on a side-by-side view even. Of course, I wouldn't know how hard that would be to implement. Alpha3031 (t • c) 14:32, 8 June 2025 (UTC)[reply]
One tip I have is that when you notice that one person is responsible for 25% of the comments in a discussion, you can usually skip reading their comments and save a lot of time. Matma Rextalk12:18, 6 June 2025 (UTC)[reply]
I just don't know how it got to this point. Our money is being spent on an AI team at the WMF? It feels like you guys just don't really understand or even like our website. And if that is the case, please leave it be. ForksForks (talk) 13:52, 6 June 2025 (UTC)[reply]
I honestly think the best course of action is to leave Wikipedia to be a human affair (besides bots that do specific tasks like AnomieBot, CitationBot, etc) Generative AI is not the magic potion tech bros are making it out to be, and Wikipedia and it's readers shouldn't be subjected to LLM mistakes because some are bad readers, and or have a low attention span. That shouldn't be our issue, but it will be if this is rolled out. Plasticwonder (talk) 17:54, 6 June 2025 (UTC)[reply]
What is there to digest? The overwhelming consensus is "don't do this." A week later the consensus will most likely continue to be "don't do this." The only possible takeaway, then, is "we're not going to do this," and it takes no digestion to realize this. Gnomingstuff (talk) 19:30, 6 June 2025 (UTC)[reply]
@Gnomingstuff There are definitely more things to digest here other than just "hey stop this". Particularly, what "this" is is still up for debate, does "this" refer Simple Article Summaries, simplifying articles, any work involving generative AI or AI development altogether. Many sentiments have been raised across this discussion and it is important for folks at the WMF to take stock of the situation and understand the prevailing community sentiment and weigh it against work already done in the area. Another way to approach this would be the for WMF to ask "what went wrong here?" and try remedy their process to account against this kind of incident. Sohom (talk) 21:35, 6 June 2025 (UTC)[reply]
"This" refers to "this project," and "don't do this" means to not "pause" it (with the implication that it can be unpaused) but cancel it altogether. There is no amount of process or bureaucracy that can make this bad idea good. If it was introduced to the community two years ago with weekly check-ins it would still be bad. Gnomingstuff (talk) 22:19, 6 June 2025 (UTC)[reply]
"This" refers to "this project," and "don't do this" means to not "pause" it (with the implication that it can be unpaused) but cancel it altogether. There is no amount of process or bureaucracy that can make this bad idea good."
@Plasticwonder and @Gnomingstuff: My meta point still stands that if the WMF wants to do a deeper dive we should let them do that instead of forcing a "shut down, move on" outcome. I agree that AI generated summaries is not the way this should go. However, there is still room for folks to potentially pivot the project to be something like allowed user-generated/human-generated summaries on the mobile website could/should still be on the table as a potential continuation of the workstream but not necessarily this exact project. Sohom (talk) 01:16, 7 June 2025 (UTC)[reply]
We don't have any power to "let them" do anything or to force any outcome. We are not their boss and we are not Hollywood hypnotists, they are going to do what they want.
There might be some value in user-generated summaries but this proposal isn't about those, it's about AI-generated summaries. There is a paper trail of it being developed since 2024 (and maybe 2023?) around the core idea of AI generation. Gnomingstuff (talk) 19:19, 7 June 2025 (UTC)[reply]
@Gnomingstuff, I have no clue which "paper trail" you are referring to. To my understanding, the project started in 2024 as a search for a potential solution to the problem of us having incomprehensible leads on some technical articles (which fell under the broader umbrella of the WMF trying to find new ways to engage folks with the existing content). A hypothesis was proposed late 2024 to see if AI was any good at summarizing article ledes and presenting them in a accessible manner. The first prototype of the project was this one which led to a community confrontation. I see there as being still space to turn around while still pursuing the original goals of the project (which was to find ways of making Wikipedia more accessible to users). The overall goal of the project (and/or workstream) is not set in stone to only use AI-generated summaries. Calling for the project's cancellation achieves nothing other than a punitive victory on our part. Sohom (talk) 19:39, 7 June 2025 (UTC)[reply]
There are a lot of pages linked here, plus on phabricator, this whole thread, etc., I don't have time to dig through all of the linked pages again but there is extensive documentation around every stage of the process.
I don't think a "punitive victory" is a bad outcome here. The "punishment" is not having AI slop inserted into Wikipedia against the community's wishes. As you can see, most people here are in agreement that this is not a bad outcome, and so I don't know why my comment is the one you are picking apart rather than those of hundreds of other people commenting here. Take it up with them too. Gnomingstuff (talk) 19:51, 7 June 2025 (UTC)[reply]
@Gnomingstuff I am not advocating for AI summaries, I hate AI slop as much as other folks here and have been vocal about that in other non-public arenas as well. I think I the Reading/Web team should not pursue AI generated summaries further and in that sense I do want this "sub-project" gone. I do see the stoppage and potential cancellation of work on AI-generated summaries as a positive outcome and not a punitive victory. However, I do want them to continue exploring the overall workstream and project of finding technical improvements in ways so we can make the readers more engaged and the smaller project of trying to find ways of making our ledes/articles less technical. I would see the shutdown of that workstream and overarching project to be a net-negative to Wikipedia and a punitive victory on our part.
My initial response was a direct response to your question of What is there to digest? try to explain how the WMF worked and what they might be considering while the project was stopped (and what "this project" means in the context of the WMF's rather convoluted processes). I am sorry if I gave the impression of specifically picking your response apart. I think we are talking about the same thing just on cross-purpose lol. :) Sohom (talk) 20:14, 7 June 2025 (UTC)[reply]
MMiller (WMF) I'm joining this discussion late, and there's a lot of text here to wade through, so please forgive me if I'm asking something that's already been answered here or on the project page over at MediaWiki. But in addition to the question of accuracy, I'm curious about the questions of cost, sustainability, and environmental impact.
From a technical standpoint, how often would these summaries be generated? Each time a reader loads the page? Each time someone edits the page? Or just once?
Given (1), how much would it cost to generate these summaries for, say, the 7+ million pages on English Wikipedia? Is doing this the best use of donors' funds? What else won't get funded to cover these costs?
What are the social and environmental impacts of (2)? By what proportion would it change Wikipedia's current carbon footprint? How would this impact the health of people living around the servers?
There's mention of making these summaries editable. How much volunteer time do you envision it taking to check the tone, neutrality, and accuracy of each summary? What timeline do you envision for such a project? Will WMF commit to using paid staff time to ensure that this timeline is met, assuming that volunteers don't step up to do this tedious work on their own? How much has WMF budgeted for this work, and what has been done to justify spending donors' money in this way?
How did you come to that estimate in (4)? What value (in terms of, say, dollars per hour) does WMF assign to volunteer time?
How do you plan to assess the impacts of including of Ai summaries on users' perception of Wikipedia's accuracy? What sort of research design do you envision to capture variability in readers' perceptions across countries, cultures, and various demographic factors? How much has WMF budgeted for this work, and what has been done to justify spending donors' money in this way?
I apologise for making this so long. I don't need an answer to every point, I'm happy to sift through the documents where this has been covered. Thanks in advance. Guettarda (talk) 18:24, 7 June 2025 (UTC)[reply]
As far as I am aware, the amount of electricity required to run even computationally-intensive language models for the task outlined here is negligible compared to any of the dozens everyday tasks for the billions of individual inhabitants of any developed countries (e.g. running a single hair dryer or air conditioner for a few seconds). My guess is that spending several days carrying out an estimate of the social and environmental impacts of the activity, assuming it was done by humans who showered and did laundry and drove to the office, would vastly outstrip the carbon costs of any model running seven million prompts. jp×g🗯️06:09, 12 June 2025 (UTC)[reply]
Given (1), how much would it cost to generate these summaries for, say, the 7+ million pages on English Wikipedia?
The company behind the Aya model that was used here offers access to hosted models at the price of "$0.50/1M Tokens for Input and $1.50/1M Tokens for Output". [2] All of Wikipedia's articles apparently contain 4.9 billion words. [3] Taking an arbitrary estimate of a word being on average two tokens, and the output summary being on average 100 words, we get 4.9 billion * 2 * ($0.50/1 million) + 7 million * 100 * 2 * ($1.50/1 million), [4] or about $7000 for a one-time run. This does not seem like that much. I'm not an expert on this, so please double-check my assumptions and my math. If you hosted the model yourself, you would probably be able to do this cheaper. Matma Rextalk14:10, 12 June 2025 (UTC)[reply]
It sounds like it's missing words to me. Googling the phrase, the 12 results that come back suggest this miiight be an engvar I'm unfamiliar with. CMD (talk) 02:05, 8 June 2025 (UTC)[reply]
Looking at my own sample (not necessarily random, but I wasn't aiming to only pick articles I guessed would have issues):
Antisemitism is an example of why this would have been disastrous in contentious topics: the tone is way off compared to the actual topic, calling genocides sad events and the word itself just a fancy way to say "Jew-hatred."
Austria-Hungary mentions it being formed by joining two countries, Austria and Hungary, which is factually wrong: Hungary was previously part of the Austrian Empire (divided into multiple kingdoms and duchies since 1848), and was elevated to an equal status. The empire was made up of three main parts: Austria (called Cisleithania), Hungary (Transleithania), and the Kingdom of Croatia-Slavonia is also wrong, as Croatia-Slavonia was part of Transleithania.
Axolotl starts with the completely unnecessary title Axolotls: Mexico's Amazing Aquatic Salamander. Then, They stay small and aquatic is blatantly false, as they are on average slightly larger than the tiger salamander (a non-neotenic member of the same genus).
Aztec Empire is mostly accurate for the first half (I can't really judge the second as I'm not familiar with Aztec religion). Calling Xoconochcosome distant lands might be a bit misleading given its distance, although the actual lead calls it some more distant territories within Mesoamerica, so that might be where it came from.
Bohemia mentions that it included areas like Moravia and Czech Silesia (the two other Czech lands), failing to make the distinction between the region of Bohemia and the historical state of the same name (which our current leads manages to do just well). The next sentence, Over time, Bohemia became part of different empires and was affected by wars, is pretty vacuous as it can be applied to pretty much any historical region.
Another summary I just checked, which caused me a lot more worries than simple inaccuracies: Cambrian. The last sentence of that summary is The Cambrian ended with creatures like myriapods and arachnids starting to live on land, along with early plants., which already sounds weird: we don't have any fossils of land arthropods in the Cambrian, and, while there has been a hypothesis that myriapods might have emerged in the Late Cambrian, I haven't heard anything similar being proposed about arachnids. But that's not the worrying part.No, the issue is that nowhere in the entire Cambrian article are myriapods or arachnids mentioned at all. Only one sentence in the entire article relates to that hypothesis: Molecular clock estimates have also led some authors to suggest that arthropods colonised land during the Cambrian, but again the earliest physical evidence of this is during the following Ordovician. This might indicate that the model is relying on its own internal knowledge, and not just on the contents of the article itself, to generate an "AI overview" of the topic instead. Chaotic Enby (talk · contribs) 20:54, 7 June 2025 (UTC)[reply]
Yeah, that seems extremely likely and I don't understand how this got through quality control. Surely they'd tweak their entailment score method to weight appearance of meaningful content not present in the article as an autofail?? JoelleJay (talk) 21:38, 7 June 2025 (UTC)[reply]
This is a searchable list of summaries, along with the original text, although some filtering seems to have been done since. Two things to keep in mind here: one, it's not finished yet apparently, and filtering has not been fully done; two, the summaries suck ass. I mentioned this upthread but since it's buried, here are some search terms to find some of the worst of it. I fully admit this is cherry-picking but it should not be this easy to cherry-pick:
"cool," "awesome," etc.: The word "engineering" comes from a Latin word meaning "cleverness," which is exactly what engineers use to make the world an awesome place!
addressing the reader directly, "we're," "you," etc.: Over time, computers got faster, smaller, and more powerful, leading to the digital world we have today.
didactic phrases like "it's important," etc. It's important to know that pedophilia is different from actually abusing a child. Not all pedophiles act on their feelings, and many would never hurt a child.
phrases that indicate comparisons made up out of thin air, targeted at children (these are targeted at 7th graders): "it's like," etc: Oxytocin is a natural body chemical that acts as a hormone and brain signal. It's like a superpower that helps us feel love, bond with others, and even have babies.
markdown formatting, like hashes, which reveals the "titles" of the "posts" that are being generated ## Persian Cats: Fluffy Friends with a History
exclamation points: Rococo art makes things look exciting and full of movement. It's like a fun, colorful party for your eyes!
double spaces after a period, slop seems to ensue after that [Indra is] also found in Buddhist and Jain stories, but his power is reduced. Think of him like Zeus from Greek mythology. (This one also assumes a Western background, which would seem at cross-purposes with the whole "knowledge gaps" thing, but....)
These seem to be the prompts being used. I know almost nothing about how or whether prompt engineering works, but the main concern seems to be output that isn't in English.
These seem to be at least some of the evaluation criteria to determine whether these are actually good (they're not). People who know more about machine learning will probably know more about whether these are any good.
Looking at the Phab task, they're using the aya-expanse-32b model with five quality metrics: simplicity, fluency, meaning preservation, language preservation and tone, although it is not clear how much each is weighted. For meaning preservation, they are using the SummaCZS model, which is specifically designed for summaries. Roughly, it works by splitting the document and the summary into blocks, and taking, for each block of the summary, the largest entailment probability among the blocks of the original document.An issue with this method is that there is no estimation of how important information is at the scale of the document – the model doesn't care if the sentence in the summary matches a single block or 10, and will not be able to give appropriate weight to each aspect. It isn't clear why that model was picked and not the related SummaCConv, which is less sensitive to individual sentences. Chaotic Enby (talk · contribs) 23:43, 7 June 2025 (UTC)[reply]
Tone: The summary should be written in a style and tone appropriate for Wikipedia. Avoid any editorializing, opinions, or expressive language about the subject and ensure the tone remains encyclopedic, neutral, and professional. Well looks like that just got completely ignored. ARandomName123 (talk)Ping me!23:51, 7 June 2025 (UTC)[reply]
From the summary of Judaism: Today, most Jews live in Israel, the United States, and Canada. — Both the infobox on Judaism and the statistics contained in Jewish population by country put the top three countries as Israel, US and France, with Canada coming fourth. We got some hallucination going on.
From the summary of Epistemology: Epistemology is a fascinating area of philosophy that digs into what we know and how we know it. — Fascinating? That's not a style we use here. WP:NOTESSAY etc.
The first one actually isn't a hallucination -- it appears to originate from an earlier version of the article: In 2021, about 45.6% of all Jews resided in Israel and another 42.1% resided in the United States and Canada, with most of the remainder living in Europe, and other groups spread throughout Latin America, Asia, Africa, and Australia. So maybe a bit "LeBron James and Bronny James combined for 60 points," but not wrong. Gnomingstuff (talk) 00:31, 12 June 2025 (UTC)[reply]
On the issue of neutrality, the summary for the 2020 United States presidential election includes: Trump refused to concede and attempted to overturn the results, leading to a mob attacking the US Capitol on January 6, 2021. — The article lead doesn't currently use a descriptor, instead describing "hundreds storming the building and interrupting the electoral vote count". The election article does not use the word "mob" in wiki-voice (it appears only in the titles of referenced articles), preferring "rioters". January 6 United States Capitol attackdoes use the word "mob"—with footnotes, following a discussion at Talk:January 6 United States Capitol attack/Archive 6#Mob: biased words. Editors spend a considerable amount of time discussing the appropriate terminology to describe what happened on January 6, along with other politically contentious and historically disputed topics. Why bother though? Clippy can do the job without any of that boring arguing on talk pages or weighing up of sources. —Tom Morris (talk) 14:59, 12 June 2025 (UTC)[reply]
My personal favorite is that the Tory article reads: The Conservatives are on the right side of politics. Obviously what the LLM meant to say is "right-wing," but... it didn't. And obviously as a native English speaker with access to the original article I know this immediately, but someone less fluent in English who's reading this first... might not. Gnomingstuff (talk) 15:06, 12 June 2025 (UTC)[reply]
Baffled how any of this was checked by anyone and still pushed through toward live testing, but I guess it makes sense if the research team is purposefully made of people who have never read a single en.WP PAG or MOS page. If the WMF wants to get into kidfluencing, they can take this slop to YouTube shorts. JoelleJay (talk) 21:33, 7 June 2025 (UTC)[reply]
I have been digging through the Phabricator tasks, because no one involved has provided any transparency at all on this, to figure out methodology. This seems to be the page that talks about where the dopamine summary came from and gives the exact prompt that was used to generate it.
The choice of dopamine as the article seems to have been happened before the actual summarizing was done, and doesn't seem to come from a place of "well the rest of the summaries aren't great this is the best we've got": The reasoning here is that it's a verified "good article" and it also has a relatively complex introductory paragraph with lots of technical language. It also has broad general interest and an analog in Simple English.
People noticed that the tone was off, and noticed some very obvious issues with some early summaries: Dopamine is a chemical found in the brain. It is a neurotransmitter. Dopamine is released by neurons to send signals to other nerve cells. Dopamine is a neurotransmitter. Dopamine is a chemical that is released by neurons to send signals to other nerve cells. But there doesn't seem to be much of a focus on whether the summary was in fact a summary of the actual text. Which, since it's generative AI, it wouldn't have been.
I was wondering why the full list of summaries here is way more childish than the Dopamine summary originally shown at the top of thread, and when the change to a more adult reading level happened. It looks like it actually happened the other way around. There seem to have been at least two batches: fall 2024 and spring 2025. The Dopamine summary we originally saw came out of the fall 2024 batch. The summaries here seem to be the spring 2025 batch. I don't know why the tone is so different, given that the iterations of the prompts I've been able to find all specify something at a 7th-grade reading level or actually for 7th graders. I also don't know why anyone thought that the new ones were better, or that the old Dopamine summary was representative of the new stuff. Gnomingstuff (talk) 23:09, 7 June 2025 (UTC)[reply]
The general approach seems to be to serve up a gumbo bowl of popular misconceptions and tell people what they already know. The whale shark summary gives us:
I am absolutely astounded by how tonally inappropriate some of these are. "IKEA is a super-popular furniture company from Sweden, now based in the Netherlands. . .They keep prices low by selling furniture in flat packs that you assemble at home. People love shopping at IKEA because it's fun and you can get great deals on stylish stuff for your home."Andrew Gray (talk) 12:10, 12 June 2025 (UTC)[reply]
Frankly, I think the whole basis of this project—summarizing articles to a below-high school reading level, purportedly to address a "knowledge gap"—betrays an irremediably misguided understanding of the breadth of this encyclopedia, the capabilities of LLMs, and how Wikipedia works. I think @Jens Lallensack brought up the very apt point that our articles are written for (just below) their individual target audiences and so should not and cannot all be summarized to the same level of simplicity. Someone who reads at a 7th grade level will derive absolutely zero understanding from a TikTok digest of Hodge theory, and that's assuming its summary was manually written by an expert. In the case of AI summaries, it would be literally impossible to dumb down that topic to below an undergraduate math degree, both because it is intrinsically complex and because you could not use only the article body to source the summary. The model could not be tethered only to material present in this article because it does not explain the basic topology and algebraic geometry concepts readers are (rightfully) expected to already be familiar with if they're on this page; that's what the blue links are for. Thus it would necessarily have to draw its summary from a corpus beyond this one page, and indeed, the lower the target reading level, the more expansive the corpus would have to be. Which means the model must be able to deviate from what is present on the target page beyond simple synonymy: it has to define each technical term using a much larger corpus while retaining the context in which the term appears in the target, but it must also distinguish terms that are allowed to be "defined" using that corpus from related concepts described in that corpus that are not brought up or emphasized on the target page. LLMs can maybe be okay at this if given the proper prompt and serious semantic constraints, but the more degrees of freedom they're allotted the more likely they are to stray significantly from what is actually covered in the input. That seems to be what happened in many of the summaries mentioned by @User:Chipmunkdavis and @User:Chaotic Enby that hallucinate meaningful words that don't appear on the page at all.
I just do not see how anyone thought this would be tenable for anything beyond the most basic articles where childish treatments already exist elsewhere, let alone for the "too technical" subjects the WMF specifically developed the tool to address. Either the project needs to be scrapped entirely, or narrowed down to supporting strictly summaries, of just the most accessible topics if sticking to the 7th or 9th grade reading level, generated by humans, and in particular humans familiar with the PAGs and MOS of the target wiki. JoelleJay (talk) 02:23, 8 June 2025 (UTC)[reply]
That assessment does make sense. The models have to rely on out-of-context knowledge to understand the text they're summarizing, but might then fail to meaningfully distinguish what is and isn't in the text itself. A possible solution could be to strengthen the meaning preservation evaluation, which is currently based on SummaCZS. Maynez et al. 2020 makes the difference between intrinsic and extrinsic hallucinations: the former correspond to inconsistencies in summarizing, while the latter originate from incorporating information not in the document. Sadly, Laban et al. 2022 (who developed SummaCZS) explicitly merged both in their metrics, so the paper doesn't give us a great idea of how their method fares on that point specifically.Additionally, their method is based on textual entailment, which doesn't really exclude cases where the summarized sentence only partially derives from the original text, so that can also be an axis of research to look into.Regarding your last point (which is what I would favor), volunteer-written summaries would indeed make a lot more sense, and be philosophically more in line with the idea of a wiki. However, summarizing already accessible topics might be seen as a bit redundant, and it could be interesting to see if we can also summarize more technical topics at a (slightly) higher reading level. Chaotic Enby (talk · contribs) 02:42, 8 June 2025 (UTC)[reply]
I agree with a lot of others that this project should just pivot to displaying the Simple Wikipedia intro for articles where that's available. Doesn't seem like it'd be that difficult to swap databases. JoelleJay (talk) 15:56, 10 June 2025 (UTC)[reply]
To answer the question asked "What was the end goal in the first place?" see my responses above to Gnomingstuff and this comment in the associated AI RFC. I do not agree that the simplification of ledes is necessarily a flawed thing to focus on. However, based on a bit of digging Chaotic Enby and I did this afternoon, the initial generation used a off the shelf large-language model (called Aya) developed by Cohere.ai that seems hosted on Hugging Face with a potentially flawed setup (see above) and extremely rudimentary prompts. The extension that was supposed to be deployed on enwiki itself just fetched a static JSON file containing pre-generated (and potentially out-of-date) summaries and showed it to the user. This seems to be an extremely rudimentary experiment, the likes of those seen for tech demos and mockups, not for software that was supposed to be deployed onwiki. Why this was scheduled to be deployed on a live production wiki is beyond me. I will echo @JoelleJay's call for a pivot of the project towards human-generated summaries, since I don't think even frontier models have solved all of the issues outlined above. I would also urge the WMF to provide a commitment on internal process improvements to ensure that all new features go through sufficient dogfooding and community feedback phases before being tested onwiki. (regardless of whether or not they are AI dependent or reader focussed). Sohom (talk) 03:07, 8 June 2025 (UTC)[reply]
There was an 8-person community feedback study done before this (a UI/UX text using the original Dopamine summary), and the results are depressing as hell. The reason this was being pushed to prod sure seems to be the cheerleading coming from 7 out of those 8 people: "Humans can lie but AI is unbiased," "I trust AI 100%," etc.
Perhaps the most depressing is this quote -- "This also suggests that people who are technically and linguistically hyper-literate like most of our editors, internet pundits, and WMF staff will like the feature the least. The feature isn't really "for" them" -- since it seems very much like an invitation to ignore all of us, and to dismiss any negative media coverage that may ensue (the demeaning "internet pundits").
Sorry for all the bricks of text here, this is just so astonishingly awful on all levels and everything that I find seems to be worse than the last. Gnomingstuff (talk) 08:43, 8 June 2025 (UTC)[reply]
My takeaway from the feedback study is that any evaluation of AI products must include an objective measure of, in this case for example, how accurately the respondent was able to understand information from the article after reading the summary. (for example, a human vetted list of questions that cover the most important points) We can't feed a bunch of hallucinations and confabulations to a bunch of people who aren't expected to read the article and expect their feedback to be based on how accurate things are versus how accurate they look, and LLMs excel at generating very good looking bullshit. Alpha3031 (t • c) 14:12, 9 June 2025 (UTC)[reply]
What an incredibly sad read, and a misunderstanding of Wikipedia's mission. It almost feels like a marketing stunt - "we are losing out to TikTok influencers reading a fluff summary, how can we win those people back?" Has the WMF tried offering free beer, or a random photo of a bikini-clad woman adorning every page? Hornpipe2 (talk) 21:25, 13 June 2025 (UTC)[reply]
Only a couple people in the entire discussion above mentioned that this is what all the search engines, and the search-enabled LLMs which have started to slowly supplant search engine use, already do to our content. From my impression of the Research team's discussion of LLM integration in recent months, I suspected they wanted to get a baseline for doing that on which improvements could be made, but I don't see how that can work. Who would take the trouble to get Wikipedia's LLM summary of an article instead of Google's without just reading the Wikipedia intro? ESL learners are the obvious answer, and we don't do enough to promote and make it easy to get to Simple Wikipedia for them. That's what it's there for, and what makes this project such redundant cringe. Cramulator (talk) 03:29, 9 June 2025 (UTC)[reply]
Many thanks @Sohom and @JoelleJay for tirelessly improving and illuminating the above discussion. You have both made my day much better. Please enjoy a page-specific barnstar :)
People have noted that a convergence of oversights was needed for this to have almost gotten deployed — and as a large delving model I hope process reviewers delve into the five whys and look at systemic causes. But beyond that, no project like this should have AI outputs tested in isolation. The concept of 'rapid test iteration' should be upgraded to developing a {rubric - benchmark - eval - editor feedback} loop, which crystallizes an idea into a process designed for continuous evaluation and improvement.
At its heart, useful automatic summaries are attainable (and provided by many tools), even if imperfect. The subfield of automatic document summarization exists, and many of its frontier researchers are friends of the wikis. We should work with some of their labs on article summarization approaches rather than making up our own process. Language-level simplification is even more attainable, with fewer confounds. To make progress on either we need good evals for summary quality (coverage, balance, compactness?) and language-level suitability (both estimating current complexity and estimating what level is appropriate for the topic).
In both cases, even if the end goal is a fully automated tool for languages with a high reader-to-editor ratio, where edits are already infrequent and dominated by bots, an intermediate step should be providing better summaries to editors in order to fine tune the process and see what works and what doesn't.
And an essential prerequisite to doing this should be nailing the presentation of rich, clear context -- not a long paragraph of confusing qualifiers about 'unverified' provenance. A client-side summarizer where you as reader can see and control its configuration, see and rerun the prompt used, &c. could be interesting. In contrast, it is more confusing to have a similar result provided opaquely / statically / exclusively by Wikipedia in quasi-encyclopedic-voice, appearing in the same space (top of article, below article title) as existing article summaries (lede, infobox, &c). – SJ +05:06, 11 June 2025 (UTC)[reply]
I think this is an insightful way to think about it. These types of projects should be defined in a product development process with goals and risks, and the openness to change the specifications as more is learned about the problem space. WMF devs and product folks should not create a special sauce WMF solution but look to best practices in the field and try to adopt working solutions that work in other domains. One of the problems with LLMs is that they do not have a strong integrity to logic or facts, but that could be improved with techniques that have been studied, but there is no evidence that this is how things are being done. Frankly, it feels that this is a flavor of the year or last 2-3 years and so everyone and their board needs to incubate this tech even when something else might work better, like a knowledge graph approach. Andre🚐05:18, 11 June 2025 (UTC)[reply]
Right, and it's not either-or: We are a perfect candidate for tools that ground LLM outputs in a given knowledge graph -- particularly one whose nodes are articles or wikidata entries which can be linked. – SJ +20:25, 11 June 2025 (UTC)[reply]
I agree, LLM is an unarguably very compelling end interface to some pipeline that could include other sources of information through an MCP or other integrated API, and has a similar use case to a Wikipedia summary, and something like Wikidata or Abstract Wikipedia is basically trying to crowdsource the distributed knowledge graph, and it makes logical sense and I am sure efforts are already underway to use the LLM as just a fancier output lexer that deterministically translates nodes of data into sentences without being the link in the chain to provide the factual information. Unfortunately though since LLMs are good bullshit generators and get a lot of low-hanging fruit right, they trick people into thinking they can be AGI or that they can pretty much replace a human at a complex task, even as the research shows they have inherent limitations and are going to encounter difficult to surmount roadblocks that are basically impossible to solve simply by predicting a pattern of answers. They completely lack self-awareness or a meaningful system to understand and learn from mistakes. But they generate bullshit at such a large clip that it overwhelms the ability of humans to keep up with manual review. We should not "vibe" our encyclopedia because that is going to lead to more errors. That does not mean there is not some use case for the LLM technology itself as it evolves into a targeted contextualized tool not a be-all end-all. Andre🚐01:57, 12 June 2025 (UTC)[reply]
The future of LLMs for Wikipedia is on the client, not the server
This project should have been a sticky option to show the Simple English Wikipedia's intro when available.
I think leveraging simplewiki is a good idea, playing to our strengths instead of replicating something Google can throw effectively infinite money at. I'm not sure using Google's API counts as being "on the client" though, that would be more like distilling a task specific model to the point it can actually run on any old computer, like Mozilla has done for translations. Alpha3031 (t • c) 13:55, 9 June 2025 (UTC)[reply]
I think he means on the client as in a user script that runs client-side though as you point out, the real work is done on a Google cloud server before coming back to the client, but it does not involve something installed on the server-side of Mediawiki. Also, the user was blocked apparently. Hopefully that script isn't bad because I just installed it and used it to find some typos and yes, it did work. But I definitely do not think it should be shown to random users. Andre🚐05:24, 11 June 2025 (UTC)[reply]
The scripts aren't bad at a technical level, I believe @Polygnotus wrote a amalgammated script that works for a bunch of LLM providers. The idea is also not bad, if your prompt engineer properly, having a LLM proofread your work might be useful to catch small grammar or tonal mistakes. Sohom (talk) 01:24, 13 June 2025 (UTC)[reply]
Thank you, everyone, for looking at the work and thinking hard about this. The team and I are really grateful for the discussion and the many perspectives, ideas, and concerns it is surfacing – many of which we had thought about, and many which we hadn’t. I’ll first say that I’m sorry for the way we brought up this idea here – though we’ve posted about this idea before on WP:VPT and brought it up on community calls and at Wikimania, we should be talking with communities about controversial ideas with plenty of context and heads-up. Going forward, we need to make sure it’s clear what problem we’re trying to solve, and explain why we think our idea might help (and what pitfalls we think the idea might have). And with enough heads-up to communities, we can incorporate and react to the opinions of the volunteers who know the wikis well – ideally building out our ideas and plans together.
In short, we still have this Simple Summaries project on hold. That means that we are reading and thinking about everything you’ve posted so that we can regroup to have the next conversation about how to improve Wikipedia for readers. We’re not going to begin with directly answering the many specific questions you all have asked in this thread or to clarify how we had planned to go about this experiment (though we want to do that at some point in the future!) While the intention of this experiment was to help with reader understanding and learning, I think we should take a step back and talk together about what priority problems need solving for our readers, and how to solve them. As many of you have said, LLMs are just a tool that could potentially help – not an end unto themselves.
I also hope we can continue talking about how best to experiment, because small-scale experimentation is a powerful way to learn what works and what doesn’t, and then change course without expending too many resources. Our team will return to this thread to start some of the next conversations we're hoping to have. -- MMiller (WMF) (talk) 14:30, 11 June 2025 (UTC)[reply]
Thanks a lot! I believe that having a discussion between the WMF and the community on how best to experiment going forward is a great idea. I would be more than happy to help organize such a discussion on best practices for A/B testing and on-wiki experiments in general, instead of having it be centered on such a polarizing case as generative AI. It could take place at WP:VPWMF with the English Wikipedia community, and maybe lead to a global discussion at Meta down the line if that first one is a success. Chaotic Enby (talk · contribs) 15:06, 11 June 2025 (UTC)[reply]
This is good to hear :) As a very long time reader, and only just recently starting to get involved editing properly, Im glad to hear that you will be considering what readers actual priorities are. In my personal experience, I come to Wikipedia for what I can safely assume to be a reliable, and concise but still fairly in depth overview of topics. A simple one or two sentence summary would not be enough for me - Reading the meat of the articles is where the fun is! NoSlacking (talk) 17:50, 11 June 2025 (UTC)[reply]
I hope if you run an LLM experiment in the future that you will include a clear ethical disclosure (such as how the AI acquired its datasets & if there are copyright concerns, what are the environmental impacts of including something like this on every article, etc). As an aside, 404 Media just published an article ("Wikipedia Pauses AI-Generated Summaries After Editor Backlash") about this test & the reaction at the village pump. Sariel Xilo (talk) 20:48, 11 June 2025 (UTC)[reply]
Eh, the last sentence in Kyle Wigger's TechCrunch article, "While Wikipedia has paused its experiment, the platform has indicated it’s still interested in AI-generated summaries for use cases like expanding accessibility" is true, and I find that worrisome. The "platform" he refers to is WMF, not the Wikipedia Community. But WE are Wikipedia. Carlstak (talk) 00:51, 12 June 2025 (UTC)[reply]
Thanks! The question of experimentation is a good one, because obviously there is a lot of community hesitation about testing AI-based features on actual readers, and yet to understand real impact, the WMF needs the ability to try out experimental features on readers. Not sure how best to square that circle. —Ganesha811 (talk) 21:50, 11 June 2025 (UTC)[reply]
Thanks for putting it on hold. There might be roles for GPT-type mechanisms on Wikipedia, but I don't think producing article text will ever be one of them. To me the focus of it is this: Wikipedia should be reliable. It should reliably reflect the content of the sources it draws from, and "reliable" is not something that the GPT-alikes are good at or could possibly be good at. They are probabilistic. That is inappropriate for such a task. There are many roles where they might fruitfully enhance or amplify editor effort, but they are fundamentally inappropriate for replacing it. Particularly they are inappropriate for a first point of contact with articles — a top-of-the-page placement inherently says, in the language of design, "this is more important, pay attention to this, this matters." Putting inherently unreliable information in that position is very bad. Many articles about technical topics (e.g. math) are difficult to understand, but while there are problems with this state of affairs, those articles truthfully tell readers that the subject matter itself is difficult to understand. If the current articles make it difficult for a lay reader to understand a group of Lie type, a ring (mathematics), or lattice (order), that is far preferable to a GPT-alike telling those readers something that is both easier to understand and also wrong. Additionally, as others have mentioned, most of them have Wikipedia as part of their source corpus anyhow, so there would be no particular value added by such a summary as was proposed. Krinn DNZ (talk) 23:19, 11 June 2025 (UTC)[reply]
Regarding "but I don't think producing article text will ever be one of them", it might work in specific constrained domains. For example, this is an interesting paper. I would rather keep an open mind. I hope the WMF will at least be able to test things that might have some utility. Sean.hoyland (talk) 11:11, 12 June 2025 (UTC)[reply]
The fundamental issue regarding producing article text raised by the abstract of that paper ("Wikipedia-style summaries of scientific topics that are significantly more accurate than existing, human-written Wikipedia articles") is that if we get to the point where AI does this, and we accept it is better and use it, then there's no point figuring out how to get it to work here as Wikipedia would be obsolete. There's no point going to a dedicated site when you have AI that can spin something up on any topic. Any such AI would be able to pull from Commons too, although as Commons accepts AI images it somewhat erodes its own utility in that regard as the AI will be able to generate its own images instead of pulling Commons-hosted AI images. CMD (talk) 12:48, 12 June 2025 (UTC)[reply]
It seems very likely that we will get to the point where AI does this, and perhaps the majority of people out there accept it is better and use it, and our relationship to sites and sources will be very different. I assume Wikipedia has a good few years left and there are bound to be some tools that can help editors and readers. "Simple summaries" seemed like a bit of an odd choice to me, but I'm just glad to see people trying things. If they don't work, that's okay. I wish there was more experimentation in Wikipedia in general. There is a lot of inertia in the system. Sean.hoyland (talk) 14:00, 12 June 2025 (UTC)[reply]
WMF's after-action report on this should address how AI-generated summaries that called the genocide of Jews a "sad event" and defended 4chan were about to be rolled out. I'm not sure how we can trust any future AI experiments unless there's a clear explanation of what quality control processes will be in place. voorts (talk/contributions) 01:23, 12 June 2025 (UTC)[reply]
I'm not sure how we can trust anything from the WMF at this point, as they have consistently shown extreme sloppiness and disregard for the community in recent years Ita140188 (talk) 12:51, 12 June 2025 (UTC)[reply]
If the lesson taken away from here is mostly about communication, that would be a mistake. There's always going to be ways to improve communication and there probably is some lessons, but I don't think there was an issue with for example posting a note about the start of an experiment to VPT. What does need to be looked at is what happened during the process as it moved from the initial communications and announcement to the reaching of the now-paused trial phase. There are issues that should have been flagged within that process that don't seem to have been, and it's really those that have been the focus of concern here rather than communication. CMD (talk) 02:29, 12 June 2025 (UTC)[reply]
The WMF has been the biggest threat to Wikipedia since a few years. It is now an existential threat that risk breaking the spirit of this project and what made it work. The WMF should only run the servers and not interfere in the content at all. Ita140188 (talk) 07:30, 12 June 2025 (UTC)[reply]
I had real concerns about the AI summary project as pitched, but for what it's worth I'm impressed with this response -- it seems to be genuinely reflective when it could easily have been defensive or tin-eared. I understand that it isn't (yet) a comment on the merits of the critiques of the AI idea itself, but I'm sure that will come later, perhaps when more orthodox consensus-building mechanisms are brought into play. UndercoverClassicistT·C09:46, 12 June 2025 (UTC)[reply]
Thank you for listening. AI has an important role to play in slashing budgets by replacing expensive humans by cheap computers which, on a good day, do the job nearly as well. That's not a problem Wikipedia needs to solve: articles get leads for free. The 404 article cited above describes Wikipedia as a "laudable model" not "degraded by the flood of AI-generated slop and misinformation". Let's keep it that way. Certes (talk) 10:40, 12 June 2025 (UTC)[reply]
Frankly, the lesson *I* am going to take away from this debacle is that WMF has far too much money if it feels it can throw it away chasing AI-LLM nonsense. Especially when it was clearly a solution in search of a problem given it appears mostly intended to replicate either or both of the lede of articles, or simple.wikipedia articles. I had better not see a banner begging for donations for quite some time. Resolute13:32, 12 June 2025 (UTC)[reply]
Honestly I am slowly coming to the conclusion that the only way to save Wikipedia from itself, other than a fork, is to starve the WMF of funds. That is, actively trying to discourage donations so that they cannot do too much damage. --Ita140188 (talk) 13:48, 12 June 2025 (UTC)[reply]
This sounds like "we think you would've been quiet about this if we explained it differently", as if the main flaw was the communication, as if you're certain people would like it if you talked about it more. While the communication was a flaw, fixing that wouldn't change that this is a horrible idea. People don't want you to come back with a fresh round of buzzwords explaining that you're going to do it anyway; they want you to not do the thing. What I'm listening for is a commitment that the WMF is not going to force-push a bad feature that had an overwhelmingly negative response. I'm not hearing that yet, so I'm very concerned that this is going to come back when WMF thinks the attention has died down. Renaati (talk) 17:38, 12 June 2025 (UTC)[reply]
With all due respect: anyone even remotely involved in this "project" should resign immediately. Readers and editors are not subjects to be experimented on. (Without informed consent, I might add!) You have not learned anything and are clearly going to keep trying to force unwanted features onto an unwilling community. James (talk/contribs) 23:26, 12 June 2025 (UTC)[reply]
I genuinely believe that this is not a productive way to address it. Yes, WMF developers were close to pushing unwanted changes, but they ultimately listened to the community, and are still listening. I don't think them resigning would do anything, besides being replaced by new people who will likely have less experience with the community. Chaotic Enby (talk · contribs) 23:33, 12 June 2025 (UTC)[reply]
I genuinely believe this latest fiasco is yet another instance of the incurable rot that has always been at the core of the so-called Foundation. James (talk/contribs) 16:01, 13 June 2025 (UTC)[reply]
CE's point still stands, replacing folks who have made a misstep with folks who are completely unaware of how the community works is a recipe for disaster. Sohom (talk) 16:37, 13 June 2025 (UTC)[reply]
I've always actively seeked out the Wikipedia link when searching Google for factual information, even more so now that everything is tainted by generative AI.
The absolute, only world in which I could accept AI on Wikipedia is if it's trained from the ground up on Wikipedia and given so little creative freedom as to be redundant.
LLMs are so wildly successful because of how good they are at mimicry, so whether a person "likes" or "finds helpful" a generated summary says nothing about the quality or accuracy of the information. It's should be clear to everyone how casually generated results are accepted. If Wikipedia cannot ensure 100% accuracy of the data it's summarizing which it cannot then it shouldn't move forward with any generative AI project.
It would be far more inline with the stated mission to "...empower and engage people around the world to collect and develop educational content..." to help enlist humans in the work of improving the quality of summaries. Dysiode (talk) 03:44, 13 June 2025 (UTC)[reply]
Even if it were 100 % accurate - which it is not - it shouldn't be included. Wikipedia is written by humans. It's like WMF actively tries to get rid of editors. Lupe (talk) 08:55, 13 June 2025 (UTC)[reply]
Yes, right. If Wikipedia cannot ensure 100% accuracy of the data it's summarizing an idea would be to get summaries approved or declined (regenerated/adjusted/removed) by editors to help enlist humans in the work of improving the quality of summaries the quality can be good but people often want a different level of simplicity and/or length in addition to the current Wikipedia article one (that is n=1). For enlisting humans, it's not feasible to get that many new and current Wikipedians to manually create simple-level summaries for all articles or all articles with a somewhat technical/complex subject. Simply unrealistic; it won't happen. And I'm happy to have as much Wikipedia work automated as possible in a good way because there is so much to do. Most Wikipedians should know just how much there is to do here and not fear to become redundant just because technology is sought to be used. I'm not sure AI summaries are a good thing but it's something to consider. That people often miss a shorter simpler version in addition to the section/article lead is one of Wikipedia's problems; people may only want to get the gist and read the article if after reading that they still like to know more. I think of AI summaries as one approach to address this alongside other ones and I'm not sure if it's a good approach. I hope people approach it with a rational open mind, taking into consideration the possible ways various issues could possibly be addressed (and actual data) instead of rejecting it right away.
I'm gonna call myself involved here, but can a uninvolved passer-by admin close the discussion at the top of the thread regarding the opposition or support of the feature with a outcome ? Sohom (talk) 14:22, 12 June 2025 (UTC)[reply]
Yeah, but people are going to keep posting to it like it's still up for debate. A WP:SNOW closure might help make things clear. 3/4 of the VPT page at this point is already taken up people preaching to the choir. --Ahecht (TALK PAGE)14:52, 13 June 2025 (UTC)[reply]
Yes, that, the consensus is obvious, but peeps still keep voicing the same concerns over and over again and piling on. A WP:SNOW closure would point folks towards the correct sub-sections to raise any (newer) concerns that they might have. Sohom (talk) 15:02, 13 June 2025 (UTC)[reply]
This, especially since the recent media coverage seems to be attracting more new editors who might not have read the full context. A good closure could summarize it and indicate where constructive criticism is still welcome. Chaotic Enby (talk · contribs) 15:18, 13 June 2025 (UTC)[reply]
I've closed it, just encouraging people to move discussion down to other subsections. I don't think it's in any way equivalent to a formal RfC closure, just discussion moderation. —Ganesha811 (talk) 19:15, 13 June 2025 (UTC)[reply]
Disgusting - the waiter serves what he likes, but never what the customers ordered. And of course the German language Wikipedia is not on the testlist. The foundation knows their rebells on the other side of the pond. Bahnmoeller (talk) 15:19, 12 June 2025 (UTC)[reply]
Improving WMF IT /Wikipedia process for editor related changes
We need a better process.
The feedback above is great, but it would have been so much easier if it was at project inception (and then continued throughout the project), and we had a better way of expressing what our problems are.
We are missing a lot of standard steps that we could do in Wikipedia (What are our issues? What is the proof that the problem exists? What is the benefit/risk/cost/motives/community priority for solving the issue? What are the options for the change? How will progress be reported?) Wakelamp d[@-@]b (talk) — Preceding undated comment added 13:01, 13 June 2025 (UTC)[reply]
Improving the measurement of the problem
The issue here is making our articles more accessible, right? But you can't manage what you can't measure and the current interface doesn't seem to give feedback about the reading level of the prose which is being written.
So, as a way forward, I suggest that someone make such scores easy to find from within Wikipedia. For example, these might be added to gadgets like WP:PROSESIZE. If such readability metrics were readily available, then they could be used in our peer review processes. We might then have a better appreciation of the problem. Remedies and solutions might then be easier to agree.
The problem goes deeper than that. Reading the summaries, one of the things that jumps out is that they seem to be written for 7th graders, not simply at a 7th-grade reading level. That's where the didactic and/or excitable tone comes from -- Flowers are the special parts of flowering plants that make babies! -- and the sugarcoating of controversial topics like genocide. The various iterations of the system prompts tweaked the "7th grade" wording slightly, but the result seems to have been similar.
This gets at one of the big questions that should have been ironclad from the start: who is this for? (Besides not us.) If the intent was to address global knowledge gaps and target readers less fluent in English, then why are we giving them summaries that treat them like children? And if the intent was indeed to write them for children, why include topics like bukkake and necrophilia? No one seems to have asked these questions. No one seems to have tried to alter the prompt much -- which itself is wild, because the whitepaper for summarization suggested and demonstrated several ways of doing so. While they did throw out several of the summaries for this "inappropriate tone," they didn't do a thorough job, and it doesn't seem like they acknowledged the root cause. Gnomingstuff (talk) 16:30, 13 June 2025 (UTC)[reply]
Wikipedia is obviously for anyone and everyone. Its texts already have a hierarchical structure – the simple description, the infobox, the lead, the body and whatever else. My vision is to provide an easy way of assessing the reading level and other measures of these elements. As they are supposed to vary in difficulty, we'd then have a way of measuring whether they are doing so. The information might also be provided to readers to help them understand whether they are at the right level. While lots of people have pointed out that the lead of an article is supposed to be a simpler summary of the detailed sections, the leads don't actually explain this to the reader who tends to be just presented with a huge scrolling page and left to figure out its structure. Andrew🐉(talk) 17:04, 13 June 2025 (UTC)[reply]
Well, most readers are presented with the first paragraph, the infobox, the rest of the lead, and then a number of collapsed lv2 headers. CMD (talk) 02:19, 14 June 2025 (UTC)[reply]
You're talking about the mobile view, right? Checking that with Dopamine(see screen shot), I find that I don't even get all of its first sentence on the first screen. That's because there's lots of other stuff including headers, banners, menu links, alternative topics and more. It's quite a busy interface and that's an argument against adding yet more non-essential features and clutter. Andrew🐉(talk) 12:21, 14 June 2025 (UTC)[reply]
This was actually studied by the m:Research:Multilingual Readability Research project under User:MGerlach (WMF)! The project tried to evaluate readability metrics in many different language editions of Wikipedia, by establishing corpora which they then evaluated with both language-agnostic and multilingual models, in what is called Automatic Reading Assessment (ARA).The team finally opted for the latter, with their ARA model (TRank) being trained on 14 different languages for which a "simplified" version was accessible at either Simple English Wikipedia, Txikipedia or Vikidia. This allows them to compare the model's estimates with FKGL scores for both the regular and simplified corpora, and thus produce a mapping between model scores and Flesch-Kincaid reading levels.Their research results, covering these 14 languages as well as 10 others, are available on https://martingerlach.github.io/assets/pdf/2024.acl-long.342.pdfIf anyone is curious, a stalled research project was drafted at m:Research:Understanding perception of readability in Wikipedia to evaluate readability from a reader-first perspective. While it did not go through, it can still be an interesting read for research pointers. Chaotic Enby (talk · contribs) 13:12, 14 June 2025 (UTC)[reply]
My other question about this percieved issue comes at a holistic level - it's easy to pick and choose some fiendish articles that are "too hard" (Bose–Einstein condensate, Hasse–Minkowski theorem etc) and then carry a grudge about science topics, but is that a fair assessment or just one-off a bad experience? Some kind of cross-article mega survey would help to answer questions about whether this is a widespread issue or just a relatively smaller number of articles needing remediation. Hornpipe2 (talk) 15:22, 15 June 2025 (UTC)[reply]
Trouble looking at diffs
Hello, everyone,
I've been having problems looking at an individual edit/diff. Even for small edits, I click on the link in the page history and seconds later, I get the message "It took too long to compute your changes, so the description below may not be optimal." and then the page appears below, all in red so it is basically unreadable. It's Thursday, did any big changes occur in the system? Thanks for any explanation you can offer. LizRead!Talk!00:23, 13 June 2025 (UTC)[reply]
The reply tool and New section buttons aren't working for me half the time, I'm wondering if there is just something running slow somewhere. CMD (talk) 02:36, 13 June 2025 (UTC)[reply]
Hi Liz. [EDIT @ 09:45, 13 June 2025 (UTC) : TLDR: The "Visual" diff will time-out after a few seconds, if the diff is too complicated for the algorithm to analyze. Try switching to the Wikitext diff for those viewing kinds of revisions. Details follow:]
I cannot reproduce this bug, and I haven't seen it mentioned elsewhere, and I see you have an vast quantity of user-JS... (User:Liz/common.js and /vector.js)
So first I tried testing all your user-JS in a test-account; however that didn't help me reproduce the problem, as I can still see both types of standard diffs on desktop (Visual and Wikitext), even complex diffs (e.g. screenshot: phab:F62308675) on multiple test pages.
Then I tried searching Phabricator for the specific error-message string you provided, and it's only mentioned in a single old task about the wording of the message itself, but the tag (#VisualDiff) and a comment therein (phab:T194944#4213911) explains (IIUC) that: [TL;DR] This error-message is shown for Visual Diffs whenever the user's computer/phone is taking too long to render all aspects of the diff.
If you see this error again, but only sporadically, you could use the workaround of switching between the other Diff type(s). I.e. phab:F62308691
To further diagnose the bug, we'd need to know if it's
(1) related to a specific page-history (examples always help!), OR,
(2) if it's related to your extensive user-JS or a gadget, OR,
(3) if it still happens even with those removed (in which case it might just be that your computer is too busy doing other things).
You can most easily test & confirm the 2nd possibility by adding this string &safemode=1 to the end of any URL you see the bug at. What it does is load the page but ignore all gadgets and user-JS.
@Quiddity I downloaded MediaWiki and then I grepped it.
"visualeditor-diff-timed-out": "It took too long to compute your changes, so the description below may not be optimal.", is in mediawiki-1431/extensions/VisualEditor/lib/ve/i18n/en.json
@Quiddity (WMF): To reproduce this: take an article that is already long. Then use search and replace to replace all instances of the letter 'e' with something else (which ensures that the diff view will be very complicated). Then use lipsum.com to generate 50 paragraphs of nonsense and add those to the article too. That way you'll see the same error Liz sees. Quarry 91714 will tell you what the longest articles are (e.g. List of chiropterans). Press publish, then Review your changes. I added a screenshot. File:Quiddity (WMF) error message Visual Editor reported by Liz.png It is possible that @Liz: does not have the fastest computer ever. Or used a slow phone or tablet. Polygnotus (talk) 06:37, 13 June 2025 (UTC)[reply]
@Quiddity: Do you know the current timeout setting used? It sounds like a good idea to increase that with a second or two for people using slow devices (and/or a lot of JS, although this isn't onLoad so the amount of installed scripts is probably irrelevant). Since the diffing happens on the user end its not like Wikipedia is affected by how long it takes. Who creates a Phab ticket? Polygnotus (talk) 10:22, 13 June 2025 (UTC)[reply]
This happens to me sometimes. It is one of the error messages for visual diffs. I suspect it only happens on big pages. Is it only happening for you on big pages? It seems clear from the error message that this error should correlate to the size/difficulty of the diff. –Novem Linguae (talk) 18:33, 13 June 2025 (UTC)[reply]
Month in country category header
Ever since the idea of categorizing things as "[Month] [Year] events in [Country]" started catching fire, there's been a recurring issue at Special:WantedCategories where people create the category for one specific month and year in one specific country, but then fail to create the "[Year] in [country] by month" parent that gets autogenerated by {{Month in country category header}}, thus leaving a redlinked category behind — but because this is all happening in an incredibly scattershot fashion rather than by any kind of coordinated project, there's frequently only one month with its own category, such that the creation of the parent category can't be justified until there's more than just one month for it.
But in turn, because the category is autogenerated by a template, I'm left having to either wrap the template in {{suppress categories}} and then manually readd it to all of the appropriate bluelinked categories, or create the "[Year] in [Country] by month" category as a redirect to the base "[Year] in [Country]".
This isn't an isolated issue, either: there's always at least one instance (and sometimes several instances) of this every time WantedCategories updates with new redlinked categories.
Accordingly, could somebody more versed in template coding than I am modify that template to slap an #ifexist condition on "[Year] in [country] by month", and to automatically just use "[Year] in [Country]" if the month category doesn't already exist? Thanks. Bearcat (talk) 17:21, 13 June 2025 (UTC)[reply]
@Bearcat: An example is always good. I couldn't find a current example, maybe because you fixed them, so here is a hypothetical example. Suppose Category:June 1989 in Romania was created (similar to Category:June 2022 in Romania). {{Month in country category header}} would add the red Category:1989 in Romania by month. You want it to instead add Category:1989 in Romania. The #ifexist test would be in {{Month in country category header/inner core}} on Category:{{{year}}} in {{Country prefix the|{{{country}}}}} by month. But do we really want this instead of just creating the missing category? Category:2022 in Romania by month does exist and has five month subcategories but is it so bad to only have one? It's part of a larger category navigation system. And if a a red category isn't added then the category may not be created when it would have multiple month subcategories. You wrote "the creation of the parent category can't be justified until there's more than just one month for it". Is this based on a guideline, a discussion, or your opinion? PrimeHunter (talk) 21:13, 13 June 2025 (UTC)[reply]
It's been standard practice of the Wikipedia category system, for literally the entire history of Wikipedia, that with certain specific defined exceptions in certain specific defined circumstances (e.g. Category:Albums by artist is allowed to contain "Artist albums" categories for any artist even if they only ever released one album), categories are not supposed to be created for just one thing, and require several things before their creation is warranted. You can peruse CFD and plainly see that "category created for just one thing", or "category that was previously populated, but most of its contents have been deleted or redirected, so that it now has only one thing left in it", are seen as deletion rationales, and routinely succeed as deletion rationales, all the time.
And even if you want to decree that "[Year] in [country] by month" categories should be added to the "one-entry categories are permissible" exceptions list, they would need to be handled in some other way that prevents them from becoming the redlinked category cleanup's job to deal with, such as a bot that automatically creates any non-empty category of that type whenever one shows up. Bearcat (talk) 12:46, 16 June 2025 (UTC)[reply]
<mw:dt-ellipsisbutton> is internal markup that you shouldn't see :) We need to use placeholders like these, because they're shown in the user's language, while the rest of the page contents is shown in the wiki's language. It is used to display an additional button next to "Reply" with a dropdown menu of actions, including "Thank" (T366095) and "Report" (m:Incident Reporting System), but these features are not yet enabled here. Matma Rextalk09:53, 16 June 2025 (UTC)[reply]
It seems there isn't. Only a PHP hook was added in gerrit:961809. You could easily enough add an item to the dropdown menu from JS when it is shown (OO.ui.infuse() it and go wild), but you can't make it appear when it isn't. Matma Rextalk13:34, 16 June 2025 (UTC)[reply]
Citation in infobox does not work in visual editor
If you open this revision in VisualEditor, both the PBS citation in the infobox and the TIME citation after the first sentence in the lead of the article show up as number [1], even though they're not the same. The PBS citation in the infobox also doesn't show up in the "References" section and thus cannot be selected to edit using the visual citation/template editor. The issue doesn't occur in the source editor's preview pane or when viewing the article normally—then, the PBS citation is correctly labeled [1] and the TIME citation [2], and both appear in "References" as they should. 2A00:807:D3:9A9A:986B:2094:714B:898C (talk) 10:47, 14 June 2025 (UTC)[reply]
VisualEditor has limitations when references are inside template parameters. If you edit the infobox then the source text of the reference can be edited in the "Part of" field. PrimeHunter (talk) 11:06, 14 June 2025 (UTC)[reply]
Some links are interpreted incorrectly in the Wikipedia mobile app
In the app, if you scroll down to the External Links section of the article pedophilia and open the wikiversity link, it actually opens https://en.wikiversity.org/wiki/Pedophilia:%20Innate%20or%20Learned? rather than https://en.wikiversity.org/wiki/Pedophilia:%20Innate%20or%20Learned%3F and because the browser interprets ? as a separator, it tries to open v:Pedophilia: Innate or Learned, which doesn't exist. Weirdly though, it only happens in the app.
@HyperAnd: I see your Phab report is about the Android app. I have the iOS app 7.7.5 (5231) on an iPhone 8 with iOS 16.7.11 and Safari. The app is not for Wikiversity so v:Pedophilia: Innate or Learned? opens in Safari and works correctly for me. Internal links like Quo vadis? stay in the Wikipedia app. I don't know the Android App. Does the link open in the app or a browser for you? If it's a browser then I think your report should say so and name the browser. PrimeHunter (talk) 23:34, 14 June 2025 (UTC)[reply]
This edit of mine[5] seemed to do something disastrous to much of the content of the talk page. I self-reverted and the missing material reappeared. A second attempt at posting in a slightly different way had the same effect, so I reverted again. I cannot see anything wrong with what I have done, so could someone take a look at this for whatever has gone wrong.
Thanks, ThoughtIdRetiredTIR20:19, 14 June 2025 (UTC)[reply]
In this edit, an editor mentioned refs tags, which actually implemented a ref. The reflist template that you added then put the rest of the page into references. I put some nowiki tags around the code, so you should be able to add your comments as normal now. Woodroar (talk) 21:44, 14 June 2025 (UTC)[reply]
The nowiki tag got stripped off the "ref" tag (edit: or wasn't there before, but was added while I was looking into this) which messed up the parsing. I don't know how that happened, but that's how it happened.
Why is Zo nationalism in the backlog of pages needing an infobox conversion?
I hope I'm asking this in the right place. It's been in the backlog for awhile and I don't understand why. If I someone would explain it to me, I might be able to address other pages like that which I come across. I'd be really grateful. Oona Wikiwalker (talk) 00:44, 15 June 2025 (UTC)[reply]
@Oona Wikiwalker: Do you mean the last entry in your pages link? It says Talk:Zogam for me, not "Zo nationalism". What does it say for you and what happens when you click it? I go to Talk:Zogam and stay there but I have discovered that the corresponding non-talk page Zogam is a redirect to Zo nationalism. I don't know something which could cause the category page to say "Zo nationalism" or cause the talk page link to go there. Talk:Zogam was added to the category by placing {{New infobox}} on it in 2024 [6] when Zogam was an article and made its infobox with a wikitext table [7] instead of an infobox template PrimeHunter (talk) 01:59, 15 June 2025 (UTC)[reply]
So, do you think I can just remove the tag, since there is no infobox to convert? It must have been placed in error... I thought about adding an infobox from scratch, but I'm not even sure what the article is about... a people? a political movement? a social movement? I don't think the article even knows what it's about. Oona Wikiwalker (talk) 02:22, 15 June 2025 (UTC)[reply]
After making this report, I got the normal ping "Cannot send mention etc." for reporting an IP. However, I then got the same ping 2 minutes after that, and a 3rd identical ping another five minutes later. Any reason this might have happened? CMD (talk) 15:21, 15 June 2025 (UTC)[reply]
Wiki🖤︎
Does anyone know when and why the wikilove button was changed from a heart icon to text? I always accidentally click on it instead of history. Aaron Liu (talk) 17:08, 15 June 2025 (UTC)[reply]
"articles" vs. "pages" in WikiProject rating categories again
The latest run of Special:WantedCategories has been weighed down with over 200 redlinked categories being spawned by {{WikiProject Military history}}, of the "Something something pages" variety, where a category almost always already exists at the form "Something something articles" for the exact same value of something-something, and is being moved to "pages" on some pages while remaining at "articles" on other pages with the exact same template parameters on them. But the template itself has not been recently edited, which means that once again the redlinks are being smuggled in via a module.
But since this is only happening on some pages and not on others, I have no idea how to resolve this as every solution I've tried so far has caused other problems. Moving a category from "articles" to "pages" broke stuff, redirecting a "pages" redlink back to the "articles" form broke stuff, and on and so forth — so I just don't know what to do about them, but can't just leave them sitting red either. Today's update was already the second run in which these categories have failed to go away (and in fact increased in number compared to the previous update), so they absolutely have to be resolved one way or another because they're actively interfering with cleaning up other redlinked categories — if I go with the "ignore these and deal with everything else" approach, it's become untenably difficult to even find the everything else in the list because there are so many of these to ignore, so the solution cannot be "just put up with it".
Indeed, that worked. Thanks. Obviously if there is a desire to move all WikiProject rating categories to "pages" across the board, that's fine if it happens consistently and gets dealt with systematically — but this, with the categories moving to redlinked versions on some pages and staying in bluelinked versions on others, is clearly not how such things should be done. So thanks again, I'd never have found that on my own. Bearcat (talk) 20:43, 16 June 2025 (UTC)[reply]
I've given that a try already but it doesn't seem to be working. The whole template population system is a total mess and these random changes keep making it worse. Timrollpickering (talk) 22:01, 16 June 2025 (UTC)[reply]
Seems the module reversion plus deleting has done the trick. We must get better protection for the module so one user can't repeatedly create these messes and dismisses the problems caused by them. Timrollpickering (talk) 07:48, 17 June 2025 (UTC)[reply]
The check_fallbacks function that Pppery modified is designed to get the type of page to fallback to something appropriate in the event that a category does not exist. For example if placed on a category talk page then it would look to place the page in Category-Class TOPIC pages, but if that category does not exist then it will fall back to NA-Class TOPIC pages. Similarly FM-Class will fall back to File-Class. This logic was never intended for WikiProjects which have opted out of the standard scale. These projects should really define all the custom logic that they want in their custom class masks — Martin (MSGJ · talk) 13:22, 17 June 2025 (UTC)[reply]
In the case of the categories listed above:
For the Help project, these ought to be Category:B-Class Help pages, etc. because they are assessing the quality of help pages, not articles.
For the Military history project listed above, I suggest the issue is with the logic in Template:WikiProject Military history/class. I would guess that the template is allowing editors to assess redirects, disambiguation pages, etc. with a quality class (e.g. Stub-class) instead of automatically applying Redirect-Class or Disambig-class which the standard code does by default.
I reverted that change because I observed that when I previewed with that change reverted pages currently in redlinked categorries were no longer in them, and indeed my revert seems to have solved the immediate problem and caused pages no longer to be in redlinked categories. I can still reproduce this right now; if I undo my own edit and preview Talk:Atlantic Revolutions (among other pages), it displays several categories that don't exist. * Pppery *it has begun...19:03, 17 June 2025 (UTC)[reply]
Okay. Well, the edit to the module was correct, but some opt-out projects need to improve the logic in their custom masks. I have removed the help project's quality ratings based on a discussion I saw on their talk page. And I will work with the military history project to improve their template. (This is the problem when projects opt out but then don't maintain their bespoke code!) I will reapply that edit to the module shortly. Thanks — Martin (MSGJ · talk) 09:20, 18 June 2025 (UTC)[reply]
Tech News: 2025-25
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
You can nominate your favorite tools for the sixth edition of the Coolest Tool Award. Nominations are anonymous and will be open until June 25. You can re-use the survey to nominate multiple tools.
Foundation staff and technical volunteers use Wikimedia APIs to build the tools, applications, features, and integrations that enhance user experiences. Over the coming years, the MediaWiki Interfaces team will be investing in Wikimedia web (HTTP) APIs to better serve technical volunteer needs and protect Wikimedia infrastructure from potential abuse. You can read more about their plans to evolve the APIs in this Techblog post.
Looking at the blog post about their API plans, I'm glad to see that the planners seem to have avoided some of the worst past mistakes. I still see some hints they haven't entirely given up on bad ideas like "API tokens" though. And I find it amusing that they're celebrating plans to add things to the REST APIs that the Action API has had since 2014 or 2015. Anomie⚔00:20, 17 June 2025 (UTC)[reply]
I nominated {{Database report}} for the Coolest Tool Award. If you're a data nerd like me and can write SQL, it's pretty powerful. I had trouble thinking of other tools to nominate because they had already won before. Any suggestions for other tools for me (or others) to evaluate and potentially submit? I already know of tools lists in various spots, so I'm looking for specific personal recommendations. What really excites you? Stefen 𝕋owers among the rest!Gab • Gruntwerk05:19, 18 June 2025 (UTC)[reply]
Can anybody give me an idea of what the current stub count is roughly, using 1500 bytes of readable prose as a threshold? Category:All stub articles has about 2,321,000, about 33% percent of all articles, but I could have sworn when I asked a few years ago there were over 3 million and it was 57% of all articles. Of course there'll be many articles under 1500 bytes currently not stub tagged. ♦ Dr. Blofeld08:24, 17 June 2025 (UTC)[reply]
I wonder if the figure you saw before was based on talkpage stub-tagging? That total is currently ~3.9m, which would be ~55% of all articles, though there is potentially some double counting, mistaken tagging of disambigs/redirects, etc. It's certainly in the same range though.
I'd love to know an answer for this as well - a couple of years ago someone calculated prosesize for all FAs, but I don't think it's been done for all pages. Will have a look and see what I can find. Andrew Gray (talk) 12:21, 17 June 2025 (UTC)[reply]
@Dr. Blofeld So I've dug into this a bit more, and I think that a) that must have been the source of the figure you saw before, but b) on reflection it's almost certainly an overcount and I should have spotted that sooner!
Wikipedia:Content assessment has a table with a total of 7.86m rated articles (plus another 394k unrated). This is where we get the 55.6% figure - it assumes every talkpage stub tag matches a different stub article, 3.9m articles. But of course we don't actually have that many articles.
The biggest factor in the overcount seems to be that pages are counted multiple times under different importance ratings. If we count the number of distinct mainspace pages that have a stub class talkpage template, we get a more conservative 3.14m, or 44.8% of articles. (petscan query). I think this is going to be closer to the correct value.
(I did wonder if it was possible that talkpage tagging would have a lot of "lag" - pages that were once stubs but have since been improved. It turns out that 95% of the corresponding articles are under 5000 bytes pagesize, which does suggest that they are mostly still broadly "stubby", even if we can't quite map that to the prose-size threshold.) Andrew Gray (talk) 12:31, 18 June 2025 (UTC)[reply]
We are looking for a pilot for our new feature, Favourite Templates
Hello everyone! We're building a new feature, called Favourite Templates, that will provide a better way for new and experienced contributors to recall and discover templates via the template dialog, that works with both VisualEditor and wikitext editor. We hope this will increase dialog usage and the number of templates added.
Since 2013, experienced volunteers have asked for a more intuitive template selector, exposing popular or most-used templates on the template dialog. At this stage of work, we are focusing on allowing users to put templates in a “favourite” list, so that their reuse will be easier. At a later stage, we will focus on helping users discover or find templates.
We are looking for potential additional testers for Favourite Templates, and we thought you might be interested in trying it out. If so, please let us know if it is the case, we would be happy to set up a pilot. So far, the feature has been deployed successfully on Polish and Arabic Wikipedia, and we’re currently in talks with German Wikipedia and Italian and English Wikisource for expanding the pilot phase.
In addition, we’d love to hear your feedback and ideas for helping people find and insert templates. Some ideas we’ve identified are searching or browsing templates by category, or showing the number of times a template has been transcluded.
Hi @Nardog, thanks for your reply. If there is consensus, we would like to deploy the feature on English Wikipedia, so that individual users might test it out. Also, we would like to understand how you normally search for templates to be inserted into articles, in terms of how many do you use and how frequently you use them. Sannita (WMF) (talk) 14:45, 17 June 2025 (UTC)[reply]
Indeed. Make it a beta feature, and create a Wikipedia-space page for it to explain what it is and how it works. Ask for feedback on the accompanying Wikipedia talk page. You will get much better results from this community if you keep all of the traffic local instead of hoping that people will go over to Meta or Test wherever to give you feedback and answer your follow-up questions. I never deliberately check my watchlists on any sites except en.WP. – Jonesey95 (talk) 00:25, 18 June 2025 (UTC)[reply]
Also, if the feature turned out to be useful but it could only be used on certain wikis, that would be quite frustrating. Nardog (talk) 01:40, 18 June 2025 (UTC)[reply]
Our scope is to deploy on several wikis for testing, and then deploying on all wikis, once the feature proves to be useful. Since it is a wish from users from the Wikimedia communities, we do think it would be a useful addition to your functionalities, but we're open to suggestions on how to make it better. That's what piloting is for, in all cases. :) Sannita (WMF) (talk) 09:27, 18 June 2025 (UTC)[reply]
Just to be clear, is the template dialog the puzzle button that creates a searchbox of templates? On my screen it calls itself the TemplateWizard. CMD (talk) 14:57, 17 June 2025 (UTC)[reply]
Hi @Chipmunkdavis, thanks for your question. No, it would be a separate function, that will allow you to create a list of "favourite" templates, for you to call and re-use more quickly. For example, the Cite templates you use the most, or the infobox you usually use when writing an article, and so on. Sannita (WMF) (talk) 15:37, 17 June 2025 (UTC)[reply]
CMD is asking what you meant by "the template dialog" in your first post. If you meant TemplateWizard then it's not so much "a separate function". Nardog (talk) 23:54, 17 June 2025 (UTC)[reply]
@Chatul Thank you for your message, I will report your suggestion to the team, and see if we can work it on. Since we're still in the test phase, I doubt such changes will happen soon, but I'll see that they get triaged. Sannita (WMF) (talk) 09:25, 18 June 2025 (UTC)[reply]
I'm not sure which of the above categories it would fit in, but by far my most used template in article space is {{convert}}, and making it generally more known would be a great asset. Thryduulf (talk) 03:31, 20 June 2025 (UTC)[reply]
Fixing PageViews templates
I wonder if an iframe type solution could be allowed for this, where some service produces embedable pageview graphs, or if all pageview templates can be removed from talk pages. I don't think the charts extension will support dynamic content, so porting it is a lost cause.
GalStar (talk) 18:07, 17 June 2025 (UTC)[reply]
Right now charts can not fetch PageViews. Well, apart from the jank of letting a bot populate the data into the data namespace on commons. That jank will also send the message to developers that a proper solution is not needed, so it is better to wait. When developers have been asked about it, they have said since the chart is on a talk page it is not a priority. wikitech:SLO/Charts exists however, so it might be supported at some point, but it will be one of the last things to be worked on. Snævar (talk) 19:07, 17 June 2025 (UTC)[reply]
Thanks! It made me realise I had worked with some other workaround in the past as well [9], but I'm not sure whether it will cause any problems. Not using rowspan in the 5th column could indeed be an option, but would duplicate references even more than I have already done. Dajasj (talk) 19:03, 17 June 2025 (UTC)[reply]
A row was rendered with height 0 because there was no content which had to be displayed in that row. A workaround is CSS to force increased height in a cell. PrimeHunter (talk) 20:25, 17 June 2025 (UTC)[reply]
Hi, I have been using Huggle for years, but yesterday, after logging into Huggle, the system displayed a "Wikimedia Foundation" error message and advised contacting Wikimedia system administrators. If anyone knows any Wikimedia system administrators, please let me know or provide the link to the page for reporting issues. I have reported this to https://phabricator.wikimedia.org/ and if this is not the venue to report the incident, then please let me know. Thank you. Cassiopeiatalk02:25, 18 June 2025 (UTC)[reply]
"Wikimedia Foundation" error message"
"If you report this error to the Wikimedia System Administrators, please include the details below.
Request served via cp5018 cp5018, Varnish XID 446793839
Upstream caches: cp5018 int
Error: 429, at Tue, 17 Jun 2025 03:59:01 GMT
Sensitive client information
IP address: //Reducted//"
Not sure if there's any fix for that Welcome page, but you can change the default provider to start getting RC queue. (System -> Change Provider > IRC or XmlRcs) Currently, Huggle is pretty much unusable for me because every time I rollback an edit, it says I'm not logged in and the app crashes; there r other people with the same issue too at Wikipedia talk:Huggle/Feedback. — DVRTed (Talk) 03:54, 18 June 2025 (UTC)[reply]
DVRTed Huggle used to work when connected to XmLRcs, then about some months ago, I have to change to Wiki to load the edits but they system never should the "Wikimedia Foundation" error message". I have changed to Wiki as provider and it works. Thank you. Cassiopeiatalk04:08, 18 June 2025 (UTC)[reply]
This is a fundamental design flaw with the Vector 2022 skin. There are probably a few Phabricator bugs about it from a few years ago when the skin was introduced, but as far as I know, there has been no resolution to the problem. – Jonesey95 (talk) 14:21, 19 June 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
With the context of SD0001's patch, I still support the separate namespace solution, per Pppery. Sure, it would be nice to have fewer namespaces, but seeing as the phab hasn't moved since November I think waiting for the patch would probably push back the potential AELECT dates by a significant time with only relatively minor gains to show for it. BugGhost🦗👻16:46, 19 June 2025 (UTC)[reply]
I support this, even after learning about the patch. If that patch is ever deployed then the namespace can be withdrawn at that time, but as that is not guaranteed to happen (let alone guaranteed to happen before we run our first local election) the namespace solution is better now. Thryduulf (talk) 18:37, 19 June 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Adding SecurePoll logs to the MediaWiki namespace
To make consensus easier to link to in phab tickets, can we also get a survey going in this subsection for the alternate proposal above? The alternate proposal is turning on $wgSecurePollUseMediaWikiNamespace = true which will put the same SecurePoll logs discussed above (example) into a read only section of the MediaWiki namespace. The section affected will be all pages that start with MediaWiki:SecurePoll*, case sensitive. If we do this, then we get the same benefits as above (wiki-like page histories of settings changes made to polls, and ability to view poll settings in JSON format), without having to create a new namespace. This feature is still being coded, but I think we can get it across the finish line in a week or two. Is this alternative approach OK? –Novem Linguae (talk) 00:09, 20 June 2025 (UTC)[reply]
When it is technically possible we should adopt this solution, we should use the dedicated namespace option until that time. Thryduulf (talk) 00:19, 20 June 2025 (UTC)[reply]
I would like to avoid potential migration of old logged efforts and subsequent removal of the namespace (== more engineer time needed). If it delays things a week or whatever, that's not a big deal. A +2 on that patch this week would make the software available next Thursday, a +2 on the patch next week would make it available the week after (pending whether there's a deploy the week of July 4, so at latest July 10). And either way, the alternative of using a whole separate namespace for this material would likely not be available until next week, even ignoring however much time this request for consensus is available.
In the end, I don't think the timeline changes materially, and if I review the proposed schedule for the next use of SecurePoll the timeline changes not at all, even including time for kibitzing prior to plugging all the candidates in. And there's even another week of time in that schedule available.
I am fairly confident we can get a review on the patch in time. Novem and SD0001 know who to poke about it and Novem has already started testing the patch. Izno (talk) 00:39, 20 June 2025 (UTC)[reply]
If explicit support statements are needed to establish consensus in order to smooth the way for code approval, then I support writing log information into the MediaWiki namespace. Just curious: other than the very good practical reason that it's already coded, does anyone see advantages or disadvantages in using a special prefix versus a special page and subpages? isaacl (talk) 02:26, 20 June 2025 (UTC)[reply]
To clarify, I am now in favor of this option instead of the other option. The goal of this section is to have somewhere to easily link to show consensus, which is required for operations/mediawiki-config tickets. It's probably not needed to discuss a bunch of details about "what if we do both" since it will just make this section's consensus more confusing for the WMF dev that has to read it. My plan is to just do this section only at the moment. –Novem Linguae (talk) 05:17, 20 June 2025 (UTC)[reply]
Support - I think both approaches are acceptable, I mainly would prefer whatever way is quicker/simpler to implement. Seeing as the consensus tide is turning towards applying the patch, I'm mainly just explicitly supporting this in order unblock work on the ticket. BugGhost🦗👻05:54, 20 June 2025 (UTC)[reply]
Whenever I try to scroll on User talk:Kwamikagami in the official Wikipedia app for iOS, the app immediately crashes. If I try a section link like User talk:Kwamikagami#Instruction to click "disable" then it crashes when I click the link. Does it happen to others? I don't have problems on other tested talk pages like my own. I have an iPhone 8 with iOS 16.7.11, the latest release supported by the device. iOS 16 says it's from March 31, 2025. The app says Wikipedia 7.7.6 (5398). PrimeHunter (talk) 12:57, 19 June 2025 (UTC)[reply]
Consider filing this on Phabricator with the tag "Wikipedia-iOS-App-Backlog". That tag will email the iOS app developers, helping them see your issue quicker. –Novem Linguae (talk) 13:02, 19 June 2025 (UTC)[reply]
I first wanted to hear whether it's just me. The phone has one other unrelated app which often crashes but not systematically like this. PrimeHunter (talk) 13:09, 19 June 2025 (UTC)[reply]
Rationale of the proposer: The main effect would be to officially recommend using HTML superscripts and subscripts instead of Unicode subscripts and superscripts (e.g. 2 instead of ². This has generally been done on a de facto basis, for example in widely used templates like {{convert}}, {{frac}}, and {{chem2}}. I estimate only about 20,000 out of about 7 million articles use the Unicode characters outside of templates, mostly for square units of measure or in linguistic notation that should be put into a template. A lot of articles have already been converted to the HTML method, either organically or systematically.
This would also bless the exceptions for linguistic notation, which have arisen after complaints from some editors of that topic, who say these Unicode characters are specifically intended for that purpose.
The other exceptions and sections are I think just summaries of other guidelines, put in one place to help editors who are working on typography or e.g. asking the on-site search engine "how do I write subscripts?" when they really want to know how to write chemical formulas specifically. -- Beland (talk) 04:14, 20 April 2025 (UTC)[reply]
Support upgrading to guideline. I don't see any reason not to and this looks like good advice. However, I am also no expert on HTML/Unicode, so if some compelling issue with this proposed guideline emerges, please ping me. Toadspike[Talk]09:11, 20 April 2025 (UTC)[reply]
Support as good HTML/Unicode practice. However, it could be good to have input from editors who might be more directly affected by this (maybe editors who use screenreaders?) to make sure this will not cause any unforeseen accessibility issues. Chaotic Enby (talk · contribs) 12:59, 20 April 2025 (UTC)[reply]
For context, the reason Unicode characters are allowed for only 1⁄2, 1⁄4, and 3⁄4 is that these are the only fractions in ISO/IEC 8859-1; others can cause problems, according to Graham87 comments at Wikipedia talk:Manual of Style/Mathematics/Archive 4#Accessibility of precomposed fraction characters. The only superscript or subscript characters in ISO/IEC 8859-1 are superscript "2", "3", "a", and "o". I would expect using HTML superscripts and subscripts consistently should avoid screenreaders skipping unknown characters (certainly mine reads out footnote numbers). I use a screenreader for convenience and not necessity, though, and I welcome comments from others! -- Beland (talk) 17:41, 20 April 2025 (UTC)[reply]
That depends on the amount of money and volunteer time devoted to such a project. There are a variety of both proprietary and open source products that would need to be surveyed to see even how big the problem is. With no particular effort on our part, I expect the software actually in use will gradually support more characters over years and decades. Our own List of screen readers might be a good place to start. There are plenty of other Unicode characters we would also want to have supported; if someone wants to lead an effort to do this, I could make a list or even a page that could be used for testing. -- Beland (talk) 22:09, 10 June 2025 (UTC)[reply]
Oppose Support. Wikipedia talk:Citing sources is currently having extensive discussions about which rules apply to citations and which do not. Beland (talk·contribs) is heavily involved in these discussions. I believe those discussions should be resolved before any new related guideline are created. Failing that, I notice the essay has no mention of citations. This means whoever wrote it wasn't giving any thought to citations. Therefore an prominent statement should be added that it does not apply to citations. Jc3s5h (talk) 13:24, 20 April 2025 (UTC) The RFCs about citations have been resolved, leaving the status quo in place. And the essay does mention citations, although I didn't notice it because it wasn't very prominent. Maybe it should be in a more prominent place so an editor who comes to the essay looking for information about citations can find it. Jc3s5h (talk) 20:01, 19 May 2025 (UTC)[reply]
I don't think anyone is proposing to use Unicode superscript characters for endnote indicators? It seems reasonable for endnote contents to follow the general guidance on the use of superscript and subscript markup. isaacl (talk) 17:09, 20 April 2025 (UTC)[reply]
I think Jc2s5h means that if the original title of the magazine article is "e=mc²: How a simple formula change the world" (using the Unicode superscript) then WT:CITE is talking about whether it should be 'legal' to replace that ² character with a <sup>2</sup>. (What they're really talking about is whether, if one magazine capitalizes their titles as "Man In The Moon" and the next as "Man on the moon", these different approaches to capitalization can be put in the refs of the same FA or FL and called "consistent", in the sense of "consistently accepting whatever quasi-random capitalization style is used by each individual source without regard to whether it looks consistent compared to the neighboring refs", but if "copy each separate title with no changes of any kind" is accepted, then replacing a ² with <sup>2</sup> would probably also fall in that range.) WhatamIdoing (talk) 21:05, 26 April 2025 (UTC)[reply]
HTML subscripts and superscripts should also be used inside citations. At the end of the section MOS:SUBSCRIPT#General guidelines it says: These guidelines also apply in citations [...]. This is fine. Subscript and superscript are just a matter of typesetting, replacing unicode subscripts with HTML subscripts doesn't change the meaning. Joe vom Titan (talk) 18:12, 27 April 2025 (UTC)[reply]
@Jc3s5h, any interest in changing your vote now that WT:Citing sources#RFC on consistent styles and capitalization of titles has reached consensus against treating capitalization used by sources as an acceptable citation style? With that discussion closed and this essay noting that "these guidelines also apply in citations and template parameters," it seems clear that if promoted, it would not be an an acceptable citation style to retain whatever super-/sub-script formatting is used in the source title. ViridianPenguin🐧 (💬) 16:06, 19 May 2025 (UTC)[reply]
Support with the obvious exceptions of references to characters themselves. I don't see why citations would have an exception here. Headbomb {t · c · p · b}10:50, 21 April 2025 (UTC)[reply]
Support elevating the essay as written to a guideline. It appears to give good practical guidelines for how to deal with most common situations, including the remark that it should apply inside citations. This is the only way to ensure consistent formatting since there are only few subscript and superscript unicode characters. Joe vom Titan (talk) 18:12, 27 April 2025 (UTC)[reply]
Here via WP:RFCC. There's obvious consensus to support here but I'm wary of closing an RFC on a new guideline with such low participation. I'll put it up on CENT. -- asilvering (talk) 19:34, 17 May 2025 (UTC)[reply]
Support, looks reasonable and sounds like it aligns with existing best practice, though I wonder if it is worth adding an explicit exception to confirm that the degree symbol ° should be kept for the normal scientific uses (temperature, arc measurement, etc), rather than using {{sup|o}}. The section about music notation using the two approaches interchangeably confuses things a bit. Andrew Gray (talk) 20:47, 17 May 2025 (UTC)[reply]
No one objected to remove the degree symbol from the template or music guidelines, so I did so and converted articles using the removed parameter. -- Beland (talk) 18:29, 26 May 2025 (UTC)[reply]
Although the degree symbol was historically derived from a masculine ordinal indicator, in modern usage it is not a superscript letter o, either visually or semantically, and it would be quite wrong to use <sup>o</sup> for degrees. I'm not sure why ° would be preferred to a character that is in ISO-8859-1, however. Rosbif73 (talk) 13:57, 26 May 2025 (UTC)[reply]
If the guidelines in MOS for degree signs never change, the recommending the template is not necessary and ° should be preferred. However, if most articles use the template and the guidelines change, then a change to {{degree}} automatically brings those articles into compliance with the new guidelines. I don't understand the last sentence, since the value of ° is the 8859-1 degree sign. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:18, 26 May 2025 (UTC)[reply]
No articles use ° - all instances of that have been converted to U+00B0°DEGREE SIGN and database dumps are scanned for new instances every two weeks. It would save some work if we didn't encourage people to usethe HTML entity; it's easy enough to add from a phone keyboard or the desktop special characters pull-down. -- Beland (talk) 17:43, 26 May 2025 (UTC)[reply]
If people need a way to enter special characters without touching their mouse, I would recommend {{subst:degree}} for this one. -- Beland (talk) 18:45, 27 May 2025 (UTC)[reply]
I also agree that the degree symbol should be an exception, as the intended Unicode symbol is semantically different from a superscript o. I agree with Beland's change to the music template to standardize things there. Chaotic Enby (talk · contribs) 18:52, 26 May 2025 (UTC)[reply]
Yes, it's time to just implement it. The things people are discussing below were just suggestions by the closer, not part of the consensus; the key point is that the articles should not be left in mainspace, and even the gentle suggestion by the closer (which was in no way part of the close or consensus, and is in no way binding the way the requirement to remove them from mainspace is) has been met, since more than enough time has passed for people to review any articles that they believe were salvageable. Further steps forward can be determined after that part is implemented, but constantly re-litigating a settled RFC is inappropriate. --Aquillion (talk) 18:26, 19 May 2025 (UTC)[reply]
The closing statement by @HJ Mitchell says, in part:
"However, I would urge the proposers not to charge headlong into the draftification process without further thought. A lot of people are uncomfortable with the large number of articles—a list of 1200 people from different eras and different nations is very difficult for humans to parse and I would urge the proponents to break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles. I would also urge care to ensure that the only articles draftified are those which clearly meet the criteria outlined, even if that takes longer or even considerably longer—we won't fix mass editing without due care by mass editing without due care. There is merit in the idea of a templated warning being applied to the articles before draftification takes place and in a dedicated maintenance category to give interested editors a chance to review. To that I would add a suggestion to check for any articles that exist in other language versions of Wikipedia."
What's your plan for breaking down the lists, avoiding more "mass editing [including draftifying] without due care", and adding warning templates in advance? WhatamIdoing (talk) 21:33, 26 April 2025 (UTC)[reply]
Did you break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles? Or is it your idea that this part of the closing summary has magically expired because it wasn't done by your WP:DEADLINE? WhatamIdoing (talk) 22:34, 10 May 2025 (UTC)[reply]
I'm not sure what you mean, I ask as the quote WAID posted explicitly states it. Could you link to which criteria were requested? CMD (talk) 16:47, 11 May 2025 (UTC)[reply]
The closing summary gives them as examples to be requested by editors who wish to evaluate subsets. Are there editors who wish to evaluate subsets, and have they requested these? CMD (talk) 16:59, 11 May 2025 (UTC)[reply]
Firstly, why? Secondly, the discussion that was closed with the summary quoted above, this discussion, and probably other discussions in between the two.
If that is not enough for you, please take this as formal request to break down the list into smaller lists by era and nationality. Thryduulf (talk) 17:16, 11 May 2025 (UTC)[reply]
Because that's what the close is looking for in quite plain language? It's a quite late request, but if you genuinely want to look through them I'll give you a couple. CMD (talk) 17:19, 11 May 2025 (UTC)[reply]
I really don't understand why this is like pulling teeth? Yes, this is a genuine request to do what has been requested multiple times by multiple people in multiple discussions. Thryduulf (talk) 01:42, 12 May 2025 (UTC)[reply]
It is very hard to take that last claim seriously as you refuse to provide any links. Anyway, here are some to start you off. CMD (talk) 02:12, 12 May 2025 (UTC)[reply]
Thank you, finally, for the lists but I don't understand why you need explicit links to the discussion we are currently having and a link to the original being referenced many times. The Australian list alone has 170 entries (which is still really too large for managability, hence the requests for nationality and era), so it's going to take a long while to do a Propper search on just them (and I'm just about to go to bed). Please be patient and remember that this could have started over a year ago now. Thryduulf (talk) 02:19, 12 May 2025 (UTC)[reply]
I don't need links to the current discussion or the original discussion. I was asking for links to what the close asked for, for people to request specific divisions. If they didn't happen then please stop insisting they did. If the request were not made, that has nothing to do with me. I was barely involved in the prior discussion. CMD (talk) 02:35, 12 May 2025 (UTC)[reply]
The "finally" is quite a particularly perplexing comment, these lists were produced less than a day after the first request. CMD (talk) 02:37, 12 May 2025 (UTC)[reply]
That was explicitly framed as a suggestion by the closer, not as part of the consensus. It has no weight or force whatsoever. --Aquillion (talk) 18:27, 19 May 2025 (UTC)[reply]
Chamindu Wickramasinghe – Sri Lanka – sources have been added, needs to be removed from the list. The draft note has already been removed from this article (in June 2024)
So? It is not up to those who don't think there is a need to delete/draftify the articles en-mass to work out which ones those who do believe that is a desirable course of action are referring to, let alone without the latter group having done what was explicitly noted as a prerequisite to deletion/draftification. Thryduulf (talk) 16:33, 11 May 2025 (UTC)[reply]
Jay, I agree: You've had more than a year at this point to follow the directions in the closing summary and break it down into smaller lists by nationality, era, or any other criteria requested by editors who wish to evaluate subsets of articles. Time enough? WhatamIdoing (talk) 16:49, 11 May 2025 (UTC)[reply]
Yes, I would support draftify-ing those articles sooner rather than later, especially before Wikipedia reaches the 7 million articles mark. Some1 (talk) 14:04, 11 May 2025 (UTC)[reply]
Can I point out that there's a talk page for this at Wikipedia talk:Lugstubs 2 list. I've already gone through a bunch of these articles, mainly New Zealanders, to suggest those that might be kept, those are, in my view, a merge – which retains the page history and is a valid WP:ATD – and those that might be deleted. Some have been improved. I've not gotten to all of them by any means. But that's somewhere that anyone about to make any of these a draft needs to have a look at first please. I've not done any work on these lists for a while as it's so time consuming and I'm not sure when I'll get a chance to look again, but a clear procedure for reviewing these was put in place. Ta Blue Square Thing (talk) 10:55, 12 May 2025 (UTC)[reply]
e2a: a quick look through the British and New Zealand ones suggests all are either keeps or redirects – I note a number that have had suitable sourcing added and some with suitable levels of detail, other than the ones that I'd worked through. I imagine the same is true of the Australians as well – an ATD will be available on almost every case if they haven't has sourcing added. I'm not entirely sure that the original list is really that valid from the POV of these subsets if I'm honest. It's certainly not a job that I would like to automate based on the list as it exists Blue Square Thing (talk) 11:07, 12 May 2025 (UTC)[reply]
I'm working through the New Zealanders – 70+ done. There's an interim list at User:Blue Square Thing/sandbox3#NZ. Once I'm done (a few weeks I imagine – I have 22 left) I'll push that list to the same talk page as above
At Wikipedia talk:WikiProject Cricket The-Pope has broken down the Australian list into state teams, which is really helpful. But these will take a while to get through
The instructions on the {{Special draft pending}} tag say that when sources have been added, the tag shouldn't be removed (why?), but instead the article should be listed at Wikipedia talk:Lugstubs 2 list for review.
However, so far, over the course of the last year, almost 200 articles have been individually reviewed and listed there (either with a recommendation to redirect or with sources), and this work has been ignored. The editor who wrote these instructions is no longer editing.
Should we:
Tell people to just remove the tags when they redirect or add sources? (This would require re-generating the list.)
Find some volunteers who will actually follow up on the chosen process? (I believe the process was boldly made up by one editor; I've seen no evidence of discussion, much less consensus.)
I really don't know what is the most effective way to do this. I can see the benefit to removing them as someone works on articles, but it involves removing them from two places. There certainly seems to be evidence that articles have been worked on without notes left on the talk page, so I'm not sure it's reliable to ask people to remove from two places.
It makes sense to redirect as we go though. Ultimately this is a human task – unless there's a really clever way to do it, I don't think it can be automated due to the need to redirect a huge number of the articles – in the original discussion I estimated 75% were redirects
On that subject, there was some discussion about the best way to do the draft/redirect process. MY gut feeling is that it's redundant to send articles to draft, have someone bring the article back to mainspace, and then redirect the article – the draft isn't deleted automatically and that creates more overheads. I think. A straight redirect is better I think
But it's difficult to do this when the tags are still on the articles, I agree. I would have started to do that last March, but for the process that was put in place... It will, fwiw, take some time Blue Square Thing (talk) 19:17, 13 May 2025 (UTC)[reply]
If people pulled the template off the page when redirecting/improving, then we should be able to combine (e.g., with grep) the original list against the list of pages that transclude the template, to find which ones are still in need of work/eligible for being moved to the Draft: space. WhatamIdoing (talk) 21:25, 13 May 2025 (UTC)[reply]
Changing the template message just involves going to Template:Special draft pending and clicking the [Edit] button. However, I don't know how the opponents of these articles would feel about that. What if somebody adds a source and removes the tag, but they think the added source isn't good enough to justify keeping the article in the mainspace? They might prefer more bureaucracy. WhatamIdoing (talk) 18:11, 14 May 2025 (UTC)[reply]
I've now managed to work through all the British and New Zealand articles. Of the 50 British ones, seven need to be removed from the list as sources have been added, and the other 43 are probably redirects – although a number of them (at least 12) have significant possibilities (i.e. I know that if I could expend the time on them that they'd almost certainly have sources added). Of the 89 New Zealanders, one needs to be drafted, 40 have had sources added, and 48 can be redirected (with strong possibilities for 10 or so at least). The detail is at Wikipedia talk:Lugstubs 2 list. I'm about to start on the Zimbabweans.
Perhaps someone could let me know what they'd like me to do next? There's a list of 1,106. A great many of them will be redirects or drafts, but at the minute the note added to the top of each page stops me doing anything very much to those articles – one Charles Chapman (cricketer, born 1860) (British but not appearing on the British list for some reason) has been merged with Charles Chapman (rugby union) as they were the same person, but the article still appears on the original list. I have no idea what an automated attempt at this process would do to an article like that, but I can't imagine that any automated process will work, I can't remove the list, I don't think I'm allowed to redirect them, and I'm pretty certain I'm not supposed to remove them from the list.
Speaking only for myself, I'm annoyed by the fact that we had a lengthy discussion that came to a consensus to do something, and then didn't do it, and that we've had articles that have been allegedly pending being moved into draft space for years. I don't care much more about the procedure than that we get out of that state. * Pppery *it has begun...18:44, 18 May 2025 (UTC)[reply]
So if BST removes the tags for the ones they think shouldn't be draftified, and pulls them off the list, then you're okay with that? WhatamIdoing (talk) 18:46, 18 May 2025 (UTC)[reply]
Well, I tried to support it being done if someone wanted to do it. To be honest, I don't completely understand the situation, but if it helps I think the ones that @Blue Square Thing describes as probably redirects should probably be redirected? Or if the draft tags don't allow that, drafted. Enough time has gone by in my opinion if they're still unsourced -- don't know whether there was an already-fixed timeline?
If I'm understanding this correctly, I think we should just let people go through and draftify/redirect them all (except the sourced ones), removing the tags. If there are some that sources could be found for, well, new pages can always be created later with the sources. Mrfoogles (talk) 18:57, 18 May 2025 (UTC)[reply]
None of these are unsourced articles. The ones on this list were chosen because they:
were created by an editor who fell out of favor with the community, and
are sourced (only) to specific websites.
The tag was boldly created by an editor and suggests a new/unprecedented process that, e.g., claims that redirecting an article to a suitable list would still leave that redirect subject to draftification and eventual deletion. I suspect that his intention was to personally review any article that others thought was eligible to be left in the mainspace. However, he has since stopped editing, so we can't ask him how he thought this would work out in practice. WhatamIdoing (talk) 19:23, 18 May 2025 (UTC)[reply]
Part of the problem is that you have to know where to redirect them to. Which is slightly tricky. Sometimes lists don't exist, which means we draft; sometimes you need to choose a list from options, which is OK but tricky. I can start to do that, but it takes time and is slightly difficult as it tends to rely on having accessed to a paywalled source. But it needs doing – the current situation is starting to get silly and I share the exasperation of Pppery because I could already have dealt with a couple of hundred of these
At least four have already been sent to draft and then the draft deleted. I thought the process we have here guaranteed that they wouldn't be deleted from draft space for five years? (from memory) That doesn't appear to be happening – for whatever reason Blue Square Thing (talk) 19:29, 18 May 2025 (UTC)[reply]
They were probably just draftified independently of the RfC without putting the tag on them.What about just draftifying everything you (or others) haven't already redirected or otherwise exempted via introducing IRS SIGCOV, then you can get started on deciding which other pages to redirect/exempt from within draft space? JoelleJay (talk) 16:15, 19 May 2025 (UTC)[reply]
I was/am interested in working on this myself – I didn’t mean to imply with my comment that it’s somebody else’s problem. 3df (talk) 21:08, 18 May 2025 (UTC)[reply]
Any that have not already been individually assessed as probably meeting notability criteria (or as being redirectable) should just be draftified. The whole point of their getting privileged draftification treatment was so that interested editors had 10x time to trawl through these articles after they were removed from mainspace: I find that there is a rough consensus in favour of the proposal, and a stronger consensus that they should not be left in mainspace. They don't get to hang around indefinitely in mainspace just because the same editors who staunchly opposed the consensus neglected to show any interest in the non-mandatory close recommendation of making more discretized lists (which are supposed to make it easier for the post-draftified articles to be parsed, not as a way for one editor to adopt a set beforehand and delay its articles' draftification by claiming they "need more time" to run through them individually). We most definitely do not need a second RfC to ratify the first one, and a year is more than enough for any editors who cared to ensure draftification is only applied to eligible articles. The rate-limiting step here cannot be the inaction of the same editors opposing draftification, that would completely defeat the consensus to remove these from mainspace. JoelleJay (talk) 20:25, 18 May 2025 (UTC)[reply]
The rate-limiting step appears to be the inaction of the editors supporting draftification.
The immediate question here is, for the (small?) subset that has "already been individually assessed as probably meeting notability criteria (or as being redirectable)", how do we stop them from wrongly getting dumped in the Draft: namespace?
This would be a stupid process:
BilledMammal puts a page on his list of pages to dump in the Draft: namespace.
Alice reviews one. She decides that it does not meet the GNG and redirects it to a List of Olympic athletes from Ruritania.
Bob draftifies everything on the original list, including Alice's new redirect.
Chris un-draftifies the redirect, because it's stupid to have a redirect in the Draft: space when Alice has already determined that this athlete doesn't appear to qualify for a separate, stand-alone article and has already redirected it.
No. I am saying any that are already redirected or clearly ineligible can be removed from the list, any that are not are draftified NOW by an admin, per the consensus that these stubs should not remain in mainspace. The accidental draftification of false-positives is of minuscule concern: editors have 5 more years to go through them. JoelleJay (talk) 23:03, 19 May 2025 (UTC)[reply]
Why the rush? As @HJ Mitchell pointed out in the close, it is more important to get it right than to do it quickly. There are currently multiple people actively working out what doing it right means. Thryduulf (talk) 23:38, 19 May 2025 (UTC)[reply]
I wonder whether the auto-deletion process in the Draft: space has been modified to accommodate this five-year timespan. I suspect that the answer is "no". WhatamIdoing (talk) 00:59, 20 May 2025 (UTC)[reply]
One year is not "doing it quickly". If the editors who believed certain articles ought to be exempted just never bothered to address those articles, then that's too bad for them: there was a consensus to remove the articles from mainspace and into a protected draftspace where they could be worked on, and a stronger consensus not to leave them around in mainspace for some indefinite length of time while some editors maybe work on some selection of them. You and WAID contributed like 50 comments in the RfC unsuccessfully trying to kill the proposal, now you're trying to do the same thing to its implementation. At some point this just becomes disruptive. JoelleJay (talk) 03:29, 20 May 2025 (UTC)[reply]
Please read this entire discussion where all your complaints have been fully addressed and/or rebutted multiple times. I'm not trying to kill it's implementation, I'm trying to ensure that the damage to the project is minimised by ensuring that the due care the closer found consensus for is actually applied. If that takes longer than you want, then I'm sorry but the community wanted due care rather than haste. Thryduulf (talk) 03:41, 20 May 2025 (UTC)[reply]
Yet the consensus was that it is more damaging to the project that these articles remain in mainspace, and it certainly did not include your definition of "due care". JoelleJay (talk) 03:53, 20 May 2025 (UTC)[reply]
Instead of talking about hypothetical "editors who believed certain articles ought to be exempted just never bothered to address those articles, then that's too bad for them", how about we talk about "the editors who did address those articles, and who are addressing those articles, and who have been addressing those articles for over a year now, but who have been told that they're not allowed to take the tag off or remove the articles from the list"?
This process has been badly designed, with incomplete documentation, instructions that contradict normal practices, no tools to separate these drafts with their RFC-mandated five-year time period in the Draft: space from the ordinary six-month G13 process, and an implicit dependence on an editor who is not editing any longer. One goal (i.e., boldly redirect articles that editors believe won't qualify) is simple and straightforward under normal circumstances, but it's being stymied by editors who are trying to follow the directions they've been handed, because the tag says nobody's allowed to remove it.
If we want to move forward on this, then we need to figure out things like how (e.g.,) Liz and Explicit identify Draft: pages that are eligible for G13 deletion, and how they could not have their systems screwed up by these pages, which aren't eligible for five years.
We need to get this right. I've no sympathy for people who ignored this for the last year and a half, but now that we've been reminded about it, they think it's an emergency. People have been posting on the designated talk page for well over a year, and their questions and comments have been ignored by you and everyone else who just wants these pages gone. If you don't choose to help, then that's fine, but the result is that sorting out this process is going to take longer. WhatamIdoing (talk) 05:04, 20 May 2025 (UTC)[reply]
Hang on, we were explicitly told not to remove the hatnote and not to redirect. That was supposed to be handled sensibly – multiple reassurances were given at the original RfC and since. If someone were to draft all those with the hatnote remaining, you'd send articles which obviously meet the GNG to draft – there are hundreds that either were in the original process or that need to removed from the list – almost 50% of the New Zealanders for example. That would, in my view, be likely to be used as an argument against any future mass-draftification of articles. Any support that I was able to give to the original RfC was based entirely on the assurances received that redirects would be handled sensibly. I imagine I would feel I had been lied to if they were simply all drafted without any consideration for the process that I've been working my arse off on for periods of the last year Blue Square Thing (talk) 08:48, 20 May 2025 (UTC)[reply]
The proposal says
If this proposal is successful: All articles on the list will be draftified, subject to the provisions below: [...]
Any draft (whether in draftspace, userspace, or WikiProject space) can be returned to mainspace when it contains sources that plausibly meet WP:GNG[d]
Editors may return drafts to mainspace for the sole purpose of redirecting/merging them to an appropriate article, if they believe that doing so is in the best interest of the encyclopedia[e]
}}I imagine any resistance to removing hatnotes or redirecting would be due to concerns the article would just be recreated from the redirect without undergoing scrutiny for GNG and without having the hatnote returned. Maybe it would be helpful to have a hidden category for redirects from this list and/or a talkpage banner noting they were originally part of LUGSTUBS2 on them as well as on any pages that are returned to mainspace as GNG-compliant. Anyway, I don't see why we can't just draftify the pages that haven't been worked on by you guys (or that you have found non-notable), while separately addressing redirection/removing hatnotes for those that remain. JoelleJay (talk) 17:45, 20 May 2025 (UTC)[reply]
A talk page banner might be more helpful – cats can get deleted easily.
In terms of what to draft and when, it would be more efficient to redirect first where a redirection is possible. In some subsets, this is nearly all articles; in other subsets it will be fewer. It would be possible to work fairly quickly through those I think – over the last day or so I've reviewed all 170 articles on the Australian list. 147 of those can be redirected in the first instance (a number having strong possibilities); 23 need to be kept. None need to be drafted. Of the 89 New Zealanders, one needs to go to draft. The others are all redirects or to be removed from the list and kept. The same won't be true of Pakistanis, for example, where there are a lot fewer lists for redirection.
I'm not entirely sure how it would be possible to identify those that have been worked on btw. I've come across some today which other people worked up but haven't left a note anywhere about Blue Square Thing (talk) 20:09, 20 May 2025 (UTC)[reply]
The practical reason why we can't just draftify the pages that haven't been worked on by you guys (or that you have found non-notable) is because you don't actually know which ones haven't been worked on.
The ones that can be redirected can be put in a new list, removed from the original list, and a banner put on their talk pages. The ones that BST et al have determined should be kept can likewise be put in another list and a banner put on their talk pages. The ones that others have since worked on but which have not been actively endorsed as demonstrably meeting SPORTCRIT can be moved to draft alongside all the other eligible pages for the individualized attention that the community decided should take place in draftspace. JoelleJay (talk) 20:50, 20 May 2025 (UTC)[reply]
That makes sense. The banners are a good idea – who will create them? Can I check:
a) that we're talking about dealing with the list at WP:Lugstubs 2 list (1,106) – these are the ones that were tagged with the hatnote? This is not the same list as the one at WP:LUGSTUBS2] (1,182). I can't remember why they're different – I think everyone on the first list is on the second one. From memory I think the query was re-run and some came off it. They had probably been improved to the extent that they dropped off the list
b) where would you like me to create the lists? Wikipedia talk:Lugstubs 2 list is a bit of a mess because I've stuck so much stuff on there and the lists that are on there are messy as well
c) I think the original idea was to re-run the query again first to remove the ones that would have fallen off the list. I wouldn't have a clue how to do that. Is that something someone could do? It might save a bit of time and effort
Once we have the banners made and an idea about where to create the lists, we're good to start moving on this I think. Is it worth discussing a formal timeframe? Blue Square Thing (talk) 07:55, 21 May 2025 (UTC)[reply]
Whichever is the most recent agreed-upon list should be used. We can run a new query on it, then look over any pages that no longer qualify through the query to make sure their disqualification is legitimate. I think the three new lists (redirectable, likely notable, all remaining eligible stubs) can just be put in a new talk page section. I don't know anything about making banners or running quarry queries; perhaps @Pppery has background or knows editors who do? JoelleJay (talk) 16:33, 21 May 2025 (UTC)[reply]
I have some familiarity with Quarry queries, but it's not clear to me what is being asked for right now. Or, one you have a clear request, you can ask at WP:RAQ (although that's largely a single-person operation too). * Pppery *it has begun...16:46, 21 May 2025 (UTC)[reply]
I think the intent is to just run the same query as before on the current list to see if any other names now need to be removed? JoelleJay (talk) 17:07, 21 May 2025 (UTC)[reply]
I think that would be best. It would also be best to actually deal with the ones that have been sorted out before re-running the list. Do you have a link to the query?
I'm 99% certain that the list at WP:Lugstubs 2 list is the list that had the template added to it. I know of at least two articles where editors have removed the template, but that list hasn't been edited since BilledMammal put it there, so it should be reliable Blue Square Thing (talk) 17:49, 21 May 2025 (UTC)[reply]
One of the inefficiencies in Wikipedia talk:Lugstubs 2 list#2025 procedure is that, for redirecting non-notable subjects, I think we need to remove the template from the page and the name from the list. But if we are reasonably certain that everything on the list got tagged with the template, I'd love to simplify this to "anything still transcluding the template is getting moved" (after a reasonable but short pause to get those known-non-notable subjects redirected). WhatamIdoing (talk) 17:58, 21 May 2025 (UTC)[reply]
I've only found two without the template, and I've looked at getting on to 750 of the articles over the last week. If at all possible it would be better to use those using the template (the other two have easily good enough sourcing I think – Alexander Cracroft Wilson and Chamindu Wickramasinghe) and then conduct a check with the quarry query afterwards or run through and check them some other way. There doesn't seem to have been any mucking around with the list other than the three (not four) which were drafted early and have since been moved back to mainspace e2a: a look at the number of articles with the template, shows that there are six more somewhere where it's been removed. I'll sort out which at some point by comparing the lists Blue Square Thing (talk) 18:07, 21 May 2025 (UTC)[reply]
23 June. That goes everyone a month. If it goes a bit further than that then fine, but a deadline in this case is probabyla good diea to stop me from prevaricating Blue Square Thing (talk) 19:02, 21 May 2025 (UTC)[reply]
That sounds good to me. I've updated the directions to state that date. I've also removed instructions to edit the list itself. We can use the templates themselves to track it. (I assume nobody's spammed the template into other articles; if my assumption is invalid, then we'll have to check the list.) WhatamIdoing (talk) 21:00, 22 May 2025 (UTC)[reply]
I actually managed to do some myself yesterday morning (the Auckland redirects), but had a ridiculous day at work so wasn't able to leave a note here. It sees to work, although it's slightly trickier that I thought – need to remove the class rating from the talk page and the circular redirect from the list as well. I also added R with possibilities to the ones I did as they're ones that I think have that. Oh, and in some cases we can redirect to a section...
It would be better if we could re-run the querry that BilledMammal used in the fist instance as there are 400+ articles I've not managed to check – the Sri Lankans and Indians. But if we can't do that, I think this is the best option Blue Square Thing (talk) 04:26, 23 May 2025 (UTC)[reply]
AIUI the WikiProject banner figures out redirects automatically, so you can ignore those. We should be able to get a bot or an AWB run to handle the circular redirects. (Surely we have a bot that can do this?) WhatamIdoing (talk) 05:06, 23 May 2025 (UTC)[reply]
I've started more work on these – it's just the class on the redirect talk page that I'm slightly worried about.
The special draft pending template still says to remove people from the list. Do we actually want to do that or does the template need changing to remove that? Blue Square Thing (talk) 17:04, 24 May 2025 (UTC)[reply]
@Blue Square Thing, ignore the class on the redirect's talk page. A while ago, we updated Module:WikiProject banner to auto-detect redirects and ignore whatever the banner incorrectly claims the class is. Eventually, a bot will remove it (but it's basically a WP:COSMETICBOT edit, so it won't happen quickly).
Here's a potentially useful option. Many of these articles have a see also section with a link to a list. One potential solution is that if the article still meets the criteria (which will need to rechecked obvs) and if it contains such a link, it gets redirected to the list that's linked; if multiple lists are linked someone tells me and I sort it out (this is rare fwiw)
Fwiw I rather think this has been a lot more complex than everyone expected it would be. I did start working on this in March 2024, after the list was finalised. The original rfc included multiple assurances that redirects would be dealt with sensibly. I think we can do that, but I'm waiting to be told how to do it Blue Square Thing (talk) 04:21, 19 May 2025 (UTC)[reply]
Agree that if there is a clear and obvious redirect target then redirecting there is far more appropriate than draftspace for the article, as per WP:ATD. Joseph2302 (talk) 19:12, 19 May 2025 (UTC)[reply]
Yes, it could be. It would mean that the draft article would stay as well however, which is inefficient from a storage post of view. It would involve double the work involved, as rather than simply redirecting the articles I'd have to move them back and then redirect them. Blue Square Thing (talk) 08:33, 20 May 2025 (UTC)[reply]
But wouldn't you have to do such move for any articles you end up working on in draftspace anyway? Moving to mainspace and then redirecting is just one more trivial step than what was already expected to happen if this RfC got implemented. JoelleJay (talk) 17:51, 20 May 2025 (UTC)[reply]
Given the numbers of articles that will end up as redirects – as above, of the 170 Australians, 23 are keepers right now and the other 147 are all redirects; not a single draft – it would be a lot more efficient for me to just have to do the redirects. I have them sorted in teams anyway, so the redirection notice will essentially be the same. Given that I've ploughed through all of those over the last 28 hours, I don't see why I couldn't manage the redirection process over a similar sort of timeframe for those 170. Having to bring back from draft first, more than doubles the time it would take – I'd have to do all the drafts first to keep the note I'd need to place in the reason box and then go through and do all the redirects by team afterwards. That's really adding to the work – all of it by hand. From a technical efficiency perspective, it must also be better to not have absolutely unnecessary drafts kicking around for five years either. All I need is for someone to work out exactly what process to go through and to have a bunch of people agree it. I'm not sure how long it would take to do work through the full 1,100 and come up with a list to draft, but it wouldn't be that long so long as I'm in the country and able to work at it Blue Square Thing (talk) 20:15, 20 May 2025 (UTC)[reply]
I don't see any reason not to redirect most of, if not all of the remaining articles as well, unless I am missing something here? Let'srun (talk) 23:54, 24 May 2025 (UTC)[reply]
We don't always have lists to redirect to – so, for Afghan cricketers, for example, I don't believe there's a suitable list. I've managed to redirect the New Zealanders who need redirecting and have started to remove tags from those I think we should keep, but it's a slightly complex process to do by hand. It will take a little time to get it done right Blue Square Thing (talk) 14:04, 25 May 2025 (UTC)[reply]
This process is now under way. I'm focussing on removing tags and redirecting. It takes a long time and all has to be done by hand. If anyone can figure out a way to automate any or all of the process it would really help. In particular, I've stopped doing anything to the talk pages – it's just taking so long. Thanks to all the people who have been cleaning them up, but if there were an automated way to do this it would really, really help matters. I'm aware that I'm leaving work for other people to do in the short term. I will try and return to the talk pages if I can do, but sorting out the articles seems like a sensible priority in the relatively little time I'll have to do this
I think the fact that redirecting was not actually easy was the entire reason why draftification was chosen in the first place. Frankly, I favoured just straight deleting them and if there's a WP:LUGSTUBS3 that will get my !vote. FOARP (talk) 11:01, 2 June 2025 (UTC)[reply]
The assurance that redirection would be handled automatically was the only reason I was able to give any support to the original proposal. Unfortunately BilledMammal is away for at least most of the rest of this year otherwise that might have happened. I appreciate that people wanted to punish Lugnuts by removed their articles entirely, but there are clear ATDs in many cases and redirection would have almost certainly been the result of AfD discussions in the cases where there are realistic ATDs. So I'll keep going. If you could look through the 200+ Indian articles and see if any have had loads of sources added it'd help massively. Thanks Blue Square Thing (talk) 11:32, 2 June 2025 (UTC)[reply]
The reason why I prefer straight deleting is because recreation of the content worth keeping (which is minimal) is way easier and cleaner. Redirects are cheap... to create... FOARP (talk) 14:18, 2 June 2025 (UTC)[reply]
To be clear, are we redirecting the ones with no substantial edits, or draftifying them? Taking the first on the Indian list, C. R. Mohite, since they were an Umpire what is the redirect target supposed to be? List of Baroda cricketers? But then is it even verified that he played for Baroda rather than just coming from there? Draftify looks like a way easier option.
BTW to me this was never about "punishing" Lugnuts. This was about saving editor time vs a massive time sink with minimal value-creation that was negligently dumped on us. FOARP (talk) 14:28, 2 June 2025 (UTC)[reply]
I've redirect the first ten in the list, none of which had any source but ESPNCricinfo and so were straight-forward NSPORTS fails. FOARP (talk) 14:49, 2 June 2025 (UTC)[reply]
Thanks for doing what you're doing there. I really appreciate anything that anyone else does to help this process. The key is to find the small number of articles where sources have already been added and that need to be removed. Then redirecting.
Yes, redirect to wherever is most obvious – any that cause significant problems shout and I can check on CricketArchive, which is paywalled unless you know the way around it – so Mohite played 25 matches for Baroda, but the redirect you have is just as good.
Redirects, for me, have other advantages. They make re-creation of the article as a duplicate more difficult and retain cross-wiki links (Mohite is linked from multiple pages, for example). Drafting removes those. Eventually we might get notes added to articles – like on List of Otago representative cricketers for example – which summarise careers and so on. The problem, of course, is that that takes time. More clarity over the process from the get go and a set of lists organised in some way are all things that would make that easier if we do this again. Blue Square Thing (talk) 14:55, 2 June 2025 (UTC)[reply]
Honestly, we should just delete these articles and save ourselves the time, and then use the time save to create real articles. But if redirecting is how we're resolving the issue right in front of us today then that's how we're resolving it. I'll do the others in the India list after work. FOARP (talk) 15:21, 2 June 2025 (UTC)[reply]
None of the first ten anyway. For all the protestations that time was needed, in reality no-one was doing anything nor was there any obvious signs of the intent to do anything. Even if it wasn't intended, the effect of this was simply to suspend the decision for a year with no obvious improvement. FOARP (talk) 08:52, 3 June 2025 (UTC)[reply]
I think having them sorted into lists of countries **really** helps. Knowing what sort of sources are available for each country does as well. It would be better to present future lists by country (preferably by team); I think it's much more likely that the process gets done better and quicker if we can do that. Shorter lists will help as well – give me 50 New Zealanders and I can tell you what needs to happen to them within a few weeks. BilledMammal largely not being here to shepherd the process obviously hasn't helped fwiw Blue Square Thing (talk) 10:59, 3 June 2025 (UTC)[reply]
CricketArchive, which is paywalled unless you know the way around itIs there an easier way than inspect>sources>refresh>pause load? That's how I've been doing it the last few years. JoelleJay (talk) 23:06, 2 June 2025 (UTC)[reply]
Hitting Esc quick enough also works I believe. Or if you can still find it, I have Opera 12 installed - the last update before they moved the browser to Chromium I think. For some reason it ignores the redirects to the paywall. Obviously it's years out of date now, but it's the only thing I use it for and it seems to work Blue Square Thing (talk) 07:14, 3 June 2025 (UTC)[reply]
Picking a random name Arnell Horton (Arnell Stanley Horton), there is more information available about him, but even what was in the stub has not been copied to the notes field on the redirect target. Better to do this slower without losing the information. All the best: RichFarmbrough20:18, 2 June 2025 (UTC).[reply]
I appreciate that we're, at least temporarily, losing information, but there's just so much to do. I'm going to copy the lists of names on to the talk pages of the teams the redirects have been done to so that we know which ones need to be gone back to. I have no idea how long it would take to copy across as we worked through, but I might have two or three half-days available until the deadline and that'll be about it Blue Square Thing (talk) 07:14, 3 June 2025 (UTC)[reply]
I took a look at the Zimbabwe list. Dobbo Townshend is clearly notable. I've redirected a couple more. But most of the other ones don't have clear redirect targets and should probably be PRODded. SportingFlyerT·C00:07, 4 June 2025 (UTC)[reply]
The whole point of LUGSTUBS was to draftify these articles in a protected draftspace rather than going through the PROD/AfD process for each individually. JoelleJay (talk) 16:05, 4 June 2025 (UTC)[reply]
Update: All but the British, Indians, and Sri Lankans are just about done. I know what's probably happening to the British articles, so my calculation is that of the 805 articles that have been dealt with (excluding Indians and Sri Lankans), 695 have been redirected to a list of some kind or developed and removed from the list, I've PRODed 7, which leaves 104 to send to draft. It's about 13.7% being drafted or PRODed. I've not calculated how many have been removed from the list after having been improved or as false positives (a handful) – gut feeling says around 75–100, maybe a little less. Sri Lankan lists are scarce, so that will probably increase the percentage of drafts. I'm not sure about the Indian lists Blue Square Thing (talk) 08:41, 4 June 2025 (UTC)[reply]
Indians are all done 65%ish redirect or keep the article fwiw, but I didn't look too hard for places to redirect to. Just the British and Sri Lankans to do now Blue Square Thing (talk) 20:46, 6 June 2025 (UTC)[reply]
Sri Lankans all done – just a 22% redirect rate. I think we now know how to deal with these sorts of articles more effectively if we wanted to do this again Blue Square Thing (talk) 07:55, 7 June 2025 (UTC)[reply]
Update: I have five more articles to work through of British cricketers. All five will either be redirects or ones that can be improved – I'm vaguely hoping one might make DYK actually... I should be done with these by the middle of next week. That should leave around 287 to send to draft Blue Square Thing (talk) 11:47, 11 June 2025 (UTC)[reply]
Final update: I'm done working through the lists. Of the 1,211 which were originally suggested for tagging, either at WP:LUGSTUBS or in the initial identification process, 8 have been PRODed and deleted and 287 remain on the list of articles with tags. That's about 25%. Oddly it's almost exactly what I predicated during LUGSTUBS, but that's more by luck than anything.
The majority of the articles which remain tagged are south Asians, with a few South Africans and the odd other article. That's essentially because we have fewer lists to redirect to. I guess someone should double check them all before sending them to draft – I presume there will be an automated process for it.
If we do this again can I suggest:
smaller, more targeted lists. It's much easier to do this when you're looking at 50 New Zealanders or 100 Australians. 200 Indians is just about manageable, because so many will be redirects. It will make the process so much easier if they're broken down by country at least. By team is even better. Sorting by surname, where possible, is also so much easier;
a recognition that some sets of articles will take longer to process because there is more of a chance of sources existing. New Zealanders, Britons, and Australians in particular. These, particularly the first two, are where most of the articles that have been developed are from;
the ability to redirect and remove tags as we go – this has been the only thing that has made this process workable and was decided upon in May 2025. We could have moved things so much quicker;
ideally the process could be made more efficient. Do articles that are going to be redirected need to be considered for draft? Yes, they need to be checked and any which are obvious keeps weeded out, but when redirects exist we should probably do that up front. A two stage process where a list is produced, checked and obvious redirects and keeps noted, and the others tagged for draft, perhaps, to allow double checking etc... would be quicker I think – for example, as IP editor dropped a set of 36 names on my talk page last week, all British. I've already identified that 15 or so are obvious keeps with easy sources to add, 7 or 8 need more investigation, and the others could probably be redirected straight away. That's much more effective;
gut feeling says at least a three month time frame for each set that need to be considered for draft;
a short pause between sets – I need a fortnight break from this and there will times of the year when people are busier or not around.
I think you've done great work. But I think this would have been a lot less time-crunchy for you if your assessments had taken place while these pages were already in the special draftspace and we had some automated way for mass-moving (and talk page-tagging) those you identified as redirectable. The point of LUGSTUBS was to give editors the chance to evaluate and improve these articles outside of mainspace, over an extended draft-life. So in the future I think it would be beneficial for us to talk to the bot people to see if there are better options than someone manually undraftifying and then tagging and redirecting each eligible page. JoelleJay (talk) 16:59, 18 June 2025 (UTC)[reply]
InvadingInvader have you actually read the whole discussion, or is this a drive-by comment? Blue Square Thing has made an effort to check notability of most of these articles and supplied a sensible list of recommendations for them- so blindly saying "draft them all" seems like a drive-by comment to me, as you haven't provided justification that most/all would benefit from this process. Joseph2302 (talk) 15:38, 18 June 2025 (UTC)[reply]
I have PRODded more than a few Lugstubs in the past (admittedly not recently), but I think that a draftification gives a chance and an incentive to actually improve them. Six months should be more than enough time. InvadingInvader (userpage, talk) 16:06, 18 June 2025 (UTC)[reply]
The time limit rather depends on the number of articles suggested. It takes a while to work through. And a stubborness to try to get things done in a way that's moderately "right" (spoiler: it's not; I've almost certainly redirected articles that should have been kept because I didn't have time to check Wisden obituaries, for example). It might be different for other sports. A two-part process where articles are selected and then reviewed before tagging for draft would probably be more effective. The same would apply to PRODs and AfD noms fwiw – if I de-PROD I'll often boldly redirect immediately afterwards if I can't see anything quickly that makes me think the article would survive an AfD without the outcome being to redirect Blue Square Thing (talk) 16:14, 18 June 2025 (UTC)[reply]
draftification gives a chance and an incentive to actually improve them. Six months should be more than enough time. – I can say as one of the users most active in trying to save notable "Lugstubs", draftification does not give any incentive, nor is six months sufficient time to research hundreds or thousands of foreign, pre-internet subjects. Of the 1,000 draftified in Lugstubs1, less than 2% have been restored in two years. At minimum, over a third of those would turn out notable if someone looked for coverage. But thanks to draftification, we don't have anyone doing that. BeanieFan11 (talk) 16:25, 18 June 2025 (UTC)[reply]
They get occasionally improved in mainspace. At least in mainspace editors can see them. In draftspace, the only editors aware are the ones who participated at the LUGSTUBS discussion, almost none of whom seem to have much interest in improving them (going off of only a tiny tiny handful having been improved in draftspace in two years). BeanieFan11 (talk) 16:52, 18 June 2025 (UTC)[reply]
Thanks for the list of recommendations. I agree that the original process was broken, and I'm glad that we got that fixed.
One of the things that has struck me is how many editors have been pushing to hide these m:where articles go to die and demanding that other editors deal with everything right now, but who have not done any of the work themselves. It has not felt (to me) like we're all in this together. It has felt like some editors have set themselves up as wiki-rulers and assigned themselves the job of ordering other people to do things they aren't willing to do themselves.
If I could change one thing in any future versions, it would be that people need to help with the work, at least in some small way, and not just issue demands that somebody else do all the work. Wikipedia is a collaborative project. This has felt more adversarial – like dealing with an unreasonable client, rather than working together. Let's do better next time. WhatamIdoing (talk) 17:17, 18 June 2025 (UTC)[reply]
Chipmunkdavis broke the lists down into nationalities. That was crucial. Without that there's no way I'd have been able to get even close to the stuff I've done. The-Pope broke the Australians down. Again, that was crucial in helping to crack a large set. Those sorts of things are invaluable and it would have been so much more useful to have had this happen right at the beginning. I think BilledMammal did provide some categories, but they seemed to disappear into the ether Blue Square Thing (talk) 19:18, 18 June 2025 (UTC)[reply]
There was strong consensus that these articles not remain in mainspace. It has been a year, the burden was on those wanting to keep them to initiate whatever process they felt necessary to reduce false positives. The "work" was always supposed to be taken on by those editors, otherwise we would not have had a consensus to skip the timesink of individual AfDs for the stubs to get draftified. Creating the special draftspace was a compromise to allow such editors to put in that work over an extended period. The only additional effort needed was rerunning the original stub eligibility script. The process would have been much smoother if, per the proposal and consensus, they had just been draftified in the first place and editors interested in demonstrating standalone worthiness had worked on categorizing and tagging for redirection from within draftspace. JoelleJay (talk) 15:12, 19 June 2025 (UTC)[reply]
I'm not sure that "strong consensus" is really a fair reading of the close. But anyway, it got done. Lets see if we can take less than 18 months next time Blue Square Thing (talk) 17:34, 19 June 2025 (UTC)[reply]
How about just going through normal processes, rather than this which guarantees the loss of many notable subjects and wastes extraordinary amounts of editor time with very little benefit? BeanieFan11 (talk) 17:36, 19 June 2025 (UTC)[reply]
AFD and PROD have practical logistics problems, which I summarize here:
The editors who viscerally dislike the articles don't want to redirect the articles to appropriate lists themselves. (That requires effort, usually – but definitely not always! – entailing reading the first sentence, seeing that it says "for the Foo Team", and replacing the contents with #REDIRECT[[List of players on the Foo Team]], maybe with an {{R to list entry}} tag. Also, it should be somebody else's job, because I shouldn't have to lift a finger to fix a mess created by somebody else.)
The community objected to a single mass AFD nomination, because the correct outcome depends on the individual. AFD, despite having higher median participation than in previous decades (i.e., four respondents instead of three), believes that it is chronically short of participants and therefore unable to properly address large volumes of nominations on the same subject. The community has also opined that nominating large numbers of similar articles (especially athletes who are all from the same non-English-speaking country) at the same time results in inadequate evaluation of any of them. That means you can send 25 articles a week if they're Al American, Bob British, Chris Chinese, David Danish, Eve Egyptian, Frank French, etc. but not 25 Gabonese athletes this week followed by 25 Hungarian athletes next week. This could be solved by making a list and marking your calendar to nominate four random articles from that list each day, but again: that's work for me, not work exclusively for thee. Also, quite a lot of these are going to end up with a recommendation to blank and redirect to a list, which would not be good for my success rates in the AFD stats department, and people might (legitimately) start yelling at me for using AFD on subjects that should be merged.
PROD has the same volume restrictions and at least as much possibility of getting yelled at for abuse. Also, mass prodding tends to get mass reverted, especially if there is a significant number of false positives/pages that should be redirected instead of deleted. So the opponents of these articles believe – and I believe that they're correct – that prod is an ineffective route for removal.
The end result of this is that whingeing in the village pump about how no other WP:VOLUNTEER has already done the things that you don't choose to do yourself actually is a "rational" response to the self-imposed and community-imposed restrictions.
One thing I've been thinking about this morning is the math. 140 people commented in LUGSTUBS2. About 60% of them voted in favor of the proposal. What if we had taken the list and had a bot parcel individual articles out to everyone who helped make the decision? Imagine that 1200 articles had been divided between the 140 participants, with instructions to check this one article and either add a source or redirect it to a suitable list? There were less than 10 articles per person in the list. Even at a rate of one a month, this would have been done faster, and without the bus factor risk of having a very small number of people doing nearly all the work. WhatamIdoing (talk) 19:48, 19 June 2025 (UTC)[reply]
The point of LUGSTUBS was to get permastubs out of mainspace in bulk without needing to go through and evaluate them individually while still in mainspace. That received strong consensus. The work of determining what to do with them individually was always supposed to be the burden of those who wished to keep them in some form. All that was recommended in the close pre-draftification was reconfirming continued stub eligibility according to the original draft inclusion standards, with breaking them into smaller groups being a suggestion; that is absolutely not the same as obligating anyone to evaluate them manually pre-draftification and certainly not obligating performing editorial actions like redirection (which is usually much more involved than your bulleted example). The proposal was not for a mass AfD or mass prod so your other bullets are strawmen. JoelleJay (talk) 01:52, 20 June 2025 (UTC)[reply]
You will note that the close explicitly found consensus against "indiscriminate mass editing", shoving them all into draftspace without any evaluation at all is indiscriminate mass editing. Thryduulf (talk) 01:59, 20 June 2025 (UTC)[reply]
(edit conflict) How about, rather than mass removing through either draft or AFD or PROD or whatever process, we actually work to improve them? (And if some are truly non-notable, then take a few to AFD each day.) Crazy idea, I know. But it results in a lot more benefit to the encyclopedia than endlessly arguing then arguing even more about whether the aforementioned arguing is best addressed by this type of mass removal or that type of mass removal... BeanieFan11 (talk) 02:01, 20 June 2025 (UTC)[reply]
Joelle, the summary for that allegedly "strong consensus" begins with these words:
"Tl;dr: the proposal passes, but by a narrow margin and with caveats."
Emphasis in the original. The proposal achieved, to again quote the closing statement, "rough consensus". I would not describe it as "strong consensus", and I doubt that most experienced editors would.
This sentence of yours: The work of determining what to do with them individually was always supposed to be the burden of those who wished to keep them in some form is a good description of what I'm identifying as a problem. Why should some editors (e.g., those who don't want to keep articles) be able to impose "the burden" of curating the mainspace on other editors? WhatamIdoing (talk) 02:13, 20 June 2025 (UTC)[reply]
Maybe this will be clearer:
What happened: "We" over here decided that "they" over there will do this work.
What I'd prefer: "We all" decided that "we all" will do this work.
Our mission is to enrich Wikimedia projects with high-quality and diverse content related to the Middle East and North Africa (MENA) region. This initiative focuses on creating new articles, multimedia, structured data, and more, covering topics from MENA countries, communities, and diaspora worldwide.
Who Can Participate?
All registered Wikimedians are welcome to join! Whether you're an individual contributor or part of an organization, your support is valuable. We encourage content creation in any of the six official UN languages (Arabic, English, French, Russian, Spanish, and soon Chinese).
What Kind of Content Are We Looking For?
New Wikipedia articles focused on MENA topics
Multimedia contributions on Wikimedia Commons (photos, videos)
Structured data for Wikidata
Language entries on Wiktionary
Public domain texts on Wikisource
Note: Make sure your content follows local Wikimedia guidelines and licensing policies, including Freedom of Panorama for media files.
Join us in bridging content gaps and showcasing the richness of the MENA region on Wikimedia platforms!
Stay tuned for more updates and participation guidelines. Reda Kerbouche (talk) 09:08, 23 May 2025 (UTC)[reply]
Per both the header at the top of this page and the editnotice, This page is for concrete, actionable proposals. As written, it sounds like the "proposal" in question here is "go create new articles", which is what we've been doing for the past two decades and plan to continue doing indefinitely into the future.
There is a lot of community skepticism of affiliate activities after we've seen numerous flashy announcements of ambitious-sounding projects filled with vague corporate buzzwords (e.g.Building strategic relationships with key stakeholders, identify growth opportunities) and funded by expensive grants that ultimately do little or nothing to improve the encyclopedia. I assume that there is more detail/planning to your initiative than is described in your note above and on the project landing page (where you may wish to fix the broken header tabs), but it may behoove your interests to craft announcements that assuage rather than exacerbate the aforementioned fears. Sdkbtalk15:00, 23 May 2025 (UTC)[reply]
Thank you for your feedback; it’s both valid and appreciated. And we took time to discuss all the questions with the whole team.
We understand that from a first read, this may seem like a broad or familiar call to action. However, the Million Wiki Project is not just about encouraging content creation, it’s about coordinating and resourcing communities in multiple regions (some are underrepresented) to increase content equity across multiple Wikimedia projects. If you think the details are insufficient in the landing page; we can expand it based on the feedback we receive.
We’ve seen firsthand that in many MENA countries, editors face barriers like limited outreach, infrastructure, or access to local events. This project provides logistical and financial support (e.g. internet stipends, local editathons etc.) to empower them to organize impactful campaigns.
At its heart, this project is about inclusion; bringing everyone along on this journey, even those who haven’t had the chance to participate before. While the name may highlight a numerical goal (a million contributions), our true aspiration is to ensure that every Wikimedian feels they have a place and a voice in this movement.
This project has been co-designed by experienced editors, supported by the grant committee of the Project, and built on the feedback received from the community organizers. It's an ongoing process; and we’re learning every step of the way. Abbas14:00, 3 June 2025 (UTC)[reply]
I'm confused about what this is actually about. Does create one million new contribution and content pieces mean one million edits or one million articles? Does it include images on Commons and documents on Wikisource? Why does any of this need funding? If you are paying editors, it may slow things down (on enwiki), as draft articles would have to go through the Articles for Creation review process. Toadspike[Talk]16:18, 23 May 2025 (UTC)[reply]
Thank you for raising these valid questions. The “one million” target includes meaningful contributions across Wikimedia projects: new additions/articles, structured data, Commons uploads, Wikisource documents, and more. Full details are available here. To clarify: we are not paying editors for content creation. Instead, we provide microgrants to communities and affiliates who want to run campaigns, editathons, similar to other movement grants. These are needs-based, and only support logistics, internet costs, etc. We're especially encouraging experienced editors to lead these initiatives, precisely to maintain quality and alignment with Wikimedia’s standards, including AfC processes when required. Reda Kerbouche (talk) 17:36, 2 June 2025 (UTC)[reply]
Why is this project restricting its support to content in "official UN languages", the majority of which have limited, if any, connection to the MENA region? Is such blatant discrimination normal practice? AndyTheGrump (talk) 16:25, 23 May 2025 (UTC)[reply]
English does make sense as the international lingua franca, and of course (Modern Standard) Arabic as the standard language used by half of the Middle East, but it misses on relatively large wikis (such as Persian, Hebrew, Egyptian Arabic and Turkish Wikipedias), which are all more relevant to the region (and likely have more native speakers who might be able to help on MENA topics) than Spanish or Russian. Chaotic Enby (talk · contribs) 16:37, 23 May 2025 (UTC)[reply]
Thank you for your questions @AndyTheGrump and Chaotic Enby:; it's important to clarify this point. At this stage of the Million Wiki Project, we’ve chosen to focus on contributions in the six UN official languages (Arabic, English, French, Spanish, Russian, and Chinese). This was a strategic decision made by the organizing team and the grant committee to ensure consistency in tracking, reporting, and coordination across different regions and communities. The choice is based on practical reasons:
These languages already have strong foundations across many Wikimedia projects.
They are widely spoken or used in official or educational contexts in several MENA countries.
They provide a shared framework for documentation and collaboration with international partners and communities.
The scope of the project is limited to the mentioned languages; which reflects the priorities and capacity of this phase. However, we will consider other languages as the project evolves. Reda Kerbouche (talk) 17:43, 2 June 2025 (UTC)[reply]
FWIW - for most parts of West Asia and North Africa you're far more likely to be able to communicate in French over Hebrew, Farsi or Turkish. Oh... and Russian these days will stand you in pretty good stead in the Gulf. Regards, Goldsztajn (talk) 03:34, 28 May 2025 (UTC)[reply]
I agree with @Sdkb that the project page does read as corporate-written (or possibly AI-written, with little concrete difference between both). It could be good to clarify it in more concrete terms on the landing page, although there seem to be more detail on meta:The Million Wiki Project/FAQ (to reply to @Toadspike's query, it seems to count new page creations on all projects). Concerningly, neither that page nor meta:The Million Wiki Project/Funding Guidelines talk about how this meshes with our policies on paid editing, despite repeatedly talking about "transparency". Chaotic Enby (talk · contribs) 16:29, 23 May 2025 (UTC)[reply]
Original Media:** Photos, audio, or video content taken or created by the uploader(s).ChatGPT very often generates bullet point lists of the form **Short Title:** Longer explanation of what is meant by the short title. (as it uses **this syntax** to bold text). This very much looks like a remnant of that syntax that wasn't correctly removed, especially since the asterisks don't seem to be referenced anywhere. Chaotic Enby (talk · contribs) 21:36, 23 May 2025 (UTC)[reply]
That's quite concerning. Jtud (WMF), the WMF Grants team should probably be aware of this whole thread (if you're not the right point person, I'd appreciate you forwarding this or letting us know who the right person would be). Sdkbtalk19:18, 24 May 2025 (UTC)[reply]
All major decisions, structures, and policies were drafted by human contributors — the grant committee members — many of whom are seasoned Wikimedians; we made sure no policies were breached. As everybody does, we consulted AI tools to proofread the English draft, e.g. grammar checks and language structure. We understand the importance of human tone and accuracy in Wikimedia spaces, and we truly welcome community edits to improve clarity or remove awkward phrasing or markup remnants. cordially Nehaoua (talk) 17:22, 2 June 2025 (UTC)[reply]
From Meta:The Million Wiki Project/Eligibility Criteria: This effort covers a wide range of countries, including Algeria, Bahrain, Egypt, Iraq, Jordan, Kuwait, Lebanon, Libya, Mauritania, Morocco, Oman, Palestine, Qatar, Saudi Arabia, Somalia, Sudan, Syria, Tunisia, the United Arab Emirates, and Yemen, as well as topics relevant to their diaspora communities worldwide.. There is an obvious omission here, which I hardly need spell out. Can I ask why the 'MENA' region appears to have a hole in it? AndyTheGrump (talk) 16:35, 23 May 2025 (UTC)[reply]
Given how Iran, Israel, and Turkey are all missing, while Somalia is there, it looks like the list of Arab League members was used for some reason (although for some reason Djibouti and the Comoros were excluded but not Somalia). Chaotic Enby (talk · contribs) 16:40, 23 May 2025 (UTC)[reply]
Combined with the requirement that submissions be in a UN official language, I'm not sure this looks like an evenhanded approach to the Middle East. Wehwalt (talk) 17:37, 23 May 2025 (UTC)[reply]
It isn't. Not remotely. And given the issues the English-language Wikipedia already has with partisan editing with regard to many 'Middle East' topics, the last thing we need is to look like we are endorsing such a perspective. This ill-thought-out project should never have been approved in the state it is. AndyTheGrump (talk) 19:37, 23 May 2025 (UTC)[reply]
This ill-thought-out project should never have been approved in the state it is. – They should make this the collective slogan of wikimedia projects. Thebiguglyalien (talk) 🛸21:31, 25 May 2025 (UTC)[reply]
That could be said about Wikipedia itself, especially when it started, but kinda still today. Good thing that ill-thought-out project didn't need anyone's approval to get started.
My fellow editors, I never cease to be amazed at the reflexive and vehement opposition so many of y'all have to experimentation and ideas and change in general. It's a wiki, for fuck's sake, it's supposed to be iterative, not perfection. Levivich (talk) 20:34, 10 June 2025 (UTC)[reply]
Other than Arabic, Farsi, Pashto, Urdu, Kurdish etc is written using Arabic script. It is *the* most representative script across the entire region, including other scripts would not be "even-handed". Regards, Goldsztajn (talk) 03:51, 28 May 2025 (UTC)[reply]
@AndyTheGrump and Chaotic Enby:, we understand that geopolitical or regional classifications can differ. For example, countries like Turkey, Iran, and Other countries, while geographically part of the broader Middle East, are classified under different regions by the Wikimedia Foundation’s regional structure (e.g. CEE, Northern & Western Europe).The countries listed were selected based on a few practical factors:
Existing connections with local Wikimedia communities and affiliates
Participation in the WikiArabia conference
Inclusion in the League of Arab States, which formed a cultural basis for our first project phase
That said, this is not a political exclusion (it's a reflection of community capacity and scope). We’re open to expanding this framework in the future as our network grows. Reda Kerbouche (talk) 17:51, 2 June 2025 (UTC)[reply]
As far as I know, Iran is very much classified as MENA by the Wikimedia Foundation. Also, that wording of "Turkey, Iran and Other countries" is a bit weird given that there was only one other country mentioned.It could be much better to present it as a contest about Arab countries, not about MENA countries. Chaotic Enby (talk · contribs) 20:19, 2 June 2025 (UTC)[reply]
@Reda Kerbouche I'm looking for a specific answer here, if possible: would Israeli participation be welcome? Could they be included in the project upon request, either by the their chapter, a wikiproject, or individual editors? FortunateSons (talk) 08:04, 10 June 2025 (UTC)[reply]
I would guess that all the countries on the list are more underrepresented on Wiki than Israel is. I completely support the WMF focusing its efforts on areas that are underrepresented, although who knows what they are thinking here. (t · c) buidhe21:49, 26 May 2025 (UTC)[reply]
Hi Reda - sorry that you had to face this intense scrutiny all at once, it's really worth trying to get the community on board before launching stuff like this, then these issues will be dealt with in advance. One more point, you say "we are not paying people for editing" (paraphrase) but the funding page says "Contributors performing significant verified work (e.g., high-quality editing, multilingual translation, metadata curation)." I'm fine with that (a lot of people might not be), but concerned that you gave a different answer. All the best: RichFarmbrough21:16, 2 June 2025 (UTC).[reply]
It perhaps would have been better received had it been posted at WP:VPW or WP:VPM, since this is really just an announcement to the community about an available resource rather than a proposal for the community to implement. signed, Rosguilltalk14:15, 3 June 2025 (UTC)[reply]
Sorry again for the bother, but I haven't gotten any response on how the payment might work regarding our paid editing policies. It could be good to clarify what is meant by contributors being paid for "significant verified work". The FAQ page (item 19) currently states that funds could go to targeted contribution campaigns, is there any information about what they might be? How much involvement do the project's partners (which I assume are providing the funding) have in the selection and organization of these campaigns?As you state that the project is committed to transparency in its funding, it could be great for Wikimedia volunteers to have more information about these points. Chaotic Enby (talk · contribs) 22:41, 2 June 2025 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Should the Wikipedia logo be changed for one day to commemorate the 7 millionth article? To the right is the modified version of the last millionth's logo.Catalk to me!02:39, 28 May 2025 (UTC) Edit: Chaotic Enby has created a logo that better resembles the one used in the last million. 23:54, 28 May 2025 (UTC)[reply]
This. The serif font, yellow/gold gradient, and banner border are all weird. I know Wikipedia is known for having a long-outdated look (and some of us are proud of this), but if we're creating something new to represent our progress it should look...new. Toadspike[Talk]06:38, 28 May 2025 (UTC)[reply]
Changing the logo would probably take at least a couple days, maybe a week or two, because of needing to get consensus, then needing to write a patch and deploy it. Those are not fast processes. Would folks still want this if it's weeks after the 7 millionth article date? –Novem Linguae (talk) 04:18, 28 May 2025 (UTC)[reply]
Readers aren't necessarily checking the exact number, so celebrating the milestone even a few days/weeks late would still be just as meaningful in my opinion. Chaotic Enby (talk · contribs) 11:42, 28 May 2025 (UTC)[reply]
A better source of inspiration?Meh, that logo isn't especially modern or elegant – I especially second Toadspike's more detailed remarks. While a serif font could be okay (assuming we're going for Linux Libertine Bold), the border on the text, and the yellow-white gradients, all look tacky and not very professional. If we really want, a variant of the other 6 million logo would look more elegant.The circumstances are also less than ideal, as, from what I understand, the 7 millionth article came in the middle of a batch of 200-something mass created city council articles, which isn't really what we wish to encourage.Edit: with a cleaner logo, support – although I still believe that the circumstances are less than ideal, it is still a strong message to show that Wikipedia is still just as thriving. Raw article count shouldn't be encouraged for editors, but these flashy logo changes are mostly destined to readers (and potential readers), and the communication opportunity is pretty good. Chaotic Enby (talk · contribs) 09:49, 28 May 2025 (UTC)[reply]
I'm sure there are non mass-created articles in the final 1,000. At a slight topical shift, if we want to encourage quality, we're currently at 6,741 FAs. A bit of work to go to catch up to a 0.1% total article rate, but we could also celebrate 7,000. On a longer view, we could begin planning for the big 10k FA, presumably with a much longer lead time than we had for this. (Although in both cases only if this doesn't pressure the FAC coords, who presumably should treat potential milestone FAs the same as any other.) CMD (talk) 09:58, 28 May 2025 (UTC)[reply]
A logo with a more fitting styleSadly, the 6 million logo above wasn't available in a SVG version (besides a lower quality autotraced one), although I've tried to make one in the same style for 7 million articles. Feel free to make any improvements to it! Chaotic Enby (talk · contribs) 11:18, 28 May 2025 (UTC)[reply]
Support this version. Thank you for creating it, Chaotic Enby! I agree in principle with the "quality, not quantity" folks, but the two are not mutually exclusive. 50K GAs and 10K FAs are milestones we should reach soon, which we can also celebrate with a logo change. But we celebrate easily-understood milestones to encourage readers to become editors, and article count is the most easily-understood milestone of all. Toadspike[Talk]12:56, 28 May 2025 (UTC)[reply]
Support this version. I think that changing the logo for a brief period of time is a great way to advertise the progress done so far. Quality would be way harder to advertise in my opinion (Since it is way harder to shorten into one number and to objectively measure) Madotea (talk) 18:05, 29 May 2025 (UTC)[reply]
Oppose in favor of Wikipedia celebrating quality over quantity for a change, which is even more important in the age of AI. Generating a lot of text is not an accomplishment in and of itself. Levivich (talk) 12:02, 28 May 2025 (UTC)[reply]
Btw I'd probably support marking major milestones like 10M and 25M articles, but I don't support changing the logo every 1M articles. It's WP:EDITCOUNTITIS to keep track of such small intervals--the encyclopedia grew by 16%, from 6M to 7M. Wow, big deal. Levivich (talk) 16:56, 29 May 2025 (UTC)[reply]
The interval isn't the passage of time, it's the article count. We already celebrate the passage of time: Wikipedia's 20th birthday was celebrated and its 25th will be celebrated next year. Sure, change the logo for those anniversaries. But our article count increasing by 16% does not seem like anything worthy of celebration to me. When you have 6 million articles, adding another million is not a big deal. Even less so when we hit 8 million. I'd rather we reserve logo celebrations for actually-meaningful milestones, like 5,000 FAs, or 500,000 women biographies, or a million articles about the southern hemisphere... take your pick, there are plenty of meaningful milestones to choose from. "16% increase in article count" isn't one of them, IMO. Plus, it sends the wrong message: that what we're about is article count. Given that every year there will be new notable topics (new notable events, new notable works, etc.), article count increasing is a given; it's not an accomplishment in and of itself. Levivich (talk) 19:21, 29 May 2025 (UTC)[reply]
Oppose Anything like this or Wikicup that encourages simple creation without any expectation of quality is bad behavior. How many of the 7M articles are GAs or FAs? Its less than 1% of the total article count which is not a good look if we're just praising simple creation. Masem (t) 12:05, 28 May 2025 (UTC)[reply]
0.69% GA or FA, although GA is likely bottlenecked more by reviewing time than it is by content creation. CMD (talk) 12:45, 28 May 2025 (UTC)[reply]
How does the Wikicup encourge simple creation without any expectation of quality? Points are only awarded for quality articles (GAs, FAs, etc.) and for DYKs. Cremastra (u — c) 12:36, 28 May 2025 (UTC)[reply]
I still feel that the Wikicup encourages rushing processes along to earn points during the limited time the cup is held. Any type of gamification of wikiprocesses can be a problem. Masem (t) 17:24, 28 May 2025 (UTC)[reply]
No comment on the oppose, but as to the WikiCup comment the opposite is true. I and the other WikiCup judges have been disqualifying entries rather frequently for not being of high quality. I do get the gamification concerns though, but claiming the Cup "encourages simple creation without any expectation of quality" is false. Epicgenius (talk) 20:09, 28 May 2025 (UTC)[reply]
Gamification is a great tool. Backlog drives can make good progress on or clear out a backlog, and also serve as a great recruitment tool and raise WikiProject morale. Definitely a net positive, imo. Outliers can be dealt with via ANI and/or a re-review system. –Novem Linguae (talk) 20:28, 28 May 2025 (UTC)[reply]
Oppose. We shouldn't celebrate an editor dumping nearly 200 identical poor articles in violation of WP:MASSCREATE just so they can claim the 7 millionth article. The less attention we give to this, the better chance we have to stop such silliness. Quality over quantity seems more apt than ever here. Fram (talk) 14:46, 28 May 2025 (UTC)[reply]
Despite having more articles, our pageviews have not really changed - existing in a range of 7 - 8.5 million since 2015. While it's possible that without an expansion of articles we'd be even lower, I am skeptical that our readers actually care about our number of articles. Instead I think it makes us as editors feel good. I think there's a way to make the editing elite feel good without changing the logo, and also agree with the general focus on quality of information for our readers rather than focusing on the quantity of articles, and so I oppose this logo change but support other ways of celebrating the milestone. Best, Barkeep49 (talk) 15:09, 28 May 2025 (UTC)[reply]
According to Wikipedia:Statistics#Page views: Most articles have very low traffic. In 2023, 90% of articles averaged between zero and ten page views per day. The median article gets about one page view per week. Because the top 0.1% of high-traffic articles can each get millions of page views in a year, the mean is about 100 times the median. If that % still holds true today, it would mean that ~6,300,000 articles of the 7 million articles average between 0 and 10 page views a day. Some1 (talk) 23:37, 30 May 2025 (UTC)[reply]
Support we can find time to celebrate, and though 7 million articles of varying quality is arbitrary, all milestones on a volunteer encyclopedia are probably a bit arbitrary. and ChaoticEnby's work looks nice. Bluethricecreamman (talk) 17:16, 28 May 2025 (UTC)[reply]
Given the fractious nature of the post-7 million discussion and the incentive structure that led towards it, and perhaps very pertinently due to it being seemingly impossible to identify the actual 7 millionth article given how rapidly things are in flux, I have come around to leaning oppose towards celebrating a specific article. I'm not at this moment opposed to celebrating "7 million articles" in the plural, but it should be clear that the proposal is not to "commemorate the 7 millionth article". CMD (talk) 20:13, 28 May 2025 (UTC)[reply]
Mild oppose Would have little impact and celebrates the wrong thing (article count vs. quality) North8000 (talk) 21:00, 28 May 2025 (UTC)[reply]
Conditional Support, upon consensus on which article to represent the 7-million articles milestone at Wikipedia talk:Seven million articles, and that the chosen article is of acceptable quality. There is a shortlist of articles which may represent the milestone. While some may have started as stubs or start-class articles, the respective authors of the shortlisted articles and other editors have started on improving the quality of the articles, possibly in hopes of their article getting chosen at the end of the consensus building exercise. There is no rush to push the logo out. – robertsky (talk) 04:08, 29 May 2025 (UTC)[reply]
"The English Wikipedia has reached 7,000,000 articles with [chosen article]" seems like a misleading statement then if we don't exactly know what the 7-millionth article is and are just choosing one to represent it. Some1 (talk) 12:04, 29 May 2025 (UTC)[reply]
Out of curiosity - what is the current count of GA & FA articles? Are we anywhere close to a milestone on those? If so… THAT would be something that is much more meaningful to celebrate. Blueboar (talk) 17:00, 29 May 2025 (UTC)[reply]
We're at 41,835 GAs, 6,741 FAs, and 4,655 FLs (for a total of 53,231 quality articles). I'm guessing the next big milestones would be 50,000 GAs, 7,000 FAs and 5,000 FLs, and the latter two would be reachable in one or two years (although I doubt enough readers care about lists to celebrate it on the main page). Chaotic Enby (talk · contribs) 18:19, 29 May 2025 (UTC)[reply]
Comment: Edited the 6 million red logo to be 7 million. Font for the red banner is Roboto Condensed, and then bolded, if anyone else wants to do it (I have no idea how to properly photo edit.) Red 6 mil logo but for 7 milARandomName123 (talk)Ping me!21:24, 29 May 2025 (UTC)[reply]
Support. We have to celebrate the small wins. This is good PR, attracts press attention, puts Wikipedia in the news, reminds people of the website that is secretly funneling ChatGPT's wisdom. The next 8M milestone may be 6-7 years away, and that's if the project survives – it most likely will, but don't take it for granted. Levivich makes a reasonable point above about celebrating quality instead, but it's not easy to communicate a milestone like 50,000 good articles to the intended audience ("are the other 6.5M articles bad?"). Featured article milestones are a better sell, but our count of FAs is embarrassingly low. – SD0001 (talk) 21:57, 29 May 2025 (UTC)[reply]
On PR: I'm unsure about the design style of the logos put forward. They are inconsistent with Wikipedia/MediaWiki's design style, though I certainly cannot make anything better. Aaron Liu (talk) 03:26, 30 May 2025 (UTC)[reply]
My proposal went with the Linux Libertine font, which is the one used in Wikipedia's logo typography (although bolded for better readability, so the letter shapes slightly differ). That's the main reason why I didn't want to copy the exact style of the "6 million" logo. Chaotic Enby (talk · contribs) 13:07, 30 May 2025 (UTC)[reply]
"50,000 good articles to the intended audience ("are the other 6.5M articles bad?") What happened to the other 0.45 million? :P Regards, Goldsztajn (talk) 21:59, 30 May 2025 (UTC)[reply]
SupportChaotic Enby's version for up to a week (seven days for seven million?) While I'm definitely in the quality-over-quantity camp, I think it's worth making a (not-too-gaudy) statement that can be appreciated by the media and casual visitors – we're still here, we're still creating and improving content, and we're still mostly human. For the same reason, if we do have a special logo it should be up for more than 24 hours – it may be easy for us insiders to forget that people who care about Wikipedia don't necessarily visit the site every day. – ClaudineChionh (she/her · talk · email · global) 02:04, 30 May 2025 (UTC)[reply]
Support I like the red 7 million logo, and I like seven days for seven million. This is a fun tradition, and its a little victory to celebrate! We should be proud of what we've accomplished! CaptainEekEdits Ho Cap'n!⚓03:57, 30 May 2025 (UTC)[reply]
Changing to oppose. The moment has passed. I'm very disillusioned here. How could we not make a simple logo change happen in time?? We did it easily, and with no fuss at six million. We took like... a day, and nobody raised a fuss. At any rate, with Vector 2022, we need a square logo (sans the Wikipedia subtitle), in an svg, which nobody has even created. So chock this up as a dismal and upsetting failure. When we hit 8 million, I'll make sure to do this like 6 months before we think we'll hit that number, so we have enough time for everybody to complain and do like three close reviews. Super disappointing. Where'd our spirit of fun go? CaptainEekEdits Ho Cap'n!⚓05:17, 4 June 2025 (UTC)[reply]
Support Variety is the spice of life and so celebrating this with a splash is a healthy sign of continuing vigour. I'm not fussy about the format – the key thing is to show that we're still alive and kicking.
Editors who prefer quality to quantity can celebrate that too but the numbers there are not so good. Currently there are just 6,743 FAs and 41,837 GAs and my impression is that those numbers don't rise so steadily. So, we should count our blessings and celebrate what we can.
Ugh. A fine demonstration of Wikipedia's unreliability; the English language Wikipedia has 7,011,419 articles (and Wikipedia as a whole has 65,101,842). What's celebratory to some is self-congratulatory to others, and this does beg the question "but are they any good?" NebY (talk) 12:04, 30 May 2025 (UTC)[reply]
Support each million articles is a huge milestone (considering each one has to hold its own weight). I think either ChaoticEnby's version or the one initially proposed would work.
Support red or pink ribbon versions. This is an important milestone that should be celebrated! Yeah, many (maybe even most) articles aren't of great quality, but should that really matter? Wikipedia will always be a work in progress, and said progress should be recognised wherever possible. Loytra (talk) 18:25, 30 May 2025 (UTC)[reply]
Support but make the text on the ribbon gold. I have been waiting for this for ages, Finally I am here for an event that I am not blocked for! Toketaatalk18:28, 30 May 2025 (UTC)[reply]
Comment - maybe including a casualty count would make it more interesting - x articles, y editors imprisoned, z articles taken down by court order. Maybe y is zero-ish for English Wikipedia and z is one-ish (temporary). More impressive than 7 million articles in a way. Sean.hoyland (talk) 18:44, 30 May 2025 (UTC)[reply]
Notably, something needed is going to be showing of community consensus -- such as a closed discussion finding as such. — xaosfluxTalk20:59, 30 May 2025 (UTC)[reply]
The community already did this for the 5M and 6M milestones and so there's an existing consensus and tradition. Andrew🐉(talk) 21:27, 30 May 2025 (UTC)[reply]
You might want to cut and paste this bullet and its replies into an "implementation" sub-heading. I agree that getting someone to formally close the discussion would be a good idea (maybe list it at WP:ANRFC?). Do we know which of the multiple proposed logos achieved consensus? Do we know how many days the altered logo should be up for? –Novem Linguae (talk) 22:37, 30 May 2025 (UTC)[reply]
@CaptainEek: "solid support"? By my rough count it's a little less than 2/3 supports and 1/3 opposes, with a fair number of weak on either side. I'm not outright opposed, but I think it's a stretch to say "solid" given Wikipedia's notions of consensus. Regards, --Goldsztajn (talk) 22:12, 30 May 2025 (UTC)[reply]
@Goldsztajn at a rough count of 20 to 8, that seems solid to me, and it's going to take some time to get the ball rolling. Like, if you were in a room of 28 people, and 20 of them were on one side, even if they were grumbling, you'd say "clearly they have the majority". CaptainEekEdits Ho Cap'n!⚓22:20, 30 May 2025 (UTC)[reply]
They don't do it 3/7 days in a week? I didn't realize how much slower the process is these days. I guess the lesson for 8 million is to plan out a logo change ~ten thousand articles before it happens. CaptainEekEdits Ho Cap'n!⚓01:12, 31 May 2025 (UTC)[reply]
I'd concur with the 20 support, but I count 12 opposes (including my Meh, but not Chaotic Enby's) that are more on the oppose side than the support side. Regards, Goldsztajn (talk) 00:36, 31 May 2025 (UTC)[reply]
FWIW - the last print edition of Britannica had 40,000 articles, I'd be less grouchy celebrating 7 million Wikipedia articles *and* more GAs than the last print edition of Britannica had articles. Regards, Goldsztajn (talk) 02:40, 31 May 2025 (UTC)[reply]
Support and it makes me a little sad that even something this tiny and cute is being dragged into the deletionist hellpit. I guarantee no reader is going to look at the logo and think "wow, these articles must suck and/or be created by the Wikipedia scapegoat." Gnomingstuff (talk) 16:39, 31 May 2025 (UTC)[reply]
Support: I think we’re probably due for a discussion about how and whether to celebrate x millionth article milestones going forward. However, I say we should celebrate this milestone with a logo change, even if for one last time. Spirit of Eagle (talk) 23:21, 31 May 2025 (UTC)[reply]
I am not opposed to this, but I would point out that the new Vector skin's Wikipedia logo is quite small nowadays. If we implement the same logo design as in years past, it might not be legible anymore. Mz7 (talk) 02:47, 1 June 2025 (UTC)[reply]
Oh, and on the subject of Vector 2022 the logo actually consists of three separate images (logo, wordmark, tagline) which are specified separately in the config file (whereas legacy Vector still uses one file). So you will need to change the logo proposal to fit in that format. * Pppery *it has begun...03:05, 1 June 2025 (UTC)[reply]
Hmm, what if we just temporarily change the tagline away from "The Free Encyclopedia" to a ribbon that says "7 Million Articles". Sounds like that is possible and would be the cleanest solution. Mz7 (talk) 03:09, 1 June 2025 (UTC)[reply]
Ehhh, I really dislike that design. I would rather the ribbon text be illegible than adopting a yellow Wikipedia logo with font that looks like we're back in the 90s (lol). Mz7 (talk) 03:03, 1 June 2025 (UTC)[reply]
Support for a week, as a tradition that shines a positive light on Wikipedia's progress. I prefer the ribbon style, with Chaotic Enby's version as first choice for its SVG format, but I would rather see any commemorative logo implemented than to have this discussion deadlocked any further. — Newslingertalk11:07, 1 June 2025 (UTC)[reply]
Oppose In favour of Wikipedia celebrating quality over quantity. Why should we strive to i-don't-know-how-many stubs without serious content? The Bannertalk19:07, 1 June 2025 (UTC)[reply]
Support. It is still a notable achievement. We won't have a perfect encyclopedia where each and every article is GA-grade until the Sun burns out, but I think we can certainly celebrate 7 million articles. It is a good way to communicate to casual readers about the number of articles that Wikipedia had. SunDawn (talk) 01:43, 2 June 2025 (UTC)[reply]
Support fun times. The "quality over quantity" argument is specious. Only 7 million things for the entire history of the universe are found to be notable? Our quantity is on the low end. Furthermore it infers nothing about quality, they are not mutually exclusive traits. -- GreenC01:55, 3 June 2025 (UTC)[reply]
Here's the square!To clarify, I did resize it to be square at one point, but the MediaWiki documentation did mention that there were exceptions to the "square rule" if the logo had text underneath (in which case 135x155px seemed appropriate). The square thing appears to be for the logo alone (without text) in new skins like Vector 2022, and I just uploaded it separately. Chaotic Enby (talk · contribs) 08:43, 4 June 2025 (UTC)[reply]
Oppose, creating three URLs with 200 words each shouldn't be treated as superior to creating one URL with 600 words. It's already hard enough to maintain quality control without telling people that having the first edit in the article history is somehow more meaningful. Thebiguglyalien (talk) 🛸18:14, 4 June 2025 (UTC)[reply]
Oppose A large chunk of new articles these days are WP:CORPSPAM, and that is a major cottage industry with rather limited tools to fight it, so celebrating articles purely based on sheer quantity rather than quality adds fuel to what is already a raging forest fire. ᴢxᴄᴠʙɴᴍ (ᴛ) 08:16, 9 June 2025 (UTC)[reply]
There appears to be consensus for this. Do we know which of the multiple proposed logos we should use? Do we know how many days the altered logo should be up for? Once details like these are decided, myself or someone can write a patch using the procedure at meta:Requesting wiki configuration changes#Changing a wiki's logo. We shouldn't wait too long though. This thread is already getting kind of stale, and we are drifting away from the 7 million achievement with each passing day. –Novem Linguae (talk) 11:10, 10 June 2025 (UTC)[reply]
There's heavy enough opposition there should probably be more than a glib statement that there is consensus. I'd like to see a more formal close. Wehwalt (talk) 11:54, 10 June 2025 (UTC)[reply]
I'd say this whole 7 mil milestone stuff is getting stale now. Once the main page banner gets taken down, we're beating a dead horse with this logo change, imo. Some1 (talk) 12:05, 10 June 2025 (UTC)[reply]
I came here with the intention of closing this discussion, but after reading it I have some strong thoughts and am not going to supervote. Perhaps the below will be useful when we get close to eight million.
There should have been a hard time limit set for the end of the RfC.
There should have been an agreed-upon design ready to go. That first design is, with apologies to its creator, not good. It looks more like a price tag than the professional logo you'd expect from the world's largest encyclopedia. No one should be surprised by/angry with those early concerns/opposes.
There should have been an agreed-upon amount of time that the logo would have been live, or at least one proposed in the OP.
Even though there's something like 2:1 support in the raw number count above, I can't help but wonder how many people who !voted early would now agree with CaptainEek and others who are saying "it's too late"... because it is. As I write this, it's nearly two weeks late. Shame on us, frankly. Ed[talk][OMT]02:56, 11 June 2025 (UTC)[reply]
Agreed on all points. We could probably take the main page banner down now; it's been up for a good while. Better luck in 6 years or so. Mz7 (talk) 21:12, 11 June 2025 (UTC)[reply]
We could already get the next steps ready for the next GA or FA milestone, as they might come much sooner than 8 mil articles (and put more emphasis on quality). Chaotic Enby (talk · contribs) 22:13, 11 June 2025 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
"Basic" is not a good description of the topics this board is for - to me "basic" implies simple, uncomplicated questions about fundamentals rather than anything to do with subject matter. Questions relating e.g. policy belong on the policy village pump regardless of there complexity, questions unrelated to the subject of the other village pumps belong here even if they are very complex. If the length of "miscellaneous" was an issue (and I'm not convinced it is) then surely the obvious thing would be to change it to "misc"? Thryduulf (talk) 11:32, 1 June 2025 (UTC)[reply]
I think "miscellaneous" is fine. If we were going to change it, "basic" is not at all correct. "Other" would be more accurate. Anomie⚔11:54, 1 June 2025 (UTC)[reply]
Hi all - not sure whether this is possible but it would be nice. I see a lot of latitude and longitude coordinates given to impossibly precise levels of accuracy - buildings and structures given with coordinates like 41.572947546321°N, 125.462903749248°W. While I like accuracy, this pinpoints a building to within 1/1000 of a micrometre - which is probably overkill. Is there anyway of automatically truncating such precision to, say, six decomal places? That would still give precision within about 20 centimetres, which is close enough for any practical coordinate purposes. (PS, I'd prefer if they were all in ° ' ", but that's probably just me and not worth doing). Grutness...wha?03:59, 3 June 2025 (UTC)[reply]
It's the fault of whoever added it like that and you are welcome to change it. It's hard to do automatically, though, since the proper precision depends on the size of the thing that is being located. A building is worth more digits than a river, etc. Maybe a bot could be written for certain types of articles that the bot can recognise, but I'm not sure it would have few enough false positives. Zerotalk07:33, 3 June 2025 (UTC)[reply]
Most of these will be copied directly from services like Google Maps which displays the location you click to 5 decimal places but puts about 15 decimal places on the clipboard. e.g. on it's minimum zoom level I got 51.23262708044534, 0.23095125460548796 despite 1 pixel making tens of kilometres of difference at that latitude.
The first step to fixing over-precision is to identify the scale of the issue. For example get a bot to list all the articles with coordinates more precise than 6 decimal digits (or the equivalent in DMS). There is likely to be some way of cross-referencing articles with Wikidata to group them by the "instance of" property. Thryduulf (talk) 09:18, 3 June 2025 (UTC)[reply]
My thought would have been to trim down some overly-precise examples and leave an edit summary referring to WP:OPCOORD or the coord template documentation. When other editors see it some may take note and make similar edits. However, the guideline seems a bit technical and I suspect that some editors would find it easier to understand "If it's the same size as a football field use X level of precision" - perhaps it would be helpful if OPCOORD also included a precision/object conversion chart equivalent to the xkcd table. EdwardUK (talk) 15:13, 3 June 2025 (UTC)[reply]
Ideally yes, but rows need to be worded carefully. Going back to the structure example earlier, there are some bridges that have a rather extreme length dimension, however we are still going to want coordinates that are within its width dimensions and approximately midway down the length. 184.152.65.118 (talk) 16:14, 6 June 2025 (UTC)[reply]
That is also rather technical and suggests that there is no suitable precision for an object ~100m in size located further than ~37° from the equator. Thryduulf (talk) 01:16, 9 June 2025 (UTC)[reply]
I don't know how it could be less technical. It's closely analogous to a Blackjack strategy quick-reference card, which any teenager could handle. It's a simple two-dimensional table lookup, eliminating the need for any arithmetic; the arithmetic was done when the tables were created. Does an editor need help determining that 35 is closer to 30 than to 45? Or 35.41899175, even? If so, maybe coordinates aren't a good place to spend their efforts. Coordinates are all about numbers. (Most likely, the editor is working on coordinates because they like numbers. We rarely like numbers unless we're good with numbers. I speak from experience, as that's why I spent multiple years of my life working with Wikipedia coordinates.)there is no suitable precision for an object ~100m in size located further than ~37° from the equator. Sorry, I don't follow. That precision will be d° m' s.s" or d° m' s", depending on how much further than 37° from the equator. Or, in the other format, d.dddd. Both are derived from the tables at OPCOORD, like the rest of COORDPREC.Regarding coordinates, like so many other things, we need to beware of overthink, of over-engineering. Perfect is the enemy of good. ―Mandruss☎ IMO. 08:53, 9 June 2025 (UTC)[reply]
Re the suitable precision argument, if d° m' s.s" is suitable why is it coloured red in the table? I interpret red to mean that that precision should not be used for objects of that scale at that latitude. If that interpretation is right, then there are several combinations of scale and latitude where no suitable precision exists (e.g. 50m above ~37°, 100m below 57°, 10km at any latitude). If my interpretation is wrong then the table needs a key or some other explanation of what the colours actually mean. Thryduulf (talk) 14:22, 9 June 2025 (UTC)[reply]
The colours appear to be meaningless, and are used only to differentiate between each level of precision - it should be possible to change them to something else that does not suggest yes/no in the way green/red can do. EdwardUK (talk) 16:58, 9 June 2025 (UTC)[reply]
The colors improve the aesthetics, and that's important. Colors make the tables more inviting, less intimidating. But that's secondary to the usability enhancement. With an all-white table, it would be significantly more difficult to see minor differences between cells on the same row. That's why the Blackjack strategy quick-reference card uses colors in a similar way.I'm not married to red and green. Any two complementary pastels would do, and that could easily be changed lest a user looks at the tables and sees traffic lights. (Or they could just read the instructions above the tables. The tables are derived from those at OPCOORD only if the instructions are followed.) ―Mandruss☎ IMO. 18:01, 9 June 2025 (UTC)[reply]
I think it would work better if each level of precision had its own colour across rows, so the overall table would resemble a topographical plot. isaacl (talk) 18:17, 9 June 2025 (UTC)[reply]
Four different colors for the dms table and six for the decimal table? Struggling to see the improvement. ―Mandruss☎ IMO. 18:33, 9 June 2025 (UTC)[reply]
The colours would have an independent meaning easier to intuit. That being said, the change to two colours with higher contrast helps in creating visual diagonal bands, also tying the same precision levels together across rows. isaacl (talk) 21:42, 9 June 2025 (UTC)[reply]
That's less confusing in one way, but I only know that the colours are there to distinguish the different precisions. This needs to be noted in the key to the table. Thryduulf (talk) 20:17, 9 June 2025 (UTC)[reply]
I was about to say that we also need to avoid putting "meaning" into coordinates where the meaning is known only to Wikipedia editors. Then I realized that's exactly what we're doing with any kind of variable coordinates precision. How many readers will find and read this discussion, COORDPREC, or any other guideline, do you think? One has to wonder who's benefiting, and how. Is coordinates precision just a fun exercise for Wikipedia editors who like numbers? Is it a case of the aforementioned over-engineering? Should we sack OPCOORD and COORDPREC in favor of some fixed precision, in a rare simplification of Wikipedia editing? Perhaps coordinates need re-imagining, but that's a different discussion (scope expansion bad). Or, perhaps this is an appropriate place for that discussion; I see comments below moving in that direction.In my opinion, it's about time for a new subsection containing a specific proposal for standard precision (both decimal and dms). I'm not inclined to create one, but I would !vote in it. ―Mandruss☎ IMO. 01:29, 9 June 2025 (UTC)[reply]
Thanks for watching my thinking evolve in real time. I hate it when that happens. I should throw it all away and start over with a clean sheet of paper, but I'm damned if I'm going to discard the product of all the effort I put into it. Sue me. :D And, if standard precision fails, COORDPREC is my fallback position. ―Mandruss☎ IMO. 13:01, 9 June 2025 (UTC)[reply]
The OP's suggestion is good. I don't think we have anything on Wikipedia that warrants precision to less than 20 centimetres, so a bot could easily truncate to 6 decimal places. Articles where lower precision is needed (such as cities or countries) can be taken care of manually. Let's not let the best be the enemy of the good. Phil Bridger (talk) 21:44, 6 June 2025 (UTC)[reply]
If we have a reliable source that cites the coordinates to greater precision than that we should keep them. I sort-of remember Geni mentioning that this is the case for some museum exhibits. Thryduulf (talk) 23:11, 6 June 2025 (UTC)[reply]
Wikivoyage imports ("copies", not "dynamically transcludes") coordinate data from Wikidata when it's available. Wikidata stores the lat/long data as degrees/hours/minutes (12° 3' 45"). Wikivoyage uses the decimal format (12.345). One result of the automated conversion is that I've seen a few that look like "12.34500001". This is false precision. WhatamIdoing (talk) 00:13, 7 June 2025 (UTC)[reply]
There must be articles on smaller objects, but I don't know that latitude and longitude would be appropriate. Are there any articles on individual electrons? I guess not, because they are indistinguishable particles, but we can work up from there. Phil Bridger (talk) 08:32, 7 June 2025 (UTC)[reply]
From my layman's knowledge of quantum mechanics I would say that they don't exist any more, having been destroyed by the process of detection. I may be wrong. Phil Bridger (talk) 19:48, 7 June 2025 (UTC)[reply]
I think that even with objects as small as the Strawn-Wagner Diamond, 20cm is likely close enough - unless we want to go around altering the coordinates every time the cabinet is dusted! Even then, 7 digits would put it within an inch. We don't need anything listed to 12 digits unless we start getting articles about specific atoms, and they vibrate so... that way lies madness. Grutness...wha?12:33, 7 June 2025 (UTC)[reply]
I agree, especially since most GPS systems are only reliable to a level of about 3 m/10 ft. More than four digits is dicey, and more than five is like reading a 19th century recipe, seeing that it calls for "one pat of butter", and weighing your butter out to the tenth of a gram. The resulting 4.7 grams of butter isn't a wrong answer, but "about five or so" would have been fine, too. WhatamIdoing (talk) 04:36, 9 June 2025 (UTC)[reply]
Also agreed.
Even if we assumed for the sake of argument that objects on museum display at this sort of size (or even slightly larger, such as the Ain Sakhri figurine or Aineta aryballos in the British Museum) can have their locations known with precision to the millimeter, and assuming for the sake of argument that their locations remain consistent to the millimeter over the medium-to-long term: how frequently do readers need to know the location of such an object more precisely than to the nearest foot?
Even if these coordinates were actually accurate to twelve decimal points I can't see any real downside to automatically truncating to six d.p.; given that we can be almost certain that they are not in fact that accurate there is at least some benefit in not conveying false precision with little to no downside that I can concieve of. Caeciliusinhorto-public (talk) 09:52, 13 June 2025 (UTC)[reply]
If you do not know why a source uses a given precision (regardless of what that precision is) then it is completely inappropriate to say that it is more or less precise than is necessary. Thryduulf (talk) 13:44, 17 June 2025 (UTC)[reply]
I can imagine the UGSS having good reasons and I don't think it's inappropriate to mention a couple of possibilities, but I'm not saying it's either more or less precise than necessary for their purposes or ours. NebY (talk) 13:56, 17 June 2025 (UTC)[reply]
Per my comments above, it does not serve readers to put "meaning" into coordinates when the meaning is known only to Wikipedia editors. That is useless to readers unless they find, read, and understand the applicable Wikipedia guideline(s). It does, however, cost a lot of editor time in determining appropriate precision and discussing how to do so.
Ultimately, coordinates simply provide a way to position a location pointer in a mapping facility such as Google Maps. Mapping facilities do not currently have any way to show the size of the object based on the coordinates precision.
I propose "standard precision" of d° m' s.s" (dms) and d.ddddd° (decimal)d° m' s.ss" (dms) and d.dddddd° (decimal). Per WP:COORDPREC, these precisions would work for objects as small as around ten meters. For even smaller objects, they would place the map pointer within perhaps five meters of the object centers one meter, which is easily close enough for the needs of Wikipedia readers.
As with any guideline, there would remain room for exceptions, though I can't think of an exception that wouldn't ascribe "hidden" meaning known only to Wikipedia editors. editors. Well, here's one: We might use a smaller (shorter) precision when space is greatly constrained.
A bot could be created to convert coordinates to standard precision, but that's a separate and independent question. ―Mandruss☎ IMO. 13:27, 17 June 2025 (UTC) Edited after early discussion, tweaking the proposal. 04:40, 19 June 2025 (UTC)[reply]
Oppose as a blanket rule. We should not be using a different precision to that found in reliable sources, which can be more accurate than those obtained from online mapping sources. Whether the precision given in the source is accurate to that level of precision and/or appropriate to the relevant object is something that can only be determined in the context of both source and article so is completely inappropriate for a high-level guideline. Thryduulf (talk) 13:43, 17 June 2025 (UTC)[reply]
We would be free to take coordinates from a reliable source and adjust the precision to our standard. Many sources, including GNIS IIRC, use the same arbitrary precision for everything. Thus, they don't ascribe meaning and neither should we. ―Mandruss☎ IMO. 13:54, 17 June 2025 (UTC)[reply]
However many sources do use different precisions with meaning, and it would be inappropriate for us to differ from that. My objection is not to removing excessive precision where justified, it is to the blanket treating of all precision greater than d° m' s.s" or d.ddddd° as excessive. If there is a valid reason to differ from a reliable source, that needs to be explained in the context of both the article and the source, regardless of how or why we are differing. Thryduulf (talk) 14:01, 17 June 2025 (UTC)[reply]
But you're still ascribing hidden meaning. As with any Wikipedia editing, focus should be solely on reader benefit. Few readers are going to guess that greater precision means smaller object. Few readers will notice the differences at all; those few will very likely assume it's a matter of editors' personal preferences. ―Mandruss☎ IMO. 14:09, 17 June 2025 (UTC)[reply]
No I'm not ascribing hidden meaning, I'm accurately reflecting the meaning used by the reliable source I'm using to verify the content. Anything else would be applying my own interpretation not accurately reflecting the reliable source. If there is a good reason to do that, and it's plausible there might be, then I need to be able to explain that in the context of both the article and the source - it is entirely inappropriate to do that at a higher level. Thryduulf (talk) 14:14, 17 June 2025 (UTC)[reply]
Yes, you are ascribing hidden meaning; you're simply taking the source's hidden meaning and plugging it into Wikipedia articles. Precision adjustment does not violate WP:V any more than style changes. It would violate V if we modified the coordinates in a way other than precision. ―Mandruss☎ IMO. 14:24, 17 June 2025 (UTC)[reply]
You assume that every source has "hidden meaning", which is simply not true. Everything else you say follows on from that fallacy. Thryduulf (talk) 16:47, 17 June 2025 (UTC)[reply]
I think we already agreed that GNIS uses the same precision for everything. That means no hidden meaning, so I'm hardly assuming that every source has it. Maybe you could restate your comment in a way that says what you mean to say. ―Mandruss☎ IMO. 18:18, 17 June 2025 (UTC)[reply]
Oppose as blanket rule. 10 meters will easily distinguish between two office buildings. It wouldn't distinguish between two notable sculptures in a park. My rule-of-thumb for precision is "if you change the last digit one up or down and you're still on the object, and you change the next-to-last and you leave the object, you're set." I think I "violated" that rule once for the UMaine Campus, where three directions left it on, and the fourth moved just outside, but close enough so that you could see it. --SarekOfVulcan (talk)14:05, 17 June 2025 (UTC)[reply]
10 meters will easily distinguish between two office buildings. In that case, up the standard precisions one level, increasing the precisions by a factor of 10. Same concept, but your objection now addressed. Would one meter not be close enough for our readers' needs? ―Mandruss☎ IMO. 14:11, 17 June 2025 (UTC)[reply]
Oppose Anything unreasonable can be edited out. My main reason is wp:creep. But also the "can locate" rationale is not a good one to make the decision on. An extra digit beyond the known precision minimizes unnecessary contribution of an error to the number by the display/rounding process. North8000 (talk) 15:37, 17 June 2025 (UTC)[reply]
CREEP?? This would delete both WP:OPCOORD and WP:COORDPREC and replace them with one sentence: "Generally, Wikipedia articles use a standard precision of [x] (dms format) or [y] (decimal format)." I believe that's the opposite of CREEP. ―Mandruss☎ IMO. 16:17, 17 June 2025 (UTC)[reply]
The precision guidelines also say in one sentence: "A general rule is to give precisions approximately one-tenth the size of the object, unless there is a clear reason for additional precision." I don't see anything else that would be deleted except that sentence. Dege31 (talk) 17:58, 17 June 2025 (UTC)[reply]
The entirety of OPCOORD and COORDPREC, which are all about how to vary precision, which is what the proposed change would eliminate. The whole point is that precision need not and should not be varied. It's a simple cost vs benefit analysis, giving equal thought to both sides of the weight scale. ―Mandruss☎ IMO. 18:23, 17 June 2025 (UTC)[reply]
The whole point is that precision need not and should not be varied I fundamentally disagree with this. Appropriate precision is a combination of scale of the object and precision available in reliable sources - one size does not and can not fit all uses. Thryduulf (talk) 18:29, 17 June 2025 (UTC)[reply]
Even saying the words fit all uses shows that you still haven't grasped the "hidden meaning" concept (speaking of "fallacy"). Please confront my point directly, show me the error of my ways. Explain how readers can divine any meaning that is described nowhere readily accessible to them. We are writing this encyclopedia for readers, not for ourselves—something too often forgotten. ―Mandruss☎ IMO. 18:38, 17 June 2025 (UTC)[reply]
I don't know how to explain to you any differently than the multiple ways I've explained things already, so I'll leave it up to someone else to try. Thryduulf (talk) 18:42, 17 June 2025 (UTC)[reply]
As a bystander so far, may I suggest that saying you still haven't grasped the "hidden meaning" concept doesn't really work? "Hidden meaning" is a phrase you've introduced and it doesn't seem that anyone else finds it powerful or perhaps even understands quite what your point is and why you think it so powerful. Myself, I think of the rounding of other quantities (e.g. distances, money) which we do quite casually with some sort of proportionality, and the only "hidden meaning" I can imagine would be the implication that if we don't round the cents and millimetres, they're important. Which is probably not your point. NebY (talk) 19:05, 17 June 2025 (UTC)[reply]
Yes, I coined a phrase for efficiency of communication. Shame on me?"Hidden meaning" is when meaning is known only to Wikipedia editors. One meaning known only to Wikipedia editors: Greater precision signifies smaller object. I'm somewhat patiently awaiting refutation of my point. ―Mandruss☎ IMO. 19:29, 17 June 2025 (UTC)[reply]
OK, thanks. "Greater precision signifies smaller X" seems to me to be a corollary of rounding appropriately, and one to which that most readers will be fully accustomed, even if as writers they don't confidently apply all the rules of significant figures. It would be bad communication to go against that and start writing $12,345,000.01 or 15.0001 km if we didn't want to suggest rather strongly that the smallest parts were significant. Or to use "hidden meaning", it would be bad communication to always use the same precision with a "hidden meaning" or footnote that "the precision with which we state values does not imply that the precision has any significance". NebY (talk) 20:02, 17 June 2025 (UTC)[reply]
start writing $12,345,000.01 or 15.0001 km - False comparison, IMO. Coordinates differ in function: they generate a map pointer that looks the same for all precisions (among a few other, less-commonly-used functions). This is the only meaning available to readers, and it needs no explanation (assuming a new reader isn't afraid to click on a coordinates link just once, just to see what happens; some ability and willingness to explore is assumed). You click on a coordinates pair and you are presented with a "menu" of things we can do with it. The main one is to produce a map with a pointer. ―Mandruss☎ IMO. 21:57, 17 June 2025 (UTC)[reply]
Producing a map pointer might be the most prominent way Wikipedia uses coordinates at present. We can't assume it's all that readers use coordinates for, and you write that Wikipedia uses them for a few other, less-commonly-used functions. We shouldn't provide data that's apparently more precise than our sources to readers who will be unaware of that and who may be using the data in ways of which we are unaware, or present anyone within Wikipedia working on those "less-commonly-used functions" or any future ones with falsely precise data. Still, thanks for the clarifications, not least the statement below. NebY (talk) 18:10, 18 June 2025 (UTC)[reply]
To be clear, if a source gives us four decimal positions, I have no problem with appending zeroes to extend it to six dp's. Again, that would matter only to Wikipedia editors, and only some of them. I also have no problem with rounding eight positions to six. I note that the "What's here" function of Google Maps provides six dp's.This ain't a perfect solution, but none exists; any pursuit of perfection is a wild goose chase in this case. It's merely better than any alternative, all things fairly considered. Editors here appear to be looking at only one side of the cost-benefit equation. ―Mandruss☎ IMO. 22:13, 17 June 2025 (UTC)[reply]
If that is Madruss' point, then to put my argument in the same terms cents and millimetres are sometimes important so a guideline saying that we should always round to the nearest metre or nearest dollar is inappropriate. Thryduulf (talk) 19:12, 17 June 2025 (UTC)[reply]
I said wp:creep because it creates a new guideline which is to a partial extent a new rule. (I mentioned this in combination with in essence saying that it's not really needed). Your response asserted that it is not creep because it might replace lengthier ideas at a wikiproject. A wikiproject is not a guideline or policy so it's still creating a new guideline. Sincerely, North8000 (talk) 18:44, 18 June 2025 (UTC)[reply]
A distinction without a difference, in my opinion. WP:OPCOORD and WP:COORDPREC may not be guidelines, strictly speaking, but they are sure being used like guidelines (I did so often for years). What do you suppose the shortcuts are for? Instinctively wanting site-wide coherence, editors seek guidance and we'll take it where we can get it. We're not overly concerned about organizational boundaries. We don't really care what the guidance is, as long as it has community consensus. If we have strong feelings against the community consensus, we may challenge it; until the challenge is successful, we comply with the existing guidance. Such centralized guidance is the only way to get most editors on the same page, and therefore the only path to site-wide coherence. Ergo, the CREEP principle also encompasses OPCOORD and COORDPREC.CREEP applies when the added site-wide coherence is not worth the cost in space and complexity. ―Mandruss☎ IMO. 04:59, 19 June 2025 (UTC)[reply]
Comment I ask the proposer, and supporters, to explain how this is superior to the WikiProject Geographical coordinates suggestion. Why not make that the guideline? Dege31 (talk) 18:00, 17 June 2025 (UTC)[reply]
Oppose this removal of proportionality and its replacement with false precision unsupported by sources, to the confusion and frustration of readers and editors using our content in ways not considered at the time of this proposal (or considered and dismissed). NebY (talk) 18:18, 18 June 2025 (UTC)[reply]
opposeI work with two classes of subjects (lighthouses and towns) and I use the precision provided by the sources. For the lighthouses this is down to thousands of seconds; for the towns GNIS gives only seconds, which even then is questionably precise in practice. I see no reason to override those values, and the one standard is not appropriate to the other circumstance. The light of a lighthouse is on the order of less than a meter in size; even the smallest town is a hundred times less precisely located. I would agree that it is reasonable to put some sort of a limit on precision, but context matters here and the best we can say overall is that when you get down to the centimeter level, you're talking about locations for which continental drift is a factor even in the short term, so we probably shouldn't go that low. But a uniform standard precision for all sorts of locations is a bad idea, particularly since few things or places we can locate to the pricision of a navigational aid.Mangoe (talk) 19:11, 18 June 2025 (UTC)[reply]
English Wikipedia doesn't specify a specific font to be used for article text. It just uses the one configured in your browser for sans-serif text, so you can change your browser to use a different sans-serif font. isaacl (talk) 21:59, 6 June 2025 (UTC)[reply]
Note that you can even set your browser to use a serif font in situations where the site calls for a sans serif one. I've got mine set to use Times New Roman in all situations. --User:Khajidha (talk) (contributions) 13:09, 9 June 2025 (UTC)[reply]
"Important, do not remove this line before article has been created."
Not sure where to post this so posting here. I'd like to request an exception to WP:COSMETICBOT to remove 250ish hidden HTML comments (<!-- Important, do not remove this line before article has been created. -->) from mainspace articles. List of articles. This HTML comment is usually left over from the draft process and can be removed. I did some spot checks and found a couple articles that were never drafts that had this, such as Battle of Jahra and Supreme Constitutional Court (Egypt), so I am not sure how the comment got in there. Maybe someone cut and paste moved it from draftspace. Anyway, thoughts? Is this OK to clean up with WP:AWB? –Novem Linguae (talk) 07:00, 16 June 2025 (UTC)[reply]
The former certainly seems like something that could be added to general fixes without an issue, the second would need to be supervised as it's plausible that it is there for a reason in some cases. In both instances though, I would oppose making the edit in the absence of other changes to the article unless it is causing some actual layout issue/problems for screen readers. Thryduulf (talk) 10:37, 16 June 2025 (UTC)[reply]
Agreed, I had looked at before but decided it was also very common for non AfC left over issues. Possibly it would be OK to remove if it was on a line with nothing other that white-space. KylieTastic (talk) 12:10, 16 June 2025 (UTC)[reply]
Personally I'd be fine with this. For just 250 articles it won't create any watchlist spam, and a full unneeded HTML comment is a more significant nuisance than most cosmetic edits. Sdkbtalk17:14, 16 June 2025 (UTC)[reply]
I started to fix some of them as I found ones that needed extra clean up and have ended up finishing the lot while chilling to some tunes. So job done. KylieTastic (talk) 22:40, 16 June 2025 (UTC)[reply]
For topics which may not yet meet Wikipedia's inclusion criteria for articles, but for which relevant information is present across multiple articles (such that an editor may have difficulty deciding which page to redirect to), there should be a type of mainspace page dedicated to listing articles in which readers can find information on a given topic. A page of that type would be distinct from a disambiguation page in that, while disambig pages list different topics that share the same name, a navigation page (or navpage) would include a list of articles or sections that all contain information on the exact same topic. In situations where a non-notable topic is covered in more than one article, and readers wish to find information on that particular topic, and that topic can't be confused with anything else (making disambiguation unnecessary), and there turns out to be two or more equally sensible redirect targets for their search terms, then a navpage may be helpful.
Rough example #1
Wikipedia does not have an article on the Nick Fuentes, Donald Trump, and Kanye West meeting, but you can read about this topic in the following articles:
This navigation page lists articles containing information on Nick Fuentes, Donald Trump, and Kanye West meeting.
If an internal link led you here, you may wish to change the link to point directly to the intended page.
Rough example #2
Wikipedia does not have an article on Anti-Bangladesh disinformation in India, but you can read about this topic in the following articles:
This navigation page lists articles containing information on Anti-Bangladesh disinformation in India.
If an internal link led you here, you may wish to change the link to point directly to the intended page.
I also agree! I'm thinking some disambiguation pages tagged with {{R with possibilities}} could make good navigation pages, alongside the WP:XY cases mentioned above. At the same time, we should be careful to not have any "X or Y" be a navigation page pointing to X and Y – it could be useful to limit ourselves to pages discussing the aspects together. Chaotic Enby (talk · contribs) 13:26, 18 March 2025 (UTC)[reply]
Good idea – people seeing the nav page and how it is split across more than one article could also help drive creation of broad-topic articles. Cremastra (talk) 23:40, 18 March 2025 (UTC)[reply]
Also noting that the small text If an internal link led you here, you may wish to change the link to point directly to the intended page. might not necessarily be needed, as it can make sense to link to navigation pages so readers can have an overview of the coverage, and since that page might be the target of a future broad-topic article. Chaotic Enby (talk · contribs) 23:50, 18 March 2025 (UTC)[reply]
This seems a useful idea. As a similar example I'd like to offer Turtle Islands Heritage Protected Area, which I created as an odd disambiguation page because it was a term people might search, but with little to say that wouldn't CFORK with content that would easily fit within both or either or the existing articles. CMD (talk) 01:32, 19 March 2025 (UTC)[reply]
This is great. I often edit articles related to PLAN ships, and since many ships currently lack articles, we cannot use disambiguation pages for those ships(e.g. Chinese ship Huaibei, which has two different frigates with the same name). This could really help out a lot. Thehistorianisaac (talk) 03:33, 21 March 2025 (UTC)[reply]
Throwing my support behind this as well. It would be very useful in cases where AFD discussions find consensus to merge the contents of an article into multiple other articles. -insert valid name here- (talk) 05:01, 3 April 2025 (UTC)[reply]
Done for both! About the technical aspect of things, I added the "you can also search..." in the template (as it could be practical) but it might look less than aesthetic below a "See also" section. I made it into an optional opt-in parameter, is that fine? Chaotic Enby (talk · contribs) 07:34, 14 April 2025 (UTC)[reply]
If this sort of page type is to be used for topics without independent notability (including deleted through an AfD), perhaps it should just drop that part and simply say "You can read about the Nick Fuentes, Donald Trump, and Kanye West meeting in the following articles"? Those with the potential to be expanded could be integrated into the hidden Template:R with possibilities system or something similar. CMD (talk) 08:50, 14 April 2025 (UTC)[reply]
I already added a parameter for that part (on the Fuentes-Trump-West meeting, the link inviting to create the article is not present). But yeah, removing it entirely as an optional parameter could also make sense. Chaotic Enby (talk · contribs) 08:53, 14 April 2025 (UTC)[reply]
Also thinking about the Poor people's rights search below, removal seems best. Alternatively, flipping it so that it is the prompt to create a page that is the optional addition might provide the desired goal while erring on the side of not encouraging creating poorly scoped articles. CMD (talk) 01:49, 15 April 2025 (UTC)[reply]
Also, once that is all done, we should probably update {{Dmbox}} so navpages are a parameter, to avoid them being automatically detected as disambiguations (although that's not really that big of a deal). Chaotic Enby (talk · contribs) 16:15, 15 April 2025 (UTC)[reply]
I think we should decide early on, should this be allowed to have some context or info like WP:SIA? Maybe some content, which not enough for notability (the reason why it's not an article)? ~/Bunnypranav:<ping>12:04, 15 April 2025 (UTC)[reply]
I was initially keen on this idea, but after thinking a bit more and reading this discussion, I have to say I'm opposed to it. Either write a stub or stick to the search function. Cremastratalk19:36, 7 May 2025 (UTC)[reply]
I also have some concerns about navigation pages. They do indeed seem like they could require a lot of maintenance (especially if they are linking to sections. renaming a heading would break the links). It also seems like this could encourage fragmentation. Perhaps the better approach would be to pick one spot for something like Nick Fuentes, Donald Trump, and Kanye West meeting (pick a section in one of the articles), and redirect to that. Perhaps {{Navigation page}} might need to go to TFD to have a wider discussion to determine if it has consensus. –Novem Linguae (talk) 18:53, 18 April 2025 (UTC)[reply]
I am also unconvinced this is a good direction of travel. The article on the meeting of these three men was deleted; if we think this is a worthy article title, shouldn't we just have the article? There is a longstanding tradition at WP:RFD to delete ambiguous redirects and to rely on our search function instead, see WP:XY. Do we really want to have "navigation pages" for every single sports rivalry (mentioned in articles about both teams), relations between countries that do not suffice for a separate article? Amari McCoy is just bad: it is a bluelink that should be a redlink to show we do not have an article, and it is impeding the search function. If an article could potentially be created, a "navigation page" will impede actual article creation and (in the future) deny the creation credit (and the relevant notifications) to the actual article creator. —Kusma (talk) 19:17, 18 April 2025 (UTC)[reply]
I would be okay with this one being deleted, as it doesn't actually contribute to navigation in any useful way (none of the target articles do more than list her as one of many actors). However, I mildly disagree with your point about article credit, as it isn't meaningfully different from the current situation with redirects. More generally, I do believe that navigation pages could be useful in a specific case (where there is a substantial amount of information about the same topic on several pages), but that they shouldn't abused to link to every single page that namechecks a subject. Chaotic Enby (talk · contribs) 23:14, 18 April 2025 (UTC)[reply]
I think we agree on the point that creating a redirect/navpage shouldn't give you creation credit. But that alone doesn't mean the page type shouldn't be kept, otherwise one could argue that redirects should be deleted for the same reason. Since navpages are functionally intended as multi-redirects, I believe the analogy especially makes sense. Chaotic Enby (talk · contribs) 23:25, 18 April 2025 (UTC)[reply]
I also agree. Even though I created The Book of Bill as a redirect, it was Googabbagabba who ultimately filled it with meaningful article content and thus the one who should've been notified when the article was linked with a Wikidata entry. Nonetheless, I don't think "another editor wants to create an article under this title" would be considered valid rationale for deleting a redirect or navpage. – MrPersonHumanGuy (talk) 00:16, 19 April 2025 (UTC)[reply]
I'd also seen Goldie (TV series) and think it looks like an unholy amalgam of a stub article and a navigation page: it should be one thing or the other, not both. I suppose my principal concern is that permitting adequately-sourced and verifiable content about an otherwise non-notable subject in a legitimate navpage is effectively quite a backdoor to a Wikipedia article about a non-notable subject. Cheers, SunloungerFrog (talk) 20:12, 18 April 2025 (UTC)[reply]
The Goldie page is ridiculous; it should just be a stub. I think navpages have a very specific application: a topic that for whatever policy-based reason does not belong in mainspace as a standalone page but is discussed in multiple pages. I would oppose them having any references or additional formatting at all. It should basically a multiple-choice redirect. Dclemens1971 (talk) 20:44, 18 April 2025 (UTC)[reply]
I didn't really expect this to go anywhere so I'll now elaborate on "This is a cool idea!". I think these pages can fill a narrow but present gap in our page ecosystem. Essentially, topics where there is more than one possible redirect target about the same subject, which distinguishes them from DABs, which have more than one possible redirect target about different subjects.
Also, since it's relevant to this discussion, I closed an AfD as "Navify" earlier today – feedback from others on the close and the resulting nav page (Armand Biniakounou) would be appreciated. I thought nav pages had been fully approved by the community, but I was clearly mistaken – if I had known that this is still being discussed, I may have closed this AfD differently or not at all. Toadspike[Talk]00:07, 19 April 2025 (UTC)[reply]
I also misjudged consensus the same way, and that caused me to get carried away until I checked this page again and learned that not everyone was on board with the whole navpage idea, at which point I decided to pull the brakes and stop creating any more navpages. As for Amari McCoy, the fact that two stubs were being suggested for navification was what gave me enough guts to create that navpage in the first place. My reasoning was that "If these athletes can get navpages even though other articles only mention them as entries in lists, then that logic can be applied to other topics as well." In hindsight, that may not have been such a good idea after all. – MrPersonHumanGuy (talk) 01:06, 19 April 2025 (UTC)[reply]
I think your approach was reasonable. Sometimes you need to ramp up a bit to get wider community feedback. I didn't make a decision about this idea until I saw some actual articles with the template. Anyway thank you for stopping now that this is becoming a bit more controversial. –Novem Linguae (talk) 01:13, 19 April 2025 (UTC)[reply]
I think the gun was kind of jumped with this, though the topic was posted one month ago. Some more voices weighing in on this would likely be helpful. --Schützenpanzer(Talk)00:15, 19 April 2025 (UTC)[reply]
Chaotic Enby mentioned something above about namedropping a subject, which seems to be similar to something I've been mulling over, and trying to decide how to formulate my concern. Let me start by turning your attention to the issue of WP:NOTTRIVIA just for a moment. I know there are lots of editors who love to dig up every place their fave character was ever mentioned, and there are folks on all sides of the question of sections like "FOO in popular culture". I remember how discouraged I was when I found that the relatively short article on a medieval French poet was about 50% allusions to modern popular culture items which in my view contributed nothing to an understanding of the poet. When you have a good search engine, it becomes trivial to dig up obscure allusions of this type, and so people do.
Transfer that thought now to the nav page concept. At first blush, it kind of seems like a good idea, but how might it morph in the future, and are we maybe opening Pandora's box? Suppose the good guys all do it the right way for a while, and then enthusiastic new editors or SPAs or Refspammers or social media types get wind, and all of a sudden it explodes in popularity and these pages become heavy with idiosyncratic additions based on somebody's fave niche reference? Will we end up needing new guidelines to specify what is or isn't a proper entry? Are we setting ourselves up for a possible giant future maintenance burden for regular editors? Mathglot (talk) 00:53, 19 April 2025 (UTC)[reply]
That is indeed a very good point, and this is why we should, in my opinion, have these guidelines ready before having navpages deployed on a large scale. While every new article or page can be seen as a "maintenance burden", navpages should fill a very small niche: subjects where in-depth content can be found on several pages, but which do not fit the notability guideline by themselves. This should be a much stronger criterion than simple mentions, and likely only apply to borderline cases where notability isn't very far away. Chaotic Enby (talk · contribs) 10:51, 19 April 2025 (UTC)[reply]
Do you have a single example of a subject where we should really have such a navigation page? Everything we have above is "mentions" (we certainly shouldn't allow those, or we will soon have thousands of genealogy stubs on non-notable minor nobility disguised as "navigation"), with the longest discussions being those of the "meeting" above, which are a short paragraph each and fairly repetitive with little critical commentary. If that is the best use case for the concept, I think the negatives strongly outweigh the positives for this idea. —Kusma (talk) 11:36, 19 April 2025 (UTC)[reply]
It was a better situation for Ethiopia in World War II, which probably could be an article, but in the meantime the various links would have been very helpful to readers. Now it is a redirect to an article subsection covering a time period mostly before WWII that also does not cover most of WWII. CMD (talk) 12:49, 19 April 2025 (UTC)[reply]
The classic solution "just write a stub" still looks superior to having a "navigational" pseudo-article to me in that case. —Kusma (talk) 13:07, 19 April 2025 (UTC)[reply]
I agree that the navigation page at Ethiopia in World War II was much more helpful than the current redirect, and I'm not sure what benefit a stub would bring given that we have existing coverage of the topic in multiple places already. Thryduulf (talk) 13:57, 19 April 2025 (UTC)[reply]
@Kusma Do you think the navpage (Armand Biniakounou) resulting from the AfD I linked is a good use? The two articles it links to don't have in-depth content, but there were two equally-good redirect targets and a consensus to redirect. Toadspike[Talk]16:17, 19 April 2025 (UTC)[reply]
I think that is terrible. The bluelink promises we have nontrivial information, but there is only a trivial mention in a table. This is what fulltext search is made for. —Kusma (talk) 19:27, 19 April 2025 (UTC)[reply]
Very true. But – and I'm trying to understand the entirety of your argument, not be contrarian – the alternative is a redirect to one of the two bluelinks. This would equally promise nontrivial information, except it only provides half of the information we have.
Speaking not from a Wikipedian's perspective but a reader's perspective, I would be annoyed by that article. The formatting's a bit weird, and it's trying to tell me that it's not an article, but I can see very clearly with my own two eyes that it's just a short article that tells me this man has been in the Olympics, twice. Despite the promise in the template, clicking on those links does not give me any additional information about him. Also, there's a bunch of unsourced biographical details in the categories? My reader self doesn't understand why those aren't in the article. Additionally, I can only see those facts in desktop view, so if I send the article to my friend to tell them that Wikipedia says this sprinter was born in 1961, they're going to be very confused. On a related note, I think understand ATDs in an abstract way, but it's very annoying when you're a reader, you're trying to look something up, you know Wikipedia used to have an article about the subject, but now you find yourself on a nearly unrelated page that doesn't seem to mention the topic at all? Or, if it does, only very briefly as one entry in a table? It's very frustrating and I don't like it. GreenLipstickLesbian💌🦋20:06, 19 April 2025 (UTC)[reply]
I understand all your points. The issue is that this case ties into the broader debate over sports stubs and new sigcov requirement of WP:SPORTCRIT – we have a bunch of verifiable information about this guy (and thousands of athletes like him) but they are not notable. What we should do with them instead is a huge can of worms. If you and Kusma believe articles like this should be deleted instead of redirected or navified, we're gonna need an RfC.
To avoid redirection in general? Yes, that's a something even I'm not masochistic enough to deal with (though I will take any opportunity to remind people that we have a fairly functionable search bar for mentions and draftspace/userspace to preserve the history of poorly-sourced but potentially notable articles). To avoid navigation? This produced, again, an unsourced perma stub about a living person. Without sources, we actually don't even know if this is the same person. Sure, the external sources listed in the AfD (that I'm not allowed to put in the stub, aren't present in either of the articles?) seem to confirm that, and his name is unique enough, but we already have enough of an issue with editors accidentally mixing up people just because they have the same name. GreenLipstickLesbian💌🦋00:14, 23 April 2025 (UTC)[reply]
Subjects which are more akin to an index of possible articles with content relating to the subject (the old version of Ethiopia in World War II, the example in the original comment about Anti-Bangladesh disinformation in India)
It seems like there's more pushback to the fourth category than the first three. The third might be a bit too broad of a category that could be split up; I like the Ethiopia page as a navpage a lot more than the anti-Bangladesh disinformation page. The fourth category seems like a bad use of navpages, just because it leads readers to places that have little or no more information about the subject than the navpage itself. The first two seem to have the most potential. Skarmory(talk •contribs)00:03, 22 April 2025 (UTC)[reply]
I generally agree with that classification, although I'm not sure "subtopic" is quite the right word for 2 and the line between 2 and 3 seems blurry, with the only difference I can immediately see being 2 has a title that is a proper noun which gives it a firm scope, while 3 has a descriptive title and thus a more fuzzy scope. Is that a useful distinction to make? I'm not sure.
One thought that has just occurred to me with 4 is that this would be used to create pages that are just a list of notable sports teams this player we don't have an article about played for (either because they aren't notable or because nobody has written one yet). I can see arguments both ways about whether such a page is encyclopaedic, but it isn't a navigation page in the same way that 1-3 are. So I think we should come up with a different name for that sort of page and discuss separately whether we want them or not. This does leave open how to determine an appropriate amount of content about a is enough to make it a navigation page, and my thinking is that we want a rule of thumb rather than a hard limit, perhaps "at least a few sentences, ideally a paragraph". Thryduulf (talk) 00:20, 22 April 2025 (UTC)[reply]
I would agree that a few sentences or a paragraph in two separate articles is probably a good bar for navpages, though they probably should also be different sentences and not the same text copied between articles (might be hard to police, but the reader gets no new information on the target by visiting both pages).
I think category 3 is the fuzziest one. I can see the argument for including category 2 in it, but my sense is that category 3 is already broader than I'd like, and I see a distinction there. I would say Ethiopia in World War II (as a redirect) would be more of a {{R from subtopic}}, not a redirect to a subtopic, so it'd be more likely to merge with category 1; the Anti-Bangladesh disinformation in India example is something I wanted to call a broad-concept page, but the definition didn't quite fit, and it's not really a clear subtopic or supertopic of anything (maybe {{R from related topic}} if used as a redirect to any of those?). Meanwhile, the Turtle Islands Heritage Protected Area is clearly a topic that contains both Turtle Islands National Park and Turtle Islands Wildlife Sanctuary; I'd call it a supertopic, but the redirect category is named R to subtopic, so that's what I went with.
I don't get the sense that consensus would like a separate type of page for category 4, though I personally could be swayed either way on it. I do agree that it shouldn't be what we're making navpages. Skarmory(talk •contribs)08:45, 22 April 2025 (UTC)[reply]
I like this precision, but I worry this whole concept of nav pages is too complex for little benefit. We would have to teach a lot of folks these 4 rules (npps, autopatrollers, wiki project disambig, gnomes) and this has a cost. –Novem Linguae (talk) 00:37, 22 April 2025 (UTC)[reply]
Obviously I don't speak for those groups, but I'm in three of them and I think the idea is definitely worth considering even with the editor hours it'd take to teach editors. It's not that different from the idea of a disambiguation page or a set-index article, and it will be helpful to readers if done right. Skarmory(talk •contribs)08:49, 22 April 2025 (UTC)[reply]
I don't see how this function could really be useful: it breaks our search function by directing readers to these short, useless articles. And I think they should be considered articles: Amari McCoy and Armand Biniakounou both list the name, vocation, and biographical details about a real person, but would otherwise be rejected as citation-free BLP stubs in AfC or NPP. I fully agree with GreenLipstickLesbian's comments above about the latter article. I worry that this opens the door for a million new context-free stubs for every name we list in the encyclopedia, breaking the hypertext-based structure of linking people's names when they become notable. Search would be totally broken if typing a given name like "John" into the search box returned a list of hundreds of non-notable people in the suggestions just because they'd been listed somewhere and thus got a navigation page. Dan Leonard (talk • contribs)12:32, 22 April 2025 (UTC)[reply]
I agree that John would make a terrible navigation page, and lists of places a person is trivially mentioned is not a navigation page per my comments above. Please don't be tempted to throw the baby out with the bathwater. Thryduulf (talk) 12:44, 22 April 2025 (UTC)[reply]
My point wasn't about a page called John, it was the issue of the search box's automatic suggestion function. Currently, typing a partial name into the box helpfully prompts the reader with a list of all the notable people with similar names for whom we have actual articles. If we made navigation pages for hundreds of non-notable people like above, this search function would be cluttered with short navigation stubs instead of the notable people we have useful articles on. This proposal is intended to assist navigation, but I think it would do the exact opposite. Dan Leonard (talk • contribs)13:04, 22 April 2025 (UTC)[reply]
See above where we are dealing with this exact issue (Skarmory's type 4). We intend navigation pages to be used for instances of notable topics that are covered in at least some depth on multiple other articles. Lists of mentions of non-notable people are something qualitatively different - there are arguments for and against having such pages (and you have articulated some of them) but they are not navigation pages and their existence or otherwise should not be relevant to whether pages of Skamoary's types 1-3 should exist. Thryduulf (talk) 13:16, 22 April 2025 (UTC)[reply]
My point isn't that they shouldn't be discussed, but that objections to one type should be used as a reason to reject the whole concept, especially when discussion about them being separate is already happening. Thryduulf (talk) 13:42, 22 April 2025 (UTC)[reply]
These are reasonable concerns; when I saw the "navify" option come up at AfD I thought it was already a settled template that was intended to apply to non-notable topics that are mentioned on more than one page and so can't be redirected. If the discussion is instead leaning toward these being restricted to the kinds of intersections of notable topics described by Skarmory, then we probably should make that clearer to AfD. I agree that these navpages showing up in prompts the same way real articles do is not ideal. JoelleJay (talk) 16:52, 22 April 2025 (UTC)[reply]
This will massively overcomplicate everything for very little benefit except for straightening out a few odd ends that almost nobody who is not extremely into wikipedia-as-wikipedia cares about, for the price of possibly hundreds of thousands of useless or actively deleterious articles. We can barely get people to understand what a set index article is. #4 is especially problematic, #1 is also very bad, #2 & #3 probably harmless but extremely close to being SIAs so we don't need to invent a whole new thing for it. PARAKANYAA (talk) 22:38, 26 April 2025 (UTC)[reply]
Why is #1 bad? It leads our readers to content that doesn't have a full article but which does have content in multiple places, as opposed to having to select one target to redirect to. I would also disagree that #2 and #3 are any closer to being WP:SIAs than #1; these categories all fall into the same bucket of pointing you to pages that have content on the subject when we don't have an individual article for the subject, and they're not separate lists about subjects of a certain type with similar names (which is what a set index article is). Skarmory(talk •contribs)01:48, 27 April 2025 (UTC)[reply]
Well, and I'm probably going to say this much less eloquently that anybody else, but in this particular example, the content doesn't have a full article because Wikipedia editors at the time decided the sources did not demonstrate enough of a widespread, lasting impact to merit standalone coverage. In American politics - a topic area which is not suffering for lack of sources. If we can't demonstrate that this event had a lasting impact on anything, there's an a WP:NOTNEWS/WP:UNDUE/WP:10YEARTEST style argument that we probably shouldn't have anything more then a passing mention of the the subject in any article. (Verifiability doesn't guarantee inclusion, after all.) If the sourcing has changed, and now supports the idea that this event had a lasting impact on one particular subject, then we should create a section in the article about that in the subject's and redirect this page there, and maybe point to that section in the other, more tangentially-related articles. Similarly, if the sourcing has developed enough to show that this event had a lasting/significant impact on multiple subjects, then we should have a standalone article, not send the readers to like five different articles because the sourcing in 2022 wasn't good enough. I also agree with Parakanyaa that 3 is essentially a close cousin of a SIA, not in the sense that it's a list of similar things with similar names, but it's a list of similar things that readers will refer to with similar names. I disagree about 2, I think those are either permastubs we should accept as permastubs (and add sources), or stubs that should be expanded by merging the subtopics up into them. After all, if the Bombing of Hiroshima and the Bombing of Nagasaki can be covered in the same article, then there's no reason we can't cover two closely related parks together. (Or maybe redirect it to Transboundary protected area which currently contains the exact same links as the nav page, but with sources and more information.) GreenLipstickLesbian💌🦋02:13, 27 April 2025 (UTC)[reply]
That argument applies to Nick Fuentes, Donald Trump, and Kanye West meeting, but I'm not convinced it applies to every potential navpage which would fall under #1. Off the top of my head for another example, I think the redirect Mars Silvanus is another example of something that could be turned into a navpage, given both Mars (mythology)#Mars Silvanus and Silvanus (mythology) are reasonable targets (the former was picked as the redirect target at RFD); this is a subtopic of both which probably doesn't make sense as its own article, but it's sourced content that is relevant. There are probably more examples of similar RFDs where there's multiple potential targets and one just has to be picked.
I can see the argument on #3, but I think the general concept of a navpage is going to be a close cousin to an SIA in all four categories (admittedly, #3 does seem to be the closest category). I could see an argument for trying to meld navpages in with SIAs instead of making it its own separate page type, and I suppose there category #3 would be the easiest one to meld in. Skarmory(talk •contribs)04:08, 27 April 2025 (UTC)[reply]
Hatnotes are appropriate when either there is a single page that is clearly the most appropriate location for people to be redirected to and a short list of alternative pages people are plausibly but less likely looking for. Navigation pages are appropriate when there isn't an appropriate page because our coverage is split approximately equally across multiple different pages. Thryduulf (talk) 23:39, 1 May 2025 (UTC)[reply]
An example: topic A is covered in 9 articles. Per WP:SS, there's a broad-concept article about topic Z, of which A is a subtopic. The article on topic Z has a section on topic A. "A" redirects to Z#A. Z#A then has a sidebar containing links to the other 8 articles that have information on A.This is preferable to a "navigation page" because it immediately directs a reader to the highest-level overview of the topic. voorts (talk/contributions) 00:39, 2 May 2025 (UTC)[reply]
This covers cases like the old version of Ethiopia in World War II, but it doesn't cover something like Nick Fuentes, Donald Trump, and Kanye West meeting, which doesn't have a broad-concept article that it can target. It also wouldn't work well for category 4, but that seems to be getting no support as a navpage.
I will admit that I didn't think of hatnotes, which can work for some of these cases, but they don't work for all of them; any topic where there isn't a clear target is going to be somewhat awkward (Turtle Islands Heritage Protected Area), and the aforementioned case of a topic with lots of potential targets will be unviable. Skarmory(talk •contribs)00:48, 2 May 2025 (UTC)[reply]
The Fuentes-Trump-West meeting can also involve a redirect to an appropriate section and hatnotes as needed per GLL. None of our articles that cover the event are particularly good anyways. Directing readers to four meh sections isn't really helpful. Shouldn't the Turtle one just be a SIA? voorts (talk/contributions) 01:00, 2 May 2025 (UTC)[reply]
Ooh, that's interesting. It does somewhat suffer from the same issue as a redirect with a hatnote (which article do you actually target?), but it feels cleaner than hatnotes. The one problem I might have with it is that it's a footnote while not really being article content, but I'm not sure whether that's a big deal. Skarmory(talk •contribs)10:52, 2 May 2025 (UTC)[reply]
Help:Explanatory notes says: Explanatory or content notes are used to add explanations, comments or other additional information relating to the main content but would make the text too long or awkward to read, which is why I thought they're just the thing for the job. As to which article to target, in this case I really don't think it matters, as they're both linked together, but I arbitrarily chose the earliest competition. I imagine that a convention would soon arise, and if not the matter could be discussed at RfD. Cheers, SunloungerFrog (talk) 12:34, 2 May 2025 (UTC)[reply]
I think that works if the subject is only connected with one other event, as is the case here, but I'm not as certain if it would be as clean if we had more solely participation based information from multiple other events. Let'srun (talk) 13:58, 11 May 2025 (UTC)[reply]
I haven't researched the Turtle Islands. Maybe the park is primary over the preserve or vice versa. If a PTOPIC doesn't exist, the current page, which is a SIA, should remain as is. The Fuentes-Trump-West case can redirect to any of the four sections spread across articles, probably the one that is best developed at present (but, as I noted before, none of them are particularly good). voorts (talk/contributions) 01:45, 2 May 2025 (UTC)[reply]
That is great. For the Turtle Islands navpage, as a lazier alternative to GreenLipstickLesbian's actual content creation, I had thought about a redirect to Turtle_Islands_Wildlife_Sanctuary#Background because the first paragraph of that discusses the subject briefly, with a couple of sources (In 1996, the islands were declared as Turtle Islands Heritage Protected Area by the governments of the Philippines and Malaysia as the only way to guarantee the continued existence of the green sea turtles and their nesting sites). There is no equivalent paragraph in the Turtle Islands National Park article. Cheers, SunloungerFrog (talk) 05:06, 2 May 2025 (UTC)[reply]
That slightly less than 300 word paragraph cites eight journals, a book, and a website, so yes, I would expect it to meet GNG. Donald Albury15:12, 18 May 2025 (UTC)[reply]
Next steps
Looks like there's 7 pages in Category:Navigation pages. That's good that it's not growing. I think creation of these has mostly paused. I think the next step is for someone to create an RFC on whether navigation pages should be allowed to exist. I guess at WP:VPPR, or at Wikipedia talk:Navigation pages but with notification to many other pages. Does that sound reasonable? Depending on the outcome of that RFC, we can then decide on whether to start peppering navigation pages everywhere, or to turn these 7 existing ones into something else. Whoever creates the RFC should be someone who is pro-navigation page, and should do some work on Wikipedia:Navigation pages to make sure it accurately documents the navigation pages proposal, and that page can be where we have our description of exactly how navigation pages will work. –Novem Linguae (talk) 16:55, 22 April 2025 (UTC)[reply]
I don't think we're ready for an RFC yet as discussion is still ongoing about which of the four types of page outlined above should be considered navigation pages, and if it isn't all of them how to distinguish the type(s) we want from the type(s) we don't. Some discussion on formatting will likely be needed too. Going to an RfC prematurely will just result in confusion and !votes based on different things and different understandings. Thryduulf (talk) 17:44, 22 April 2025 (UTC)[reply]
Agreed. If we were to hold an RfC now, we should at least have separate discussions on each of the four types of navpages laid out by Skarmory, to be authorized or forbidden separately. Toadspike[Talk]17:57, 22 April 2025 (UTC)[reply]
Also agreeing – I would be in support of types 1 to 3, but opposed to type 4, which I believe is also the case for a lot of navpage proponents.There are also more technical issues we should consider before going for an all-or-nothing RfC. For instance, whether it would be technically possible to suppress or push down the appearance of navpages in search results (although having limited use cases like types 1 and 2 will likely make these much rarer than actual articles, and limit them to topics with actual content written about them somewhere). Chaotic Enby (talk · contribs) 18:22, 22 April 2025 (UTC)[reply]
Perhaps also a wording tweak to be more conservative. "There is currently no article" feels too encouraging, especially if the template might be used in the wrong locations (much as how Ethiopia in World War II is mischaracterized as an SIA). The closer these stay to disambiguation pages, which are firmly established, the clearer it will be that these are not articles. CMD (talk) 00:38, 23 April 2025 (UTC)[reply]
Noting that these should probably go to RfD rather than AfD. They are effectively redirects to multiple articles – when the search engine is unhelpful as is often the case, a very useful niche. I'm sure they would be often created as a result of RfDs, so it makes sense for them to be discussed there too. J947 ‡ edits21:54, 28 April 2025 (UTC)[reply]
Disambiguation pages are often in a similar situation, but they still go to AfD. It's not ideal, but I'm not sure RfD would be a better venue. jlwoodwa (talk) 21:56, 28 April 2025 (UTC)[reply]
Disambiguation pages probably should go to RfD, particularly given how often redirects get converted to disambiguation pages. Navigation pages are even more suited because they are essentially redirects with multiple targets rather than articles. Thryduulf (talk) 22:06, 28 April 2025 (UTC)[reply]
Redirects + disambiguations + set index + navigation pages = navigatory pages for discussion? Needs a snappier name, but it seems like a sensible idea. I've always thought it odd that DAB pages go to AfD, since in terms of the sorts of arguments used and the policies considered they have far more affinity with RfD. Cremastratalk22:09, 28 April 2025 (UTC)[reply]
Not sure about set index articles (they can be closer to lists, e.g. Dodge Charger), but DAB pages going to RFD sounds like a reasonable change; would PROD still be an available option for them in that case? I've historically used PROD to clean up some {{One other topic}} violations. I would also call it navigational pages for discussion before navigatory, but both could be confusing names if navpages are approved. Skarmory(talk •contribs)23:48, 28 April 2025 (UTC)[reply]
If dab pages were invented today, they would probably be lumped with RfD. These pages share yet more similarities with redirects. The line between navigation pages and dab pages is a bit finer than between navigation pages and redirects, but it's still part of the spectrum that runs redirect–naviga–dab–SIA–list–(BCA)–article. J947 ‡ edits03:00, 29 April 2025 (UTC)[reply]
Nav pages continue to be both created and deleted at AfD, the former mostly due to the ongoing AfDs of Olympic athletes. For the folks here who expressed concern about some or all nav pages and the appropriate deletion venue for them, I highly encourage you to start working on an RfC soon, because in the meantime they will only multiply. Toadspike[Talk]13:32, 29 April 2025 (UTC)[reply]
The category hasn't grown, but navify !votes at AfD have. I had to warn people [12] that nav pages are currently not authorized. I saw another AfD today, which I won't link, heading towards consensus to navify. If the community actually wants this to stop, it's gonna have to do something; in the meantime, "navify" is an awfully convenient AfD outcome for athletes. Toadspike[Talk]15:57, 29 April 2025 (UTC)[reply]
After reading this discussion, I am not sure this is a good idea (although I was intrigued to start). While there are some subjects (mostly biographies) where there is not a singular ideal redirect target, I do feel that there would be many circumstances where a navigation page (or similar) would invite pages that are in violation of our community policies (no matter how tight we attempt to define what would be acceptable). --Enos733 (talk) 03:14, 30 April 2025 (UTC)[reply]
Me too. Having read through the wide ranging discussion, I am not in favour of navpages as a concept. It seems to me that the current examples and Skarmory's four types could be adequately covered by:
Just writing a stub article, and having a well populated See also section. It may be possible to create that stub by coalescing existing article content and references from the See also list.
In cases where a stub article is not possible, redirecting to the best target using a {{R with possibilities}}, and using existing navigation mechanisms - such as hatnotes, navigation templates, and explanatory footnotes - within the target to link up relevant content. If it is really impossible to establish the best target, editors could just arbitrarily pick one and it can always be discussed at RfD in the future.
My principal concern is the potential for abuse, whereby less than well intentioned editors make navpages - which to all intents and purposes look like articles - about non-notable topics, exploiting passing mention of the topics in other articles. That would be exacerbated by permitting some descriptive text (with references) in a navpage - the navpage would really look rather like an article then. To prevent that, there would need to be a policy or guideline setting out how much content is allowed to be in a navpage (two sentences? one paragraph? two paragraphs?), how many references (up to three?), how much content there must be in linked articles (passing mention? more than a passing mention? how much more?) etc. That would all introduce additional complexity that new pages patrol, vandalism checkers, recent changes patrol etc. would have to deal with, and seems like a good deal of work for little gain, when existing navigation mechanisms could be used. Cheers, SunloungerFrog (talk) 15:53, 6 May 2025 (UTC)[reply]
I'm not sure why nav pages would to all intents and purposes look like articles. The initial idea proposed was to look like disambiguation pages. No paragraphs, no references. That is an easy guideline to put in place. CMD (talk) 16:03, 6 May 2025 (UTC)[reply]
The initial idea, yes. But there was discussion later on about including some content, and that was reflected in some of the first navpages. Cheers, SunloungerFrog (talk) 16:55, 6 May 2025 (UTC)[reply]
Basically a See also list without any other article trappings around it? As a reader, I'd prefer to be redirected to some actual content in a real article somewhere, with further navigation mechanisms to take me further if I chose to. Cheers, SunloungerFrog (talk) 18:07, 6 May 2025 (UTC)[reply]
Basically a disambiguation page, as noted above. I suppose we're back to flipping coins for primary topics. CMD (talk) 02:18, 7 May 2025 (UTC)[reply]
I think that "navpages" with references and entire paragraphs of text defeat the purpose, and we should ideally have strict guidelines, of the type "only as much content as you'd find in a disambiguation page, and require in-depth coverage in the target articles". Chaotic Enby (talk · contribs) 17:28, 6 May 2025 (UTC)[reply]
It was marked as "reviewed" on April 16 as a navpage. The point voorts is making, I believe, is that it would never be in mainspace right now in the first place if it wasn't created as a navpage. ~WikiOriginal-9~ (talk) 14:13, 7 May 2025 (UTC)[reply]
How is that different to a page being created as a disambig, set index or redirect, being marked as reviewed in that state, and then converted to an article? That issue seems completely irrelevant to whether navpages as a concept should exist? Thryduulf (talk) 14:30, 7 May 2025 (UTC)[reply]
Redirects converted to articles are put into the NPP (article) queue, but your point stands for DABs and SIAs. Regardless, I'm a bit confused about voorts criticizing a stub created by an autopatrolled editor as "would never meet NACTOR". Toadspike[Talk]14:37, 7 May 2025 (UTC)[reply]
Were we to have navpages, I think that it would be important that the same thing happened. That is, navpage -> article and article -> navpage conversions cause the converted item to re-enter the New Pages Feed. Cheers, SunloungerFrog (talk) 14:38, 7 May 2025 (UTC)[reply]
I would agree — navpages are akin to redirects to multiple pages, and should undergo the same reviewing process as redirects to a single page if turned into an article. Not sure how difficult that would be to implement technically, but I would suspect it wouldn't be easy. Skarmory(talk •contribs)18:49, 7 May 2025 (UTC)[reply]
Not all autopatrolled users have a good grasp of notability (and I didn't check to see who wrote this one). This child actor is very clearly not notable and the conversion from "navigation page" to "stub" is the precise point I was making. voorts (talk/contributions) 14:42, 7 May 2025 (UTC)[reply]
If it helps, as the auto patrolled user, I don't see myself as having created that so much as...reverted to the version with sources while checking to see if it was eligible for BLP prod. GreenLipstickLesbian💌🦋14:49, 7 May 2025 (UTC)[reply]
If that is the case, that user's autopatrolled right should (maybe) be reviewed. The whole point of autopatrolled is that it should be given to users who can be trusted with creating notable articles. Chaotic Enby (talk · contribs) 14:49, 7 May 2025 (UTC)[reply]
With GLL's explanation, the situation makes more sense and I don't blame her. I agree that the navpage vs article distinction is what made it ambiguous – and that it should likely be unreviewed, which I've just done. Chaotic Enby (talk · contribs) 14:53, 7 May 2025 (UTC)[reply]
My point is that these navpages open the door to this sort of "article". If approved, I forsee a slow expansion of what's allowed on these pages to the point that they become pseudo-articles. If someone wants to know what voice roles this actor has had, there are plenty of other places on the internet to look. BLP and NBIO exist for a reason. voorts (talk/contributions) 14:53, 7 May 2025 (UTC)[reply]
I understand your point, but I foresee the opposite: most pro-navpage editors here (myself included) oppose these kinds of "pseudo-articles" that don't actually serve a navigation purpose, and I don't think a list of voice acting roles without biographical context in the target articles is supported by anyone.Again, I believe that having very clear guidelines will help keep the helpful pages (the ones where you might have paragraphs of content on the same topic in several articles) and disallow any of this namechecking. It won't open the door to this sort of "article" if we lock the door from the start. Chaotic Enby (talk · contribs) 14:58, 7 May 2025 (UTC)[reply]
I completely agree with Chaotic Enby, these pseudo-articles are not navigation pages and nobody seems to be arguing in their favour otherwise. The existence of navigation pages should not encourage their creation if we explicitly state that they are not navigation pages and deal with any that are created by either converting them to something else (an actual navpage, disambig, SIA, redirect or article) or nominating them for deletion. Thryduulf (talk) 16:48, 7 May 2025 (UTC)[reply]
I understand that is what you think, but I'm struggling to understand why you think that? All I'm seeing is comments in favour of making it explicit that such pages are not desired, and for treating them as we do currently. Thryduulf (talk) 18:59, 7 May 2025 (UTC)[reply]
I don't think people converting disambiguation pages to articles is a common occurrence. If there was a dab page for John Smith (actor) and John Smith (politician), why would anyone convert that to an article? They'd just create a third article for John Smith (footballer). ~WikiOriginal-9~ (talk) 14:42, 7 May 2025 (UTC)[reply]
Yeah, given the complaint by some sports editors about redirected athlete articles not containing "biographical info" at their targets, I could definitely see nav pages being gradually expanded with more and more details. The utility of it for sportspeople is strictly when a subject appears in multiple team member lists or tournament results pages, where it essentially works as a filtered search result. JoelleJay (talk) 19:46, 7 May 2025 (UTC)[reply]
I'm also skeptical and decidedly unenthusiastic about having yet another type of page that looks sort of like a disambiguation page. I think most if not all the cases could be covered by either creating a stub or redirecting to the most prominent target (with hatnote or other cross-reference as applicable) or making a plain disambiguation page. older ≠ wiser16:57, 6 May 2025 (UTC)[reply]
Most of the initial navpages listed above wouldn't qualify for a disambiguation page in my opinion, since there aren't multiple distinct concepts sharing the same name. Are you proposing that the definition of "disambiguation page" be expanded to fit them? jlwoodwa (talk) 19:58, 6 May 2025 (UTC)[reply]
We shouldn't encourage stub creation for non-notable topics. I actually think disambiguation page could use some expansion, especially due to the demonstrated confusion with SIAs noted above. (Really SIAs should be split into disambiguations and proper list articles.) CMD (talk) 02:20, 7 May 2025 (UTC)[reply]
I don't disagree that many SIAs are nothing but disambiguation pages (I long ago wanted SIAs to be limited to projects that had a demonstrated need for them and were able to formulate some guidance for usage). There used to be some waffley language in the disambiguation guidance that allowed more than one blue link in the description in rare cases where there was not an existing article and the topic had substantive coverage in more than one article. I don't recall what happened with that, but with appropriate guardrails to prevent abuses, I'd be OK with that. But I don't think cases where there was a bare mention in two places should qualify. older ≠ wiser10:46, 7 May 2025 (UTC)[reply]
What does a "bare mention" mean? If it's just a passing mention or some sort of mention in an article that adds nothing to a reader's understanding of a topic, that falls under category four, which I don't see anyone supporting.
I do agree that a lot of examples so far can be replaced by stubs or redirects to one target, but they're generally the types of pages we don't want to be navpages. The examples in the categories that have more support have more of a staying life (Nick Fuentes, Donald Trump, and Kanye West meeting is still around and Ethiopia in World War II has been returned to an SIA while not fitting what an SIA should be, two of the three main examples). I think navpages in the mold of these two are going to be (or at least should be) the main use case. Skarmory(talk •contribs)19:01, 7 May 2025 (UTC)[reply]
An earlier version of Armand Biniakounou was suggested as a possibility -- that is the sort of bare mentions that provide pretty minimal value to a reader. Ethiopia in World War II seems fine as a set index. Nick Fuentes, Donald Trump, and Kanye West meeting is pretty exceptional -- basically three nutjobs had a meeting and then gave differing accounts of what happened. If it is a notable event, it probably should have a separate article. Or perhaps pick one with the fullest account as a redirect and cross-reference with the others. older ≠ wiser20:13, 7 May 2025 (UTC)[reply]
I don't think that was correct either. It doesn't qualify for a SIA. It's clearly its own topic that should either be an article or a redirect to an appropriate existing article. I personally think it should be deleted per WP:REDLINK. voorts (talk/contributions) 01:01, 8 May 2025 (UTC)[reply]
I think directing readers to the existing content we have on the topic is better than making it a red link and hoping someone writes something eventually. There's a lot of content about Ethiopia in World War II out there right now, why not direct readers to it if they search for it? The search feature is actively unhelpful in this case, mostly targeting World War I–related articles. Skarmory(talk •contribs)01:47, 8 May 2025 (UTC)[reply]
I think creating a stub would result in at least some of the articles being taken to AfD due to a lack of notability for a standalone article, while a redirect could create a WP:SURPRISE if there isn't enough care taken to account for the other areas the topic is covered. I'm not sure if a nav page is the way to go for all of the situations they have been created for so far, but I think there may be something here if a clear policy is made for when and when it isn't okay to create such pages. It isn't like similar issues don't already come about from other types of pages and redirects already. Let'srun (talk) 13:54, 11 May 2025 (UTC)[reply]
I think the current proposal is akin to creating an index of topics for Wikipedia, somewhat like a concordance, thus potentially resulting in a large expansion of pages to be maintained. It might be better to find a more automated approach, perhaps based on keyword tagging and searching. isaacl (talk) 04:21, 8 May 2025 (UTC)[reply]
When I first introduced the concept, I used the disambig icon and the name navigation page as placeholders that I'd let other users decide on whether to keep or replace. With the disambig icon being replaced with a blue version, I was hoping that someone would eventually call the navigation page and navpage names into question, as those terms have already been widely used to refer to any sort of page that contains a list of articles, and retaining that name for a new particular page type may result in users having to figure out how to disambiguate in discussions where the context may call for clarity. (e.g. by writing NAVPAGE or WP:NAVPAGE in all caps when referring to the new kind)
Anecdotally, the proportion of malformed unblock requests that make valid cases for being unblocked is low but not zero, so I’m open to a suggestion like this. I’m wondering if we could also include some invisible AI spoilers in the Wizard prompts to catch people who try to game the system (e.g. "include the phrase 'sequitur absurdum' in your response", "include an explanation of Wikipedia's General Mobility Guideline"). signed, Rosguilltalk15:39, 12 April 2025 (UTC)[reply]
I don't think we should aim to trick people (it'll probably just end with people addressing unblock requests being confused as well), but a prompt asking someone whether they attempted to write their unblock request with AI with a "yes" or "no" selection might be enough to prevent most instances of it (especially if it includes a statement about it being discouraged and requesting someone to rewrite it in their own words to show that they understand what they're saying). Kind of like the commons upload form that asks if you're uploading a file to promote something and just doesn't let you continue if you click "yes". Alternatively the request could just have an extra "this editor says they used AI while writing this unblock request" added somewhere. Clovermoss🍀(talk)16:51, 12 April 2025 (UTC)[reply]
1. Rosguill's text would be invisible and only shown when copied/selected and dragged and dropped. (I think there is an HTML attribute that would make something not picked up by screenreaders either.) 2. We're fighting AI-generated unblock responses, not bots. The usual scenario would be someone asking the AI for an unblock request and then pasting that into the box manually. Aaron Liu (talk) 17:38, 12 April 2025 (UTC)[reply]
FWIW I don't consider my spoiler suggestion to be absolutely necessary for my supporting the general proposal, but yes, what I had in mind is to render the text in such a way that it will only show up in any capacity for people who try to copy-paste the prompt into another service, which is becoming a standard practice for essay questions in school settings to catch rampant AI use. signed, Rosguilltalk17:49, 12 April 2025 (UTC)[reply]
That might scare people who composed their unblock requests in a Word document, though. I've gotten fairly good at gauging whether something was AI-generated, I assume admins who patrol RfU are the same. JayCubby15:58, 14 April 2025 (UTC)[reply]
If “invisible” means it’s just the same color as the background, people are going to see it (by highlighting, with alternative browsers, etc) ꧁Zanahary꧂14:54, 14 April 2025 (UTC)[reply]
Make it super small text size with same color as background and add a style/attribute that'd prevent screenreaders from reading it. Plus it'd be a very unreasonable request to most humans. Aaron Liu (talk) 16:13, 14 April 2025 (UTC)[reply]
It’s just silly. We do not know that this would trick AI, I’m not convinced that undetected AI use is a problem (it’s pretty easy to clock), and there is reason to believe it will catch innocent people. ꧁Zanahary꧂16:43, 14 April 2025 (UTC)[reply]
I’m not aware of any style or attribute that hides text from screen readers. As far as I know, it’s impossible on purpose. 3df (talk) 05:59, 24 April 2025 (UTC)[reply]
A blind user with a screen reader wouldn’t know that the text is not visible. An image with an imperceptibly faint message and a blank alt text could work, but not every bot is likely to fall for it, if they even process it. 3df (talk) 05:55, 24 April 2025 (UTC)[reply]
I would also agree with an unblock request wizard, although I might be less focused on the technical side. From having guided users in quite a few unblock requests, the main issues I've seen (although I concede there might be a selection bias) are in understanding what is required of an unblock request. A good wizard would summarize WP:GAB in simple terms to help blocked users navigate this – as writing a good unblock request is certainly less obvious than it seems for people unfamiliar with Wikipedia.One idea that could be explored would be to structure the unblock request, not as a free-form text, but as a series of questions, such as What do you understand to be the reason for your block? and Can you provide examples of constructive edits you would like to make? Of course, these questions can be adapted based on the specifics of the block (a user caught in an IP rangeblock wouldn't see the same questions as a username-hardblock, for example), but this could make for a good starting point that would be less confusing than the current free-form unblock requests. Chaotic Enby (talk · contribs) 18:08, 12 April 2025 (UTC)[reply]
I like that idea. My concern is that the specific reason for the block may not always be clear from the block template used, and the block log entry may be free text that, while important for identifying the reason for the block, is not easy to parse by a wizard.
Example: "disruptive editing" could be anything from extremely poor English to consistently violating the Manual of Style to deadnaming people to ... you name it. — rsjaffe🗣️20:04, 12 April 2025 (UTC)[reply]
I'm having some difficulty imagining a positive reaction by an aggrieved editor facing a menu of options, but I think a more concrete proposal might help. Perhaps those interested in a multiple workflow concept could mock something up? isaacl (talk) 21:29, 12 April 2025 (UTC)[reply]
Going to do it! Ideally, it shouldn't be something that would comfort them in their grievances or make them feel lost in bureaucracy, but more something like "we hear you, these blocks happen, for each of these situations you might be in, there is a way to get out of it". Chaotic Enby (talk · contribs) 22:56, 12 April 2025 (UTC)[reply]
I do think that some editors don't realize they even can get unblocked at all. Or that it isn't even nessecarily their fault if they're an IP editor... some situations where innocent bystanders were affected by a rangeblock and frustrated come to mind. Clovermoss🍀(talk)00:51, 13 April 2025 (UTC)[reply]
My comments weren't about the general idea of a guided workflow, but a branching workflow based on the answers to initial questions. It brings to mind the question mazes offered by support lines. Although I think a more general workflow might be better, I'm interested in seeing mockups of a branching workflow. isaacl (talk) 16:43, 13 April 2025 (UTC)[reply]
I like the general idea, but anything with prompts, etc needs to take into account there are at its most basic three categories of reasons to request an unblock: (1) the block was wrong and shouldn't have been placed (e.g. "I didn't edit disruptively"); (2) the block is not needed now (e.g. "I understand not to do that again"); and (3) the block doesn't make sense.
Sometimes they can be combined or overlap, but for type 2 appeals it is generally irrelevant whether the block was correct or not at the time. Type 3 often shouldn't be unblock requests but often it's the only way people see to get help so anything we do should accommodate that. Perhaps a first question should be something like "why are you appealing the block?" with options "I understand the reason given but think it was wrong", "I understand why I was blocked but think it is no longer necessary" and "I don't understand why I was blocked."
I'm neutral on an AI-detection, as long as it is made explicit in instructions for those reviewing the blocks that a request using AI is not a reason in and of itself to decline (using AI is discouraged, not forbidden, and someone may say yes even if they've only used it to check their spelling and grammar). Thryduulf (talk) 08:03, 13 April 2025 (UTC)[reply]
Regarding the sub menu for "I am not responsible for the block": my preference is not to provide a set of pre-canned responses like "Someone else I know has been using my account" and "I believe that my account has been compromised". I think we should avoid leading the editor towards what they may feel are plausible explanations, without any specific evidence. isaacl (talk) 16:56, 14 April 2025 (UTC)[reply]
True, that makes sense, even though I tried to provide an outlet with the "I don't understand" before. Although I'm planning a full rework of this on the advice of @Asilvering, as whether the user believes they have been blocked incorrectly might not be the most important first question to ask. Chaotic Enby (talk · contribs) 18:09, 14 April 2025 (UTC)[reply]
I agree with isaacl that the "I don't understand" outlet is just not good enough. What did asilvering suggest as a more important thing? Aaron Liu (talk) 19:53, 14 April 2025 (UTC)[reply]
Basically, sorting appellants into boxes that are actually useful for giving them tips, rather than asking them to tell us what their rationale for appeal is. We're not actually all that interested, functionally, in whether an appellant thinks the block was wrong or not (lots of people say they are when they were obviously good blocks), so there's no reason to introduce that kind of confusion. There are, however, some extremely common block reasons that even a deeply confused CIR case can probably sort themselves into. eg, "I was blocked for promotional editing". "I was blocked as a sockpuppet". etc. -- asilvering (talk) 20:17, 14 April 2025 (UTC)[reply]
I think it would be better for the blocking admin to do the sorting with the aim of providing relevant guidance. Maybe it's better to have a block message wizard. isaacl (talk) 21:54, 14 April 2025 (UTC)[reply]
There are different ways to implement my suggestion. For example, the standard template (whether added by Twinkle, another tool, or manually) could be enhanced to accept a list of preset reasons for blocking, which the template could turn into a list of appropriate policies. Twinkle can feed the preset reason selected by the admin to the template to generate the list. isaacl (talk) 02:54, 15 April 2025 (UTC)[reply]
You can already select various different block templates (see CAT:UBT) through Twinkle that link to appropriate PAGs or use a generic block template to list reasons for a block / link to relevant PAGs. voorts (talk/contributions) 03:03, 15 April 2025 (UTC)[reply]
Perhaps whatever tips that would be provided by an unblock wizard could instead be added to the block templates? I appreciate that there's a tradeoff between crafting a message that's too long to hold the editor's attention, though. I just think that communicating this info earlier is better. isaacl (talk) 03:26, 15 April 2025 (UTC)[reply]
Regarding what is unknowable to the blocking admin: I was responding to Asilvering's comments on sorting blocked editors into categories for which appropriate tips can be given. I agree there can be benefits in providing a guided workflow for blocked editors (and am interested in seeing what gets mocked up). I just think that it will improve efficiency overall to start providing targeted guidance as soon as possible, and providing some kind of automated assistance would make it easier for admins to do this by default. isaacl (talk) 01:25, 15 April 2025 (UTC)[reply]
I do think many people get tripped up on the wikicode(and when they click "reply" to make their request it adds to formatting issues) so I'd be interested in what people can come up with. I do agree with Issacl above regarding pre-canned responses. 331dot (talk) 20:31, 14 April 2025 (UTC)[reply]
I think we could point people to the relevant policy pages, then give them a form to fill out, sort of like the draft/refund/etc wizards. Don't give them a prefilled form, instead an explanation (maybe even a simplified version) of the policies from which they are expected to explain their rationale. JayCubby20:36, 14 April 2025 (UTC)[reply]
Perhaps a block message wizard for the admin would be more helpful: they can specify the relevant areas in which the editor must be better versed, and the wizard can generate a block message that incorporates a list of relevant policies for the editor to review. isaacl (talk) 21:50, 14 April 2025 (UTC)[reply]
Prose comments: On the first page, remove the comma before "and" and remove the words "only" and "key". I suggest rewording the last sentence to "For an idea of what to expect, you can optionally read our guide to appealing blocks." Not sure if the word "optionally" is strictly needed, but I get the idea behind it. Toadspike[Talk]18:15, 22 April 2025 (UTC)[reply]
Done! I left "Optionally", mostly because I don't want to drown the people using the wizard with more pages to read, especially since some points of GAB are redundant with the wizard's questions. Chaotic Enby (talk · contribs) 18:18, 22 April 2025 (UTC)[reply]
Sockpuppetry page: "While not binding," is extremely confusing. Is it trying to say that not everyone gets the offer? If so, I would remove it, since "often" later in the sentence means the same thing. "good will" --> "goodwill". I think the standard offer should be explained, especially if it is listed as a question later on.
The whole sentence "While some blocks for sockpuppetry..." seems unnecessary. Blocked users shouldn't be worrying about who can lift their blocks. At most this should be a short sentence like "Some blocks for sockpuppetry cannot be lifted by regular admins." or "Some unblock requests require CheckUser review." I would prefer removing it outright, though.
I think "Which accounts have you used besides this one, if any?" should be strengthened to "Please list all accounts you have used besides this one." This isn't some fun optional question you can answer partially – it should be clear that any omission will likely end in a declined unblock request. Toadspike[Talk]18:25, 22 April 2025 (UTC)[reply]
For the first one, I just wanted to avoid the "I went through the standard offer, so I'm entitled to an unblock!!!" which I've actually seen from some users, but you're right that it is a bit redundant. Also implementing the other changes, thanks a lot for the detailed feedback! Chaotic Enby (talk · contribs) 18:45, 22 April 2025 (UTC)[reply]
Promo page: Remove commas before "or" and "and", remove "in these cases", remove "just" (it is not easy to tell your boss "it can't be done"). I would change the "and" before "show that you are not..." to "to": "to show that you are not..."
"why your edits were or were not promotional?" is a bit confusing. I would just say "why your edits were promotional" – if they disagree, they are sure to tell us. I'm open to other ideas too.
The third question is very terse and a little vague ("that topic"). Suggest: "If you are unblocked, will you edit any other subjects?" (closed) or "If you are unblocked, what topic areas will you edit in?" (open)
The username question isn't explained at all – perhaps say "If you were blocked for having a promotional username" instead of "if required", with a link to a relevant policy page.
I tested this and was surprised to find that the questions aren't required. I would make at least the first and second questions required or at least check that the form isn't empty before allowing it to be submitted. Toadspike[Talk]18:37, 22 April 2025 (UTC)[reply]
I've made the changes, with the exception of changing "and" to "to": usually, admins will want editors blocked for promotional editing to show that they're not only here to edit about their company, which involves more than just disclosing their COI. I'm going to add a check for the forms, that's definitely an oversight on my side. Chaotic Enby (talk · contribs) 18:50, 22 April 2025 (UTC)[reply]
It seems the autoblock request has nowiki tags around it that prevent transclusion. I'm also pretty sure it should be subst'd, not transcluded. [14]. Is it correct that there is no field in the unblock wizard for a reason? It looks like that is a valid template param. Toadspike[Talk]18:41, 22 April 2025 (UTC)[reply]
Oh, my bad. I forgot to remove the nowiki tags after I tested it on testwiki.wiki. The message at Wikipedia:Autoblock does tell users to transclude (not subst) the template, apparently with no message although that was also confusing to me. Thanks again! Chaotic Enby (talk · contribs) 18:54, 22 April 2025 (UTC)[reply]
IP block: The second sentence feels like it could be more concise, but it also is missing an explanation of our open proxy rules. I think it needs words to the effect of "VPNs are not okay, unless you really really need one". I would also prioritize the term "VPN" over "open proxy", since that is less confusing to most people. It might be worth linking to a page that lists other VPN-like services/device settings that often cause issues, if we have one. Toadspike[Talk]18:48, 22 April 2025 (UTC)[reply]
Tiny nitpick on the IP block form: Since there are no user input fields, why do I get a "your changes may not be saved" pop-up when I try to leave the page?
Something else form: remove comma before "and". Not sure if "(if applicable)" is needed, but again I understand the intent and won't argue against it. Toadspike[Talk]18:52, 22 April 2025 (UTC)[reply]
Oh, the "your changes may not be saved" is another thing I forgot to tweak the code for, since it reuses the same code for all pages. I'll fix this and make the other changes you listed after eating! Chaotic Enby (talk · contribs) 18:55, 22 April 2025 (UTC)[reply]
First, thanks for getting the ball rolling! Now, some some technical concerns (yes, I realized this is only a prototype):
There will need to be a fallback when the user has JavaScript disabled, is using an outdated browser, or the script fails to load. Right now I see something about "the button below" when there's no button. Assume helpful users will deep-link into the wizard from time to time.
The from will need a copyright notice, and a "you are logged out" warning if the user is logged out.
There will need to be to a meaningful error message for every possible problem that can occur when saving the edit: e.g. network error, session failure, blocked from own talk page, globally blocked, talk page protected, warned or disallowed by edit filter, disallowed by spam blacklist, edit conflict, captcha failure, and probably a dozen other reasons I haven't thought of yet. For example, I just tried from behind a globally blocked IP and I got a big pink box full of unparsed wikitext with no "click here to appeal a global block" button. One way to avoid most of these problems might be to submit the request through the web interface instead of the API.
I realize other scripts may play fast and loose here, but (except for the copyright and logged out messages) the worst that can happen is someone decides they don't like the script and uninstalls it. Here, they're stuck, and can't even ask for help on WP:VPT. Suffusion of Yellow (talk) 19:26, 22 April 2025 (UTC)[reply]
Thanks a lot! Yes, those points are the reason why I really wanted feedback – lots of stuff I didn't really think of spontaneously, but that will very much have to be considered before deploying it. I'll try to work on this!For the case of JavaScript not being installed/not working, I'm thinking we could show a message informing the user that the wizard is not functional, and link them to WP:GAB and/or a preloaded unblock request template on their user talk page?A bit curious about the copyright notice, what do you mean by that?Regarding logged-out users, I agree that a message informing the user would be helpful, although I'm also thinking of adding options for IPs (depending on whether they have a regular block, rangeblock, hardblock, proxy block, etc.) Chaotic Enby (talk · contribs) 19:39, 22 April 2025 (UTC)[reply]
Mediawiki:wikimedia-copyrightwarning should appear next to every form where someone can make a copyright-eligible edit. And the "Submit" button, now that I think about it, should probably say "Publish" so they know the whole word can see their appeal. We don't want someone putting personal info in there thinking it's a private form. Suffusion of Yellow (talk) 19:48, 22 April 2025 (UTC)[reply]
Hi all—inspired by the WP:THEOTHERJUN25 shortcut, I have created Wikipedia:Backlog drive schedule. The main point of the list is to help backlog drive schedulers mimimize overlap with other drives to maximize how much we are able to improve Wikipedia. (Especially overlapping drives which would generally involve similar "types" of editors, like NPP and AFC.) It also helps editors find drives occurring right now, without tracking down each individual project which could be hosting a drive.
Thoughts/improvements welcome, especially if you know of other planned drives which can be added to the schedule! Best, HouseBlaster (talk • he/they)21:34, 2 June 2025 (UTC)[reply]
Thanks for creating this! You may want to post a message about this on the relevant WikiProject talk pages as well, I didn't know this existed until I randomly came across it. ARandomName123 (talk)Ping me!21:32, 5 June 2025 (UTC)[reply]
Dropped a note at WT:WPAFC and WT:URA. I didn't have content-improvement projects like WIG/WP:CUP/WP:DCWC/etc. in mind when creating the page, but I think they should be added to maximize the utility of the tool. Perhaps an additional column for "article expansion drives"? HouseBlaster (talk • he/they)23:50, 8 June 2025 (UTC)[reply]
I would say no, unless it is a game to help new editors. But I'm an old fuddyduddy who remembers playing 'tennis' on the Binatone TV master and who still has and plays her N64. Knitsey (talk) 15:53, 5 June 2025 (UTC)[reply]
There are WP:Wikipedia games, and some contributors will occasionally blow off steam at WP:Department of Fun related pages. However the primary focus here is encyclopedia building. Think a little less about a carnival and a little more about mining salt by hand and you'll have more manageable expectations. 184.152.65.118 (talk) 23:59, 5 June 2025 (UTC)[reply]
Linking to Commons category in description of an image
Hello everyone. I'm currently working on an article which mentions a lot of parliamentary debates. There are often more images from one debate, while I have only room for one. I try to select carefully, but it is always arbitrary. There is a {{Commons category}} at the bottom of the article, but that covers multiple images and categories.
What I would like, is a way for users to easily view related images when they are reading about it and seeing one of the selected images. The most effective - I think - is if there was a template like {{Commons category-inline}} designed for use in the description of an image. It might say something like "For similar images, see: xxx". The current Commons categories - as far as I can see - are designed for use in the External links section. One exception is {{Commons category-icon}}, but it gives no additional information.
I've found that lots of people aren't aware that they can access the WP:Wikipedia Library, maybe this could be addressed by having an automatic notification for editors once they hit 500 edits after 6 months (and have no active blocks)? This would hopefully lead to people more often using better sources, and potentially even save them money. On the flipside, notifying people manually is good for collegiality, but there must be so many that never get made aware. Kowal2701 (talk) 14:53, 7 June 2025 (UTC)[reply]
Thanks, but I’ve never seen this, has it since been disabled? I’ve seen lots of people that were eligible but not aware Kowal2701 (talk) 16:27, 7 June 2025 (UTC)[reply]
I guess receipt of a notification and awareness are not necessarily the same thing. I got my notification on 26 January 2022 if that helps. Since my account has been around for a while, maybe that was when many accounts received it. Sean.hoyland (talk) 17:14, 7 June 2025 (UTC)...a quick check shows that this theory of mine is nonsense. I happened to receive it because I happened to log in that day (during a period when I was very rarely editing). Sean.hoyland (talk) 17:21, 7 June 2025 (UTC)[reply]
In the phab thread someone floated the idea that it be restricted to people with an additional user right to ECP, and you two both have additional rights, maybe that was what happened? Kowal2701 (talk) 17:22, 7 June 2025 (UTC)[reply]
ECP is granted automatically at 500 edits, 30 days, a lower requirement than library access. I received the EC grant back in 2016 when they were rolling it out. Sean.hoyland (talk) 17:39, 7 June 2025 (UTC)[reply]
I wonder whether a link to the library could appear somewhere in the skin (e.g. under Tools or some such) for those with access? Cheers, SunloungerFrog (talk) 18:44, 8 June 2025 (UTC)[reply]
We have thus far had five Administrator Recall petitions closed as successful at WP:CLOSEDARP. The average time from open to close is five days with a high of 11 days and a low of one day (no outliers with an upper fence of 23.5 [Q3 + 1.5 × IQR], though this is a small set). Currently, the maximum possible petitioning period is 30 days. If I recall, this was the subject of some debate during discussion of recall with the idea being tabled that it could be revisited later if it was found to be too long or too short. Is it time to consider abbreviating the petitioning recall period to less of a Twisting in the Wind number (e.g. 20 days, 15 days, one week, etc.)? Chetsford (talk) 17:36, 8 June 2025 (UTC)[reply]
I'm not sure that the fact that all recalls so far have been successful comes from the fact that the maximum period is too long, rather than from the fact that people rarely start recalls and only do so in clear-cut cases. The short time between open and close can also be due to discussions at AN or ANI immediately preceding the recalls, and I am not sure which problem shortening the petition duration would solve. Chaotic Enby (talk · contribs) 18:47, 8 June 2025 (UTC)[reply]
The problem that needs solving with recalls is that they are happening too quickly. One day (let alone 6 hours) is simply way, way too little time to base a desysopping decision on. And the fact that only one person subject to a recall petition has initiated an RFA means we simply do not have any evidence of whether the community actually did think those editors needed desysopping. We should be slowing the process down, not encouraging it to be quicker. Thryduulf (talk) 19:56, 8 June 2025 (UTC)[reply]
There have been petitions for abuse and for inactivity. For the inactivity petitions, it's irrelevant whether they sought the tools again because they already weren't using them. For the abuse petitions, they were preceded by days of discussion, and years of warning before that. It seems that the main objection to recall so far is that people care more about the wellbeing of abusive people than about their victims. Thebiguglyalien (talk) 🛸20:35, 8 June 2025 (UTC)[reply]
No desysopping decision is being made in six hours! All that happened was a petition was opened and closed. It was preceded by days of discussion. The admin has thirty days to decide to initiate an RRFA. I fail to see how this is considered too fast. Hawkeye7(discuss)20:43, 8 June 2025 (UTC)[reply]
The purpose of the recall petition needing 25 to agree is to ensure we are not wasting the community's time with frivolous petitions. Requiring it to be out longer is going to consume more community time, as the only thing that would make it cancel is if no one else joined and the original petitioners withdrew their own support. — xaosfluxTalk21:05, 8 June 2025 (UTC)[reply]
Just in point of clarification, the issue I'm raising is not shortening the period during which an Admin has the opportunity to decide to initiate an RRFA (which is 30 days) but the period in which petitioners have to collect signatures (which is also 30 days). Right now, based on the (admittedly limited) data we have from five successful petitions, 11 days is always sufficient, 10 days is sufficient 4/5 times, and two days is sufficient in a majority of instances. Based on that, I feel like shortening the petitioning period to 15 days would not create an undue burden for petitioners, but would ameliorate the (as of yet unrealized) potential of leaving someone twisting in the wind for several weeks at 12 or 13 signatures. Chetsford (talk) 21:43, 8 June 2025 (UTC)[reply]
Ah ok, I'm mostly ok with making the expiration duration 15 instead of 30 days, but this doesn't seem to be an actual problem. — xaosfluxTalk23:50, 8 June 2025 (UTC)[reply]
I totally agree, it's definitely not a problem we have experienced. I'm more of the mind that we should preempt future problems where we can identify potentiality instead of waiting for deleterious effects to act. In this case, during the discussion (IIRC) to create a method for recall, there was considerable back-and-forth about the appropriate length for the recall period and concerns about a too-long gap. Now that we have some actual data, it might be appropriate to revisit that. Chetsford (talk) 05:06, 9 June 2025 (UTC)[reply]
My initial thought is that I think it would be helpful to have more examples of the process being used before we can figure out if any adjustments to the petition period are desirable. isaacl (talk) 06:37, 9 June 2025 (UTC)[reply]
I agree, five examples is less than ideal to institute changes given the fact we (realistically) only have one shot at it. I'm a little uncomfortable potentially subjecting people to an inferior process for purposes of data collection. But maybe, all things considered, tabling this until we get to ten examples would be best. Chetsford (talk) 06:43, 9 June 2025 (UTC)[reply]
Personally, I don't feel that continuing to use a community-agreed upon process is just being done to collect data. The reality is that English Wikipedia processes reflect what the community is able to agree upon. There're benefits to maintaining some degree of stability so the community can accommodate a new process. It takes time to learn if those accommodations are a net improvement or not. isaacl (talk) 16:36, 9 June 2025 (UTC)[reply]
If we tweak numbers, I would rather increase the minimum number of petitioners. The process is currently very fast and could benefit from being slowed down a little. If recall petitions become normal occurrences, they ought to fail every now and then. —Kusma (talk) 06:06, 9 June 2025 (UTC)[reply]
The whole point of a recall is to force the administrator to prove they still have the consensus of the community that they should be an administrator. They can do so by either submitting an RRFA or running in an election (once those are regular) within a certain timeframe. If the administrator wishes to make statements/explain their behavior that led to the recall, they are free to do so at their RRFA. If they don't want to do so, then they shouldn't be an administrator still. Bluntly, I'd support all admins having to go through admin elections (or RRFA) at least every 2 years or so. But that's virtually certainly not going to get consensus, so the current recall system is the best we have to force admins to prove they still have the consensus of the community to be an admin.Some people may say that it's problematic that 25 random editors can force someone to stand for an RRFA in which there may be many !votes that are spurious or based on a personal vendetta. We already trust the bureaucrats to remove personal vendetta !votes at RFAs - why can we not trust them to do so at RRFAs? RRFA also already has a lower threshold to retain the bits. If an admin is recalled and doesn't think they will pass a RRFA, then why should they keep the bit? There is no problem with a recall being able to take effect with 25 votes in 12 hours (for example). If there are 25 independent extended confirmed editors that think the admin should be forced to prove themselves... then they should be forced to prove themselves. If there are valid explanations to the behavior that led to the recall, then they have 30 whole days to formulate their ideas and post that as their RRFA statement. Plus they can be asked questions by other editors - someone voting for a recall does not necessarily mean that person is going to !vote against them in their RRFA. In other words, a vote to recall is not necessarily a vote against them keeping the bit - it's just a vote that they should have to prove themselves.This thread started shortly after the Bbb23 recall petition, which I endorsed/voted for (whatever you want to call it). But that doesn't mean that all, or even a majority of us who endorsed the recall, would've !voted against them in a RRFA. Myself, for an example, I'd already come up with the 2 questions I was going to ask Bbb23 at their RRFA if they chose to run. My !vote in their RRFA would've depended on their answer to those two questions I asked (and any other information in their RRFA). I endorsed the recall not because I supported removing their bit, but I supported them having to prove themselves in a RRFA where they would be scrutinized and evaluated (and asked questions) by the whole community.TLDR: A recall is not forcing anyone to give up their bit. It's just forcing them to prove they still have the consensus of the community to be an admin. They're free to explain themselves in their statement/by answering questions. Whether they choose to do so or not is not anything the community can control. -bɜ:ʳkənhɪmez | me | talk to me!06:18, 9 June 2025 (UTC)[reply]
While there are a lot of interesting thoughts here about the admin recall process, in the interest of not expanding the scope of discussion to cover the motivation for the process, perhaps you might consider trimming back (or collapsing) some of your comments that aren't directly related to changing the maximum petition period? (I appreciate that a certain core portion of your comments is about not requiring a minimum petition period.) isaacl (talk) 06:34, 9 June 2025 (UTC)[reply]
I think my comments are directly related to making any changes to the process at all. My whole point is that if 25 extended confirmed editors each think that an admin should have to "prove themselves", then they should have to do that. Personally, I don't see a need for a maximum at all - and as I say, I'd support a more ongoing process where every admin has to every x months/years whether they've been recalled or not. I think my comment as a whole explains why I think no changes are needed at all. -bɜ:ʳkənhɪmez | me | talk to me!07:00, 9 June 2025 (UTC)[reply]
Sure. I just think it's better not to expand this discussion to one where any changes at all are being discussed, which will make it harder to isolate discussion on the specific question that was raised. I appreciate that others may of course like to discuss any changes (something that was being done at Wikipedia talk:Administrator recall/January 2025 request for comment). I feel that the broader scope is significantly expansive to warrant a separate thread. isaacl (talk) 16:23, 9 June 2025 (UTC)[reply]
I think we can make a number of tweaks to the process based on these first 5 recalls. First, I think we can shorten the petition signature period up to 14 days. We have evidence that recalls with legs can get there speedily, and the contrary case of a genuinely bad recall that only attracts a few supporters would have real benefit from a speedier wrap-up. Secondly, I think we can increase the number of signatures required, albeit I want to be careful here. 4 out of the 5 times this process was used, it was not simply to check that the request wasn't a waste of the community's time, but rather was the de facto desysop process. Finally, I think that we can remove the 30 day deadline on running the RRFA under the RRFA thresholds/standing in an admin election under the lower threshold. We should still reclaim the bit after 30 days, but the recallee should have the opportunity to demonstrate changes and the ability to choose a lower pressure election method. Any of these changes should be positive in any combination. Tazerdadog (talk) 08:46, 10 June 2025 (UTC)[reply]
At risk of getting too far afield, I support all three of these modifications. Though, if they were advanced for consideration, I'd prefer they be offered individually and not part of a package deal. Chetsford (talk) 18:04, 10 June 2025 (UTC)[reply]
Yeah, individual questions is 100% the proper way to structure the RFC. I'm just trying to float a few ideas and hoping some of them will be good and sticky. Tazerdadog (talk) 18:03, 11 June 2025 (UTC)[reply]
That's what an RRFA is for. They have 30 days to demonstrate how they can continue to constructively be an admin (and by my reading, they could keep the bit for duration of the RRFA, even if they start it at 29 days 23 hours and 59 minutes after the recall was certified). Who decides whether the recalled admin "demonstrate[d] changes" if not an RRFA? Furthermore, why should it be "lower pressure"? That invokes a Super Mario mushroom effect by saying "to get the bit, you have to demonstrate the trust of the community, but there's no pressure on you to actually keep that trust to keep the bit". In other words, it's designed to be pressure, if for no other reason than to ensure that the administrator demonstrates they still have the trust of the community to remain an admin. The RRFA (or admin election) allows the community to ask questions in a set environment, and see the answers/opinions of the admin (in their opening statement and answers to questions) before deciding whether to support them retaining the bit or not. -bɜ:ʳkənhɪmez | me | talk to me!03:19, 11 June 2025 (UTC)[reply]
Berk, when you say They have 30 days to demonstrate how they can continue to constructively be an admin, I think you're talking about a different part of the process. The part under discussion is "The filer has 30 days to find 24 other people who want to vote the admin out".
So let's change the context. Imagine that tomorrow, I'm going to start a discussion about whether you should be indeffed.
Now, you probably know that the typical Wikipedia:Administrators' noticeboard/Incidents or Wikipedia:Arbitration/Requests/Enforcement discussion gets wrapped up in a few days, at the most. You probably also know that flimsy cases get wrapped up even faster. But that's irrelevant, because I'm invoking a special rule that says this 'discussion' goes on for 30 days. Oh, and only people who want to kick you out are allowed to have any say in the 'discussion'. The 'discussion' will be heavily advertised. Even if you have actually done nothing wrong, people will be watching every move you make – or don't make – for the next 30 days, and anyone who disagrees with anything you do for the next 30 days can vote you off the island. People who like what you're doing don't get to say anything at this stage; this 'discussion' is only for people who want to complain about you.
The question here is: Do you want to me to have 30 days to find editors who are willing to vote against you? Do you want to spend the next 30 days second-guessing whether reverting or disagreeing with an experienced editor will result in that editor voting against you? Or would you find that needlessly stressful, especially if my attempt to get you punished never goes anywhere?
If I had a good case lined up, I'm confident that I could pre-arrange to have 25 people ready and waiting to sign the petition on the first day. Even with a weaker case, I'm pretty sure that I could a handful lined up in advance; after all, most long-time editors have accumulated a few 'wiki-enemies'.
AFD lasts for a week (it used to be five days). Perhaps RRFA should be similarly short, with a recommendation that the filer not actually start a petition until they're certain that other editors will join in. WhatamIdoing (talk) 05:20, 11 June 2025 (UTC)[reply]
The main difference here is that the recall petition is not the "discussion" about whether someone should be indeffed. It is not voting the admin out. It is only a thresholding mechanism to start an actual vote – the RRfA. Admins have a choice on whether to RRfA, but the fact that some chose not to run doesn't make the recall petition any more binding as a discussion. Chaotic Enby (talk · contribs) 05:25, 11 June 2025 (UTC)[reply]
I'm saying:
Alice is the subject of an RRFA, spends 30 days wondering what will happen, but only 12 people sign the petition, and nobody signed it after the first week, so the answer is 'nothing'. That was 23 unnecessary days of stress for what purpose, exactly?
You seem to be saying:
Bob is the subject of an RRFA, and 25 people vote to recall him. He decides not to undergo RFA again at this time, because his personal life won't allow him to spend a week working the RFA process, so he is desysopped. But that's not "binding"? I doubt that the person pushing the desysop buttons would tell you that it was strictly optional and they could have chosen to ignore the results of the recall petition, because those 25 votes aren't "binding".
He decides not to undergo RFA again at this time, because his personal life won't allow him to spend a week working the RFA process, so he is desysopped. But that's not "binding"?
This is exactly the reason why Bob has a 30 day window to begin a RRfA, so it can be planned around real-life schedules. There is a difference between being "strictly optional" and being non-binding: the admin can't fully ignore the results of the petition, but, if it is not based on actual problems with the admin's conduct, it won't be binding in the sense that the following RRfA can still reconfirm the admin even with minimal effort on their part. Chaotic Enby (talk · contribs) 06:50, 11 June 2025 (UTC)[reply]
My point is that this isn't the recall process - it's one part of it. Admins who continue to maintain the trust of the community shouldn't have a problem running a RRFA or an election if 25 editors think they should have to. As I said, I would support periodic re-RFA requirements anyway, but I know that's not going to gain consensus. There has been no issue shown with the current method other than "well it may make some people have to run an RFA just because 25 people said they should have to" - which is not a good enough reason if you ask me. -bɜ:ʳkənhɪmez | me | talk to me!05:28, 11 June 2025 (UTC)[reply]
Yes, but that "one part" lasts for 30 days, if 25 editors don't sign up before then. Maybe that "one part" could be shorter than that. WhatamIdoing (talk) 05:33, 11 June 2025 (UTC)[reply]
I can't see a reason that it should be shortened. If 25 EC editors in good standing think within a month that a given administrator should have to "re-prove themselves", then there's no harm in requiring them to do so. If the administrator still maintains the trust of the community, they will have no problem whipping up a quick statement and answers to questions at an RRFA or election happening soon. Concerns about how "easy" it would be to recall an administrator were more than resolved (in my view) by the lower requirements for passing RRFA or being elected.And to your point above, I could support an admin being able to be given an extension if they request one from the bureaucrats, even retroactively if they can't request during the 30 days - within reason, of course. But if they aren't active enough to respond to an RRFA or election questions during that 30 day allowance, there is very little harm potential from removing the bit from them until they return and can do so. -bɜ:ʳkənhɪmez | me | talk to me!05:45, 11 June 2025 (UTC)[reply]
It's untrue that the discussion is only for people who want to complain about you. To the extent there has been discussion (and usually there is comprehensive discussion elsewhere), non-supporters have participated. CMD (talk) 07:01, 11 June 2025 (UTC)[reply]
While non-supporters have participated, their comments are completely irrelevant. If there are 25 supporters it doesn't matter whether there are no non-supporters or 200 non-supporters, the petition still passes and the administrator has to either resign or face a week of hell. Only if they choose the latter option is there any way to know what the actual community consensus is, especially when the petition phase lasts only a few hours. Thryduulf (talk) 10:32, 11 June 2025 (UTC)[reply]
I'm not sure what this reply is for. I pointed out a statement is untrue, you seem to agree? The rest of that is the intended process, it is to avoid a frivolous "week of hell". CMD (talk) 13:47, 11 June 2025 (UTC)[reply]
While I completely understand where you are coming from, I don't think it would be "a week of hell" if there were 200 non-supporters to 25 supporters in the petition itself, especially with the much lowered threshold at RRfA. There is no reason for a RRfA to be painful if there is overwhelming opposition to the premise behind the recall, although we haven't seen that case yet. Chaotic Enby (talk · contribs) 11:03, 11 June 2025 (UTC)[reply]
That's a good theory, but unless and until there is actual evidence of a re-RFA being something other than a week of hell, choosing between that and resignation is the choice that recalled administrators are actually making in practice. They already know that there are at least 25 editors who believe they should be desysopped, at least some of whom will be keen to point out all their flaws and misdeeds again. Thryduulf (talk) 11:08, 11 June 2025 (UTC)[reply]
To be fair, we also haven't seen the case you describe where the vast majority of editors explicitly refuse to support the recall petition. It feels like, without any clear data points for admins recalled despite a clear majority opposing the petition, we can't really say anything with concrete evidence either way. Chaotic Enby (talk · contribs) 11:13, 11 June 2025 (UTC)[reply]
Indeed, we have exactly one datapoint about whether recall is leading to the correct outcomes (Graham87). Every other recalled administrator has chosen to leave the project - regardless of whether they should or should not have remained as an administrator this is not a good thing. Even discounting the pointlessness of explicitly not supporting a petition, in at least two cases the petition was certified so quickly that most people who would have commented (either way) were likely not aware that it was even happening.
What I'm primarily pushing back against are the claims that recall is working - admins leaving the project because 25 people don't like them being admins, with no opportunity for other opinions to be registered, it is very clearly not. Thryduulf (talk) 11:28, 11 June 2025 (UTC)[reply]
No admins have left the project: 4 editors have left the project because they had lost their admin status through a community-approved process. And "25 people don't like them being admins": it seems highly uniikely that only 25 people thought they shouldn't be admins any longer, the rapid influx of such opinions by a wide variety of editors was a clear indication that many others would have certified as well if the threshold hadn't already been met. What isn't a good thing is that people are so attached to their admin status that they don't want to remain part of enwiki when that status is removed. This isn't solved by refactoring the recall process though. Fram (talk) 11:46, 11 June 2025 (UTC)[reply]
Wikipedia is supposed to work on consensus. Your (or my) theories about how many people would or would not certify and/or support or oppose an RFA are entirely meaningless.
What isn't a good thing is that people are so attached to their admin status that they don't want to remain part of enwiki when that status is removed. That's one theory as to why they chose to leave. Another theory is that a few vocal editors made them feel so unwelcome that they chose to leave rather than subject themself to more of the same. Both theories are equally supported by the available evidence. Thryduulf (talk) 11:52, 11 June 2025 (UTC)[reply]
I do not consider my theory any more or less meaningless than your theory, which you present as if it were both factual and meaningful. Thryduulf (talk) 13:21, 11 June 2025 (UTC)[reply]
Even discounting the pointlessness of explicitly not supporting a petition I actually don't think it is pointless – even if they don't count as votes (which makes sense as the petition would, in an ideal world, only be a thresholding mechanism), they provide reassurance to the admin being subject to the recall, and could convince them that a RRfA wouldn't be as painful. Again, purely theorizing, but encouraging this mechanism for informal discussion could make admins feel more confident to go to a (formal) RRfA afterwards. Chaotic Enby (talk · contribs) 11:47, 11 June 2025 (UTC)[reply]
There doesn't seem to be a problem that needs to be solved. Process works as designed, and so far none of the results have been shown to be problematic. Fram (talk) 10:43, 11 June 2025 (UTC)[reply]
And then four minutes later, in this same discussion, you write "Your (or my) theories about how many people would or would not certify and/or support or oppose an RFA are entirely meaningless." Anyway, if people want to solve a problem, they first have to show that there is a problem. Replying that only one has been shown to be correct (in your opinion) is meaningless as a reply to that statement. Fram (talk) 12:12, 11 June 2025 (UTC)[reply]
Thank you for explaining how you have misinterpreted my words to suit your point of view. We do not know that "the process has worked as designed" and it is decidedly the opposite of meaningless to point out that statements that you present as incontrovertible fact are actually nothing of the sort and are exactly as supported by the evidence as the exact opposite. Thryduulf (talk) 13:24, 11 June 2025 (UTC)[reply]
Your reply was obviously to "none of the results have been shown to be problematic", not to "process works as designed". IF I say "A and B", you reply with "not B", then don't expect people to read that as "not A". As usual, no point having a prolonged discussion with you. If 1 out of 5 has been shown to be correct, and 0 out of 5 have been shown to be incorrect, then "exactly as supported by the evidence as the exact opposite." is obviously false as well. See also the above, where you call your own theory "entirely meaningless" but see no harm in spouting it anyway. Fram (talk) 14:03, 11 June 2025 (UTC)[reply]
Should there be some sort of policy to state that transgender people are transgender?
It can be confusing in some contexts to read an article that doesn't mention at all the fact that someone is transgender. I think there should be some sort of guideline to make it clear. Pxldnky77 (talk) 09:02, 9 June 2025 (UTC)[reply]
I guess "confusing" wasn't all encompassing. Being transgender is an important piece of information, along with things like age and hometown. It's something that the reader of a person's Wikipedia article should know about the person. You shouldn't have to look up "Is this person transgender" outside of Wikipedia in order to figure that out. I know most articles on transgender people include that information in one way or another but it might be helpful to have it as a standard in the infobox or something. Pxldnky77 (talk) 09:27, 9 June 2025 (UTC)[reply]
That probably covers any concerns I had on the topic. I'm fairly new to editing and Wikipedia manages to be a step ahead in any improvements I can think of. Thank you for the guidance. Pxldnky77 (talk) 09:43, 9 June 2025 (UTC)[reply]
See WP:DEADNAME - We respect the gender identity that is stated by an individual, and unless they or extremely high quality RSes have noted themselves as being transgender, we do not include that fact. Masem (t) 12:04, 9 June 2025 (UTC)[reply]
Also, it might be a personal privacy (and even safety) aspect if the person is not out as transgender, or wants to keep a low profile about it for various reasons. Chaotic Enby (talk · contribs) 12:25, 9 June 2025 (UTC)[reply]
Exactly. I know of one case of a transgender person where editors were improperly using court documents to affirm that (this was back during Gamergate so you can probably guess why they wanted to show that), which is why if are going to be including if someone is transgender, it needs to be a self-statement, or something well and clearly documented in high quality RSes appropriate for a BLP. Masem (t) 12:33, 9 June 2025 (UTC)[reply]
WP:PEOPLECAT doesn't have something about trans people specifically, but, as per the general guidelines, they would only be categorized that way if being trans was a defining part of their notability. Chaotic Enby (talk · contribs) 13:43, 9 June 2025 (UTC)[reply]
Category:Transgender people (and subcats) exists and is probably used a little more often than PEOPLECAT would recommend. We also have Category:Transgender rights activists, which would be expected to include trans and cis people who are activists for trans rights.
I find that there are two main approaches to cats, roughly minimalist and maximalist. The difference is most obvious in large articles, especially large articles about BLPs. Michelle Obama is my usual example. There are 52 cats on that page right now.
The extreme minimalists say "We should only have cats if they're Wikipedia:Defining. Michelle Obama's defining characteristics are that she was the first Black woman married to a US president. Oh, and because we'll generously compromise, you can add the cat for the year she was born and Category:Harvard Law School alumni."
The maximalists (who have clearly won that article, BTW) say "Let's add a category for everything we associate her with. But we, too, can generously compromise: We'll limit it to the top fifty or so categories."
I suspect that the latter approach is guided by the notion of cats as being similar to lists. The point, therefore, isn't that Obama's old law firm is super important to her reason for being notable; the point is that Category:People associated with Sidley Austin itself would be incomplete if her name wasn't listed there. WhatamIdoing (talk) 20:30, 11 June 2025 (UTC)[reply]
Thanks for the ping. Currently we're getting very close to a complete setup.
I'm automatically porting certain graphs from demographics related pages. I'm happy to consider any other highly repeated graphs.
Marking a graph as Template:PortGraph is the current method of finding graphs to port.
@Snævar wrote a script to mark automatically portable graphs that use Template:Graph:Chart for User:GraphBot to port. When this becomes active hopefully marking graphs for porting would be as simple as adding a name= attribute to a graph that uses Template:Graph:Chart.
There still are about 14,000 pages in need of porting, so even if it was as simple as adding a name attribute, that'd need to happen atleast 14,000 times (some pages have multiple graphs).
Spanish wikipedia, like English Wikipedia, also has around half of its graphs using Template:Graph:Chart. It would make sense to see if they are interested in GraphBot. Other wikis have a lower percentage. Eastern Europe has graph templates originating from Russia.
I might expand my script that marks automatically portable graphs by applying it to other graph templates. Then we know all of the graph template transclusions that can be ported, and which ones are waiting on WMF.
Wikipedia:Graphics Lab/Resources/Charts has an explaination of how the .tab and .chart pages work.
Myself, Tacsipacsi and Theklan (a greek user) have agreed to how graphs which use datapoints from wikidata will work. An example of that kind of template is Template:Graph:Lines.
I'm curious as to how the datapoints from wikidata will work. I'm happy to support the Spanish wikipedia if they are interested. GalStar (talk) 22:25, 16 June 2025 (UTC)[reply]
It's a nice idea, but it'll never pass. If we changed it for Pride, it would create a precedent of changing it for other events as well; who gets to determine which events merit such a change and which don't, and how do we avoid appearing politically biased in the process? DonIago (talk) 16:34, 10 June 2025 (UTC)[reply]
@155.190.1.6 Put another way, there's a difference between flying a pride flag to Keep Up with the Joneses and really being a part of the gay rights movement. If Wikipedia were an organ of the furry fandom, this would make sense, but alas, we might be better off raising awareness for autism and type 2 diabetes. Shushimnotrealstooge (talk) 04:22, 15 June 2025 (UTC)[reply]
Turn WP:ClosingDiscussions into a guideline
It's been recently pointed out once again that Wikipedia:Closing discussions is an information page. However, it effectively commands the respect of a guideline already. And unlike e.g. BRD, I can't see a reason why this shouldn't be a guideline. The talk page archive seems to imply it was a guideline proposal that went stale. What do we think? Aaron Liu (talk) 03:15, 11 June 2025 (UTC)[reply]
Offhandedly I could see objections arising because it's not worth the bother, though admittedly that line of thinking ends up proving too much. Another concern is that sometimes informal norms can be better when the community disagrees on specifics of implementation, and yes I'm aware of the counterarguments to that line of reasoning as well.
As to the question to whether it really documents accepted community practice, on a first read it seems fine, but I'm largely inactive these years so it's possible there are shifts I've missed. 184.152.65.118 (talk) 01:45, 12 June 2025 (UTC)[reply]
Having edit histories show net increases in an article's length in green, and decreases in red, can encourage editors to think that more is always better. Often, it's the opposite, whether in terms of expressing the same information more concisely, or removing information that is irrelevant to most people who are reading about a topic. I suggest that this formatting be changed, so that it's always the same color, or two colors be used that do not convey a value judgment (purple and orange, say).
Robert (talk) 17:28, 12 June 2025 (UTC)[reply]
The colours do not have a "value judgement". That is just a convention for markup. Red can mean lucky or could mean stop. Green could mean environmentally friendly or go. But here is means a count of removed or added. Redis more likely to be problematic than green, but vandals can add rubbish as well as remove good text. You can change your own style sheet to your preference. For red you will be wanting to set class="mw-plusminus-neg" to purple and change green on "mw-plusminus-pos" to orange. let me know if you want the exact .css text. Graeme Bartlett (talk) 11:44, 13 June 2025 (UTC)[reply]
BHL
The Biodiversity Heritage Library is very widely used here and on other projects and is an invaluable reference, but it is currently in a bit of trouble and looking for "partnership opportunities to support its operational functions and technical infrastructure" after the Smithsonian Institution opted to "conclude its long-standing role as BHL’s host on 1 January 2026". Is the WMF able to help in any way? Cremastra (Go Oilers!) 23:58, 12 June 2025 (UTC)[reply]
The people who can answer that question are unlikely to see it here. Somewhere on Meta is probably your best bet, but I don't know off the top of my head where. Thryduulf (talk) 00:50, 13 June 2025 (UTC)[reply]
Further input is needed at Wikipedia talk:Four Award#Why not use the draft symbol instead? as I think it's a great idea. Looking back at the icon, it really doesn't make sense why a "no opinion" icon would represent the start of an article. We already have a dedicated symbol for that; though I do see why people would want to not change as the icon has remained the same for 16 years. Generalissima has made this new potential icon incorporating the draft symbol. Yelps ᘛ⁐̤ᕐᐷ critique me09:07, 14 June 2025 (UTC)[reply]
Adopting superscript for ordinal numbers
If I want to read the English Wikipedia article on the thirty-eighth parallel, I should see the T-H written in superscript after the Roman numeral 8. In my opinion, "38ᵗʰ" is correct and "38th" is not, and we don't need to buy little letters cast in lead to publish this the right way. Shushimnotrealstooge (talk) 03:51, 15 June 2025 (UTC)[reply]
Even if the editors at the Style Guide don't agree to this now, if Wikipedia has code to automate this ready to go, that would make the change much, much easier and then worth considering. Shushimnotrealstooge (talk) 04:13, 15 June 2025 (UTC)[reply]
What are you requesting? The link Do-Re-Mi has punctuation, and the two links you gave are piped to text with punctuation. Are you asking for wiki to automatically insert punctuation and, if so, based on what criteria? This seems like a case where stet should apply. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 12:22, 15 June 2025 (UTC)[reply]
In this case I would also agree with Chaotic Enby in that I also think the first looks cleaner. To me the second suggests that somehow the apostrophe/quotation mark is relevant to "Do" in this case, which makes it more confusing (at least for me) Emily.Owl ( she/her • talk) 19:39, 15 June 2025 (UTC)[reply]
Telling me which of two phrases is clearer is irrelevant. What is it that you are requesting? Adding punctuation? Removing punctuation? E, none of the above?
They are asking for the trick where links automatically include other letters (eg. [[duck]]s becomes ducks) also apply to punctuation. CMD (talk) 03:31, 16 June 2025 (UTC)[reply]
And also for it to apply to punctuation preceding the link, e.g."[[Sergeant]] Adams" producing the same output as [[Sergeant|"Sergeant]] Adams", and "[[Solfège#Movable_do_solfège|Do]]: producing the same output as [[Solfège#Movable_do_solfège|"Do:]]. Thryduulf (talk) 10:44, 16 June 2025 (UTC)[reply]
I'd oppose that change since general convention for hyperlinks for the past decades across the Internet has been not to include leading or trailing punctuation in hyperlink text. Similar to how trailing punctuation should not, in general, be bold or italic even if the preceding word(s) is/are. Skynxnex (talk) 13:30, 16 June 2025 (UTC)[reply]
Proposed mechanisms for improved Wikimedia database distribution
I am presently working on a proposal/project named TetWix which aims to develop mechanisms that facilitate quicker and easier ways to distribute large-form Wikipedia content like the Wikipedia database downloads in a fashion that should hopefully transfer a large burden of data service and bandwidth costs from WMF resources to volunteers in the userbase, primarily by employing technological approaches which avoid the need (And reduce the desire) to download a large (~25GiB for the English Wikipedia) data dump every two weeks.
It is hoped that this proposal/project may help to make access to Wikimedia datasets much quicker and easier for the majority of users who like to keep local copies of the databases - Primarily by making these inherently compatible with and distributable via Bittorrent - While at the same time considerably reducing WMFs data export bills and equipment operating costs. It may also make Sneakernet-based distribution of Wikimedia content and updates easier in locations where internet access is slow, non-existent, or prohibitively expensive.
Howdy! I've been meaning to propose something like this for a while, based on an idea of Tamzin's that we fleshed out together – there's a gap in our coverage for people and institutions who aren't quite notable but have a lot of notable creations or alumni. They don't qualify for standalone articles, but there are multiple equally plausible redirect targets, so they just remain redlinks. For example, Neal Agarwal is the creator of Stimulation Clicker, The Password Game, Internet Roadtrip, and Infinite Craft, but there's only really one source directly about him and all of these would be equally plausible redirect targets. Under policy, there could be a list article under the WP:LISTN clause allowing navigational aids, but local consensus enforcement of that idea is very hit-or-miss, so it wouldn't be a great use of time for someone to go around and start creating those lists.
This kind of reminds me of Navigation pages above! This idea of "directory navpages" for non-notable folks was brought up as an argument against navpages, but also fits the "multiple equally plausible redirect targets" spirit, and might absolutely be something to consider. Chaotic Enby (talk · contribs) 10:52, 17 June 2025 (UTC)[reply]
Can't believe i didn't notice that at all! I like that concept, but I do share a lot of the concerns people are expressing about navpages in that section – directory articles are a narrower idea because they play into already-existing notability guidelines. "Here's a bunch of places you could read about this person/event" might be useful some day, and that does fit into the broader concept of a multi-soft redirect, but it can't be written as a list article so it'd require some significant new policy. I'm mostly looking at lists of notable articles that fit into the scope of "projects by [creator]", "alumni of [institution]", "publications/projects by [institution]", "subsidiaries of [institution]". theleekycauldron (talk • she/her) 11:03, 17 June 2025 (UTC)[reply]
One of the unfortunate conflicts at AFD is that some editors, usually seeing themselves as having high standards, reject the idea that a couple of sources about A, a couple of different sources about B, and a couple of different sources about C can all add up to a decent Wikipedia article about A+B+C. They're usually saying "Where are links to at least two independent secondary sources containing at least 300 consecutive words exclusively focused on whatever we named the article? Because obviously these seventeen sources about the {author's many books|company's many products|singer's many albums|director's many films} can't result in an article that merges all of the {books|products|albums|films} into a single thing and gets titled by the maker's name."
Yes, this is an important question! The AFDs I've seen tend to agree that WP:NCREATIVE#3 can function as a standalone SNG if sources focus on the creator's works. There is much less agreement about related criteria such as WP:NACTOR#1, and whether a company/organization can pass WP:NORG just by having notable products. I will admit that I previously PRODed an article about a company with two notable products that had their own articles. Helpful Raccoon (talk) 23:14, 19 June 2025 (UTC)[reply]
Add a language-switch prompt when a search yields no results
Currently, if a search fails on a non-English Wikipedia (e.g., Swedish), users receive no prompt to check other language versions. To find the article, they must either:
Manually navigate to www.wikipedia.org (which isn’t linked on the failed search page), or
Search for a widely translated article (e.g., "Adolf Hitler") and switch languages from there.
Edit the url (e.g. en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab) ➜ de.wikipedia.org/wiki/Wikipedia:Verbesserungsvorschl%C3%A4ge/Feature-Request) but this is tedious and often fails unless the article name is the exact same in both languages.
Use the language properties tab under the main menu column. (unintuitive, complex, too many clicks and does not even work the way it is supposed to).
This causes unnecessary strain both for users and wikipedia servers. My suggestion is to add the language selection prompt next to the search bar or at the upper right corner where it usually sits for most articles. This feels like a fast and easy solution to me. One could also improve on this further and translate the search term via some dictionary, gpt or online translator and give suggestions for articles in other languages that contain that term (e.g. This article doesn’t exist in [current language]. Try: [English] [Deutsch] […]" (linking to the same search term in other languages). Rgamer2005 (talk) 14:16, 17 June 2025 (UTC)[reply]
If you precede the search term with the other Wikipedia's language code, the search result should take you there. E.g. searching de:Inge Lange will take yo to the German Wikipedia entry. -- Michael Bednarek (talk) 15:07, 17 June 2025 (UTC)[reply]
This does exist, but has some limitations on when it appears; IIUC, it's computationally-intensive to search all the wikis, and if there are too many results from multiple wikis then it's difficult to programatically select the optimal results. (and other limitations). The technical docs and details are at mw:TextCat, and the example at the top still works: "As an example, searching English Wikipedia for málvísindi (‘linguistics’ in Icelandic) gets no results, so results from the Icelandic Wikipedia are shown." IIUC, that section of search would disappear if/when we have more local search results (and other factors). I hope that info helps! P.s. I've passed along this idea to the devs, in case it helps spur additional features. Quiddity (WMF) (talk) 19:03, 17 June 2025 (UTC)[reply]
That will help almost nobody. It's literally a rounding error. It would only affect logged-in editors, to begin with, and among them, it would only affect the tiny minority that have a Babel boxes in their userpage. A quick insource: search indicates that there are maybe 60K user pages with Babel boxes at enwiki – total, for all time. Category:User en and its subcats contain about 90K user pages with Babel boxes and/or equivalent. Let's say that it's a cool 100K editors. Since more than 95% of registered accounts haven't made any edits for over a year, probably less than 5K Babel-labeled accounts are active. But let's round up to 10K, for easier math.
Last month, we had 1.15 Billion-with-the-big-B unique devices reading at least one page on the English Wikipedia. That's 1,150,000,000 readers for at most 10,000 editors. That means 1 logged-in editor might have a Babel box for every 115,000 visitors. That's just 0.00087% of readers.
Various branches of mathematics use commutative diagrams, i.e., directed graphs whose edges represent functions and where the composition of functions between two vertices is the same for every path between those vertices. CTAN[1] has several packages[a] that simplify drawing, and usig one of them inside of <math>...</math> would be much more convenient than building diagrams outside of wiki and importing them as images. -- Shmuel (Seymour J.) Metz Username:Chatul (talk) 14:18, 18 June 2025 (UTC)[reply]
I'am 13 and reading it for reading time and I came across red when it says and I'm surprised because there's kids in grade 4 reading Wikipedia
did think before making the did you know. look at the last one it says. "that the Fuck Tree has been described as a "physical embodiment of desire"?
hover over the link and read what it says
I remember taking my son to Hampstead Heath nearly 40 years ago when he was about two years old and unwittingly straying into the gay cruising area (I happen to be straight). We met some very nice people and the experience didn't do him any harm. What exactly are you complaining about? Phil Bridger (talk) 18:44, 19 June 2025 (UTC)[reply]
I am conducting research (for my Masters) on content-gaps related to orphan articles. I am doing my best with Wikidata, but I cannot seem to find the appropriate attribute or combination of attributes that would let me extract orphan articles.
For context: An orphan article is one that has no other articles referencing to it. (Wikipedia:Orphan)
Does anyone have any pointers?
So far, I am using following two lines of SPARQL to narrow down orphan articles, but when I check the resulting list of articles, any given article does have links when I look under What Links Here.
Hi Peaceray! Thank you for the super quick response. I did look into this for the English Wikipedia. However, I need to extract the orphans from different languages. Spanish, for example does not use the categories for their orphans.
I have so far found a very inefficient way to do it... And I am hoping to get some help from the community to optimize this! (I posted it on Request A Query). If you have any advice. I would be very grateful. MNSanchez (talk) 14:04, 14 June 2025 (UTC)[reply]
@MNSanchez to add to the comment above, you can't do this through Wikidata - that does not have any information about article to article links on individual wikis. Using "wikibase:sitelinks" will get you the number of links on Wikidata to individual language versions of that article (and any Wikidata item with sitelinks=0 would this presumably have no linked Wikipedia article)
I actually did find a way to do it through Wikidata using the mwapi API in SPARQL. It works, but it is very slow and times out, which I am hoping to resolve with the help of the community (See here).
I am curious about Quarry. I will have to play around with it to get familiar with it because I have been spending all my energy into the SPARQL query I mentioned earlier. If you have any advice either regarding how to get started with Quarry or about the SPARQL query, I would appreciate it a lot!
Oh interesting! Yes, I had forgotten the magic of invoking the API within a query. I think for this particular use case it will be impractical - just too many articles involved if you're needing to look at "all women". I'll follow up over there. Andrew Gray (talk) 17:37, 14 June 2025 (UTC)[reply]
This seems suboptimal (not even counting the "demostration" misspelling). I'm concerned that if I use it as is, either it's subverting the CDN functionality (I know, not my problem), or it's going to break at the drop of a hat.
Any thoughts here? I'm really not sure if there's any other possible answer than "just use it and move on", but I wanted to see if anyone else has some clever ideas here. NapoliRoma (talk) 19:00, 11 June 2025 (UTC)[reply]
I think all citations added to Wikipedia get archived by archive.org automatically after a couple hours/days. So if it does break it should be easy to add an archive link. Once the reference is archived, you can use a tool such as User:InternetArchiveBot to get the archive URL added to the citation (click "Run InternetArchiveBot on a specific Wikipedia article"). –Novem Linguae (talk) 19:12, 11 June 2025 (UTC)[reply]
I hadn't really thought about a URL being part of the seal of legitimacy of a source, but I see how it could be considered in that light. For now, I've just used the standard {{cite web}} template, describing the web site as being the same California agency as for the page it's linked from. NapoliRoma (talk) 02:33, 12 June 2025 (UTC)[reply]
Israel Palestine articles have a sourcing problem
I feel like I/P articles have a very big issue of an excessive use of problematic sources, especially on less popular I/P articles. Usually these articles are either minor incidents from the ongoing Gaza war where the only reporting that is readily available is from problematic sources. The most common problematic sources are Al Jazeera English which is listen the Perennial sources page as biased on I/P and Middle East Eye which is 75% owned by the "former director for the Hamas-controlled Al-Quds TV" according to its Wikipedia Page. I could go ahead and try to change on of these articles but theres too many for me to get through, I feel like something more systematic and top down is needed. Denninithan (talk) 23:45, 11 June 2025 (UTC)[reply]
You should probably get consensus before mass removing a generally reliable source. Perhaps others may disagree that the use of this source is a problem. –Novem Linguae (talk) 01:37, 12 June 2025 (UTC)[reply]
Where would I even go to get consensus on something like that, I haven't really spent much time on the policies side of wikipedia usually I just write stuff. Denninithan (talk) 01:53, 12 June 2025 (UTC)[reply]
If it is about a particular use of a source, the article talk page is the place. If it is about then general use of a source, it is WP:RSN. However, before you start a section on a source at RSN you should read the previous discussions about those sources at RSN and also look at their entry in WP:RSP. If you don't have more to offer than was already discussed, you might consider whether restarting the same discussion again with the same evidence has a chance of a different outcome. Zerotalk03:07, 12 June 2025 (UTC)[reply]
Are there Israeli sources that you think may have the "excessive use" and "problematic" features from the ongoing Gaza war? I ask because the reporting environment in Israel is quite difficult right now in terms of reporting restrictions. Sean.hoyland (talk) 06:06, 12 June 2025 (UTC)[reply]
It's important to remember that it's officially okay for sources to be biased (WP:RSBIASED). The goal is for Wikipedia editors to behave in an unbiased way, so that the result is an article in which Wikipedia editors have fairly and proportionately presented the views of all the reliable sources – including biased reliable sources. WhatamIdoing (talk) 02:33, 15 June 2025 (UTC)[reply]
CentralNotice for Bangla Wiktionary Entry Contest 2025
A contest will take place from July 1, 2025, to July 31, 2025, on Bangla Wiktionary to enrich its entries. A central notice request has been placed to target both English and Bangla Wikipedia users, including non-registered users from Bangladesh and the Indian state of West Bengal. Thank you. Aishik Rehman (talk) 20:49, 13 June 2025 (UTC)[reply]
When I tried to identify the language of the text in "Latin script" with "Google translate". It did suggested me "Tamil" as a language.
Now , I read your message. I think that there are a high probability that the text was wrote in "Tamil" with "latin characters" instead of "Tamil script".
You could try asking the person who posted it, either on the article talk page or the user talk page. It's unlikely, but you could possibly get a reply. Phil Bridger (talk) 09:30, 14 June 2025 (UTC)[reply]
I think likewise that he can post a message on the "User talk page".
The language appears to be tamil. I'm guessing that Silambarasan is locally famous in India (or part of it) for singing that particular song, and that the IP who added these lyrics doesn't understand much about English Wikipedia, and it's a good question as to whether they understand English. We of course assume good faith and that they were trying to add relevant and accurate content.
This year, the Wikimedia community will vote in late August through September 2025 to fill two (2) seats on the Foundation Board. Could you – or someone you know – be a good fit to join the Wikimedia Foundation's Board of Trustees? [3]
Learn more about what it takes to stand for these leadership positions and how to submit your candidacy on this Meta-wiki page or encourage someone else to run in this year's election.
Best regards,
Abhishek Suryawanshi
Chair of the Elections Committee
On behalf of the Elections Committee and Governance Committee
During the last round, I wrote m: User:WhatamIdoing/Board candidates to describe my view of what's needed and often missing in Board candidates. Specifically, editors from this community tend to look at the board as "How do I get an admin from the English Wikipedia elected?" IMO we need to be thinking more like "How do I get someone who can read a balance sheet elected?" Being able to run WP:AWB does not make you suited to working on a committee, or to allocating a US$175,000,000 budget. WhatamIdoing (talk) 18:35, 18 June 2025 (UTC)[reply]
Paid editors question
If I suspect that certain editors are undisclosed paid editors, what is the best way to handle that without causing undue drama? Nosferattus (talk) 16:20, 18 June 2025 (UTC)[reply]
A question about accessibility. When I watched the demo video, it looks like the default position for the "simple summary" was collapsed. For our visually impaired readers and editors who use screen readers to access Wikipedia, would this summary be available to them/us. Because in order to view and/or hear the summary, it requires interaction (clicking on it to open it), which obviously screen readers are not capable of. And per our guidelines at MOS:COLLAPSE, content in an article (if this summary is to be considered content), should never be collapsed by default. So how would this feature be beneficial to our visually impaired readers/editors if it is not accessible? We have alternative text for images, so has there been any consideration given by the develpers for alt text for this feature if it is to remained collapsed by default? Isaidnoway (talk) 07:47, 5 June 2025 (UTC)
Polygnotus (talk) 04:26, 5 June 2025 (UTC)
_error_message_Visual_Editor_reported_by_Liz.png?lang=en)
View all 33 community-submitted tasks that were resolved last week.
Courtesy link: User talk:Joe Roe § An idea 
Wonderful! JayCubby 20:54, 12 June 2025 (UTC)