Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The idea lab section of the village pump is a place where new ideas or suggestions on general Wikipedia issues can be incubated, for later submission for consensus discussion at Village pump (proposals). Try to be creative and positive when commenting on ideas.
Before creating a new section, note:

• Discussions of technical issues belong at Village pump (technical).
• Discussions of policy belong at Village pump (policy).
• If you're ready to make a concrete proposal and determine whether it has consensus, go to the Village pump (proposals). Proposals worked out here can be brought there.

Before commenting, note:

• This page is not for consensus polling. Stalwart "Oppose" and "Support" comments generally have no place here. Instead, discuss ideas and suggest variations on them.
• Wondering whether someone already had this idea? Search the archives below, and look through Wikipedia:Perennial proposals.

Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56

Semi-Administrator right

I believe that there should be an extended level of protection named "Semi-Administrator" that requires a user request their permissions on a WP:PERM page. I believe this should be added because it would prevent WP:PGAME and a possible future WP:INVASION. It would be like requesting WP:TPE or WP:RBK, but instead it gives users the right to edit semi-administrator protected pages which would likely become commonplace in the future due to the expansion of media bias, systematic bias, and political extremism, all leading to increased vandalism. Combined with the reduction of editors, this will cause disasterous effects. Another idea is to make WP:ECP a requested right instead of an automatic one. To reduce request backlog, however, there must be more administrators which means WP:RFAINFLATION needs to stop. 2003LN6 18:34, 18 February 2024 (UTC)

WP:WTF? OMG! TMD TLA. ARG!
I don't think we should worry about anything that has no indication of happening. Permission gaming isn't happening on a large scale, and I'd rather preserve adminship being no big deal. Aaron Liu (talk) 19:44, 18 February 2024 (UTC)

Sounds good, but I still believe a backup plan is good or else admins will have to do mass rangeblocks on pretty much the entire world during an WP:INVASION, which would be quite hostile to newcomers. 2003LN6 05:37, 19 February 2024 (UTC)

I think mass-enabling WP:Pending changes would be a good plan. Aaron Liu (talk) 13:25, 19 February 2024 (UTC)

How about phasing out edit requests in favour of pending changes for any protected pages? This is pretty radical, sure, but it'd make it much easier to propose a change quickly, rather than going through the hassle of putting up the template, etc... This would also make it easier for newcomers to quickly do some copyediting. Cocobb8 (💬 talk • ✏️ contribs) 20:46, 18 March 2024 (UTC)

I feel like this would put too much of a burden on pending changes patrollers. QuicoleJR (talk) 00:42, 19 March 2024 (UTC)

Approving 100 pending changes is much faster than responding to 100 edit requests. It could only require more effort from the community if we got far more contributions (e.g., 100 people willing to an edit under PC vs only 10 willing to figure out edit requests). On the other hand, if we believe what the Wikipedia:Editing policy says about Wikipedia being best when it has the most knowledge, then maybe that's a burden we should try to accommodate, at least to some extent.

BTW, a few years ago, an admin removed semi-protection from a bunch of articles (appropriately selected ones, not those likely to be targeted by spammers or juvenile vandals) and added PC. I believe the increase in activity was negligible. It might be possible to do something along these lines, e.g., to reduce some EC-protected articles to semi+PC. WhatamIdoing (talk) 01:15, 19 March 2024 (UTC)

What's "semi+PC"? Aaron Liu (talk) 01:19, 19 March 2024 (UTC)

I'm not 100% certain what the setup is these days, but I believe that it at least used to be possible to stack protections in a way that would prevent editing by IPs and new accounts entirely, and have PC protection for other accounts. WhatamIdoing (talk) 03:45, 20 March 2024 (UTC)

There is not currently an EC level of pending changes. There is only one level of pending changes at the moment, and a consensus would be needed to add a new one. QuicoleJR (talk) 12:09, 20 March 2024 (UTC)

Consensus would be needed for any of this, so that's not a showstopper. WhatamIdoing (talk) 16:19, 20 March 2024 (UTC)

There used to be another level of pending changes, but there was consensus for its removal. Chaotıċ Enby (talk · contribs) 16:24, 20 March 2024 (UTC)

That would be Pending Changes Level 2. It used the reviewer userright (before extendedconfirmed existed) and locked approval of pending changes to that. It was trialled in 2010 and had failed RfCs to approve it in 2012, 2013, 2014, and 2016 before finally achieving consensus to remove it completely in 2017. Wikipedia:Pending changes#Timeline gives more context. Frankly, now that we have ECP there doesn't seem to be much use for Pending Changes at all anymore. The actual extension (mw:Extension:FlaggedRevs/m:Flagged Revisions) is unmaintained and the WMF has had a moratorium on new installs since 2017. I think it would be easier to get consensus to remove FlaggedRevs altogether than to expand it's usage. The Wordsmith^{Talk to me} 18:45, 20 March 2024 (UTC)

I doubt it. FlaggedRevisions is used on all articles at the German-language Wikipedia. While one might not wish to emulate their overall trajectory, it would is unheard of for any of the larger communities to voluntarily give up any software that allows them to exercise greater control over article content or new editors. WhatamIdoing (talk) 23:10, 20 March 2024 (UTC)

I don't think removing FlaggedRevs is likely, I just think that gaining consensus for expanding its use would be even less likely. The Wordsmith^{Talk to me} 17:25, 27 March 2024 (UTC)

The number of active editors (registered accounts making 5+ edits in a given month) has been stable at the English Wikipedia since about 2013.

@2003 LN6, just in case it was the very old image at the top of the page that made you believe that the number of editors is still declining, I've made an updated image for you.

As you can see, the number of active editors has been stable for 10+ years. There are some seasonal effects, but most months have 36K to 38K registered editors making five or more edits during the calendar month. The English Wikipedia isn't growing, but there is no decline, either.

If you want to see what a decline looks like, then check out the numbers for the German Wikipedia. Other communities, like the Persian Wikipedia, are growing. Overall, across all the languages, I understand that the number of editors was increasing slowly over time, spiked up during the first year of the pandemic, and might be settling down to a natural growth rate again. WhatamIdoing (talk) 07:18, 25 February 2024 (UTC)

I genuinely don't think a hypothetical scenario of thousands of vandals hacking into Wikipedia is a reasonable basis for such drastic changes. Blocking is easy for admins, and, if your hypothetical WikiInvaders can hack into established accounts, what would stop them from also hacking into accounts with that new user right? Chaotıċ Enby (talk · contribs) 13:30, 27 February 2024 (UTC)

I agree. This is highly unlikely, and many of the outlined potential changes are a horrible idea. QuicoleJR (talk) 23:01, 7 March 2024 (UTC)

On the other hand, wikipedia is a free encyclopedia that anyone can edit, and nobody WP:OWNs the content here. I actually doubt that introducing new measures to increase barriers of entry would actually address the bias problems that you raise. It might even have the opposite effect. This would be an interesting topic to study. spintheer (talk) 03:58, 27 March 2024 (UTC)

Have we ever ran a banner explaining the quality topicons to readers?

Hi, y'all! After reading Wikipedia:Village_pump_(proposals)#Proposal:_Remove_the_topicons_for_good_and_featured_articles, some editors say that readers are not aware of what the topicons represent. Has the wiki ever ran a campaign or put up banners explaining what they are? If not, could it be done? — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 21:34, 5 March 2024 (UTC)

Hovering over the icon produces a tooltip explaining what it means, and the icon itself also links to GA or FA. InfiniteNexus (talk) 22:10, 5 March 2024 (UTC)

Generally speaking, readers hate banner messages that get in the way of the information they were seeking. Personally, I feel a banner to explain page status indicators would be overly intrusive. A link to a legend would be better. isaacl (talk) 22:22, 5 March 2024 (UTC)

As above, a banner is overkill. IMO it's obvious and any final concerns should be solved by the tooltip. Aaron Liu (talk) 22:36, 5 March 2024 (UTC)

Well, I support it. The WMF runs banners for fundraising and random non-enwp-related stuff all the time -- giant ones, too -- so I don't think we can act like the presence of a banner is an unwelcome imposition on readers ipso facto. I mean, look at this: meta:CentralNotice/Calendar. Here is what enwp has flying atop the page:

• Awareness of Wiki community run Wiki Loves Folklore International Photographic contest
• Movement Charter Community feedback period
• Movement Charter ratification period
• Ukraine's Cultural Diplomacy Month 2024
• Wikidata Leveling Up Days 2024
• Wikimedia Stewards elections
• International Women's Day/International Women's Month
• Every Book Its Reader 2024 in English speaking countries
• Wiki Loves Monuments 2024
• Some dozen or so fundraising campaigns in different countries

At worst, it's background noise that they're thoroughly used to, and at best, it's something that might actually improve their understanding and skill at using the website -- something for readers -- as opposed to something like e.g. steward elections, that even 99% of editors don't participate in, or the photography contest, which is of interest for photographers and contributors. Not that it's bad to run banners for these things, it's just that I think in practice the bar is pretty low for how relevant something has to be to get a sitenotice. jp×g🗯️ 01:41, 6 March 2024 (UTC)

...and readers complain about them, and users ask for ways to suppress them. And there should always be a way to figure out what the status indicators mean; there are always new readers, and even existing readers should be able to learn about them outside of a time-limited campaign. isaacl (talk) 02:02, 6 March 2024 (UTC)

As one of the people who raised that in said discussion, I feel there's many other aspects of the encyclopedia that would warrant more reader attention, and it seems a bit odd to solely prioritise this. A good amount of people are going to ignore the banner anyway, see banner blindness.

A better idea IMO would be having a running section on the Main Page that cycles through various elements of the encyclopedia that we feel readers should know about. It could go below featured pictures. ― novov (t c) 05:25, 6 March 2024 (UTC)

That's a promising idea: a sort of "tip of the day" but for readers. Certes (talk) 09:43, 6 March 2024 (UTC)

I agree. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 10:06, 6 March 2024 (UTC)

That could be a great idea! Although "featured pictures" is often too low for new readers to see without scrolling, so maybe our new section could be placed higher up instead? Chaotıċ Enby (talk · contribs) 13:46, 6 March 2024 (UTC)

I don't know if that would get support for a permanent spot in the page, but what about a temporary thing? Like, for one month each day has different information in the section and it could be done yearly or something so it doesn't take up too much space all the time. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 14:39, 6 March 2024 (UTC)

There's {{Main page banner}} when you need it. Aaron Liu (talk) 17:12, 6 March 2024 (UTC)

I like this, we hide the inner workings of Wikipedia too well from the viewers in a time where we are losing editors. ♠ Ca ^{talk to me!} 01:05, 13 March 2024 (UTC)

What are the inner workings that viewers don't know we feel they should know the most? — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 10:31, 13 March 2024 (UTC)

Not sure where to start editing? Create an account, and we'll offer you a bunch of easy tasks to get started! Ghosts of Europa (talk) 16:57, 14 March 2024 (UTC)

OOOOOOOOh! I think actually something that could get a lot of support in the community is running some kind of recruitment drive with tips of the day as part of it. Not sure how it could look doe. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 19:10, 14 March 2024 (UTC)

That's a pretty good text! Probably combine it with File:Wikipedia-logo-banner-ihojose.png as the image on the left and link create an account, while linking "a bunch of easy tasks" to either Wikipedia:Task Center, Template:W-graphical, or, if we're feeling adventurous, Wikipedia:Dashboard. Aaron Liu (talk) 19:22, 14 March 2024 (UTC)

Active editors at the English Wikipedia 2001–2023

@Ca, the English Wikipedia has not been losing editors for a decade now. WhatamIdoing (talk) 01:35, 19 March 2024 (UTC)

Thank you for the updated graph! All of the editor count graph I've seen has been horribly outdated. It's nice to see the editor count is at least not in decline. ♠ Ca ^{talk to me!} 00:18, 20 March 2024 (UTC)

Just wondering, why has there been a yearly peak of active editors in March in every year since 2014 (except 2020)? Sungodtemple (talk • contribs) 01:12, 23 March 2024 (UTC)

Summer vacation? Aaron Liu (talk) 01:21, 23 March 2024 (UTC)

Summer vacation is July and August in most places (June and July for the US), and editor activity goes down then (just like it goes down on weekends and holidays).

March is when International Women's Day happens, and there are a lot of organized events around that, so maybe that's relevant? WhatamIdoing (talk) 04:17, 27 March 2024 (UTC)

Spring break is another possibility. Some1 (talk) 22:54, 27 March 2024 (UTC)

Onboarding for new users?

This was promted by a wikimedia-l thread

New users are given zero guidance and then get yelled at when the break the rules they didn't know about. Therefore, I propose that, after sign up, we make a page (perhaps something like H:INTRO?) that we then direct new signups to

Two questions I have:

1. Will new users simply click away without learning anything?
2. How much will this help?

As it stands, the current onboarding procedure is basically nothing: just set them out there and yell at them when they mess up. Something needs to change and I hope my proposal will generate some discussion on how to make the onboarding process better. NW1223<Howl at me•My hunts> 01:37, 7 March 2024 (UTC)

The current onboarding procedure is to use Wikipedia:Welcoming committee templates and new users also get a newcomer home (see Wikipedia:Growth Team features). I'm pretty sure automatically sending new users welcome templates is at Wikipedia:Perennial proposals. Aaron Liu (talk) 02:00, 7 March 2024 (UTC)

Wikipedia:Perennial proposals#Use a bot to welcome new users is probably what you were thinking of. Anomie⚔ 12:40, 7 March 2024 (UTC)

Aaron highlighted the Growth team features. To summarize them, new users get Special:Homepage as their base-camp (you might have to activate it in your preferences). There, they have access to selected help links and,

Some wikis also post a message at talk pages. From what I observe*, a successful welcome message requires the following:

• it is a real message, not a block of links
• it is clearly signed by a real human
• it includes a clear indication "contact me if you have any question"
• they are posted before the user make an edit (so that they can ask a question to the user who welcomed them**).

Messages consisting of blocks of links are not successful (a known issue), in particular when the message look like a banner or something else than a discussion. Signatures have to be clear, as the way we format our messages on wikis is not something the rest of the works is used to.

* Of course, what I observe is not a proof of anything, but I observe a lot of newcomers/experienced users at a lot of wikis since a long time. :)

** This is how Mentorship works: you get a name to contact at Special:Homepage (but unfortunately, at your wiki, not everyone gets one as we don't have enough mentors).

The discussion at wikimedia-l was more focused on explaining the rules while editing, which is also something the Wikimedia Foundation works on.

Trizek_(WMF) (talk) 15:09, 7 March 2024 (UTC)

Since so many recent changes have the "newcomer task" tag, I think it's enabled by default for newcomers. Aaron Liu (talk) 15:28, 7 March 2024 (UTC)

It is default for all new accounts, correct.

But Mentorship is only available to 50% of new users for the reasons I explained, and a key feature to discover editing, Add a link, is still missing at your wiki.

Trizek_(WMF) (talk) 16:48, 7 March 2024 (UTC)

or we could just not yell at them... It is my personal opinion that a lot of our users have themselves forgotten they are on wiki that anyone can edit. —TheDJ (talk • contribs) 21:48, 7 March 2024 (UTC)

I wish our policies had TL:DR versions of them too because some of them are very lengthy and I have no doubt that that's put some people off from editing here. ♠JCW555 (talk)♠ 22:16, 7 March 2024 (UTC)

Most policies have {{nutshell}}, a summary, on top, and welcome templates already link many summaries, such as Help:Introduction and Help:Getting started. Aaron Liu (talk) 22:51, 7 March 2024 (UTC)

Although experienced editors do make mistakes from time to time, in my experience, the vast majority of new editors who get "yelled at" are spammers, self promoters, POV pushers, axe grinders, conspiracy theorists and others whose manifest goals are not in alignment with improving this great encyclopedia. As I see things every day on the firing line, any editor who comes here with a genuine intent to neutrally improve this encyclopedia is almost always welcomed with open arms. So, when an editor puts forward vague assertions of "yelled at", I expect diffs and specific cases. Who in particular got "yelled at", and why? Cullen328 (talk) 09:49, 9 March 2024 (UTC)

When I see an edit that degrades the encyclopedia, I revert it, and usually use Twinkle to leave a message on the user's page, with or without an additional comment. I think that kind of response is what some are calling "shouting". I will not leave unreverted an edit that damages the encyclopedia, no matter how well intentioned. I think the lowest levels of the Twinkle warnings are benign enough. I use the stronger versions of Twinkle warnings when a user repeats the same kind of edits after being warned. I block users who repeatedly over a short period of time make obviously problematic edits after being warned. It may be that new users don't see messages on their talk pages, but that is not a reason to allow them to continue to make edits that degrade the encyclopedia. Donald Albury 14:13, 9 March 2024 (UTC)

@Cullen328, how would you describe to an external observer how English Wikipedia welcomes good faith users with open arms? I'm asking it as finding how bad faith users are treated is easy (Donald gave a good example above), but examples of how one deals with good faith users is more difficult to find.

Actually, what I observed over the years is that vandalism or damageable edits get a warning message, while good faith edits are just left as they are, with no message, because they fit what is expected.

Thoughts? Trizek_(WMF) (talk) 15:18, 10 March 2024 (UTC)

Sometimes they get a thanks and they get a welcome if they're a new user. Aaron Liu (talk) 15:29, 10 March 2024 (UTC)

And {{cookies}}! Chaotıċ Enby (talk · contribs) 17:59, 10 March 2024 (UTC)

Trizek (WMF), we have places like the Teahouse and the Help Desk where new editors can get assistance, and they are easy to find given the amount of traffic they get. I have over 10,000 edits to the Teahouse and over 1,200 to the Help Desk, so I have considerable experience helping and encouraging new editors. Many new editors come to my talk page asking for advice. and I have 5,600 edits there. I agree that bad edits and those that make them get more attention in general than good editors making uncontroversial typo fixes, converting bare URLs into bibliographic references, and reverting vandalism. If I notice particularly good work from a new editor, I will definitely thank them. I think that a brief, personalized compliment is better than 100 "welcome templates". The analogy that comes to mind is that few people give detailed thanks to people doing routine work. Few people go into a McDonald's and lavishly compliment the people sweeping the floors, taking the orders and packaging up the french fries. We just treat them politely, with a "thanks" to the order taker being about the extent of it. Cullen328 (talk) 20:09, 10 March 2024 (UTC)

Trizek (WMF), I don't know if the WMF collects any statistics, but I wouldn't be surprised if the English Wikipedia gets more than its fair share of bad faith users, making experienced editors more cynical. At least if I were a spammer, self promoter, POV pusher, axe grinder, conspiracy theorist or any other bad faith user I'm sure I would prefer to target the largest Wikipedia that has the largest readership. Phil Bridger (talk) 20:35, 10 March 2024 (UTC)

@Aaron Liu, is "sometimes" good enough? :)

@Cullen328, thank you for the details. I think volunteer-me have the same profile as yours, but at my wiki. I don't really count places mike the Help desk or the Teahouse as proofs of being welcomed, as these are places you have to discover (or at least find the link to them). Thanks are apparently only for "particularly good" edits as you said. Messages are often perceived as costly to create. What would you (any of you) do to show a user that they edit is going in the right direction, at low cost?

@Phil Bridger, I'd say the bigger the wiki, the more likely it is to attract people. But as I read it quite often, I kind of think there is a perception of a mass of bad faith users that damage things, while only a few users do it right. I'm not sure this is true: maybe there is a perception bias, as badly behaving users are way more visible than users who do things the right way, don't you think?

Trizek_(WMF) (talk) 00:28, 15 March 2024 (UTC)

I meant that they sometimes get a thanks and nearly always eventually get a welcome. Aaron Liu (talk) 00:31, 15 March 2024 (UTC)

examples of how one deals with good faith users..

• How do we welcome new medical editors?

--Dustfreeworld (talk) 02:55, 19 March 2024 (UTC)

I'm assuming that, in this context, you're using "getting yelled at" not to mean overt incivility (which is against policy), but rather more subtle snubbing, e.g. ignoring messages or responding curtly. I honestly think that this encyclopedia could improve if this just didn't happen at all, regardless of the person. spintheer (talk) 03:43, 27 March 2024 (UTC)

Trizek (WMF), there used to be a bot called HostBot that would send welcoming Teahouse invitations to new accounts in good standing that had made 10 edits within a few days. Sadly, the bot operator, User:Jtmorgan, is far less active in recent years, and the bot no longer operates. Maybe you can look into that.

If you take a look at the Home Page, you will see that the first prominent word is "Welcome". The prominent phrase "anyone can edit" links to Help:Introduction to Wikipedia. There is a prominent link to Help:Contents on the Home Page, which links to many other help pages. Further down are links to the Community Portal, the Village Pump, the Teahouse, the Help Desk, the Reference Desks, and so on. In other words, the page that new editors first see shouts "Welcome! How can we help you?" I know about banner blindness but I doubt if it would make much difference if we displayed "WELCOME" in bold, bright orange all caps, flashing and flickering. It wouldn't help and it would make us look ridiculous.

Most new accounts do not ever edit. Of those that do, most of those make only a handful of edits and then lose interest. Of those that continue editing, a significant percentage have motivations incompatible with the goals of the project as I described above. Of those who really want to improve the encyclopedia, many are here to create or improve one or two articles about topics of great interest to that person, and then they stop editing. Student editors are here to get a good grade, and only a tiny percentage continue after the course is over. People go to edit-a-thons to satisfy their curiosity, meet cool people and get some free food. Only a tiny percentage keep editing.

I have been wondering for nearly 15 years what the positive psychosocial factors are that separate all those types of people who contribute little or no encyclopedic content from the "rare beasts" who make improving this encyclopedia in countless ways an avocation for many years. I cannot answer that question with confidence although I have my pet theories. I hope that the WMF could make that research happen but I do not know.

As an adminstrator, I believe that blocking bad actors like harassers, vandals, spammers and the like is essential, because showing such people the door makes the editing environment more hospitable. And so I am not ashamed to have blocked nearly 10,000 accounts. I think my work in that area makes Wikipedia a more welcoming place. I think I have said enough so I will stop now. Cullen328 (talk) 02:49, 15 March 2024 (UTC)

There's been some research on the psychological profile of Wikipedians. I am not sure you would consider the factors to be "positive", but if memory serves, we are above average for neuroticism and below average for agreeableness. In plain English: we start editing because there's a typo, we would rather be right and have an argument than go along with something that's wrong. We also don't like change. This all aligns with my experience. How about you? WhatamIdoing (talk) 01:53, 19 March 2024 (UTC)

I like change and demand a link to such a study immediately >:( Aaron Liu (talk) 02:05, 19 March 2024 (UTC)

@Cullen328, thank you for your detailed answer. You describe what I would call "passive welcoming": various signs, at various places that convey the idea of welcoming others. At the opposite, "active welcoming" goes more on the way of telling users personally that you can mentor them, thank users for their edits, etc. This is something you do, and I believe it is super important.

It tights to positive reinforcement: someone getting a positive stimulus on their edits are more likely to continue participating. If that positive discourse comes from a human, it has way more chances to be received and appreciated, compared to one coming from an information message on static page.

Following what @WhatamIdoing said or what @Dustfreeworld illustrated above, we, communities, are apparently very good at saying when something gets wrong. Worse, we are very good at qualifying one edit as not good even if just a part of it is not good. Reverting seems to be sometimes easier than fixing up an edit. And I'm not talking of vandals and trolls there: my focus is on users who genuinely came to fix something and saw "be bold" written at various places.

This topic started with the question of onboarding new users, but it is also on how to keep them editing. As we are in the ideas lab, I'm looking for your ideas: what would you (any of you) do to show a user that they edit is going in the right direction, at low cost? What do you miss to encourage users in an easy way?

Trizek_(WMF) (talk) 16:29, 19 March 2024 (UTC)

@Trizek (WMF), thanks for the ping :-) I’m not sure if I can give much useful comment about your questions, because I’m facing issues very similar to those described in the “How do we ... “ discussion myself as well… ...

My problem is, there’s a user who really doesn’t like me. It seems that my edits are being watched. When they think there’s an “opportunity”, they will suddenly “jump out”, sometimes just within minutes after my edit, nominate the article I edited for AFD, or have half of an article deleted, or criticise me on talk page and have the thread I opened being closed, or, directly yelling at me that “You’re sprouting ... “, etc. All within a short time / same day, like heart attacks. You can’t feel the stress/threats just from viewing the page history unless you’ve experienced them (and that can only be felt from those notifications popping up). And when I tried to restore the removed content, I faced 3RR and 2 warnings, all within minutes; followed immediately by very unpleasant “discussion”/criticism on the project’s talk page.

When I look up the warning templates pages [1][2], I can’t find the warning template that they used. There is no such (level 4) warning template which says “restoring good-faith content is disruptive” (not to mention those are sourced long-standing content not added by me). It seems that they have “tailor-made”/created their own version of warning message for me.

If I were a new user, I would have been threatened and left already. Definitely, with no doubt. I’m quite sure that they have done similar tricks (3RR + level 3/4 warnings) to other good-faith editors as well. (This differs greatly from most other editors do, like providing a detailed edit summary, just remove one or two sentences/sources at a time unless they are doing a rewrite, tagging it first, try fixing the problem first, discuss civilly on talk page first, and only remove outright contentious bad content like those involving BLPs, etc.)

But I can understand why other users may not notice that or can’t see the problem because one can’t feel the tension just from viewing the page history, or, they might not understand how bad I felt when I saw large amount of valuable content that had been there over a decade was deleted mainly because of me. I came here to improve articles and to add content, not making them vanish. That completely goes opposite with the reasons that I’m here. What they did do affect my editing. I’ve left WP for a few days because of that, but it seems no use. Some of the above happened after I came back. I’ve asked for advice on another editor’s talk page, it seems that I was misunderstood. I was mainly asking for suggestions on the likely animus / uncivil behaviour, not on article’s content. I regret having asked that.. yes, my fault.. it was misunderstood.. and it seems that I’ve put someone in a difficult situation, which is not what I intended ... (As a side note, if we’re talking about content, removing a large amount of content at a time of course is not good. No one knows everything about every subject, and everyone makes mistakes. Removal like that will just increase the risk of mistaken removal, even when done in good-faith, without leaving the chance for correction).

I won’t deny that perhaps some of my edits/comments had irritated that user .. but I don’t think what they did is the way to go. Perhaps they just want to prove that “See? The article has problems that you didn’t notice and I’m correcting them now.”? I hope that can come to an end.. but that kind of behaviour has been lasting for quite some time already, and I’m not that optimistic ….. I choose to speak up here, anyway. What also troubled me is their fluctuating attitude/behaviour. Sometimes they seem to be very civil (mostly to others, but once or twice to me also). But when they are unhappy / don’t like you, it’s just totally different. I’ve been told to “find way” to like them, but it’s just too difficult.. I have tried not to escalate during the discussions (if you are familiar with my edits you’ll know how assertive I can be) but I wonder if that helped. I hope I’ve made it clearer now on why I said “I’ve tried my best already”. It’s not about “discovering the value of others”. Nothing like that. You can’t really like someone if they treat you (and others?) like that, no matter whatever value they have ...

Back to the “How do we welcome new medical editors?” thread at WP:MED talk page.. well, I think that user (one different from the above) has taken some of the advice in that discussion and probably has become more civil (as seen from their comments at least) now. And they have never been uncivil to me, which I really appreciate; despite the fact that I’ve pointed out several times what they shouldn’t have done. I believe that’s an editor with good intention. For that I’ve even given them a barnstar. So, perhaps I should go on and start a new discussion called “How do we work with our newly-joined colleagues?” Do we work with them by ... 3RR … warnings ... following … ?” I don’t think I have the energy (or should spend the time) for that though .. after all, it’s just Wikipedia ..

(N.B. I’m talking to myself and reply is welcome but not absolutely needed.. I’m not providing any diff, because I really don’t want to piss people off… if you know you know, anyway ..) --Dustfreeworld (talk) 18:35, 21 March 2024 (UTC)

WP:Wikihounding is against policy. You might want to consult someone to see if it fits. Aaron Liu (talk) 18:47, 21 March 2024 (UTC)

Thank you for sharing this, @Dustfreeworld. I'm really sorry for your bad experience. First and foremost, as Aaron Lui said, you need to report the behavior you describe.

On your message, I agree regarding the attitude. Welcoming users and providing suggestions to their edits is a positive and active way to have more editors joining. Trizek_(WMF) (talk) 17:47, 26 March 2024 (UTC)

@Trizek (WMF) The biggest blocker with any active welcoming and mentorship plan is that... They all fail thanks to no longevity plans and too much effort required.

I have never seen WP:Welcome Committee in action (but it's hard to, because the idea is decentralised anyway), WP:Teahouse has longevity (because it's low frills for everyone), but Wikipedia:Adopt-a-user pretty much has dried up (It's a lot of effort per mentor), WP:Co-op never really got off the ground (too much effort for everyone), WP:Snuggle is disbanded now (don't think many users used it but I might be wrong), WP:TWA is... I am not even sure if it's alive or not, it's not very easy to see the impact of it there, Growth Team's Mentorship space is currently indecipherable for any veteran editor (I don't even have an enwiki page to link for it), Hostbot is unfortunately inactive (not sure why), WP:Twinkle welcoming templates are still active.

Of all of these, I'd recommend reviving Hostbot and encouraging more Twinkle Templates for your active welcoming purposes. One is a bot, the other is a simple 2-clicks per user who's already installed Twinkle. Essentially the simpler and lower effort your solution is for everyone, the more impact it'll have overall (because it's much more likely to be used 3 years later instead of 3 months).

I could go in more depth, but essentially I'd like to see WMF dedicate more resources to simple easy to maintain ideas that solve one problem each, instead of overarching mega-goals that fail soon after the "patronship" dries out. Soni (talk) 06:42, 1 April 2024 (UTC)

There was research that showed people liked TWA but it did not improve editor retention. Not sure what your suggestion about Twinkle is; isn't Twinkle-welcome already working? Aaron Liu (talk) 14:45, 1 April 2024 (UTC)

Yeah I was pointing out Twinkle-welcome as one of the few "active welcoming" things that do already work; so if I were WMF, I'd focus some resources towards "Can we encourage this more". Right now it's mostly used by veterans who already know what Twinkle is/how to use Twinkle/are used to welcoming via Twinkle often enough. I don't have any specific plans already, but I assume anything that boosts any of those three will increase active welcoming. My point of highlighting Twinkle was "Improve something that works" vs "Make a new project that first crosses the longevity barrier".

I do think there's better avenues to explore, roughly in 'more automated and less heavy on maintenance' things. I'd like Hostbot revived, if only because it'll give us a lot of data on impactful retention. Soni (talk) 18:34, 1 April 2024 (UTC)

Some kind of encouragement to use Twinkle Welcome messages more might indeed help. After using Twinkle for many years, I only recently realized that I should be using the welcome messages more often when dealing with problem edits from (apparently) new editors. I think part of my problem was that I did not realize that besides the purely welcoming messages I often saw on user talk pages, there are also welcome messages that deal with a subset of problem edits that I can use instead of a pure warning message in many cases. Donald Albury 13:09, 2 April 2024 (UTC)

Most initiatives to help newcomers in a direct way (not through passive messaging) are time consuming, that's true. In my opinion (which is just an opinion), it is also the price of quality welcoming, to create a new generation of wikipedians. At the moment, the lack of time creates a gap on who will join: only users with "survival" skills will succeed, while less assured people will give up.

What I call "Passive messaging" are user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. Donald just gave good context about them.

Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits.

@Soni, if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Trizek_(WMF) (talk) 16:47, 2 April 2024 (UTC)

user talk page messages, often pre-formatted for a given purpose, often with wiki-jargon, looking like being distributed by a machine and very often with no way to contact the sender. I actually disagree. I get the main point you're making, but in practice, I find Template:Welcome cookie to be strictly better than literally everything (including Special:Homepage). There are a lot of worse templates, agreed, but tweaking to adjust the templates to better serve your purpose (A simple message saying "You can contact me at [my talk page]")

Also, I don't know if Twinkle offer ressources to encourage users of they've done good (or partially good) edits. That's why I mentioned Snuggle from earlier. If you specifically want "Let us encourage editors who made good editors recently" you may be better off partially or completely reusing codebase that should already exist from before. The project had an interface like WP:Huggle and pointed out newer editors with "good" edits that I could then send welcome messages to. It just was a separate interface that editors had to get used to using, so ended up not actually being used much (IIRC).

if I set aside using Twinkle, what are the solutions to welcome and sustain a new generation of editors? Like I tried to mention earlier, I think this problem is best solved by breaking down each subproblem separately. I think reviving Hostbot could be good for "Identify lots of promising editors, send them to pipeline of "editors training others". I think Growth homepage is good for "Every new editor sees this" but it needs severe updates to allow experienced editors to interact or help (Teahouse and a bunch of onwiki resources are still not added, there's no enWiki landing page or talk page, there's no WP project page with simple "Here's example screenshots of how the growth page looks", all of those will allow veterans to point out specific things that can be improved). I think there is room for space to grow "Mentor and retain editors who are promising (100+ good edits)", probably an evolution of WP:Adopt in some way. (I don't offhand know what that could be, other than "You could probably ask WP:WER and WP:EotW folks". Those have done excellent work in retaining promising veterans from burnout, simply by encouragement. So I can totally see something similar working for newcomers).

In essence, I'm recommending "Iterate and improve on every subproblem" as a way. "Will veterans use and maintain this space 2 years later" can be very hit-or-miss, but my best guess for increasing those odds involve asking a few Wikiprojects, then improving the projects they are most excited by/most likely to use. Soni (talk) 17:56, 2 April 2024 (UTC)

Interesting thoughts, thank you. They will feed into my work on mentoring and how to help communities in this area.

Regarding pre-formatted messages, my definition may not apply to some messages, but the majority of them are actually not that good across wikis. Even the Welcome cookie one could be improved for the benefit of new users. It is a problem in itself. :)

Anyway, to be continued, probably somewhere else. Trizek_(WMF) (talk) 19:01, 3 April 2024 (UTC)

My favorite welcome template is {{w-graphical}}, which neatly categorizes the links. Aaron Liu (talk) 19:06, 3 April 2024 (UTC)

Oh I completely agree that things could always be improved, I just think the improved templates are really "solid" and cover a lot of useful ground consistently (even if a bit impersonal). I also like automation because I treat this process as a scaling problem.

We probably have thousands of new editors monthly who make a useful edit, a few hundred who stick around for 10 edits, and probably dozens who I'd call "promising" (>20% odds of editing 1 year later, say). Each group requires a different approach to maximise our "odds", simply because otherwise you'd spend a lot of time personalising messages that might never be ever seen.

The more we can accurately go "Okay we have 20 new editors with 50 unreverted edits made over the last month", the more we can focus vet effort on personally interacting/encouraging/mentoring those. And the "They made 2 edits that weren't flagged as vandalism" folks can be handled by automated/semi-automated systems to get them to "Okay this is what talk pages are, also ask questions on this link" levels Soni (talk) 19:50, 3 April 2024 (UTC)

@Trizek (WMF) Also if you'll solicit future community input, I recommend WP:Helpdesk, Wikipedia:IRC/wikipedia-en-help regulars as well. Both locations deal with large volumes of newcomers constantly, so the vets there would know exactly the things that would smoothen their mentoring curve. Soni (talk) 19:54, 3 April 2024 (UTC)

You know that we don't have a common definition of a "useful edit"? The one used is based on reverts: a non-reverted edit after 3 days. We have data about this.

Regarding automated system providing guidance, they could work, but human-to-human interactions are way better to improve retention. We are working on the Wikimedia Foundation's annual plan, and it has a question regarding how we can distinguish ourselves from other platforms. I think the human factor is important there. It doesn't mean that we should not use any form of semi/automated ways of helping users (like we plan to do with Edit check), but we can make a difference on how we encourage new users with a more human -centered approach. Again, it is still a question with no proper answer. Yet!

Trizek_(WMF) (talk) 14:15, 4 April 2024 (UTC)

Oh I completely understand, I'm just making sure to emphasise making it sustainable for human volunteers. The last time I checked the Growth dashboard (6 months ago?) my realisation was that most of the human effort on veterans' end was fairly wasted. You do not want to burn out all your experienced editors trying to reply to everything when it's way more important for the "promising newcomers" (People who have already shown they understand Wikipedia basics AND are sticking around for more than 1-2 days) to get that interaction. I do not believe the latter is happening at all (or enough) right now, so I feel former (Spreading out volunteer attention to everyone) is not helpful enough.

You know that we don't have a common definition of a "useful edit"? I don't know if this is the biggest problem to solve, but I'm fairly confident I've seen something like this before. Snuggle, Huggle, mw:ORES all have some way of judging the quality of edits. I know I've seen this in my Watchlist as well. This is a perfect usecase for this or similar tooling: Decent accuracy but sorts through everything. Soni (talk) 14:33, 4 April 2024 (UTC)

I've often written about the inefficiencies of Wikipedia's discussion processes, and combined with the realities of most volunteer recruiting, where the vast majority of people stopping by aren't going to commit to staying around, agree that recruiting is costly. (There's a commonly used solution for that, but it's not one that I feel the English Wikipedia community is ready to accept: have paid staff do the welcoming and hand-holding.) That being said, I think that's just something that has to be paid to feed the pipeline for maintaining English Wikipedia at its current scale. While I also agree that having tools to help identify promising newcomers would be helpful to target them for retention, I additionally feel we need to work on ways to get more editors to the point where their promise can be evaluated. As others and I have previously suggested, perhaps there should be recruiting initiatives targeting groups whose interests align well with the idea of volunteering to write encyclopedia articles. This can be on a one-on-one personal level (current editors reaching out to people they know who would be interested) and on a higher level, such as trying to get history buffs involved. isaacl (talk) 15:34, 4 April 2024 (UTC)

@Soni, well the sustainability of any program that involve humans to help new users feeling welcomed and capable of editing is precisely the challenge.

My realisation was that most of the human effort on veterans' end was fairly wasted -- could you elaborate on this?

Regarding the quality of edits, there are two different cases: ORES can give a prediction of the intent or the level of damage. It is a possibility to guess if the edit is useful, but it is not qualifying as such for sure. Some obvious cases are immediately identified, but the grey area between vandalism and constructive edits is left to humans' appreciation. If we had a proper definition of a useful edit, the prediction models (ORES or its replacement) would work differently.

Regarding assigning a mentor to active users who already shown apetite for Wikipedia by a few edits could be a mistake. Being a mentor myself at my wiki, I often get questions from users who aren't sure if they can change something on a page. Their very first edit is a question to me. If i put aside SPAs, the majority of them are now active users (even if not regularly).

@Isaacl, if you have any link to your writings at hand, I'm curious to read about welcoming new users.

The Growth team worked on a tool to identify promising users, so that their mentor can encourage them. We tested it at a few wikis, but it is not ready at all for a larger release. We also have plans to assign mentors to newcomers who match their interests, but it is not on Growth's scope for now. Trizek_(WMF) (talk) 14:13, 5 April 2024 (UTC)

I think it's a good idea to try to match mentors to new editors based on common interests, as well as directing new editors towards active groups of editors with matching interests. Unfortunately, many WikiProjects no longer have high levels of engagement on their talk pages, which makes it harder.

I don't think I've written much about welcoming new users. I once wrote down some quick thoughts on active mentorship for new editors. At the editor retention WikiProject talk page, I have discussed selective recruitment and challenges in understanding how to make English Wikipedia more attractive for new generations to edit. (I do not remember where I discussed recruiting from historians/history buffs.) On the general theme of trying to attract people to help out, I've floated an idea for volunteer weeks, where editors host "open house" activities to recruit potential volunteers for specific initiatives. (If you're asking about something else, you might find something relevant on my "Community" user sub-page.) isaacl (talk) 18:08, 5 April 2024 (UTC)

could you elaborate on this? We've actually discussed exactly this last year. I noticed that the Growth dashboard was casting too wide a net, so I got 10 mentees who had never made an edit (and never would again). I don't believes any changes were made from there. And the dashboard continues to not be clear on what "level of editors" you'll get questions from. Veterans are a 'non-renewable resource' so I always prefer them fully knowing what they're signing up for and/or being tapped after there's already a "filter" applied on their potential mentees.

Their very first edit is a question to me I guess we disagree. I would like those editors to also get some assistance, but I personally believe it's way more important to first build a sustainable structure at the "higher levels of the pyramid". That is currently missing, so in my opinion, you are giving good human support to a few thousand editors who edit once, but have nothing for few dozens/hundreds who are already super likely to stick around.

I would rather Growth team's efforts be on building the "newbie to experienced editor" mentorship pipeline for all levels of newcomers, than focus all new initiatives trying to redo fancy new ideas but only for the newest editors. The reason I suggested ORES is because it probably isn't perfect but it's definitely "good" as a starting point. The scale at which enWiki operates, I'll rather have an existing tool that's 70% accurate in iding newcomers, than a tool that comes a few months later. I'd rather WMF spent more resources improving current tooling and reviving good projects with promise, than continue churning out newer plans every few months. Soni (talk) 18:14, 5 April 2024 (UTC)

Workshopping a trial admin process

In WP:Requests for adminship/2024 review/Phase I, I proposed trial adminship but it appeared that the proposal was not quite ready. I want to figure how can we have a trial admin process that is most likely to hold well with the community. There definitely should be a method for there to be trial admins when consensus is unclear or to dispel any doubts about current user conduct. Or maybe trial adminship should be the only result of an RfA. I do not know. Awesome Aasim 18:16, 12 March 2024 (UTC)

The framework that I think has the best chance would be a kind of limited adminship. I would make a permission, requestable at WP:Perm and grantable/removable by a single admin as appropriate. The permission is designed to counteract vandalism and be used by a new change patroller. The permissions would be:

Block any account that is not autoconfirmed for a short time (37 hours?)

Semi-protect any page for a short time (probably same time frame as blocking)

Delete any recently-created page.

This gives these permission holders the full block/protect/delete triad to avoid the law of the instrument. It also gives them enough ability to break up most common/simple cases without letting them get into a lot of situations where they generate controversy.

The permission would NOT have viewdeleted. This is awkward because they could delete a page and not have any way to revisit it, but it is a WMF requirement for any process that didn't go through a full RfA or similar.

The way the actual restrictions on the perms are enforced could be technical or social. If they have the technical ability to make any block, but there's a brightline policy against it and a bot that reports any discrepancy to AN, I think that's still fine.

I know this isn't exactly what you had in mind from trial adminship (giving the full tools and a period of time to use them before some kind of reconfirmation), but I think it's the best way to practically solve some of these issues. Tazerdadog (talk) 18:40, 12 March 2024 (UTC)

That feels like a pretty good idea, as making it a perm removes the need for a double RfA, and it can still show experience and trust in light of a future RfA. Chaotıċ Enby (talk · contribs) 19:31, 12 March 2024 (UTC)

On many Fandom wikis, there is this right called "content moderator". This right gives users the ability to edit fully protected pages (but not interface pages), delete/restore pages, rollback, and protect pages. We can have something similar particularly for those extremely familiar with the deletion policy. Awesome Aasim 03:43, 15 March 2024 (UTC)

Yeah, but having the ability to protect/delete but not the ability to block suffers from the law of the instrument. Chaotıċ Enby (talk · contribs) 14:10, 15 March 2024 (UTC)

That is indeed a problem, but I don't think it is that big of a problem when other administrators are able to immediately intervene when there is an incident of disruption going on. Awesome Aasim 16:42, 15 March 2024 (UTC)

That's not the issue. It's not about "they can't block and will have to wait for other admins", it's "they can't block and thus will likely protect instead of blocking, which is often not ideal". Chaotıċ Enby (talk · contribs) 16:44, 15 March 2024 (UTC)

I am thinking any trial admin process needs to allow users to demonstrate that they know how to act appropriately with the admin tools. Conduct as a non-admin is not necessarily an indicator as to whether they will behave that same way with the admin tools. In fact, people are more likely to be careful when given the tools just because they know the community can easily take the tools away. Awesome Aasim 20:11, 21 March 2024 (UTC)

I can think of lots of ways to do this. The trail admin might be paired with a full admin who would supervise the, trial admin. More high powered use of the tools might be reported to a notice board, Blocks might be limited to 24 hours to give a full admin time review, assuming a longer block is appropriate. The whole trial admin concept itself might be done a trial, say one year with a pause after to evaluate how it went.--agr (talk) 21:29, 21 March 2024 (UTC)

What do you have in mind when you say "supervise"? isaacl (talk) 02:02, 22 March 2024 (UTC)

I like the idea in general. The details would need work. There's nothing that precludes working on this even if it outside the main current review. North8000 (talk) 20:23, 21 March 2024 (UTC)

Well, re "delete/restore pages"... restoring pages (which perforce would require the right to read them first) is probably the most sensitive right on the project. Sure, for the overwhelming majority of deleted pages, there's nothing sensitive there. But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. One single person could cause a deal of mischief by reading these articles and giving them to a third party. (Yes, admins can do this, and some have, but I think we want to keep this ability as tightly controlled as possible.) As for deleting pages, are not enough pages being deleted? Could be quite the opposite. Herostratus (talk) 02:17, 26 March 2024 (UTC)

But, other pages might contain egregious libel, doxxing of persons, state secrets, instructions for making infernal devices, and so forth, and we really want them to be gone and to stay gone. That is what WP:SUPPRESS is for. Awesome Aasim 19:34, 2 April 2024 (UTC)

I don't think arbitrarily increasing the workload of a 45-person team that is already swamped with other stuff is a good idea. Aaron Liu (talk) 20:41, 2 April 2024 (UTC)

Okay, trying a different way to frame the problem:

There is a decently strong consensus that deletion, protection, and blocking are a core trio of permissions which should be packaged together.

The viewdeleted permission is incredibly sensitive for the reasons Herostratus listed above. Restoring a deleted page is also dependent on viewing it. Being able to delete a page but not undelete or review it is incredibly awkward for both admin accountability and mechanical reasons.

Trusting any user enough to give them the viewdeleted permission, along with all the other buttons, without having seen them use protection, blocking, or deletions before is a tall ask and is one of the reasons RFA is struggling.

I'm going to try to attack this from a different angle. Would it be possible from a technical perspective to create an adminbot that would email you the contents of a deleted page if and only if you were the person who most recently deleted it, and you had an appropriate userright, and/or undelete that page for you under the same conditions.

If we can do that, I think unbundling block/unblock, protect/unprotect, and delete/undo own deletion would be viable. Tazerdadog (talk) 19:51, 4 April 2024 (UTC)

Proposal: preference to hide maintenance tags

Moved from WP:VPR

For many Wikipedia readers, maintenance tags are annoying to see. While WP:OVERTAG does try to mitigate this, it would be great if there was an option in preferences to hide maintenance tags. Pksois23 (talk) 06:45, 15 March 2024 (UTC)

That's something you could probably do with a CSS gadget. Most readers don't have an account though, and I think maintenance tags do the important job of warning that the article isn't up-to-quality or even is misleading. Aaron Liu (talk) 11:42, 15 March 2024 (UTC)

Note: @Pksois23: this is not currently an actionable proposal, hard moved from VPR. Feel free to continue discussing here. — xaosflux ^Talk 14:11, 15 March 2024 (UTC)

Got it. Side note, VPR links to Vermont Public Co. Pksois23 (talk) 14:18, 15 March 2024 (UTC)

Fixed VPR link. Schazjmd (talk) 14:22, 15 March 2024 (UTC)

Agreed with Aaron. Maintenance tags present information that's important for readers to know (and to the extent they don't, they should be removed), so we don't want to make hiding them at all a default option. And for those who really want to anyways, despite the information literacy risk, there's already CSS. Sdkb ^talk 15:45, 15 March 2024 (UTC)

Another possible way to do this would be to have a hide button like [hide] next to the tags Pksois23 (talk) 14:23, 15 March 2024 (UTC)

One world still have to click it everywhere. Aaron Liu (talk) 14:28, 15 March 2024 (UTC)

• So we want to hide problems with articles from readers. Please, no. 🌺 Cremastra (talk) 15:51, 15 March 2024 (UTC)

  It's an option, so we aren't deliberately hiding anything. As long as it's unobtrusive it won't do any harm Pksois23 (talk) 11:57, 16 March 2024 (UTC)

  Hiding them does harm!!!! Then readers won't know what the issues with the article are!! 🌺 Cremastra (talk) 13:33, 16 March 2024 (UTC)

I can sympathize with the tags being "annoying", they often are. But that's the thing: they're supposed to be. Their purpose is to make sure the reader isn't accidentally misled by content that may not be up to our usual standards. They're supposed to be noticeable. That said, I wouldn't mind a userscript or CSS that could show/hide them for logged-in users who know what they want, similar to what we have for CS1 errors in citations at Help:CS1 errors. I also think it wouldn't be a bad idea to take a deeper look into whether our maintenance tags should have their appearances updated for modern aesthetics. I don't think there's anything wrong with the old classic look (I still use Monobook unless I'm updating page layouts where I'd need to check other skins) but as long as they stay noticeable I think consensus for a redesign pass could probably be achievable. The Wordsmith^{Talk to me} 16:11, 15 March 2024 (UTC)

There was {{mbox/sandbox}}, which changed the icons used (see Template:Ambox/testcases#name= text=text 2 for how it looks), but the community didn't like it. Aaron Liu (talk) 16:17, 15 March 2024 (UTC)

I remember a few proposals to update the boxes, but if I'm remembering right most of them were fairly small changes, backend stuff or accessibility. I don't think there's been a comprehensive major overhaul attempt in a while, but its possible I missed that discussion. Would you happen to have a link to the discussion for the last round? The Wordsmith^{Talk to me} 16:24, 15 March 2024 (UTC)

Scrounged a bit for this, it's at Wikipedia:Village pump (idea lab)/Archive 37#Changing to flat icons which also links to the same failed proposal's discussion in 2020. Aaron Liu (talk) 16:36, 15 March 2024 (UTC)

For many Wikipedia readers, maintenance tags are annoying to see. I have literally never seen a person IRL express this sentiment, nor any comments from new/ip users calling tags ugly at the Teahouse or the like. Mach61 23:19, 15 March 2024 (UTC)

Neither have I. I've also not seen any complaints (in real life or on wiki) from readers saying that they really missed the maintenance banners when they were hidden (for years and years) on the mobile site.

I'm seeing comments above like Maintenance tags present information that's important for readers to know – dubious, discuss? We have WP:No disclaimers in articles. Maintenance tags present information that's important for people doing maintenance work to know. That could include readers (aka "potential editors").

I think what we might need is a shared understanding of what the purpose of these banners is. Is it really to make sure readers know what the issues with the article are? If so, then a whole lot of tags need removing, because they're not actually problems that readers should care about. WhatamIdoing (talk) 01:59, 19 March 2024 (UTC)

If we really want to pursue that path of hiding unimportant tags, things get complicated, and the simplest solution would involve excluding IPs from seeing such tags. Aaron Liu (talk) 02:07, 19 March 2024 (UTC)

The guideline you listed specifically lists cleanup templates as "acceptable disclaimers" that are considered an exception. The Wordsmith^{Talk to me} 03:46, 19 March 2024 (UTC)

I think WAID is arguing based on principle. Aaron Liu (talk) 11:46, 19 March 2024 (UTC)

What it actually says is that they're acceptable because they're "temporary" and "should be cleaned up quickly". It does not say anything even remotely like "It's important for readers to know that there is inconsistent American and British spelling used in this article". WhatamIdoing (talk) 00:32, 24 March 2024 (UTC)

I think the public is used to our tags and they serve a cautionary purpose. In particular I've seen the phrase "citation needed" used outside a Wikipedia context and it is becoming part of the language. There is room for improvement in the tagging system. In particular I think some of the more contentious tags should always be accompanied with a new section in the talk page. No drive-by tagging. --agr (talk) 21:18, 21 March 2024 (UTC)

There's even a XKCD about it! Chaotıċ Enby (talk · contribs) 10:12, 22 March 2024 (UTC)

Wikipedian protester

User:xkcd generously gave us a free license for that favorite comic. It looks like it's used in several articles and even more talk pages.

(Oooh, lookit Citation needed#Usage outside Wikipedia. This might turn out to be an WP:IPC section I could enjoy reading. Hmm, a custom-printed scarf to sneak into events?) WhatamIdoing (talk) 00:58, 24 March 2024 (UTC)

Changing {{Broken anchors}} to the pattern of {{dead link}}

Hi all. User:Soni suggested changing {{Broken anchors}} to the pattern of {{dead link}}. I think this is a good idea. Since this task affects all Category:Pages with broken anchors pages, I'm here to ask for your opinion on this suggestion. If it goes well, I'll be ready to start modifying it. Kanashimi (talk) 07:20, 18 March 2024 (UTC)

Do you mean to change it to a tag that will be displayed in the article? Wouldn't that look very weird, since anchors are invisible? Aaron Liu (talk) 11:31, 18 March 2024 (UTC)

These are links to anchors, rather than the anchors themselves. The issue is anchors get changed, but the links to them don't. So there are 70,000+ articles with such broken links. -- LCU ActivelyDisinterested «@» °∆t° 16:59, 18 March 2024 (UTC)

Oh. In that case I agree. Aaron Liu (talk) 17:25, 18 March 2024 (UTC)

Can you explain further? I'm unclear on what change is being proposed. isaacl (talk) 17:50, 18 March 2024 (UTC)

To change the current system for tagging broken anchors into a {{fix}} template put after wikilinks to nonexistent anchors. Aaron Liu (talk) 18:14, 18 March 2024 (UTC)

At the moment the {{Broken anchors}} template is added to the talk pages of articles that have links to non-existent anchors. From my reading the proposal is to replace this with an inline template directly after the broken link, similar to how {{dead link}} is used to mark broken weblinks. -- LCU ActivelyDisinterested «@» °∆t° 18:30, 18 March 2024 (UTC)

@Kanashimi: can you please confirm whether your proposal is as described by ActivelyDisinterested, perhaps with a before and after example? isaacl (talk) 21:14, 18 March 2024 (UTC)

Thanks for joining the discussion. I did a demo edit here. Kanashimi (talk) 23:03, 18 March 2024 (UTC)

Sorry, I still don't understand what you are proposing to do. Is Cewbot intended to make edits that show how to invoke a template, rather than invoking the template? isaacl (talk) 23:13, 18 March 2024 (UTC)

Cewbot is supposed to stop adding these banners altogether and use a {{fix}} template to mark wikilinks to broken anchors. Aaron Liu (talk) 23:33, 18 March 2024 (UTC)

It looks like you're in favor of changing it to {{broken anchor}}? Kanashimi (talk) 23:36, 18 March 2024 (UTC)

That's not what appears in the link that Kanashimi provided. Perhaps you can let them explain their proposal? I still don't understand what is the current situation, and the proposed new situation. isaacl (talk) 23:39, 18 March 2024 (UTC)

This discussion started User talk:Kanashimi#Broken anchor edits. Perhaps you could take a look at what User:Soni has to say. Kanashimi (talk) 23:46, 18 March 2024 (UTC)

I am very confused. Is the proposal not to replace Cewbot's current talk-page-banner mechanism with one that puts {{broken anchor}} after links to broken anchors? That is what appears in the link (Note that Cewbot's first edit was wrong and Kanashimi fixed it.), and that's what appears on Kanashimi's talk page:

Personally I'd just add a template to the main article page, like Template:citation needed shows up inline. That way it's immediately obvious to editors where the potential anchor is.
— User:Soni

Aaron Liu (talk) 23:54, 18 March 2024 (UTC)

OK, so that sounds like what ActivelyDisinterested said. Is that correct? isaacl (talk) 23:58, 18 March 2024 (UTC)

Yes, if the bot can't fix it, it will insert {{Broken anchor}} after the link or template. Kanashimi (talk) 00:40, 19 March 2024 (UTC)

There was a mistake in the test settings, so I changed them manually. The current version is the one that will be available after the robot modification. Kanashimi (talk) 23:34, 18 March 2024 (UTC)

To re-cap:

Imagine an article that contains a link to Example#typo_here. This is a working link to an article, but there's no section called ==typo here== in the article.

• The current behavior is: A bot adds a note to the talk page to say that there's no section called ==typo here== in the linked article.
• The proposed behavior is: A bot adds a ^{[broken anchor]} template in the article, after the relevant link.

Is that right? WhatamIdoing (talk) 02:07, 19 March 2024 (UTC)

As far as I know, yep. Aaron Liu (talk) 02:08, 19 March 2024 (UTC)

That's pretty much it. The only distinction is that the bot currently adds {{broken anchors}} which resembles the talk page Wikiproject headers. My suggestion was to add [broken anchor] in the article and (additionally) maybe also adding a message in talk page. Like Talk:1st_Academy_Awards#External_links_modified from Internet Archive Bot. If we need something on the talk page, that's better than a banner. Soni (talk) 04:26, 19 March 2024 (UTC)

Is the change going to move the template for the current 70,000+ pages? Perhaps it would be better to hide the visual appearance by default, while allowing editors to enable its display through a personal CSS file if desired. isaacl (talk) 02:15, 19 March 2024 (UTC)

I say just grandfather keep the talk-box version and make new versions the inline {{fix}}. Aaron Liu (talk) 02:42, 19 March 2024 (UTC)

Yes, this change will affect all 70K pages. I'm expecting the same behavior as {{dead link}}, so I'll leave a marker to let users know to fix it manually. This is just like the behavior of {{dead link}}. Kanashimi (talk) 03:39, 19 March 2024 (UTC)

The problem with keeping the talk-box version grandfathered is that they are very hard to fix. As I mentioned in User_talk:Kanashimi#Broken_anchor_edits, I manually tried editing 2-3 of them to see how it was. There's no easy way for a human to see the talk-box template and find the respective text that was actually broken. You have to search through the text of the article, look for history (just in case the text got changed but the broken anchor remained) and crosscheck that with the talk page itself.

In fact, given how current automation works, you have no way to remove the talk-box notification when it's fixed. Of the articles I spot-checked, 2 were already fixed years ago, out of which one was even a redirect page.

Essentially the 70K pages with talk box version will contain a lot of pages that are already fixed, and everything else will be tiresome. It's simpler to just shift to a new functionality and have the script rerun on the 70K pages. The backlog can then be semi-automated (using AWB/similar) and the main fixes will become a lot easier Soni (talk) 04:21, 19 March 2024 (UTC)

Sure, but that can still be done while keeping the text hidden from readers by default (which I'm guessing was the original reason for placing the message on the talk page). isaacl (talk) 05:17, 19 March 2024 (UTC)

We don't keep {{dead link}} hidden, so I don't think we should keep broken anchors hidden either. Aaron Liu (talk) 11:46, 19 March 2024 (UTC)

If we were starting from scratch, then perhaps the two should be handled in the same way, though I'm guessing that {{dead link}} appears mostly in references, thus not affecting the visual appearance of the main content. But if the only discussion about this is on the idea lab village pump, then a lot of people will be surprised when thousands of indicators pop into existence. A more reader-friendly approach may be warranted. isaacl (talk) 15:15, 19 March 2024 (UTC)

I'd say these are no more intrusive than maintenance tags or {{cn}}. Aaron Liu (talk) 15:30, 19 March 2024 (UTC)

Agreed. I think it's not a big deal to put maintenance tags on talk page. I'd personally not attribute a lot of weight to why the template was originally written as it was, since it was basically "Because another template used this way" more than anything.

I am okay if the template was hidden (in which case it may just as well be a single Category:Articles with broken anchor link), but I think that's still less preferable than a tag similar to {{cn}} Soni (talk) 01:43, 20 March 2024 (UTC)

• User:Kanashimi Out of curiosity, what's the process for this usually? Does his need to go through another village pump/RFC/Bot approval/something else? Soni (talk) 08:09, 26 March 2024 (UTC)

  This is basically within the scope of the original bot application. But since it affects a lot of pages, I'm looking for suggestions here. I've recently started implementing it, and you can see it in action at Visa policy of Russia. Kanashimi (talk) 11:45, 26 March 2024 (UTC)

  I think the template needs to add a category as well, otherwise it'd be impossible to find broken anchors to fix. I don't think I see it in the Visa Policy article.

  Also if the broken anchor is on a redirect, should it default to just redirecting to the overall page? Soni (talk) 12:00, 26 March 2024 (UTC)

  Problematic articles are added to Category:Pages with broken anchors. You can see it on Union Pacific 1982. If there is a problem with the redirect page, I think sometimes it's just that the target of the redirect has been deleted and needs to be checked manually. Kanashimi (talk) 12:06, 26 March 2024 (UTC)

  I don't see why redirect links should be changed. If an anchor doesn't exist, it doesn't do anything either Aaron Liu (talk) 12:23, 26 March 2024 (UTC)

  Mainly because I think most broken anchors are just redirects, so the category is full of them. I can't check offhand though, and there doesn't seem to be a simple way to see everything in the category that's not a redirect.

  @Kanashimi Is there no way to check if an article exists? If the anchor (redirect or not) is at a deleted article, it probably shouldn't be a broken anchor template use anyway. (I forget if there's another template for redlinks) Soni (talk) 12:27, 26 March 2024 (UTC)

  Redirects to nonexistent articles fall under speedy deletion, and I'm pretty sure some bot like AnomieBOT already detects them. I don't see why broken anchors are mostly redirects = we must remove the anchor. Aaron Liu (talk) 12:30, 26 March 2024 (UTC)

  Sorry I didn't make it clear. I was referring to the situation where the article still exists, but the entire section has been deleted. Kanashimi (talk) 12:30, 26 March 2024 (UTC)

  I still do not see why we cannot change any redirect pages with broken anchors to instead be a redirect to the overall article instead. Without a "fix" redirects like Union Pacific 1982 already behave that way.

  Essentially I just want "Redirects with broken anchors" treated slightly differently than "Pages with broken anchors" just because it'll be a bit different dealing with both those backlogs Soni (talk) 15:20, 26 March 2024 (UTC)

  Without a "fix" redirects like Union Pacific 1982 already behave that way. So why should we remove the extra information of where it was meant to point? The same reasoning applies to normal wikilinks too. Aaron Liu (talk) 15:22, 26 March 2024 (UTC)

  My primary concern is the Category:Pages_with_broken_anchors page. Right now it's 70K pages, including talk pages. I think the non redirect pages would be much less in number. I think that any "backlog removal" efforts at the non redirect versions will be a lot different than the redirect pages.

  If we had some way to see "Non redirect pages with broken anchors" in the category easily, it's good enough for my concerns. "Redirect pages with broken anchors" can be hacked at in it's own free time Soni (talk) 05:09, 27 March 2024 (UTC)

  I still don't see the difference between those of redirects and those of links, and why we should separate them. Fixing them is the exact same process. Aaron Liu (talk) 11:29, 27 March 2024 (UTC)

  What's the purpose of the |target_link= parameter? Aaron Liu (talk) 12:27, 26 March 2024 (UTC)

  I'm thinking of using this parameter to quickly find all broken anchors linked to a specific page. Kanashimi (talk) 12:32, 26 March 2024 (UTC)

Captchas

I think we need more complicated CAPTCHAS in case a more complex bot comes on to the system and tries to log in Amoxicillin on a Boat (talk) 14:24, 19 March 2024 (UTC)

Our CAPTCHA system is not managed locally here on the English Wikipedia. There are several idea open for changing CAPTCHAS, you can review them here (including possibly using reCaptcha v3). — xaosflux ^Talk 14:29, 19 March 2024 (UTC)

Our current system has been enough for the last ten years. Aaron Liu (talk) 14:58, 19 March 2024 (UTC)

The current system is an impediment for some impaired persons. reCAPTCHA v3 may be better; here's a study on its effectiveness for those with visual impairments. isaacl (talk) 15:29, 19 March 2024 (UTC)

That's a good point, but I'm pretty sure our current captcha was developed so we wouldn't have to use Google. Maybe hcaptcha? It has a special sign up thing where you can get a cookie to skip all hcaptchas for the visually ipmaired. Aaron Liu (talk) 16:15, 19 March 2024 (UTC)

Feel free to give feedback to the MediaWiki devs. phab:T6845 is a ticket on accessibility of CAPTCHA; phab:T250227 is a ticket on using hCaptcha; and there are a number of other tickets at the link Xaosflux provided. Yes, the sticking point is how to keep user information private, which hinders dropping in a third-party solution. isaacl (talk) 16:26, 19 March 2024 (UTC)

There's a CAPTCHA? 3.14 (talk) 19:07, 19 March 2024 (UTC)

It only appears sometimes, like when the IP address has too much editing activity, when the edit triggers certain edit filters, and after too many failed login attempts. Aaron Liu (talk) 20:28, 19 March 2024 (UTC)

That may need to be expanded upon. BTW, possible vandalism in Just Shoot Me! - Missing Neilsen Awards. 3.14 (talk) 22:03, 19 March 2024 (UTC)

Not sure what you mean. Aaron Liu (talk) 01:20, 20 March 2024 (UTC)

The list of things that trigger CAPTCHAs needs to be expanded to things like creating an account (Speculation, IDK much about bots) or stuff like that. 3.14 (talk) 01:38, 20 March 2024 (UTC)

The last thing that I heard about our current system is: It keeps out humans (especially if they're not using a Latin-script keyboard, because typing correcthorse is difficult यदि आपका कीबोर्ड इन अक्षरों का उपयोग करता है), but it is easily defeated by bots.

Also, I've heard that creating our own could require a decade's worth of work for a team of engineers. Unless someone shows up with a US$10M grant and a determination to do it right, that project will probably continue to be postponed. WhatamIdoing (talk) 04:27, 27 March 2024 (UTC)

WikiNLP

This is the concept of a machine learning-assisted countervandalism tool, made using Natural Language Processing (NLP). We will train the system to distinguish vandalism from constructive edits; the system will then share the data with countervandalism users and bots such as ClueBot NG. If it works as intended, it has the potential to significantly reduce vandalism. 2804:14D:72B3:9F5D:0:0:0:1F54 (talk) 17:36, 20 March 2024 (UTC)

Great idea, but isn't this already mw:ORES? Chaotıċ Enby (talk · contribs) 17:40, 20 March 2024 (UTC)

It's also the already mentioned ClueBot. Q ^{T C} 17:43, 20 March 2024 (UTC)

ORES predicts the quality and the intent of edits. A new revert risk models is developed by the Wikimedia Foundation Research team, with two components: a multilingual model, with support for 47 languages, and a language-agnostic model. Trizek_(WMF) (talk) 17:52, 26 March 2024 (UTC)

Unpacking the infobox

Sometimes I run across an article where the infobox has been packed up in a tight wad of code that requires much more effort for an editor like me to analyze. Should we have a global 'bot' edit those into a more human-readable form? I think that would make it much easier for editors to maintain and expand. Here's an example edit: https://en.wikipedia.org/w/index.php?title=NGC_2523B&diff=1215012630&oldid=1214766725 . I've seen much worse. Thanks. Praemonitus (talk) 16:26, 22 March 2024 (UTC)

We can start with a regex like \{\{ ?[Ii]nfobox.*?(?:[^\n ]|[^\n] )(\|).*?(?:\{\{|\}\}) (and replace the captured group with \n\|), with the caveat that it doesn't work if other templates are nested in the infobox as regex (a glorified finite-state automaton) cannot count nested brackets. Chaotıċ Enby (talk · contribs) 17:09, 22 March 2024 (UTC)

Such a bot would be against WP:COSMETICBOT. -- LCU ActivelyDisinterested «@» °∆t° 20:38, 22 March 2024 (UTC)

Yeah, probably just ask to include in Wikipedia:AutoWikiBrowser/General fixes instead. I'll try to work on an AutoEd module for this. Aaron Liu (talk) 03:28, 23 March 2024 (UTC)

Thanks. The one concern could be inline cites in the infobox. Praemonitus (talk) 15:52, 23 March 2024 (UTC)

You can define use TemplateData for any template, to specify how the wikitext should be displayed in source mode. When defined, any edit to an article will activate the formatting from the TemplateData, and format the template the way it was defined. Trizek_(WMF) (talk) 17:56, 26 March 2024 (UTC)

Not really. It's limited to adding templates using TemplateWizard in source mode and adding/modifying templates in VE. The article won't automatically convert these every time you save an edit. Aaron Liu (talk) 18:40, 26 March 2024 (UTC)

No, but it will convert them every time you touch any part of the template in the visual editor. Eventually, that makes all of them conform. WhatamIdoing (talk) 04:30, 27 March 2024 (UTC)

Yeah, that's what I meant. Aaron Liu (talk) 11:26, 27 March 2024 (UTC)

I had the same info WhatamIdoing had, but apparently it wasn't really reflected in my sentence. Trizek_(WMF) (talk) 16:22, 27 March 2024 (UTC)

ITN reform

I am opening this discussion to invite suggestions and proposals to reform WP:ITN in anticipation of an RfC. Such reforms are long overdue: ITN has effectively shut itself off from the rest of the site as a walled garden and have developed their own system of rules that conflict with sitewide expectations, creating multiple problems:

• The inclusion criteria are entirely subjective and based on the personal whims and opinions of participants. Editors at ITN routinely use original research to determine "significance", applying their own analysis of each situation. Weight in reliable sources is not a major factor in whether ITN considers something to be "significant".
• ITN flouts community norms around consensus. Discussions are typically closed as head counts, without weighing arguments in regard to the application of policy. "I like it" votes are given equal weight in discussions. The discussions are also closed before consensus has time to develop: no other part of the project would dream of letting a discussion without a clear consensus be closed in under a week, but ITN's nature requires that they be closed in a few days at most. Many discussions are closed after just a few !votes one way or the other.
• ITN requires a fast turnaround, sometimes as short as a few hours. In addition to contradicting WP:DEADLINE, this creates rushed work and prevents in depth review. Nominal quality checks are done to make sure citations are present, but the window is short and most participants only evaluate "significance". This results in articles that are not only not ready for the main page, but ones that are unstable as they are oftentimes recently created, subject to early reporting errors, and undergoing significant changes.
• Since arguments about personal beliefs and opinions are built into ITN's processes, it is inherently less civil than other parts of the project. Over the years, drama at ITN has rivaled most CTOPs, to the point that applying general sanctions to ITN itself has been discussed in the past.
• The arbitrary selection of news stories (with a major systemic bias toward elections, sports, and mass-casualty events) misrepresents the overall state of what's actually in the news. Pushing this bias onto our readers does them a disservice.

These problems are intractable with ITN in its current form. I am asking for suggestions on how it can be reformed, or if that fails and there is consensus to abolish it entirely, how it can be replaced.

Examples of reforms:

• Remove the significance requirement entirely and include any article that is the subject of a recent news event.
• Require that a story receive significant coverage in a certain number of countries or a certain number of newspapers of record
• Promote articles based on trending topics (with oversight to prevent gaming the system)

Examples of replacements:

• Use the space to display several short blurbs for good articles each day, like smaller versions of WP:Today's Featured Article
• Use the space to provide links on how to edit and to help users find where to start in order to recruit more editors
• Move the "Other areas of Wikipedia" section of the main page into the space for easier navigation

These are ideas that have been suggested in the past. This is not an exhaustive list of examples, nor do I personally consider all of them viable. I'm requesting input from the Village Pump so we can develop additional suggestions and get a general idea of what the community thinks about them. Thebiguglyalien (talk) 18:48, 30 March 2024 (UTC)

Two issues with points raised:

• On the fourth point related to arguments: the only time general sanctions have been applied is when the topic itself falls into areas where general sanctions have already been applied (like AP2, etc.) There have not been any sanctions applies for topics outside these areas. So that's just how general sanctions should be applied, and not an ITN issue.
• On the fifth point, WP is not a newspaper and we absolutely should not share topics to match what is big in the news. Not every news story that gets a short term burst of coverage deserves a WP article (per NOTNEWS, WP:N and NEVENT) and ITN reflects that.

Remember that the main page as a whole is meant to showcase articles that represent some of the best of WP. Replacing it with a list of top stories in newspapers or with popular topics won't work at all, because not all those topics meet the main page requirement. — Masem (t) 19:17, 30 March 2024 (UTC)

I would also offer a suggestion that the ITN box include a permalink to the Wikinews sister project, which may be more attractive to those potential editors who get confused or put off in their first reverts that we are WP:NOTNEWS. SamuelRiv (talk) 15:09, 5 April 2024 (UTC)

Automatic page blocks to prevent 3RR violations

Hi! I have spent a few days patrolling recent changes and noticed that it can be quite easy to break the 3RR if you're not careful. I have thought of an idea that could help reduce accidental 3RR violations and/or impulsive edit wars from good-faith editors.

My idea is that somewhere in the preferences, there is an option named: 'Apply page block to self after revert limit reached'. If this is checked and the user then makes 3 edits tagged as some kind of revert to 1 page, a bot automatically blocks them from that page (not extending to its talk page). The block expires 24 hours after the first revert. If it is technically possible, it may also apply the block after 1 revert where there is a 1RR.

The aim of the block is to act as a sort of 'guard rail' to prevent the good-faith user from crossing the bright line. If they anticipate that they will have a legitimate reason to perform a 4th revert (e.g. blatant vandalism), they can turn the preference off before the 3rd revert. QwertyForest (talk) 21:11, 31 March 2024 (UTC)

That could be made into a user script, if you replace "be blocked" by "be warned that you might break 3RR" (especially since making 3 reverts shouldn't prevent you from editing the rest of the page normally) Chaotıċ Enby (talk · contribs) 21:21, 31 March 2024 (UTC)

That could work too. Nice suggestion! QwertyForest (talk) 21:24, 31 March 2024 (UTC)

Of course you could slow down a bit and be more careful. Phil Bridger (talk) 21:40, 31 March 2024 (UTC)

The thing is violations of 3RR may result in a block, but does not guarantee a block. Any kind of automated program such as the abuse filter blocking needs to be such that an admin would block the user in all cases. As aptly stated here, 3RR does not apply to reverting vandalism, BLP, or ban/block evasion. So unfortunately no I don't think this idea is a good one. Awesome Aasim 02:42, 1 April 2024 (UTC)

About to open RfC but need last minute feedback

Wikipedia:Requests for comment/Enforcing ECR for article creators is intended to address the problem of WP:ARBECR where only extended confirmed users are allowed to edit in a specific topic area. I am posting here to get last minute feedback on the format of the RfC before I open it formally. Any suggestions for changes to the format or what? Awesome Aasim 02:36, 1 April 2024 (UTC)

Would speedy dratification be a valid option? Aaron Liu (talk) 03:14, 1 April 2024 (UTC)

@Aaron Liu If you think it should be an option please feel free to boldly add it. Awesome Aasim 17:31, 1 April 2024 (UTC)

Really not sure how to word it.

Option D: Addition of a draftification criteria for articles with enough merit to Wikipedia:Drafts#During new page review, with another specified option taken if it does not have enough merit.

? Aaron Liu (talk) 17:56, 1 April 2024 (UTC)

That's fine. Awesome Aasim 21:53, 1 April 2024 (UTC)

Articles for Creation/Disambiguations

Hi. I've been reviewing redirect and category requests for some time now and I have an idea: Disambiguation requests.

Currently, requesting the creation of a disambiguation page is not easy for new and IP editors, as it can only be requested with the same process as normal articles. Therefore, I would like to discuss the possibility of a new AFC page, AFC/D, which will be used for the requests of disambiguation pages.

The format of such requests can be something like this:

== Disambiguation request: [Disambiguation page name] ==
=== Pages ===
# [Article 1]
# [Article 2]
...

The request can then be reviewed by experienced editors with help from user scripts such as the afcrc-helper, which will make the process much easier and quicker.

Thank you. CanonNi (talk) 01:40, 2 April 2024 (UTC)

• This sounds a good idea, and one that would, I am sure, help the Wikipedia community. YTKJ (talk) 19:51, 2 April 2024 (UTC)

New logging interface

Tracked in Phabricator
Task T71596

Here's an idea for a new way of signing up and logging in to Wikipedia (and maybe other projects too, if proven useful).

Instead of being brought to a new page (separate URL) and having to go through, in total, two separate page loads to finish signing in (which, for people with a poor connection, could mean minutes), I would like to suggest that the logging interface opens in a popup window within the tab (I.E. in the same URL), such that it automatically closes once signing is successful.

Thoughts?

Cheers, Cocobb8 (💬 talk • ✏️ contribs) 14:04, 2 April 2024 (UTC)

This sort of suggestion would likely be an upstream software change. A similar feature request for this is open at phab:T71596. Feel free to comment on it or submit patches there. — xaosflux ^Talk 14:26, 2 April 2024 (UTC)

Either every page download would have to include the appropriate code to perform a login, or the browser would have to load the appropriate logic from another URL when displaying the popup. While the extra cost of the login code is likely small, all non-logged in users would be affected, whether or not they ever log in. So while there may be other reasons related to user experience that would favour this change, I don't think resource usage is the best motivation for it. isaacl (talk) 16:00, 2 April 2024 (UTC)

In-page attribution of authors/contributors

Tracked in Phabricator
Task T120738

Something I've been thinking about for a while is how Wikipedia could provide better attribution for the contributors of its articles. After all, attribution is a key part of our license, but the authorship of an article is very much hidden away out of sight. In order to see the authorship of an article, one first needs to go to the "View history" tab, then click on the "Page statistics" external link, which redirects to an entirely different website, and even then you need to scroll down in the page before seeing authorship details. It also appears to only be visible in the web browser version, while it seems completely absent from the mobile app version. This presents a pretty unintuitive set of hoops for readers to jump through in order to discover (and attribute) the authorship of various articles. Even as a regular contributor, I didn't know this tool existed until a year or so ago.

This means that, to the lay reader or content re-user, all of our articles might as well be written by a monolithic "Wikipedia", or maybe a vague gesture at "Wikipedia contributors". Contrast this with other prominent encyclopedias like Britannica, which display the primary contributors to an article quite prominently beneath the article title and list secondary contributors in an easy-to-find section in the article history.

I was thinking that, either in the main page or at the top of the "View history" tab, it may be worth including such a list of contributors. It could be as simple as listing the primary author (with the most percentage/characters contributed), followed by any secondary contributors (with >10% contributed), followed by an "et al", which could itself link to further information about the article's authorship.

I think this would be a very important fulfilment of our own license's terms of attribution, both for in-wiki use and for anybody that might be reading or thinking about reusing the article's content. It would be a step away from the monolithic conception of "Wikipedia contributors". It could also provide a greater sense of impact for the articles' authors themselves, who would be able to easily see the fruits of their labour on screen. Of course, I understand this may come with its own drawbacks. I know some editors prefer the anonymity, while others may be worried that this could encourage low-effort edits in order to farm credit. But I personally think that the potential benefits of such a credit feature would outweigh the potential costs.

Having looked through the village pump archives, I'm confident this isn't a perennial proposal. I only managed to find one discussion of such a feature, which was opened by @Doc James almost a decade ago, but it didn't seem to gather a clear consensus and I'm not sure if anything ended up resulting from it. If anyone has any comments on this embryonic proposal, I would be happy to hear from you. --Grnrchst (talk) 14:27, 2 April 2024 (UTC)

@Grnrchst as an example, could you produce what you would expect the output of such to look like for this page? — xaosflux ^Talk 14:32, 2 April 2024 (UTC)

It's an odd example, because this is a discussion page, but it would currently be something like "Written by WhatamIdoing, Xaosflux, et al." --Grnrchst (talk) 14:43, 2 April 2024 (UTC)

So you'd be fine ignoring the thousands of other authors on such a byline? — xaosflux ^Talk 14:58, 2 April 2024 (UTC)

I don't think it's feasible nor particularly useful to include every single contributor in a byline, but I don't think they should be entirely ignored either, that's why I've included the "et al." (could also say "and others", or something). The reason I set the byline inclusion at >10% is because that's the rule of thumb used by the good articles project to determine major contributions. I think named inclusion in the byline should be limited to such major contributors, but linking to total authorship in the "et al." would also be useful for showing the full scope of contributions. --Grnrchst (talk) 15:05, 2 April 2024 (UTC)

I don't think there is going to be any good way to programmatically determine those values. In your example above, what calculation did you use to determine that WhatamIdoing and I were >10% contributors for example? This is primarily why the cite this page tool example just says "Wikipedia contributors". (see more below) — xaosflux ^Talk 15:17, 2 April 2024 (UTC)

I was using the "Top editors" section in the Xtools page I linked to in the "et al." As this is a discussion page, rather than a mainspace page, Xtools doesn't show an "Authorship" section in this case (hence why I didn't think it was a good example). Whereas in the one for Morgan Bulkely, there is an authorship section that shows Wehwalt at 79% of authorship, Real4jyy at 6.2% of authorship, etc. The authorship tool on Xtools is apparently powered by WikiWho, which we may be able to use for generating such a byline. --Grnrchst (talk) 15:25, 2 April 2024 (UTC)

As for the "Cite this page" tool, I think this is an example of how just vaguely citing "Wikipedia contributors" is unhelpful and even redundant. Of course it's authored by Wikipedia contributors, it's a Wikipedia article! --Grnrchst (talk) 15:51, 2 April 2024 (UTC)

Another example, using today's featured article Morgan Bulkeley, would read: "Written by Wehwalt, et al." Grnrchst (talk) 14:47, 2 April 2024 (UTC)

I was thinking this "Written by [...]" could go next to the bit where it says "From Wikipedia, the free encyclopedia". --Grnrchst (talk) 14:51, 2 April 2024 (UTC)

In the mobile view, we do advertise the "last" author (e.g. see the bottom of this page) - that could possible be ported to desktop. — xaosflux ^Talk 15:00, 2 April 2024 (UTC)

I think the "latest contribution" is a good measure of recent activity, what I'm aiming at with this proposal is trying to demonstrate a broader scope of total activity. --Grnrchst (talk) 15:07, 2 April 2024 (UTC)

• Note, a feature request that may address this idea is open at phab:T120738. — xaosflux ^Talk 15:18, 2 April 2024 (UTC)
• Note that we currently have https://xtools.wmcloud.org/articleinfo/en.wikipedia.org/C418_discography and Who Wrote That which calculate the percentage, the latter using an API that does it Aaron Liu (talk) 15:20, 2 April 2024 (UTC)

  I think you'd want to use the WhoColor API (which is what mw:Who Wrote That? uses). The other methods tend to overemphasize people who don't actually write any words. For example, if the article has 50 edits total at the time of calculation, and five of them are me blanking the whole article, or changing the whitespace on a template, then I've made 10% of the edits, but I haven't written a single word on the page.

  @Grnrchst, the last time I remember seeing a discussion about highlighting the names of contributors, a jerk who normally edited under his real name created an account with a vulgar username and made one edit, just for the purpose of asking whether we really wanted to have vulgarities displayed in the mainspace. WhatamIdoing (talk) 16:41, 2 April 2024 (UTC)

  And his alt was banned for WP:DISRUPTNAME, right? Aaron Liu (talk) 20:40, 2 April 2024 (UTC)

  I was having the same thoughts. It should be based on who contributed to what the article as currently displayed. It would be wrong for instance to list the top contributor as someone who hasn't edited the article since it was completely rewritten.
  It might also encourage more competitive editors to try and find ways to boost there standings, without having to do any actually helpful work. -- LCU ActivelyDisinterested «@» °∆t° 15:54, 3 April 2024 (UTC)

• I am concerned that this would encourage WP:OWNERSHIP of articles. The entire point of the Wikipedia model is that articles are “authored” by the community, not by individuals. Blueboar (talk) 20:48, 2 April 2024 (UTC)

  This is a completely fair and valid concern. --Grnrchst (talk) 21:54, 2 April 2024 (UTC)

I don't see the need for this. I do get a certain pleasure from seeing how much of the content in an article I have contributed (which I can see at Page Statistics), but I am well aware that no one else really cares, and the future of such content is out of my hands. I am not editing Wikipedia to build my curriculim vitae. Donald Albury 21:41, 2 April 2024 (UTC)

• As someone soliciting donations for your Wikipedia work, is this something you are considering using to attract donors? isaacl (talk) 21:43, 2 April 2024 (UTC)

  No. --Grnrchst (talk) 21:51, 2 April 2024 (UTC)

Personally I strongly dislike the idea of articles where I have primary authorship saying "written by Levivich, et al." or anything like that. That is very much not the kind of attention I want. Also, xtools authorship is not really reliable. For example, I am listed as the #2 author of Alexandria Ocasio-Cortez [3] but that's only because I once ran the archive bot on that page [4], I am not actually anywhere near a top author of the actual prose on that article. Levivich (talk) 17:15, 3 April 2024 (UTC)

If you have a divisive article and then add a note that User X was its most prolific contributor, readers will immediately assume User X holds those divisive views. And all the better if User X is an IP and offended readers can immediately find their location. (Which is already possible, of course, but why place it front and center?)

Speaking of which, how would this even work with dynamic IP addresses? 2603:8001:4542:28FB:25EE:12B6:DCFA:E43E (talk) 18:43, 3 April 2024 (UTC) (Send talk messages here)

I agree with the concerns voiced by Levivich and others. And even if the authorship statistics were 100% accurate I still don't like the idea of omitting certain users; as sappy as it sounds I think every contribution matters. Potentially, we could do something like Based on the contributions of 328 users but even then I think a more appropriate place for this kind of thing would be the footer alongside the last edited date. ― novov (t c) 08:21, 4 April 2024 (UTC)

• I can totally see the issues with this: we'll never have a 100% reliable measure of authorship, you can't include everyone, and we'll probably see a slight uptick in WP:OWNERSHIP and authorship gaming. But overall, I think it would be a nice way to acknowledge our volunteer editors and to communicate to readers "look, this was written by real people – you can join us". And twenty years into the project, with declining editor numbers, increasing restrictions and expectations of those editors that persevere, and donations to "Wikipedia" siphoned off by an organisation that has increasingly little to do with it, I think we really do need to start prioritising looking after our volunteer base over other concerns. Relying on the ideal of the selfless, perfectly-self motivated contributor, happy to work in complete anonymity, was fine in the early days of the project when the internet was the playground of affluent nerds with utopian ideals; those days are long gone. – Joe (talk) 08:56, 4 April 2024 (UTC)

I can see how algorithmically a shortened authorship list would be generated automatically, fine-tuned for a relatively accurate representation. And while anything like that could be gamed by users, that's why we have lots of human eyes to review abuse. I can also see how such a list would be useful to researchers and those making citations. However, were such an authorship list to be implemented, I'd suggest it be hidden out of the way a bit, at least certainly from the front page of the article, and perhaps even completely hidden from UI except as metadata.

I'll give some contrasting examples: Scholarpedia places its curator-authors (respected subject-matter experts) prominently at the top of its articles: non-random example is BCM Theory (SP). By contrast, Internet Encyclopedia of Philosophy has its authors' names and affiliation mentioned simply at the bottom, under "Author information" following the bibliography; while Stanford Encyclopedia of Philosophy has its author even more nondescript, being in a footer at the bottom under a copyright notice, and not implied to be an actual "author" until you click on the "Author and citation info" link on the sidebar. (Again, respected subject-matter experts; random ex.: Gender in Chinese Philosophy (IEP), Plato on utopia (SEP).) Wolfram MathWorld also has authorship given relatively subtly at the bottom of the page -- if it's contributed by someone other than the editor, the contribution note precedes the bibliography; otherwise authorship is indicated only in citation information (ex. Chen-Gackstatter Surfaces (MW)).

Given all this, I don't know what example editors here would want to find themselves compared to, especially since an algorithm listing authors would not distinguish one editor writing 95% of an article immediately preceding GA, from one editor writing 55% of the prose in a B-class, for which others had to find new citations (unless we'd want it to do so, but this would epitomize wp:ownership). SamuelRiv (talk) 15:37, 5 April 2024 (UTC)

It’s really hard to measure the significance of contributions to an article. It’s not just a count of who added the most words, or even of who added the most words that survive into the current version. How should we weigh a user who adds some high word count nonsense to an article, against a user who painstakingly sifts through the garbage, deletes most of it, and copyedits down any remaining kernel of valid content? Or the user who contributes great source analysis to a talk page discussion on a matter which results in a single word changing? Perhaps the article on Antoine de Saint-Exupéry is finished not when there is nothing left to add, but when there is nothing left to take away? Barnards.tar.gz (talk) 18:05, 5 April 2024 (UTC)

This is an excellent point. We don't have any accurate automated way to assess contribution levels, and xtools authorship isn't it (neither is bytes added or edit count). Levivich (talk) 18:56, 5 April 2024 (UTC)

Just because an algorithm isn't currently implemented, does not mean an algorithm doesn't exist. As a rough starting point: authorship+curation can be measured by taking the diffs made by an editor to bring text in line with the current stable state, weighted by time. (For the simplest measure, you can just use edit longevity with hysteresis.) Now, absent some new API properties, this is an expensive calculation to maintain for every article, but it's perfectly technically doable. (Another, more sophisticated method is analogous to a co-authorship network.) Of course this has been done before: Arazy et al 2010; Lanio & Tasso 2011 (citing Biuk-Aghai 2006). SamuelRiv (talk) 19:28, 5 April 2024 (UTC)

Redirect deletion

Just floating this idea.. MediaWiki now includes a specific permission for deleting redirects with only one revision. The delete-redirect user right could be granted to page movers to allow them to delete pages that had been moved to draftspace by a non-PM and subsequently tagged with CSD R2. I see these pages pop up in the new pages feed from time to time, where the article had been draftified but sometimes the R2 tag lingers for quite awhile. To be clear, this permission only allows deletion of redirects that have only one revision (namely those created as a result of a page move). We could also probably set up an edit filter to further restrict usage of this feature to only permit deletion of the page if the person attempting the deletion is the original author, or if the R2 tag is on the page (I know there was at least an experimental/joke edit filter at one time to prevent deletion of the main page, so the functionality is there). Thoughts? Taking Out The Trash (talk) 01:10, 3 April 2024 (UTC)

Makes sense. If we trust page movers to move articles without leaving a redirect, we can trust them to help other users do the same. On the other hand, CAT:R2 very rarely has more than a couple of pages in it, so I don't think there's a pressing need for more hands there right now. – Joe (talk) 07:15, 3 April 2024 (UTC)

This proposal seems useful and reasonable. If R is a one-revision redirect to article A, a page mover could already delete R badly by moving A to R then back to A without leaving a redirect. (Don't try this at home.) Let's give them the tool to delete R well instead of badly. Any redirects we really need to keep should be protected anyway. Certes (talk) 09:09, 3 April 2024 (UTC)

The challenge this idea creates is setting up a "You can do X, but you can't undo yourself" situation. That isn't necessarily a showstopper, but something to consider. — xaosflux ^Talk 14:11, 3 April 2024 (UTC)

I had thought delete-redirect still only helped during page moves and was currently granted to page movers: Wikipedia:Page mover#delete-redirect. (I've also looked through Wikipedia:Page mover/delete-redirect.) I think expanding it to just delete single revision redirects is maybe unwarranted; maybe with additional limitations as mentioned but I'm not sure the expansion of the right would be added to MediaWiki if it depends on local edit filters? Skynxnex (talk) 14:19, 3 April 2024 (UTC)

• To be clear the permission delete-redirect is already assigned to "page-movers" (in fact that is the only group it is assigned to). — xaosflux ^Talk 14:25, 3 April 2024 (UTC)

  Also, as @Skynxnex mentioned above, it only actually applies during a move (a page move can't use Special:Delete directly with this access). — xaosflux ^Talk 14:30, 3 April 2024 (UTC)

  (To make sure nothing recently changed, I just validated that workflow with my test accounts as well). — xaosflux ^Talk 14:31, 3 April 2024 (UTC)

  Thanks for the clarification. It sounds as if some of what was asked for already exists, and the rest is not possible, so there's nothing to do here. Certes (talk) 14:40, 3 April 2024 (UTC)

• Well, what I was interested in was granting access to Special:Delete only for single revision redirects to page movers, so that they can delete anything tagged for R2. I thought that the delete-redirect permission would allow this, but I could be wrong. Taking Out The Trash (talk) 17:18, 3 April 2024 (UTC)

  It doesn't (verified), this permission was built (phab:T239277) to only be used during moves. — xaosflux ^Talk 18:53, 3 April 2024 (UTC)

Expunged criminal offences

The state of Virginia, where most Wikipedia servers are, permits the expungement of certain less serious criminal records. This is common across the US. Most democratic countries have similar arrangements, for example the UK and Australia allow for many offences to become 'spent'. In the US, it is usually a misdemeanour to report expunged convictions without good reason (acceptable reasons are laid out in the relevant legislation); in the US and other countries like the UK it is a tort (a civil harm, and so actionable in civil court) to report without good reason. Should Wikipedia policy permit the removal of expunged convictions from articles? Charlie Campbell 28 (talk) 06:48, 5 April 2024 (UTC)

As a general rule our content should be guided by reliable sources rather than the location of the WMF's servers. How do they usually treat expungement? – Joe (talk) 08:03, 5 April 2024 (UTC)

Thanks, Joe. My question was inspired by coming across an ex-offender's article where all his expunged criminal convictions are listed in detail. So I guess we allow it at present? Charlie Campbell 28 (talk) 11:42, 5 April 2024 (UTC)

Several major US newspapers (e.g. the Cleveland Plain Dealer, the Boston Globe) have in the past few years implemented a right to be forgotten policy. See Miller & Folkenflik, NPR 2021-02-23 and Ahmad, CJR 2019-12-12. SamuelRiv (talk) 13:47, 5 April 2024 (UTC)

This is interesting, @SamuelRiv, and thank you. I read a good roundup of the US situation which suggested that the media might take this forward in their own way according to local editorial policy. This seems to be a good example. It's why I wondered if Wikipedia might consider doing the same. https://thecrimereport.org/2021/09/10/expungement/ Charlie Campbell 28 (talk) 22:40, 5 April 2024 (UTC)

I'm not sure about other jurisdictions, but here in England records of crimes that attract sentences of more than a couple of years' imprisonment are never spent. Less serious crimes should not be covered at Wikipedia anyway (per WP:BLP). If the location of the servers leaves us open to court action we should consult our legal team. Phil Bridger (talk) 08:20, 5 April 2024 (UTC)

Thanks, @Phil Bridger. I can't see a reference at WP:BLP which says that spent (less serious in your formulation above) offences should not be covered. Are you sure? Charlie Campbell 28 (talk) 12:18, 5 April 2024 (UTC)

On legality, if WMF has any concerns about the possibility of liability for hosting such information, it can take an office action to say so. I'd suggest that you would be hard-pressed to find any example of a speaker like an encyclopedia, newspaper, or blog (rather than a consumer reporting agency, government official, or person in possession of a restricted government record) being held liable in the United States (or in a foreign judgment enforced in the United States consistent with the SPEECH Act) for continuing to report true information about a past criminal proceeding that was published in the news before it was expunged. See United States defamation law (a major theme/adage of which is that truth is an absolute defense to defamation) and Gertz v. Robert Welch, Inc. (requiring at least culpable falsity for defamation on a matter of public concern), to say nothing of Section 230. SilverLocust 💬 09:21, 5 April 2024 (UTC)

Thanks, @SilverLocust. I looked up the law in some states and in Europe. In US states like Virginia and Michegan, reporting an expunged conviction without justification is a misdemeanour, but you are right to say that it is far harder to secure a successful defamation action on that basis in the US than in Europe. There is a good brief here https://www.rcfp.org/disclosure-expunged-records-does-not-invade-privacy/. The media organisations discussed there won their case because they could show good reason. In the UK, it is simply a breach of tort law to report any spent offence without good reason. In mainland EU, the rules are even tougher. One question which might arise, then, is whether Wikipedia should observe the law in other jurisdictions (like UK and EU) or just US? Charlie Campbell 28 (talk) 12:00, 5 April 2024 (UTC)

Per WP:NOTCENSORED, just United States law. SilverLocust 💬 13:11, 5 April 2024 (UTC)

If the crime was minor, and the only material available to verify it are things like court records, WP:BLPCRIME already says it shouldn't be in the article. Of course if there was substantial coverage about it in independent sources, then it might merit inclusion. As to the claim In the US, it is usually a misdemeanour to report expunged convictions without good reason—[citation needed] on that one; I would very much have expected to see a First Amendment challenge to that, and I would expect it to win. Laws muzzling the general public from disseminating truthful information almost never pass constitutional muster. UK law may say that, but well, we're not in the UK (though that may be a concern for individual editors who are, but it's on them to comply with law in their jurisdiction, and that doesn't affect anyone else). Seraphimblade ^{Talk to me} 11:48, 5 April 2024 (UTC)

Thanks @Seraphimblade. Replies here don't appear to permit in-line citations so I was reluctant to simply cut and paste as that seemed to be against the purpose of the functionality. I'm not a lawyer and so I'm reluctant to cite the law (one of my own reference points was Virginia law) but was rather giving what I feel is an accurate pen-picture. I completely agree that it would be very hard, if possible at all, so win a defamation case in the US. It would, by the looks of it, be straightforward in Europe. The fact remains, however, that the legislation has a purpose, however difficult or feasible it might be to enforce. I think Wikipedia should have a clear policy on it. Charlie Campbell 28 (talk) 12:12, 5 April 2024 (UTC)

There is no problem using in-line citations. Just add {{Reflist-talk}} after your post to keep the full citation associated with your post. Donald Albury 13:01, 5 April 2024 (UTC)

Thanks so much, @Donald Albury. I'll do it that way in future. Charlie Campbell 28 (talk) 13:16, 5 April 2024 (UTC)

I have read all the very useful posts here and follow through wherever I can. I should say that my original thoughts were about Wikipedia policy rather than liability. My takeaway so far is as follows: US and EU law does allow for expunged convictions but it is highly unlikely that any case for defamation would succeed in the US. A similar type of case in the EU might be successful against the individual editor if resident there, however that editor would need to be identified and Wikipedia would be unlikely to yield to requests for such disclosure from outside the US. It does not seem that liability is a pressing question which could drive any kind of policy change.

However, a policy change can be driven by things other than legal liability. It also seems true, though, that US wikipedia editors in particular (but perhaps many elsewhere) would likely defend the stronger US freedom of expression over an emphasis in the EU towards a right to be forgotten. This all seems to rule out any policy of the automatic removal of expunged criminal records, regardless of jurisdiction.

It seems possible (likely?) that most editors recognise the sensitivity around different democracies' differing public policy and prefer to avoid conveying the impression that the US-based nature of Wikipedia is used to ride roughshod over every other part of the world. Might other, already extant, policies have relevance upon the way expunged convictions are reported in Wikipedia articles (e.g. proportion as per WP:NPOV?). Or is any kind of revision required? I come back to the example which prompted my post here, where an article largely comprises a list of an individual's spent convictions. Charlie Campbell 28 (talk) 13:18, 5 April 2024 (UTC)

That policy is WP:WEIGHT. Also, in the specific case that prompted this query, the subject of the article is a high-profile individual, a former British MP. In other cases, WP:BLP1E could apply and we could choose to not cover the person at all. Also because in this specific case the subject is a former MP, it seems extraordinarily unlikely that any attempts to suppress discussion of his criminal history would be successful in court. VQuakr (talk) 00:18, 6 April 2024 (UTC)