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.
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.
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]
Oppose requiring NPP/rollback, these are two different rights and there is no reason why someone who needs temporary-account-checkuser needs to have rollback or NPP. The WMF has set requirements, why should we add in more convoluted requirements? 206.83.102.217 (talk) 00:30, 21 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]
Because with TAIV you can see multiple IPs that you know are from the same person/device, and having more IPs narrows people's location down and therefore has more potential risk. Sophisticatedeveningš·(talk)00:44, 21 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]
Thank you for replying @NKohli (WMF). Can you please also tell if it would be possible for us to communicate with temporary editors by messaging on their talk pages, if their TA keeps changing? I know a lot of people who clear browser history, cookies after each use, and those who use incognito. If I need to let them know something, what is the process I must follow? Thanks! āCX Zoom[he/him](let's talk ā¢ {Cā¢X})16:35, 21 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]
TAIV will never be "required" for vandal fighting. It might be "useful" for it, but you can fight vandals in many ways. If you can fight vandalism committed by a registered account without seeing its IP address(es), then you can fight vandalism committed by a temporary account without seeing its IP address(es). WhatamIdoing (talk) 03:44, 21 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]
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.
@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)7:08 am, 20 June 2025, last Friday (3 days ago) (UTC+8)
Thank you for replying @NKohli (WMF). Can you please also tell if it would be possible for us to communicate with temporary editors by messaging on their talk pages, if their TA keeps changing? I know a lot of people who clear browser history, cookies after each use, and those who use incognito. If I need to let them know something, what is the process I must follow? Thanks! āCX Zoom[he/him] (let's talk ā¢ {Cā¢X})12:35 am, Yesterday (UTC+8)
@EggRoll97 @CX Zoom Apologies I couldn't reply sooner. I was out sick.
To EggRoll's question, we have overhauled the IPInfo policy to have only one right `ipinfo-view-full` going forward. It has the same access permissions as TAIV. Anyone who has TAIV on wikis where temporary accounts are deployed, will be able to also turn on IP Info. Like you said, the basic right was far too basic to be meaningfully useful.
To CX Zoom's question: If a user's temporary account keeps changing it would limit our ability to reach out to them. If users keep clearing their cookies they will not be able to receive notifications about messages like other temporary accounts would. Unfortunately there is no good mechanism to get around this. However, we are hoping this to be a minority of users instead of the majority.
Additionally, after 6 temporary account creations in a 24 hour period, there will be an account creation throttle (similar to how it is for registered accounts) and the user won't be to create any temporary accounts for a day. We will nudge the user to create a permanent account if they want to edit at this time. We have data monitoring in place to see how often this limit is hit. I've filtered this dashboard to show data from Norwegian, Korean and Czech Wikipedias if you are interested. The graph for "Temporary account creation rate limit hits" shows how often this limit is hit. Note that we deployed to Norwegian over 6 months ago and Czech and Korean were deployed to last week.
@CX Zoom Yes, pretty much. Unless some non-logged-in users have bookmarked their particular talk page(s) and use them to communicate (I don't expect this to happen much). -- NKohli (WMF) (talk) 10:42, 24 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]
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]
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]
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]
Stray more-of-a-proposal-than-a-policy-but-relevant-here thought: Would it be possible/make sense to just automatically block display of NFC if called from non-article space? That way, the draft article could be constructed with appropriate image tags in place (although I would not be of help for new NFC content only meant for the draft article, rather than reuse of of NFC content already used elsewhere in article space.) I see three routes to implement this... even though I know basically zip about the tech end and these all could be undoable:
Build it into the image server, which will only put out an NFC image if going to article space. Ideally, if it's going to Draft: space or to a subdirectory of user space (i.e., not User:NatGertler but to User:NatGertler/List_of_most_fabulous_things) would put a placeholder image there.
Create a template that goes around file/image tags that will simply put through the file if it's in article space, put through the placeholder if it's in draft space
Add an NFC variable to image tags that would cause the image not to be displayed if in inappropriate space. (Admittedly, no help with infobox images, which is probably a larger portion of what we're discussing.) -- Nat Gertler (talk) 17:48, 23 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]
But why do you need the image before you finish the draft? Most comparable online encyclopaedias do not allow non-free content at all so it does not seem strictly necessary. āKusma (talk) 12:50, 23 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]
NFEXMP is, as described, use of non-free outside of mainspace necessary for maintaining the encyclopedia or where there are technical limitations. It would be completely inappropriate to add draft space to be covered by NFEXMP because non-free in draft space is not essential towards maintaining the encyclopedia. Masem (t) 12:42, 23 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]
Agree with Levivich and S Marshall, of course free as in liberty is a wonderful side effect for most of the content on WMF projects, but an actually complete encyclopedia has to exist in the world as it exists (with mass media and copyright laws). To not avail ourselves of fair use allowances (or comically limit ourselves with WP:IMAGERES nonsense that claims to be a "suggestion" but has a bot actively running around resizing images to resolutions that are only viable if you're viewing on a screen from circa 1999) is counterproductive to that goal. āLocke Cole ā¢ t ā¢ c17:33, 22 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, and 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]
Why is this any different from having public domain images in drafts, which is unequivocally allowed? Or having either kind of image in an unreviewed BLP in mainspace? There is no actual legal distinction between draftspace and mainspace. BD2412T17:17, 22 June 2025 (UTC)[reply]
NFCC #9 was added in October 2005, in the second-ever edit to the page, and subsequently edit-warred over in December of that year.
The creation of the Draft: namespace was formally proposed in November 2013. I think it is fair to say that the Draft: space was not considered when the NFCC rule was put in place. However, given the blanket ban on not using fair-use images in User: space (where editors sometimes drafted articles), I doubt that the result would have been any different if they had. WhatamIdoing (talk) 01:53, 24 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]
Draft space is an extension of article space. Articles and drafts share the same guidelines and policies. The difference between the two is that drafts may be deficient, in some way, towards meeting some combination of guideline and policy. Drafts are supposed to move closer to ending up how an article should look. It seems an odd aberration to have a not uncommon part of creating an article be barred from being used on a draft. Some problems this causes are mentioned above, but another key one might be that this prevents someone working on a draft from figuring out how NFC should be included in an article, defeating the purpose of draft space in that regard. This means that any experiments/learning regarding NFC must take place on live articles, which doesn't seem a sensible policy place to be in if we are concerned about the correct use of NFC. CMD (talk) 19:24, 22 June 2025 (UTC)[reply]
An issue is that draft space articles are not always "live" in that the editor might start it and then walk away without doing any further updates, which then after six months they should be deleted. But then keeping NFC uploaded to support that draft while those six months progress makes no sense when unused NFC in mainspace is supposed to be deleted after seven days.
Perhaps when checking for non-free through bots we try to identify that there is reasonable work over time to continue to improve the draft then the NFC can be kept in the draft, the idea that the draft article is still "live" because there is active work to get it ready for main space. Masem (t) 19:53, 22 June 2025 (UTC)[reply]
unused NFC in mainspace is supposed to be deleted after seven days If it's currently in use in a draft that has yet to be deleted, then it is not unused. We don't need a different time limit for Draft-space NFC. āLocke Cole ā¢ t ā¢ c20:01, 22 June 2025 (UTC)[reply]
I had thought about this type of scenario, and in combination with CMD's comment, if we made so that a draft article could keep NFC as long as it was determined to be in active development, that would allow images from draftified articles to remain as long as there was good faith effort to improve the article. But we still have the issue that articles get draftified from AFD the time and no one spends any time to improve it to get it back to mainspace in the short term, so we have those existing NFC going unused in a "dead" draft outside of mainspace, so we eventually need to remove those images to meet the WMF mission. Masem (t) 19:57, 22 June 2025 (UTC)[reply]
Support The proposal is clearly sensible for the reasons given. Articles are supposed to be moved to-and-fro between article and draftspace and it would be disruptive to treat them differently in this respect. Andrewš(talk) 19:58, 22 June 2025 (UTC)[reply]
Thanks, yes, I had not even touched on the fact that sometimes articles containing fair-use images are moved to draftspace for improvement. BD2412T20:08, 22 June 2025 (UTC)[reply]
Support We already allow non-free images outside the mainspace (in the File space). The proposal to allow images in the Draft space is both reasonable and sensible. Articles not being worked on in the Draft space get deleted, and the non-free images used will then get automatically deleted too if they are not used by another article. Hawkeye7(discuss)20:23, 22 June 2025 (UTC)[reply]
Oppose, (a) articles are usually drafted in user space (WP:DUD). (b) Non-free files are not needed in unfinished articles not shown to readers. Minimal use of non-free clearly means we restrict to articles. āKusma (talk) 20:37, 22 June 2025 (UTC)[reply]
@Kusma: This proposal is only for draftspace. From the perspective of the real world outside of Wikipedia, there is no legal distinction between these spaces. BD2412T16:07, 23 June 2025 (UTC)[reply]
There is no legal distinction between any of our namespaces; user space and MediaWiki talk are covered by the same laws as draft space. Our non-free content criteria are deliberately much stricter than what is legally possible. You have been here long enough to remember the time before non-free images were purged from user space and when people were claiming fair use quite liberally. āKusma (talk) 16:14, 23 June 2025 (UTC)[reply]
We have had a long history of editors using userspace as if Wikipedia were Myspace or Facebook. I can see a legal factfinder being skeptical about the presence of copyrighted works in such spaces. Not so with a draft space set aside by policy as a place to develop main article content. BD2412T17:08, 23 June 2025 (UTC)[reply]
But we have had editors use users pace to develop draft articles, and I am pretty sure (but not in a place I can easily search to verify) we've determined that user's pace even if used for this purpose should allow for non free use. Yes, draft space is meant to be exclusively on draft development, but at the same time it is not part of mainspace nor searchable like mainspace. As the WMF has said NFC should only be used in conjunction with educational content, draft space articles, even with good faith to be made into mainspace, are not educational materials until they are actually moved there. Masem (t) 17:22, 23 June 2025 (UTC)[reply]
Oppose - Not really seeing much positive given the place holders and could see negative since it is against WMF requirements and has legal implications. PackMecEng (talk) 01:17, 23 June 2025 (UTC)[reply]
What "legal implications" do you see? Other commenters have explained how in their view that there is no legal relevance to article space vs draft space, why do you think they are incorrect? Thryduulf (talk) 09:41, 23 June 2025 (UTC)[reply]
I'm not expressing an opinion on which is correct, but the reasoning behind the view that there are no legal issues has been explained in detail and contains no flaws that are glaringly obvious to me. In contrast the view that there are legal issues has not been explained so I have no idea what part(s) of the contrary view they disagree with or why they disagree with it, so I can't tell whether it is based on incontrovertibly sound logic and legal principals, is pure hogwash or somewhere in between. Thryduulf (talk) 15:47, 23 June 2025 (UTC)[reply]
The legal implications would be WMF getting sued for using non-free images? We have legal saying dont do it and the only counter I see is someone who claims to work in that field saying trust me a judge totally wouldn't take it seriously. That does not inspire confidence. So unless we have our legal giving the thumbs up or we can point to ANY tangible evidence from legal experts I'm going to side with WMF's guidelines to keep us from being sued. PackMecEng (talk) 17:26, 23 June 2025 (UTC)[reply]
the reasoning behind the view that there are no legal issues has been explained in detail and contains no flaws that are glaringly obvious to me Huh? We must be talking about different comments. I thought you were referring to this comment and this comment, neither of which contain any explanation of any reasoning at all, they just contain assertions (that the authors would be surprised if courts cared how many web pages on the same website contained a fair use image). (That's not a criticism of those comments; nobody is required to provide any legal explanations, and we're not going to resolve any legal questions on this website anyway.) Which comments were you referring to that explained in detail the reasoning behind the view that there are no legal issues? Can you quote the detailed explanation for me?
In contrast the view that there are legal issues has not been explained... Well, I'm not sure if there are any legal issues or not -- I think we should just ask WMF Legal to tell us the WMF's view on the matter rather than debating it amongst ourselves -- but I can imagine at least two issues that might be legal issues:
First, one of the four factors of fair use under US law is the impact of the use on the potential market for or value of the copyrighted work. Now I have no idea whether a court would consider a website that has a fair use image on multiple web pages to have a greater market impact than a website that has the image on only one web page. But I know that when it comes to the old-fashioned paper photocopying of copyrighted works, e.g. by a professor to hand out in a class, the number of copies that one makes is considered relevant to the market impact of the fair use, which is why university libraries will caution people not to make too many copies (example). Do "multiple copies" on a website work the same way as multiple photocopies? I don't know, maybe? I don't know of any US court decision about that particular question (doesn't mean there isn't one out there).
Second, US law provides statutory damages for copyright infringement, between $750 and $30,000. Some lawyers say that the "number of violations" is relevant to where in that (very wide) range of damages a defendant lands (example). Does having the image on multiple web pages mean you will get whacked on the higher end of the statutory damages range? I have no idea. I don't know of any US court decision about that particular question, either (doesn't mean there isn't one out there).
That's all just armchair speculation, there could be completely different issues/factors at play. That's why I'd defer to WMF Legal on the question. I'm not particularly swayed by other editors saying they think it's not an issue, just like nobody should be swayed by me saying it might be. Levivich (talk) 18:04, 23 June 2025 (UTC)[reply]
It's not an issue at least for en.wiki as our non free policy, which the WMF uses as a template for what is expected, addresses how all the NFCC steps are there to try to address the fair use defense, that should someone ever sue the WMF over our use of non free, WMF legal has a solid basis for evoking all four points of the fair use defense. It helps to remember thst on en. Wiki, this was a fair use policy starting around 2005, and built to aid in the fair use Defence. The focus shifted to NFC when the WMF made it a goal to make this a freely redistributable work and thus minimize the amount of non frees used. The fair use reasoning is still in NFC's DNA, to speak. Masem (t) 19:03, 23 June 2025 (UTC)[reply]
Oppose Masem highlights most of my concerns here. I could see the argument for allowing temporary stays on images as they're moved to draft space, but that would just encourage gamesmanship and an additional layers of rules and bickering we don't need. The reality is drafts languish all the time, and as a result non-free images would be parked in what is functionally userspace or back-of-house areas. Der Wohltemperierte Fuchstalk18:14, 23 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.
RfC on new temporary account IP viewer (TAIV) user right
Are political userboxes now allowed in Templatespace?
Back in 2006, political userboxes were userfied per WP:Userbox migration as a result of the Great Userbox War. Since then, it appears that a lot of them have popped up again in the Template namespace. Also, the index page for WP:Userboxes/Politics by country, which had been userfied following MfD in 2009, was moved back to Projectspace in 2020 by a now-indeffed user, apparently without discussion. I was would revert the move, but then 16 years is a long time for consensus to possibly have changed, so I thought I'd ask here first:
Is current consensus in favour of allowing political userboxes in the Template namespace? Where is the line drawn for those that should only be in Userspace?
That describes userboxes that are not allowed, period. My question, however, is about userboxes that are only allowed in Userspace and not Templatespace. The relevant guideline is under WP:UBXNS, which is rather vague. The convention was developed way back in 2006 and doesn't appear to have been clearly documented. --Paul_012 (talk) 14:22, 23 June 2025 (UTC)[reply]
Just curious as to what is sufficiently divisive to be banned. This user has an āanti-UNā user box, in addition to multiple pro-2nd amendment userboxes. They popped up in the anti-AI discussion using a signature saying āHail Meā and crosses that are similar to the Iron Cross. This was addressed on their talk page; where they disclaim any connection to Nazism, but refuse to remove the crosses. 173.177.179.61 (talk) 20:46, 23 June 2025 (UTC)[reply]
I failed to see why the ā have to be connected to Nazi Germany. I failed to see why multiple pro-2nd amendment and anti-UN statements are regarded as supportive to Nazism. I would again claim that I have no love for Hitler and Nazi Germany. I refuse to remove the ā from my signature as I didn't think that it is a symbol of Nazism. If you feel that the ā are sufficiently divisive to be banned you can go to WP:ANI for that. Have a good day. ā SunDawn ā Contact me!10:57, 24 June 2025 (UTC)[reply]
To clarify, I do not think the anti-UN and pro-2nd amendment userboxes are supportive of Nazism of themselves. But including them, along with several pro-Trump userboxes makes it clear you support fascist causes. Hope that helps clear things up! 173.177.179.61 (talk) 11:44, 24 June 2025 (UTC)[reply]
@Sock-the-guy and IP editor 173... this is the wrong venue for discussion of a specific editor, if you believe action should be taken then make your case, with evidence, at AN or ANI. If you don't believe action should be taken then stop talking about it. Thryduulf (talk) 17:26, 24 June 2025 (UTC)[reply]
Sure, Iāll restate my original question then. Is a userbox for being āanti UNā sufficiently divisive to be removed?
For clarification, I have only been browsing these boards for a couple weeks. I saw that this user was asked to adjust their signature, but there was no comment about the userboxes, so I was unsure if they were allowed or not.
I donāt know how to file an ANI unfortunately. That said, Iām not really interested in helping out a community that is pro-Trump, so as a queer Canadian, I guess Iām outta here. 173.177.179.61 (talk) 17:54, 24 June 2025 (UTC)[reply]
If User:SunDawn wants people to assume that they support fascist causes, then they are quite welcome to keep their signature, as long as they don't complain when people call them out on it. Black Kite (talk)18:42, 24 June 2025 (UTC)[reply]
All Userboxes should be moved out of template space. If you find one, move it.
The unresolved question is whether political Userboxes should be moved out of Wikipedia?
I've never heard of any guidance to that effect. Presumably you don't mean to include Babel boxes? But what about user group userboxes? WikiProject membership userboxes? Legitimate areas of expertise and/or interest? --Paul_012 (talk) 14:51, 23 June 2025 (UTC)[reply]
(edit conflict) All Userboxes should be moved out of template space. If you find one, move it. is this just your opinion? It's not something I've ever heard before and doesn't seem to match what is written at WP:UBXNS,
That's a historical page that proposes moving some userboxes to userspace and which explicitly eschews being a policy or guideline, it does not support your statement. Thryduulf (talk) 22:43, 23 June 2025 (UTC)[reply]
It describes the rationale and the practice, and it still occurs, and is often an MfD result. In my opinion nothing needs fixing, if someone doesnāt like a template space userbox, Userfy it to User:UBX. SmokeyJoe (talk) 03:19, 24 June 2025 (UTC)[reply]
Adding Official Sources as references
Please advise on why official sources such as Airlines and Airport websites cant be used when adding information to Wikipedia.
Using Indepandant sources provides incorrect information. For example using a outdated article from clare fm saying Shannon- Paris is ending in October. Which is wrong because the official Airline and airport site state its NOT.
Wikipedia is supposed to be reliable source providing old links like that is wrong and unrelibale. Please allow official sites be used AVGEEK7813 (talk) 09:23, 9 July 2024 (UTC)[reply]
They can? An airport's website would be a primary source, which can be used for straightforward, descriptive statements of facts like whether that airport has certain flights. āāÆJoe (talk) 10:13, 9 July 2024 (UTC)[reply]
Ok @TheBanner is convinced that only indepandant sources are allowed and not official sites. He is removing peoples updates that have been gotten from official sites and replacing them with old outdated links. AVGEEK7813 (talk) 10:23, 9 July 2024 (UTC)[reply]
That's not how it works I'm afraid. We don't have moderators. If you have a disagreement with The Banner (courtesy ping) about a specific source, you should discuss it with him and other editors on the article's talk page and seek a consensus based on policies like WP:V and WP:PSTS. āāÆJoe (talk) 10:41, 9 July 2024 (UTC)[reply]
In fact, it was a case where an independent source was just removed. No replacement, just removal. And an unsubstantiated claim that the source used was incorrect. The Bannertalk15:31, 9 July 2024 (UTC)[reply]
If a source is removed, usually the information the source supports should also be removed. The removal constitutes a challenge to the source and the information. If someone wants to restore it, the person adding it should include a different reliable source. Or, discuss on the talk page why the removed source is reliable after all. Jc3s5h (talk) 15:43, 9 July 2024 (UTC)[reply]
A simplified story might sound something like this: Is it okay to use a public blog post from an airline to say that they're going to offer a route between Airports A and B, or a press release from one of the affected airports? Or should we require a local newspaper or radio station to repeat what the press release says, because ā I don't know ā maybe the airline doesn't know where it's sending its planes? Or there's some secret skullduggery going on, and the local news outlet will ferret out the malfeasance involved in claiming to offer a route to the local airport?
Aer Lingus clearly is offering flights between Shannon and ParisāCharles de Gaulle; drop by your favorite airline website and see what happens if you try to book at flight between "SNN" and "CDG". It's a 1 hour, 45 minute flight, and the price for departures this Thursday is only US$156. Flight "EI 908" is scheduled to depart at 7:10 a.m., and if you happen to be in Shannon that morning, you could be on it.
So can we stop fighting over this? @The Banner, it's good to have the best possible source, but it's bad to leave something completely unsourced merely because the most easily available source isn't the best possible source. Two self-published, non-independent primary sources are available and reliable for the fact that Aer Lingus flies between SNN and CDG. If you want a better source, then find it yourself, but until then, don't remove primary sources and replace them with a {{citation needed}} tag. If you feel you must tag it, leave the mediocre source in place, and add {{better source}} after it. WhatamIdoing (talk) 02:43, 25 June 2025 (UTC)[reply]
Generally speaking, Wikipedia's purpose is not necessarily to be a conduit for an organization's PR, and WP:NOTDIRECTORY might be relevant for an airport's connections. Editors might want independent sources to show that sources actually care about a given announcement and establish WP:DUE for inclusion. āBagumba (talk) 03:01, 25 June 2025 (UTC)[reply]
I know we just had in the last year a large discussion about airline destinations and connections from airports, with the consensus generally supporting these, but I think this argument above (how we are sourcing information only stated by a company) is why these types of articles are problematic, violate NOT#CATALOG if they aren't using predominately third-party sources. this type of information at this type of detail is far far better located at Wikivoyage, whereas the encyclopedic article should be focused on the high level descriptions of routes and destinations as reported by third-party sources. Masem (t) 03:06, 25 June 2025 (UTC)[reply]
Yes, that is true sometimes. However, when Wikipedia is providing a complete list of certain facts (e.g., airlines that fly into this airport, or destinations with direct flights from this airport, or ā to switch subjects ā a complete list of books by this author, or albums by this band), then it's not a matter of an organization's PR: It's a matter of making it easier for editors to figure out whether or not the item belongs in the list.
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]
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]
Ascorbic acid is a furan-based lactone of 2-ketogluconic acid. It contains an adjacent enediol adjacent to the carbonyl. This āC(OH)=C(OH)āC(=O)ā structural pattern is characteristic of reductones, and increases the acidity of one of the enol hydroxyl groups. The deprotonated conjugate base is the ascorbate anion, which is stabilized by electron delocalization that results from resonance between two forms.
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.
Other ideas include enabling users to write an additional tl;dr text for article (& some section?) leads that can be displayed by users with a click. [show simple summary] next to the lead I think AIs could help with these, particularly due to the difficulty of writing things in a simple way and the sheer number (~millions) of relevant articles ā enabling such first may also make people see this. For articles that have a Simple English Wikipedia pendant (important note: few users find & read SEW articles!), the lead of that article could be shown when clicking that button.
Meant to say that people missing a shorter simpler version in addition to the generally fairly accurate but often too long or complex section/article lead is one of Wikipedia's biggest problems. It's why millions of potential readers often instead turn to either a) other websites that have simpler explanations (not written collaboratively, often including marketing, often inaccurate) and b) asking AI (not collaboratively controlled, often inaccurate).
In the current form AI summaries could be too problematic as still sometimes inaccurate even when just summarizing some text (note: this is not comparable to the high inaccuracy when it's new output rather than just a summary) but it would be good to have a structured rather than a long linear comment chain about the Pros and Cons of these since again it's possible it could be implemented in a positive way such as via including options for users to adjust, flag and regenerate summaries.
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]
Talk page edit that obliterated a lot of page
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.
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]
@Nardog @Jonesey95 @Robertsky Sorry, but we are not planning on making it a separate Beta feature. The wish has been requested for it to be a feature for everyone to have.
Since we are asking if you want to be one of the pilot projects, though, I can register your opinions as a "no, thank you". That's all I can do at the moment, but do know that this feature will be available to everyone, once the piloting phase it's over, but you can always choose to not use it in the end. Sannita (WMF) (talk) 10:23, 20 June 2025 (UTC)[reply]
That's like the literal opposite of what we've been saying, so I'm at a loss as to how you came to the conclusion that you can. We're saying make it available for everyone (i.e. on all wikis) already, just on an opt-in basis.
Unlike reader-facing features, a feature for editors should court feedback not from entire communities but from individual editors, who would not be able to give meaningful feedback if they couldn't test it across wikis they edit. Nardog (talk) 10:57, 20 June 2025 (UTC)[reply]
Sannita (WMF), you literally said that you were looking for testers, making it clear that this feature is not ready for production yet. But you're going to roll it out to all users on a given wiki? You are looking for feedback and ideas but have not set up a Wikipedia-space page to explain the feature and welcome feedback and ideas? Maybe I don't understand what you are hoping to achieve, because it doesn't sound like you want testers and feedback. ā Jonesey95 (talk) 14:03, 20 June 2025 (UTC)[reply]
@Nardog @Jonesey95 Yes, we are looking for projects that will test this new feature that has been requested through the Community Wishlist. We cannot do it as a beta feature, though, we can only put it available for the whole project, or not at all. I'm sorry if my communication isn't clear, as English is not my first language, but the communication was for English Wikipedia as a project, not as individual testers. Sannita (WMF) (talk) 14:38, 20 June 2025 (UTC)[reply]
OK, good luck. Please create a page at Wikipedia:Favourite templates (or a similar name) when the feature is ready. Explain what the feature is, how to use it, and what editors it is compatible with. I do not have a "template dialog", whatever that is, in my wikitext editor. Maybe this new feature is compatible only with the Visual Editor? There is no need to answer here; create the page, and editors here will help you expand it and provide feedback on the accompanying talk page. ā Jonesey95 (talk) 16:26, 20 June 2025 (UTC)[reply]
You should have one, even if you're in the older source editor. In WikiEditor it's the little puzzle-piece icon with the "insert a template" tooltip, also called TemplateWizard. I think the only article-editor you wouldn't have it in is if you've turned off the editing toolbar in your preferences, which isn't a very popular choice. DLynch (WMF) (talk) 13:57, 23 June 2025 (UTC)[reply]
Can you explain why you "cannot do it as a beta feature"? It seems that should be the way to go for something like this. If you are not able to do it that way, there should be a clear explanation of why, and whether something can be changed to allow for it. Ita140188 (talk) 08:52, 21 June 2025 (UTC)[reply]
Because it is not planned to make it a beta feature, rather a feature that will be available to everyone. We're a team that works on community wishes, therefore we assume the change is for everyone, and not on a selective basis. Sannita (WMF) (talk) 08:59, 23 June 2025 (UTC)[reply]
If the reason you can't release it as a beta feature is that you have decided you won't release it as a beta feature, then that's a won't, not a can't. Nardog (talk) 10:03, 23 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]
@Sannita (WMF): what do you think Beta Features are intended for actually? "We are looking for potential additional testers for Favourite Templates, and we thought you might be interested in trying it out." mw:Beta Features (an extremely outdated page it seems) is a perfect fit for this, that page makes it clear that Beta Features can be enabled on a per-wiki base. So why not make it a beta feature so people can test it here extensively before making it a generally available feature? Your reply boils down to "we don't want to do that", without actually explaining why. It will eventually be rolled out everywhere, with a per-wiki option to opt out of it. Fine, and until then it can be made a Beta Feature for enwiki or whichever other wiki wants it like that.
You/WMF would get a lot less pushback if something like this can be tested in a more controlled environment or with a more restricted rollout (like Beta) instead of this "all-or-nothing" you are presenting us with now. WMF/enwiki relations are already a bit tense after a few disastrous AI experiment announcements, trying to consider what is suggested here a bit more seriously instead of reacting all dismissive would be beneficial. Fram (talk) 11:45, 20 June 2025 (UTC)[reply]
Hi all, given the consensus that emerged in this discussion, we decided not to go on with the testing of the feature on English Wikipedia. Unfortunately, we cannot make this feature into a Beta feature, as I already explained. The feature will be available at a later stage, when testing is completed. We thank you for your feedback, and we will work on documentation in time for the general rollout of the new feature. Sannita (WMF) (talk) 09:02, 23 June 2025 (UTC)[reply]
This is a very confusing statement. You stated that it could not be a beta feature as you want it to be available for everyone, but mw:Beta Features says it is meant for features that will be available for everyone. I don't read consensus against testing so much as confusion as to what exactly is being asked for. CMD (talk) 09:31, 23 June 2025 (UTC)[reply]
Because it is not planned to make it a beta feature, rather a feature that will be available to everyone. We're a team that works on community wishes, therefore we assume the change is for everyone, and not on a selective basis.
This is such a bonkers response I'm in disbelief. I mean, do you even know what a beta feature means? Or the word "cannot"? The whole point of a beta feature is to make it available to everyone who opts it in, in preparation to release onto everyone by default. Which is the same goal as pilot wikis, the difference being whole wikis opting in vs individual users opting in.
At face value, your response suggests you do not understand what "beta" or "pilot" or "testers" or "can" mean. I doubt the foundation would hire such a person (or people, assuming you're just the messenger), so the AGF interpretation is that you're being dishonest. Nardog (talk) 09:32, 23 June 2025 (UTC)[reply]
@Nardog I find your last remark totally unacceptable. I can deal with the fact that you don't agree with my words, or with the decision of my team, but I cannot accept to be called "dishonest". I kindly ask you to retire that portion of your intervention. Sannita (WMF) (talk) 09:36, 23 June 2025 (UTC)[reply]
In addition to that, I acknowledge that there might have been some problems in communication, arising from the fact that English Wikipedia is not usually a pilot project for new features, and that English is not my primary language. But being called "dishonest" is absolutely an unacceptable behaviour, in any situation, and in flagrant violation of WP:AGF, that you cited as basis for your personal attack, that again I ask you to retire. Sannita (WMF) (talk) 09:39, 23 June 2025 (UTC)[reply]
I'm not calling you, the person, dishonest. I'm sorry it came out that way. My point is that one of the only possible conclusions I can draw from your response is that it misrepresents your team's decision-making process, however inadvertently. I'm not saying you did that out of malice. But the other possible conclusion is that you do not know what any of the words you're writing means, which in my view is even more insulting. So having assumed good faith, my only conclusion is that you're misrepresenting the situation we're inquiring about, which is something many competent public relations employees do. Nardog (talk) 09:54, 23 June 2025 (UTC)[reply]
If WMF is making someone who doesn't know what a beta feature is speak for a development team about a technical topic with the community, then they have a management problem, and if they are trying to make us swallow The wish has been requested for it to be a feature for everyone to have as the reason for not making it a beta feature, then they have a communication/honesty problem. I don't think you have a problem, Sannita, but if you have been honest and genuine, then I think whoever assigned you to speak with us about this topic or has been feeding you what to say does. Nardog (talk) 10:23, 23 June 2025 (UTC)[reply]
I agree with Nardog. Sannita's answer shows at best a lack of understanding of what a Beta feature is or what is its purpose, and at worst, an attempt to pass what is effectively a decision by the WMF (not beta testing this tool and pushing it into the community without opt in) as a technical limitation (not possible to beta test). Ita140188 (talk) 10:49, 23 June 2025 (UTC)[reply]
Sannita (WMF) may indeed be stuck in the position of having to publicly support and justify an idiotic position because someone above them in the management chain has made that a condition of their continued employment. I've seen it happen before at WMF, and heard of more instances there. Anomieā12:12, 23 June 2025 (UTC)[reply]
Can you please ask someone else from "movement communications" to join the discussion and explain to us why enabling this as a Beta Feature isn't possible? There are plenty of people for whom English is their native language (people like ELappen or CKoerner and probably others). The current situation only leads to frustration on both sides. Fram (talk) 10:48, 23 June 2025 (UTC)[reply]
In short, it would require too much of a rewrite of code. Plus, it's just a minor adjustment to the existing dialog windows on both VE and wikitext editor, so it shouldn't - in WMF's perspective - require a Beta feature. I hope this clarifies the point. Sannita (WMF) (talk) 12:19, 23 June 2025 (UTC)[reply]
Thanks. Do you not agree that that explanation is different from the one you gave earlier? In other words, you (the organization, not the person) were not being honest? Do you still want me to retract my statement?
Also, can you elaborate? All WMF wikis get the same codebase anyway (though on different days of the week), and it doesn't look like you're building a whole new extension, so what's so much more difficult about turning it on for some users than turning it on for some wikis? Can someone with actual familiarity with the project (SWilson?) explain? Nardog (talk) 13:01, 24 June 2025 (UTC)[reply]
I suggest not belabouring the issue regarding the accuracy of previous statements. "Dishonest" has certain connotations regarding intent, which don't necessarily hold whenever someone makes an error.
Although it's now moot since English Wikipedia won't be used as a pilot, it would have been instructive to see some mockups of the changes. From what I understand, it would have added a feature to the template wizard for saving a list of favourite templates, which editors could just ignore if they wished. (More info on the ongoing support planned after the pilot would also have been helpful.) isaacl (talk) 16:47, 24 June 2025 (UTC)[reply]
Within phab:T367428, the ticket for this feature, contains Feature flag will be in TemplateData and be $wgTemplateDataFavoriteTemplates = false. If I search through the codes using Github (much easier to search there), it seems that feature flag is already being utilised at least two times. If there is a feature flag already, why can't the BetaFeatures extension be used?
mw:Extension:BetaFeatures shows that the BF flag can be enabled accordingly with the additional BF hooks and then pepper BetaFeatures::isFeatureEnabled( $this->getUser(), 'template-data-discovery' ) at in the codes at where the feature flag is?
For some reason it seems to work if you don't use rowspan in the 5th column [6]. Can't explain why though ā Martin (MSGJ Ā· talk) 18:53, 17 June 2025 (UTC)[reply]
Thanks! It made me realise I had worked with some other workaround in the past as well [7], 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]
Rowspan can lead to poor display when using a sortable table. Having single-row cells following rowspan in a preceding column, or differently-spanned cells after rowspan in a preceding column, can be hard for the eye to track. It might be cleaner if the refs are attached to the names in the first column. DMacks (talk) 17:05, 20 June 2025 (UTC)[reply]
@Dajasj: Also, it is really not a good idea to use techniques like style="line-height:1.067" attributes, non-breaking spaces and <br> tags to force a row height, as you did here. First, it makes assumptions about the reader's setup - something that should never be done. Second, if you sort the table - on any column - you'll see that the rows are now of inconsistent height. --Redrose64 š¹ (talk) 23:11, 20 June 2025 (UTC)[reply]
I am aware, that's why I came here. But if I understand the other discussion correctly, there is no solution other than to fill my cells with more info so there is no problem anymore? Dajasj (talk) 23:25, 20 June 2025 (UTC)[reply]
You must always remember that whatever resolution you edit at is probably not the resolution that most readers read at (who 2 to 1 prefer mobile). Fill the content appropriately without display hacks and let the browser take care of the rest. Izno (talk) 00:54, 21 June 2025 (UTC)[reply]
The least messy solution is to set a small non-zero height on the table rows that would otherwise be collapsed to zero height: |- style="height: 1em;". I did it for this row in this article: [8]. Matma Rextalk04:33, 21 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 MediaWiki:SecurePoll and its subpages. 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]
Proposal 1 wants to use a new namespace. Proposal 2 wants to use a sliver of the existing MediaWiki namespace. The advantage of proposal 2 is less namespaces, which has advantages for maintenance and proportionality (do a couple hundred or couple thousand pages really need an entire namespace?). Neither proposal uses special pages. āNovem Linguae (talk) 23:05, 20 June 2025 (UTC)[reply]
Yes, I understood the difference between the two proposals. My question was regarding proposal 2: instead of treating any page starting with MediaWiki:SecurePoll as read-only and reserved for the SecurePoll extension to use, could just MediaWiki:SecurePoll and its subpages be read-only and reserved for the SecurePoll extension to use? I appreciate of course that the first option is already coded and so is the practical choice today. isaacl (talk) 02:00, 21 June 2025 (UTC)[reply]
Ah, got it. That's probably a pretty easy change to make. Would just need to search for titles starting with MediaWiki:SecurePoll/ instead of MediaWiki:SecurePoll. Thoughts, @SD0001? āNovem Linguae (talk) 06:14, 21 June 2025 (UTC)[reply]
It's already like that. The protection is applied on titles where $title->getRootText() === 'SecurePoll', which means all subpages of MediaWiki:SecurePoll, and incidentally that page itself. Pages like MediaWiki:SecurePollFooBar will remain open. ā SD0001 (talk) 06:32, 21 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]
Seems OK, but there is no production deployment scheduled for this yet - and we've seen plenty of features become vaporware while in development. ā xaosfluxTalk12:32, 20 June 2025 (UTC)[reply]
Support. I disagree with Pppery as SD0001's reply on Phab is convincing ā better to have fewer namespaces if we don't absolutely need them. Toadspike[Talk]23:13, 20 June 2025 (UTC)[reply]
Support assuming this is reasonably easy to work out. I think if the Phab ticket solution does not happen within reasonable time, going back to new namespace is also good. Soni (talk) 07:20, 21 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]
In #We are looking for a pilot for our new feature, Favourite Templates above, en.wiki was invited to be one of the pilot Wikipedias for a new feature. WMF asking looks like good diplomacy and engagement, but do we have a good formal way to accept such invites ā for example, would we need an RFC rather than a brief thread? And if so, does WMF need to know it has to allow enough time for that? NebY (talk) 10:41, 20 June 2025 (UTC)[reply]
I believe the implementation of the Event namespace and associated tools followed a few conversations here where some of us said 'it's probably fine' and some in the community began to request it. In practice the WMF seems to inform us with enough leadtime for an RfC if needed, as the above request seems to have done. Requiring an RfC seems unnecessary unless it's a significant change (which we could define as anything contentious enough that people want an RfC). CMD (talk) 11:54, 20 June 2025 (UTC)[reply]
I think this has fixed it, but you'll probably want to get control of the number formatting of the Facebook and Instagram figures somehow. Removing all uses of {{nts}} from that column might do it; the documentation suggests it's no longer needed. NebY (talk) 18:43, 20 June 2025 (UTC)[reply]
Done{{celestial events by month links}}, used on P:astro, forced a width of 65em; I have changed that to max-width 65em; which should have the intended effect of limiting its size without causing horizontal overflows.
Huh. That other thing is caused by the design of {{Astronomy navbox}}. All those nowraps are making it impossible for it to fit in a very narrow screen. I'd say drop the nowraps on the table headers on the left (given those cells are in these cases already forced by the link lists to be very tall), but it's not very clear-cut. ā Alienā3 3 321:50, 20 June 2025 (UTC)[reply]
@Utfor: I'd say use flex and not a table. On that page there's just too much content for the four to line up. Flex allows an about seamless wrapping of stuff.
I've made a flex mockup of that page at User:Alien333/sandbox. The exact styling can be tweaked, but you get the gist of it.
I previously made a simple template for flex layout, {{Flexbox wrap}}, which tries to fit blocks next to each other but wraps blocks when they can't all fit. It might be able to assist with managing the flex styling. isaacl (talk) 02:32, 23 June 2025 (UTC)[reply]
However, if the intent is really to have a grid, then grid styling is probably easier, since it's designed to let you specify the grid at the top level. (For my use case, I wanted to prefer to have blocks in one line, but wrapping if necessary, so flex is more suitable.) isaacl (talk) 02:40, 23 June 2025 (UTC)[reply]
how do we add web font support for needed symbols?
the standard international symbol for earth mass [as a unit of measure] is MšØ.
this used to be a problem because some mac fonts treated šØ as a subscript, which meant that subscripting it made it nearly illegible.
i believe that's now been fixed, and in general font-support has gotten better over the past several years, so I've started restoring the standard symbol to our articles. I've been thanked for that, but also one editor reports that they still see tofu.
At User:Thebiguglyalien/Portal sample I have a redesign of a portal, done in the style of the main page. Do the people here have any thoughts on the most efficient way to automate a page like this, so it updates at 0:00 UTC each day? All it would have to do would be to grab FAs, GAs, FPs, and FLs and insert them into the page. The thing I'm not sure about is where it would draw them fromāwhether we'd need a manually-updated master list or if there would be a way to automate that too. Are there any technical concerns that might complicate any of this? Thebiguglyalien (talk) šø22:07, 20 June 2025 (UTC)[reply]
{{Database report}} can be used for this, using the |row_template= option to render annotated links for GAs or excerpt for the FA, and the |silent=1 to remove the boilerplate text added by the bot. To fetch a random FA, you'll need an SQL query that lists all FAs relevant to the project, and append ORDER BY rand() LIMIT 1 to select a random one. ā SD0001 (talk) 07:06, 21 June 2025 (UTC)[reply]
I just stumbled upon this (seems to be an AI-powered gadget - ko:ėÆøėģ“ģķ¤:Gadget-WikiVault.js - for, among other things, writing an article) on Korean Wikipedia: ko:ģķ¤ė°±ź³¼:ėźµ¬/WikiVault. "WikiVault is an AI-powered tool that provides useful features to Wikipedia. The three main features currently provided are as follows: Translation : Using AI to provide more accurate translations. Writing : Provides writing features for quick drafting using AI. Quick Access : Quickly access the features you want from any screen with shortcut keys." They have an wiki meetup/workshop/thon using this today, in fact, advertised on their site notice: ko:Event:2025ė _6ģ_21ģ¼_ģ¤ķė¼ģø_ėŖØģ. In which they say "At this event , we will hold various editing events using WikiVault, a generative AI tool that has been introduced to the Korean Wikipedia and has received great response." What do we know about this? What do we want to know about this? Particularly considering that the English Wikipedia community seems to be a wee wary of all that AI stuff... Koreans, on the other hand, seem to be forging ahead. Piotr Konieczny aka Prokonsul Piotrus| reply here08:55, 21 June 2025 (UTC)[reply]
Looks like that is primarily a loader for tedbot.toolforge.org, but I can't find any tool documentation on that at toolhub. Do you know where the external tool documentation is? ā xaosfluxTalk09:14, 21 June 2025 (UTC)[reply]
@Xaosflux I know nothing except what I stumbled upon. There's more material on ko wiki (discussion pages, etc.). I assume some folks here may be interested in digging into this for whatever reasons. I am quite curious myself if (and why) Korean Wikipedia is taking a different approach from en. A hypothesis I have is that AFAIK they are understaffed (have a very low ratio of editors to population, given their development level; I actually published some research on that). Maybe it's a sign of divergence between big wikis that will limit the use of AIs, and small ones, that will seize upon them to bridge the gap. What consequences will it have is interesting (consider, for example, translations. We don't want AI generated articles, but are we going to ban translations of such content from other Wikipedias...? How to spot it when it's not a taggedf article but a less obviously added part of one? Ex. imagine this. Someone on Korean Wikipedia adds a section to some article using AI. Some time later, that article, or parts of it, are translated to en wiki. The article wasn't started by AI, so it's not flagged as such; if it was in the edit summary, most translators don't check old ones. Should we require some global flagging for any article affected by such a tool? Food for thought). Piotr Konieczny aka Prokonsul Piotrus| reply here09:35, 21 June 2025 (UTC)[reply]
We (en.wiki) have no control over ko.wiki or its community. I have seen this tool in its translation capacity (and was not aware of the other features), the understanding I was given was that it was better able to handle templates and similar than previous tools during translation. At least in the implementation I saw, the translated page was generated linearly in the same way that your llm of choice will slowly type out a long answer in front of you, and I believe it is some version of Google Gemini. Looking at that event page, it seems the de novo edits made with the tool come with the summary "WikiVaultģ ėģģ ė°ģ ź²ģ". CMD (talk) 09:40, 21 June 2025 (UTC)[reply]
Well to amend my statement above then, translations also get the summary "WikiVaultģ ėģģ ė°ģ ź²ģ". I am surprised the tool does not attribute the translation, that seems a core element. Frankly a script to fill out {{Copied}} for me would be a minor miracle. CMD (talk) 10:40, 21 June 2025 (UTC)[reply]
We have no control over kowiki, but if content from kowiki is translated back here it may contain hallucinations. This isn't a huge deal for us, though, unless we actually see it causing problems on enwiki. @Grapesurgeon, you may want to take note of this. Toadspike[Talk]10:14, 21 June 2025 (UTC)[reply]
Thanks for tagging. I think it's possibly something we need to widely spread awareness of on enwiki; what we don't want to happen is people on enwiki translating AI stuff over from kowiki and then others getting outraged when that's discovered. Need to get awareness sooner rather than later. grapesurgeon (seefooddiet) (talk) 10:38, 21 June 2025 (UTC)[reply]
I'm going to read through all their materials (incl. past public discussions, feedback given about tool, etc) and translate the important points into English and make a subpage at WP:KO with all my findings. It may take a day or two. Based on that I think we'll be able to have a better discussion. grapesurgeon (seefooddiet) (talk) 10:44, 21 June 2025 (UTC)[reply]
I've just completed the translation: Wikipedia:WikiProject Korea/WikiVault. This is what I could find based on a quick search of kowiki. If we need more information we can reach out to kowiki admins; I'm sure they're willing to talk to us.
Just a general note (not to anyone in particular): please be respectful when discussing this topic; I know AI writing can get people heated. There are real humans on kowiki who worked hard to develop something that they view as helpful to their community. Their situation is different than enwiki's; kowiki is imo very short-staffed on editors.
Wow. I just published ko:Cheese pull using the tool; this is a translation of my enwiki article Cheese pull.
It was remarkably easy and the tool worked well. The kowiki prose is adequate (closely matches my enwiki prose) and it just used the same sources I used on enwiki but with formatting suitable on kowiki. Honestly impressed. Generation took a few seconds, my manual verification took the longest time, and publishing was near instant.
I don't think anyone answered my earlier question. This gadget is just a shim for an external tool, I'm not seeing any tool documentation, or finding it in the tool directory. ā xaosfluxTalk00:36, 22 June 2025 (UTC)[reply]
I don't know what any of that entails; don't have experience with similar tools. I think the main developers of these gadgets can understand English to a reasonable degree; think you can reach out to them. grapesurgeon (seefooddiet) (talk) 00:46, 22 June 2025 (UTC)[reply]
Hi there, I just want to leave some comment on this. Koreans are very positive about using AI as a tool to help translate and write articles. Despite here are issues such as a lack of editors, but even with that in mind, my sense is that AI is becoming a believer in Korean society as a whole. Compare to other communities such as Japanese (where I heard that they are very negative about using AI work) I can share with you that this tool is much better than MediaWiki's existing MediaWiki's ātranslation toolā, where uses machine translation and has been very well received by the Korean community. I know that many users in the English community have concerns about this, at least I do. If you have any questions, I can answer and share some from the Korean community's perspective. --*Youngjin (talk) 02:20, 25 June 2025 (UTC)[reply]
Pinging Liz, who declined the deletion. I'm inclined to speedy this given the offensiveness of the usernameāand especially if it isn't even really a username. Newyorkbrad (talk) 16:25, 21 June 2025 (UTC)[reply]
Might this offensive username (and the one with which it was said to clash) have been almost completely oversighted years ago, accidentally leaving that talk-page? NebY (talk) 16:59, 21 June 2025 (UTC)[reply]
I do all my editing here logged-in (as is recommended), but much of my browsing logged-out. FWIW I typically use Firefox 139/Windows 11 Home on a laptop.
While browsing, I would like to occasionally observe the source code producing a particular WP page. (For example, I recently learned about {{stack}} from reading vanadium(IV) oxide's source.) As of two days ago, I could observe the source code without logging in. I would click on the "Edit Source" link by each article section or at the page top.
As of today, "Edit Source" links are gone (from all unprotected pages and sections) when I browse logged-out.
I can still observe the source code by clicking "Edit" (which starts VisualEditor), waiting a while for VisualEditor to load, and then switching to source mode. In the process, VisualEditor forgets which specific section I would like to examine, producing instead the source code for the entire page. Both the delay and nonspecificity are nontrivial inconveniences to my workflow.
I don't know if the change has substantially worsened the editing experience for new users, but I find it hard to believe that removing an unobtrusive option improved it. Certainly, WP:VE continues to exhibit subtle bugs in handling of indentations, pictures, and named references when I edit large articles.
Was a WP:CONSENSUS developed for this change? If so, where might I find the corresponding discussions? If not, why has this change occurred?
@Bernanke's Crossbow: For me it remembers which editor I used last time. I guess a cookie is used for this. Do you use private browsing or have cookie restrictions in your browser like automatic deletion of cookies? Can you try to clear your cookies for wikipedia.org, or clear all cookies? PrimeHunter (talk) 19:51, 22 June 2025 (UTC)[reply]
@PrimeHunter: Yes, I do often browse InPrivate. I'll be honest, I checked that the same phenomenon occurred in Firefox's "usual mode" while logged-out...but only once. So I didn't catch that it recorded my preferences for the next time I edited (until I just tried it again a moment ago).
The English wikipedia is somewhat unique in that it uses the single edit tab setup - the editor should automatically remember which editor you last used via a cookie. Most WMF projects use the two tab setup, with separate buttons for source vs visual editing, see fr:Apollo 8 for example. 86.23.87.130 (talk) 11:14, 24 June 2025 (UTC)[reply]
RPP data/processes
Hi all. Considering doing some analysis of the RPP log, and hoping some admins or others in the know can help me. Here are random reports from 2014 and 2024:
==== {{la|Zoe Sugg}} ====
'''Pending changes:''' [[WP:BLP|BLP]] policy violations ā Almost all recent edits have been vandalism/BLP violations by anonymous contributors. [[User:Seahorseruler|<span style='color:#1A2BBB'>'''Seahorseruler'''</span>]] <sup>[[User talk:Seahorseruler|(Talk Page)]] [[Special:Contributions/Seahorseruler|(Contribs)]]</sup> 03:18, 1 December 2014 (UTC)
:[[File:Pictogram voting support.svg|20px|link=|alt=]] '''[[Wikipedia:Protection policy#Pending changes protection|Pending-changes protected]]''' for a period of '''6 months''', after which the page will be automatically unprotected.<!-- Template:RFPP#pend --> [[User:Ricky81682|Ricky81682]] ([[User talk:Ricky81682|talk]]) 03:36, 1 December 2014 (UTC)
=== [[:Josef JelĆnek]] ===
* {{pagelinks|1=Josef JelĆnek}}
'''Temporary semi-protection:''' [[WP:BLP|BLP]] policy violations ā Repeated IP attempts to insert unsourced death information for the subject, whose family says is still alive. [[User:NatGertler|Nat Gertler]] ([[User talk:NatGertler|talk]]) 06:49, 3 December 2024 (UTC)
:[[File:Pictogram voting support.svg|20px|link=|alt=]] '''[[Wikipedia:Protection policy#Semi-protection|Semi-protected]]''' for a period of '''two days''', after which the page will be automatically unprotected.<!-- Template:RFPP#semi --> [[User:Chetsford|Chetsford]] ([[User talk:Chetsford|talk]]) 07:52, 3 December 2024 (UTC)
It looks like the standard for {{la}} looks to have been replaced by a colon-prefaced wikilink, the {{pagelinks}} template seems to be added by default, pictograms appear to still be used, and there are still html comments which seem to indicate the template ultimately used.
Questions:
Any other changes in standard formatting that I'm missing?
Do all admins resolving sections use the same script (otherwise, what accounts for those html comments)?
How often would you say someone creates a report that isn't formatted like the above? (and is this the same as asking "how many people reporting don't use Twinkle?")
Perhaps most importantly, are there existing RPP statistical reports out there?
Finding article_history entries with incomplete dates
I just fixed an {{article_history}} entry that just had "8 September" as the GA date, instead of including the year. Is there a way to find all talk pages that have article history entries with dates that are missing the year? They render as the current year (which I think is a bug, and I'll mention that at the a_h talk page), so it's not easy to spot them when casually looking at the talk page. If there are not too many of them I'd like to fix them -- they screw up the date information in ChristieBot's historical GA database, as well as just being wrong. Mike Christie (talk - contribs - library) 01:42, 23 June 2025 (UTC)[reply]
You can probably just insert around Module:Article history#L-542 some basic "does this have a 4 digit number" in the input, which is a fairly easy check (string.find(str, "2%d%d%d")). If you want more detailed checking, based on a review of the #time parser function (yes, the behavior of "current year" is intended, see the docs), you would need to go in the same direction as Module:Citation/CS1 does. Izno (talk) 02:37, 23 June 2025 (UTC)[reply]
When I first click on the Watchlist star icon, it causes a pop-up to appear that blocks the underlying picks for a period of time; just long enough to be irritating. I would like to be able to left-click and make that pop-up go away immediately. Is that change feasible? This would be a workflow quality-of-life feature. Thanks. Praemonitus (talk) 14:11, 22 June 2025 (UTC)[reply]
It looks like nobody here knows the answer, you might have more luck asking the folks at Wikipedia:Village pump (technical). Either they'll know that it is currently possible and can tell you how, or will know that it isn't possible and can advise accordingly (in this instance it is likely to require coding or configuration changes). Thryduulf (talk) 20:36, 22 June 2025 (UTC)[reply]
That is already the case (even with safemode enabled). When you left-click over the white (not a link & not the drop-down menu) portion of the pop-up, the pop-up immediately disappears. āCX Zoom[he/him](let's talk ā¢ {Cā¢X})12:33, 23 June 2025 (UTC)[reply]
@Praemonitus: if you mean "go away immediately" as in "not see it in the first place", you can add #mw-watchlink-notification{display:none;} to one of your user CSS pages. ā Alienā3 3 316:04, 23 June 2025 (UTC)[reply]
It should be possible to make it go away sooner. This is because the appearance and subsequent disappearance are controlled by means of animations that vary the transform: and opacity: properties according to events on a timeline. Unfortunately, I don't know how to use Firefox developer tools to find out how it's done in the first place, nor could I suggest how to modify it so that the duation is decreased. --Redrose64 š¹ (talk) 21:58, 23 June 2025 (UTC)[reply]
After looking at source, it's controlled through an internal timeout not accessible to the exterior, so have to be a bit hacky here.
Here's code that clears notifs after 2 seconds, using mutationobserver:
letmo=newMutationObserver((mrs)=>{mrs[0].addedNodes.forEach((el)=>{setTimeout(()=>{el.remove();},2000)// This is the number of miliseconds you let it stay})})mo.observe($(".mw-notification-area-overlay")[0],{subtree:true,childList:true})
That's not what the OP asked, and it's already been resolved. FWIW, the default period for notifications can be tweaked at the global mw.notification.autoHideSeconds (once the mediawiki.notification module is loaded). Nardog (talk) 08:50, 24 June 2025 (UTC)[reply]
Connection problem with wikipedia.org and its wikis (no other site) at home only
Yesterday and the day before I could not access wikipedia.org for about five hours each time. The error message directly from the browser was "This site can't be reached". I could access other sites, including Wikimedia Status Dashboard (which reported no issue). The problem is only with my IP at home: I could connect with wikipedia.org when going outside in a coffee shop with the same laptop. I had the same problem with all devices connected through that IP at home. Even though the modem worked fine for all other sites, I turned the modem off for several minutes and turned on and it did not help. I understand that I might be the only one reporting that issue, but that does not rule out the possibility that it is related to the way Wikipedia manages IP ranges at the connection level (nothing to do with IP address partial blocking by administrators of individual wikis). I checked if my IP at home has received bad reports and it seems perfectly clean, but perhaps Wikipedia uses different reports that I could not see. Is there any way to make sure that my IP is clean for connecting with wikipedia.org (again nothing to do with IP address blocking implemented by admins in individual wikis, unless they can request complete access blocking). It is in the range 198.52.0.0/16 owned by B2B2C.ca. Dominic Mayers (talk) 13:41, 23 June 2025 (UTC)[reply]
I am now connecting from a coffee shop, since it is happening again now since around 10-11 AM (NY time) this morning. I will check when I come back home. Dominic Mayers (talk) 17:32, 23 June 2025 (UTC)[reply]
Unfortunately (or fortunately), back at home, I have now access to wikipedia.org. If it does not occur again, I suppose, all his good. Otherwise, I will check if the browser received a little bit more info from the server about the issue and I will report it. Dominic Mayers (talk) 21:16, 23 June 2025 (UTC)[reply]
Thanks, glad to hear it is resolved. If it happens again, please do let us know. And re: IPv6, that's fine because most networks don't support IPv6 anyway (our websites do) so it seems unlikely that the lack of IPv6 support would have been a problem. SSingh (WMF) (talk) 13:10, 24 June 2025 (UTC)[reply]
Is there any way to trace all the pages that have linked to a given page in the past? I want to be able to track the history of DYK hooks, i.e.:
June 1: promoted to prep 2
June 3: moved to prep 5
June 9: promoted to queue 5
June 11: moved to queue 7
June 23: included on the main page
Hooks get moved around all the time during the curation process; while the above might be more volatile than typical, it's not outrageously so. Sometimes edit comments are left behind which assist in the archeology, but not always, so I think to do this you'd need to track inbound links, and I don't see any way to do that short of slogging through every revision of all the preps and queues between when the hook was first promoted to when it ultimately ran or was pulled and parsing them. RoySmith(talk)17:05, 23 June 2025 (UTC)[reply]
I think you can find when a hook was run by taking a look at WP:Recent additions. As for preps and hooks, less luck there. You can find which prep the hook was brought to by taking a look at the DYK nomination template's history; it usually says which it was moved to there. Departureā (talk) 17:42, 23 June 2025 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Weekly highlight
This week, the Moderator Tools and Machine Learning teams will continue the rollout of a new filter to Recent Changes, releasing it to the third and last batch of Wikipedias. This filter utilizes the Revert Risk model, which was created by the Research team, to highlight edits that are likely to be reverted and help Recent Changes patrollers identify potentially problematic contributions. The feature will be rolled out to the following Wikipedias: Azerbaijani Wikipedia, Latin Wikipedia, Macedonian Wikipedia, Malayalam Wikipedia, Marathi Wikipedia, Norwegian Nynorsk Wikipedia, Punjabi Wikipedia, Swahili Wikipedia, Telugu Wikipedia, Tagalog Wikipedia. The rollout will continue in the coming weeks to include the rest of the Wikipedias in this project. [12]
Updates for editors
Last week, temporary accounts were rolled out on Czech, Korean, and Turkish Wikipedias. This and next week, deployments on larger Wikipedias will follow. Share your thoughts about the project. [13]
Later this week, the Editing team will release Multi Check to all Wikipedias (except English Wikipedia). This feature shows multiple Reference checks within the editing experience. This encourages users to add citations when they add multiple new paragraphs to a Wikipedia article. This feature was previously available as an A/B test. The test shows that users who are shown multiple checks are 1.3 times more likely to add a reference to their edit, and their edit is less likely to be reverted (-34.7%). [14]
A few pages need to be renamed due to software updates and to match more recent Unicode standards. All of these changes are related to title-casing changes. Approximately 71 pages and 3 files will be renamed, across 15 wikis; the complete list is in the task. The developers will rename these pages next week, and they will fix redirects and embedded file links a few minutes later via a system settings update.
View all 24 community-submitted tasks that were resolved last week. For example, a bug was fixed that had caused pages to scroll upwards when text near the top was selected. [15]
Updates for technical contributors
Editors can now use Lua modules to filter and transform tabular data for use with Extension:Chart. This can be used for things like selecting a subset of rows or columns from the source data, converting between units, statistical processing, and many other useful transformations. Information on how to use transforms is available. [16]
The all_links variable in AbuseFilter is now renamed to new_links for consistency with other variables. Old usages will still continue to work. [17]
The latest quarterly Growth newsletter is available. It includes: the recent updates for the "Add a Link" Task, two new Newcomer Engagement Features, and updates to Community Configuration.
In the Phab task for the Unicode conversion, I'm seeing "Ź" as "ź " (a box with four blocky characters in it). This appears to be a bit of tofu. If this new title will not display properly for me, I imagine that I need to update my computer in some way, which indicates that other people might need to do the same. We'll see what happens after next week; we might need some easy links for readers and editors. ā Jonesey95 (talk) 01:36, 24 June 2025 (UTC)[reply]
Most of these seem to be specific character or script pages describing the very character. I'm assuming that many of these articles already use images in addition to the characters, as many of these are not supported on older computers to begin with. āTheDJ (talk ā¢ contribs) 10:05, 24 June 2025 (UTC)[reply]
Unicode is HUGE ("ultimately capable of encoding more than 1.1 million characters"). Almost everybody is missing many rare characters. And this news is only about MediaWiki's automatic capitalization of the first character in page names. More characters will now be recognized as lowercase which MediaWiki will treat as upper case but only at the start of page names. Nothing inside articles will change and since it's only redirects, nothing will change in displayed page names of articles. All enwiki cases in phab:T396903 are redirects:
Would then delete ź (technical rename): Uppercasing title for Unicode upgrade, and found that Ź and ź both redirect to Voiceless retroflex fricative.
The first case Ź ā ź would rename "0282 LATIN SMALL LETTER S WITH HOOK" to "A7C5 LATIN CAPITAL LETTER S WITH HOOK" according to a copy-paste to [18]. That sounds sensible. In Firefox I see a real character for the former and a box with the Unicode points A7 C5 for the latter but I don't care when it's just a redirect. Links and searches on the lowercase form should continue to work like example going to Example. If a link uses the lowercase form Ź then that form should continue to be displayed as link text. PrimeHunter (talk) 14:58, 24 June 2025 (UTC)[reply]
Interesting thing I am observing: when editing a page, choosing how long to watch a page doesn't actually work. It always, regardless of what I choose in that dropdown, sets it to "permanent". I am using the 2017 wikitext editor. I haven't tested the standard wikitext editor. Justjourney (talk | contribs) 00:08, 24 June 2025 (UTC)[reply]
The 2017 editor is a wikitext editor; as far as I know it doesn't have any capacities related to watchlists.
What I'm asking is through what means they watchlisted that page; as I can't reproduce this bug by clicking the star button with either editor, I assume that they used some other button that uses a different process and is broken. ā Alienā3 3 310:20, 24 June 2025 (UTC)[reply]
You can watchlist a page when you save an edit to it, the option appears near the Edit summary. I could reproduce this in both the 2017 wikitext editor and the VisualEditor (but not the 2010 wikitext editor). Have reported at phab:T397709. the wub"?!"11:22, 24 June 2025 (UTC)[reply]
There are several ways of watchlisting a page. Some of them depend upon settings at Preferences ā Watchlist, which additionally might cause a page to be watched silently.
Clicking the star icon (or equivalent tab or link, depending upon skin) toggles the "watched" state
When viewing (not editing) a page, Alt+ā§ Shift+W toggles the "watched" state
When editing a page, Alt+ā§ Shift+W toggles the "Watch this page" checkbox
You can append ?action=watch to a page's URL, this requires an additional confirmation step
Hiding prompts in comments to catch AI communication
So, I have been talking to a lot of users who couldn't bother to write 2 lines themselves, and rely wholly on AI to communicate, even when replying to comment asking them to specifically not use AI. What would be the html for a prompt that isn't visible on talk page, but gets copied when someone selects and copies the whole block of text? I have previously tried using font-size=1% which works great on desktop, but fails badly on mobile, which is where most AI-editors are. āCX Zoom[he/him](let's talk ā¢ {Cā¢X})08:41, 24 June 2025 (UTC)[reply]
I'm using Vector 2010 in the latest Firefox on desktop. I've been having an issue lately where the "unsubscribe" button for sections on talk pages can't be clicked. Everything was working properly in safe mode. On a hunch, I re-disabled the "auto-number headings" gadget (which I'd enabled recently) -- and voila! The "Unsubscribe" button works as expected again. Is this a known issue? -- Avocado (talk) 18:26, 24 June 2025 (UTC)[reply]
Thanks for taking a look! This very thread we're in right now is an example. Although, interestingly, it is working intermittently (opening the page in multiple tabs and reloading a few times confirms this). Makes me suspect a race condition between multiple scripts, perhaps.
Using my browser's developer tools, it looks like when the problem occurs, the <h2> element is the full width of the container element it shares with the Unsubscribe <a> element even though the text is not long enough to fill the line. It overlaps the Unsubscribe button, and being later in the source it has a higher Z-index and thus sits on top of the button -- transparent but blocking clicks and mouseover events. I don't even get the link cursor on mouseover.
When the button works as expected, the <h2> element has shrunk itself to the width of its contained text and there's no overlap.
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion.A summary of the conclusions reached follows.
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]
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.
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]
There was a consensus, a very, very narrow one, in this particular discussion on a select group of them. Not for all of them. We should not have more time-wasting RFCs like this in the future ā we should actually spend time improving them because it has been proven that a very sizable portion of them are indeed clearly notable. BeanieFan11 (talk) 15:49, 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.
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. The burden is on editors wanting to keep content to demonstrate it is verifiably encyclopedic. Lugnuts had imposed the much more serious burden of maintaining tens of thousands of mass-created non-notable BLPs upon everyone else. There is zero presumption of notability for these stub subjects and additionally they currently violate the global consensus requiring them to cite IRS SIGCOV, so the rest of the community is compromising by creating a special draftspace lasting 10x longer than normal just so those editors who want the stubs retained have more time to improve them. You three have just been trying to interfere with the implementation of a consensus that was against you using the same arguments that were rejected in that consensus. JoelleJay (talk) 14:03, 20 June 2025 (UTC)[reply]
"Stronger" than weak isn't automatically "strong".
Statements like "The burden is on editors wanting to keep content to demonstrate it is verifiably encyclopedic" are exactly the kind of us-vs-them and "I get to boss you around without lifting a finger to help" thing that I'd like to see less of in the future.
I don't feel like I've been interfering with anything. I'm the person who figured out how to solve most of the incomplete, broken process so that hundreds of the articles could actually get moved. I believe that constitutes helping implement the LUGSTUBS2 consensus. Do you disagree? BST spent dozens of hours manually reviewing articles and getting most of them boldly redirected. I would describe that as complying with the closing statement's injunction against mass draftification "without further thought" and "without due care", and even helping us "ensure that the only articles draftified are those which clearly meet the criteria outlined, even if that takes longer or even considerably longer". CMD produced the organized lists that made BST's work feasible and which the closing statement "urge the proponents to break it down into smaller lists by nationality, era, or any other criteria requested". I wonder what you did. How did you contribute towards compliance with the RFC's closing statement? Did you do anything in the last few months that I can't see in this discussion?
I find that there is a rough consensus in favour of the proposal, and a stronger consensus that they should not be left in mainspaceNowhere does this say the consensus was "weak". The only consensus mentioned as "weak" in the close is a finding for a weak consensus to apply this process to Lugstubs beyond this list. I don't know what broken process you "solved"...? The close said we should be careful to make sure the articles in question still fit the original eligibility criteria. That explicitly does NOT involve evaluating each article for notability or even redirectability. In fact, the consensus proposal states 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. Articles should've been draftified before redirects were considered; the only reason this wasn't pursued right after @Pppery resurrected the topic was out of respect for the good work BST has been doing and his assurance he'd be done with his redirection effort soon. Repeatedly muddying the process by insisting editors have to jump through hoops that never existed, or that were even rejected, is disruptive. JoelleJay (talk) 03:16, 21 June 2025 (UTC)[reply]
Nowhere does it say that the consensus is "strong". Being stronger than the rough consensus doesn't mean it is actually "a strong consensus". (Compare: a weak acid is stronger than a very weak acid, but still not actually a strong acid.)
My solution for the broken process can be seen at Wikipedia talk:Lugstubs 2 list#2025 procedure and in these changes to the template. The unfinished and abandoned process in place before then would have failed the "make sure the articles in question still fit the original eligibility criteria" requirement, because it had no provision for letting editors communicate that an article did not "still fit the original eligibility criteria", except to post a note on a talk page that was being ignored. WhatamIdoing (talk) 03:30, 21 June 2025 (UTC)[reply]
Whoa, hang on there. At every stage of this (here, here, here, here, here, here, and here at least, probably in other places as well) I've been looking for practical solutions to make this happen. I supported the proposal, with caveats. I have a long record of disagreeing with editors at the cricket project who believed every cricketer should have an article. I'm not sure I find it fair to characterise that as some kind of interference. The inability to boldly redirect and/or remove the special draft pending tag from articles was a major element in stalling the process ā and that was never mandated by the RfC either. And bear in mind that Billed Mammal's original intention was to re-run the querry once people had had a chance to churn through and check things ā this was all discussed in multiple places throughout the process. We've ended up in about the right place by hook or by crook. We'd have gotten to a similar place if the articles had all been moved to draft immediately fwiw. It just took longer (bad) and half as many clicks (good). I suspect it may be best for someone to hat this now. I don't think we're getting anywhere anymore. Blue Square Thing (talk) 06:10, 21 June 2025 (UTC)[reply]
This allegation of interference has been made on multiple occasions, but that doesn't make it any more true now than it was on any of those other occasions. All I've been trying to do is ensure that the implementation matched the actual consensus that was found, not the outcome that some proponents would like to have been found. I would appreciate it if you could now stop making unfounded allegations of bad faith and work with other people to achieve the outcomes that consensus determines are best for the project rather than simply attacking those who don't do exactly what you want them to do at the speed you want them to do it. Thryduulf (talk) 19:13, 21 June 2025 (UTC)[reply]
Implement on the 287 subjects who remain on the list with tags, which are the non-notable cricketers who donāt have an obvious redirect target; so that the community can then move on to LUGSTUBS3, which consists of the remaining 4,000 cricketers from the original list. Luis7M (talk) 2:02, 22 June 2025 (UTC)
Immediately starting a discussion on 4000 articles is not the most helpful way to do this, and violates WP:NODEADLINE. Let editors have time to look into articles- as has been done for hundreds of articles here- rather than trying to push them all into drafts pace blindly and in violation of WP:ATD where sensible redirects exist. Joseph2302 (talk) 10:40, 23 June 2025 (UTC)[reply]
@Luis7M, we don't need a "LUGSTUBS3". If you read the comment above about what's actually needed, the answer is not a vote over whether to clean up this old mess. What's needed is things like someone to make "smaller, more targeted lists".
Naturally, things like making lists requires actual, hands-on work instead of just bossing other people around. Are you able to do any of this work? WhatamIdoing (talk) 20:44, 23 June 2025 (UTC)[reply]
Assign me a list (anything except Asia) and consider it done before June is over (without deadlines, I will procrastinate). Kind regards. Luis7M (talk) 22:41, 23 June 2025 (UTC)[reply]
Thanks for offering to help out, @Luis7M. The reviewers don't need anything as complicated as List of France international footballers (1ā4 caps). What they really need is just a simple, short list posted at Wikipedia talk:WikiProject Cricket, with a note like "Here's 50 ____ cricket players that meet the LUGSTUBS2 criteria, if anyone's willing to sort through them. Ping me when you're ready for the next list" really is enough to help them out significantly. Fill in the blank with whatever you want, e.g., South African players, players on a particular team, etc. You don't even have to get all the ____ players, as they've said that lists of 50 or so at a time are preferable to one huge list.
If you wanted to help with reviewing individual athletes (even just for the easiest cases), then I'm sure someone there could make some recommendations for the fastest methods. They also need editors who are willing to make list articles when no plausible redirect targets exist (e.g., a List of Imperial Lions players, to which non-notable players for the Imperial Lions could be redirected), but this need not be as complex as your French list. WhatamIdoing (talk) 23:30, 23 June 2025 (UTC)[reply]
Thanks. It'll depend on how you plan to work. My starting point might be South Africans ā a set I mostly redirected where possible because sourcing is less easy. Ideally I'd like them in lists by team. I have no idea how many that would be ā a rough list in a sandbox first might be the easiest way to go about it. There will be some overlap where people played for more than one team, but we can deal with that. The teams are slighly complex because of name changes ā so Orange Free State and Free State are the same side; both had B teams which played at the highest level as well, so all four grouped in one would be most useful; Transvaal became Gauteng; Natal became KwaZulu-Natal etc... Once I know how easy (or not) that is and how many players are involved we can decide what a sensible approach is from there. There's a list of South African teams in Template:Cricket in South Africa and a list of lists in Template:Lists of South African cricketers ā lots of red links so if you're able to produce even partial lists - perhaps from categories - that would be useful as well.
I think BilledMammal had an adapted quarry script that dug out likely relevant cats that would help create team lists, but I'm not sure how to find it and I don't have a copy Blue Square Thing (talk) 05:53, 24 June 2025 (UTC)[reply]
Yes, that's the sort of thing we're looking for. I assume it's been put together using categories, yes? The list isn't complete because the cats aren't complete: so people like Craig Alexander (cricketer) also played for Lions. But they can be added inonce we have more lists. There's a couple of things we could use doing to the lead ā the team also played T20 cricket, for example ā and the naming of South African teams is complex. I'm going to try to get some clarity on it, so it might be helpful not to publish it just yet (the (unreferenced) history section at Dolphins (South African cricket team) seems to summarise it quite well, but it doesn't help with how we name teams as we still have KwaZulu-Natal (cricket team).) But, yes, that's the sort of thing we're looking for. Thanks for using the layout and so on that most of our lists follow.
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,022,988 articles (and Wikipedia as a whole has 65,118,993). 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.
Latitude and longitude
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]
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]
"Important, do not remove this line before article has been created."
DONE MANUALLY
I'm not sure if there would've been consensus to remove these invis comments without any other edits to the affected articles, but these have now all been taken care of manually alongside other improvements to the affected articles. Toadspike[Talk]00:07, 21 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.
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. SdkbāÆtalk17: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]
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.
RfC on new temporary account IP viewer (TAIV) user right
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]
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 [21] 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. [23]. 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]
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]
Okay, this is just a slippery slope argument. And Wikipedia, as an organization rather than an encyclopedia, does have political leanings -- pro-human-rights and freedom of access to information. We shut down the entire website to protest SOPA/PIPA, if I remember the acronym correctly. Mrfoogles (talk) 22:35, 21 June 2025 (UTC)[reply]
Slippery slope is only a fallacy when the start is quite unlikely to cause the end of the chain of causation. I think what DonIago said is pretty likely. Aaron Liu (talk) 02:02, 23 June 2025 (UTC)[reply]
Colors for adding/removing characters
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]
I heard back a couple days ago; they said they would raise it internally and get back to us. I'll let everyone know when I have further updates :) HouseBlaster (talk ā¢ he/they)23:22, 21 June 2025 (UTC)[reply]
@Cremastra @HouseBlaster this is a great idea, I use the BHL all of the time writing species articles. Without it a lot of good information would be lost and completely inaccessible, especially for obscure species where much of the available information is in the original paper on them, which the BHL often preserves. Mrfoogles (talk) 22:37, 21 June 2025 (UTC)[reply]
Update: it has been changed, and looks much better. For new entrants to the discussion, the old symbol was just a gray circle with two horizontal lines for some reason; now it's a pen. Mrfoogles (talk) 22:40, 21 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]
I think this is a good idea -- actually I was looking for an article on Neal Agarwal given there were so many game articles earlier anyway. I think this kind of thing, listing all the scattered articles relating to him in a user facing way (no, categories do not count) would be useful. Mrfoogles (talk) 22:44, 21 June 2025 (UTC)[reply]
This is a better idea than the navpages because these have clearly-defined boundaries. The reason I ultimately turned against nav pages was because they often turned into a sort of poor-man's search result page, with an awkward smattering of tangential sections and no clear inclusion criteria. Cremastra (talk) 23:23, 21 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.
And the fact that someone has a language listed on their Babel box does not guarantee that they'd be looking to the wikis in that language, either. Jo-Jo Eumerus (talk) 06:56, 20 June 2025 (UTC)[reply]
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]
The second one is building diagrams outside of wiki and importing them as images. I wonder if we have precedent of adding TeX packages? Aaron Liu (talk) 16:34, 20 June 2025 (UTC)[reply]
I'am kid 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]
Sexual morality is something that parents should discuss with their children; it's not up to wiki to judge or enforce it. There are a lot of things that I believe should be kept away from children; other parents may disagree on some of them, and wiki policy is to not act In loco parentis.
Had this issue recently. Several editors and I agreed that an article had an NPOV issue, but people didn't have the time to work on them. Another editor removed the NPOV tag due to inactivity.
In Template:POV#When_to_remove, we currently have that the tag can be removed if a discussion becomes dormant. Given Wikipedia editors may get busy, how much sense does it make to remove NPOV tags for this reason?
I think it should be that the editors who want the tag get responded to and do not respond further. Like the discussion is inactive but the last word says the tag should be removed. Aaron Liu (talk) 21:24, 23 June 2025 (UTC)[reply]
A time requirement makes no sense and said time requirement isn't the problem with your background situation. I slightly like the first one but "any agreement" should be changed to "consensus". None of these are what I was talking about but the first one would be an improvement. Aaron Liu (talk) 21:43, 23 June 2025 (UTC)[reply]
The time requirement is there because many pages in Wikipedia is not as active as people think
I still don't get what you mean about the time requirement. Tags are for adding pages to categories so that people who check these categories can act on recommendations to improve a page. They are for attracting activity.Not many things require an RfC. If this can be resolved through a discussion on Template talk:NPOV, it need not an RfC. See WP:RFCBEFORE. Aaron Liu (talk) 22:48, 23 June 2025 (UTC)[reply]
I think it depends in part on the current state of the article and how the discussion went. I suggest the following as rules of thumb (explicitly not to be interpreted rigidly): If the person seeing the old tag things there are (still) POV issues with the current version of the article the tag should remain and they should try and revive the discussion (possibly seeking input from a WikiProject) or, ideally, fix the issues.
If the person seeing the old tag doesn't see any issues with the current version, then if the article is in an objectively very different state to the one it was in when the discussion ended then they should remove the tag. If someone objects to this then the second person should (re)start discussion as there are now at least two editors paying attention to the article.
If the article is in a similar state to how it was when the old discussion happened then, the tag should remain if there was general agreement or consensus there were POV issues but no agreement/consensus about how it should be fixed. Today's editor should probably try and restart discussion.
If there was no consensus/agreement about whether there were POV issues, then try and restart discussion, if that doesn't work or the editors previously discussing matters are no longer active then remove the tag. If someone objects to this, then the person who objects should (re)start discussion. Thryduulf (talk) 22:34, 23 June 2025 (UTC)[reply]
@Thryduulf: it's not a bug, but should it be modified? Specifically the second part: 3. In the absence of any discussion, or if the discussion has become dormant.Bogazicili (talk) 19:43, 24 June 2025 (UTC)[reply]
No, that's the exact opposite of what should be taken from my comment. The vague introduction isn't very useful (and on its own is possibly worse than what we currently have), the important and useful part is the actual guidance. Thryduulf (talk) 21:03, 24 June 2025 (UTC)[reply]
It's true that what we have is not great, but that's not a reason to replace it with something even vaguer. I'm not sure why you think that there isn't space for something more detailed? It is usually possible to condense what I write into something more concise, but even if you were to take my suggestions verbatim it would fit perfectly fine. Thryduulf (talk) 21:30, 24 June 2025 (UTC)[reply]
If you want you can make a proposal.
Otherwise I think "or if the discussion has become dormant" should simply be removed.
I don't think that should be removed. We need to be able to remove these tags when:
nobody ever explained ("in the absence of any discussion") or
there was a brief or useless discussion ("if the discussion has become dormant").
If there isn't a provision to remove in the case of dormant discussion, then Alice can say "This puts too much emphasis on him and not enough on her", Bob can reply "Maybe, but I don't think it's big a problem" ā and then they both walk away, and the tag is stuck there for eternity, because there is no consensus that the problem was resolved (#1), the alleged problem was properly identified (#2), and there was a discussion on the talk page (#3). The purpose of "If the discussion has become dormant" is to deal with situations in which nobody cares enough to resolve the problem, or the discussion goes nowhere. WhatamIdoing (talk) 21:45, 24 June 2025 (UTC)[reply]
Then we need to add something concise for points covered by Thryduulf.
For me, the whole thing that prompted this was that people acknowledged the issue in the talk page, but no one got around to fixing the article. In that case, the POV tag shouldn't be removed due to dormant discussion. Bogazicili (talk) 21:48, 24 June 2025 (UTC)[reply]
The template "may" (as in "allowed to") be removed under those circumstances.
The template is not required to be removed under those circumstances.
If you think that the POV tag shouldn't be removed from that article under its specific circumstances, then nobody is forcing you to remove it.
If someone else removes the POV tag from that article under its specific circumstances, then no rule prevents you from re-adding a new one, and starting a new discussion. WhatamIdoing (talk) 22:00, 24 June 2025 (UTC)[reply]
I've thought about this before. I ultimately think it won't work.
I think I'm more insistent than average about the POV tags not being used in violation of Wikipedia:No disclaimers. "Warning the reader" that some editor disagrees with the article, but can't get their POV to dominate, is an ongoing problem, especially in less visible pages. We also have a problem, for certain subsets of articles, that an NPOV-policy-compliant article gets tagged as "promotional" because it accurately and appropriately reports positive things about the subject. "If it doesn't disparage, it's not neutral" is a view held by only a small minority of editors, but they're disproportionately likely to add these tags. So I agree: There is a real problem associated with this set of maintenance tags.
I have, over the years, made several trips through lists of elderly POV tags (like this one ā warning: large page), and I found that many of them could be removed as stale. Either a significant problem didn't exist in the first place, or it was fixed long ago.
However, I have also found that many other POV-related are there for obvious reasons. They are, in my experience, a minority of what you'll find in Category:Wikipedia neutral point of view disputes, but they are not a very small minority. Some of these are also not easy to fix.
The end result is that I concluded that any automatic system is going to throw the baby out with the bathwater. What we need is something more like a backlog drive to reduce the oldest ones. For example, there are only about 226 articles with POV tags from 2014 to 2019. Maybe we could try to clean those up? Or at least review them, to make sure they're real POV problems, and not just (e.g.,) {{third party sources}} problems? WhatamIdoing (talk) 23:58, 23 June 2025 (UTC)[reply]
@WhatamIdoing: I realized I was vague with the title of this topic. What do you think of POV tag being manually removed after few months because the talk page discussion is not active? Even though several editors have acknowledged the POV issues. Bogazicili (talk) 19:42, 24 June 2025 (UTC)[reply]
I think that it both is, and should be, "legal" to remove a POV tag after a few months (or even just one), if the talk page discussion has stopped.
Sometimes the removal is what prompts the discussion to restart, and that should be counted as a win for removing the tag (even if it's immediately reverted back in).
However, I also believe that editors should not make edits they personally disagree with. So if you see that the article has a POV tag, you (personally/individually) think that tag is warranted, and you see that the discussion either never started or has petered out, then you might prefer to choose one of the other, equally "legal" options available to you, and instead start a discussion, or try to fix the problem, or ping the people who previously discussed it. WhatamIdoing (talk) 21:57, 24 June 2025 (UTC)[reply]
For really old ones such as those from 2014, they can simply be removed? I mean if someone had the time, the preferable thing to do would be to check if the issue has been resolved, rather than simply removing the POV due to discussion being dormant.
A backlog drive that divided up the oldest tagged across relevant+active WikiProjects might work. That would be a relatively small list for each group. WhatamIdoing (talk) 21:39, 24 June 2025 (UTC)[reply]
For example, I'd just remove this and mention it in the talk page, no reliable sources seem to be in Talk:Slovakization#POV,_inacurracies. But I am not going to remove it now as I have not read the entire discussion in the topic.
Since we struggle to get editors to start a discussion at all, I'm not sure that we could realistically get them to start a specific, pre-formatted discussion. WhatamIdoing (talk) 22:01, 24 June 2025 (UTC)[reply]
It would remind them to add missing details. For example, a link to a reliable source.
The only issue with the Neutrality issues backlog drive is that editors who may have no idea about the issue making decisions.
A standardized neutrality issues template for the talk page might help when adding POV tags. Things such as the issue, the sources, etc. Those without talk page discussions could be removed. Bogazicili (talk) 19:52, 24 June 2025 (UTC)[reply]
Imo WP:DRIVEBY tags should always be removed, even when they explain in the edit summary. Some POV issues are mammoth tasks, like Ian Smith, others too technical for most people. I like the idea, but encouraging POV tagging rather than WP:FIXIT is something we should steer clear from. Kowal2701 (talk) 22:14, 24 June 2025 (UTC)[reply]
If the effect of having a routine backlog drive is that it takes the onus off of the tagger to work towards fixing it, then it may be detrimental. Kowal2701 (talk) 22:50, 24 June 2025 (UTC)[reply]
Working only on articles tagged in the previous decade, many of which probably don't qualify for the tag any longer, might not have that effect, though. "See? You don't get a permanent badge of shame just by driving by and dumping a tag on the article" might encourage solving problems, or at least removing unexplained tags.
I don't agree in principle that a maintenance tag shouldn't be added by a person who can't fix the problem. Sometimes, pointing out the existence of a problem actually is helpful. But if that's all you are willing or able to do, then the existence of the problem needs to either be obvious or adequately explained. "I spy with my little eye a POV problem that nobody else can see" is not okay. WhatamIdoing (talk) 00:52, 25 June 2025 (UTC)[reply]
New protection level
I'm thinking of a new protection level, which would be used when semi-protection would be too relaxed, but EC protection would be too restrictive. The requirements would be 14 days and 100/200 edits (I can't decide) and I think we could call it mid-protection.
To build on this, I think autoconfirmed users should be able to semi-protect their own user page. As there is an edit filter, why don't we place the semi-protected shackle? Starfall2015let's talkprofile08:12, 24 June 2025 (UTC) (amended 10:43, 24 June 2025 (UTC))[reply]
User pages are de facto semiprotected via an edit filter. If you want to unprotect your userpage, use {{unlocked userpage}}. I don't think finer protection levels would be particularly helpful; semi keeps out the low-effort vandals and EC is a real threshold for participation. I don't think there are many bad-faith users that have a "is it worth it?" threshold somewhere inbetween. āKusma (talk) 09:37, 24 June 2025 (UTC)[reply]
Where would this protection level be useful? Semi-protection works well against random vandalism, extended confirmed protection works well on controversial topics and pending changes works well for low-volume articles that get constructive edits in addition to disruptive ones. There's no point adding more protection levels just for the sake of adding more protection levels - it just adds more complexity and bureaucracy for no benefit.
I would oppose allowing people to protect their own userpage because a) it would be completely pointless - as you note we already have an edit filter to stop those edits and b) it would result in privilege escalation - anyone could semi-protect random pages by moving them to their userspace, protecting them, then moving them back. 86.23.87.130 (talk) 11:20, 24 June 2025 (UTC)[reply]
The padlock is something not coupled with the software at all and can (though not necessarily should) be added or removed from any page, protected or not. See {{protection templates}}. Like others here I fail to see a usecase. Aaron Liu (talk) 18:41, 24 June 2025 (UTC)[reply]
Is there anything we can do to make level 2 and 3 3 and 4 section headings more different? For example see Bantu expansion, "c. 5000 BCE to c. 500 CE " is level 2 3, the remaining ones level 3 4, they look identical to me Kowal2701 (talk) 21:15, 24 June 2025 (UTC)[reply]
I was confused at first because level 2 and level 3 headings are actually quite distinct, but it turns out you actually mean level 3 and level 4 section headings (see Help:Section#Creation and numbering of sections). I believe you can change the display of these for yourself by customising you user css (but I don't know how to do it myself, so can't give you instructions). If you are proposing changing it for everyone, it would help if you could describe what you'd like to change it to. Thryduulf (talk) 21:27, 24 June 2025 (UTC)[reply]
Underlining of text has traditionally been the method to provide emphasis in cases where italic was not available: on typewriters. As that limitation isn't a concern for Wikipedia, personally I would prefer to follow best typographical practice and not use underlining. isaacl (talk) 02:24, 25 June 2025 (UTC)[reply]
Level 1 is the article title. It's technically possible to have one in the page body but it should be semantically as if a different page. Aaron Liu (talk) 02:30, 25 June 2025 (UTC)[reply]
We actually do use =Level 1s= on some discussion pages, but >99% of the time, you'll only find it used for the page title (and never for anything except the page title in the mainspace). WhatamIdoing (talk) 00:57, 25 June 2025 (UTC)[reply]
I suspect that the best approach for most articles will be to restructure them to use no more than two levels of hierarchy (below the page title, so level 2 and 3 headings). My instinct is that keeping track of where you are in the reading hierarchy becomes noticeably more difficult when a third level of hieararchy (that is, a level 4 heading) is introduced. I think a set of level 4 headings can be workable when the accompanying sections are short and the headings iterate through a small number of parallel items. But in general, less nesting is easier to process. isaacl (talk) 02:39, 25 June 2025 (UTC)[reply]
WMF
RfC: Adopting a community position on WMF AI development
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
Should the English Wikipedia community adopt a position on AI development by the WMF and affiliates?
This is a statement-and-agreement-style RfC. 05:05, 29 May 2025 (UTC)
General
Discussion of whether to adopt any position
We have two threads on this page three open village pump threads about the WMF considering or actively working on deploying AI technologies on this wiki without community consultation: Ā§ WMF plan to push LLM AIs for Wikipedia content, andĀ§ The WMF should not be developing an AI tool that helps spammers be more subtle, and WP:VPT Ā§ Simple summaries: editor survey and 2-week mobile study. Varying opinions have been given in both all three, but what is clear is that the WMF's attitude toward AI usage is out of touch with this community's. I closed the RfC that led to WP:AITALK, and a third of what became WP:AIIMAGES, and what was clear to me in both discussions is that the community is not entirely opposed to the use of AI, but is deeply skeptical. The WMF's attitude appears to be the mirror image: not evangelical, but generally enthusiastic. This mismatch is a problem. While we don't decide how the WMF spends its money, we should have a say in what it uses our wiki's content and editors to develop, and what AI tools it enables here. As discussed in the second thread I linked, there are credible concerns that mw:Edit check/Tone Check could cause irreversible damage even without being enabled locally. Some others disagree, and that's fine, but it should be the community's decision whether to take that risk.Therefore I believe we need to clearly establish our position as a community. I've proposed one statement below, but I care much more that we establish a position than what that position is. This RfC's closer can count me as favoring any outcome, even one diametrically opposed to my proposed statement, over none at all. -- Tamzin[cetacean needed] (they|xe|š¤·) 05:05, 29 May 2025 (UTC), ed. 14:35, 3 June 2025 (UTC)[reply]
what is clear is that the WMF's attitude toward AI usage is out of touch with this community's ... with some in the community, while it's in touch with others in the community. That much should be clear by now.
we need to clearly establish our position as a community ... we don't clearly establish a position as a community on anything, not even on basics like what articles Wikipedia should have, or what edit warring is. There are hundreds of thousands of people who edit this website, and this "community" is not going to agree on a clear position about AI, or anything else. Groupthink--a single, clearly established position as a community--is neither possible nor desirable. Levivich (talk) 16:59, 30 May 2025 (UTC)[reply]
PS: these sort of things work better organically. If you want to get everybody on board on a website with hundreds of thousands of users, history has shown the best way to do that is from the bottom up, not the top down. Posting a statement on a user page and seeing if others copy it, writing an essay and seeing if it's promoted to a guideline... those kind of approaches work much better than trying to write a statement and having people formally vote on it. Levivich (talk) 17:10, 30 May 2025 (UTC)[reply]
Hi everyone, Iām the Director of ML at the Foundation. Thank you for this thoughtful discussion. While PPelberg (WMF) has responded in a separate thread to address questions that are specific to the Tone Check project, I wanted to chime in here with some technical perspective about how we use AI. In particular, I want to highlight our commitment to:
Prioritize features based on what we believe will be most helpful to editors and readers. We aren't looking for places to use AI; we are looking for ways to help readers and editors, and sometimes they use AI.
Include the community in any product initiative we pursue, and ensure that our development practices adhere to the principles weāve aligned on through conversations with the community.
Our technical decisions aim to minimize risk. We select models that are open source or open weight, host models on our own servers to maximize privacy and control, use smaller language models that are more controllable and less resource-intensive, and ensure that the features that use these models are made configurable to each community that sees them (example).
We also follow processes that make these decisions, and the broader direction of our work, as transparent as possible. We share prototypes of our ideas long before theyāre finalized, evaluate the performance of our models using feedback from community volunteers, publish model cards that explain how our models work and include talk pages for community members to react, conducted a third-party a human rights impact assessment on our use of AI (that will be published as soon as its finalized), model cards will start including a human rights evaluation for each new model in production, and weāre now creating retraining pipelines that will allow each modelās predictions to adapt over time based on community-provided feedback.
@CAlbon (WMF), I took a look at the Simple Article Summaries feature (which I was unaware about). Based on the image on the top, as it currently stands the idea appears to be appending LLM generated summaries to the top of articles. This feels at odds with WMF's AI strategy of prioritizing helping editor workflows over using generative content. I would expect a fair amount of push-back from the English Wikipedia community (including myself) if this feature were to be deployed in it's current form. Sohom (talk) 16:02, 30 May 2025 (UTC)[reply]
Hi @Sohom Datta, this is Olga, the product manager working on the Simple Article Summaries project. Thank you for flagging this and checking out the project page. Youāre noticing and calling out an interesting part of our work right now. While we have built up an AI strategy for contributors, we have yet to build one for readers. We think these early summary experiments are potentially the first step into our thinking for how these two strategic pieces will work together. To clarify, weāre so far only experimenting with this feature in order to see whether readers find it useful and do not have any plans on deploying it in this current form, or in any form that doesnāt include a community moderation piece. Not sure if you saw the moderation consultation section of the page where we describe this, and weāll also be posting more details soon. One of the two next steps for the experiment is a series of surveys for communities (planned to begin next week) where we will show and discuss different options for how editors will be involved in generating, moderating, and editing these types of summaries. Curious if you have any suggestions on this. If these summaries were available - what do you think might be effective ways for editors to moderate them? Also happy to answer more questions here or on the project talk page. OVasileva (WMF) (talk) 17:24, 30 May 2025 (UTC)[reply]
I do believe that an AI strategy for readers is essential going forward ā getting feedback from what readers expect from Wikipedia (separately from the expectation of editors) is difficult but extremely important. However, a reader-facing AI will also impact editors, as they will have to write articles while taking into account the existence of these summary tools and how they might present the content these editors are writing. That way, it could be interesting to give editors (and the community at large) some level of input over these summaries.A basic possibility could be to have an AI-generated first draft of a summary, that is then editable by editors. The main issue would be that this draft couldn't be updated with each new edit to the main article without resetting the process. To solve that, we could envision a model that takes a unified diff as input and updates the summary accordingly, working in sync with editors themselves. I would be very happy to help in this process, if any more input is needed! Chaotic Enby (talk Ā· contribs) 17:37, 30 May 2025 (UTC)[reply]
@OVasileva (WMF), I think my major concern is that the screenshot shows the AI generated text in the prime position, highlighted over and above beyond volunteer-written text (which is the core of the encyclopedia) and should be the thing we drawing attention to. Wrt to the rest, I would like to Chaotic Enby's comment above. I think we should first define a AI strategy, get community feedback and then design the feature around.
When it comes to the moderation of such secondary content I think a good model to take inspiration from is the enwiki short description model, which is typically set using a enwiki template that triggers a magic word to set the values in the backend. Sohom (talk) 18:06, 30 May 2025 (UTC)[reply]
Regarding the screenshot shows the AI generated text in the prime position, highlighted over and above beyond volunteer-written text, one of my favorite essays is WP:Reader. I love it so much, I quote it on my user page:
A reader is someone who simply visits Wikipedia to read articles, not to edit or create them. They are the sole reason for which Wikipedia exists.
When evaluating what goes where, all that matters is what's best for the readers. So we should be evaluating what goes where based on which text is better for them, not who wrote it. RoySmith(talk)18:33, 30 May 2025 (UTC)[reply]
I agree, but I feel like prioritizing LLM generated text could rub parts of the readers the wrong way, whereas a "show me a simplified LLM generated summary" button would have the same effect, without potentially alienating the portion of the userbase looking for a AI generated summary of the article contents. Sohom (talk) 19:16, 30 May 2025 (UTC)[reply]
What I wonder here is, why does a reader come to Wikipedia? Active searchers will have clicked past their google default summary which already generally simply draws from Wikipedia. They will have chosen not to ask their chosen llm app or site about the subject. Presumably they are less likely to want an llm summary. Readers coming from links may have not have made such choices, but I wonder if the differences in expectation are that different. They could also, if they want, place the url in their favourite llm and ask for a summary. Does natively integrating the function that readers can access dilute WIkipedia's USP? That said, we can often have problems with technical language. Previous attempts I've seen to fix this with llms have been quite poor, but as it improves there is something to a tool which editors can use to evaluate their work and perhaps identify the more complexly written parts. CMD (talk) 17:29, 31 May 2025 (UTC)[reply]
I think this is a good take stacking with the idea that trust built slowly and lost quickly. For readers that are ideologically opposed to AI, making LLM content the default anywhere important to them on the cite is likely to violate their trust. For more open minded readers they have the option of seeing LLM summary. For the die hard LLM users they will probably find their information elsewhere and that is ok too. Czarking0 (talk) 05:39, 20 June 2025 (UTC)[reply]
I object to this premise. Wikipedia is a human-curated encyclopedia that anyone can edit. All readers are editors, they're simply allowed to choose whether they edit or not, just as we are. Thebiguglyalien (talk) šø21:57, 3 June 2025 (UTC)[reply]
If our presumption is that LLM-generated text may be better for readers than human-written, we should just shutter the project and replace it with an AI-written encyclopedia. ź§Zanaharyź§21:30, 6 June 2025 (UTC)[reply]
Note that this has been extensively discussed at WP:VPT and the project has been paused, with folks at the WMF are planning on taking stock of the situation and returning back later next week. Sohom (talk) 21:42, 6 June 2025 (UTC)[reply]
Hey everyone! Thank you for engaging with this - this is exactly the kind of feedback we're hoping to get at this state of the project. I'll be back after the weekend to speak a bit more on the strategy aspect. Before that though, @Sohom Datta - you helped me realize the screenshot we'd put on the page was pretty misleading. In that screenshot you can see the design for the browser extension experiment that we did. In general, we expect this design to be iterated on as we keep working on this. Most importantly though, it didn't show that the default state for the browser extension was for the summary to be closed by default. Basically, you only see the summary if you click on the dropdown to open it. We tested it this way for the exact reason you mentioned - we wanted viewing the summary to be the choice of the reader, rather than something we force on readers. In terms of the positioning we thought that having it close to the top of the page would help it feel more clearly separated from the article content (more like navigation), but we also explored a few other places to put the dropdown, such as below infoboxes (open to other ideas for placement as well! Like I mentioned above, we expect these designs to change a number of times as we explore this more). I've just added a design section to the documentation that I hope makes this a bit clearer, thanks again for flagging it! OVasileva (WMF) (talk) 08:43, 31 May 2025 (UTC)[reply]
@OVasileva (WMF) Ooh, the mock-ups look more promising. Is the feature expected to be released as a opt-in browser extension ? Or, do we expect this to be part of the default experience of Wikipedia? (If it is, maybe a button to collapse the bar/opt-out (like those present on the Page Previews feature) would be useful? Also, in it's current state "View simplified summary" and "Unverified" are the most visible elements on the page, which seems to distract over the content itself.) Sohom (talk) 17:16, 31 May 2025 (UTC)[reply]
I second the points Sohom makes, although I think it can be a good thing to clearly state that the summary is unverified. On the other hand, having an "Unverified" warning sign on all articles could be seen as an indicator of lower encyclopedic quality, as readers might not immediately realize that it only applies to the summary.The precise date and author are a bit of a clutter, however, and a simple "View machine-generated summary" could be better, maybe with a hoverable information sign alerting that it has not yet been verified, as well as an "X" button to allow users to remove the bar. Chaotic Enby (talk Ā· contribs) 17:21, 31 May 2025 (UTC)[reply]
Thanks for flagging this. I see your point around "Unverified". I wonder if maybe we could show the "unverified" tag only once a summary is open and that way make the connection a bit clearer? We wanted to make it really visually obvious but I agree that it might be a bit distracting from the article content itself. I'll bring this to the team to discuss more. Like I mentioned above, the design is in no way final so this type of feedback is really useful right now! OVasileva (WMF) (talk) 12:44, 2 June 2025 (UTC)[reply]
These are all good questions, thanks! The browser extension itself was just to allow us to have a lightweight way to experiment and get some initial feedback. We have a series of these small experiments coming up - we started with the browser extension, this week we'll be launching the surveys for communities that I mentioned above, where we'll be asking their thoughts on moderation. Next week we'll also be doing a two-week opt-in only experiment for mobile readers so we can see how the idea fares on mobile. From there, we'll see! We don't have concrete plans yet on what a final version of the feature would be, but I feel like we would start as opt-in only (or potentially a beta feature first for logged-in users), and on-wiki. Right now though we still need to discuss and build out the moderation piece, so any more permanent experiments or beta features are still blocked on that. OVasileva (WMF) (talk) 12:40, 2 June 2025 (UTC)[reply]
Agree that the final product should definitely be opt-in only. From what I understand, the surveys are mostly aimed at experienced users regarding moderation-related questions, right? Are other experiments planned for the wider userbase (including users without accounts) once a first moderation workflow is set up? Chaotic Enby (talk Ā· contribs) 20:28, 3 June 2025 (UTC)[reply]
Another thing I noticed: I just took the survey, but the "Agree" and "Disagree" columns get flipped in the fourth page, should that be fixed? Thanks a lot! Chaotic Enby (talk Ā· contribs) 20:57, 3 June 2025 (UTC)[reply]
In my case, the last page flipped from having "Very poor" on the right to putting "Strongly agree" there. I doubt the overall results on that page reliably reflect respondents' views. (Also, no back button? And no way to indicate that one idea is very poor, but marginally better than the others.) NebY (talk) 09:43, 4 June 2025 (UTC)[reply]
As is common with these surveys, it fails to provide an option for when you just have no idea how good or bad something will be, but insists on an answer. Ā· Ā· Ā· Peter Southwood(talk): 12:31, 13 June 2025 (UTC)[reply]
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:41, 4 June 2025 (UTC)[reply]
I feel Scaledish's post strikes the issue square between the eyes. The developers of the SAS are missing the forest for the trees: the threshold questions should not presuppose that the tool is appropriate and beneficial to work of this project and move directly to inquiries targeted at optimization and risk management. There's a real and concerning replication here of the primary rational error and cognitive bias that is driving the rapidly mounting societal harms of AI: that is to say, leaping directly from "this is now technically possible" to "therefore, let's do it!" SnowRise let's rap21:26, 4 June 2025 (UTC)[reply]
The main disconnect here seems to be that a lot of the feedback-gathering seems to be from a UI/UX perspective, where the actual problems involve content. The issue is not that the extension is buggy or hard to use, the issue is that the actual summaries, such as the ones in this list, are bad. They're not just flawed, they are so unfit for purpose and demonstrate such a mismatch between task and result that the whole project should have been scrapped or radically rethought the minute someone looked at them. Any serious moderation would throw most of them out for many reasons: claims that don't appear in the original text, inappropriate tone, outright falsehoods, politically controversial and/or legally problematic statements, and Western-centricism (in a feature intended for "global readers," no less). None of this should be surprising: they're the same problems that LLM-generated text has across the board.
That list of summaries, while public, was not easy to find, nor was the example given to us representative of it. The community was told that these summaries "take existing Wikipedia text, and simplify it for interested readers," when what they actually seem to do is generate whole-cloth blurbs targeted at 7th graders (per these prompts) with titles like Monitor Lizards: Big, Strong, and Wide-Ranging (and no, just filtering out the titles doesn't fix the underlying issue). We have had to piece the details together ourselves, and it took people about 15 minutes to find problems that apparently took the team several months to only partially notice. I'm sure there are some misconceptions in our interpretation of the various scattered documents and diffs -- which is to be expected, since we were told very little about the project. How is this being "as transparent as possible"?
Actual transparency would provide, at bare minimum: the exact articles chosen and why, exact prompts used, the full list of output (as well as any intermediate stages or rejected output), the methodology used to evaluate that output, and so on. It would need to also happen much earlier in the process -- at least as early as September 2024, when sample summaries were available and when there would been time for people to tell you exactly what they have told you now. Gnomingstuff (talk) 00:47, 8 June 2025 (UTC)[reply]
The average American reads and writes at a 7th grade level.[24] That's a major demographic we aren't thinking about. A person who is reading our article on zero because they don't understand the number will likely understand:
Zero is a number that represents nothing. It's special because adding zero to any number keeps that number the same. In math, it's called the "additive identity." Multiplying a number by zero always gives you zero, and you can't divide by zero.
much better than:
0 (zero) is a number representing an empty quantity. Adding 0 to any number leaves that number unchanged. In mathematical terminology, 0 is the additive identity of the integers, rational numbers, real numbers, and complex numbers, as well as other algebraic structures.
So what if the first tone is more casual and treats the reader like a child? As a child I enjoyed reading Wikipedia, and if I could've opted in to a feature like this I likely would have. AI-generated summaries are a big part of how people consume information because they can be tuned to the individual reader's preferences. This is clear step forwards in democratizing access to information. Chess (talk) (please mention me on reply)05:33, 8 June 2025 (UTC)[reply]
Pre-generated AI summaries cannot be tuned to individual reader preferences. They are as static for the reader as our existing lead is. CMD (talk) 05:45, 8 June 2025 (UTC)[reply]
Except that one could pre-generate a bunch of different summaries targeted to different reading levels and present the best one for the reader. Kind of like how we cache multiple resolution versions of images now. RoySmith(talk)06:06, 8 June 2025 (UTC)[reply]
I mean, there's probably lots you can do if you want to approach the utility of having an llm browser extension without being quite as helpful as an llm browser extension. It still wouldn't be tuned to individual reader preferences. CMD (talk) 06:19, 8 June 2025 (UTC)[reply]
I'm surprised they got that level of quality out of <1B parameter models (Flan-T5 and mt0).[25] I wonder how many of these issues are caused by the resource constraints. Chess (talk) (please mention me on reply)06:57, 8 June 2025 (UTC)[reply]
Just re-read this. The summary has other problems:
0 is not the additive identity, it's the additive identity of integers, rational numbers, real numbers, complex numbers etc. This is an important distinction in math that gets lost in the summary. If the concept of an "additive identity" is too complex for seventh graders -- which it may well be, this is college-level math -- then it shouldn't be in the 7th-grade-level summary. But a LLM doesn't care.
"Represents nothing" is ambiguous. Someone who isn't fluent in English might see this and think "wait, it doesn't represent anything? Then what is it?"
The part of the summary you didn't quote is even worse. It mentions 0's use in the place value system without ever actually saying it's talking about place value, and then moves on to "this system." What system?
Should the English Wikipedia community adopt a position on AI development by the WMF and affiliates? This doesn't seem like the right thing to RFC. Telling the WMF and the 193 affiliates what to work on is outside our jurisdiction, the same way that the WMF telling us what content to write or who should become administrator is outside their jurisdiction. āNovem Linguae (talk) 15:33, 30 May 2025 (UTC)[reply]
This is kind of why I'm sitting at either "no opinion" or maybe something that comes out of the first draft I put below. Basically saying what our opinions are, requesting updates be provided directly to us (instead of us having to go search through Meta Wiki or MediaWiki Wiki or elsewhere for them), and that's that. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!19:04, 30 May 2025 (UTC)[reply]
First, I appreciate having some WMF input here. If any WMFers are reading this comment, could you maybe opine on whether providing a relatively short statement to enwp directly (as I proposed below) would be feasible? I can't imagine it's not feasible, but I think that's a lot of the problem - people here don't want to have to go to multiple different websites (Meta, MediaWiki, WMF, etc) and watch different pages on all of them to know that a project is happening or there's an update to it. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!19:07, 30 May 2025 (UTC)[reply]
Here's a statement I'm thinking of proposing:
Wikipedia's greatest strength is the contributors that have dedicated their time, energy and enthusiasm to build "the sum of all human knowledge". Automation, including AI, has played a significant role in assisting contributors, with the best results coming when it is developed in a bottom-up manner. It is important that we continue developing new features and advances to help humans as technology improves, with the understanding that getting it wrong risks corrupting Wikipedia's soul.
This is more of a statement of principles than a specific demand/ask, but basically: bots, gadgets, and MediaWiki itself have been crucial in helping humans build Wikipedia. The best ideas were organically started by editors and made their way up through the tech stack rather than top-down. Getting the automation/human balance right is not an easy task, and the consequences of getting it wrong are massive. Thoughts? Legoktm (talk) 18:22, 31 May 2025 (UTC)[reply]
@Legoktm I was with with you up until "the consequences of getting it wrong are massive". On the content side of the house, we have WP:BOLD, which basically says "the consequences of getting it wrong are trivial". In the software development world, this is embodied by philosophies like Minimum viable product and Fail fast. Facebook famously stated this as Move fast and break things.
The problem is (as with so many software shops), projects out of WMF seem to take on a life of their own. I don't have any visibility inside WMF, but I'm basing that on what I see as an interested observer, and a veteran of many dev projects IRL. This is understandable. Once somebody (be it an individual dev, a product manager, a VP, whatever) have sunk a bunch of resources into a project, it can be difficult to say, "Hey guys, you know that $X I convinced you to invest in this? It turns out it was a bad idea and we should just chuck it and move onto something else". It really sucks to have to put on your annual performance report "Spent the last year working on something that never shipped and never will" if you're not working in an organization which rewards that sort of thing.
So where I'm going with this is I'd like to see more of a culture where the consequences of getting something wrong aren't so massive. That would encourage more experimentation, which ultimately is a healthy thing. RoySmith(talk)18:59, 31 May 2025 (UTC)[reply]
@RoySmith: thanks, and I agree with what you would like to see (and working bottom-up is the easiest way to do that IMO). The point I want to communicate about risks is that Wikipedia is ultimately a human project, built and shaped by humans. I support the use of automation when appropriate, but if you automate too much, then what you end up with isn't really a Wikipedia any more. The best case study being when a bot was allowed to take over multiple projects. I think we're too early in the Gen AI development cycle to understand what it fully means, but since folks are making pretty wide statements, I think we need to be honest about what the consequences could be if there isn't enough humanity in Wikipedia. Maybe there's a better way to express it? Legoktm (talk) 19:11, 31 May 2025 (UTC)[reply]
I think this RfC is quickly going into the sprawling kind and that's not good. It would be quite unreasonable for a new participant to step in and parse through what we have discussed till now. Maybe the idea here should be to coagulate aligned positions into more succinct categories so editors can yay or nay. --qedk (tęc)13:36, 10 June 2025 (UTC)[reply]
I'm beginning to doubt the point of even having a statement. What's the point? Everyone who has pointed out the poor quality, factual inaccuracy, and legal risks (even after "manual review") has been completely ignored. I guess we're just "internet pundits" and the feature isn't "for us." Gnomingstuff (talk) 14:13, 10 June 2025 (UTC)[reply]
I know. The WMF will just do what they want to anyway. There's pretty much 100% opposition to this but I doubt it will stop them. It didn't stop them with Visual Editor 2022 Vector 2022. There was consensus against that but they did it anyway. ~WikiOriginal-9~ (talk) 14:17, 10 June 2025 (UTC)[reply]
I will ask both of y'all to pump the brakes on assuming the worst here. To my understanding, the WMF folks has scheduled a call to discuss this issue (among other things) with the PTAC on the 25th of June, I would atleast wait until then before coming to conclusions. Also, while you don't see any explicit official comments from folks, you can pretty sure they are following these discussions. Issuing a statement is definitely the correct way to go both from the POV of establishing boundaries and helping with identifying process deficiencies. Sohom (talk) 14:28, 10 June 2025 (UTC)[reply]
I don't think that's a good comparison because time has shown the new Visual Editor to be not such a bad idea. And I don't actually think the community opposition is the problem with this -- even if the community loved this feature it would still be a terrible idea. Instead, the quality of the summaries should speak for itself: informing adult readers that Logic is like a superpower that helps us think and argue smartly. It's all about understanding how to make good decisions and draw the right conclusions. (For some reason this output is obsessed with calling things "superpowers.")
[edit conflict] I don't think I'm assuming the worst here. Not sure how I'm expected to know about a call on June 25th that to my knowledge was not publicized to anyone until now. Gnomingstuff (talk) 14:33, 10 June 2025 (UTC)[reply]
(replying to wikioriginal9) Vector 2022 is also a bad example just cause based on hindsight it wasn't necessarily a bad idea. There was a reason V22 did not necessarily have unanimous consensus to be disabled despite multiple RFCs on enwiki.
(replying to gnomingstuff), my point was to assume that folks are listening (as opposed to not). I did not expect prior knowledge of the call. Sohom (talk) 14:47, 10 June 2025 (UTC)[reply]
I would be fine with collating a few proposals. berchanhimez, thoughts on combining your proposal with mine as well ? (I think it calls for effectively the same thing with asking for periodic updates). Sohom (talk) 14:52, 10 June 2025 (UTC)[reply]
@Sohom Datta: You have my permission to take any part of my proposal that you feel would help. I honestly don't know if I'd support such a strong statement as your proposal is, but at least yours gives an out, and if it was combined with my idea of "early and often" communication and collaboration with the community (for an example), I may be able to support it. Feel free to take any/all/none of my statement and I don't even need credit for it :) - after all, you're the one doing the work to try and get something workable put together. If there's anything I figured out from this discussion, I think having any sort of single statement (even a multi part one) get consensus is going to be a miracle, due to a large spread between views in more than one direction. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!20:37, 10 June 2025 (UTC)[reply]
Users who oppose adopting any position
I firmly oppose any sort of universal statement. The WMF is not here to support just the English Wikipedia. They are there to support all WMF wikis. And if they come up with a reliable, reasonable AI model that works on other wikis, we should not be speaking out against it before we see it. There seems to be a widespread opposition to "AI" in the world nowadays, without considering what types of "AI" it affects or what benefits it can provide. I would support only a statement asking the WMF to comment on the English Wikipedia to keep us updated on their efforts - but that should be a given anyway, so I do not consider that a "universal statement" like this. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!05:37, 29 May 2025 (UTC)[reply]
Noting here that, while I still believe no blanket/universal statement is necessary, I posted a "request to keep us better informed" style statement below for people to wordsmith and/or consider. I don't even know if I would support making such a statement yet, mainly because I don't know how feasible it is to expect the WMF to make announcements like that here however frequently it may end up being. But maybe such a statement would help assuage the concerns of some people that we aren't being kept in the loop enough or given enough opportunity to provide feedback during early stages of projects, for example. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!00:24, 30 May 2025 (UTC)[reply]
I agree with Berchanhimez: it is premature to start determining our positions on tools that have not yet even been properly developed. I think it's important to remember that the entire Wikimedia Foundation does not revolve around the English Wikipedia, and whilst I too am sceptical about such usage of AI, I don't think this is going to be the way to address it (assuming it would ever have any actual impact). ā Isochrone (talk) 08:25, 29 May 2025 (UTC)[reply]
Strongly oppose EnWiki adopting any position; it needs to be a global RfC first before any other action can be taken, as the English wiki should not have veto power over all the other wikis just because of its popularity. Stockhausenfan (talk) 12:37, 29 May 2025 (UTC)[reply]
We can't say it's clear that WMF's views are out of touch with the community when we haven't heard from the community yet; it could be that there's a strong majority in support of WMF's position outside of EnWiki. (Not that I'm saying this is the most likely scenario of course.) Stockhausenfan (talk) 12:45, 29 May 2025 (UTC)[reply]
Cluebot is one of the earliest examples of the successful use of AI technology. While fear of new technology is human nature, we shouldn't give into it. I'd rather encourage the WMF to spend its resources on new editing technology (including AI-assisted) rather than some of the other stuff it's spent money on historically, so with regards to enwiki-WMF relations, this would be a step in the wrong direction. Levivich (talk) 15:45, 29 May 2025 (UTC)[reply]
Oppose adopting any position at this time. Short of a collapse of industrial civilization, AI is not going away, and adopting policies and resolutions is not going to protect us from the harmful aspects of it. In my opinion, the Foundation and the community must remain open to exploring how we can use AI to benefit the project. - Donald Albury18:23, 29 May 2025 (UTC)[reply]
AI is just a tool. What matters is what you do with the tool. In 10 years, even your washing machine and tea kettle will probably be running AI models. As AI slowly becomes permeated in all kinds of software, people will stop talking about it as it were something special, rather than just another paradigm of building software. I find it exciting that WMF is embracing the future. WMF's attitude toward AI usage is out of touch with this community's Indeed, but it's not the WMF's attitude that needs to change. Perhaps we as a community could try being less orthodox and conservative. ā SD0001 (talk) 18:48, 29 May 2025 (UTC)[reply]
+1. WP:AITALK and WP:AIIMAGES are, of course, reasonable policies. The adoption of those doesn't mean AI is bad, or that any kind of general statement to the WMF about AI is needed (whatever meaning that would possibly have).
The below statement can have the effect of the WMF not exploring AI technologies and possible productivity improvements they may bring, which of course would be detrimental. ProcrastinatingReader (talk) 23:15, 29 May 2025 (UTC)[reply]
The use of AI is growing at a rapid pace and (for better or worse) I don't think it'll slow down anytime soon. Any statement or position adopted now may make us feel good in the short term, but won't be future-proof. Some1 (talk) 00:12, 31 May 2025 (UTC)[reply]
Oppose any statement. Really, guys, oppose tools that have not even been designed yet and that you have no idea how do they work or any actual advantages or disadvantages they may have? And make big announcements that you oppose them just because? And all just because of a provincial and superstitious fear of AI? You'll just embarrass yourselves with such nonsense, and turn Wikipedia into a laughing stock. Cambalachero (talk) 19:13, 31 May 2025 (UTC)[reply]
Oppose AI is a broad and general concept like algorithms, bots, programs and software which we already have in abundance. The WMF should obviously consult the community when introducing new features and usually does so. It's the applications and features that matter rather than the computing technology. Andrewš(talk) 08:30, 3 June 2025 (UTC)[reply]
As I touched upon in another section, I don't think wordsmithing a proclamation specifically regarding one category of technology is the best approach. I appreciate that WMF developers, in general, haven't always engaged the community to a sufficient degree to understand its concerns regarding feature development, and I feel the WMF needs to collaborate more with the community. To help overcome a natural resistance to change, though, I think the community needs to be understanding of exploratory work and rapid prototyping of different concepts. The spirit of a wiki is to quickly try things and revise. Of course, how this works on a highly visible web site is much different than less visible sites, and the effect of reader-visible changes (even for experiments) must be carefully considered. isaacl (talk) 15:58, 4 June 2025 (UTC)[reply]
"Quickly try things and then revise" is in an incredibly dangerous and ill-advised philosophy for this particular type of information technology. Our public-facing content gets automatically replicated in a variety of ways by a variety of actors, pushing it out into online ecosystems that we have no control over. The current state of art for generative AI as a nascent technology is absolutely riddled to the core with technical issues making it prone to producing deceptive, misleading information, and (very frequently) just outright hallucinated hogwash. Literally no LLM yet produced is incapable of producing such artifacts with alarming frequency. Integrating this technology with our systems at this moment in time (at all, let alone in the slap-dash, band-wagon-jumping-upon fashion that we are seeing from the WMF's devs), is utterly incompatible with this project's core aims and ethos. It is not a question of whether we will pollute the global corpus of factual information online if we fail to slow down the deployment of these tools: it is merely a matter of just how large the disaster will end up being because we failed to act with diligence. Thinking about the BLP implications alone sends a chilling spike into my core. Nor is this just a matter of our duty of care resulting from how we all assisted in placing this project at the heart of the dissemination of general human knowledge in the contemporary world. There are extra issues that are particular to this moment in time, because the project is in its most delicate moment in its entire history when it comes to potential external forces which would seek to control or suppress our coverage of many socially and politically pregnant topics. All it would take is for these summaries, or other LLM-generated content, to include a small handful of hallucinations about the "wrong" subjects in order to provide immense amounts of ammunition to people who leverage it to the earth for advantage in framing this project in a negative light. And again those hallucinations will happen--there's not the slightest question about it. The WMF should be presently conserving its warchest and focusing it's energies on the legal, social, and public image fight that will define the future of this movement that is going to take place in the next couple of years, not greenlighting technologies that are only likely to add kerosene to the fire. And meanign no disrespect, but there's a lot of people opposing a statement here that are clearly completely missing the point, accusing others of being a part of some sort of anti-AI moral panic from lack of understanding of the technologies while demonstrating their own misconception of the technical issues here. I for one just got done strenuously objecting to the blanket ban on AI images, and couldn't be more disappointed by the lack of nuance in the community's "solution" there. This proposal is clearly not about reactionary, irrational responses to the concept of AI proliferation. That's a larger issue and a bell that can't be unwrung by this community. What this proposal is about is creating a mechanism for this community to monitor, regulate, and control a very specific variety of such tools that we are uniquely positioned to control, by virtue of the community's inherent placement within the relevant systems and our understanding of the implications that will result if we do not exercise that restraint. It is especially necessary in light the Foundation's eminently apparent laissez-faire attitude to these same concerns and "light speed ahead" attitude towards deployment of these tools, despite the fact that they have not gone through even the smallest fraction of the testing or safety analysis that they should have before we were even contemplating such a move. And I say "we", but part of the issue here is that the devs have set an unrealistic timetable for all of this with virtually no consultation with the community. I'm sorry, but a lot of people here seem so pre-occupied with being a part of the crowd that "gets it" and aren't going to be 'chicken little's over an inevitable technological seachange, that they have fully Dunning-Krugered themselves into conviction that the dangers here are being exaggerated. And that's mind-bogglingly short-sighted. The risks here are profound, and there will be no effective way to reverse the damage if we don't show the prudence we should have here, at the outset. SnowRise let's rap01:19, 7 June 2025 (UTC)[reply]
I don't advocate for quick deployments of features in general, and I agree that there are plenty of areas where caution is key. I do think, though, that the community should keep in mind that it's very, very hard to get consensus in a large group, so requiring consensus to approve every step is a considerable bottleneck. I know some people think there are benefits to slowing down any exploration. All I'm saying is that the community should keep in mind the tradeoffs and where it wants to strike the balance between them. isaacl (talk) 02:05, 7 June 2025 (UTC)[reply]
As to balance, that's a reasonable position, but more of an argument against particularly worded statements than a solid basis for avoiding establishing any restraints. I don't see why, for example, Tamzin's statement of baseline principles would mandate such an extensive series of checks as you are imagining. What it comes down to is that we need to say something which communicates the following: "Hey, as we say around here, these are some pretty WP:BOLD and future-of-the-project-defining ideas that you are trying to push here, and we have some concerns. In fact, we really would have appreciated the community being formally consulted about this from the very beginning of blue sky planning on this, so our input on whether this was an avenue the community was comfortable with was explored before we were suddenly aware you had a half-finished alpha to launch. You all seem to have begged-off the question of whether this was even an in-principle good idea for this project and skipped straight to putting us under the gun to launch a tool that could have deep consequences for this project and how it is perceived. So, meaning no disrespect to the good intentions of the Foundation and its developers, we're going to need to talk about some guardrails here."In short, I see nothing in the proposals so far that would preclude a reasonable amount of oversight that would still allow for the prospect of development. And if some projects did not get greenlit, or get held up for extended periods of time while their rough edges are knocked off...well, that's precisely the point. There are considerable risks attached to the tools being considered here: in terms of our responsibility for our content, for the reputation of this project, and for the neutrality we count on as a legitimate justification for the strength of our processes even in the most uneventful of times, let alone in the shadow of the legal/social/political shitstorm that we all know is coming just over the horizon for Wikipedia. We should be assured that both the value of such technical developments and the risk management are both sufficiently where they need to be, before we assume those risks. And apparently, given the recent evidence, we seem to need to state that explicitly for the Foundation and its developers. SnowRise let's rap08:55, 7 June 2025 (UTC)[reply]
@Snow Rise I think I've said this somewhere below, but the checks and balances proposed in Barkeep statement are already the standard operating procedure at the Wikimedia Foundation for the most part. The recent Simple Article Summaries issue cropped up because of new technology being introduced, not the obvious shiny elephant in the room (generative AI) but the much less shiny and small elephant concept of A/B testing.
Typically, most features at the WMF is planned and developed iteratively with multiple rounds of feedback from different parts of the community, before a progressive roll out where the feature is deployed in a staggered manner to wikis with more and more activity. Every single wiki where a rollout occurs recieves a community notifications from WMF staffer, this is turned into a community consensus discussion if the wiki is a bigger wiki like enwiki. If a community reacts negatively to a rollout, the rollout is typically paused and eithier the wiki is skipped or significant changes are made to accomodate the wiki's demands. There are already significant checks and balances in the process already. Tamzin's proposal requires that the Wikimedia Foundation require community approval (mind you, not feedback) before this process is started, i.e. when a project is planned and developed something, which, while it sounds good in theory effectively means multiple consensus "approval" discussions at every step of something that is supposed to be a iterative process to begin with. (Imagine if WP:RFCBEFORE required a community-wide RFC to approve every single change to the "idea" already going to be proposed to the community as a RFC)
In the case of the Simple Article Summaries project, the Reading/Web team decided to follow a rather idiosncratic workflow. Instead of progressively testing their features across multiple wikis, and asking for feedback and community approval, the Reading/Web team decided to deploy their first iteration directly to the most populous wiki as a A/B test without any major community feedback cycles. The way the Reading/Web Team expected to deploy the project was through a Central Notice that introduced a small amount of code to trigger a dialog that then opted the user into the experiment (see, T387771). This is typically not how software development is done for most features on wiki. I think folks on the team failed to understand that even though the deployment was a "A/B test" in their eyes, the community and the readers would see it as deployment of a new feature (potentially without the communities approval). A/B tests are not something that is typically done on-wiki since we prefer to use feedback cycles instead (I think A/B tests have been used for a total of two or three projects in total). It is a new technology and I assume the folks using it made a good-faith misjudgement and were not aware of how it will be percieved by users. I've already pointed it out internally, but we really shouldn't be doing non-trivial A/B tests for features with prior community approval and I'm hoping the WMF will take that to heart after the negative reaction to this rollout and will modify it's internal processes to accomodate that.
TLDR, the existing process does have checks and balances and is for the most part sufficient to convert bad ideas into useful ideas that community might use (I'm pretty sure that if Simple Article Summaries went through the typical feedback cycles it would have emerged as a different product once the community opposition to genAI summaries became obvious over feedback cycles), I see the Simple Article Summaries as a good-faith accident by folks who did not understand the ramifications of how their test would be percieved. I see Tamzin's and other's "rejection" proposals as a introduction of significant beaurcrarcy into the software development process that will gut Wikimedia Foundation's AI team and significantly reduce (and potentially stop forever) any future development of AI features by the team. Barkeep's proposal is the most amenable at the moment, however, in it's current form, it is describing a process that is already in place. Sohom (talk) 14:21, 7 June 2025 (UTC)[reply]
A couple of years ago, there was a big kerfuffle about some live testing WMF was doing on enwiki. I was part of the small group that ended up meeting with the WMF to discuss this. As I recall, @Barkeep49 was also there; I don't remember who else. The end result was foundation:Policy:Wikimedia Foundation Staff Test Account Policy. It's not a perfect analogy to this situation since that specifically dealt with the use of undeclared WMF accounts and that's not what's happening here (well, not unless you consider ChatGPT and Claude to be socks). But I think it would useful to take a step back and read the broader message in that policy which is twofold:
Testing is an essential part of development. A lot of testing can and should be done internally, but at some point, you need to get exposure to real users to fully understand the impact of a new feature.
Wikipedia (and most other WMF projects) are production systems. Doing testing on a production system is risky and thus to be avoided until you've exhausted the alternatives, and then only after appropriate discussion with the community.
As I mentioned earlier, it is critical that we stay abreast of new technologies. That will inevitably involve making some mistakes and learning from them. Those who fail to adapt to a changing environment will inevitably discover that the environment doesn't care if they adapt or not. So the community just needs to get over that. On the other hand, I think the WMF didn't do a great job on the "only after appropriate discussion with the community" aspect. RoySmith(talk)15:04, 7 June 2025 (UTC)[reply]
I completely agree, and will add that the specifics of when A/B testing starts to need community consensus are not yet clear. We don't really want community consensus for tiny aesthetic changes, and massive features like generative AI definitely need such consensus. However, where do we draw the line is something we have yet to establish.The best example that comes to mind is mw:Edit check/Tone Check, another MediaWiki feature for which an A/B test is currently planned (phab:T387918). It is a lot less flashy than this "in-your-face" generative AI, and, at a first glance, we wouldn't expect consensus to be needed for a small "quality-of-life" feature. However, Tamzin raised major objections about the feature's consequences ā even if a test wouldn't cause irreversible harm to Wikipedia's image, it might be something that the community would want to reach a consensus on beforehand.I'm not saying that Tone Check in particular is the issue here, but that we should have a meta-discussion on which level of changes should require a community consensus before deployment on the English Wikipedia ā and, possibly, even a global consensus in these cases where implementation on one wiki might have consequences on others. Chaotic Enby (talk Ā· contribs) 15:09, 7 June 2025 (UTC)[reply]
Rushing to A/B testing was certainly part of the problem. There were others. The existence of the project indicated to the community that the WMF team doesn't think our leads are good and thinks it can make an AI that summarises complex subjects better than this massive and outstandingly successful community of editing volunteers. A survey focused on implementation suggested that rejection was inconceivable to the team. Sure, there's a question of why the team chose to and why they were permitted to carry out such testing, but framing this only in terms of testing enhances the perception of a gulf between community and WMF and the ever-present sense among the community that the WMF developers too often just don't get it. NebY (talk) 15:52, 7 June 2025 (UTC)[reply]
More communication is certainly needed, and probably from both sides. It could be great to have more avenues for interaction, as we often run into these situations where the community doesn't know the inner workings of the WMF (and at which stages they can give feedback!), and the WMF doesn't know the needs of the community. Chaotic Enby (talk Ā· contribs) 16:10, 7 June 2025 (UTC)[reply]
In the first draft of my comment above, I also used the phrase "both sides", but then I thought better of it. The problem is that saying "both sides" reinforces the mindset that there's a competition here, and I would prefer that we not think like that. WMF and the editing community exist in a symbiotic relationship. RoySmith(talk)16:20, 7 June 2025 (UTC)[reply]
Yes, I completely agree with that ā I was thinking of "both sides" in a non-competitive way (two communities working together), but it's true that the notion of "sides" might be a little too "us vs them". Maybe "both communities" could be a better wording? Chaotic Enby (talk Ā· contribs) 16:23, 7 June 2025 (UTC)[reply]
@NebY For context, The original proposal comes from a specific subsection of WMF planning where they are trying to Increase retention of logged-out readers by 5% on apps and 3% on web by creating "new experiences". (Something that has been previously requested by community folks as well) They had decided to tackle the fact that our leads our not good. (The WMF is not strictly speaking wrong here) The project was to see if [the WMF] can make an AI that summarises complex subjects better. (And I don't think it's a inherently problematic thing to investigate to be honest) That was the hypothesis and it was mentioned during the planning process (search for the text: "machine-generated summaries" in the planning document) which underwent community feedback until 31st May. (The document has a awful amount of corporate speak and I don't fault the community for not finding the problematic parts) The way they went about implementing their test for the hypothesis was flawed. (For all of the reasons outlined above) If the team had gone thought the proper steps of iteration and community feedback they would have probably figured out that AI-summaries was not the correct place to go and would have potentially landed on community-led summaries once their hypothesis was proved wrong. The jumping of the gun and direct "test on 10% of users" was the reason we ended up with a community confrontation. Sohom (talk) 16:55, 7 June 2025 (UTC)[reply]
I've worked in big places that had a multi-layer approach to rolling out experimental services. We used to start with "teamfood", where only members of your dev team would get the new feature, then proceed to "dogfood" (as in Eating your own dog food) where it was shown to all company employees.
Then we would move on to what I guess in other places might have been called a "public beta", where we rolled out the new feature to some percentage of external users in an A/B comparison test. The selection of users could be configured in all sorts of ways ranging from those who met some specific requirements ("Don't show to users who are subject to GDRP") to totally random. Typically we'd slowly ramp up the percentage as we got more confidence in the feature. This also had the nice side-effect of letting us better judge the performance impact on our systems. It also gave us a built-in Kill switch. If we found some drastic problem, we could immediately stop all testing without having to roll out a new deployment.
I wonder if we could do something like that here (in general for new feature rollouts, not specifically just this one). Have some way to identify "internal users". Perhaps those with more than some threshold of account age and number of edits (perhaps with opt-in/opt-out layered on top). Let them get the feature first and solicit comments from them. WMF typically does rollouts on small projects first, and enwiki last; the problem is that by the time enwiki gets the feature, it's already a fait acompli. RoySmith(talk)17:21, 7 June 2025 (UTC)[reply]
An opt-in A/B test group could be helpful in getting data from a broad set of users, while not affecting the vast majority of Wikipedia readers. It wouldn't be as good as a random selection (and probably, to avoid affecting performance for non-logged in readers, only be available to logged in users), of course. isaacl (talk) 17:45, 7 June 2025 (UTC)[reply]
Yes, I am aware of this work in progress. As far as I understand it, the capability enables A/B testing but doesn't allow for opt-in. An opt-in level may be helpful for some types of A/B testing that may be unduly disruptive for the entire readership. isaacl (talk) 17:57, 7 June 2025 (UTC)[reply]
Since it is based on browser cookies, making it opt-in is technically feasible (only add the cookie of people subscribed to the testing). However, it will of course be a skewed sample (mostly focused on experienced editors), but that can definitely be a good in-between step before full testing, and allow for editor feedback.However, for big additions like Simple Summaries, I'm not necessarily sure going straight to A/B testing is the best option, even on a small sample. A/B is really effective when you are comparing two versions of the same feature ā not when you are adding a whole new layer to your product, with consequences that you can't really measure with engagement metrics alone. Chaotic Enby (talk Ā· contribs) 20:17, 7 June 2025 (UTC)[reply]
Sure, with development, it's possible. As far as I can tell, it's not currently within scope. My understanding of the current implementation plan is that it's handled on the edge, caching servers, so it doesn't know if you're logged in or not, and has no access to any personal configuration. isaacl (talk) 22:16, 7 June 2025 (UTC)[reply]
I think the problem is not that there isn't a feedback process, but that the feedback process is not working. This is the feedback received from the study, which seems to have been 8 participants, some of whom are non-native English speakers, with the conclusion We might have a hit on our hands with this feature.
The most troubling part of this is that: "The only participant who said they would not use it was a seemingly native English speaker who used university-level diction in their responses. They expressed familiarity with deep reading for research. For them, Simple Summaries weren't useful because they would just read the article. This may suggest an inverse proportion of educational attainment and acceptance of the feature. 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."
This feels, frankly, like an invitation to disregard all feedback from us because "it's not 'for' us." It also feels patronizing to lower-literacy and non-native English speakers to decide that the factually incorrect and unencyclopedic AI "summary" content generated is good enough for them. Gnomingstuff (talk) 08:27, 8 June 2025 (UTC)[reply]
It could be interesting to see how representative that sample is of the Wikipedia audience. Assuming that editors must be "hyper-literate", and that there is a rift between them and readers, feels at odds with Wikipedia's mission, and I am curious to see if there are statistics on reading levels in readers and editors. Chaotic Enby (talk Ā· contribs) 13:01, 8 June 2025 (UTC)[reply]
@Gnomingstuff, To push back a bit, a) I wouldn't consider this to be a feedback stage, that is a initial survey and nothing else b) I don't see that as a invitation to do anything here, but as a personal observation/editorializing on the part of the research team conducting the survey (and probably a accurate statment one to be honest). Multiple countries where I would not expect folks to not know English that well show up among the top 10 countries that visited Wikipedia last month, including the likes of India, Brazil, Germany and Phillipines (see this table). I would like to encourage folks to still assume good faith against WMF staffers and not assume that they had pre-emptively decided to ignore consensus.
@Sohom Datta, the other thing I'm having in mind is the question of whether editors are consciously writing for a lower reading level than their own. While that would be ideal, editors might unconsciously use their own understanding level as a reference point, and having statistics on the reading level of our articles could be good.I know that reading levels of the original articles were evaluated in phab:T395246 using the Flesch-Kincaid Grade Level, but, as far as I know, that was only used as a quality metric for the summaries. I'm wondering if we should look at it from a more statistical point of view to evaluate whether there is a discrepancy to begin with, and how much, between our content and our readers. The JSON files should be available, so I could look into that if a similar thing hasn't been done already. Chaotic Enby (talk Ā· contribs) 14:34, 8 June 2025 (UTC)[reply]
We are not meant to be targeting places where one "would not expect folks to not know English". It is not a problem to be solved that people who do not know English do not understand our articles well. To be sure, it would be nice if they did, but that isn't a target for en.wiki and anything aimed at that is going to be wildly misplaced. CMD (talk) 14:44, 8 June 2025 (UTC)[reply]
@Chipmunkdavis, I don't quite understand your take here, we should always try to make our article accessible to folks who might not have the same command of complex English that I or you have. Yes, obviously certain folks who do not understand English as well will be underserved, but that does not mean we shouldn't try, especially when some of those demographics make up a large portion of our readers. I know we are not there yet, but dismissing it as "English Wikipedia is not targetted at them" doesn't seem in line with our mission of being a encyclopedia in the first place. Sohom (talk) 15:12, 8 June 2025 (UTC)[reply]
"folks who might not have the same command of complex English" is not exactly the same goalpost, and that will result in different considerations. English Wikipedia is targeted at English language speakers, being one of 342 currently supported language encyclopaedias, each intended to reflect speakers of that language (plus those that have been shuttered, because they did not reflect speakers of their language). CMD (talk) 15:25, 8 June 2025 (UTC)[reply]
@Chipmunkdavis I see where the disconnect comes from, when I said "would not expect folks to not know English" I meant "would expect to have a reduced competency in English/have the very good command of complex English", sorry for the mixup :( Sohom (talk) 15:32, 8 June 2025 (UTC)[reply]
I'd like to and am trying to assume good faith, but the research team has already characterized readers who might be opposed to the feature as, among other things, "internet pundits." That's not the kind of phrasing one uses when talking about someone whose opinions they value. The whole thing also mischaracterize why people might not like the featur. Most people here aren't opposed to a simple summary feature (as you can see in the discussions), but to the use of generative AI anywhere, and to the poor quality and poor accuracy of the AI-generated blurbs. Gnomingstuff (talk) 16:40, 8 June 2025 (UTC)[reply]
@Gnomingstuff The person who wrote up the report is somebody from UX design who (I assume) was editorializing a fair bit because they were enthusiastic of their work and was relatively new to the WMF (I think they joined in 2023) and thus did not expect this level of scrutiny in what was a pretty small report (I don't even know if they expected public scrutiny in the first place). Folks are human and even stodgy academic research papers take victory laps at times that are ill-judged (there is a paper in 2008 that claiming that they had solved web security). Yes, in hindsight it was a a poor choice of wording, but you still have the burden of proof that this sentiment was shared by the whole team (or for that matter by the rest of the leadership). Sohom (talk) 16:54, 8 June 2025 (UTC)[reply]
You're right, I don't know what the whole team thought deep down in their heart of hearts about the report, but the team was happy enough with it to directly link to it on the Simple Article Summaries overview page that they showed to us on the original village pump thread, and to quote from its findings and judgment of the "main issue to be addressed before release." They also seemed to have enough trust in the results to go ahead with the next stage of the project (the browser extension experiment), and to make that feedback-gathering less about whether the summaries were a good idea, and more about whether people clicked them. From what I understand, the survey that we got also didn't include any place to say we didn't want this feature, but I didn't see it so I don't know exactly what was asked. Gnomingstuff (talk) 17:14, 8 June 2025 (UTC)[reply]
That is a good point, I agree that there was a lack of a "we don't like this" option presented to us in the original message. I will bring that up internally/at PTAC as another potential area for improvement. I don't think the idea was to shut out community feedback, but with hindsight it does look bad that no such option was provided. Sohom (talk) 17:36, 8 June 2025 (UTC)[reply]
Thank you for doing that. I don't think the idea was to shut out community feedback or mislead the community, although in practice the community has been misled and I haven't been impressed with the PR-speak surrounding the whole thing. I do think that the idea devalues the content of the summaries, so much as the perception that they are good or trustworthy.
A lot of that could be been solved even without community involvement, even. We wouldn't be here had the WMF hired copy editors/fact checkers to go through each "summary" and flag anything with inappropriate tone, false statements, or statements that weren't in the original article. Basically anything that violates the prompt. (I used to do this at my last job for alt text.) This would at least have caught a lot of the crap like how Tinder is "a fun and easy way to meet new people online" or how the GDP is "like a report card for a country's economy." If they really wanted to do it right they would also hire subject matter experts to fact-check them, since a lot of the errors are subtle. Gnomingstuff (talk) 17:52, 8 June 2025 (UTC)[reply]
@Sohom Datta, Yes, the team tackled a hard problem. Our leads are like democracy, not good but better than the alternatives, perpetually in tension between being readable and being right ā checks and balances, if you like. Now we find that some initial summaries were said to be readable so a batch were sent to legal, who threw some out but didn't point out that others just weren't right. Was it no-one's place to say so, would no-one dare to say the emperor had no clothes? And in seeking to maximise reader retention percentages, are developers of AI summaries, tonechecks etc. and their management too deprioritising Wikipedia's USPs, such as the high standard expressed in Wikipedia:Five pillars, "All articles must strive for verifiable accuracy"? NebY (talk) 14:18, 8 June 2025 (UTC)[reply]
@RoySmith, Legal review is fairly standard (read mandatory) for new deployments of features on any production wiki. There have been cases (the Commons Structured Data deployment comes to mind) where legal review required changing the publishing flow to include text that mentioned the license they were being published under. Given that the summaries here were statically hardcoded by the extension, I assume the legal team found them in the source code and decided to review them as well, I don't think the idea here was to have legal review every summary going forward or for legal to have any say in what the summaries would say once the actual extension was deployed. (atleast they don't mention any plans about it in their mediawiki page, in fact, the extension did not even have ways for the enwiki community to moderate the summaries themselves, which was mentioned on the mediawiki page which imo is a critical oversight).
A more community forward/better plan would have been to allow the community to review before this freaking thing happened, but I think we've already established that the Simple Article Summaries was a poorly thought out experiment that should have never been deployed on a live wiki to start with. Sohom (talk) 16:41, 8 June 2025 (UTC)[reply]
I assume for the usual reasons lawyers do pre-publication reviews: check for copyright vios, defamation, incitement to violence, etc. Remember: these summaries aren't written by the website's users, they're written by the WMF (by software written/maintained/used by WMF employees) so none of the internet safe harbor stuff would apply. Not surprised it would get legal review. Levivich (talk) 16:41, 8 June 2025 (UTC)[reply]
BLP concerns, libel, etc. Here's one discussion from phabricator, and this link lists a couple of subjects that are problems (note: this filter doesn't seem to have been implemented yet, and the sample summaries certainly haven't been filtered on it, otherwise stuff like Project 2025 and Jeffrey Epstein and antisemitism and suicide would not even have made it into the test summary set).
Murders (crimes generally in the last 100 years)
Terrorist acts (e.g. hotel mumbai shooting, Las Vegas sniper)
Political parties that still exist
Terrorist groups
Mental health (suicide, depression)
Controversial subjects (bomb making; chemical weapons)
@NebY, I see the Simple Summaries experiment as a tech demo to gauge sentiment rather than an oportunity at evaluating the summaries themselves. I assume the reason the summaries were thrown away was because the assumption was that the English Wikipedia would have the power to do the same when it came to the actual deployment of the feature. Also, legal review is a standard part of any feature being deployed onwiki, it was not something specifically added to bolster this feature's chances. I see no evidence for us to assume malicious/bad faith against the product managers who are leading these initiatives. The metrics used to evaluate these models (from a ML POV) are unfortunately not public but I assume both that and the number of summaries that were thrown away would have factored into the final report as a potential downside when evaluating the experiment as a whole. To my understanding, this is not a case of willfully hiding evidence, but the fact that we are looking at the wrong thing in the wrong light and assuming intentions that just weren't there to start with.
I particularly dislike your framing of Tone Check's product manager as person who deprioritises Wikipedia's USPs. The product manager has been extremely responsive onwiki, has taken Tamzin's concerns to heart, has opened phabricator tickets tracking work on the feedback they have recieved (see T395166 and T327563 and T327959), and has committed to interacting with and onboarding feedback community and answering folks questions about the product through a community call hosted on Discord. Sohom (talk) 16:11, 8 June 2025 (UTC)[reply]
I'm not suggesting malice or bad faith. I am perturbed that the reviewing of the summaries was limited. I have a lot of respect for the intelligence and general knowledge of staff in legal departments, so I would guess they would have noticed that there were also factual errors without legal implications but might not have felt it was within their remit to point them out. In such ways, alas, the emperor goes down the road without anyone calling out.
I have no intention of accusing anyone of wilfully hiding evidence, I don't think they have and don't know how you've read me that way. This is an entirely different kind of process failure, or rather multiple failures, and they're disheartening because they suggest a cultural disconnect. I'm very glad that the Tone Check project manager is now putting such effort into engaging with the community; I remain concerned about the organisational culture and processes that got them into this situation. NebY (talk) 16:39, 8 June 2025 (UTC)[reply]
@NebY The review of the summaries was limited agreed. That being said, I don't think legal is the team that is considered to be very engaged with the product and the community. Typically feedback and community insights (atleast in the context of WMF features) come from the engineers, other product managers and community laisons (read movement communication folks). Many of the engineers (and some product managers as well) at the WMF are folks who are English Wikipedia volunteers who have spent significant amount of time volunteering onwiki (some of whom are admins on this wiki and have served as stewards). Also, yes, the culture inside the WMF is obviously not as open as that of Wikipedia, where anybody can object to anything, but in my experience, it is a lot more open than most other tech companies working in the web space. (I can speak from personal experience, I've met folks from the Growth team, Community Tech team, the Moderator Tools team and even folks who are currently in charge and every one of them were interested in hearing and onboarding criticism/feedback of the products their teams were developing). Sohom (talk) 17:31, 8 June 2025 (UTC)[reply]
There are already significant checks and balances in the process already.
Yes, I am aware. But very clearly more is needed here, when 1) at least one development team has demonstrated just how laissez-faire they can be about existing custom in this respect, and 2) the software in question here presents an unprecedented danger and a challenge to safe deployment that is very arguably not feasible to meet at this time.
Tamzin's proposal requires that the Wikimedia Foundation require community approval (mind you, not feedback) before this process is started, i.e. when a project is planned and developed something
Right, which is, beyond the merest shadow of a doubt, exactly how that should work, for anything that would involve textual content creation by any generative model. We should never be hearing about anything that uses generative AI when the development team is preparing to test on our production pipeline/public facing content. There should be no question in the minds of anyone working at any level at or for the WMF of that happening again with anything involving a generative model producing article space or adjacent content.
which, while it sounds good in theory effectively means multiple consensus "approval" discussions at every step of something that is supposed to be a iterative process to begin with.
Again, I just don't see that mandate in Tamzin's statement of interests. Can you be more specific about what language makes you fear an endless series of checks? What I see is a clear requirement that the community be informed early of the concept and be given the opportunity to scrutinize the idea during the blue sky phase (and yes, if the community finds the concept too problematic in even the broadstrokes, the opportunity exercise its discretion in whether to allow development of the feature on-wiki to proceed.
(Imagine if WP:RFCBEFORE required a community-wide RFC to approve every single change to the "idea" already going to be proposed to the community as a RFC)
The problem with that analogy is that we are not talking about garden variety RfCs, or anything like such, here. It is very difficult to overstate just how much damage could be done--and just how irreversible much of it could be--by not exercising caution in this area.
In the case of the Simple Article Summaries project, the Reading/Web team decided to follow a rather idiosncratic workflow. . . . It is a new technology and I assume the folks using it made a good-faith misjudgement and were not aware of how it will be percieved by users.
I agree with all of this, but with a critical caveat: the issue is not merely how the approach of the team was bound to be perceived by the community: more important is the huge potential for damage with this tool, and the apparent sight-blindedness of the development staff to that fact as well.
I see Tamzin's and other's "rejection" proposals as a introduction of significant bureaucracy into the software development process that will gut Wikimedia Foundation's AI team and significantly reduce (and potentially stop forever) any future development of AI features by the team.
The thing is, to my mind, that is by leaps and bounds the lesser of two evils here. The possible stalling of AI development generally has far less potential for catastrophic harm than unchecked use of generative AI in content drafting at this moment in time. Here's the very simple truth of the matter: every LLM trained for text production hallucinates--or let's put it in more apt terms for our purposes here: makes shit up. Left, right, and center. Constantly. Now this might be a feature that can be to some extent forgiven in certain use cases--or at least has less severe consequences in some. But when your business is very specifically providing factually reliable information, that is a hell of an unavoidable implication of a tool. LLMs simply do not have robust self-corrective mechanisms in this respect, and it could be some time yet before they do, as this is a consequence of the fact that LLMs do not employ logical syntax like traditional software but rather produce their output through weighted associations--as I'm sure you know. Point being, this is not a quality of such models that is going away over night, nor one which the WMF software development teams are going to be capable of mitigating, by and large. So honestly, if our "bureaucracy" leaves us two years behind where industry leaders are other actors are racing forward (and not altogether without negative consequences, mind you), that might very will be the best possible thing that could happen in these circumstances. We have to recognize that these tools, as they exist today, are not fit for purpose for the work of this project. In fact, we might just be the single worst place to try to deploy generative AI text, in the entirely of the contemporary information ecosystem online. And yes, I recognize that part of your concern is that all AI software may get lumped in with LLMs. But A) I don't see why that outcome can't be avoided with further discussion about what the ultimate oversighting guidelines look like and B) even if that were a result of community action, I would still judge it a small price to pay, relative to the potential harm of swinging too far towards a too permissive attitude from the community on these issues. SnowRise let's rap22:20, 7 June 2025 (UTC)[reply]
@Snow RiseBut very clearly more is needed here, when 1) at least one development team has demonstrated just how laissez-faire they can be about existing custom in this respect, - I don't know if I've made this clear, but the web team was nowhere close to deploying the feature, they decided to do a tech demo (for the lack of a better word) on a live wiki and whatever you would expect to happen in that case happened. Better policies are needed but it is a broader discussion and a problem for every feature rather than just AI. WMF internal processes need to change here.
Right, which is, beyond the merest shadow of a doubt, exactly how that should work - Consensus is a very different thing from feedback. Consensus means a 30 day wait with a mandated binary outcome often final, even if based on an early version of a feature. That kind of rigid checkpoint can actually undermine the iterative nature of development. For example, if early concerns (say, lack of moderation) get fixed midway through development, but a significant portion of the community had already opposed it based on the first iteration, the project might be dead-on-arrival despite having meaningful improvements with no downsides. Feedback on the other hand is a two way iterative street.
We should never be hearing about anything that uses generative AI, Generative AI is not a one-dimensional technology there are uses cases in areas such as translation, classifying and highlighting text that might be too technical or gendered and so on, that would not harm the encyclopedia.
Again, I just don't see that mandate in Tamzin's statement of interests. - Ideas change iteratively throughout development. Let me take the case of a fictional Simple Article Summaries, which (say) that it made it through it's first round of review by the community and it was agreed upon to use a specific kind of AI model that was free from hallucinations (say). Now, imagine the product manager found that the agreed on AI-model architecture was not able to scale to being used across so many pages requiring a rethink of the architecture and the use of a different model, previously it would have been a quick-ish switcharoo, now requires a RFC. Now, imagine, after that the product manager finds out that model really doesn't like a particular set of Japanese or Chinese characters that are present in a bunch of ledes and needs to change the model architecture again, what would have been a day's worth of work needs a 30-day wait. This is in stark difference to Barkeep's proposal which says "hey, you need to get feedback before deploying on enwiki", which would have also caught the problems without potentially having 3 RFCs dragging on a week of iterative development to 3 months (this is a conservative estimate assuming only the English Wikipedia was targeted).
more important is the huge potential for damage with this tool, and the apparent sight-blindedness of the development staff to that fact as well. - I agree that they shouldn't have done it, on looking at the extension source code it was nowhere near production ready and I'm not sure why they decided to experiment with it on production. I'm as interested as you are in figuring out what went wrong so that we can apply the bandage correctly and in a way such that we avoid such a outcome going forward for any product, not just AI ones.
So honestly, if our "bureaucracy" leaves us two years behind where industry leaders are other actors are racing forward - The AI team doesn't only work on new features. They also help maintain the liftwing infrastructure which is used by almost every antivandalism tool to filter for more severe vanadlism edits and many of the growth features used in Special:HomePage. Gutting that team will mean that a large portion of this critical infrastructure will be left without a good maintainer or a steward. I'm not sure that's a good (or even desireable) outcome? Sohom (talk) 00:15, 8 June 2025 (UTC)[reply]
Consensus is a very different thing from feedback. Consensus means a 30 day wait with a mandated binary outcome often final, even if based on an early version of a feature. I don't think this rigid RfC-style consensus is necessary in most cases. I see it more as semi-binding feedback: if there is a clear consensus in the community's responses (maybe just after a few hours or days), WMF researchers should take it into account to some extent. But it doesn't mean they have to wait for someone to formally close the discussion or be forced into a binary choice: in most cases, the community's opinion might be more nuanced, and an open discussion (rather than a rigid binary) can capture this better without forcing the researchers' hand in non-obvious cases. And, at the same time, researchers can keep iteratively working on the feature and gathering feedback on their updates from the community, making this a continuous back-and-forth discussion rather than a series of rigid RfCs.Generative AI is not a one-dimensional technology there are uses cases in areas such as translation, classifying and highlighting text that might be too technical or gendered and so on, that would not harm the encyclopedia. From what I understand, those latter two would be classification rather than generation? Granted, the same models are often trained on both tasks, but I don't think every use of language models necessarily counts as generative. Chaotic Enby (talk Ā· contribs) 00:25, 8 June 2025 (UTC)[reply]
I don't think this rigid RfC-style consensus is necessary in most cases. I agree but I fear that given that AI is a controversial topic, chances of discussions spiraling out, requiring multiple days is going to be norm without folks who are confident of acting as discussion moderators/stewards. (not to mention, that detractors of semi-controversial features would be more likely to vote in subsequent RFCs than the folks who aren't invested in the feature but supported it, making it harder for a "yep your good" outcome early on). I would potentially be advocating for a very different outcome if Tamzin's statement read without first obtaining substantial feedback from potentially affected wikis
From what I understand, those latter two would be classification rather than generation? - You are right, classification would definitely be classificative, highlighting could be generative depending on the context. I was more equating generative AI to the transformer architecture. Sohom (talk) 01:06, 8 June 2025 (UTC)[reply]
Better policies are needed but it is a broader discussion and a problem for every feature rather than just AI. WMF internal processes need to change here.
That's a cogent point, but I for one have no problem with starting by creating a particular bulwark against overly credulous, incautious, devil-may-care approaches to this particular variety of issue, given its unique challenges and particularly pronounced and self-evident risks. If the community wishes to contemplate a more extensive re-orientation of the oversite of WMF labing on the project, I'm sure we'll all have opinions. But one thing at a time in order of operations matching the scope and cause for concern, is my take.
Generative AI is not a one-dimensional technology there are uses cases in areas such as translation, classifying and highlighting text that might be too technical or gendered and so on, that would not harm the encyclopedia.
As someone with multiple dimensions of expertise on this subject, I actually think the issues with AI generated translation are much more significant than have been recognized on this project to date. But I'm also capable of recognizing the ship has to some extent already sailed there. Again (and with sincere respect, I feel like we are going around and around in circules on this point), the kind of AI that I (and I think most others here with heavy concerns) am saying needs to be either outright proscribed for the immediate future or must be at least considered with the heaviest of scrutiny and testing from the earliest planning stages is this: LLMs and other ML-based models which generate natural language ouputs for any public facing content space on the encyclopedia. I think that's very specific and tailored, and entirely reasonable, given the objectives of our editorial work here and the known, common, and serious flaws of LLM-generated text, vis-a-vis constantly generating non-factual statements and fake sources (to name just the most serious manner in which such content is typically an issue, but hardly the only one).
Ideas change iteratively throughout development . . . potentially having 3 RFCs dragging on a week of iterative development to 3 months (this is a conservative estimate assuming only the English Wikipedia was targeted).
Again, I feel we're going around in circles to some extent here too, because I don't see why you think (for example) Tamzin's proposed statement would lead to such a cumbersome system, and I don't think I'm going to understand that belief until you explain what specific verbiage in their statement gives you that concern. But honestly, at the risk of sounding like a broken record, even if I thought that was a possible outcome, I would still favor the proposal over the current status quo and lack of a reasonably spelled-out statement of what the community does not want to see in terms of generative AI without, and forgive the stolid bureaucratic speech: an epic shit ton of discussion and community consultation, with full transparency from the devs from the earliest planning states. And honestly, such rules stand to save the devs much time and wasted effort on something that is never going to fly here, in addition to serving the project's needs.
The AI team doesn't only work on new features. They also help maintain the liftwing infrastructure which is used by almost every antivandalism tool to filter for more severe vanadlism edits and many of the growth features used in Special:HomePage. Gutting that team will mean that a large portion of this critical infrastructure will be left without a good maintainer or a steward. I'm not sure that's a good (or even desireable) outcome?
No, indeed not, I agree. But that also feels like a false choice to me. The community, I think, is more than capable of making distinction between the former category of technical product and the latter. The general editorial community and our technical specialists have been striking this balance more or less capably for a long time. I guess I'd agree with the statement that this is getting to be a more difficult balancing act all of the time, but I don't think the proper solution to that issue is to start writing the WMF's dev teams blank checks. Especially when this episode has emphasized just how out of touch they can be about what is a useful feature, vs. something that is terrifyingly ill-judged for an encyclopedia. SnowRise let's rap05:13, 9 June 2025 (UTC)[reply]
@Snow Rise, Tamzin's current proposal is ambigous in it's current state, due to the fact that it does not adequately define what happens when a "idea" changes. What happens if within a single project multiple iterations with different novel avenues of using AI are proposed during it's lifecycle? Your reading appears to be the more positive view that the community will auto-approve the new novel avenues since the previous ones were also approved by community consensus. I however am taking the more pessimistic (and imo realistic) view that community members who are not for controversial features will try to wikilawyer the definition of "novel avenues" and will call for the team to participate in multiple long RFCs every time changes are made to the idea that subtantially alter how the AI will be deployed. I find your assurances that the community will somehow turn into a oracle on AI-software projects to be very unlikely based on historical experiences during my four+ years working on Wikimedia software code as a volunteer developer. Sohom (talk) 06:31, 9 June 2025 (UTC)[reply]
Well, I guess my perspective is that Tamzin's statement (or another similar one) should be the start of our regulatory efforts here, not a final guideline as the particulars; it is, afterall, heavy on aspirational statements of concern and the relative remit of the WMF development teams and the editorial community, and features next to nothing in terms of specific proposed processes. I fully agree that we'd need something that sets clearer standards and thresholds that would allow developers to be flexible (and indeed, transparent with the community) concerning their approach. We gain nothing by making them feel so nervous about making proposals that they hedge their bets and communicate in non-specifics for fear of triggering a backlash they can't recover from. But to my mind, none of that obviates the need to set out some broad-strokes expectations to start. Considering your response, and taking a look at Tamzin's wording with those thoughts in mind, it seems to me that the most operative/controversial phrasing is that concerning "novel avenues". I have been interpreting this as meaning we should have a handful of major checks for any new proposed software feature. I can see now that you (not unreasonably) believe that this might be interpreted as a call for consensus being triggered by any change in approach, even minor pivots between major benchmarks. But I think this can all get ironed out with further WP:PROPOSALS. I just think the danger of doing nothing is more pressing and significant than potential stagnating effects from an initially somewhat broad statement. As other have noted here, I don't think we should let the perfect be the enemy of the good in this particular moment. That said, I don't want to minimize the issues you raise, and I see how you come to view them as major stumble points from your particular experience and perspective as a developer. I just think there's a happy medium that can be reached, with the statement in question as the first stepping stone, rather than the final word. SnowRise let's rap06:55, 9 June 2025 (UTC)[reply]
@User:Snow Rise I spent a bit of time, I don't think I can bring myself to support Tamzin's statement since I don't find the assurances of "we will figure it out at some point" to be anywhere near sufficient. However, maybe we can split the difference and land on something like so?
At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation, with varying degrees of success. The use of AI for translation has been controversial and the WMF's use of generative AI as a proxy for content in Simple Article Summaries was unanimously rejected by the community. As a result, the English Wikipedia community rejects any attempts by the Wikimedia Foundation to deploy novel avenues of AI technology on the English Wikipedia without first obtaining an affirmative consensus from the community.
Deployment here refers to the feature being enabled in any form onwiki, eithier through A/B testing, through the standard deployment process, or through integration into Community Configuration. Modifications made to existing extensions and services like the ORES extension or the LiftWing infrastructure must be atleast behind disabled by default feature flags until affirmative consensus is achieved.
Wikimedia Foundation teams are heavily encouraged to keep the community notified of the progress of features through venues like WP:VPWMF of ongoing initiatives and to hold multiple consultations with affected community members through out the process of the development of the features.
Wikimedia Foundation teams should also keep transparency in mind as it works on AI, both in communication with projects and by enabling auditing of its uses, especially on projects (e.g., use of a tool having a tag applied automatically and open-sourcing and documenting onwiki the output, methodology, metrics and data used to train the AI models).
TLDR of what this means, we ask for only a single hard requirement for consensus before deployment, and we heavily encourage folks to follow a set of general transperancy guidelines when developing AI features. Sohom (talk) 09:14, 9 June 2025 (UTC)[reply]
Speaking for myself, that would satisfy all the major signposts I'd like to see in an initial statement of principles, and even adds some extra weight to important points, in addition to the carve-outs you made for the additional specifics on bottlenecks. I'm still in support of Tamzin's proposal in principle, but if you wanted to post this as an alternative/refined statement, I would give it my formal endorsement, and I think it stands a chance of getting robust support. SnowRise let's rap09:26, 9 June 2025 (UTC)[reply]
I would also agree, and it looks similar to my proposed statement below (which also focused on implementation rather than development, although with some nuance). Chaotic Enby (talk Ā· contribs) 12:52, 9 June 2025 (UTC)[reply]
As I stated, I don't think a statement about one single category of technology is the best approach. I think the community is broadly concerned about feature deployment in general. I think there needs to be better feedback loops for all development. It's often useful to be able to discuss some ideas, and then develop some test concepts or prototypes to help focus more discussion. Personally I feel that it would be too constraining to require community consensus to be established for every early stage idea. isaacl (talk) 17:22, 7 June 2025 (UTC)[reply]
I agree with your point that this discussion shouldn't be focused exclusively on AI, especially since that is a topic that can easily bring up more heated emotions. Giving more opportunities for communication, and making editors aware of the already existing ones, should be a more general trend. It could be helpful to have more updates (newsletters maybe?) about current WMF research projects, written in a digestible, non-corporate-speak way. Chaotic Enby (talk Ā· contribs) 20:23, 7 June 2025 (UTC)[reply]
There's a bulletin regularly posted to this page, with links to various other newsletters and bulletins, and a technical newsletter is regularly posted to the technical village pump. It's challenging because there's a lot of news and everyone has their own specific set of interests. The crowd-sourcing way would be for interested people to aggregate the items related to different domains, but this requires substantial sustained effort. Delegating to a group of representatives is one typical way to enable a crowd to have influence while managing the demands on people's time, but so far those in the English Wikipedia community who like to comment on these types of matters generally prefer not to cede their representation to others. isaacl (talk) 22:31, 7 June 2025 (UTC)[reply]
My thoughts align with Isaacl here, I am not a advocate for the the "move fast, break things mantra" (atleast not onwiki) but this proposal is the equivalent to requiring a RFC-style super-majority approval for every single major edit in a contentious topic. That is just simply not something I can get behind having spent the last four years working on the software development side of Wikipedia especially when it is applied to a field as broad as AI (which you appear to be confusing in your comment with the more narrowly defined and more controversial subset of technologies centered around generative AI). Sohom (talk) 02:59, 7 June 2025 (UTC)[reply]
If I was unclear as to what I meant, let me address that immediately: I meant any generative AI software which autonomously creates textual content, including that generated in an effort to summarize our existing content. Any project or development that seeks to put such content before the eyes of the general reader in any capacity should be seriously questioned, rigorously studied for flaws, and in most cases presented to the community through a formal process well before the actual development begins in earnest. And afterall, why should it be any other way? Last time I checked, this community is still responsible for the content on this project. The fact that the Foundation now, for the first time, has potential tools to generate content in substantial amounts without the need for the community does not mean that the classical remits of each arm of the project have now evaporated into thin air. Unless this community has decided to cede that privilege/responsibility. But for crying out loud (not directed at you Sohom, more a general appeal), surely that prerogative adheres from a lot more in our movement's history and foundational organization than just the fact that the Foundation didn't have Wiki chatbots until now? Those observations aside, my response to your concerns about unwieldy bottlenecks is substantially the same to how I replied to Isaacl above, so I'll direct you there, and summarize here: we don't need a million little checks, but we do need transparency from early in the planning stages and some degree of vetting. SnowRise let's rap09:13, 7 June 2025 (UTC)[reply]
No, I don't think we as a single community should be telling the WMF what to do and what not to do. If they develop such tools we'll get to decide whether or not to adopt them at that time, and the WMF has other ways for the overall community of Wikimedia project members to contribute to these sorts of discussions. en-wiki is the biggest of those projects and we shouldn't be throwing our weight around about every issue. Our purpose is to build an encyclopaedia not tell charities how to run their affairs. WaggersTALK12:31, 9 June 2025 (UTC)[reply]
"If they develop such tools we'll get to decide whether or not to adopt them at that time" probably should be how it works, but we know it's not accurate, given there was no such option presented to the community when the llm-generated article summaries feature was scheduled to go live. CMD (talk) 01:38, 10 June 2025 (UTC)[reply]
Oppose for a variety of reasons. As other have stated, enWP is just one project. In addition, I do not think dividing WMF and enWP in advance of a problems is a good relational strategy. I also want to underscore that AI is really too vacuous and evolving of a term for a resolution to be advisable. The meaning of AI is evolving and it is ultimately a means to an end. We should take stances on specific ends that are desireable and undesireable and then work harmoniously with the WMF to achive those stances. Stances on the means taken to get there should be specific to an actual ongoing mean rather than blanket stances on what presumed means might be. This is likewise for the postive case. AI is not an end in and of itself and enWP should not make resolitions to support the development of AI per se.Czarking0 (talk) 16:05, 20 June 2025 (UTC)[reply]
Statement proposed by Tamzin
At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation, with varying degrees of success. There has never been community consensus for other uses, and even use for translation has been controversial. The English Wikipedia community rejects the use of Wikimedia Foundation or affiliate resources to develop novel avenues of AI technology without first obtaining an affirmative consensus from potentially affected wikis, and asserts the right to control what AI tools are deployed on this wiki.
A "novel avenue" is defined as a use case in which AI is not already used on WMF servers by some stable MediaWiki feature. Affirmative consensus for a novel avenue should be obtained through individual consensuses on each potentially affected wiki, or a global request for comment advertised on all of them.
All wikis should have the option to opt out of being used to develop an AI tool; to disable or decline to enable an AI tool; or, based on credible concerns of facilitating abuse, to compel the destruction of machine-learning data that has been gathered without local consensus.
Any person on the English Wikipedia seeking help in creating a dataset for machine learning should gain local consensus at the village pump for proposals before sending out any mass message or otherwise soliciting data. Those who do not do so may be found in violation of WP:NOTLAB.
The WMF is encouraged to devote more resources to areas that the community has requested support in.
Just to emphasize, the first bullet point is about what gets developed at all; the second is about what we enable. So for instance, the first bullet signals no objection to continued development of AI content translation tools, but that does not mean we are conceding that we must enable any new tools of that nature that get developed. -- Tamzin[cetacean needed] (they|xe|š¤·) 05:05, 29 May 2025 (UTC)[reply]
The bolded text is not going to work. The WMF simply cannot reach out for affirmative consensus to every Wiki when it wants something, for practical issues as much as anything else. There are advantages and disadvantages to development strategies, but we should be careful not to mix the questions of development and deployment (the second part of your bolded statement). Many tools are available subject to community consensus, very few things are pushed onto the community (so few the only recent one that comes to mind is VECTOR2022), and it is to mutual benefit that this distinction is maintained. (I only half-facetiously want to propose some bargain, like the community would approve of investing resources into llms when Visual Editor can use named references and handle more than one personal name convention.) CMD (talk) 06:03, 29 May 2025 (UTC)[reply]
That's why I left the option for a global RfC. Which I'd be fine with conducting on a timeframe closer to enwiki RfCs (usually one month) than many global RfCs (months to years). I don't think it's unreasonable to ask that, before the WMF decides to sink six or seven figures into some new kind of AI tool that may well run against the community's interests, that they ask the community first, "Hey, is this a good idea?" The WMF are quite familiar with how to quickly alert tens to hundreds of wikis to the existence of a global discussion. Furthermore, it's not a new consensus for each tool, just for each area of expansion. -- Tamzin[cetacean needed] (they|xe|š¤·) 06:29, 29 May 2025 (UTC)[reply]
I disagree with speeding things up. I imagine part of the reason those take longer is the need for translation; demanding that the process is sped up seems to be assuming that the result is a foregone conclusion. Stockhausenfan (talk) 12:59, 29 May 2025 (UTC)[reply]
I disagree with a blanket opposition to new AI uses. I also disagree with asserting a right to create needless bureaucracy. If the WMF does something silly, we can complain about that specific something. Toadspike[Talk]07:38, 29 May 2025 (UTC)[reply]
I agree with Toadspike and CMD; I don't think a blanket statement such as this is appropriate, and I think enwiki is only one (albeit the largest) of the communities the WMF serves, and shouldn't try to dictate overall development. There's no reason we shouldn't provide input to the WMF, as threads such as these are already doing, but as Toadspike says, if the WMF does something silly we can deal with it then. Mike Christie (talk - contribs - library) 11:19, 29 May 2025 (UTC)[reply]
A few months ago I obtained an AI generated list of typos on Wikipedia. I went through much of it manually, fixed a bunch of typos, made some suggestions for additional searches for AWB typo fixing, but ignored a whole bunch of AI errors that were either wrong or Americanisations. I don't consider that what I did was contentious, but it obviously stops me from signing Tamzin's statement unless it is amended to accept AI prompted editing where an individual takes responsibility for any actual edits made to Wikipedia. I'm also tempted to point out the difference between large Language Models or artificial unintelligence such as was used to generate my possible typos, which is what the WMF seems to be talking about and actual intelligence. Fifteen years ago at the very start of April 2010, I started a discussion as to how we should respond when artificial intelligence gets intelligent. But clearly the current discussion is about artificial unintelligence rather than artificial intelligence. Ļ¢ereSpielChequers13:21, 29 May 2025 (UTC)[reply]
I already said above that I strongly oppose any statement at all until a global RfC is done, but if that doesn't gain consensus, I'll also add that I oppose this specific statement as well. The first part of the statement seems weird to me. Why would we oppose the development of novel avenues of AI technology? They are novel, so by definition we don't know what they do or how they work. The statement should at the very least be amended to replace AI with LLM, and get rid of the "novel avenues" comment. Something like "The English Wikipedia community rejects the use of Wikimedia Foundation or affiliate resources to develop large language models or tools that use them". I'm currently neutral on whether I'd support such an amended statement (if it were discussed in a global RfC), but the statement as it currently stands is a non-starter. Stockhausenfan (talk) 13:34, 29 May 2025 (UTC)[reply]
Someone who knows more about the technology may be able to formulate a better statement that clarifies that it's not limited to text but also e.g. image models. But AI is such a broad, poorly-defined term that the way the statement is phrased currently makes it seem unnecessarily Luddite ("English Wikipedia opposes the development of novel forms of technology that may automate tasks that previously needed human input"). For example, a tool that checks whether chess game transcripts on Wikipedia contain errors could be interpreted as a "novel avenue of AI" that WMF cannot develop, even when it does not use any kind of LLM. Stockhausenfan (talk) 13:43, 29 May 2025 (UTC)[reply]
I think the point is that there is enough stuff that has been requested for a long time that isn't yet done, so spending resources on novel uses for AI isn't what those supporting this statement would like to see. ScottishFinnishRadish (talk) 13:58, 29 May 2025 (UTC)[reply]
The issue I have is just that I think we need to be specific about what "AI" is before we oppose its development. A program that can play perfect tic-tac-toe is popularly referred to as an "AI", despite being something that people would create in an introduction to programming class. So presumably a lot of tools that already exist on Wikipedia are "even more AI" than a tic-tac-toe bot. Stockhausenfan (talk) 14:07, 29 May 2025 (UTC)[reply]
Most of the controversial uses of AI have been generative - which for me includes translation because it's generating new text - and the less controversial uses has been pretty much everything else. So that's the first distinction I think such a statement should draw. Secondly, I agree that consultations on every project isn't practical and that a global consultation won't be representative. So I would suggest the ask be something about enabling projects to opt-out of projects and that tools shouldn't be developed that don't allow that opt-out. So, for instance, the language tool discussed above would have to be done in a way that a user inputs a page from a project and if that project has opted out the tool says "sorry I can't help you". Best, Barkeep49 (talk) 14:35, 29 May 2025 (UTC)[reply]
I'm toying with similar ideas in my head, about what guidelines we could request. I would add ensuring that projects remain add-ons to the core software, that developers should be aware of existing community decisions on different uses of novel AI tools, and perhaps a step further to ensure that individual projects/communities need to opt-in. Wikipedia:Content translation tool may serve as a useful learning experience, I know that there has already been one AI tool developed to improve translations in a way that also translates appropriate wikicode. CMD (talk) 15:18, 29 May 2025 (UTC)[reply]
Agree that the existing approach of projects opting out of WMF-built tools works better than having the WMF seek consensus from each wiki or run an enwiki-biased global RFC. Telling the WMF to destroy training sets created without local consensus, such as the Wikipedia Kaggle Dataset, seems wrong because our concern should be whether a given feature is beneficial, not the mode of its creation. ViridianPenguinš§ (š¬) 21:13, 29 May 2025 (UTC)[reply]
In replacing the annual WP:Community Wishlist Survey with the constant meta:Community Wishlist, we were told that wish popularity would no longer be gauged because of the WMF's misunderstanding of WP:NOTVOTE, only for this month's update to tell us that it is working to bring back a mechanism to support individual wishes. This incompetent overhaul has left us without a dedicated time for brainstorming change, allowing the WMF to substitute its ideas for our own. Contrary to Sohom's reply implying that Tone Check was sought by the community, the VPR and Community Wishlist posts that prompted Edit Check were about warning against wikilinks to disambiguation pages and grammar errors, and the 2023/'24 Wikimania presentations were about warnings to include references when adding prose. Based on mounting frustration with the new Community Wishlist, the way forward in realigning the WMF's priorities seems to be reviving annual Community Wishlist Surveys, rather than this poorly attended replacement that replicates Phabricator's always-open ticket log. ViridianPenguinš§ (š¬) 21:13, 29 May 2025 (UTC)[reply]
Appreciate the clarification because that reply appeared in a chain of CaptainEek and Tactica criticizing Tone Check as out of touch, not Edit Check in general. Thanks for your technical insight across a multitude of replies here! ViridianPenguinš§ (š¬) 21:38, 29 May 2025 (UTC)[reply]
I'm not sure I understand the structure of this RFC, so I'll just put my comments here and hope that's OK. There's a few different things intertwined here, which I'll talk about in turn.
AI is just a tool/technology and it is not going away (see for example this in today's NY Times; 30-day time-limited link). We can bury our heads in the sand, or we can learn all we can about the technology. Personally, I think the latter makes more sense, and the best way to learn about it is to use it, make mistakes, and learn from those mistakes. So of course WMF should be investing in AI.
As others have mentioned, WMF is more than just enwiki. If anything, this conversation should be happening on meta.
Generative AI is clearly not good enough yet for use on enwiki. If we wanted to say "enwiki bans the use of generative AI text on this project", we could do that (and I'd happily endorse it). But other projects may feel differently, for reasons that make a lot of sense to them, so WMF should be supporting their needs.
I'm not sure why affiliates are mentioned here. The idea that the enwiki community could or should have any influence on how WP:WMNYC or any of the other affiliates spends their money is absurd.
Yes this is an important point that I'd overlooked when reading the statement - why are we trying to influence how affiliates spend their money? @Tamzin would you be willing to remove the statement about affiliates from the RfC statement? Stockhausenfan (talk) 23:26, 29 May 2025 (UTC)[reply]
I would appreciate clarity on this as well. Obviously affiliates like WMNYC have never had the ability, or indeed the aspiration, to deploy or impose anything technically on English Wikipedia. Thanks for your thoughts, @Tamzin. Pharos (talk) 20:50, 11 June 2025 (UTC)[reply]
Affiliates have roles in deploying code on WMF servers, most notably WMDE on Wikidata, but also various affiliates on .wikimedia.org and .wikimania.org wikis. More broadly, I don't think that anyone affiliated with the Wikimedia movementāmost of whom get money from the WMF to some degree or anotherāshould be using their money to create AIs that will interact with Wikimedia wikis, without consent from the wikis. -- Tamzin[cetacean needed] (they|xe|š¤·) 23:16, 11 June 2025 (UTC)[reply]
I will say that as Enwiki we reallllly should not regulate what happens on other projects like Wikidata and definitely what happens in affiliates in their internal wikis. (I know for a fact that there are affiliates experimenting with using Gemini AI to help make our abilities to make better first-draft OCR technologies for Wikisource) and we as the enwiki community should not get to dictate what technologies they should use. Sohom (talk) 23:34, 11 June 2025 (UTC)[reply]
I think you're misreading my proposal, Sohom. I never said that enwiki should dictate what happens on other projects. I said that affected wikis should. Enwiki should have a say in a hypothetical WMDE project that would deploy AI on Wikidata in a way that affects enwiki, but shouldn't have a say in one that wouldn't affect us. -- Tamzin[cetacean needed] (they|xe|š¤·) 23:38, 11 June 2025 (UTC)[reply]
I would agree on this point, especially since wikis are interconnected to some extent. Say hypothetically that a feature was deployed on Wikidata to automatically generate item descriptions where it is missing. Since English Wikipedia retrieves many of its short descriptions from Wikidata, we (and other indirectly affected wikis) should have a say in this to some extent. For a more concrete example, there is ToneCheck potentially being used on one wiki to refine prose being written for another. Chaotic Enby (talk Ā· contribs) 23:42, 11 June 2025 (UTC)[reply]
What you're describing is I think appropriate for a limitation of WMDE's action with regard to developing (and deploying) features for Wikidata, on a platform it basically controls. But for the theoretical case of WMNYC using its own resources to develop an AI-adjacent feature for English Wikipedia, we would just be in the same position as if Internet Archive or Mozilla were doing the same - our next step would just be to propose adoption to the English Wikipedia community on this very Village Pump. Pharos (talk) 20:44, 12 June 2025 (UTC)[reply]
AI is a poorly defined conceptānow more than everābut even so using it for the anti-vandalism and translation tools we have now is a major stretch. They both rely on rather simple machine learning models; qualitatively different from generative AI, which is what most people think of nowadays. āāÆJoe (talk) 07:52, 30 May 2025 (UTC)[reply]
Someone who wishes to use Wikipedia articles to create a dataset to train an AI is free to do so, and does not require any special authorization. That's what it means to be published under a free license. Cambalachero (talk) 04:46, 1 June 2025 (UTC)[reply]
@Tamzin, I'm a little concerned about The English Wikipedia community rejects the use of Wikimedia Foundation or affiliate resources to develop novel avenues of AI technology. I think it was Roy who first mentioned it, but I don't think we should be preventing affiliates, like local WMF chapters, from pursuing the study of AI if they want to. Though I do sympathize with the sentiment that we generally shouldn't be using generative AI on Wikipedia, there are some cases where AI for other purposes can be useful (as Legoktm mentions above). IMO, we shouldn't be restricting or discouraging affiliates from studying the usage of AI, particularly non-generative AI, if they want to. ā Epicgenius (talk) 20:58, 5 June 2025 (UTC)[reply]
Even if I agreed with the statement, the wording itself is terrible.
As others have said, there's no definition of "AI technology".
The "preclearance" idea for community consent prior to development will kill innovation.
You're telling the WMF they can't even put together a prototype or a proof of concept without a lengthy community consultation on a half-baked idea.
According to Slate, you're a programmer. You should know the waterfall model is terrible. I would literally quit my job if I needed to do a 30-day RfC any time I wanted to start the development process on a new use case.
Your idea that enwiki can opt out of letting our data train AI models goes against the free content pillar.
That allows anyone to create a dataset from Wikipedia articles, content, talk page comments, etc. You agreed to this when you started contributing. This isn't a legal technicality; it's free culture and the idea there should be a community norm of asking for permission before using Wikipedia content is antithetical to our founding principles.
I also disagree because I believe the WMF should keep developing new technology to improve the encyclopedia. Our editor pipeline keeps drying up while the enwiki community dumps on any ideas the WMF has to modernize the website. These two things are correlated, despite common misconceptions. Chess (talk) (please mention me on reply)04:37, 8 June 2025 (UTC)[reply]
Request for comment discussions where only supporting views for proposed statements are gathered used to be more common (for example, the arbitration committee election RfC used to follow this format). They've gone out of favour at least in part because generally people find it easier to weigh consensus support when there are explicit "disagree" statements. isaacl (talk) 03:12, 30 May 2025 (UTC)[reply]
I agree with this Don't want the WMF wasting resources on this year's equivalent to the NFT craze. Remember when everything would be utopian because of blockchain? Simonm223 (talk) 18:37, 29 May 2025 (UTC)[reply]
I would tend to agree, although my motivation for it isn't "AI bad". I see AI developments as new technologies that have the potential for disruption ā positively as well as negatively. Rolling them out on a project as big as Wikipedia without the support of the community will likely exacerbate the negative effects, especially if we are not given time to prepare or adjust to it. I might write a separate statement (or an addendum) that emphasizes that it is not a reactionary "anti-AI movement", but one based on safety and alignment with our ideals as an encyclopedia. Chaotic Enby (talk Ā· contribs) 17:07, 30 May 2025 (UTC)[reply]
I agree with you on the AI alignment, but as written, Tamzin's proposal prohibits the WMF (and it's affiliates) from even trying to develop (as opposed to deploy or train) any kind of AI technology. Adopting this proposal effectively means that any WMF manager or engineer (or affiliate) planning to use AI for anything (and let me remind you that AI in this context can end up literally being a dumb random forest classifier) will need to first ask for consensus from multiple communities before being able to implement their solution. This kind of bureaucracy will effectively gut any ability for WMF to build any kind of AI technology, good or bad making safety and alignment a moot discussion to have. Sohom (talk) 15:57, 31 May 2025 (UTC)[reply]
I generally agree, although the references to AI are unnecessary. This should apply to any new technology. MER-C10:27, 31 May 2025 (UTC)[reply]
We're both been around long enough to recall the fiasco of (say) the Visual Editor rollout, Flow, and other (formerly, in some cases) unfit for purpose WMF software. AI is only another app. What I am seeing is just another manifestation of the same old problems - some product manager gets something built thinking they know the community's problems better than the community does, when they don't. MER-C17:46, 31 May 2025 (UTC)[reply]
I have noted my issues with this statement above, but Wikipedia:Village_pump (technical)#Simple summaries: editor survey and 2-week mobile study makes it very clear that a strong statement is needed. It is hard to not be blunt, but mediawikiwiki:Reading/Web/Content Discovery Experiments/Simple Article Summaries should not be anywhere near the phase it is at. The summary they did all their testing with is quite bad, and it shouldn't have even reached the testing phase. The pushing ahead, including planning a two-week live trial for 10% of mobile readers on the basis of what is shown so far, is cause for alarm. Therefore, I am not going to let the perfect statement be the enemy of the firm and clear one here. I encourage others who were initially unsure or opposed reconsider in light of the new developments. CMD (talk) 02:03, 4 June 2025 (UTC)[reply]
Any closer may consider this to also serve as a support for any derivatives of Tamzin's statement generated below. It would not be productive to figure out which (including this one) I personally have the fewest nitpicks with. I remain in support of this proposal as well. CMD (talk) 10:45, 9 June 2025 (UTC)[reply]
Strong Support. There is a profound need for the community to set some limits and develop a mechanism for review of AI-features before (indeed, well before) they begin development and deployment. This is a genie that we will find extremely difficult to put back in the bottle if we do not act with restraint and careful consideration from the outset. Our content has a vast reach, and is replicated throughout the internet in ways we typically cannot claw back after it enters that flow of information. We should not take the primacy of our position in the online eocystem for general information, built upon the good name of the work of our volunteers over decades lightly. Nor underestimate the degree of harm from misinformation that may arise from hastily developed AI "enhancements" to our processes and technical infrastructure. Tamzin's proposed statements of general interest and concern are well-considered and reasonable, and a fair roadmap to construct our broader policies in this area--which will by necessity need to evolve substantially and quickly from here--around. SnowRise let's rap21:37, 4 June 2025 (UTC)[reply]
Support. Support even more the more I look into how this has actually been done and how sloppy (no pun intended) the execution has been. Gnomingstuff (talk) 23:39, 7 June 2025 (UTC)[reply]
Support. It is abundantly clear that the WMF is hopelessly out of touch with the needs of editing communities, and in particular has entirely failed to take note of serious concerns raised in multiple places regarding the destructive effects of the use (well-intentioned or otherwise) of AI/LLM technology in the Wikipedia context. The last thing we need is more of the same, from the WMF. AndyTheGrump (talk) 08:50, 8 June 2025 (UTC)[reply]
Support - We need to hit the brakes hard here. Iād be in favor of pausing the research and development of all AI-related work at the WMF, much less deployment. My thanks to Tamzin for the work on this issue. Jusdafax (talk) 01:56, 10 June 2025 (UTC)[reply]
@Jusdafax, Stopping all AI-related work risks leaving our anti-vandalism infrastructure unmaintained (which historically have relied on old ORES models and are in the process of being modernized through the introduction of new Revert-risk models). I would be vehemently against us shooting ourselves in the foot here. Sohom (talk) 02:14, 10 June 2025 (UTC)[reply]
I have a bit of experience with reverting vandals over the past 15+ years. You want to get a handle on that particular problem, you change the rules regarding IP editing, which is where in my experience we Wikipedians are āshooting ourselves in the foot.ā Iām of the opinion that the WMF has lost the trust of many rank-and-file editors over the years, and I speak as someone who was a volunteer in the San Francisco WMF offices in the early days and was a witness to what I will charitably term ābureaucratic bloat.ā AI is a huge unknownā¦ in my view. Jusdafax (talk) 02:59, 10 June 2025 (UTC)[reply]
The English Wikipedia community rejects the use of Wikimedia Foundation resources to develop novel avenues of generative AI technology without first obtaining an affirmative consensus from potentially affected wikis, and asserts the right to control what generative AI tools are deployed on this wiki.
Discussion of Stockhausenfan's proposed statement
I've already made it clear that I oppose making any statement at this stage, but I've made two changes to the original statement to fix what I found to be the two most concerning aspects - I clarified that it's specifically generative AI that is under discussion, and removed the reference to affiliates. Stockhausenfan (talk) 23:39, 29 May 2025 (UTC)[reply]
I'm not sure a statement is warranted here, but even if we must, this version is not it. As it currently reads, the statement explicitly forbids Wikimedia Enterprise from working with AI companies without explicit consensus on enwiki (who would just start scraping Wikipedia increasing the load on our servers and causing more outages) or the existence of initiatives like the Wikimedia Kaggle dataset (which was also created to lessen the load from AI scrapers). If we do need to make a statement, it should be something more direct like, The English Wikipedia asks the Wikimedia Foundation (and it's affiliates) to seek community consensus before developing (or deploying) editor or reader facing features that make use of generative AI technology.Sohom (talk) 01:56, 30 May 2025 (UTC)[reply]
I supported the Tamzin version above but I think any statement to pump the brakes on generative AI summaries or the like is better than no statement. Andreš03:56, 4 June 2025 (UTC)[reply]
The English Wikipedia understands there are both potential benefits and harms that can come from the use of AI, especially generative AI, on or for the encyclopedia. We also understand that the implementation of any form of AI on any WMF project should be supported by the local community, which requires they be informed about the proposed use and have an opportunity to provide feedback during all stages of development.
Therefore, we request the WMF immediately provide information on any project they are currently undertaking or considering that relates to AI that is being planned related to AI. For clarity, "project" includes any study, investigation, development process, trial, model training, or any other similar activity that relates to AI and the WMF wikis, even if not explicitly related to or proposed to impact the English Wikipedia. Following this initial disclosure, we request the WMF to make a similar disclosure as soon as reasonably possible after any new project is initiated, approved, or otherwise begun, or any time there is any significant change in the status of a project, including but not limited to if it is cancelled, being deployed on any WMF project, being tested on any WMF project, or similar.
We request that the notification to us be provided on the WMF Village Pump on the English Wikipedia - and we would encourage the WMF consider providing such notifications to other projects as well, as feasible. The information that we request to be included in the notification is a clear, short description of the project, as well as the reasons for the project, goals of the project, current status of the project, and proposed timeline for the project. A link to more information (such as on Meta Wiki or another place) is appreciated but we request the information above (and any other information relevant) be provided directly in the notification itself.
These notifications will ensure that the English Wikipedia's users are kept informed of all updates to any project relating to AI, and will give us a way to provide feedback in a central place without having to monitor other websites (such as Meta Wiki) to try and find out about projects and provide feedback. We encourage the WMF to monitor the responses to any notification requested above and to treat it as no different than feedback provided through any other means on any such project.
TLDR: Pretty pretty please inform us directly (not just on Meta Wiki or somewhere) of any ongoing/new projects and any significant developments on them, and allow us to discuss them and provide feedback here, so we don't have to go hunting for them or discover them elsewhere.
Discussion of berchanhimez's proposed statement
I don't even know myself if I can support this, but I'm posting it here so it can be wordsmithed. I am still of the mind that no blanket statement is necessary/warranted, but if one is to be adopted, I would prefer it to be nothing more than this sort of a collaboration. Anyone can feel free to edit this statement to make corrections to wording, flow, etc. or add to it if they feel it will make it better.I'm putting this out there because I've been kind of thinking about this all day, and I feel that it may be better to have this sort of a request out there as supported by a large portion of the community... rather than just making no statements at all. Obviously we can't enforce this sort of a request on the WMF, but it would send a strong statement that at least some in the community are not happy with having to hunt down projects/grants/etc. to even find out that they exist. I'm not yet directly supporting this statement as I'd like to see how it evolves before I decide whether I support making any sort of statement at all. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!00:22, 30 May 2025 (UTC)[reply]
This is already the status quo (kinda-sorta). The concerns regarding Tone Check were raised when the first prototype of the feature was proposed for feedback. Typically, whenever WMF rolls out a new feature, they start of by announcing prototypes, asking for community feedback for prototypes, before announcing the feature in tech news, rolling out of the feature for beta testing on smaller wikis, scaling up sizes before starting a discussion on enwiki to enable said feature. This has been the standard operating procedure for any big feature since I've been around.
I will also note that specifically for this year, the WMF did ask for feedback on both it's AI strategy as well as some AI enabled features (which included Tone Check) from the Product and technology Advisory Council during it's first retreat. There is also a separate conversation to be had about the fact that on enwiki there isn't a good WMF noticeboard outside of this page, which does not have the best history in terms of civility towards WMF staff (see the edit notice), which leads to WMF folks posting in other places (like on WT:NPR or similarly more focused venues) over here.
Also, it does need a bit of knowledge of navigating Wikimedia's technical spaces, but all development at the WMF (minus WMF's wordpress instance and Wikimedia Enterprise) happens on eithier Gerrit/Gitlab or Phabricator which are publicly accessible to every user (although, I do concede/agree that they are not the most navigable for the average user). Sohom (talk) 01:19, 30 May 2025 (UTC)[reply]
I tend to agree, but I will say that this makes the request that they inform us before developing AI prototypes in the future, as one change. Perhaps a new page could be made as a forum to use rather than this page, if the concern is civility towards WMF staffers. But I think perhaps much earlier and ongoing interaction directly with the community could stop some of the concerns others have about their approach. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!01:28, 30 May 2025 (UTC)[reply]
I would definitely support the creation of such a forum where WMF staffers can ask for feedback on ideas from English Wikipedians (if there is community appetite). For a start, maybe we could re-purpose WP:IANB ? (which will typically have more technically minded folks who are also familiar with community norms and expectations). Sohom (talk) 01:38, 30 May 2025 (UTC)[reply]
I guess my goal with this sort of a statement is to get them to not only engage with technically minded folks. It's clear from this discussion and the prior one about the Tone Check that many users who aren't technically minded have strong opinions on this sort of thing. So the goal is to get the WMF to, for lack of a better way to say it, "dumb it down" to a level that the community as a whole can understand and engage with - without having to hunt information down or try to decipher it. I debated whether to include something about the level of detail/terms used/etc. but I ended up not to - maybe adding something like "the notifications should be in a manner in which a general English Wikipedia user can understand and engage with, even one without technical knowledge" or similar? -bÉ:Ź³kÉnhÉŖmez | me | talk to me!01:43, 30 May 2025 (UTC)[reply]
I see where you are coming from but there is also a bit of nuance here. Projects like (say) the Wikimedia Kaggle dataset or the newer revert-risk models while AI adjacent do not (and should not) require community consensus to go forward with (Kaggle does not affect the community and Revert risk models are just a technical change migrating to a new infrastructure in the context of English Wikipedia). In my head the way this would work would be for interface-administrators to act as a filter for things to escalate to the community (for example, on hearing the idea for Wikimedia Kaggle dataset interface-administrators can eithier not respond at all or affirm that it looks good, whereas for the ToneCheck idea, a interface-administrator might say "hey, you might want to post on VPWMF or VPP about this?") Sohom (talk) 02:58, 30 May 2025 (UTC)[reply]
I don't think that everything should necessarily require community consensus. But involving the community more clearly in what they're doing early in the process would enable people to ask questions and try to understand why it is a good idea. It's not necessarily that they are asking for approval - but just explaining it to the community before they learn out about it in another way.The reason I don't think having a group of people "gatekeep" whether the community learns or not is that it's really no different than it is now - tech-savvy people who know where to look learn about things get to know about them and comment about them, and others feel like they aren't being involved early. There's still two whole threads on this page that, to sum it up in how I see it, were basically "why didn't we know about this, we need to know about this, etc". And that's what I'm trying to maybe help prevent with this idea. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!03:07, 30 May 2025 (UTC)[reply]
I don't have a intention of introducing gatekeeping, but from my experience working on features alongside WMF (and other volunteer folks) involving the exact right people is a very hard problem that can't be solved by asking the WMF to throw every single new feature development at the community. If we do end up doing that we will end up with a case of banner fatique and start ignoring the actually important messages. I've personally had cases where despite multiple community consultation rounds, I ended up receiving feedback on the eve of deployment. There are also other cases where despite early negative community feedback we decided to go forward with certain technical changes since it helped significantly reduce technical debt in other areas. (the NewPagesFeed codex migration for example).
TLDR, I'm not sure what the answer is here, but I'm pretty certain that "just tell us on a designated page" isn't going to be a good one. Sohom (talk) 04:13, 30 May 2025 (UTC)[reply]
Yeah, I don't think it's a full answer either, but it would at least stop claims of "omg the WMF is doing this AI development and trying to hide it from us". -bÉ:Ź³kÉnhÉŖmez | me | talk to me!05:10, 30 May 2025 (UTC)[reply]
I would definitely support the creation of such a forum where WMF staffers can ask for feedback on ideas from English Wikipedians (if there is community appetite). This is the spot for that, in my opinion. Creating a second VPWMF, or picking another board besides VPWMF and VPM, doesn't seem like the ideal way to organize things. āNovem Linguae (talk) 15:20, 30 May 2025 (UTC)[reply]
Fair, and agreed. However, that is based on the assumption that we as a community however need to do better to moderate this page. In it's current state, it is nowhere near a lightweight feedback forum (if that was the original intention). Sohom (talk) 15:53, 30 May 2025 (UTC)[reply]
I agree with Barkeep49 that I don't think it's practical to ask the WMF to engage in consultations with all Wikimedia communities, on each community web site, for every project and initiative. In my opinion, the WMF is best situated to invest in research, whether on its own or in partnership with universities, on science and technology that can affect the goals of the Wikimedia web sites. I think it's good for it to be knowledgeable about AI research, so it can develop guidance on the advantages, disadvantages, and associated risks and uncertainties. I don't know if I would personally find any blanket statement suitable at the moment. isaacl (talk) 03:05, 30 May 2025 (UTC)[reply]
Is there a way to make this sound less like a "consultation" than just a "please keep us informed of things as they happen rather than letting people find out on their own"? Perhaps removing the part about encouraging them to monitor responses? My goal with this sort of a statement is for it to be the "bare minimum" that would prevent the two threads on this page right now from happening again where there were at least significant minorities mad that they found out through this page rather than from the WMF themselves. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!03:10, 30 May 2025 (UTC)[reply]
In an ideal world, there could be community liaisons for each community to publicize the WMF's work and help interested editors to participate in the right forums. A key challenge is that it's a hard task to do well, with so many WMF initiatives and projects that would need to be covered, and so many communities speaking different languages. So a lot of staffers would be needed, and the end efficacy is a big unknown: we know from experience that posting messages in all the usual targeted venues still fails to reach editors who express their discontent later. The crowd-sourcing approach is for each community to have interested editors stay in touch with what the WMF is doing and relay that info to the community. I appreciate this requires enough interested editors, which is particularly a problem with smaller communities, and it requires significant volunteer time.
Of course, any projects affecting the editor experience will benefit from regular editor feedback, and I agree that the WMF should be allocating enough time and resources for this in its project plans. Most recently, WMF developers seem to be aware of this need and engaging the communities. isaacl (talk) 04:52, 30 May 2025 (UTC)[reply]
I'm not saying this to be "enwp elitist" or anything like that, but given that a majority of the WMF employees that would be involved in potentially sending these notifications to us, and given that enwp is one of the most active projects, I don't think it's really too much to ask. That was my intent in including "other projects as well, as feasible". For example, if the person making the announcement speaks another language fluently, then they may consider giving a notification to any projects in that language too. I think, like you say, the WMF has been trying to engage more - this just formalizes our request that we be engaged "early and often", or at least kept updated even if it's not a full back-and-forth style of engagement. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!05:13, 30 May 2025 (UTC)[reply]
To take an example, the WMF did not commit to posting notifications on the WMF village pump, because there is typically another page that is a better fit for a targeted subset of the community who is likely to be interested, and it didn't want to fork the discussion across multiple pages. I agree with Sohom Datta: it's not clear to me that letting loose a firehose of information on this village pump page will be helpful. isaacl (talk) 05:38, 30 May 2025 (UTC)[reply]
Maybe a specific page for WMF notifications of AI developments then? People interested can go to that page/watchlist it, and then those people could start a discussion here? I guess my goal is to just prevent the "ooh look the WMF is doing AI in secret and not telling us" that was at least a portion of the two discussions that are still above on this page. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!05:46, 30 May 2025 (UTC)[reply]
This is a prime example of what my statement is intended to counter. A tool being developed with, from what I can see, only one prior notification to enwp (that got zero replies there), followed by a scheduled test that we're being informed about barely 2 weeks in advance (at most) and without any opportunity for the editing community to test it in advance and provide our feedback. Thinking about it more, perhaps a new noticeboard (such as WP:Village pump (AI)) would be best for the WMF to provide updates more regularly - but it's clear to me more frequent updates/engagement would be something a lot of users would like. For full disclosure, I did link to my comment from that thread so others may be able to see this and help with it. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!22:58, 3 June 2025 (UTC)[reply]
I don't think a new noticeboard is needed; we already have Wikipedia:Village pump (WMF) which says ... Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the Foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation. Some1 (talk) 23:54, 3 June 2025 (UTC)[reply]
@Berchanhimez See the top of the RFC, we were going back and forth on the design of the exact tool. Also, nothing has been implemented yet, this is just them asking for feedback on their designs. Sohom (talk) 00:02, 4 June 2025 (UTC)[reply]
in the next two weeks we will be launching: ... A two-week experiment on the mobile website. It's being actively implemented to test, according to the notification there. And to User:Some1, this page would work but there were some concerns above regarding whether this is a good place for it if these notifications would be frequent. Having it on a separate page would keep it separate from "clutter" (such as the whole ANI v WMF debacle) so people can watch that specific page if they want to, and also could have more "strict" moderation of comments to ensure they're on topic and constructive and not flaming the WMF. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!00:08, 4 June 2025 (UTC)[reply]
@Berchanhimez As @OVasileva (WMF) mentioned above this is not the final product. They are not deploying this in it's current state after the experiment. The primary reason to do this is to test and gather feedback the reader facing components. I agree with you that deploying an experiment on the live website was hasty and maybe having editor feedback on the mockups would have been a better approach, but "testing" is not "we will deploy this tommorow". Sohom (talk) 00:34, 4 June 2025 (UTC)[reply]
There's a problem testing things without prior consultation too. That's what my proposal here is intended to prevent - is a whole product being developed with only people who know where to look and look frequently knowing it's been developed and even going into testing without any input from the vast majority of users on enwp. -bÉ:Ź³kÉnhÉŖmez | me | talk to me!00:48, 4 June 2025 (UTC)[reply]
@Sohom Datta, "testing" may as well be "deployment" from the perspective of the readers who see the test. Once "Wikipedia is using AI to summarize articles" gets mentioned on social media, we're not ever, ever going to be able to get that stain out. -- asilvering (talk) 03:47, 4 June 2025 (UTC)[reply]
Users who agree with berchanhimez's proposed statement
Statement proposed by Chaotic Enby
At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation, with varying degrees of success. There has never been community consensus for other uses, and even use for translation has been controversial. The English Wikipedia community rejects the use of Wikimedia Foundation or affiliate resources to implement novel avenues of AI technology, or use user-generated data to develop novel avenues, without first obtaining an affirmative consensus from potentially affected wikis, and asserts the right to control what AI tools are deployed on this wiki.
A "novel avenue" is defined as a use case in which AI is not, as of this statement, used on WMF servers by some stable MediaWiki feature. Affirmative consensus for a novel avenue should be obtained through individual consensuses on each potentially affected wiki.
All wikis should have the option to enable an AI tool, or to provide their data to develop an AI tool, and both of these processes should be opt-in rather than opt-out.
Any wiki providing their data for AI tool development should, based on credible concerns of facilitating abuse, have the option to compel the destruction of machine-learning data that has been gathered without local consensus.
Any person on the English Wikipedia seeking help in creating a dataset for machine learning should gain local consensus at the village pump for proposals before sending out any mass message or otherwise soliciting data. Those who do not do so may be found in violation of WP:NOTLAB.
The WMF is encouraged to devote more resources to areas that the community has requested support in.
The rejection of novel avenues being implemented without community consensus should not be interpreted as a rejection of AI as a technology. Instead, it stems from a safety and AI alignment issue, and the community asserts its right to decide whether new technologies are aligned with our goals as an encyclopedia.
Besides the aforementioned encouragement, this is also not a limitation on the WMF's ability to work on developing novel avenues. However, the community has the final say on whether these avenues are implemented, and on any testing that should take place beforehand.
This is a variation of Tamzin's statement, asserting the need for consensus on affected wikis to implement novel avenues or aid in their development (making the latter opt-in rather than opt-out), but not requiring a global consensus to begin the development of these novel avenues. It also clarifies the position of the problem as an AI alignment question rather than a pro/anti-AI debate. Chaotic Enby (talk Ā· contribs) 18:16, 30 May 2025 (UTC)[reply]
I think some additional refinement is needed if you're trying to distinguish between "[not limiting] the WMF's ability to work on developing novel avenues" and "[rejecting] the use of Wikimedia Foundation or affiliate resources to implement novel avenues of AI technology, or use user-generated data to develop novel avenues, without first obtaining an affirmative consensus from potentially affected wikis..." Development is part of the process of implementing new things, whether they're proofs-of-concept, prototypes, deployable features, or other project outcomes. isaacl (talk) 22:21, 30 May 2025 (UTC)[reply]
Good point. What I'm meaning to say is that they should be able to work on the earlier parts of the development that do not necessitate direct testing on wikis, but not do the latter without affirmative consent. Chaotic Enby (talk Ā· contribs) 22:39, 30 May 2025 (UTC)[reply]
This would also reject the experiment the foundation did with the ChatGPT plug-in of which I'm not aware of any onwiki criticism of. Beyond which my concerns above would also apply here. Best, Barkeep49 (talk) 23:01, 30 May 2025 (UTC)[reply]
Users who agree with Chaotic Enby's proposed statement
Statement proposed by Barkeep49
The English Wikipedia community is monitoring news about Artificial Intelligence and knows that the Wikimedia Foundation has been researching its use on Wikimedia projects. Our community would like to remind the WMF about how AI is used and seen on the project. At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation with varying degrees of success. There has never been community consensus for other uses, and even use for translation has been controversial. As such, we request that when the foundation develops tools intended to help with core project activities, they should be developed in a way that enables projects to opt-in to their use, perhaps through Community Configuration, and where that is not feasible, that it be possible for a project to opt-out of tool deployment on that project. The Foundation should also keep transparency in mind as it works on AI, both in communication with projects and by enabling auditing of its uses, especially on projects (e.g., use of a tool having a tag applied automatically).
Discussion of Barkeep49's proposed statement
I'm really not precious about this and so would likely be open to tweaking most of this. It also seems like the very real concerns about any message (something I'm rather sympathetic to) that all of these specific proposals will be more for ourselves than the WMF. Best, Barkeep49 (talk) 23:14, 30 May 2025 (UTC)[reply]
I agree with Sohom Datta and you that I'm not sure a blanket statement is helpful on what the WMF already aspires to do generally for new features. I appreciate that the WMF has not always been successful. I feel, though that any issues are best addressed by continuing to provide ongoing feedback to improve the collaborative process, rather than wordsmithing a proclamation of some sorts. isaacl (talk) 17:31, 31 May 2025 (UTC)[reply]
I had that in mind when writing that section and think WMF would go towards it naturally. I also didn't want us to be proscriptive on process. But adding it in a similar way to the tags suggested by Roy makes sense. Best, Barkeep49 (talk) 02:56, 31 May 2025 (UTC)[reply]
If we aim to "remind the WMF about how AI is used and seen on the project", we should include recent positions that relate to the recent developments on the llm front, such as the WP:AIIB RfC. CMD (talk) 13:24, 31 May 2025 (UTC)[reply]
I think this comes closest to covering - or could be tweaked to include - something that's permeated these discussions but isn't quite explicit in the various statements, roughly this community is highly averse to / rejects any use of AI for content generation (including generating summaries and guiding users to spam more effectively). Our attitude to e.g. admin or RPP tools and filtering seems more mixed, but we largely see content as editors' remit, not developers'. NebY (talk) 18:42, 10 June 2025 (UTC)[reply]
Users who agree with Barkeep49's proposed statement
I think the wording today (31 May) strikes a good enough balance in terms of what we want to actually say v/s stifling the ability of WMF to build new AI tooling. I would ideally not see a statement at all, since in my opinion, this is just restating what is already the recommended standard operating procedure at the WMF (from my understanding), but if we must, this is what we should be saying. Sohom (talk) 16:16, 31 May 2025 (UTC)[reply]
I agree that I don't like restating existing best practice, particularly in the context of one specific domain. It leads to the impression that the community is less concerned about following best practice in other domains. isaacl (talk) 17:35, 31 May 2025 (UTC)[reply]
While I'm still skeptical of any statement, this seems to me to be clearly the least bad one if we have to make one. Loki (talk) 06:32, 1 June 2025 (UTC)[reply]
This seems to me to be the best of the proposed statements so far. As above, I like that it maintains a balanced perspective, not pre-emptively ruling out such developments in tooling while also centring community consent and consensus in the implementation. --Grnrchst (talk) 17:45, 2 June 2025 (UTC)[reply]
This would be an appropriate statement for the community to make. Other proposals seem to set hard lines against development of AI products. I am not sure that is desirable, as development and management teams need to have some freedom to develop further software products. Other Wikimedia communities may have greater need or appetite for AI products, and any limit we impose need to apply when products are being deployed and where deployment affects our project. Total bans at this stage would just be a step too far. The danger here is thinking that something must be done; banning AI at the WMF is something; therefore we must do that. A softer, open-minded approach is better here, and would not even require conceding to the deployment of more AI products. Arcticocean ā 10:21, 14 June 2025 (UTC)[reply]
Statement proposed by Curbon7
[Prior paragraphs of whichever variation go here]
The English Wikipedia community is also concerned about the environmental impacts generative AI tools would cause. For instance, xAI (Grok) has recently been accused of emitting large quantities of "toxic and carcinogenic pollution" in the city of Memphis, Tennessee, while this 2025 paper provides data supporting the claim that LLM models consume a huge amount of water for cooling. In keeping with the resolution passed on 24 February 2017 ā WMF:Resolution:Environmental Impact ā the English Wikipedia community demands assurances that the WMF's development of AI tools will not significantly impact the environment, and requests annual update reports about this.
Discussion of Curbon7's proposed statement
This is not meant as a standalone proposal, but as an addendum to whichever proposal (if any) achieve consensus. The WMF passed an environmental resolution ā WMF:Resolution:Environmental Impact ā on 24 February 2017, but with the environmental impacts of AI-use being well-known, these two goals seem to be at odds. Curbon7 (talk) 00:46, 31 May 2025 (UTC)[reply]
Thank you, I had not seen wikitech:Machine Learning/AMD GPU prior. The output of just 17 GPUs is indeed practically nothing, However, how far is this number expected to grow, as some of the plans the WMF has laid out for AI seem pretty aspirational? Obviously 100,000 is not going to happen, but could it go into the high hundreds? Beyond a thousand? And from there, where do we start seeing effects beyond rounding errors? I am not sure as I do not purport to be an expert in this area, but an affirmation from the Foundation that they intend to adhere to their prior environmental resolution in this regard would be decent. Curbon7 (talk) 19:36, 31 May 2025 (UTC)[reply]
@Curbon7, @CAlbon (WMF) Would be the best positioned to answer your questions regarding the projected growth of WMF GPU usage.
However, to my understanding is that even with WMF's AI plans, a majority of the models will feature simpler and older model designs that do not require anywhere close to the processing power of the frontier models that have sparked criticism about environmental concerns.
Additionally another key reason why the WMF can keep running AI inference on such limited hardware is because most of the features where AI is used on Wikimedia wikis don't require immediate feedback (unlike, say, ChatGPT), allowing for slower hardware and more efficient inference logic (where one inference is generated and is subsequently cached for long periods of time). So while usage may grow modestly as a result of the new AI strategy, it's unlikely (imo) to scale to levels where the environmental impact becomes comparable to large-scale AI operations. Sohom (talk) 20:07, 31 May 2025 (UTC)[reply]
I can! We are planning on purchasing 16 AMD GPU per year for the next three years. We just ordered 32 GPUs, which is the budget for two fiscal years (this fiscal year and next fiscal year).
To Sohom's point, we aren't and will never be a computational powerhouse. Instead, what we are actually really good at is being super efficient with limited resources (e.g. pre-caching predictions [like Sohom mentioned], using really small models, using CPUs instead of GPUs). CAlbon (WMF) (talk) 18:54, 1 June 2025 (UTC)[reply]
Just for the sake of those non-nerds trying to follow along, a GPU is a Graphics Processing Unit. This is a specialized type of CPU which was originally designed for quickly rendering the high resolution graphics needed by video games. They are very good at doing the very specific but highly repetitive types of calculations needed, but not so good at more general problems. Kind of like how some people are capable of doing amazing math calculations in their heads but struggle with everyday tasks. It turns out that other real-world problems like Bitcoin mining and AI model generation do the same kind repetitive computations. At one point, people were buying off-the-shelf gaming consoles to build supercomputers because they were being sold at a loss to spur game sales and were the cheapest way to get that kind of processing power. In a remarkable example of symbiotic evolution, the hardware manufacturers started packaging these types of chips into systems that could be installed in data centers, and the software folks have been hard at work developing algorithms and application frameworks to better take advantage of this kind of hardware. RoySmith(talk)19:24, 1 June 2025 (UTC)[reply]
That's just the usual anti-AI conspiracy theories. Do AI need water cooling? Yes, of course... just like streaming a film from Netflix, an album from Spotify, playing an online game, or even working in Wikipedia if we get to it. Is there an environmental impact? Of course not. The ammount of water used for cooling is just trivia, which is then taken out of context. The water used to cool a computer is inside a closed system. See Computer cooling for details. --Cambalachero (talk) 19:30, 31 May 2025 (UTC)[reply]
Server cooling is not what I'm an expert in, but I will note that the statement The water used to cool a computer is inside a closed system. is not necessarily always accurate. While most individual computer cooling systems are closed loop, many server farms (for example Microsoft's Azure data centers where ChatGPT's AI workloads are run) do make use of evaporative cooling which consumes water by design. In these systems, water is intentionally evaporated to carry away heat and must be replenished from external sources, so the system is by definition not closed. Sohom (talk) 20:49, 31 May 2025 (UTC)[reply]
Even if that was the case, it still doesn't answer the other part of the argument: how is that any different from just any other use of internet? Cambalachero (talk) 23:12, 31 May 2025 (UTC)[reply]
I don't know why you'd frame AI's environmental impact only in terms of water cooling. AI uses a lot of energy, more than simply delivering content. Generating and delivering that energy has environmental impacts and the heat of employing it does too. NebY (talk) 23:48, 31 May 2025 (UTC)[reply]
and, as said, they apply to all internet, and do not explain this weird finger-pointing to AI as if it was the single one to be blamed. It's like saying that books are evil, because to reach the libraries and bookstores they are distributed by cars fueled by oil, which causes pollution. Cambalachero (talk) 04:09, 1 June 2025 (UTC)[reply]
Was also about to say this, and I disagree with the author's simplistic categorization of data-centers, data-centers are rarely used for a single-category of workload, but rather are used for a variety of workloads not limited to AI inference, web services, data processing etc.
That being said, they apply to all internet, is not entirely correct eithier since most internet services do not require significant computing resources to develop (unlike say frontier models which require significant extra compute time to be trained before they can be deployed). Sohom (talk) 16:01, 1 June 2025 (UTC)[reply]
I've found that "AI is harmful to the environment" is an argument used by those who are already disposed to anti-AI sentiment and are looking for more reasons to oppose it. Otherwise it wouldn't be anywhere near the top of the list of environmental concerns to be concerned about. Thebiguglyalien (talk) šø21:53, 3 June 2025 (UTC)[reply]
The ammount of water used for cooling is just trivia, which is then taken out of context - I keep seeing these claims, but never from an independent source. I trust you have one you can share, Cambalachero? Guettarda (talk) 17:48, 6 June 2025 (UTC)[reply]
The relevant question here is WMF's commit[ment] to seeking ways to reduce the impact of our activities on the environment. Articles are supposed to have lead sections. An LLM summary can never be more useful than a good lead. But even generating that lead once is going to have hundreds or thousands of times the carbon emissions of a human editor.
Using LLMs to summarise articles that lack leads is another issue entirely, but even then there would need to be cost-benefit considerations. A "commit[ment] to seeking ways to reduce the impact of our activities on the environment" doesn't mean "ignore the environmental impact of our actions if we find they have any benefit whatsoever". And how often would these summaries be regenerated? If I make 100 edits to a page, does that mean the summary will be regenerated every time? If so, the impacts would be staggering. If not, then these summaries will be about as useful as the old spoken word articles. Guettarda (talk) 18:06, 6 June 2025 (UTC)[reply]
@Guettarda, With a total capacity of 17 GPUs (see above) I don't think the conversation is "ignore the environmental impact of our actions if we find they have any benefit whatsoever" but rather "even if we do this, our environment impact is negligible compared to the environmental impact of running all of the other non-AI servers". Sohom (talk) 17:05, 7 June 2025 (UTC)[reply]
Sohom Datta: saying even if we do this, our environment impact is negligible compared to the environmental impact of running all of the other non-AI servers is precisely a case of ignore the environmental impact of our actions. And even if it isn't, it's most decidedly not consistent with the idea of seeking ways to reduce the impact of our activities on the environment.
And focusing on the current capacity is misleading. Either they're doing this with absolutely no intention of implementing it (in which case, it's a total waste of money and incredibly poor stewardship of donations) or they're doing it with an eye to implementing it. And if you add Ai summarise to the top of every article on Wikipedia, you're no longer talking about negligible impact - you're talking about something that will increase the environmental impact (and the cost) of running the servers significantly, possibly hundreds of times what it is now. (While still running the risk of being as big a "success" as spoken-word Wikipedia.) Guettarda (talk) 17:32, 7 June 2025 (UTC)[reply]
I'm not sure the folks implementing it had reached that stage of thought here. This was one of the first prototypes of the project. I don't think it was a given that future iterations of the project would use AI. Also, based on the fact that the summaries had a date on them, I would assume that the idea would have been to update the summaries with less frequency than every edit on the page. While I agree that there should have been some conversation about environmental impact, I don't think we had reached that stage yet and even with the expected growth over the next few years I don't think there is a expectation of WMF GPU usage coming anywhere close to the impact of running non-AI workloads on our servers (leave alone the ones used to train frontier models that have cause scrutiny into the environmental effects). Sohom (talk) 17:44, 7 June 2025 (UTC)[reply]
Users who agree with Curbon7's proposed statement
Support: this is an important principle and worth appending to any statement, even although the WMF currently uses negligible amounts of computer resources and intends to keep doing so. It isn't enough that other (hypercapitalistic and ecocial) technological actors are much worse. They are hardly the best basis for an ethical comparison. Arcticocean ā 10:27, 14 June 2025 (UTC)[reply]
Statement proposed by Chess
Keep up the good work!
Discussion of Chess's proposed statement
I wrote this statement because nobody has unambiguously supported the WMF's attempts at integrating AI. I like the idea of autogenerated simple article summaries. Our math and science articles are famously difficult to comprehend. Allowing readers to opt-in to an automatically generated article summary is a great idea. I also like the idea of having community moderation, where we can verify that a given summary is accurate. I want the WMF to keep coming up with interesting ideas and use cases for AI without being restricted by an onerous approvals process, or overly legalistic guidance from the community. Chess (talk) (please mention me on reply)04:51, 8 June 2025 (UTC)[reply]
Users who agree with Chess's proposed statement
Statement proposed by Sohom
At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation, with varying degrees of success. The use of AI for translation has been controversial and the WMF's use of generative AI as a proxy for content in Simple Article Summaries was unanimously rejected by the community. As a result, the English Wikipedia community rejects any attempts by the Wikimedia Foundation to deploy novel avenues of AI technology on the English Wikipedia without first obtaining an affirmative consensus from the community.
Deployment here refers to the feature being enabled in any form onwiki, either through A/B testing, through the normal deployment process, or through integration into Community Configuration. Modifications made to existing extensions and services like the ORES extension or the LiftWing infrastructure as part of new features must be behind disabled-by-default feature flags until affirmative consensus is achieved. Furthermore, irreversible actions, such as database migrations on the live English Wikipedia databases or the public release of production models for these new features, should not proceed until affirmative consensus for the feature has been achieved.
Wikimedia Foundation teams are encouraged to keep the community notified of the progress of features and initiatives through venues like WP:VPWMF and to hold multiple rounds of consultations with affected community members through out the process of the development of the features.
Wikimedia Foundation teams should also keep transparency in mind as it works on AI, both in communication with projects and by enabling auditing of its uses, especially on projects (e.g., use of a tool having a tag applied automatically and open-sourcing and documenting onwiki the output, methodology, metrics, and data used to train the AI models).
In line with my own proposal as it puts a limit on deployment rather than development while still keeping transparency throughout the development process. I wonder if it could be possible to add something about Wikimedia Foundation teams having to clearly inform editors in plain language of what is being worked on (as it can otherwise be "transparent" but hidden at the bottom of a page of corporate jargon). The "multiple rounds of consultations" is a good idea, although I'm afraid it might become a bit too rigid of a system, and continuous feedback on pages like WP:VPWMF could also be considered. Chaotic Enby (talk Ā· contribs) 02:33, 10 June 2025 (UTC)[reply]
Support. This is a good statement of community reservations and expectations, balanced against an effort to make sure that the ultimate guidelines that devolve from this starting point are not overly onerous and do not create undue barriers for useful and less problematic software development and technical backbone support. In other words, it makes no bones about demanding transparency and insisting that nothing goes live in our technical and editorial ecosystems without a serious opportunity to vet (and if necessary, veto) AI software which is at odds with the community's perspective on safe, ethical, and pragmatic practices, while also keeping a path open for much less controversial implementation of AI that does not draft content or otherwise create problematic operational quagmires. SnowRise let's rap11:59, 10 June 2025 (UTC)[reply]
Incidentally, it's worth noting that this proposal resulted from a substantial back-and-forth between a few parties in the Users who oppose any position section above. It's worth reading that dialog to understand the needle that this version of the statement attempts to thread. SnowRise let's rap12:04, 10 June 2025 (UTC)[reply]
This is still a comparatively forceful and straightforward statement. I believe that is appropriate following the unpleasant surprise that precipitated this issue, and the raised eyebrows re apparent level of WMF clue. I would support this. --Elmidae (talk Ā· contribs) 15:34, 10 June 2025 (UTC)[reply]
Collaborative statement workshopping
Following the discussion above, there have been proposals of merging multiple statements together, and this approach would fit nicely into the wiki spirit of building our community statement together. We can take Sohom's statement as a starting point, feel free to edit it as you wish!
At present, AI is integrated into the English Wikipedia in the contexts of antivandalism and content translation, with varying degrees of success. The use of AI for translation has been controversial and the WMF's use of generative AI as a proxy for content in Simple Article Summaries was unanimously rejected by the community. As a result, the English Wikipedia community rejects any attempts by the Wikimedia Foundation to deploy new use cases of AI technology on the English Wikipedia without first obtaining an affirmative consensus from the community.
Deployment here refers to the feature being enabled in any form onwiki, either through A/B testing, through the normal deployment process, or through integration into Community Configuration.
A "new use case" is defined as a use case in which AI is not already used on WMF servers by some stable MediaWiki feature. Modifications made to existing extensions and services like the ORES extension or the LiftWing infrastructure as part of new features must be behind disabled-by-default feature flags until affirmative consensus is achieved. Furthermore, irreversible actions, such as database migrations on the live English Wikipedia databases or the public release of production models for these new features, should not proceed until affirmative consensus for the feature has been achieved.
Wikimedia Foundation teams are encouraged to keep the community notified of the progress of features and initiatives through venues like WP:VPWMF and to hold multiple rounds of consultations with affected community members through out the process of the development of the features.
Wikimedia Foundation teams should also keep transparency in mind as it works on AI, both in communication with projects and by enabling auditing of its uses, especially on projects (e.g., use of a tool having a tag applied automatically and open-sourcing and documenting onwiki the output, methodology, metrics, and data used to train the AI models).
The only big difference I see is that "new uses" might apply to implementing already existing tools in new situations, which might be too wide-ranging for our community proposal. However, "new use cases" could also work while still using plain language. In either case, we could maybe consider borrowing a sentence or two from Tamzin's statement to define more clearly what we mean by that. Chaotic Enby (talk Ā· contribs) 03:40, 11 June 2025 (UTC)[reply]
I would be open to using the term "new use cases" but you are right, we should define what we mean by eithier phrasing Sohom (talk) 03:44, 11 June 2025 (UTC)[reply]
Database migration (or rather schema migration) aren't very reversible at Wikimedia's scale (or atleast would require significant work to undo in certain cases). I think it makes sense to caution folks against doing a lot of hard to undo work before obtaining consensus. Sohom (talk) 18:26, 11 June 2025 (UTC)[reply]
For this proposal to be workable, we need a distinction between "deployment" and "development", possibly with different proposals. The proposal says it only restricts deployment, but there's several lines in it about development. Telling the WMF they cannot even develop an AI feature is counterproductive, because Google/Meta/Microsoft/Apple/etc can develop AI features based on Wikipedia content without any extra permission (due to our licence) and continue to take our readers. We are kneecapping the only organization with a legal mandate to help us.
I will strongly oppose any requirements for ongoing consultations in the development process, because that isn't how software works. I usually build a prototype, demo it to users, get feedback, and iterate from there. Doing lengthy requirements analysis before anything concrete exists has discredited for decades. If I were a WMF developer faced with restrictions on database migrations or training, I would either a) ignore enwiki's statement or b) not develop anything new for enwiki, because we are painful to work with.
I can understand the desire for a community consultation process before widely deploying a feature, though. If something is going to change my workflow I would appreciate a heads up. But that should be a 7-day RfC for a simple A/B test or opt-in feature. Not multiple rounds of consensus. Chess (talk) (please mention me on reply)03:04, 15 June 2025 (UTC)[reply]
I usually build a prototype, demo it to users, get feedback, and iterate from there.Wouldn't that count as the "multiple rounds of consultations" in the proposal? I don't see anywhere that these must start before the first prototype, or include requirement analysis rather than simply sharing updates with the community and asking if they have feedback. Chaotic Enby (talk Ā· contribs) 03:17, 15 June 2025 (UTC)[reply]
The whole point of the proposal is to formalize and provide guidelines for what is already common practise, the language around multiple rounds of consultation is explicitly loose so that it does not require consensus, but rather to encourage feedback and iteration through demos and "test this out on betawiki and give your thoughts" (i.e. the agile model). The proposed recommendations around database migrations (associated with new features) on production wikis are (to my understanding) already established procedures since we consider those operations to be hard to undo. The new recommendation here is for production model training (note, not training models in general, since training test models are fine) should be considered a irreversible action since one of the conversations surrounding ToneCheck is that once such a model is trained and released to the public, engineers cannot "untrain" it. Sohom (talk) 03:53, 15 June 2025 (UTC)[reply]
I think it could be good to clarify that last guideline to explicitly refer to models made available somewhere. It is perfectly possible that engineers may have a production branch they are working on, but not release the model to the public and only show its results on select test cases. In that situation, assuming no model leaks (which could also happen on a test branch), there wouldn't be a ToneCheck-like issue to my understanding. This could be more reassuring as it gives freedom for developers until the actual deployment (on either test or production wikis) while making the actual issue more specific (as test models could also lead to similar issues once released to the public). Chaotic Enby (talk Ā· contribs) 04:06, 15 June 2025 (UTC)[reply]
Yes, that could work! "Public release" could also be a possibility, as publication is usually related to copyright law, although it depends on how much we value precise language vs plain language. Chaotic Enby (talk Ā· contribs) 04:17, 15 June 2025 (UTC)[reply]
The community seems to care a lot more about deploying features than developing features, which is why Simple Article Summaries started getting flak once it was proposed as an opt-in. Both WP:VISUALEDITOR and WP:Media viewer garnered controversy when they were deployed, not when they were developed.
If we're going to go with mandatory "rounds of consultation" (i.e. points where the community can express outrage about an idea), it shouldn't be loose. We should have actual milestones so managers can add community consultations to the project timeline and account for its risk. I think it's unclear to the WMF why their first notification of Simple Article Summaries was uncontroversial[26] and their second notification resulted in unanimous opposition.[27]
One way is a 7-day mini-RfC for key deployment milestones like A/B testing. The project manager can say "we're doing the RfC for the A/B on June 2nd. We need x, y, and z from the team by that date. If we pass that, we can do the RfC for the full deployment in September". That gives the WMF time to plan budgets/hiring/etc for negative community responses that could kill a project. Chess (talk) (please mention me on reply)04:55, 15 June 2025 (UTC)[reply]
The major pain point, the fact that consensus before deployment, even for A/B testing is a must is already codified in the proposal. The headline is that English Wikipedia if this proposal is accepted, enwiki will not accept deployment of new usecases of AI without community consensus. This would already provide the structure you are talking about. The "multiple-rounds of community consultation" cannot really be structured since it differs for every team (and to be honest I don't think it should be enwiki's place to decide what product development lifecycle is followed) and so is left as a "you should probably do this" suggestion of how teams can modify their workflows to avoid failure at the A/B testing phase (by fitting in multiple consultation stages). Sohom (talk) 05:21, 15 June 2025 (UTC)[reply]
@Sohom Datta: There are real people employed to help us onwiki, is my point. They need parental leave, medical leave, and vacation. They have professional reputations and can't be anonymous.
When we publicly[28][29][30] and kill projects at random points in the cycle after the WMF tries to consult us with no response, that hurts. It's going to make them more reluctant to innovate in the future. That's a failure on us that we didn't have a better way to approach the problem.
If we want to mandate that the WMF get affirmative community consensus, we have to come up with a workable consensus process for them to follow. Right now, that's going to default to a 30-day RfC posted here. A 30-day RfC is fine for volunteers, but for actual professionals working full time, it's 1/3rd of a quarter. We need something faster than that. We also need to make it clear to them when they need to run those RfCs.
This is all our job, because we are the customer and we pick the acceptance criteria. We can't punt that off to the WMF. Chess (talk) (please mention me on reply)07:53, 15 June 2025 (UTC)[reply]
Again, I genuinely don't think a series of 30-day RfCs on a fixed schedule is the best way to go at it. That's the whole point of agile development, and why the waterfall model, as you mentioned above, isn't in use anymore. The key is to have a live communication between the "customer" (us) and the developers, and to adapt accordingly. Chaotic Enby (talk Ā· contribs) 14:14, 15 June 2025 (UTC)[reply]
Also a good point. I was putting it in quotes, but yes, readers should also be involved (to the extent that it is possible) in the process of deploying new features. Chaotic Enby (talk Ā· contribs) 15:45, 15 June 2025 (UTC)[reply]
There are different types of customers, depending on the feature. With automatically generated summaries, readers are the external customer, and editors are the internal customer with respect to changes to their workflow, as well as being a collaborator due to their vested interest in how Wikipedia presents content. With tone check, editors are the internal customer, though the potential effects of having tone check available affect readers. isaacl (talk) 16:46, 15 June 2025 (UTC)[reply]
Also, editors are the Content Generation and Management Team, by far the largest part of the workforce with immense individual and collective expertise, entrusted with massive responsibilities and altogether Wikimedia's greatest resource. Plus we're cheap. Time and money spent liaising with this team is an acceptable cost that should be factored into project budgets from the start. NebY (talk) 17:21, 15 June 2025 (UTC)[reply]
@Chess, Again, much of what is codified here is already is standard operating procedure across most teams (see the IP Masking rollout, Moderator Tools Automoderators, Growth Team experiments many of which went through multiple feedback loops before coming close to being deployed). The deployment of a single feature is typically supposed to take a longer than a quarter as folks fix bugs and respond to community feedback over a staged rollout. The fact that Simple Summaries got struck down is not only a failure on the community but also a failure of the WMF to effectively communicate and ask for feedback in the right way. What this proposal is aiming to do is to give guidance on engaging with the community, and putting up bright lines and guardrails at the point of deployment without providing a rigid structure that incapacitates them. Technically, a team can ignore our recommendation for "multiple consultations" if they want, but what we are saying here is simply, having multiple consultations (which are not 30-day RFCs on their own) increases your chances of having a easier time with the 30-day RFC approving deployment/A/B testing towards the end of the quarter. Sohom (talk) 16:52, 15 June 2025 (UTC)[reply]
@Chaotic Enby: My reading of irreversible actions, such as database migrations or training production models for these new features, should not proceed until affirmative consensus has been achieved is that significant development work on a prototype requires affirmative community consensus. For example, before I can even download a data dump of Wikipedia and put it into a database on my laptop to begin working on the prototype, I need to hold an RfC by the plain language of the proposed wording. I also doubt any editors would comment on an RfC that's "should the WMF add a new field to the global database schema?", given Simple Article Summaries got no comments at WP:VPT.[31]Chess (talk) (please mention me on reply)04:03, 15 June 2025 (UTC)[reply]
To give an example of how I'd write an RfC statement: The WMF needs a vector database of English Wikipedia articles to enable RAG pipeline research. This will require creating a secondary Postgres+pgvector cluster replicating the primary MariaDB instance. We will also do a staged rollout of Postgres for a subset of our readers to evaluate its performance characteristics. I can't imagine many of us would comment on that, and if I were a developer, I'd rather not wait 30 days to get a community response that is either "sure whatever I don't care" or "I read a blog post saying RAG is dead so the WMF shouldn't invest in it". Chess (talk) (please mention me on reply)05:17, 15 June 2025 (UTC)[reply]
You are misreading the statement here. This kind of a change should not require consensus at all under the current wording since this would not result in the immediate deployment of a AI feature on the English Wikipedia. If a particular RAG based feature is proposed that requires a database migration, the migration should wait until the deployment of the feature (say Simple Summaries) has affirmative consensus. Sohom (talk) 05:31, 15 June 2025 (UTC)[reply]
I don't think that is the case, as building the prototype of a new database would not be an "irreversible action", but only implementing the actual database migration would be. However, if there is an ambiguity over this, you are of course welcome to suggest a clarification to the language.Also, the WP:VPT post was very vague in its wording, mostly focusing on the background and metrics while not mentioning at all the key fact that a generative AI model was used, with the exception of a mention of the text simplification model at the top of the page (not actually anywhere on the page). This lack of clarity over what was actually being done might have been the reason for the lack of engagement, and communicating in plain language about ongoing projects would help. Also noting that WP:RFCs are widely advertised and required to be in the form of a brief, neutral question, while the VPT post was in a completely different form, so this issue might not be present. Chaotic Enby (talk Ā· contribs) 04:14, 15 June 2025 (UTC)[reply]
Indeed, the VPT post didn't even ask for responses, ending instead We will come back to you over the next couple of weeks with specific questions and would appreciate your participation and help. In the meantime, for anyone who is interested, we encourage you to check out our current documentation. That was 10 February; did they come back with questions in two weeks somewhere?
The post wasn't really structured to engage editors either. An encyclopedic lead would have opened by describing Simple Summaries, e.g. as stated later in the post, a summary that takes the text of the Wikipedia article and converts it to use simpler language. Instead it began with a leisurely scene-setting in terms of WMF strategy The Web team at the Wikimedia Foundation has been working to make the wikis easy to engage and learn from so that readers will continue coming back to our wikis frequently.NebY (talk) 15:01, 15 June 2025 (UTC)[reply]
Statement proposed by [user]
Discussion of [user]'s proposed statement
Users who agree with [user]'s proposed statement
ToneCheck community call/discussion
Hi hi, the team behind Tone Check, a feature that will use AI to prompt people adding promotional, derogatory, or otherwise subjective language to consider "neutralizing" the tone of what they are writing while they are in the editor, will be hosting a community consultation tomorrow on the Wikimedia Discord voice channels from 16:00 UTC to 17:00 UTC. Folks interested in listening in joining in, asking questions should join the Wikimedia Discord server and subscribe to this eventSohom (talk) 20:44, 9 June 2025 (UTC)[reply]
@Sohom Datta A notification one day in advance on a page with relatively low traffic compared to other similar pages may not be the best idea. I would've liked to be able to attend. Was @Tamzin: invited, who explained why this is a bad idea here? a feature that will use AI So that decision has already been made? Sentiment analysis does not require AI at all, or at least not what most people would consider to be AI. Where can we find the recording? Why was the Discord platform chosen instead of something more appropriate? Why was the notification only a day in advance? Polygnotus (talk) 17:59, 10 June 2025 (UTC)[reply]
Rapid fire round: I notified WT:NPR, WT:AIC, here, WP:VPT and the tag has been up on discord over the weekend. Discord was suggested by me since a lot of folks are already on it, easier to get folks to show up and provide feedback (over something like GMeet). Tamzin was invited, I explicitly mentioned it to them a last week. I used to term AI because that's the way folks have described it in RFCs, I agree sentiment analysis is a better description, but it wouldn't be accessible to folks. The meeting wasn't recorded, however, notes were taken at [32] (even I couldn't make it since I got stuck in a last minute meeting IRL). The notification part is on me, I realized last minute that I should have put the notifications out earlier. Sohom (talk) 18:23, 10 June 2025 (UTC)[reply]
Also why tell the writer instead of the reviewer? It would be far better to not inform the potential spammer, but inform the AfC reviewer: "x promotional phrases detected, sentiment 95% positive" or whatever, right? Is there a reason we need to tell this information to the person writing the article instead of the one reviewing it? Polygnotus (talk) 19:06, 10 June 2025 (UTC)[reply]
I don't think the BERT model has been trained properly yet (the last I checked atleast, @PPelberg (WMF) will be able to give better specifics). To my understanding, the whole point of the feature is to potentially reduce the amount of time the user spends reviewing another user's edits. I think a big part of the conversation at this point is how to mitigate Tamzin's concerns and surface to the admins/others that the user did see the prompt. Sohom (talk) 19:15, 10 June 2025 (UTC)[reply]
@Sohom Datta We mitigate Tamzin's concerns by providing the information to the AfC reviewer/recent changes patroller/vandalfighter and not the person making the edit. Otherwise you get a bizarre version of Clippy (as NebY explains below).
We don't tell LTA's "if you do this you will be blocked as a sock of X, would you like to continue".
Is my understanding that this model takes only a single edit in account correct? If so, how will it be able to detect actual UPEs like Hajer-12? I compiled a mountain of evidence available at the three collapsible boxes here. This is how marketing companies operate. Polygnotus (talk) 19:29, 10 June 2025 (UTC)[reply]
@Polygnotus Except that we do, with Extension:AbuseFilters and with our vandalism warnings. If we want total secrecy we should just slap every user with a block and never warn them. We don't do that. The point is to tell the admin, "hey this guy was editing promotionally" AND tell the user "hey your tone is promotional". That way we have editor retention as well as better vandalism fighting.
@Sohom Datta Except that we don't, that is not how abuse filters work. There is no abuse filter or vandalism warning that says "if you post this it will be considered behavioral evidence that you are this LTA, would you still like to post it?". And editfilters created in response to LTAs are only visible to admins and edit filter managers.
And I am not proposing total secrecy, or any, so that comparison doesn't hold up. I am proposing providing the information to the person who can use it (AfC reviewer, vandalfighter) instead of showing it to those who can abuse it. They would still be able to see it, e.g. on the AfC dashboard, but only after posting the draft, and without clear instructions how to score better.
The point is to tell the admin, "hey this guy was editing promotionally" AND tell the user "hey your tone is promotional". Why is that the point? That just seems like a bad idea. That way we have editor retention as well as better vandalism fighting. I very much doubt that we want to increase editor retention among people making promotional edits.
yes the model will only take a single edit into account Has an alternative approach of taking more than one edit into account been compared? And other factors like editcount, amount of pages created, account age et cetera? Polygnotus (talk) 19:53, 10 June 2025 (UTC)[reply]
@Polygnotus That is literally how some AbuseFilters works. It shows you a popup and then it allows folks to try and resubmit, which then allows the edit to go through. I am proposing providing the information to the person who can use it (AfC reviewer, vandalfighter) instead of showing it to those who can abuse it., the point here is to allow NPP folks, admins access to the information while also giving the user some indication that they have messed up. Think about it from the new user's POV for a sec, you create a page about yourself, cause you think you are cool (idk, but lot of folks do autobiographies), you are enthusiastic about the page, two minutes later leaves a warning linking to WP:PROMO, you refresh the page and there is another one for speedy deletion and a message asking you to disclose your employer. Before you have finished typing the message, your article is deleted. If we just had one side of the pipeline as you propose, you would just get the warning faster. No change. Alternatively, with Edit Check, you get a warning while you are editing and you read through the policies and realize you should be writing about something else. You do that. On the administrator/NPP/folks who are monitoring users, you could look at a page's log and see that they received a warning and once you do, you are able to still take the same actions. (Potentially), if the folks working on make a robust system, you will also potentially able to see the text that they had before they revised it and are able to spot subtle differences where you are able to link them to specific spam rings. (and/or block them/warn them for it) I don't see a downside here to be honest.
yes the model will only take a single edit into account Has an alternative approach of taking more than one edit into account been compared?, I think using a set of edits and computing similarity with another account/using ML to detect UPE rings is out of scope for this project AFAIK, but it would be a interesting thing to raise with the Trust and Safety Product team (who I think are currently focused on CU tooling and IPMasking) -- Maybe KHarlan (WMF) (a engineer on that team) would be interested/be able to point you to a better place? Sohom (talk) 20:25, 10 June 2025 (UTC)[reply]
@Sohom DattaThat is literally how some AbuseFilters works. No, it is not.
It shows you a popup and then it allows folks to try and resubmit, which then allows the edit to go through. Yes, but that is not what I said. I said We don't tell LTA's "if you do this you will be blocked as a sock of X, would you like to continue". so the fact that there are editfilters that warn you before you can submit an edit (e.g. if it contains a bad link) is not relevant. And as an edit filter manager you know that AbuseFilters do not work that way. I am talking about the fact that we don't always tell LTAs how we detect them, because if we do they will hide themselves better next time. That is different from showing someone a message that a particular link may be undesirable. For example Special:AbuseFilter/213 is hidden from view and only edit filter managers and admins can see it. There are a bunch of other edit filters that are also hidden, usually for a very similar reason.
the point here is to allow NPP folks, admins access to the information while also giving the user some indication that they have messed up. But that is simply a bad idea. Providing that information to NPP/AfC/admin is all good, but providing that information to the person making the edit while writing is a bad idea.
Think about it from the new user's POV for a sec, you create a page about yourself, cause you think you are cool (idk, but lot of folks do autobiographies), you are enthusiastic about the page, two minutes later leaves a warning linking to WP:PROMO, you refresh the page and there is another one for speedy deletion and a message asking you to disclose your employer. Before you have finished typing the message, your article is deleted. If we just had one side of the pipeline as you propose, you would just get the warning faster. No change. Alternatively, with Edit Check, you get a warning while you are editing and you read through the policies and realize you should be writing about something else. You do that. This would basically never happen. The idea that people who write autobiographies would suddenly be converted into goodfaith editors with a simple popup is very very very very optimistic. In reality, the best case scenario is that they stop and move on, which a 24-hour block is more likely to achieve than this Edit Check.
There is a group of promotional editors, lets for the sake of argument say 100% of edits is promotional. Of the promotional edits they make only a tiny subset is salvageable if you rewrite them, maybe 1%.
If we assume that all editors are promotional editors, then there is maybe 1% or 2% who may be interested in becoming goodfaith non-promotional editors. I think that at most 1% or 2% of the general population of a rich European country would want to be a goodfaith Wikipedian, and among promotional editors that percentage is probably smaller, not larger. We do not want to increase editor retention of promotional editors, so the entire idea is misguided at best and actively damaging the encyclopedia at worst.
So a far more likely scenario is: UPE shows up, Edit Check helpfully assists them whitewashing their spam, and it gets deleted anyway but may take longer to detect it/may fool inexperienced NPP/AfC folk.
you get a warning while you are editing and you read through the policies The people I meet on the street or the internet don't work like that.
We want trolls to insult everyone, see WP:ROPE. We want promotional editors to be as promotional as possible so that it is easy to detect and flag. We want vandals to use bad words that make Cluebot's job easy.
I think using a set of edits and computing similarity with another account/using ML to detect UPE rings is out of scope for this project AFAIK Maybe, but that is not what I said. What I said was: Has an alternative approach of taking more than one edit into account been compared? So let's say an account makes 10 edits and we have a reasonable suspicion that 1 edit is promotional. It would make sense to check the other edits and if they are promotional too then you can be almost certain this account is up to no good. But when you only use 1 data point (1 edit) the reliability is far lower.
I also mentioned other stuff you can take into account when determining a score, like editcount, amount of pages created, account age. For example, it would be interesting to see people who make 10 edits, wait until 4 days have passed, and then suddenly start editing in a way that sentiment analysis determines is highly positive or negative. Or 500 edits and 30 days. Especially in a CTOP area. Am I making sense?
See WP:BEANS, we don't want to give our enemies information on how to better evade our scrutiny. Although I am a big fan of oracle attacks.
I think using a set of edits and computing similarity with another account/using ML to detect UPE rings is out of scope for this project AFAIK, but it would be a interesting thing to raise with the Trust and Safety Product team Oh yeah I made something like that once. I have a tool that gets all diffs of edits by a user, and you can filter out the context, so if you do that with 2 users it is pretty easy to compare. I hadn't really figured out a way to determine how rare each string was before my attention was drawn to something else. Polygnotus (talk) 21:10, 10 June 2025 (UTC)[reply]
I don't want to go around in circles here, but the feature is broadly aimed at increasing editor retention amongst new users. Yes, a UPE users will be warned about their impending doom, but the idea of the call was to figure out what tooling the team needs to work on/make robust so as to mitigate and counteract the effect of showing the new editor a prompt asking them to improve their text. (for example, if we as AFC/NPP folks can see the text before a edit was revised, I see no reason why we should not try to help good faith editors write about their favorite content creator in a NPOV manner or write about their research?) The point of the feature is to encourage editor retention (by letting folks know when they have violated policy) before they save an edit, not to serve as a anti-vandalism toolkit (even tho that might be a by-product). Part of the feature (not specifically ToneCheck) has even already been deployed to wikis.
So a far more likely scenario is: UPE shows up, Edit Check helpfully assists them whitewashing their spam, and it gets deleted anyway but may take longer to detect it/may fool inexperienced NPP/AfC folk. - Except, that if we design this correctly, NPP/AFC folks would know to EditCheck logs, see the previous versions of the edits and alert a admin to block the user. We could even surface the fact that an EditCheck event was triggered inside the AFC script or the PageTriage UI (Think like a AbuseFilter for bad links) That's what this call was for!
I do come from a background of computer security, so I understand your propensity to come at it from the point of view of a threat model, however, it's important to note that unlike most traditional security models, if we accidentally err on the side of too much enforcement we go the way of StackOverflow questions graph. Sohom (talk) 22:17, 10 June 2025 (UTC)[reply]
@Sohom Datta:That's what this call was for! Neither of us was there during this call, so maybe you can invite me to the next one? In my experience people who always agree with me are very boring.
As a user of both: Wikipedia can learn a lot from StackExchange, and StackExchange can learn a lot from Wikipedia.
Please respond to the part that starts with "What I said was:" to the end of this comment because it is a pretty good idea and something I have been contemplating making for a while (although my idea was to use a different approach). It looks like the team has tunnel vision on their proposed solution, which is very common in software development (especially when coders have managers). They should step back and consider what other ways of tackling this problem exist, and how else we can use this tech, and make a list of reasons why this is a bad idea/the downsides/flaws/imperfections. I also list my assumptions and why they are wrong. That usually helps me. What percentage of promotional edits do you think is salvageable if rewritten? What percentage of promotional editors do you think can be converted to goodfaith editors? Polygnotus (talk) 23:22, 10 June 2025 (UTC)[reply]
I will keep it in my mind to notify you whenever the next one happens.
I think the CTOP area idea is interesting and a good idea, I think a variation of this would be useful at SPI to find sleeper socks as well.
Regarding the rest, the reason the team is working on it is because members of the community have suggested that EditCheck in general is a good idea. Another thing to keep in mind is that we are not necessarily talking about promotional edits (even though that is a major portion), but NPOV text is general (this might be both overly negative and overly positive). I don't have numbers for the same, but I agree that it would be interesting for the team to pull them up at some point. Sohom (talk) 23:58, 10 June 2025 (UTC)[reply]
@NebY, Folks (read newbies) are unintentionally promotional as well ("Google Chrome is a renowned product" etc), in which case, they get slapped with 4 warnings and a block and leave the wiki. It's nice to tell them, hey "you tone sounds off here, please write about it more neutrally" while they are writing about it. Sohom (talk) 19:29, 10 June 2025 (UTC)[reply]
@Sohom Datta I would like to see statistics. Pretty sure most promotional edits are made by people who are actually promoting something and not well-meaning newbies with a surprising love for spyware. And I have yet to encounter the scenario of a goodfaith user without promotional intent getting blocked for promo. Most admins are sane. Polygnotus (talk) 19:33, 10 June 2025 (UTC)[reply]
We are regurgitating the thread above at this point. I don't have numbers for it, but even if the fraction is low it is still worth it to improve editor retention. It is bad for editor retention for us to even be giving warning and declining pages since warnings and declining pages are often demoralizing to well meaning editors, which are the folks we need more of. But we do need to do that anyway, so why not do it when the editor is in the edit page ? Sohom (talk) 19:44, 10 June 2025 (UTC)[reply]
I'd hope that any organisation's spending decisions went beyond "even if the fraction is low it is still worth it". New editor retention is not an absolute good to be pursued regardless of cost, whether cost to the encyclopedia in degraded quality and the attendant reputational harm, or cost to the WMF in time, money and community relations of pursuing a minimal improvement in that metric. NebY (talk) 19:57, 10 June 2025 (UTC)[reply]
@NebY The point of the community consultations is do that the team can address concerns and look at methods to minimize the costs that you mentioned. Sohom (talk) 20:27, 10 June 2025 (UTC)[reply]
Can minimising the costs include re-evaluating the project and agreeing that it is not worth it? Your phrasing suggests not and that a single metric will be pursued regardless of other considerations. NebY (talk) 21:07, 10 June 2025 (UTC)[reply]
@NebY I do not think the overall EditCheck project is going to be reconsidered (especially since it has been partially deployed on other wikis) though the specific ToneCheck component and it's applicability to enwiki definitely can be (and that decision will be not up to the team but the community).
To answer your question below, to my understanding, the team intends to understand the problems raised and to balance the trade-off there and build good tooling for folks doing anti-vandalism/detecting spammers. I don't know what you took away from the statement I said above, but the point is not to keep promotional editors in, and the long-term editors out, but rather to notify the good-faith people making the mistake so that they can course-correct and avoid getting demoralized while also preserving status quo in our ability to moderate content. Sohom (talk) 23:47, 10 June 2025 (UTC)[reply]
If I understand you correctly you believe there is a significant amount of overly enthusiastic goodfaith people who make promotional edits because they don't understand the rules who can be converted to goodfaith editors ("%celebrity% is the best evar!!1!") while I (as a jaded person) believe that that is a small minority of the people who make promotional edits. I believe that a large majority of people who make promotional edits are doing that to promote something. Polygnotus (talk) 23:53, 10 June 2025 (UTC)[reply]
Is the retention of editors who defend the encyclopedia against promotion also a consideration, and does the same "even if the fraction is low" apply to the risk of them giving up? NebY (talk) 21:33, 10 June 2025 (UTC)[reply]
Is the AI capable of distinguishing unintentional promotion from the wholly intentional that we see so often? NebY (talk) 19:38, 10 June 2025 (UTC)[reply]
Also, wtf are you doing here? That is impersonation. If I thought it was a good idea to close I would've done that. If you wanted to close it you could. But please do not edit my comments. People get very annoyed if you do that. Thank you, Polygnotus (talk) 18:03, 10 June 2025 (UTC)[reply]
I don't think it's impersonation but I understand your concern of misconstrued intentions, you can just revert and move on though, I'm pretty sure they didn't mean anything by it. --qedk (tęc)18:09, 10 June 2025 (UTC)[reply]
@QEDK Yes, I am very much assuming good faith, and I love Sohom, but I get very annoyed when people edit my comments. Hence my warning that People get very annoyed if you do that. Polygnotus (talk) 18:13, 10 June 2025 (UTC)[reply]
That, I just assumed based on the way things were laid out that you had intended it in that particular format, feel free to revert. It just makes more sense to centralize discussions about this topic at this point. Sohom (talk) 18:14, 10 June 2025 (UTC)[reply]
@Sohom Datta I agree that it makes more sense to centralize discussions, and I don't even disagree with closing, but you get very annoyed if I edit your comments to insert interesting facts about ducks and I get very annoyed if you edit mine. It is something we both share. So we only edit our own comments. And for a bit there I lived in an alternate reality where I had closed a section with absolutely no recollection of ever having done that, while clearly remembering having left that comment, and I had to dig through the history to confirm that my memory was still trustworthy. Polygnotus (talk) 18:16, 10 June 2025 (UTC)[reply]
@Sohom Datta Thanks to you and the Tone Check team for setting up this consultation. As I'd warned, I'm recovering from COVID and couldn't predict when I'd be awake; and, just my luck, this turned out to be the first day in a week that I wasn't awake that time. But I hope some kind of good discussion was able to happen with others who did make it. -- Tamzin[cetacean needed] (they|xe|š¤·) 21:25, 10 June 2025 (UTC)[reply]
@Tamzin Unsurprisingly the notes taken by the WMF say: Volunteers feel confident WMF Staff developing Tone check really understand the concerns/risks being raised in the WP:VPWMF discussion. so I doubt it was a very productive discussion of the pitfalls, downsides, drawbacks, limitations, risks, flaws and challenges. Polygnotus (talk) 21:29, 10 June 2025 (UTC)[reply]
@Polygnotus That was the expected outcomes of the meetings, potentially used to tell peeps who were joining what the agenda was. That's how notes are taken for these kinds of discussions. Everything after that is a summary of what happened, which it appears wasn't written by staff (as evidenced by the difference in color) Sohom (talk) 21:34, 10 June 2025 (UTC)[reply]
I'm glad to see some progress was made. From the minutes, it doesn't sound like the WMF is close to having an answer to the fundamental concerns about making a tool for spamming better and then enabling it by default for all users, necessarily including spammers. As I cautioned when you first suggested I talk to some people on the team, they're not going to have a good answer to that, because there is only one good answer, and it's to not make the damn thing. In a collaborative community, that is what we do when someone has a fundamentally bad idea: We tell them to stop pursuing it. -- Tamzin[cetacean needed] (they|xe|š¤·) 21:44, 10 June 2025 (UTC)[reply]
@Tamzin How do you feel about this same idea but without telling the (potential) spammer and only in retrospect after the edit was made/draft was posted? So only disclosing the sentiment analysis to NPP/AfC/admins et cetera? Polygnotus (talk) 21:50, 10 June 2025 (UTC)[reply]
I am less opposed, but still concerned about creating a large language model that could be used outside of our own servers to create more presentable slop. The obvious solution remains simply not doing this at all. The marginal benefit the WMF seeks here is pretty minor. -- Tamzin[cetacean needed] (they|xe|š¤·) 21:57, 10 June 2025 (UTC)[reply]
@Tamzin I'm not a 100% convinced that it's a completely bad idea and while I agree that it does not appear that we have a definitive answer today, I think there are technical improvements to be made that could made (for example, T395166) which mitigate a large portion of the risk. To my understanding the call was primarily so that the team was aware and understood what we are concerned about and not necessarily to pull the proverbial mitigating bunny out of the hat. I think we should give the team some time. If the mitigation(s) are not sufficient at the time of deployment I'm pretty sure we can ask them to shut/undeploy this particular component from enwiki and I see that folk have already raised the point of Community Configuration not being sufficient in this case. Sohom (talk) 22:30, 10 June 2025 (UTC)[reply]
@Sohom Datta So they are going to publish the model, make a test page where anyone can enter some text to get a score, and then get proper community consensus first (with a link on WP:CENT to a discussion on WP:VPT and then a RfC a week or two later, and not with one of their weird surveys on qualtrics or limesurvey) before potential deployment right? If that isn't their plan, can you please explain to them that they must do that? which mitigate a large portion of the risk The linked Phab ticket does not mitigate a large portion of the risk.
If the mitigation(s) are not sufficient at the time of deployment I'm pretty sure we can ask them to shut/undeploy We won't need to because they will allow the community to test the feature and are then going to get proper community consensus right? Polygnotus (talk) 22:37, 10 June 2025 (UTC)[reply]
To my understanding the answer to that is yes. I do not have access to a time machine (last I checked) so I cannot predict the future (obviously). The team has already done a fair bit of the right things (by consulting the community and releasing early prototypes, which led to this concern being surfaced in the first place) and I expect them to generally do the right thing and follow community norms in general. Sohom (talk) 22:52, 10 June 2025 (UTC)[reply]
@Sohom Datta Please make sure. Thanks. I am happy to test the model and provide further feedback. Downside is that I am a jaded nitpicker. Upside is that I am usually correct. Please let me know when and where I can download the model. Polygnotus (talk) 22:56, 10 June 2025 (UTC)[reply]
I appreciate the desire for anyone to be able to test the model, but if it is published for anyone to run, then it can be used by malicious people to train their programs or staff. I am concerned about the risk this would pose. There will be no logs on the server to consult if the iterations are being done off-wiki. isaacl (talk) 01:05, 11 June 2025 (UTC)[reply]
I've already discussed how malicious people can implement their own quality controls and develop their own programs, so there's no need to tell me about what they can do. Nonetheless, that doesn't mean we should allow them to train on the same Wikipedia quality controls being applied in production. isaacl (talk) 06:09, 11 June 2025 (UTC)[reply]
My headline would be despite all the thoughtful commentary here the team didn't understand the community concerns. I think some marginal progress was made during the meeting. I will hope that more progress, real progress, is made after when the team has time to reflect on the discussion. I was only able to stay for 45 minutes so perhaps things changed after I left. Best, Barkeep49 (talk) 01:41, 11 June 2025 (UTC)[reply]
In contrast to Barkeep I was only there at the tail end of the meeting and my interpretation was very different. The team accepted/agreed to look into several proposed improvements and alterations that, in my view, would make me fully support the implementation of ToneCheck on enwiki. These potential changes include integration with edit filters, logging edits flagged by ToneCheck, and capping the number of times the same edit/user is flagged, to prevent "oracle attacks" (or just good-faith editors circumventing a warning they do not understand by repeatedly slightly altering their edit).
I share Sohom's optimistic interpretation that most editors adding non-neutral wording are not looking to promote stuff, but simply do not understand how Wikipedia works. A wise editor once pointed out that schools spend the first two decades of childrens' lives drilling them in argumentative essay writing, so we cannot blame those people when they then come to Wikipedia and continue writing in that style. Toadspike[Talk]18:02, 12 June 2025 (UTC)[reply]
Capping the amount of times the same edit/user is flagged would not prevent oracle attacks.
Make a list of 1000 editors who made a promotional edit. What percentage of those edits can be salvaged if rewritten? What percent of those editors can be turned into goodfaith net positive Wikipedians? 2%? Polygnotus (talk) 18:07, 12 June 2025 (UTC)[reply]
I think ToneCheck is a great idea. The idea that we should make it harder to edit Wikipedia so it's easier to "trap" disruptive individuals is textbook WP:BITING. The main problem with promotional editing is a lack of neutrality. It's not a game where we try to play "gotcha" and get editors banned. Banning editors is a last resort to protect the encyclopedia, and we should always prefer improving editors to excluding them. This proposal prevents common promotional wording from even entering the encyclopedia in the first place. Chess (talk) (please mention me on reply)02:39, 15 June 2025 (UTC)[reply]
@Chess How do you propose we improve promotional editors who show up to promote a product/brand/company? The idea that we should make it harder to edit Wikipedia so it's easier to "trap" disruptive individuals is textbook WP:BITING. No, it isn't, and no one proposed that. This proposal prevents common promotional wording from even entering the encyclopedia in the first place. No, it doesn't. Have you read the above? Polygnotus (talk) 02:42, 15 June 2025 (UTC)[reply]
@Polygnotus: I did read the above. To give an example, you said: New editor retention is not an absolute good to be pursued regardless of cost, whether cost to the encyclopedia in degraded quality and the attendant reputational harm, It's obvious you want to filter out promotional editors based on motives, since you don't view them as improvable.
I'm coming at this with my experience in WP:CTOPS like Israel-Palestine, where approximately 100% of editors have some kind of agenda. Generally, that agenda is fixing Wikipedia's bias against their ethnicity or cultural group. Their remedy is adding biased statements in the other direction.
Your proposal to use this to retrospectively identify editors that become biased after reaching 500/30 isn't useful. We've had 5 ARBCOM cases and hundreds of WP:AE threads, and it's a game of Whac-A-Mole that isn't working.
What does work is guiding editors towards WP:NPOV and reassuring them that our policies are being evenly applied. ToneCheck can be helpful, because it's a machine tool, not an editor who likely has an interest in promoting or advancing the goals of their specific side. Chess (talk) (please mention me on reply)03:21, 15 June 2025 (UTC)[reply]
@ChessTo give an example, you said No, that was NebY who is far more eloquent than I am. It's obvious you want to filter out promotional editors based on motives, since you don't view them as improvable. Nah, I said there was like 1-2% who might be improvable. But that is pretty optimistic. Do you have any evidence of people who come here to promote a brand/product/company and then gets turned into a productive editor?
What does work is guiding editors towards WP:NPOV and reassuring them that our policies are being evenly applied. Why would lying to them work? No one believes that this planet, or any of the systems on it, is fair. Wikipedia certainly isn't fair. In the CTOP area some try to be fair (but their perception is flawed, like all humans), most do not.
What does work is guiding editors towards WP:NPOV New editors are immune to PaGs. And WP:NPOV is 5502 words. I am pretty sure that in the history of Wikipedia no one has ever turned a PIA POV editor into a productive editor with gentle guidance.
Your proposal to use this to retrospectively identify editors that become biased after reaching 500/30 isn't useful. Why not? How do you know? Why should we trust you?
ToneCheck can be helpful, because it's a machine tool, not an editor who likely has an interest in promoting or advancing the goals of their specific side. So you think that a small language model cannot be biased? There are roughly a quarter million news articles published recently describing AI bias. If the training data (the internet/Wikipedia) is biased then the AI output will be biased. Computers running AI are glorified calculators on steroids mixed with crack; not impartial arbiters of truth. Markov chains do not lead to spiritual enlightenment. Polygnotus (talk) 10:14, 15 June 2025 (UTC)[reply]
I'm constantly involved in arguments in ARBPIA, and the one thing that can get editors to make concessions is the perception that a neutral standard is being applied.
I'm currently working on this with the term "massacre", which is unevenly applied across the topic area. Editors are willing to !vote to remove it when the term is used for the killing of people on "their side", so long as they see the same standard being applied to killings of people on the "other side". Arguments about minor style issues consume less time.
I have less experience with COI/promotional editors outside of AfC. It'd be nice to avoid forcing people through a 4 month queue only to get rejected for blatantly promotional wording. Chess (talk) (please mention me on reply)19:25, 19 June 2025 (UTC)[reply]
@Chess:I'm constantly involved in arguments in ARBPIA Oh man that sucks. Try to escape!
the one thing that can get editors to make concessions is the perception that a neutral standard is being applied. Have we tried the honesty technique? "We are all fallible humans and most of us are trying to do the right thing but this stuff is very difficult and it is easy to fall into the trap of tribalism."
I'm currently working on this with the term "massacre", which is unevenly applied across the topic area. Even what we consider to be reliable sources use terms unevenly. There are no secret balanced sources we can use so it would be good if the general public develops a bit of media literacy. But that costs billions in education.
It'd be nice to avoid forcing people through a 4 month queue only to get rejected for blatantly promotional wording Yeah it would be pretty easy to write some code to give AfC reviewers a list of drafts that should most likely be rejected. I proposed something like that once. Polygnotus (talk) 21:55, 19 June 2025 (UTC)[reply]
Have we tried the honesty technique? Everyone honestly believes that Wikipedia is irredeemably biased against "their side". This perception is fed by individual cases of POV-language introduced by drive-by editors without discussion. Since humans tend to notice unequal treatment when it benefits "their side", any unequal treatment turns into accusations of bias.
Any effort that establishes consistency is beneficial. It doesn't actually matter what the standard is so long as it's outside of the direct control of participants in the current dispute and perceived as being somewhat neutral. A literal dice roll hosted by the WMF could benefit the area.
Oh man that sucks. Try to escape! It's too fun to leave at this point. I like the dance of negotiation and bargaining on article content. I am learning a lot.
It's an old idea with a few previous iterations, but plaudits for this specific initiative (or at the least for being the public face and focal point for this initiative) go to RAdimer-WMF. CMD (talk) 16:33, 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.
Wikipedia does not allow advertisement, so why do we allow fundraising banners all the time on these pages? This is essentially advertisement for the Wikimedia Foundation.
In the past, this was justified as a necessary evil since Wikipedia needed funds to survive. However, the WMF had over $271 million of assets by the end of the 2024 fiscal year.[1]
Even with a very conservative average 5% interest rate, and reinvesting half of it in the fund to compensate for inflation, this would mean almost $7 million per year. This is more than double the ~$3 million that the WMF spent in internet hosting in fiscal 2024 (although that does not include salaries, the other $4 million should be more than enough to pay for salaries of technicians and other essential workers). This is before any donations coming even without the banners, which would likely be much more than the $7 million from the endowment.
What about the $178 million that the WMF spent in the last year? It would necessarily need to be cut drastically to focus back on the core responsibility of the WMF: running the servers. The WMF has demonstrated many times by now that not only they are not willing to invest this extra money in projects that are requested by the community (see for example the Graph extension being down for 2 years, replaced only now by a barely functioning alternative, or the community wishlist which is consistently ignored), but they spend money and resources in ways that are explicitly opposed to the wishes of the community (and with barely any community consultation), sometimes even risking the whole project in the process (see the incredibly misguided AI proposal under discussion here).
Valid complaints. They forget that Wikipedia (and it's images in commons) is beyond being the flagship of WMF, it is THE ship that it rides on. But but that means that Wikipedia needs to help fund raise to some extent. Sincerely, North8000 (talk) 21:42, 12 June 2025 (UTC)[reply]
My point is that proceeds from the endowment (which the WMF already has established) should be enough to ensure basic infrastructure working for the foreseeable future. Any more funds coming are welcome (people will keep donating anyway without the banners), but they are not vital: fundraising banners trick people into believing that a donation is essential to the survival of the project, when this is not true at all. If anything, it seems that more money is a threat to the project rather than a help. Ita140188 (talk) 21:52, 12 June 2025 (UTC)[reply]
Yes. Wikipedia existed before the WMF, but that seems to not be realised by many WMF staff, who seem to think that the WMF owns Wikipedia. The WMF has become much more bloated than is needed to provide logistical support to Wikipedia. Phil Bridger (talk) 22:00, 12 June 2025 (UTC)[reply]
I am glad the foundation can do more than zero work developing mediawiki software. I find it essential that we have a legal department - seemingly not contemplated in the "we can run the WMF for 7 million dollar budget" - who can offer legal assistance to editors facing lawsuits and can afford to hire top notch representation to fight back legal challenges, as they have and continue with ANI's baseless lawsuit. Best, Barkeep49 (talk) 22:14, 12 June 2025 (UTC)[reply]
Donations will still come even without the banners, so the budget would be substantially higher than $7 million (probably by a factor of 10, considering previous estimates of how much the English Wikipedia banners contribute to the total donations). There will be enough funding for a legal department. As for the development of the Mediawiki software, there is plenty of examples of successful open source software developed entirely by volunteers (see Linux and its ecosystem for example) so I don't see why it should be different for Mediawiki (which by the way is already very mature and does not necessarily need large amount of work in any case). Ita140188 (talk) 22:22, 12 June 2025 (UTC)[reply]
It is not developed just by volunteers. A ton of the development also comes from WMF employees. And the tasks tracker is, of course, administrated by the WMF; the maintainers of MediaWiki also belong to WMF. Linux also has people paid by the Linux foundation and many "volunteer"s are paid by big companies like RedHat to contribute to Linux. Aaron Liu (talk) 01:40, 13 June 2025 (UTC)[reply]
You are comparing a critical/foundational infrastructure software against Mediawiki? Linux depends on paid "volunteers" for the continual development. A good chunk of codes in Linux are being written by programmers who have vested interests, e.g. Intel engineers pushing their firmware updates. How many large companies are there that rely solely on MediaWiki? A lot of successful open source movements have a corporate sponsor or two. WordPress relies on Automattic; Redis just turned corporate; its fork, Valkey is driven by volunteers employed by large corporations/entities like AWS; Chromium by Google, and increasingly Microsoft as well; MySQL and Java are with Oracle. In a way, Mediawiki benefits from having the Foundation as the sponsor as it distances the influence of corporations from its development. ā robertsky (talk) 01:40, 13 June 2025 (UTC)[reply]
Agreed. We are shortly going to have cause to be immensely grateful for the foundation's massive legal and public outreach warchest, you can be well assured of that. The greatest existential fight of this project's entire history is on the immediate horizon, make no mistake. Now personally, I believe that the WMF horrifically failed in its ethical duties to volunteers and to the community in several aspects of the ANI debacle. People have recently celebrated (with good cause) that the Supreme Court of India "permitted us" to reinstate our article on ANI, while looking past the questionable decisions of the WMF in using an office action to overrule the community's prerogative without consultation in the first instance. To say nothing of the fact that in order to preserve that appeal before the high court, the WMF (after disingenuously hand-waving away community concerns that they would do this very thing) decided to throw community volunteers thoroughly under the bus by disclosing PII to the court of appeals, knowing it would end up in the hands of ANI and other third parties in a dangerously sectarian context--thereby betraying a decades-long convention for how we protect our volunteers and vitiating the trust that accrued from those assurances. To say nothing of how the Foundation's management of those issues seriously damaged the faith of the community that the old standards for shared leadership in moments of crisis would be respected. All of which is to say: I get why trust in the foundation is at a low ebb. In the course of one short year, I for one went from someone who would easily, vocally, and consistently support the WMF in discussions like this (as a consequence of a history with non-profit administration and an appreciation of the organizations formal duties and special remit) to someone who could not really be any more concerned about the org's leadership and it's drift away from community values and towards an increasing propensity to try to unilaterally define the movement's priorities and steer its course. But those issues are at most tangentially related to fundraising, "bloat", or expanding operational costs. None of these things present a serious risk to this project's autonomy or functioning. The real issues are that the WMF Board and senior operations staff have been allowed to become increasingly isolated from the direction and influence of the project communities, becoming more and more untethered from taking their ques on movement priorities from (or having any true accountability to) the communities of the projects and affiliates. The ship is going to have to be righted in that respect in the very near future, because the only way we will be prepared to meet the challenge that is coming is if the communities and the WMF prepare a united and well-formed front against that storm. That is part of why the ANI situation has left me so ill-at-ease (though I would have been opposed in principle to selling out those editors regardless): I recognized that it should be seen as a trial run for the bigger contest that is coming on turf where comity concerns will provide the Foundation and en.Wikipedia even less room for evasion, and I didn't like what I was seeing regarding the Foundation's response under the much lower threshold of pressure it was facing in that rehearsal fight. From its a priori choice of priorities, to its questionable approach to the legal issues, to it's utterly confused and at times outright disrespectful approach to communication with the community, I feel that they demonstrated that they do not have the right people in charge to meet this defining moment for the movement. That's why I think the recent announcement of a CEO transition could not possibly be more consequential. I can't help but feel that there is an opportunity here to re-align the Foundation with broader movement priorities and rehabilitation of the Foundation's responsiveness to the community. But whether the vestigial organs of communication between the two heads of the behemoth are still operational enough to allow for any serious improvement in that respect remains to be seen. But one thing I know is certain: we gain very little from attempting to reduce the Foundation's financial resources, and any effort to block fundraising banners may in fact embolden the more autocratic elements at the WMF to just technically circumvent the community's will in the unlikely event it supported this proposal, further fracturing our trust and unity at a moment when we should be in full damage control mode with regard to repair our means of rowing together and demonstrate mutual respect. SnowRise let's rap00:38, 13 June 2025 (UTC)[reply]
I agree with Barkeep, but would be curious to see the data on how much banners impact the total donations. However, given the current political climate in the United States (where the servers are hosted), I believe that a fight between the community and the WMF will not be helpful for the encyclopedia's future. Chaotic Enby (talk Ā· contribs) 22:55, 12 June 2025 (UTC)[reply]
That's a good point, and I think it suggests another line of discussion: the need for decentralization of Wikipedia's infrastructure and governance. The authoritarian drift and the decline of the rule of law in the United States is a huge risk to the project right now, even without a fight between the community and the WMF. Ita140188 (talk) 23:04, 12 June 2025 (UTC)[reply]
There are two problems with that: 1) to say that such a move would be divisive among the various communities and within the WMF itself is about the understatement of the century. And 2) such a move would be so technically, operationally, administratively and legally complex to be as next to impossible at this juncture and, if feasible, would take nothing less than a good number of years. We don't have that time right now. The situations which so demand uniformity of planning and good faith between the community and the foundation are essentially right upon us. Now is not the time to be further damaging the sense compatriotism between the community and the Foundation. And I'm not saying the community doesn't have reasons to be concerned (read my exhaustive post immediately above to see just how much I'm not saying that). But right now we need a firm mood of detente, not more squabbles over comparatively inconsequential issues that can be re-visited in a few years if we manage to shield the critical projects against the efforts at repression and censorship that it is about to face. Not that I think it is likely to ever make sense to forbid on-site fundraising efforts. But if a time like that might someday exist, this is certainly not it.SnowRise let's rap00:48, 13 June 2025 (UTC)[reply]
The infrastructure is already decentralising, with data centers located across the world, and regular switching of the two main data centers every six months. can more be done? May be, but definitely not at the current costs. One would probably have to increase the amount of servers, storage and data transfer to upgrade the caching data centers to full fledged one and employ dedicated people on site to manage everything. ā robertsky (talk) 01:12, 13 June 2025 (UTC)[reply]
If I recall (not that I was directly involved) there were noticeable changes to funding streams as a result. CMD (talk) 02:30, 13 June 2025 (UTC)[reply]
Can we stop with this bullshit please? If you have suggestions for how the WMF should spend its money, get involved at meta-wiki or run for the board. If you think people should donate to other non-profits, go fundraise for them. The WMF exists and it has significant assets which it spends on maintaining Wikipedia, advancing the open knowledge movement, and protecting the community. None of that is not going to change. voorts (talk/contributions) 23:25, 12 June 2025 (UTC)[reply]
I think this proposal is a bit too radical and doesn't show a good understanding of the services that the WMF provides. If the WMF were stripped down to just servers and site reliability engineers, then there would be no conferences (Wikimania, Hackathon) and conference scholarships, no new software features and extensions (I assume you are proposing getting rid of all the "product" teams such as the Moderator Tools Team, Editing Team, Trust & Safety Product Team, etc. that make new software and maintain existing software), no legal department, no Trust & Safety Team, no affiliates, no rapid grants, etc.
In general, English Wikipedia has a certain amount of political capital that we can use to lobby for changes in other parts of the movement, and I think we should "spend" this political capital wisely. We should spend it on very important issues and in a way that doesn't make other parts of the movement resent us. Or if we do cause tension with other parts of the movement, it needs to be for an issue that is worth it. Let's pick our battles wisely. āNovem Linguae (talk) 00:44, 13 June 2025 (UTC)[reply]
I agree with Novem. An issue as trivial as banners is not what the community should be focusing its political capital on, and sacrificing most of what the WMF does in the name of removing donation banners is not reasonable.One of the main reasons why Wikipedia does not run ads is to stay financially independent of any backers. The WMF, thanks to donations, is exactly what guarantees that financial independence. Chaotic Enby (talk Ā· contribs) 00:49, 13 June 2025 (UTC)[reply]
The WMF continues to hugely support our work despite its shortcomings. See Wikipedia:Resource support pilot for a newly launched example. Building on asilvering, jumping to the nuclear option after the WMF retracted its AI article summaries sends a message that we are incorrigible. ViridianPenguinš§ (š¬) 04:11, 13 June 2025 (UTC)[reply]
I don't support this proposal but I do want to point out that the WMF didn't "retract" the AI project. It's on hold but not canceled. Gnomingstuff (talk) 08:17, 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.
Agreed, and that observation underscores a broader point: with the floor falling out from underneath numerous beneficial projects in the broader free knowledge movement, the Wikimedia movement may be positioned as a possible source of fall-back support for many of them. But none of that is going to come cheap. It's one thing to have reservations about how the Foundation allocates its resources in any given funding/operational cycle. It's another to decide the solution to those misgivings is to undermine its ability to recharge its resources. SnowRise let's rap01:30, 13 June 2025 (UTC)[reply]
Design feedback on category-based template discovery
The CommTech team is soliciting feedback on a set of designs to use categories to improve the quality of life for folks discovering templates through the Visual Editor template selection interface. This work comes from a focus area identified as part of the new Community Wishlist survey. The designs and the survey can be found here. Sohom (talk) 13:23, 16 June 2025 (UTC)[reply]
Official Wikipedia Roblox game and Generative AI use
I considered whether to add this as a subsection to the above RFC on WMF AI development, but decided not to as I didn't want to further bloat that discussion. Regardless, just earlier today I came across a post on instagram from the official Wikipedia instagram account (facebook link for boomers who don't have instagram) showcasing a new Wikipedia Roblox game. The post was made almost two weeks ago so I'm not sure whether it has already been discussed before, but this is a continuation of the use of generative AI (the cover image for the game page, which is also included in the instagram and facebook posts is almost certainly AI) which has quite openly been discussed and decried by many users in the community. I also think that this is a different issue, though, as rather than this use of AI being even remotely justifiable as trying to improve the quality of the 'pedia, the use of generative AI images in what is basically marketing materials really only serves to costs while providing a worse product. I also echo users concerns about the WMF's environmentalism when they say things like The Wikimedia Foundation believes that a long-term commitment to sustainability is an essential component of our work towards the Wikimedia mission and visionhere, but then use generative AI to create images for their Roblox game.
I'm aware that most folks on here are certainly not the demographic targeted by this sort of post, but in the end it still reflects on us, so I wonder what folks think. Weirdguyz (talk) 00:45, 17 June 2025 (UTC)[reply]
the WMF, last week: 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.
I guess the skibidi brainrot market technically is not the "Wikipedia reading experience", exactly! I'm aware that most folks on here are certainly not the demographic targeted by this sort of post, I think is the most important part. We don't know what folks who are actually in that segment want/use. The Future Audiences team is creating short-lived experiments to understand what kind of content the younger generation want. It obviously will be considered borderline by folks who are not the target demographic (which will be a large portion of the community base). I don't support Roblox's exploitative marketplace nor am I supporter of AI image generation, but I do recognize that these explorations are necessary to understand and figure out what kind of media for consuming Wikipedia is popular among the younger crowd (damn, that makes me sound old). Whether or not the WMF invests significantly more resources into that direction and decides to rewrite MediaWiki in Roblox-lang (I believe it is a flavour of Lua?) is up for debate and something that we should (and rightfully does) have a say on. Sohom (talk) 06:04, 17 June 2025 (UTC)[reply]
Do my eyes deceive me, are you saying Roblox may be incubating a generation of Wikipedia coders? I might change my mind on that game. CMD (talk) 06:13, 17 June 2025 (UTC)[reply]
Oh my gripe is certainly not with the fact that they've made a Roblox game, bringing in the younger generations is paramount to the continuation of our goal (I say this as one of the younger (relatively...) generations). My issue is solely with the generative AI used in said pursuit, because the only argument in favour of it is that it is cheaper than paying an actual artist. The quality of the work is worse than if you got an actual artist to make something, the environmental impact is a genuine measurable concern, and the number of people who will see the use of generative AI and be turned off the WMF and Wikipedia is not insubstantial. Weirdguyz (talk) 06:23, 17 June 2025 (UTC)[reply]
If only we had a repository of free images they could have used instead, or a cohort of editors who might be willing to create and donate actual human work for this. Fram (talk) 07:16, 17 June 2025 (UTC)[reply]
It there is a desire to productively engage on questions regarding the use of generative AI/llms/similar, it is probably not worth it in terms of both time and in terms of effective collaboration to respond to each individual use of gen AI. What is likely more effective is generating engagement with the processes behind them. In this case, the relevant initiative is meta:Future Audiences. You can see their stance on gen AI at meta:Future Audiences/FAQ: "The Wikimedia Foundation view of conversational/generative AI specifically is that we (Wikimedians, Mediawiki software developers, and WMF staff) have developed and used machine-assisted tools and processes on our projects for many years, and it is important to keep learning about how recent advances in AI technology might help our movement; however, it is equally important not to ignore the challenges and risks that commercial AI assistants may bring not just to our model of human-led knowledge creation and sharing, but to the entire ecosystem of digital knowledge." I stated somewhere during the discussion of meta:Future Audiences/Generated Video that there have been some flawed risk considerations, for example that "Experiment" (quoting to indicate this is the terminology they use, not a scare quote) page has a subsection on the risks of associating Wikipedia with TikTok, but nothing on associating Wikipedia with generative AI. (I might add that the first two bullet points at meta:Future Audiences seem to pose contradictory lessons, possibly worth digging into.) Now, what I haven't figured out and what perhaps we haven't worked out as a community is how to effectively channel feedback about broader themes rather than individual activities, and then perhaps more importantly how we remain continually engaged on that end. Say that the RfC on a statement on AI comes to a consensus, what happens next? It's quite a hard question as to how something as amorphous as en.wiki can be represented in these processes. The Future Audiences team has meetings every month, is an attendee there from en.wiki going to be representative? Should we be proactively trying to figure out statements here for such meetings in advance? How would that be most collegial/effective? A further complication is that the WMF is also not a monolith, the meta:Reading/Web team for example which is looking into the gen AI Simple Article Summaries is a different team with its own projects. Should we use this noticeboard to figure out statements that can be transferred to meta, or does that fall down as meta threads are also a discussion? We sometimes contribute to community wishlists, we have individual members who engage, but do we as a community have an overall approach? I'm rambling slightly, and I know some would prefer we did not have to engage, but we do have to and given the historical difficulties in communication maybe we could think of some ideas to create something a little more sustained. CMD (talk) 07:57, 17 June 2025 (UTC)[reply]
I think engaging is the only way forward for folks on the teams to know what the communities take on this matter is. Not engaging never was (and still is not) the answer especially if the expectation is for the WMF to reflect the views of the community.
I can/will try to be around during the next call for Future Audiences whenever that is but I don't think "proactively trying to figure out statements here for such meetings in advance" is the way to go in these kinds of situations, rather the idea would be for the enwiki representative to act as a steward/helpful member who is able to vouch for and provide context for the team's decisions while also guiding the team to not make major policy missteps and provide stewardship on where and when to ask feedback.
My understanding is that the short videos were mostly AI generated, in that the AI did the writing and the voicing (so to speak). I don't recall if the AI chose the images, or whether the final cut was done manually. CMD (talk) 08:37, 17 June 2025 (UTC)[reply]
@Sohom Datta & @Chipmunkdavis: to create these videos, we use AI to do an initial cut of selecting some images and text from a target article + "hook" (which either comes from DYK or we write ourselves) and summarize the text into a 30-secondish-length video. Members of our social media team then review and make changes to this first draft (ensuring that the summarization of facts from the article is correct and has the appropriate tone, selecting different images from the article or Commons if needed, etc.) before posting. The narration is indeed generative text-to-speech, though we've also gotten some of our staff to supply narration for a few of these. This use of AI helps us greatly reduce the time/cost to make these videos. We're also very happy to feature community-created content on these channels and have published several (example from the folks at Wikimedia Armenia). These take more time & effort, but in the longer term we'd love to get a bigger ratio of community faces to "fun fact" explainers on these channels, so if you or anyone you know is interested in creating some short video content, please get in touch! Maryana Pinchuk (WMF) (talk) 14:34, 17 June 2025 (UTC)[reply]
Creating an AI generated image for social media doesn't bother me. As I said in another WMF related thread, enwiki only has so much political capital, and we should use it wisely, i.e. making a stink only about issues that are truly worth it. āNovem Linguae (talk) 10:59, 17 June 2025 (UTC)[reply]
This is definitely true and we shouldn't be getting pissy everytime the WMF does anything outside of "make enwiki better". Is "AI" (read: chatgpt and LLMs) bad? 100% without a doubt. But if its used on a platform like Roblox, then I really don't care. Roblox is a cesspool anyway. Trying to connect with Gen Alpha and introduce them to Wikipedia (preferably as editors) is a good goal and is something that the WMF should be working on. JackFromWisconsin (talk | contribs) 04:02, 20 June 2025 (UTC)[reply]
Hi @Weirdguyz, member of the Future Audiences team here! TBC, the cover image for the Roblox game was created by the lovely humans in our Brand Studio team, not AI. The game itself also doesn't involve any generative AI imagery. I can understand the confusion, though, given the (for lack of a better word) "robo-blocky" nature of the Roblox aesthetic. Maryana Pinchuk (WMF) (talk) 14:15, 17 June 2025 (UTC)[reply]
@MPinchuk (WMF): Forgive me for being cynical, but I have both seen too many AI-generated images, and played too much Roblox myself (I am quite familiar with the visual style of Roblox, going back over a decade...) to truly believe that generative AI didn't play even a small part in the creation of the cover image without any evidence. Just to illustrate what concerns me most, the design on the bottom of the shoe that can be seen exhibits many of the hallmarks of generative AI images, where it knows vaguely what it is meant to look like, but cant quite get the details correct, so it ends up with lines and structures that don't really go anywhere or don't match correctly. If any insight into the design process for the image could be shown that would be wonderful, but I completely understand that there are limitations to what can be made public. Weirdguyz (talk) 15:05, 17 June 2025 (UTC)[reply]
@Weirdguyz My apologies, I misunderstood your original question (I thought your concern was about whether we used AI in the design of the game itself, which we didn't) and I didn't address what the process looked like for making the Roblox marketing image specifically. For us, the team responsible for making the Roblox game, the process was: we needed a cover image to use in Roblox and in the social media posts about it that would convey the feel of the game and match the Roblox aesthetic, so we asked our Brand team (who are professional designers who make other marketing materials for our social channels) to help us. They provided a few different ideas, we workshopped which ones we liked and then chose the final design concept together, which Brand then refined and finalized. Honestly, I don't have insight into exactly what tools were used to create or refine the image, and the designer is currently out of office, but it met our needs of conveying gameplay, looking Roblox-y, and being the right size & resolution for social channels.
(Also: cool to hear that you're an avid Roblox player! Have you had a chance to play our game? Any thoughts/feedback? We're currently working on some refinements to help with stickiness and learning, i.e., adding some knowledge quizzes to the gameplay ā would love to also get your feedback on those changes once those are out in a few weeks.) Maryana Pinchuk (WMF) (talk) 18:22, 18 June 2025 (UTC)[reply]
@MPinchuk (WMF) Very confusing. Why does the WMF think the community wants it to develop Roblox stuff? If that isn't the case, why does the WMF think Roblox players, who are between 7 and 13 years old are a good demographic to target? Why in this way? How much money and time did this cost? How many billable hours? How will the return on investment be calculated? This seems like a massive waste of time for unclear (no) benefit. And Roblox is truly evil. https://www.youtube.com/watch?v=_gXlauRB1EQPolygnotus (talk) 16:09, 19 June 2025 (UTC)[reply]
7-13 year kids today will one day become 16-17+ year old who might edit Wikipedia (or atleast have a positive association with Wikipedia from a early age). Even if the community did not explicitly ask for a Roblox game, there is implicit consensus on allowing the WMF to experiment and try to attract contributors to the project. I assume this is being thought of as a Gateway drug instead of a thing unto itself. Sohom (talk) 19:11, 19 June 2025 (UTC)[reply]
Also this is explicitly important thing to do since more and more companies keep summarizing our info and conveniently forget to link to us decreasing the ability to convert folks into editors. Sohom (talk) 19:14, 19 June 2025 (UTC)[reply]
@Sohom Datta:7-13 year kids today will one day become 16-17+ year old who might edit Wikipedia Agreed. But then it would possibly be more efficient (and cheaper) to reach out to them when they are 16-17+? Even if the community did not explicitly ask for a Roblox game, there is implicit consensus on allowing the WMF to experiment Maybe. But when I experiment I don't just randomly smash rocks together to see what happens; I have a hypothesis that I want to prove or disprove to build on underlying knowledge I have acquired over the years. And since I don't start every experiment at zero it is reasonable to ask things like: "What were your assumptions? Why? How will you determine if this was a success?". I assume this is being thought of as a gateway drug A debunked theory is perhaps not the greatest comparison; but I get what you mean.
Also this is explicitly important thing to do since more and more companies keep summarizing our info and conveniently forget to link to us decreasing the ability to convert folks into editors. That genie is out of the bottle. It would be weird to suddenly start demanding attribution. And using an LLM effectively "whitewashes" the use of licensed and copyrighted material. Polygnotus (talk) 21:38, 19 June 2025 (UTC)[reply]
If you know of an effective way to reach 16-17yos, please suggest it as I'm pretty sure anything slightly likely to work will have a good chance of being tried out. I believe the team tracked retention after the first play and stickiness of repeat players as metrics for the initial deployment, although I can't find the report. CMD (talk) 02:48, 20 June 2025 (UTC)[reply]
@Chipmunkdavis I think that the entire assumption that the kind of people we want are unaware of Wikipedia's existence by the time they have reached 18 is flawed (in the western world). Kinda difficult to keep a "compendium of all human knowledge" a secret from nerds; especially when Wikipedia is usually the top result for any search query on Google.
If you know of an effective way to reach 16-17yos, please suggest it Wikipedia contributors are a very specific kind of people. Marketing companies exist who specialize in this kinda thing.
I think the main problem is not brand recognition, but the fact that Wikipedia is shit at converting readers to editors and our tendency to bite even good-faith newbies. The whole set of uw- templates has depersonalized communication and has made human connection even more infrequent. Another problem is that we encourage children who are new to Wikipedia to do vandalfighting which results in them reverting a lot of goodfaith contributions. Polygnotus (talk) 03:16, 20 June 2025 (UTC)[reply]
I would guess the assumption is more that finding a way to better show the backend (in this case, the web between articles) might make people more interested. This is not a new discussion, and no-one has really figured out a 'solution'. New ideas are much more helpful that saying a current one might not be maximally effective. CMD (talk) 03:20, 20 June 2025 (UTC)[reply]
@ChipmunkdavisNew ideas are much more helpful that saying a current one might not be maximally effective. That makes little sense. There are many situations in which an old well-known solution to a problem is superior to whatever new stuff you can come up with. Dismissing all ideas that aren't "new" is unhelpful at best.
Saying that a new bad idea is a bad idea is helpful because people can stop wasting time and money and ideally it would prevent us from making the same or similar mistakes over and over again. And if you read carefully you'll see I also explained why the idea is bad and provided both superior alternatives and advice that could be used to ensure that future plans would be better. Polygnotus (talk) 03:37, 20 June 2025 (UTC)[reply]
I did not find your explanations convincing, especially as part of it seemed to rely on there not being any hypothesis. The advice going forward was also quite generic. We don't have an "old well-known solution" here. Nobody has dismissed all ideas that aren't "new". If I was to start somewhere my thinking is that a good part of the issue may be "known", and that the WMF should be doing way more regarding monitoring and evaluating affiliate actions to figure out what is "known". CMD (talk) 03:44, 20 June 2025 (UTC)[reply]
@ChipmunkdavisI did not find your explanations convincing I can explain stuff, but I can't understand it for you. We don't have an "old well-known solution" here. Yes we do, and I mentioned it already. Nobody has dismissed all ideas that aren't "new". See straw man. Polygnotus (talk) 03:48, 20 June 2025 (UTC)[reply]
Is the underlying assumption here that I did not do that when actually writing the reply? "Dismissing all ideas that aren't "new" is unhelpful"->"Nobody has dismissed all ideas that aren't "new"" is almost as close as can be. If the discussion is going to be claims that a direct reply is a strawman coupled with swipes about understanding, then it is not going to be lead to any productive outcome. CMD (talk) 03:58, 20 June 2025 (UTC)[reply]
@Chipmunkdavis I do not know what you do or don't do. I do not work at one of those 3 letter agencies and therefore all I know about you is what you have written on your userpage, which is not much. Perhaps we both like chipmunks? You seem to interpret the sentence Dismissing all ideas that aren't "new" is unhelpful at best. as "You are dismissing all ideas that aren't "new" which is unhelpful at best." but that was not the intended meaning. If it was I would've written that. In my experience most goodfaith people who disagree with me either misunderstand me or do not have (access to) the same information. Especially in cases like this, where it is unlikely that goodfaith people have wildly diverging opinions. Polygnotus (talk) 04:04, 20 June 2025 (UTC)[reply]
I interpreted "Dismissing all ideas that aren't "new" is unhelpful at best" as being related to something written prior in the conversation, but not necessarily by me ("You"). My reply "Nobody" was a general reference to all participants of the conversation, not just my comments. I don't think the Roblox experiment will be successful either, but it is relatively small, and does not impede editing or the direct experience of Wikipedia. If I had a better idea that fits the mandate of the Future Audiences team, I would raise it with them. Alas, I do not and right now only have my critical comments about the inherent conflict in their core findings and my related former comment about how their risk assessments have a substantial gap. I don't think either of these would impact the Roblox experiment anyway, and am quite happy for WMF to run relatively safe experiments even if they fail. (My shameful secret is that I have no unique affinity for chipmunks, as inherently valuable as they are, I'm simply stuck in decades of path dependency.) CMD (talk) 04:13, 20 June 2025 (UTC)[reply]
@Chipmunkdavis Are you familiar with Minecraft's redstone? The kinda kids who built computers out of them are the kind we want. But they'll probably already know of Wikipedia. I strongly believe that focusing on user retention makes more sense than focusing on user acquisition at this point.
I hope we can establish the casual redstoners who just built a door as well as the ones who run Pokemon in Minecraft. I find that cheek pouch statement hard to believe. CMD (talk) 05:23, 20 June 2025 (UTC)[reply]
In marketing speak, there are brand awareness campaigns and remarketing campaigns. Its primary utility, which is to maintain the brand awareness, which to many people would seem inefficient as it is typically more spray (for awareness) than pray (for returns). As a brand awareness campaign, it is a long shot, but if a few years down the road and some new editors go 'yeah, Roblox! There was that Wikipedia game. I played that.' we know it had done it's work. For the efficiency that you sought, it would usually be remarketing campaigns where the marketers know that what audience to tap on, and what marketing message to design for (i.e. remember the Wikipedia game in Roblox? Here's how you can contribute to Wikipedia.). There is no guarantee that the older kids know Wikipedia in the same homogeneous manner(s) than that of the brand awareness campaigns. ā robertsky (talk) 06:38, 20 June 2025 (UTC)[reply]
It's so sad to see the reputation of Wikipedia, built over so many years by volunteers working every day, squandered by the WMF's bad decisions without even consulting the community Ita140188 (talk) 12:27, 18 June 2025 (UTC)[reply]
Would love to see proof of our reputation being tarnished in any way by this. This roblox game has literally nothing to do with the editing process over here yet people are treating it like a thermonuclear bomb. Its a silly kids game. Thats it. Its not that deep. JackFromWisconsin (talk | contribs) 04:07, 20 June 2025 (UTC)[reply]
@MPinchuk (WMF): Great job! Any chance the game will be open-source?
Roblox has a lot of young people who also enjoy learning to code. Since the WMF isn't making the game for profit, you might end up with a competitive advantage by allowing the same people who like the game to contribute to it.
I am on Roblox, and I'm currently on a 17 day edit streak and well on my way to EC. I think, yeah, we should have this game, and it should be about building things, and others can edit your builds, like here! Starfall2015let's talkprofile08:04, 24 June 2025 (UTC)[reply]
Tech News: The Chart extension is now available on all Wikimedia wikis. Editors can use this new extension to create interactive data visualizations like bar, line, area, and pie charts. The Trust and Safety Product team is finalizing work needed to roll out temporary accounts on large Wikipedias. More updates from Tech News week 23 and 24.
New Engagement Experiments: We're testing out WikiRun, a fun game that lets you race through Wikipedia by clicking from one article to another, aiming to reach a target page in as few steps and in as little time as possible! It's an experiment to explore new ways of engaging readers. Give it a try and let us know what you think on the talk page!
WikiCelebrate: How one librarian brought Wikipedia into the classroom and beyond: this month we celebrate Loretta.
Wikimedia Research Showcase: The next showcase will center around the theme of "Ensuring Content Integrity on Wikipedia" and will take place on June 18 at 16:30 UTC.
Resource Support: Resource Support pilot project is now open to requests. This is a pilot project which aims to support Wikipedia content editors in obtaining resources that they need to improve content on Wikipedia.
Global Advocacy: The Global Advocacy team will be representing the Wikimedia Foundation at several events in June and July ā including hosting an edit-a-thon during UN Open Source week and running a booth at the Internet Governance Forum.
For information about the Bulletin and to read previous editions, see the project page on Meta-Wiki. Let askcacwikimedia.org know if you have any feedback or suggestions for improvement!
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]
Percentage of edits (yearly and total) made by members of each user group
Is there a way to compile this info from the existing statistics? I am curious about the proportion of edits from each group (anonymous, autoconfirmed, extended confirmed, etc.) CVDX (talk) 23:10, 20 June 2025 (UTC)[reply]
@CVDX, I suggest that you ask at Wikipedia:Request a query, and then put the answer in Wikipedia:Wikipedians (and/or other pages) so other editors will be able to find the answer later. You might need to make a few more decisions (e.g., whether you want to check only the article space, what about bots, what about AWB/Twinkle/scripts, etc.). WhatamIdoing (talk) 23:44, 20 June 2025 (UTC)[reply]
I agree. It looks like they have an easy way of figuring out what groups a user was in at a given time, which is difficult to do from the live database replicas for a single user and entirely impractical to do in bulk. āCryptic01:34, 21 June 2025 (UTC)[reply]
Looking for a document on editor retention in function of account age
I'm 90% it was the product of a WMF project. IIRC: It was shaped like a triangle of squares, colored from green to red. One of the axises was the year/month of account creation; the other was, for a given date, the probability that the account was still active. I came past it around march of this year, but I can't find it anymore. Does that ring a bell to anyone? Thanks, ā Alienā3 3 317:07, 21 June 2025 (UTC)[reply]
My perspective is the same it's always been - I'm an impassioned "no" on getting rid of ITN or making the changes that have generally been suggested for the section. In fact, I actually think much better about the state of ITN lately. DarkSide830 (talk) 19:05, 21 June 2025 (UTC)[reply]
That prior discussion (from 6months ago), is the usual result when there are seemingly odd decisions at ITN about what to post or not post that come up every once in a while. Since then, while there's been a few couple similar incidents, I'm not seeing anything that suggests that there needs to be any change here. That prior argument on abolishing ITN is just one of those knee-jerk reactions that I don't think really still has legs now. ITN is not perfect, by any means, but the step to abolish it is just too far. Masem (t) 19:07, 21 June 2025 (UTC)[reply]
I'm still opposed to "abolishing" ITN. As an editor who occasionally checks the main page (with From today's featured article and In the news being the only two sections that I read or skim over) and who isn't involved with the behind-the-scenes stuff of ITN, ITN seems pretty much the same as it did six months ago. And that's not necessarily a bad thing. Some1 (talk) 19:41, 21 June 2025 (UTC)[reply]
ITN should be canned as it is still quite dysfunctional. Just look at its current state ā it's got nothing about the Iran-Israel conflict even though this is all over the news. Instead, it's leading on a hockey game that happened days ago. This pathetic productivity arises because of poor attendance. There was just one nomination today and that has had zero responses. That's because it's another sporting event that few are interested in. Yesterday there was just a single RD nomination and that only got one response and so hasn't been actioned. The day before that there were zero nominations. You have to go back four days to find a nomination that's getting any attention. That's about the hot topic of Iran-Israel but seems stuck too. The latest comment plaintively asks, "what's taking so long?" So, the big problem is that ITN's process just doesn't work. Every other main page section posts new content every day, regular as clockwork. ITN is supposed to be the most topical and timely but it isn't. This is not a fundamental difficulty because the Portal:Current events posts lots of fresh news content every day. The problem is that ITN has dysfunctional processes which prevent it getting things done. It has had years to reform but the incumbents with power are in denial. It should therefore be deprecated so that alternatives can be tried. Andrewš(talk) 20:12, 21 June 2025 (UTC)[reply]
1) news of major significance does not happen every single day, and 2) quality is still a requirement which is what holds up most nominations that are otherwise agreed on. Neither of those can be changed (the first we can't control, and the second is a requirement of the main page) Masem (t) 23:14, 21 June 2025 (UTC)[reply]
Wikipedia is not a newspaper, and since there's a requirement for quality for a featured article link, we're not going to rush a breaking story until there's consensus to post. (and fwiw, the last events in Iran did get posted about 12 hr after its nomination) If just want to push out breaking news stories, go to Wikinews which is built for that purpose. Masem (t) 12:56, 22 June 2025 (UTC)[reply]
A bit of patience goes a long way. Both the American strikes on Iran, as well as the Israel-Iran Ongoing link are now live. What more do you want? Reaching consensus takes its time and sometimes quality issues prevent a quick posting. Khuft (talk) 13:47, 22 June 2025 (UTC)[reply]
Oppose, being an internet encyclopedia that is editable by anyone at any time leads to us having articles on current events as they happen. And as such people like coming here to find them. I'm not convinced that this process should be removed from the main page. I am also OK with it "lagging behind" major news outlets -- we aren't journalists presenting breaking news. We simply are sharing newly minted encyclopedia articles about recent events, not a live feed of what is happening minute by minute. JackFromWisconsin (talk | contribs) 02:34, 22 June 2025 (UTC)[reply]
Comment: I asked above if anything had changed in the last 6 months given the calls for reform in the last RfC. I didn't intend to start an RfC now and I don't think bolded !votes are helpful at this point. voorts (talk/contributions) 02:49, 22 June 2025 (UTC)[reply]
I attend ITN regularly and haven't noticed any significant structural change in the last six months. The news during this period has been dominated by the Trump administration's "flooding the zone". ITN has posted very little of it as there are many ITN regulars who seem averse to US news. Andrewš(talk) 06:25, 22 June 2025 (UTC)[reply]
I suggest starting an RfC now (if you plan to initiate one in the near future), because this discussion is starting to devolve into a general complaint thread about ITN. Some1 (talk) 12:56, 22 June 2025 (UTC)[reply]
Not sure where you see that... there are currently two users complaining about ITN, with all the others thinking it's fine. Khuft (talk) 14:40, 22 June 2025 (UTC)[reply]
Agreed. It also hasn't been six months yet (and I'm also not inclined to start the RfC exactly at 6 months since that would be in the middle of the summer). I'm starting this discussion now so that editors can present evidence and maybe we can come to some sort of assessment of what's happening at ITN and figure out if there are ways to fix things without the nuclear option. voorts (talk/contributions) 15:07, 22 June 2025 (UTC)[reply]
As far as I can tell, ITN still uses editor's feelings to decide what's "significant", providing readers with incredibly visible content that's unbalanced in a way we try to prevent elsewhere on the project. It still encourages the creation of articles about random news stories themselves as opposed to updating articles about notable subjects. And it still occupies space that could be used to showcase higher quality content or a panel that recruits new editors directly. Thebiguglyalien (talk) šø04:47, 22 June 2025 (UTC)[reply]
I'm not asking to rehash the old discussion. I'm asking for a 6 month update. Masem, DarkSide, etc. have their views, but characterizing the previous critiques of ITN as annoyance with seemingly odd decisions and knee-jerk reactions is quite dismissive. The issue here is that a large plurality of editors found ITN to be operating outside of the usual rules of consensus, so much so that the closers noted that there was no consensus to even keep ITN around. You can all continue to say ITN is doing fine, but I think honest reflection on what the rest of the community has said about ITN would be more valuable. If that's not possible from the ITN regulars, we may very well be on the path to abolishing ITN. voorts (talk/contributions) 15:09, 22 June 2025 (UTC)[reply]
Except that this is what has happened for as long as I've been contributing at ITNC; something does or doesn't get posted, someone yells the system is broken, and while a few times this has let to meaningful change (the RD system, where any notable death is automatically considered for the RD line), most of the time its just ends up that it works by consensus, and at times consensus can be fallible, and then life goes on. Masem (t) 15:33, 22 June 2025 (UTC)[reply]
I know a couple of editors are enthusiastic about getting rid of ITN, but is that what the millions of casual readers want? For the "community" to get rid of ITN? The main page receives ~5 mil page views daily[33]; it would be great if the WMF could conduct a survey to gather feedback/insight from casual (non-editing) readers on what they would like to see on the main page. Their input on this is, IMO, far more valuable than that of editors. (And I can't help but think that the vast majority of these casual readers have no issues with having ITN on the main page or with ITN itself.) We should also keep in mind that what we, as editors, want or don't want on the main page may not necessarily align with the preferences of casual readers. Some1 (talk) 16:26, 22 June 2025 (UTC)[reply]
A survey would be interesting, and I suspect that ITN would see a decent amount of support just because it's the status quo. But if a survey were to happen, I'd also want to see whether readers think it's representative of the most relevant news in the world, what types of things it covers too much, and what they feel it doesn't cover enough. Thebiguglyalien (talk) šø16:40, 22 June 2025 (UTC)[reply]
I highly doubt readers want a newsfeed curated based on vibes where the only news that's shown are accidents/storm deaths, wars, elections, and random awards and sporting events. Even if they did, readers can't help with the way that ITN operates, which is what most editors take issue with. voorts (talk/contributions) 17:21, 22 June 2025 (UTC)[reply]
"the way ITN operates"--That's a separate issue from "abolishing" or getting rid of ITN altogether. Editors can always propose ideas for improvement on the WP:ITN talk page (or here at the Village Pump, too). Some1 (talk) 17:36, 22 June 2025 (UTC)[reply]
I know, I participated in that RfC (my !vote was only regarding the "abolishment" of ITN; I didn't have opinions on the other two proposals as I don't participate in the behind-the-scenes stuff of ITN). Am I sympathetic to the editors who suggested those ideas and then had to see those proposals fail? Sure. But there must be more ideas to improve how ITN operates beyond those two proposals, right? Some1 (talk) 18:17, 22 June 2025 (UTC)[reply]
Good questions to ask those who have complaints about or want to get rid of ITN (neither of which applies to me); but I'm actually curious now in hearing suggestions from those who do feel this way and what ideas/changes they have in mind (changes that don't involve simply removing ITN, please). Is there anything specific you'd like to see changed at ITN, Voorts? (asking because I see that you'd !voted to abolish ITN at the RfC) Some1 (talk) 22:00, 22 June 2025 (UTC)[reply]
Articles posted on ITN should be required to follow GNG (which requires secondary sources, not just breaking news) and editors' subjective opinions on importance should be subject to WP:DISCARD when determining consensus. Thebiguglyalien (talk) šø22:47, 22 June 2025 (UTC)[reply]
Why do you think consensus is measured differently at ITN? I have faith in the Admins that regularly rule and post that, in general, they apply the rules in the same way as they do on other parts of the site. (I would also point out that in the vast majority of cases consensus is pretty obvious. It's the handful of controversial cases that end up ruffling feathers elsewhere.) Khuft (talk) 23:14, 22 June 2025 (UTC)[reply]
Every ITN item is posted (or not) based on editors' subjective opinions on importance; there'd be nothing to judge if they were discarded. (example comment from an admin on how ITN operates) Even the ITNR items have such a status through a consensus of editors' subjective opinions on importance at the ITN talk page. Most of the posted events with stand-alone articles likely satisfy GNG at some point, but it's usually impossible for the requisite secondary coverage to emerge so soon after it occurs. Left guide (talk) 00:32, 23 June 2025 (UTC)[reply]
Then either find a way to determine posting based on sourcing or article quality, or abolish ITN. And delete any articles about events that haven't already received requisite secondary coverage. Thebiguglyalien (talk) šø01:21, 23 June 2025 (UTC)[reply]
being able to judge if secondary source coverage exists for an event is going to take longer than a week to know for certain. (And this is discounting the "Reactions" section which for the most part just primary reporting about what leadership figures have said) And using any coverage based metric will bias towards western nations, particularly the US and UK. Masem (t) 12:30, 23 June 2025 (UTC)[reply]
Which means that we shouldn't be posting links to articles about the events themselves. We should be posting links to articles about the affected subjects. That's the encyclopedic content, and that's what's in the news. Thebiguglyalien (talk) šø14:06, 23 June 2025 (UTC)[reply]
It would be great if more editors updated existing article than rushing off to create a new one, but also if we had more nominations that are based on existing articles (for example the current story on the observatory and first light images is what we need more of). There are s a frequent incorrect presumption that an ITN nominee needs to be a sepearate article. That said some events can't easily fit into existing articles, like a natural disaster or a transportation accident, but in these cases it's long term notability is not always clear (like the hot air balloon accident) Masem (t) 14:24, 23 June 2025 (UTC)[reply]
So here we are, re-hashing the same discussion we had last time. Please refer to my comments then. Seems like a waste of my time to "present evidence and maybe we can come to some sort of assessment of what's happening at ITN and figure out if there are ways to fix things without the nuclear option" when the Inquisition has already made up its mind. Khuft (talk) 17:46, 22 June 2025 (UTC)[reply]
That 5 million figure for the main page is a complex artifact which doesn't represent ITN's actual readership. I often check the readership stats for topics in the news and my experience is that an ITN posting attracts about 10,000 readers/day. Most casual readers won't even know that ITN exists as the bulk of the traffic for topics in the news is driven by search engines such as Google. Andrewš(talk) 17:46, 22 June 2025 (UTC)[reply]
No section of the main page is meant to drive views. It is meant to highlight quality work that might be of interest to readers that start at the main page, so that will mean featured articles will likely see increased traffic from the main page, but its silly to pretend that readers go to the main page and then try to navigate without any searching to find a topic of interest they actually want. So we should absolutely not care about the impact on pageviews due to an item being features in ITN. Masem (t) 17:58, 22 June 2025 (UTC)[reply]
I reject the premise entirely. There is no single type of reader. Trying to say that readers collectively behave a certain way, or that they do or don't want something, will almost always give an unhelpful result. Thebiguglyalien (talk) šø18:05, 22 June 2025 (UTC)[reply]
I'm not saying that there are no readers that come to WP to browse or get caught in the Wikihole of knowledge, but the bulk of WP's visitors are either via search engines directly to the article they want, or get to the main page, hit the search bar, and go to the target page. The few extra hits that come from those that browse main page links to articles are not a significant route. Masem (t) 12:23, 23 June 2025 (UTC)[reply]
I have come to believe ITN should function more like RD with much less room to keep something out based on a super-notability judgement, with the main driver being article quality. I'm not exactly sure how that would work, but we shouldn't fear posting something that isn't top level headline news around the world. It is very toxic which is partially why I'm not there as much as I used to be. 331dot (talk) 18:12, 22 June 2025 (UTC)[reply]
A probably associated with any issues at ITN is the fact that we have far too much wikiediting that resembles a newspaper and not an encyclopedia. Editors are rushing to make articles about any small event that happens without establishing any long-term significance, which is not appropriate per NOTNEWS nor NEVENTS. Because of that, we need some type of discretion at ITN to limit what news events that are posted, and that's through the use of consensus to decide on such events (in addition to quality checks) as to balance out the lack of any checks at the article creation process. And then the other problem is that we are trying to fight the implicit bias of western and English-language media, which elevate certain national politics and events in the US and UK (and to a degree, Canada and Europe) over the rest of the world. Its not that we can't have national events there, but we need to be fully aware that something that seems minor on the world's stage can be exploded that appears big by mainstream media because it happened in a big US city. We want the smaller stories of significant events at national levels but that aren't from Western countries, and to that point, that's where we typically end up with the lack of any nominations of this type. Masem (t) 12:21, 23 June 2025 (UTC)[reply]
Polygnotus (talk) 04:26, 5 June 2025 (UTC)
Done {{celestial events by month links}}, used on P:astro, forced a width of 65em; I have changed that to max-width 65em; which should have the intended effect of limiting its size without causing horizontal overflows.
Moved from WP:VPR
View all 24 community-submitted tasks that were resolved last week. For example, a bug was fixed that had caused pages to scroll upwards when text near the top was selected. [15]
Courtesy link: User talk:Joe Roe Ā§ An idea 
Wonderful! JayCubby 20:54, 12 June 2025 (UTC)
wikimedia.org know if you have any feedback or suggestions for improvement!