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, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60

break up paragraphs

This is a practice request rather than a feature request.

When looking at diffs, it's a pain to scroll through a paragraph taller than my screen to find the one changed word (or comma), not to mention the similarly long paragraphs shown before and after it for context.

I would urge editors to insert single line breaks – which are invisible on the page – between sentences, especially after complex refs. Or at least not to go out of your way to remove such breaks! —Tamfang (talk) 19:10, 3 September 2024 (UTC)

That will converse the bots as to where the paragraph ends. Hawkeye7 (discuss) 06:06, 4 September 2024 (UTC)

I wouldn't want to converse anyone unnecessarily, but can't bots detect a blank line? —Tamfang (talk) 23:11, 4 September 2024 (UTC)

It's fine to put linebreaks inside templates, such as the citation template. If one is really concerned about losing something in the underlying html, then one can enclose a linebreak within an html comment <!-- -->. These may or may not help with alleviating the diff display.

The html for a single line break in plain wikitext appears as a newline character within a <p> element, which is not rendered by default, but may be picked up accidentally by a bot (not sure for example if AWB's regexp tools default to stop at newlines, or else match "^" to newlines, but imo regexp is inherently a trial-and-error tool, and people who have been using it on WP for a while will have tested their code on newlines already).

As for whether it impacts something more important like commercial accessibility tools (like screen readers), I don't know. But OP's issue is an important accessibility issue as well, since as most of the emerging and young world is operating exclusively on mobile devices, we want to address their UX concerns. (I enjoyed the essay Wikipedia:Editing on mobile devices.) SamuelRiv (talk) 18:41, 6 September 2024 (UTC)

I would concur it's worth considering a habit of single linebreaks following elaborate citations. Remsense ‥ 论 12:55, 11 September 2024 (UTC)

As it happens, there's already an essay advocating for this exact practice: Wikipedia:Newline after references. jlwoodwa (talk) 22:54, 12 September 2024 (UTC)

See, the issue is that shortcut isn't memorable, so how can I possibly make the same point as this essay two weeks from now if I can't remember what letters to link the guy? Remsense ‥ 论 22:57, 12 September 2024 (UTC)

Teach the controversy: WP:NEWLINE —Tamfang (talk) 15:56, 16 September 2024 (UTC)

Feedback on WP:Admin reconfirmation requested

This isn't a perfect match for VPI, but it's not concrete enough for VPPROP and isn't a policy proper yet, so can't be on VPP. This page is a result of WP:RFA2024, but being familiar with the RFCs isn't required (and, as a matter of fact, fresh eyes are encouraged). In short, we had an RFC to determine the specifics of the policy (proposal) which isaacl has summarized here. The page tries to convert the sparse bullet points into a proper proposal.

Though none of the bullet points may be changed without a strong consensus, there are obviously gaps to fill (the templates, for example, are a new addition and need refinement) and sentences to be made clearer and more concise. Sincerely, Dilettante 23:25, 16 September 2024 (UTC)

The title sounds like Wikipedia:Perennial proposals#Reconfirm administrators but the contents are more like Wikipedia:Perennial proposals#Community-based process for removing adminship. WhatamIdoing (talk) 21:57, 18 September 2024 (UTC)

That's a good point. A few others raised the issue of the name, but just cited personal preference. Sincerely, Dilettante 01:26, 19 September 2024 (UTC)

Left behind.

I feel like I've been left behind, forgotten, invisible. I made a post then it got removed. See the page Wikipedia:Village pump (idea lab): Difference between revisions - Wikipedia. Blackbombchu (talk) 15:19, 19 September 2024 (UTC)

It was removed by Remsense with the summary "can't make any sense of this post, unfortunately.", an assessment with which I agree. Thryduulf (talk) 15:25, 19 September 2024 (UTC)

I guess it's just my tiny little seed. It will add that very little tiny bit. They will all add up and get us there eventually. Blackbombchu (talk) 15:29, 19 September 2024 (UTC)

@Blackbombchu, I've left a message on your talk page out of care for you. I hope you read it and see it comes from somewhere authentic. Remsense ‥ 论 15:31, 19 September 2024 (UTC)

Uppercase fullname policy shortcuts

In the spirit essays like WP:WTF? OMG! TMD TLA. ARG! and WP:ALPHABETTISPAGHETTI and WP:UPPERCASE, I'm trying to do a lot more lowercase fullnaming when referencing policies like WP:OriginalResearch or wp:competenceisrequired. I've personally found this less likely to be cognitively associated with shouting or lawyering, more self-explanatory without needing a hover, and much easier on the eyes. Hopefully newer editors have felt the same.

Two things I'd like to address:

1. Not all subpolicies have redirects in both lowercase and camelcase. I just want to make sure they can all be made without controversy.
2. On the policy pages themselves, the shortcuts to subpolicies are always uppercase. So we have (in RS) both WP:UBO and USEBYOTHERS as shortcuts in the box, but as only UBO is an acronym, why can't we have the second shortcut suggestion be WP:UseByOthers? (Similar across the P&G.) It's just an indicator that other shortcuts besides UPPERCASE exist.

Relatively minor thing that won't change the actual functionality of anything. It just makes the replaces the suggested full-name spelling (not acronyms) of P&G shortcuts from uppercase to camelcase. SamuelRiv (talk) 19:26, 19 September 2024 (UTC)

To pre-empt the objection that editors should pipe plaintext to P&G as suggested in the essays I linked: I agree, that's great, if editors actually did it with any regularity. For my own part, piping is an extra bit of typing that may not be as clear that I'm referencing P&G in discussion in the first place, which is often important, since I've found people rarely click links anyway. SamuelRiv (talk) 19:32, 19 September 2024 (UTC)

I don't think you're likely to get any pushback on point 1. It has long been my practice to refer to such things in whichever case makes most sense in the sentence I am writing (usually lower case or with a capitalised first letter) and, if "show preview" shows it as a red link, create a redirect. I don't think I've ever had anyone revert this. I'll have to think a bit more about point 2 - there's a danger of bloat there. Phil Bridger (talk) 19:50, 19 September 2024 (UTC)

To be clear on #2: in the box in the P&G that gives the shortcuts in bold blue text: one is an acronym and one is the fullname, so in my linked example, the box says Shortcuts: WP:UBO WP:USEBYOTHERS. I suggest replacing the fullname shortcut in the P&G from allcaps to camelcase, so the box now says Shortcuts: WP:UBO WP:UseByOthers. I'm not sure where you're seeing bloat, as not a single byte is being added or subtracted, and functionally nothing is changed. SamuelRiv (talk) 20:01, 19 September 2024 (UTC)

I see one possible point of contention: in many skins including legacy vector, the search includes all redirects, and some might be annoyed to see a ton of redirects preemptively clog up the suggestions when they want to find something else after typing the first word. Personally, I like point 2-style redirects much better. Aaron Liu (talk) 23:29, 19 September 2024 (UTC)

Legacy Vector search is case-sensitive? So if I start searching "mrna", it brings up a list including "Mrna", "mRna", "mRNA", all of which link to the same thing? If that's the case, and someone is still using such software, then the adding or removing of case-sensitive redirects has surely long since stopped being a cause of heartache for that person. SamuelRiv (talk) 07:26, 20 September 2024 (UTC)

There are a great many ways of searching Wikipedia, some of which are case-insensitive and display a list of possible results as you type. This includes the internal search engine, which is independent of which skin you use (you see the same results in vector, vector legacy, monobook, etc). Thryduulf (talk) 11:29, 20 September 2024 (UTC)

I don't think the internal search engine brings up multiple results to the same page due to redirects. Aaron Liu (talk) 11:51, 20 September 2024 (UTC)

That makes sense. Still, I like the CamelCase redirects better since it's very clear where the words separate. Aaron Liu (talk) 11:52, 20 September 2024 (UTC)

You know what separates words more clearly than CamelCase? Anything spaces. "You're violating our policy about WP:BiographiesOfLivingPeople" vs. "You're violating our policy about WP:biographies of living people." Also easier to type; mostly doesn't need new redirects; and looks way less weird to everyone but programmers. (WP:biographiesoflivingpeople is even worse.) —Cryptic 12:37, 20 September 2024 (UTC)

I don't advocate for redirects like that and merely repeat the title. The UseByOthers example goes to a section with a different name. Aaron Liu (talk) 12:45, 20 September 2024 (UTC)

As could WP:Use by others. —Cryptic 12:55, 20 September 2024 (UTC)

CamelCase is a tiny bit less effort to type and still indicates that the link is a shortcut. I think the reason everything caps is precisely to differentiate them as redirects, and some of that differentiation should be preserved. Aaron Liu (talk) 12:58, 20 September 2024 (UTC)

Personally I don't feel that the visible link text should be differentiated as redirects. This primarily serves to codify a term (in allcaps or camel case) as jargon. There are times when this can lead to greater concision, but most of the time the gain is small, with a cost of greater confusion for those who don't already know the title of the destination and the corresponding text. For example, often non-neutral points of view get labelled as being WP:NPOV. I appreciate the point of view that learning a community's jargon is part of joining that community. I feel, though, that English Wikipedia has plenty of jargon already without every shortcut being used as jargon. isaacl (talk) 15:55, 20 September 2024 (UTC)

The reason I'd advocate camelcase as the second suggested redirect (in the little redirects box in the P&G sections), as opposed to spaced-out prose versions (which I'd also like to see used more by editors), is that camelcase is also at least a little suggestive that there is an acronym people use, or i.e. that a newbie following a discussion might more readily deduce 'WP:UseByOthers ↔ WP:UBO'. If everyone here would prefer listing 'WP:Use by others', that's fine by me; one could also put three shortcuts instead of just the two: 'WP:UBO WP:UseByOthers WP:Use by others'. SamuelRiv (talk) 17:38, 20 September 2024 (UTC)

Furthermore, spelling abbreviations out can at least give clue as to what the jargon means. Aaron Liu (talk) 21:41, 27 September 2024 (UTC)

@SamuelRiv, if you'd like this to be a bit easier, then try switching from 'Source' to 'Visual' in the Reply tool for a few days.

Use its Link tool for adding links. In the visual mode, just type [[ and it'll notice that you want to make a link and open the tool for you (alternatively, click the button in the toolbar or use the keyboard shortcut (=⌘K on a Mac). Type the shortcut (e.g., WP:CORP) into the link search box, and it will offer you a link to the full title (e.g., Wikipedia:Notability (organizations and companies). For individual sections, open the page in a tab, and paste the whole URL into your comment. For example, I opened WP:SIRS in another tab, and pasting the whole URL gives me a nicely formatted link to Wikipedia:Notability (organizations and companies)#How to apply the criteria.

I suggest trying this out for a few days and seeing whether you like it. WhatamIdoing (talk) 06:14, 25 September 2024 (UTC)

@WhatamIdoing The source mode's link tool in the toolbar does the same thing. Aaron Liu (talk) 21:40, 27 September 2024 (UTC)

The [[ sequence only works in the visual mode. WhatamIdoing (talk) 22:03, 27 September 2024 (UTC)

Yes, but the link icon in the toolbar works the same. (Also, ConvenientDiscussions has an inline-typing linking-assisting pop-up that autocompletes, even though it doesn't automatically expand the redirect.) Aaron Liu (talk) 04:17, 28 September 2024 (UTC)

Verified badge for Admins!

I’m not sure what others will think of this, but I accidentally had this thought: how would it be if we added a verified badge, similar to Instagram or Facebook’s verified badges, to admin signatures when they comment? It would make it easier to identify that the editor is an admin, instead of having to check their profile, contributions, or diffs, which is a lengthy process and not ideal. Similar to how Discord groups use a green name for admins. What are your thoughts on this? GrabUp - Talk 13:03, 22 September 2024 (UTC)

@GrabUp, there's a script for that: User:Mdaniels5757/markAdmins. Schazjmd (talk) 13:46, 22 September 2024 (UTC)

Schazjmd, GrabUp: there's quite a few, actually. — ClaudineChionh (she/her · talk · contribs · email) 13:47, 22 September 2024 (UTC)

My personal favorite is user:Bugghost/Scripts/UserRoleIndicator. Aaron Liu (talk) 15:30, 22 September 2024 (UTC)

Admins who care to do this can do so, and users who care to see this can do so. But in general this needn't be and shouldn't be the default. We've all seen how sometimes editors seem to show unusual deference to known admins in discussions on non-admin-related matters, such as content and meta-content. This may be unconscious or conscious, but it's counterproductive to discussion and counter to the spirit of the project either way. SamuelRiv (talk) 14:14, 22 September 2024 (UTC)

Agree on this one. Admins are just users trusted with some tools, they don't have any special authority on content or anything else. Chaotic Enby (talk · contribs) 19:26, 22 September 2024 (UTC)

If I use my administrator's tools to block an editor or delete a page or protect or unprotect an article, any one who is looking closely will know that I am an adminstrator because only adminstrators can do those things. On the other hand, when I write a new article or expand an existing article or give an assessment on an article talk page or offer advice at the Teahouse, nobody needs to know that I am an adminstrator because those are not administrative functions and I am just another editor at that moment. I did all those things long before I became an adminstrator. If I tell another editor that I am an administrator, that is in the context of a warning. I see no benefit to a badge. Cullen328 (talk) 08:52, 24 September 2024 (UTC)

It's technically impossible to enforce with traditional wikitext discussions anyways. Structured discussions as used on other wikis might be able to support it, but in that case, why are admins given the blue check and other users not?--Jasper Deng (talk) 09:00, 24 September 2024 (UTC)

(It's actually possible, you just query members of a CSS class and show them the same way you may in structured discussions.) Aaron Liu (talk) 10:57, 24 September 2024 (UTC)

(That is not impersonation-proof.)--Jasper Deng (talk) 11:03, 24 September 2024 (UTC)

Yes it is? The API always tells the truth. By query CSS class I mean all userpage links next to timestamps. There are scripts above that do the exact same thing.
A more efficient implementation would be automatically adding a new CSS class to admin userpage links along with sanitizing signatures against manual addition of the class. That said, I'm not convinced this is something we should do. Aaron Liu (talk) 12:48, 24 September 2024 (UTC)

I don't think this is something we should do either (if users really want it, there are already several user scripts doing that and allowing for custom CSS). I'd say the only place where it isn't impersonation-proof is if someone goes out of their way to fake another user's signature, but at this point it's just saying that our signatures themselves aren't impersonation-proof, and a quick check in the page history is enough to spot and revert it... Chaotic Enby (talk · contribs) 14:02, 24 September 2024 (UTC)

No it's not. The user can completely fake the badge visually by not even querying the API, since inline styles are possible in wikitext, and users control their own signatures.--Jasper Deng (talk) 18:51, 24 September 2024 (UTC)

That's a good point. If we settled on an API-based style that changed signs to say something like "Jdforrester (talk) is an admin", then soon after, we'd find that some editors had set a WP:CUSTOMSIG to say something like "WhatamIdoing (talk) is an admin" – only the first is 'real' and API based, and the second is mimicked in wikitext.

It might be possible to minimize this technologically, using the same kind of code that already disallows custom sigs without a link to your own account, but doing that would require dev intervention, which in turn probably has a minimum requirement of us thinking that it's a good idea, which doesn't seem to be the case. WhatamIdoing (talk) 06:25, 25 September 2024 (UTC)

Proposed Measures for Mitigating Vandalism from the Indian Region

At present, Wikipedia addresses vandalism in India through IP and host blocks. However, a significant issue is that most Indians access the internet via mobile connections, where mobile providers assign NATed IPs. As a result, when administrators block a host range, it inadvertently affects a large portion of mobile users. Consequently, individuals within these ranges are unable to create accounts or make IP edits. There have been reports of a decline in editors from India, which coincided with the shift towards mobile-based internet access.

To address this challenge, I propose introducing a requirement for users accessing Wikipedia from suspicious networks to provide a verified email address when creating an account. The email should be from a trusted domain, such as Gmail or Outlook, which require mobile number verification as part of their sign-up process. This would help ensure that new accounts from these networks are legitimate.

Additionally, there is room to improve how Wikipedia handles repeat vandals. Currently, when a user is flagged for vandalism, they receive a temporary block, but once the block expires, their account is restored to its previous status without further consequences. It has been observed that some users take advantage of this by making constructive edits for a period, only to revert to vandalism later, perpetuating a cycle of temporary bans. Over time, certain users have accumulated considerable edit counts and status, which they leverage to manipulate factual data—such as box office figures—or prioritise certain sources to skew rankings. The high edit count often discourages other editors from reporting them, despite their history of disruptive behaviour.

To curb this, I suggest implementing additional measures when reinstating users after a block. First, users should be required to provide a verified email address from a reputable domain before their account is reactivated. Second, they should be reinstated in a limited or "safe mode," regaining full editing privileges only after completing a specified number of good-faith edits. This would slow down organised vandals and disrupt their timing, as many appear to operate on a carefully coordinated schedule.

Lastly, to further safeguard the platform, IP edits from suspicious domains IP-Ranges should be permanently blocked, as these are often used for repeated abuse.W170924 (talk) 21:50, 23 September 2024 (UTC)

Addition To address the issue of unreported vandalism, which often remains only as an edit description, I suggest implementing an Email Required Block Filter (ERBF) for moderators. This tool would allow moderators to temporarily freeze a user account until the user provides a valid email address from trusted domains like Google or Outlook, which require phone number verification in India for account activation. Additionally, the user should not be allowed to change the email address for a month.

Furthermore, users who are temporarily blocked for vandalism should be reinstated in 'safe mode,' meaning they will only have the permissions of a newly created account. In this mode, they must complete 100 edits to regain their previous status. If the user is blocked again for similar behaviour, the required number of edits could be doubled for subsequent reinstatements. This approach encourages responsible editing while providing moderators with more effective tools to prevent repeated disruptions.W170924 (talk) 07:21, 24 September 2024 (UTC)

I removed the statements that couldn't be implemented due to WMF core principles, but I am confident the last part doesn't violate any privacy.W170924 (talk) 23:55, 24 September 2024 (UTC)

Minor nit: neither Gmail nor Outlook require mobile number verification to create an email account. Schazjmd (talk) 21:56, 23 September 2024 (UTC)

@Schazjmd:I am not sure about other regions, but in India, they won’t allow access to their service until phone number verification is completed.W170924 (talk) 22:04, 23 September 2024 (UTC)

I didn't know that, @W170924, thanks! In the U.S., there's no phone verification requirement to set up an email address. Schazjmd (talk) 22:07, 23 September 2024 (UTC)

I'd rather we just make accounts with a verified phone number get IP-block exempt by default unless the rangeblock specifically requests to block them as well. Wikipedia's software has no such functionality yet though.

IP edits from suspicious domains

what does that mean lol Aaron Liu (talk) 23:23, 23 September 2024 (UTC)

@Aaron Liu:I wrote 'IP edits from suspicious domains,' though I intended to say 'IP edits from suspicious IP ranges,' which was an unintentional mistake. Using a verified phone number is a best practice, but it would significantly increase costs for Wikipedia.W170924 (talk) 04:22, 24 September 2024 (UTC)

Currently, when a user is flagged for vandalism, they receive a temporary block, but once the block expires, their account is restored to its previous status without further consequences. It has been observed that some users take advantage of this by making constructive edits for a period, only to revert to vandalism later, perpetuating a cycle of temporary bans.

Citation needed on this one. Repeated vandalism is nearly always met with escalating blocks for registered users, and the third or fourth block is usually indefinite. For IPs, blocks are usually temporary (although increasing in duration) rather than indefinite, as they are often reassigned to new unrelated users. Nearly all indefinitely blocked IPs are open proxies rather than personal IPs.

Over time, certain users have accumulated considerable edit counts and status, which they leverage to manipulate factual data—such as box office figures—or prioritise certain sources to skew rankings.

Again, do you have any evidence? A user with repeated temporary blocks wouldn't have a lot of "status", whatever that means, and changes aren't trusted based on the reputation of the user who makes them, but on their quality of sourcing. Chaotic Enby (talk · contribs) 23:52, 23 September 2024 (UTC)

@Chaotic Enby:You acknowledge that a permanent ban is only imposed after the third block. This means a person can create an account, commit acts of vandalism, receive a temporary block, then contribute positively for a year before repeating the behaviour. Essentially, the user is given three opportunities to engage in such actions, with their edit history remaining intact throughout. This process can be drawn out, as most vandalism only results in a warning. Recently, there has been a more lenient approach to vandalism, such as using unreliable sources to cite information or editing a range without providing proper references. In some cases, the user's behaviour may go completely unnoticed. My intention was not to single out individuals but to highlight this ongoing issue. I believe systematic vandalism requires a systematic approach. Also, for a new user, the edit count matters as they may not yet be familiar with how Wikipedia operates.W170924 (talk) 04:43, 24 September 2024 (UTC)

So an editor will "contribute positively for a year", and after that the engage in systematic bad-faith editing (however many weeks or months this may take to discern, it is a function that scales with the number of bad-faith articlespace edits)? I echo users above in asking for examples in which this is happening systematically, because... if people are editing WP positively for an entire year just to game the system later, I would hypothesize (awaiting examples) that WP comes out ahead. SamuelRiv (talk) 06:10, 24 September 2024 (UTC)

@SamuelRiv:I still reiterate that the scope is not to name anyone, but you can check my history.W170924 (talk) 07:23, 24 September 2024 (UTC)

• @W170924: I know you mean well, but as someone who has worked extensively in countervandalism, including work as a Wikidata CheckUser dealing with many Indian IP's, your ideas are rather misguided. Firstly, accounts which clearly only vandalize are always indefinitely blocked even on the first instance, and that's the vast majority of cases of vandalism. Requiring verified phone number or email addresses is something the foundation categorically will not do, as they have stated repeatedly, not the least (in part) because it poses a serious inclusivity and accessibility issue for users. "Suspicious IP ranges" does not fly well in India in particular, especially with IPv6, because Reliance Jio and other ISP's stupidly allocate all addresses from one giant, monolithic, block, so (analogously to disk fragmentation) abusive users are highly interspersed with legitimate users. Verified email address obtaining is also very trivial with disposable email services and we will not allow particular providers such as Gmail and Outlook.com to gatekeep our editing access. I must reiterate what others say: you have made these claims of patterns, but have not satisfied the burden of proof since you have not provided any data to support your claims.--Jasper Deng (talk) 08:32, 24 September 2024 (UTC)

@Jasper Deng:I had sent feedback on this to you. Do you think my ideas are misguided?W170924 (talk) 13:37, 24 September 2024 (UTC)

For context, they sent an email. Aaron Liu (talk) 14:19, 24 September 2024 (UTC)

@W170924: Please do not email me unless privacy is absolutely required, which it is not here. What you sent me shows you don't understand what vandalism is; please read WP:NOTVAND. Cases where subtle vandalism are missed would not be helped by your suggestions, either.--Jasper Deng (talk) 19:57, 24 September 2024 (UTC)

@Jasper Deng:So, does that mean people are allowed to do so if the threshold is not met?W170924 (talk) 22:19, 24 September 2024 (UTC)

@W170924: I don't understand your question. Not all disruption is vandalism.--Jasper Deng (talk) 04:14, 25 September 2024 (UTC)

Ok.W170924 (talk) 06:08, 25 September 2024 (UTC)

• W170924, to give a current example, can I point you at Asian News International#Lawsuit against Wikipedia where you can see for yourself why editors would not want to be compelled to hand over personal info, and why the WMF would not want to be in possession of that info. Cabayi (talk) 11:22, 24 September 2024 (UTC)

@Cabayi:It would be inappropriate for me to comment on the example as I am strongly biased being Indian. I will only say this: if that matter escalates, Wikipedia may lose all Indian editors in the process.W170924 (talk) 13:37, 24 September 2024 (UTC)

Which is why editors shouldn't be required at all to submit personally identifiable information: nobody should be prosecuted. Aaron Liu (talk) 14:20, 24 September 2024 (UTC)

Pinging SGrabarczuk to talk about m:Trust and Safety Product/Temporary Accounts, which could reduce this problem on our end. On the off chance that any affected ISP happens to see this, if they wanted to reduce this problem themselves, then switching from using CGNAT rotating a small number of IPv4 addresses to using a stable, larger number of IPv6 addresses would help a lot, and that's something they could do themselves. WhatamIdoing (talk) 06:31, 25 September 2024 (UTC)

@WhatamIdoing: As my Jio example shows, merely using IPv6 isn't enough on its own. The subnets still have to be geographically localized, not doing allocation from one giant block, or else the same abusers end up jumping across extremely wide ranges, which I've observed while conducting CheckUser work.--Jasper Deng (talk) 06:35, 25 September 2024 (UTC)

Fix Draftification with a new template

Draftification has long been criticized as a backdoor to deletion. In New Pages Patrol (NPP), it is common to move new articles that are not ready for mainspace to draftspace. This way, articles that could potentially be suitable for Wikipedia, but are not yet, are preserved. The article creator then gets a chance to improve their article without NPPers breathing down their necks or having it taken to Articles for Deletion. If anyone, including the article creator, objects to draftification, the article should be moved back to mainspace (draftification should be reversed). This is explained by DRAFTNO #6 and #7. No reason is required for the objection.

Problem: However, we also have a rule that drafts that haven't been edited for six months get automatically deleted, under Criterion for Speedy Deletion G13. So, well-meaning New Page Patrollers will unilaterally draftify new articles that are not yet ready for the encyclopedia. The new editors who created the article may disagree with the move, without knowing that they can object. The new users can get discouraged and leave Wikipedia altogether, and after six months the draft is deleted under CSD G13. As this process happens without community discussions, it results in draftification being called a "backdoor to deletion".

Solution: This problem can be solved without changing policy or current practice. We just need to make it very obvious to new users that they can object to draftification. We can also make it easy to reverse the draftication (assuming the new user is autoconfirmed). I suggest we do this by adding a template to all draftified articles. The template would include a big blue button, similar to the "Submit the draft for review!" button at Template:AfC submission/draft, which says "Object to this move". Clicking this button either: 1. Leaves a message on the talk page of the editor who draftified, notifying them that there has been an objection to the move and requesting that it be immediately reversed. 2. Moves the page back to mainspace automatically, or if the editor's account is unable to perform this task, creates an entry at Requested moves/Technical moves to that effect. The latter is better, but also more technically complex. Adding a similar button to Template:Uw-articletodraft, the warning typically given upon draftification, would also be helpful.

Implementation: Once the new template is ready, it can be added to MPGuy's MoveToDraft userscript, which is the most common way for NPPers to draftify articles. It should be placed above the AfC template on all draftified articles.

I would appreciate comments from technically skilled editors, who could create this template (or tell me that it's impossible), from NPPers who draftify articles, and from uninvolved editors who have opinions on the draftification process. Toadspike [Talk] 10:37, 26 September 2024 (UTC)

This idea isn't really my own, it was obviously sparked by the most recent RfA. A similar idea was previously discussed here, but that discussion proposed a requirement that all editors have to follow (policy), not a technical solution, and turned into a trainwreck. To prevent something similar, I ask all participants to please focus on improving the current situation instead of debating the morality of draftification as a whole. Toadspike [Talk] 11:03, 26 September 2024 (UTC)

Notifying the users who commented most directly on this topic at the RfA: @Alalch E.@User:Onel5969@User:Hobit@User:Fangz@User:Nsk92. I have also notified the NPP Talk page and posted a message on Discord. I am not sure how to notifying all participants of the previous discussion (aside from doing it manually) and I am not sure that is productive considering how many people were involved and how offtopic it got, so I won't do that for now. Toadspike [Talk] 11:07, 26 September 2024 (UTC)

Are you sure you want to make this an RfC? Is there a BEFORE somewhere? Aaron Liu (talk) 11:32, 26 September 2024 (UTC)

Good point, I am not sure if the RfC label applies, so I'll remove the templates. I was looking for ways to notify people and misread RFCBEFORE. Toadspike [Talk] 11:34, 26 September 2024 (UTC)

• Oppose: The draftification message could be tweaked, but a big button to reverse the move will lead to more AfDs, higher strain on NPP, more BITEY behaviour, and worse editor retention. Draft space is incredibly valuable, and people have some incredibly warped views about the space. If we did something like this then we'd end up chasing away new editors because learning how to make your article meet our complicated guidelines in under 7 days (AfD tag) is not easy for a lot of folks. Draft space gives them the opportunity to work on the content, to receive advise, and to make articles that will actually survive at AfD and allow them to stick around. Really we need to draftify more, and I've taken it upon myself to begin to do so again and encourage others to do. I'm big on editor retention. This is not the way to do it. Hey man im josh (talk) 12:15, 26 September 2024 (UTC)

  The problem with unilateral draftification is that it can also be incredibly bitey, especially when done for arbitrary reasons that have nothing to do with any of the reasons why something might be deleted at AfD (although this is less prevalent than the trivial reasons things are rejected at AfC). We should be draftifying fewer articles and not sending them to AfD either but rather leaving them in the mainspace (With appropriate tags where justified) so that they can be found and improved rather than pretending that they don't exist for six months and then deleting them. Thryduulf (talk) 12:34, 26 September 2024 (UTC)

  I'm not really convinced draftification is any worse than the alternatives - tagging is *also* bitey as well, and one user tagging an article and leaving it in mainspace could lead to another user seeing it and deciding to AfD. Draftification could be a way to protect an article until it enters a better state. But I think the other part I have an issue with is the lack of clear guidelines. Clearly some people have an issue with draftification and others do not, and people have different ideas what it is for. That needs to be made more concrete. Otherwise just saying "we should use draftification less" isn't going to lead to any positive changes. Fangz (talk) 12:43, 26 September 2024 (UTC)

  I agree with the general sentiment – arguing for more or less draftification does not solve the problem that new users basically can't object to it. Toadspike [Talk] 12:47, 26 September 2024 (UTC)

  I envision a template (possibly one specific for relatively new users?) being something like:

  1. Hi, this article has been moved to a draft form because another user thinks it has potential but is not ready for the encyclopedia just yet. REASON:

  2. You can continue to work on it while it's not published, though note that if not editted for 6 months it will be deleted. Here are some useful resources.

  3. When you think the article is ready you can submit the article to a review, which can give useful feedback. []

  4. Alternatively you may return the article to the main encyclopedia at any time and have it be editted while part of the main encyclopedia. See WP: Draft Object. Note however that if other users think there are unfixable issues with the article it may be put forward as a candidate for deletion. Fangz (talk) 12:54, 26 September 2024 (UTC)

  I like the idea for the user warning. Aaron Liu (talk) 12:59, 26 September 2024 (UTC)

  Tagging never leads to an article being automatically deleted. – Joe (talk) 18:43, 26 September 2024 (UTC)

  In my view draftified articles should (semi?) automatically return to the mainspace after timeout instead of be deleted. Or at least be re-evaluated for notability. I do not really see the reason for automatic speedy deletion, except as backdoor deletion. Fangz (talk) 18:59, 26 September 2024 (UTC)

  I like that idea. They don't, though, so it's a bit of a moot point in terms of current policy. – Joe (talk) 06:16, 27 September 2024 (UTC)

  Why can't they just improve it in mainspace, without the sting on of an initial rejection and a six month deletion countdown hanging over them? I don't get why you keep presenting this as a choice between draftspace and AfD. – Joe (talk) 18:46, 26 September 2024 (UTC)

  The reason is that "improving it in mainspace" has its own issues. An article in mainspace has to juggle being of service to the reader to being of service to the editor. This implies formal processes and wikijargon for consistency, unified templates for issues in the article, clear and ruthless labelling of problems and so on. There's a strong tendency for the first experience of an editor to be a very public and humiliating fight against established editors who have a better understanding of wikipedia processes, quickly driving the editor away or getting them blocked. It is also very difficult to improve on this experience as it would imply fundamental changes affecting all sorts of things. Meanwhile improving an article in draft mode allows for a more informal process of communication to shepherd an article towards an acceptable state. Fangz (talk) 19:10, 26 September 2024 (UTC)

  I did a little work on page view statistics recently. The median article gets about one page view per week. So if the new article is typical, then it doesn't have to "be of service to the reader", because there aren't really any readers. Editors (especially NPP and RecentChanges folks) may look at a brand-new article a few dozen times on the first day, but once the reviewers leave it alone, most articles just don't have much traffic.

  I think the reason we are unwilling to "improve it in mainspace" is because we're scared that we'll forget that it was there, and years later, someone will be embarrassed to discover that an WP:UGLY article has been neglected ever since. We are using draftification and other threats as a way to make other WP:VOLUNTEERS improve the article to our idea of acceptable quality. WhatamIdoing (talk) 20:40, 26 September 2024 (UTC)

  I don't know if we're looking at different draft namespaces, but an "informal process of communication to shepherd an article towards an acceptable state" sounds like the precise opposite of our current AfC process. – Joe (talk) 06:19, 27 September 2024 (UTC)

I don't like the idea of a button but I do think the template should be changed. I think having a button suggests it's a default option, but I think a link is okay. Fangz (talk) 12:37, 26 September 2024 (UTC)

• This is pretty much what {{subst:draft article}} does but MoveToDraft uses {{subst:AfC submission/draft}} for whatever reason. C F A 💬 12:41, 26 September 2024 (UTC)

  For the record, I would support using either {{draft article}} or creating a new template with your proposed changes. C F A 💬 12:44, 26 September 2024 (UTC)

  All AfC drafts are supposed to use the AfC template. If you're talking about the "publish now" button, that's for autoconfirmed only. Aaron Liu (talk) 12:45, 26 September 2024 (UTC)

  But articles aren't inherently "AfC drafts" once draftified. People are allowed to move them back to mainspace themselves, no questions asked, or optionally submit them to AfC. The AfC draft template makes no mention of the first option. C F A 💬 12:48, 26 September 2024 (UTC)

  BTW, the MTD script was changed yesterday to use {{draft article}}. -MPGuy2824 (talk) 12:48, 26 September 2024 (UTC)

  Oh, I didn't notice. That's better, at least. C F A 💬 12:49, 26 September 2024 (UTC)

  I wonder if we will ever quit using the inappropriate and legally unsound "publication" language in that template. On this wiki, it's the author, not the AFC reviewer, who "publishes" it. WhatamIdoing (talk) 20:43, 26 September 2024 (UTC)

  @WhatamIdoing: Can you think of a better word? (Seriously, I've been trying for ages and can't come up with anything.) – Joe (talk) 07:33, 27 September 2024 (UTC)

  Yes: WP:MOVE. WhatamIdoing (talk) 20:28, 27 September 2024 (UTC)

  Well, that might solve the problem. I doesn't explain to new users how their article turned into a draft, but at least there's an easy way to reverse it. I won't withdraw this for now, maybe others have thoughts. (P.S. you might want to update User:MPGuy2824/MoveToDraft) Toadspike [Talk] 12:51, 26 September 2024 (UTC)

• This is the idea lab so no bolded comment from me, but I have mixed feelings. I am in favour of softening the experience for newcomers, but I'm opposed to the concept of draftification being automatically reversible. If a new page patroller reviews a new article and moves it to draft because it's clearly unsuitable for mainspace, the creator should need to do more than just say "I object" in order to move their clearly unsuitable article back again. I've recently proposed that all of draftspace should be move-protected at the semi level (the proposal was not well received - fair enough). This is probably the rule I ignore more than any other on Wikipedia, mostly dealing with spam sockfarms that try to abuse the rule to promote their garbage. Besides, a new user whose submission is quarantined to draft space and they're left with instructions and a list of suggestions with helpful links is already getting better treatment than most editors ever have or will, and if their reaction to that is to rage-quit then they're probably not a good fit for the collaborative environment of Wikipedia anyway. Ivanvector (^Talk/_Edits) 12:57, 26 September 2024 (UTC)

  @Ivanvector, you know the joke about "If you ask three people, you'll get four opinions"? I wonder if we ask three NPPers what "ready for mainspace" means, if we'd get four opinions. AFAICT, "ready for mainspace" most often means "contains at least as many refs as the median article, but higher quality ones". All the children in Lake Wobegon are above average, and all the new Wikipedia articles must be, too. WhatamIdoing (talk) 20:12, 26 September 2024 (UTC)

  I feel like I might vaguely recall a discussion on that topic sometime in the not too distant past. Folly Mox (talk) 22:55, 26 September 2024 (UTC)

  176 comments from 22 editors, and I probably had 22 opinions all by myself. ;-) WhatamIdoing (talk) 22:23, 27 September 2024 (UTC)

• As far as I see it draftification should never be used for subjects which pass GNG, and it should only be standard for things like films/TV series/games which are in the works but have not yet begun production. Subjects with debatable notability should be sent to AFD to the issue can be resolved.★Trekker (talk) 13:00, 26 September 2024 (UTC)

  Subjects that pass WP:GNG should never be draftified at all, instead they should be tagged and dealt with using normal community procedures. I agree that films/TV series/games/political events probably best fit the bill for draftifications, but so do potentially notable but underdeveloped articles. Sohom (talk) 13:33, 26 September 2024 (UTC)

  This is out of step with the present form of Wikipedia:DRAFTIFY, and I don't think it makes sense anyway. Articles that fail GNG should not be draftified, they should be AfDed. Films etc that are in the works should not be draftified merely because they aren't in production, and it's not really a great use for draft space because there's no guarantee that there would be a change of situation to establish notability within 6 months. Articles should be draftified only if the reviewer believes the article can be editted into an acceptable state within the time window. This implies a pass of GNG - i.e. a belief that reliable sources are potentially out there. Remember that GNG is about the *subject*, not about the state of the article. Fangz (talk) 14:09, 26 September 2024 (UTC)

  In my view the correct use of draftification is sort of as an alternative version of the WIP template. An acknowledgement that the article is not ready and should be being worked on and will likely have multiple issues, but in a protected sandboxed environment to avoid overly zealous moderation and promotion of misunderstanding for casual readers, and without implying the original editor is the one working on it. For new users it should offer a less formal and jargony process to learning how to improve an article than tagging based methods, because the latter has to balance the need to inform *readers* as well as editors. Fangz (talk) 14:23, 26 September 2024 (UTC)

  If you evaluate that a article passes WP:GNG, then there is not point in draftifying it, you could just add a {{sources exist}} template, patrol and move on. Alternatively, if you evaluate that a article fails WP:GNG, there is no point in wasting the article creator's time and you should WP:AFD/PROD it.

  The only case where you would draftify a article is if you saw a article that a) had a credible claim to significance/notability b) does not meet/prove notability in it's current state c) has been created in the last week or so by a inexperienced article creator. Sohom (talk) 14:43, 26 September 2024 (UTC)

  Not sure if we're disagreeing or we're having some semantics thing about what "passes GNG" means.

  But anyway there's issues beyond notability, in my view that's probably more useful. Fangz (talk) 15:08, 26 September 2024 (UTC)

  If an article has a credible chance of being kept or merged at AfD then it should not be draftified.

  If an article would definitely fail AfD and there is no editing that can fix that it should be sent to AfD. Thryduulf (talk) 15:57, 26 September 2024 (UTC)

  I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. It has its advantages. It should not be made a mandatory process by any means but just as some users prefer to work on articles as a draft and then push to the public wiki, it can be a better resolution to certain issues than the alternatives. Fangz (talk) 17:44, 26 September 2024 (UTC)

  I'm not sure that the Draft: namespace has any advantages over a user sandbox, and m:Research:Wikipedia article creation and m:Research:AfC processes and productivity says that the Draft: namespace is where articles go to die.

  I do think that we've fallen into a false binary here. The options are not "garbage in the mainspace" vs "auto-deleted as in the draftspace". There are other options (e.g., sticky prods for uncited articles, userification, bold stubbification, bold merging, developing a more consistent and predictable standard for evaluating articles, etc.). WhatamIdoing (talk) 20:20, 26 September 2024 (UTC)

  I think there is a argument to be made that this landscape might have changed a fair bit since this research was done. The latest data that these projects consider is from 2014-2017. WP:ACTRIAL happened after that research was done, and Wikipedia's policies have changed since those times. Sohom (talk) 20:48, 26 September 2024 (UTC)

  It's possible that things have changed, and I'm never one to turn down a new research project if you happen to be volunteering to do it (I believe that all the necessary data is public), but looking at the overall deletion rate in that namespace, it seems unlikely that the result will be materially different. WhatamIdoing (talk) 20:31, 27 September 2024 (UTC)

  I think then you're pretty much arguing that the draftification process should be removed entirely, and I don't agree with that. I'm sorry to pick on you but this is the clearest example yet of the circular reasoning that has got us into this mess: draftification must be good because we do it, so we must keep doing it because it's good. From literally the moment draftspace was created and people started doing this (before that, the equivalent process of userfication was expressly forbidden without prior discussion), others have been pointing out that the underlying logic makes no sense. Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. But since fix good content in place is a part of the editing policy and almost all the community accepted reasons for deletion involve the potential of the article, not it's current state, the intersection of those two sets is functionally zero (apart from some consensus-established edge cases like paid creations or upcoming films).

  This is why attempts to clarify and improve policy around draftification—and I've been closely involved in many of them—keep failing. You try to find a solid basis for guidelines and there just isn't one. We really need to stop trying to square the circle of justifying draftification as it is practiced now, and start asking what we the community actually wants to achieve with it and whether what we're doing now fulfils that aim. So far it's not looking good for the send-them-all-to-draftspace-and-the-god-of-notability-will-recognise-his-own camp, because there's not a shred of evidence that it helps improve content, retain editors or manage the NPP workload, and as WAID says above the empirical studies we do have concluded the precise opposite. But that picture could change with more research – somebody just needs to step up and do it! – Joe (talk) 07:01, 27 September 2024 (UTC)

  @Joe Roe Draftification is only for articles that shouldn't be deleted, but it's also only for articles that can't be in mainspace. That is the exact reason why draftspace exists in the first place. Imagine you see a article with the following content: Nicholas Carlini is an amazing researcher at Google working on adversarial machine learning. created in the last week or so and sourced to a person's personal web-page. On doing a quick google search, you see that the person exists and is a researcher at said company, however, due to your unfamiliarity with adversarial machine learning topic-area you are not able to immediately identify the person's impact on the field. Do you 1) WP:BITEly nominate the article for deletion 2) leave the content up for somebody to deal with it (and hope that the other somebody will not choose option 1) or 3) draftify the article with a note that more sources are required to prove notability? Sohom (talk) 11:25, 27 September 2024 (UTC)

  @Sohom Datta None of them. What you do is add a template to the article noting the lack of sources, leave a friendly message on the creator's talk page explaining the issues in plain English, and leave a note about it at Wikipedia talk:WikiProject Computer science. Depending on what your research found you could add more information, add some sources that might or might not demonstrate notability, remove the peacock terms, etc. Yes, this is more effort than blinding draftifying or AfDing but it is far more important that things get done well than things get done quickly. Thryduulf (talk) 12:37, 27 September 2024 (UTC)

  @Sohom Datta, thanks for creating Nicholas Carlini, whose first version does not contain the hypothetical sentence you gave in your comment above. In your example above, why can't that stay in the mainspace? I frankly don't love it, and I'd immediately pull the word "amazing" out, but what's the policy basis for saying "that article truly can't be in mainspace"? WhatamIdoing (talk) 21:10, 27 September 2024 (UTC)

  @Fangz I'm not arguing for the elimination of draftspace, it has it's uses as an optional space where articles can be developed over time so they don't have to meet all the relevant content policies from the very first edit. I'm also not arguing for the elimination of all draftifcation, just the majority of unilateral draftification because, as Joe has put better than I can, it is not a net benefit to the project as currently practised. Thryduulf (talk) 12:46, 27 September 2024 (UTC)

If a new editor thinks their article is ready for mainspace, they will put it there. They will also happily revert the move. If a new editor is unsure, they will probably ask for help first or use draftspace. Cremastra (talk) 19:35, 26 September 2024 (UTC)

I think the concern expressed by Joe and others who support the "backdoor" theory is that new users do not know how to revert the move to draftspace. Do you disagree with that assumption? Toadspike [Talk] 19:53, 26 September 2024 (UTC)

I think most users do not know how to revert the move, yes. I also think we shouldn't hand it to them on a silver platter, because that likely largely annuls the whole point of draftification. What is the solution to this? I couldn't tell you. Cremastra (talk) 20:09, 26 September 2024 (UTC)

Is "the whole point of draftification" to make my view of the subject's value more powerful than the newbies' view? Security through obscurity kind of works for that, but not reliably. WhatamIdoing (talk) 20:22, 26 September 2024 (UTC)

They don't know how, maybe, but more importantly that they don't know that they're allowed to. We have to remember how very unusual our collaborative process is. If an inexperienced editor contributes an article to Wikipedia and then it is swiftly unpublished with a message that there's something wrong with it, they won't think, hmm, I'm not sure if I agree with that, I'm going to revert and/or discuss this with my peer-editors to find a consensus. They'll think that with someone the authority to decide what happens to articles has rejected my contribution, and I'm a mere newbie. At that point they will either give up (the majority) or they'll persevere and get into cycle of trying to satisfy first the NPP reviewer and then a succession of AfC reviewers until they finally give up or manage to write a GA, which seems to be roughly the standard AfC is applying these days Even very experience editors fall into this trap because even though the templated messages try to communicate the full range of options the user has (now at least, after I and others have spent several years fighting for it), it's really hard to communicate that we're all equal and all have a say here within a draft–review structure that implicitly elevates the opinions of reviewers over others. – Joe (talk) 07:31, 27 September 2024 (UTC)

I've pulled the most recent 10 articles moved to mainspace with the AFCH script. They are:

• 607th Air Control Squadron – 80 words per Wikipedia:Prosesize, 2 refs: Stub per mw:ORES article quality rating.
• Will Putnam – 296 words, 15 refs: Start.
• Coat of arms of Saskatoon – 380 words, 4 refs: Start.
• Urban Realism – 304 words, 4 refs: Start.
• Devara: Part 1 (soundtrack) – 547 words, 29 refs: C class.
• Honor Thy Father and Mother: The True Story of the Menendez Murders – 562 words, 8 refs: C class.
• XP-21279 – 200 words, 11 refs: Start.
• Crew Dragon Launch Abort System – 641 words, 23 refs: B class.
• Vince Zampella – 536 words, 18 refs: C class.
• Jeffrey Kahn – 179 words, 14 refs: Start class.

That's an average of 372.5 words and 12.6 refs. The median article has 338 words and 4 refs. Compared to existing articles, 53% of our existing articles have fewer than 372.5 words, and 83% have fewer fewer than 12.6 refs. One in six articles has fewer words than the shortest in this list. One of three articles is shorter than the second-shortest in this list.

I think it is clear from these numbers that AFC is expecting more refs than existing community practice, and that they are trying to accept only articles that are already as long as ones that editors have been working on in the mainspace for years.

BTW, during the same span of time, more than 100 pages were deleted from the Draft: namespace. You shouldn't assume this means that more than 90% of drafts get deleted, because deletions are bursty and this is a relatively small sample size, but that's about what I expected. WhatamIdoing (talk) 20:56, 27 September 2024 (UTC)

• A Conclusion: I am sadly not surprised at the current state of this discussion. Some of the heated off-topic arguments verge on NOTHERE behavior. I am very disappointed to see this from experienced editors. To those of you who simply commented on the proposal: I appreciate you a lot.

Since the default NPP draft template was changed to Template:Draft article a day before this discussion began, I think my proposal is moot. I don't see how we could improve that template much, but I may raise some minor wording changes on the Template Talk. If someone wants to close this discussion, that's fine; if others wish to continue discussing other things here, I wish you the all best. Toadspike [Talk] 21:16, 27 September 2024 (UTC)

Worth also talking about the usertalk notification MTD leaves, which only provides one option: submit for review. Agree in principle we shouldn't trick people into thinking draftification/AfC is mandatory for a typical article creator. — Rhododendrites ^talk \\ 13:29, 28 September 2024 (UTC)

Can we consider EC level pending changes?

This is just an idea, and I want to workshop this a bit more, but I think it would be helpful to have pending changes at the extended confirmed level. This could be called "PC2" again (not to be confused with the original PC2) or "PCECP". The idea would be to help enforce WP:ARBECR and similar restrictions where non-extended confirmed users are prohibited from certain topic areas. Under this level, edits by non-extended-confirmed editors would be held for review, while extended confirmed users can approve these edits and thus take responsibility under WP:PROXYING.

I think it would be helpful for pages where (1) parts of the article intersect with a contentious topic, or (2) the article in its entirety intersects with a contentious topic, but not edited frequently. Awesome Aasim 16:54, 27 September 2024 (UTC)

This seems like it could be useful. It would have to be restricted to infrequently edited pages (likely excluding all current events articles) so as not to overwhelm Pending Changes every time Reuters publishes a new story or an edit war erupts. The big question is: what problem are you trying to solve? Toadspike [Talk] 20:39, 27 September 2024 (UTC)

There are some contentious topics designated either by ArbCom or the community where only extended confirmed users are allowed to participate. However, admins refuse to protect pages where there isn't enough disruption to justify protection. Although, it should be considered that the XCON restriction applies regardless of whether a page is protected or not.

What PCECP would do is essentially remove fears that there "isn't enough disruption to justify protection" while buffering all non-extended-confirmed contributions so they have to be approved, in line with "non-extended-confirmed can only make edit requests". Templates that are specifically for this case like {{edit protected}} break when the page is not protected. Awesome Aasim 22:00, 27 September 2024 (UTC)

The problem with that is that the 500/30 rule is specifically designed to keep newer editors out due to extreme amounts of disruption as a rule. There's a good reason why both of the world's main hot wars (the Arab-Israeli conflict and the Russo-Ukrainian war) are under 500/30. And, as has been brought up repeatedly and bears repeating again, high volumes of edits on a given article contraindicate CRASHlock.

But the biggest stumbling block here is that no consensus exists yet for an extended-confirmed CRASHlock. The last discussion about expanding CRASHlock to higher protection levels predates XCP entirely. There would need to be a formal RfC for this, not VP spitballing. —Jéské Couriano v^_^v ^{threads critiques} 15:37, 28 September 2024 (UTC)

XCON protection makes sense for high traffic articles, but low traffic articles? If the edit is minor such as fixing spelling mistakes or grammatical errors, there should be no problem. Fixing spelling and grammar is generally outside of contentious topic areas anyway. From WP:ARBECR: On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by other methods, including ... the use of pending changes.

I probably would set up abuse filters as well to see if a page is in a category that primarily deals with a contentious topic, and then warn and tag the edit in question. Awesome Aasim 16:22, 28 September 2024 (UTC)

Seems reasonable. I've always wondered why pending changes isn't deployed more often. It seems a useful tool, and there are lots of pending changes reviewers so very little backlog Cremastra (talk) 14:18, 28 September 2024 (UTC)

Because there are enough people who dislike or distrust pending changes that it's hard to get a consensus to use it. See, for example, Wikipedia:Village pump (proposals)/Archive 183#RFC: Pending-changes protection of Today's featured article. Anomie⚔ 14:41, 28 September 2024 (UTC)

Well, gee, I fucking wonder why? —Jéské Couriano v^_^v ^{threads critiques} 15:39, 28 September 2024 (UTC)

Would you care to elaborate on your point? I'm not seeing it. Anomie⚔ 17:04, 28 September 2024 (UTC)