Wikipedia:Village pump (proposals)

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following list: Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Should a new pending changes protection level - extended confirmed pending changes (hereby abbreviated as PCECP) - be added to Wikipedia? Awesome Aasim 19:58, 5 November 2024 (UTC)Reply

WP:ARBECR (from my understanding) encourages liberal use of EC protection in topic areas authorized by the community or the arbitration committee. However, some administrators refuse to protect pages unless if there is recent disruption. Extended confirmed pending changes would allow non-XCON users to propose changes for them to be approved by someone extended confirmed, and can be applied preemptively to these topic areas.

It is assumed that it is technically possible to have PCECP. That is, we can have PCECP as "[auto-accept=extended confirmed users] [review=extended confirmed users]" Right now it might not be possible to have extended confirmed users review pending changes with this protection with the current iteration of FlaggedRevs, but maybe in the future.

• Support for multiple reasons: WP:ARBECR only applies to contentious topics. Correcting typos is not a contentious topic. Second, WP:ARBECR encourages the use of pending changes when protection is not used. Third, pending changes effectively serves to allow uncontroversial edit requests without needing to create a new talk page discussion. And lastly, this is within line of our protection policy, which states that protection should not be applied preemptively in most cases. Awesome Aasim 19:58, 5 November 2024 (UTC)Reply
• Support (per... nom?) PC is the superior form of uncontroversial edit requests. Aaron Liu (talk) 20:09, 5 November 2024 (UTC)Reply

  It's better than EC, which already restricts being the free encyclopedia more. As I've said below, the VisualEditor allows much more editing from new people than edit requesting, which forces people to use the source editor. Aaron Liu (talk) 03:52, 6 November 2024 (UTC)Reply

  This is not somehow less or more restrictive as ECR. It's exactly the same level of protection, just implemented in a different way. I do not get the !votes from either side who either claim that this will be more restriction or more bureaucracy. I understand neither, and urge them to explain their rationales. Aaron Liu (talk) 12:32, 12 November 2024 (UTC)Reply

  By creating a difference between what non logged-in readers (that is, the vast majority of them) see versus logged-in users, there is an extra layer of difficulty for non-confirmed and non-autoconfirmed editors, who won't see the actual page they're editing until they start the editing process. Confirmed and autoconfirmed editors may also be confused that their edits are not being seen by non-logged in readers. Because pending changes are already submitted into the linear history of the article, unwinding a rejected edit is potentially more complicated than applying successive edit requests made on the talk page. (This isn't a significant issue when there aren't many pending changes queued, which is part of the reason why one of the recommended criteria for applying pending changes protection is that the page be infrequently edited.) For better or worse, there is no deadline to process edit requests, which helps mitigate issues with merging multiple requests, but there is pressure to deal with all pending changes expediently, to reduce complications in editing. isaacl (talk) 19:54, 12 November 2024 (UTC)Reply

  Do you think this would be fixed with "branching" (similar to GitHub branches)? In other words, instead of PC giving the latest edit, PC just gives the edit of the stable revision and when "Publish changes" is clicked it does something like put the revision in a separate namespace (something like Review:PAGENAME/#######) where ####### is the revision ID. If the edit is accepted, then that page is merged and the review deleted. If the edit is rejected the review is deleted, but can always be restored by a Pending Changes Reviewer or administrator. Awesome Aasim 21:01, 12 November 2024 (UTC)Reply

  Technically, that would take quite a bit to implement. Aaron Liu (talk) 23:18, 12 November 2024 (UTC)Reply

  There are a lot of programmers who struggle with branching; I'm not certain it's a great idea to make it an integral part of Wikipedia editing, at least not in a hidden, implicit manner. If an edit to an article always proceeded from the last reviewed version, editors wouldn't be able to build changes on top of their previous edits. I think at a minimum, an editor would have to be able to do the equivalent of creating a personal working branch. For example, this could be done by working on the change as a subpage of the user's page (or possibly somewhere else (perhaps in the Draft namespace?), using some standard naming hierarchy), and then submitting an edit request. That would be more like how git was designed to enable de-centralized collaboration: everyone works in their own repository, rebasing from a central repository (*), and asks an integrator to pull changes that they publish in their public repository.

  (*) Anyone's public repository can act as a central repository. It just has to be one that all the collaborators agree upon using, and thus agree with the decisions made by the integrator(s) merging changes into that repository. isaacl (talk) 23:22, 12 November 2024 (UTC)Reply

  That makes sense. This has influenced me to amend my Q2 answer slightly, but I still support the existence of this protection and the preemptive PC protecting of low-traffic pages. (Plus, it's still not more restriction.) Aaron Liu (talk) 23:20, 12 November 2024 (UTC)Reply

• Support, functionally a more efficient form of edit requests. The volume of pending changes is still low enough for this to be dealt with, and it could encourage the pending changes reviewer right to be given to more people currently reviewing edit requests, especially in contentious topics. Chaotic Enby (talk · contribs) 20:25, 5 November 2024 (UTC)Reply
• Support having this as an option. I particularly value the effect it has on attribution (because the change gets directly attributed to the individual who wanted it, not to the editor who processed the edit request). WhatamIdoing (talk) 20:36, 5 November 2024 (UTC)Reply
• Support: better and more direct system than preemptive extended-confirmed protection followed by edit requests on the talk page. Cremastra (u — c) 20:42, 5 November 2024 (UTC)Reply
• Support, Pending Changes has the capacity to take on this new task. PC is much better than the edit request system for both new editors and reviewers. It also removes the downsides of slapping ECP on everything within contentious topic areas. Toadspike [Talk] 20:53, 5 November 2024 (UTC)Reply

  I've read the opposes below and completely disagree that this would lead to more gatekeeping. The current edit request system is extremely complicated and inaccessible to new users. I've been here for half a decade and I still don't really know how it works. The edit requests we do get are a tiny fraction of the edits people want to make to ECP pages but can't. PCECP would allow them to make those edits. And many (most?) edit requests are formatted in a way that they can't be accepted (not clear what change should be made, where, based on what souce), a huge issue which would be entirely resolved by PCECP.

  The automatic EC protection of all pages in certain CTOPs is not the point of this proposal. Whether disruption is a prerequisite to protection is not altered by the existence of PCECP and has to be decided in anther RfC at another venue, or by ArbCom. PCECP is solely about expanding accessibility to editing ECP pages for new and unregistered editors, which is certainly a positive move.

  I, too, hate the PC system at dewiki, and I appreciate that Kusma mentioned it. However, what we're looking at here is lowering protection levels and reducing barriers to editing, which is the opposite of dewiki's PC barriers. Toadspike [Talk] 10:24, 16 November 2024 (UTC)Reply

• Support (Summoned by bot): per above. C F A 💬 23:34, 5 November 2024 (UTC)Reply
• Support : Per above. PC is always at a low or very low backlog, therefore is completely able to take this change. ~/Bunnypranav:<ping> 11:26, 6 November 2024 (UTC)Reply
• Support: I would be happy to see it implemented. GrabUp - Talk 15:14, 6 November 2024 (UTC)Reply
• Support Agree with JPxG's principle that it is better to "have drama on a living project than peace on a dead one," but this is far less restrictive than preemptively setting EC protection for all WP:ARBECR pages. From a new editor's perspective, they experience a delay in the positive experience of seeing their edit implemented, but as long as pending changes reviewers are equipped to minimize this delay, then this oversight seems like a net benefit. New users will get feedback from experienced editors on how to operate in Wikipedia's toughest content areas, rather than stumbling through. ViridianPenguin 🐧 ( 💬 ) 08:57, 8 November 2024 (UTC)Reply
• Support * Pppery * _{it has begun...} 05:17, 11 November 2024 (UTC)Reply
• Support Idk what it's like in other areas but in mine, of edit requests that I see, a lot, maybe even most of them are POV/not actionable/nonsense/insults so if it is already ECR only, then yea, more filtering is a good thing.Selfstudier (talk) 18:17, 11 November 2024 (UTC)Reply
• Support assuming this is technically possible (which I'm not entirely sure it is), it seems like a good idea, and would definitely make pending changes more useful from my eyes. Zippybonzo | talk | contribs (they/them) 20:00, 12 November 2024 (UTC)Reply
• Strong support per @JPxG:'s reasoning—I think it's wild that we're willing to close off so many articles to so many potential editors, and even incremental liberalization of editing restrictions on these articles should be welcomed. This change would substantially expand the number of potential editors by letting non-EC contributors easily suggest edits to controversial topic areas. It would be a huge win for contributions if we managed to replace most ECP locks with this new PCECP.– Closed Limelike Curves (talk) 02:07, 14 November 2024 (UTC)Reply
• Yes, in fact, somebody read my mind here (I was thinking about this last night, though I didn't see this VP thread... ) Myrealnamm (💬Let's talk · 📜My work) 21:38, 14 November 2024 (UTC)Reply
• Support in principle. Edit requests are a really bad interface for new users; if discouraging people from editing is the goal, we've succeeded. Flagged revisions aren't the best, but they are better than edit request templates. Toadspike's reasoning hasn't been refuted. Right now, it seems like opposers aren't aware that the status quo for many Palestine-Israel related articles is ECP. Both Israeli cuisine and Palestinian cuisine are indefinitely under WP:ECP due to gastronationalist arguments about the politics of food in the Arab–Israeli conflict (a page not protected), so editors without 500/30 status cannot add information about falafels to Wikipedia.
  That being said, this proposal would benefit from more detail. For example, the current edit request policy requires the proposed change to be uncontroversial and puts the burden on the proposer to show that it is uncontroversial. On the other hand, the current review policy assumes a change is correct unless it's obvious vandalism or the like, which would be a big change to the edit request workflow. Likewise, what counts as WP:INVOLVED for reviewers? Right now, there's a big firewall between editors involved in content in an area like Israel-Palestine and admins using their powers in that area. Can reviewers edit in the area and use their tools? This needs to be clarified, as it seems like editing in PIA doesn't disqualify one from answering edit requests. Chess (talk) (please mention me on reply) 21:06, 18 November 2024 (UTC)Reply

  the current review policy assumes a change is correct unless it's obvious vandalism or the like

  @Chess That's true, but reviewers are also currently expected to accept and revert if the change is correct but also irky for a revert. Below, Aasim clarified that reviewers should only reject edits that fail the existing PC review guidelines plus edits made in violation of an already well-established consensus.
  As for Involved, since there's no guidance about edit request reviewers yet either, I think that should be asked in a separate RfC. Aaron Liu (talk) 21:35, 18 November 2024 (UTC)Reply

• Support. The number of sysops is ever decreasing and so we will need to take drastic action to ensure maintenance and vandalism prevention can keep up. Stifle (talk) 17:29, 19 November 2024 (UTC)Reply

• Oppose There's a lot of history here, and I've opposed WP:FPPR/FlaggedRevs consistently since ~2011. Without reopening the old wounds over how the initial trial was implemented/ended, nothing that's happened since has changed my position. I believe that proceeding with an expansion of FlaggedRevs would be a further step away from our commitment to being the free encyclopedia that anyone can edit without actually solving any critical problems that our existing tools aren't already handling. While the proposal includes However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive. In fact that's the entire point; protection should be preventative and there should be evidence of recent disruption. If a page is experiencing disruption, protection can handle it. If not, there's no need to limit anyone's ability to edit. The Wordsmith^{Talk to me} 03:45, 6 November 2024 (UTC)Reply

  The Wordsmith, regarding "However, some administrators refuse to protect pages unless if there is recent disruption as a problem, I see that as a positive.", for interest, I see it as a negative for a number of reasons, at least in the WP:PIA topic area, mostly because it is subjective/non-deterministic.

  • The WP:ARBECR rules have no dependency on subjective assessments of the quality of edits. Non-EC editors are only allowed to make edit requests. That is what we tell them.
    • If it is the case that non-EC editors are only allowed to make edit requests, there is no reason to leave pages unprotected.
    • If it is not the case that non-EC editors can only allowed to make edit requests, then we should not be telling them that via talk page headers and standard notification messages.
  • There appears to be culture based on an optimistic faith-based belief that the community can see ARBECR violations, make reliable subjective judgements based on some value system and deal with them appropriately through action or inaction. This is inconsistent with my observations.
    • Many disruptive violations are missed when there are hundreds of thousands of revisions by tens of thousands of actors.
    • The population size of editors/admins who try to address ARBECR violations is very small, and their sampling of the space is inevitably an example of the streetlight effect.
    • The PIA topic area is largely unprotected and there are thousands of articles, templates, categories, talk pages etc. Randomness plays a large part in ARBECR enforcement for all sorts of reasons (and maybe that is good to some extent, hard to tell).
  • Wikipedia's lack of tools to effectively address ban evasion in contentious topic areas means that it is not currently possible to tell whether a revision by a non-EC registered account or IP violating WP:ARBECR that resembles an okay edit (to me personally with all of my biases and unreliable subjectivity) is the product of a helpful person or a ban evading recidivist/member of an off-site activist group exploiting a backdoor.

  Sean.hoyland (talk) 08:00, 6 November 2024 (UTC)Reply

• Oppose I am strongly opposed to the idea of getting yet another level of protection for the sole purpose of using it preemtively, which has never been ok and should not be ok. Just Step Sideways ^{from this world ..... today} 21:25, 6 November 2024 (UTC)Reply
• Oppose, I hate pending changes. Using them widely will break the wiki. We need to be as welcoming as possible to new editors, and the instant gratification of wiki editing should be there on as many pages as possible. —Kusma (talk) 21:47, 6 November 2024 (UTC)Reply

  @Kusma Could you elaborate on "using them widely will break the wiki", especially as we currently have the stricter and less-friendly EC protection? Aaron Liu (talk) 22:28, 6 November 2024 (UTC)Reply

  Exhibit A is dewiki's 53-day Pending Changes backlog. —Kusma (talk) 23:03, 6 November 2024 (UTC)Reply

  We already have a similar and larger backlog at CAT:EEP. All this does is move the backlog into an interface handled by server software that allows newcomers to use VE for their "edit requests", where currently they must use the source editor due to being confined to talk pages. Aaron Liu (talk) 23:06, 6 November 2024 (UTC)Reply

  The dewiki backlog is over 18,000 pages. CAT:EEP has 54. The brokenness of optional systems like VE should not be a factor in how we make policy. —Kusma (talk) 09:40, 7 November 2024 (UTC)Reply

  The backlog will not be longer than the EEP backlog. (Also, I meant that EEP's top request was over 3 months ago, sorry.) Aaron Liu (talk) 12:23, 7 November 2024 (UTC)Reply

  ... if the number of protected pages does not increase. I expect an increase in protected pages from the proposal, even if the terrifying proposal to protect large classes of articles preemptively does not pass. —Kusma (talk) 13:08, 7 November 2024 (UTC)Reply

  Why so? Aaron Liu (talk) 13:33, 7 November 2024 (UTC)Reply

  Most PCECP pages should be ECP pages (downgraded?) as they have lesser traffic/disruption. So, the number of pages that will be increase should not be that much. ~/Bunnypranav:<ping> 13:35, 7 November 2024 (UTC)Reply

  @Kusma Isn't the loss of instant gratification of editing better than creating a request on the talk page of an ECP page, and having no idea by when will it be reviewed and implemented. ~/Bunnypranav:<ping> 11:25, 7 November 2024 (UTC)Reply

  With PC you also do not know when or whether your edit will be implemented. —Kusma (talk) 13:03, 7 November 2024 (UTC)Reply

• Oppose — Feels unnecessary and will only prevent other good faith editors from editing, not to mention the community effort required to monitor and review pending changes requests given that some areas like ARBIPA apply to hundreds of thousands of pages. Ratnahastin (talk) 01:42, 7 November 2024 (UTC)Reply

  @Ratnahastin Similar to my above question, won't this encourage more good faith editors compared to a literal block from editing of an ECP page? ~/Bunnypranav:<ping> 11:32, 7 November 2024 (UTC)Reply

  There is a very good reason I reference Community Resources Against Street Hoodlums in my preferred name for the protection scheme, and the answer is generally no since the topic area we are primarily talking about is an ethno-political contentious topic, which tend to draw partisans interested only in "winning the war" on Wikipedia. This is not limited to just new users coming in, but also established editors who have strong opinions on the topic and who may be put into the position of reviewing these edits, as a read of any random Eastern Europe- or Palestine-Israel-focused Arbitration case would make clear just from a quick skim. —Jéské Couriano v^_^v ^{threads critiques} 18:21, 7 November 2024 (UTC)Reply

  Aren't these problems that can also be seen to the same extent in edit requests if they exist? Aaron Liu (talk) 19:10, 7 November 2024 (UTC)Reply

  A disruptive/frivolous edit request can be summarily reverted off to no damage as patently disruptive/frivolous without implicating the 1RR in the area. As long as it's not vandalism or doesn't introduce BLP violations, an edit committed to an article that isn't exactly helpful is constrained by the 1RR, with or without any sort of protection scheme. —Jéské Couriano v^_^v ^{threads critiques} 16:21, 8 November 2024 (UTC)Reply

  Patently disruptive and frivolous edits are vandalism, emphasis on "patently". Aaron Liu (talk) 16:28, 8 November 2024 (UTC)Reply

  POV-pushing is not prima facie vandalism. —Jéské Couriano v^_^v ^{threads critiques} 16:32, 8 November 2024 (UTC)Reply

  POV-pushing isn't patently disruptive/frivolous and any more removable in edit requests. Aaron Liu (talk) 16:45, 10 November 2024 (UTC)Reply

  But edit requests make it harder to actually push that POV to a live article. —Jéské Couriano v^_^v ^{threads critiques} 17:22, 11 November 2024 (UTC)Reply

  Same with pending changes. Aaron Liu (talk) 17:36, 11 November 2024 (UTC)Reply

  Maybe in some fantasy land where the edit didn't need to be committed to the article's history. —Jéské Couriano v^_^v ^{threads critiques} 18:08, 11 November 2024 (UTC)Reply

  Except that is how pull requests work on GitHub. You make the edit, and someone with reviewer permissions approves it to complete the merge. Here, the "commit" happens, but the revision is not visible until reviewed and approved. Edit requests are not pull requests, they are the equivalent of "issues" on GitHub. Awesome Aasim 19:03, 11 November 2024 (UTC)Reply

  It may come as a surprise, but Wikipedia is not GitHub. While they are both collaborative projects, they are very different in most other respects. Thryduulf (talk) 19:20, 11 November 2024 (UTC)Reply

  With Git, submitters make a change in their own branch (which can even be in their own repository), and then request that an integrator pull that change into the main branch. So the main branch history remains clean: it only has changes that were merged in. (It's one of the guiding principles of Git: allow the history tree of any branch to be simplified to improve clarity and performance.) isaacl (talk) 22:18, 11 November 2024 (UTC)Reply

  Edit requests are supposed to be pull requests.

  Clearly indicate which sections or phrases should be replaced or added to, and what they should be replaced with or have added.
  — WP:ChangeXY

  Aaron Liu (talk) 22:51, 11 November 2024 (UTC)Reply

  Yeah that is what they are supposed to be but in practice they are not. As anyone who has answered edit requests before, there are often messages that look like this:

Extended content

It is requested that an edit be made to the extended-confirmed-protected article at Wikipedia. (edit · history · last · links · protection log) This template must be followed by a complete and specific description of the request, that is, specify what text should be removed and a verbatim copy of the text that should replace it. "Please change X" is not acceptable and will be rejected; the request must be of the form "please change X to Y". The edit may be made by any extended confirmed user. Remember to change the |answered=no parameter to "yes" when the request has been accepted, rejected or on hold awaiting user input. This is so that inactive or completed requests don't needlessly fill up the edit requests category. You may also wish to use the {{EEp}} template in the response. To request that a page be protected or unprotected, make a protection request. The reference is wrong. Please fix it. 192.0.0.1 (talk) 23:19, 11 November 2024 (UTC)Reply

• Which is not in practice WP:CHANGEXY. Awesome Aasim 23:19, 11 November 2024 (UTC)Reply

  I don't see how that's much of a problem, especially as edits are also committed to the talk page's history. Aaron Liu (talk) 22:50, 11 November 2024 (UTC)Reply

  Do the words "Provoke edit wars" mean anything? Talk page posts are far less likely to be the locus of an edit war than article edits. —Jéské Couriano v^_^v ^{threads critiques} 18:05, 14 November 2024 (UTC)Reply

  As an editor who started out processing edit requests, including ECP edit requests, I disagree. Aaron Liu (talk) 18:08, 14 November 2024 (UTC)Reply

• Oppose, per what JSS has said. I am a little uncomfortable at the extent to which we've seemingly accepted preemptive protection of articles in contentious areas. It may be a convenient way of reducing the drama us admins and power users have to deal with... but only at the cost of giving up on the core principle that anybody can edit. I would rather have drama on a living project than peace on a dead one. jp×g🗯️ 18:16, 7 November 2024 (UTC)Reply
• Oppose I am one of those admins who likes to see disruption before protecting. Lectonar (talk) 08:48, 8 November 2024 (UTC)Reply
• Oppose as unnecessary, seems like a solution in search of a problem. Furthermore, this *is* Wikipedia, the encyclopedia anyone can edit; preemptively protecting pages discourages contributions from new editors. -Fastily 22:36, 8 November 2024 (UTC)Reply
• Weak Oppose I do understand where this protection would be helpful. But I just think something is EC-protectable or not. Don't necessarily think adding another level of bureaucracy is particularly helpful. --Takipoint123 (talk) 05:14, 11 November 2024 (UTC)Reply
• Oppose. I'm inclined to agree that the scenarios where this tool would work a benefit as technical solution would be exceedingly niche, and that such slim benefit would probably be outweighed by the impact of having yet one more tool to further nibble away at the edges of the open spaces of the project which are available to new editors. Frankly, in the last few years we have already had an absurdly aggressive trend towards community (and ArbCom fiat) decisions which have increasingly insulated anything remotely in the vain of controversy from new editors--with predictable consequences for editor recruitment and retention past the period of early involvement, further exacerbating our workloads and other systemic issues. We honestly need to be rolling back some of these changes, not adding yet one more layer (however thin and contextual) to the bureaucratic fabric/new user obstacle course. SnowRise ^{let's rap} 11:23, 12 November 2024 (UTC)Reply
• Oppose. The more I read this discussion, the more it seems like this wouldn't solve the majority of what it sets out to solve but would create more problems while doing so, making it on balance a net negative to the project. Thryduulf (talk) 21:43, 12 November 2024 (UTC)Reply
• Oppose and Point of Order Oppose because pending changes is already too complicated and not very useful. I'm a pending changes reviewer and I've never rejected one on PC grounds (basically vandalism). But I often revert on normal editor grounds after accepting on PC grounds. (I suspect that many PC rejections are done for non-PC reasons instead of doing this) "Point of Order" is because the RFC is unclear on what exactly is being opposed. Sincerely, North8000 (talk) 22:15, 12 November 2024 (UTC)Reply

  Pretty sure that what happens is that when vandals realize they will have to submit their edit for review before it goes live, that takes all the fun out of it for them because it will obviously be rejected, and they don't bother. That's pretty much how it was supposed to work. Just Step Sideways ^{from this world ..... today} 22:22, 12 November 2024 (UTC)Reply

  This is a very good point, and I ask for @Awesome Aasim's clarification on whether reviewers will be able to reject edits on grounds for normal reverts combined with the EC restriction. I think there's enough rationale to apply this here beyond the initial rationale for PC as explained by JSS above. Aaron Liu (talk) 23:24, 12 November 2024 (UTC)Reply

  Reviewers are given specific reasons for accepting edits (see Wikipedia:Pending changes § Reviewing pending edits) to avoid overloading them with work while processing pending changes expeditiously. If the reasons are opened up to greater evaluation of the quality of edits, then expectations may shift towards this being a norm. Thus some users are concerned this will create a hierarchy of editors, where edits by non-reviewers are gated by reviewers. isaacl (talk) 23:44, 12 November 2024 (UTC)Reply

  I understand that and wonder how the reviewer proposes to address this. I would still support this proposal if having reviewers reject according to whether they'd revert and "ostensibly" to enforce EC is to be the norm, albeit to a lesser extent for the reasons you mentioned (though I'd replaced "non-reviewers" with "all non–auto-accepted"). Aaron Liu (talk) 00:13, 13 November 2024 (UTC)Reply

  I'm not sure to whom you are referring when you say "the reviewer" – you're the one suggesting there's a rationale to support more reasons for rejecting a pending change beyond the current set. Since any pending change in the queue will prevent subsequent changes by non-reviewers from being visible to most readers, their edits too will get evaluated by a single reviewer before being generally visible. isaacl (talk) 00:59, 13 November 2024 (UTC)Reply

  Sorry, I meant Aasim, the nominator. I made a thinko.
  Currently, reviewers can undo just the edits that aren't good and then approve the revision of their own revert. I thought that was what we were supposed to do. Aaron Liu (talk) 02:13, 13 November 2024 (UTC)Reply

  Yes. Anything that is obvious vandalism or a violation of existing Wikipedia's policies can still be rejected. However, for edits where there is no other problem, the edit can still be accepted. In other words, a user not being extended confirmed shall not be sufficient grounds for rejecting an edit under PCECP, since the extended confirmed user takes responsibility for the edit. If the extended confirmed user accepts a bad edit, it is on them, not whoever made it. That is the whole idea.

  Of course obviously helpful changes such as fixing typos and adding up-to-date information should be accepted sooner, while more controversial changes should be discussed first. Awesome Aasim 17:37, 13 November 2024 (UTC)Reply

  By or a violation of existing Wikipedia's policies, do you only mean violations of BLP, copyvio, and "other obviously inappropriate content" that may be very-quickly checked, which is the current scope of what to reject? Aaron Liu (talk) 17:41, 13 November 2024 (UTC)Reply

  Yeah, but also edits made in violation of an already well-established consensus. Edits that enforce a clearly-established consensus (proven by previous talk page discussion), are, from my understanding, exempt from all WP:EW restrictions. Awesome Aasim 18:38, 13 November 2024 (UTC)Reply

• Oppose per Thryduulf and SnowRose. Also regardless of whether this is a good idea as a policy, FlaggedRevs has a large amount of technical debt, to the extent that deployment to any additional WMF wikis is prohibited, so it seems unwise to expand its usage.  novov talk edits 19:05, 13 November 2024 (UTC)Reply
• Oppose I have never found the current pending changes system easily to navigate as a reviewer. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)Reply
• Oppose the more productive approach would be to reduce the overuse of extended-confirmed protection. We have come to rely on it too much. This would be technically difficult and complex for little real gain. —Ganesha811 (talk) 18:30, 16 November 2024 (UTC)Reply
• Oppose there might be a need for this but not preemptive. Andre🚐 01:31, 17 November 2024 (UTC)Reply
• Oppose. The pending changes system is awful and this would make it awfuler (that wasn't a word but it is now). Zero^talk 05:58, 17 November 2024 (UTC)Reply
• Oppose. How can we know that the 72,768 extended-confirmed users are capable of reviewing pending changes? I assume this is a step above normal PCP (eg. pcp is preferred over pcecp), how can reviewing semi-protected pending changes have a higher bar (requiring a request at WP:PERM) than reviewing extended-protected pending changes? Doesn't make much sense to me. — BerryForPerpetuity (talk) 14:15, 20 November 2024 (UTC)Reply

  I do not think that XCON are reviewers is fixed. This RfC is primarily about the creation of PCECP. ~/Bunnypranav:<ping> 14:21, 20 November 2024 (UTC)Reply

  Well, they're capable of reviewing edit requests. Aaron Liu (talk) 14:39, 20 November 2024 (UTC)Reply

  Sure, but assuming this will work the same as PCR, isn't it possible that an extended-confirmed user who doesn't want to review edits, will try to edit a PCECP page, and be required to review edits beforehand? They're not actively seeking out to review edits in the same way that a PCR or someone who handles edit requests does. Will their review be on par with the scrutiny required for this level of protection? — BerryForPerpetuity (talk) 14:55, 20 November 2024 (UTC)Reply

  You do not need to review edits to edit the pending version of the page, which is what happens when you press save on a page with pending edits. Aaron Liu (talk) 15:02, 20 November 2024 (UTC)Reply

  Is it not the case that reviewers need to check a page's pending changes to edit a page? Either way, the point of "what would constitute a revert" needs to be discussed and decided on before we start to implement this, which I appreciate you discussing above. — BerryForPerpetuity (talk) 15:38, 20 November 2024 (UTC)Reply

  No. It's just that if the newest change is not reviewed, the last reviewed change is shown to readers instead of the latest change. Aaron Liu (talk) 16:00, 20 November 2024 (UTC)Reply

  How can we know that the 72,734 extended-confirmed users are capable of reviewing pending changes? This isn't about pending changes level 1. This is about pending changes as applied to enforce ECP, with the level [auto-accept=extendedconfirmed] [review=extendedconfirmed]. As this is only intended to be used for WP:ARBECR restricted pages, it shouldn't be used for anything else.

  What might need to happen for this to work is there are ways to configure who can auto-accept and review changes individually (rather than bundled as is right now) with the FlaggedRevs extension. Something like this for these drop-downs:

  • Auto-accept:
    • All users
    • Autoconfirmed
    • Extended confirmed
    • Template editor
    • Administrators
  • Review:
    • Autoconfirmed
    • Extended confirmed and reviewers
    • Template editors and reviewers
    • Administrators

  Of course, autoreview will have auto-accept perms regardless of these settings, and review will have review perms regardless of these settings. Awesome Aasim 16:36, 20 November 2024 (UTC)Reply

  I understand what you're saying, and I'm aware this isn't about level 1. I'm not strongly opposed to PCECP, but my original point was talking about the difference in reviewer requirements for semi-protected PC and XCON PC. If this passes, it would make reviewing semi-protected pending changes require a permission request, but reviewing extended-protected pending changes would only require being extended-confirmed. If that could be explained so I could understand it better, I'd appreciate it.

  This also relates to edit requests. XCON users are capable of reviewing edit requests, because they don't have to implement what the request was verbatim. If a user makes a request that has good substance, but has a part that doesn't adhere to some policy (MOS, NPOV, ect), the reviewer can change it to fit policy. With pending changes, there's really no way to do that besides editing the accepted text after accepting it. The edit request reviewer can ask for clarification on something, add notes, give a reason for declining, ect.

  Especially on pages that have ARBCOM enforcement on them, the edit request system is far better than the pending changes system. This approach seems to be a solution for the problem of over-protection, which is what should actually be addressed. — BerryForPerpetuity (talk) 17:22, 22 November 2024 (UTC)Reply

  Personally, I would also support this change if only reviewers may accept.
  I think editing a change after acceptance is superior. It makes clear which parts were written by whom (and thus much easier to satisfy our CC license). Aaron Liu (talk) 17:43, 22 November 2024 (UTC)Reply

  Identifying which specific parts were written by whom isn't necessary for the CC BY-SA license. (And since each new revision is a new derivative work, it's not that easy to isolate.) isaacl (talk) 18:50, 22 November 2024 (UTC)Reply

  Right, but there's no need to forget the attributive edit summary, which is needed when accepting edit requests. Identifying specific parts is just cleaner this way. Aaron Liu (talk) 18:57, 22 November 2024 (UTC)Reply

  If the change is rejected, then a user who isn't an author of the content appears in the article history. In theory that would unnecessarily entangle the user in any copyright issues that arose, or possibly defamation cases. isaacl (talk) 22:55, 22 November 2024 (UTC)Reply

  I personally see that as a much lesser problem than the EditRequests issue. Aaron Liu (talk) 19:15, 23 November 2024 (UTC)Reply

  We should be maximizing the number of pages that are editable by all. Protection fails massively at this task. All this does is tell editors "hey don't edit this page", which is fine for certain legal pages and the main page that no one should really be editing, but for articles? There is a reason we have this thing called "code review" on Git and "peer review" everywhere else; we should be encouraging changes but if there is disruption we should be able to hold them for review so we can remove the problematic ones.

  Since Wikipedia is not configured to have software-based RC patrol outside of new pages patrol (and RC patrol would be a problem anyway not only because of the sheer volume of edits but also because edits older than a certain timeframe are removed from the patrol queue), we have to rely on other software measures to hide revisions until they are approved. Specifically, RC patrol hiding all edits until approved (wikiHow does this) would be a problem on Wikipedia. But that is a tangent. Awesome Aasim 19:43, 22 November 2024 (UTC)Reply

  There's also a reason why Git changes aren't pushed directly to the main code branch for review, and instead a pull request is sent to an integrator in order to integrate the changes. There's a bottleneck in processing the request (including integration testing). Also note with software development, rebasing your changes onto the latest integrated stream is your responsibility. The equivalent with pending changes would be for each person to revalidate their proposed change after a preceding change had been approved or rejected. Instead, the workload falls upon the reviewer. Side note: the term "code review" far predates git, and is widely used by many software development teams. isaacl (talk) 22:45, 22 November 2024 (UTC)Reply

  I see I see. I do think we need better pending changes as the current flagged revs system sucks. Also just because a feature is turned on doesn't mean there is consensus to use it, as seen by WP:SUPERPROTECT and WP:PC2. Awesome Aasim 18:11, 23 November 2024 (UTC)Reply

  Your second sentence would render everything about this to be meaningless. Plus, the community does not like unnecessarily turning features on; both of your examples have been removed. Aaron Liu (talk) 19:18, 23 November 2024 (UTC)Reply

  I know, that is my point. We also have consensus to make in Vector 2022 the unlimited width being default which was never turned on. Awesome Aasim 19:20, 23 November 2024 (UTC)Reply

1. I have made my opposition to all forms of FlaggedRevisions painfully clear since 2011. I will not formally oppose this, however, so as to avoid the process being derailed by people rebutting my opposition. —Jéské Couriano v^_^v ^{threads critiques} 02:36, 6 November 2024 (UTC)Reply
2. I'm not a fan of the current pending changes, so I couldn't support this. But it also wouldn't effect my editing, so I won't oppose it if it helps others.-- LCU ActivelyDisinterested «@» °∆t° 14:32, 6 November 2024 (UTC)Reply

Someone who is an expert at configuring mw:Extension:FlaggedRevs will need to confirm that it is possible to simultaneously have our current type of pending changes protection plus this new type of pending changes protection. The current enwiki FlaggedRevs config looks something like the below and may not be easy to configure. You may want to ping Ladsgroup or post at WP:VPT for assistance.

// enwiki
// InitializeSettings.php
$wgFlaggedRevsOverride = false;
$wgFlaggedRevsProtection = true;
$wgSimpleFlaggedRevsUI = true;
$wgFlaggedRevsHandleIncludes = 0;
$wgFlaggedRevsAutoReview = 3;
$wgFlaggedRevsLowProfile = true;
// CommonSettings.php
$wgAvailableRights[] = 'autoreview';
$wgAvailableRights[] = 'autoreviewrestore';
$wgAvailableRights[] = 'movestable';
$wgAvailableRights[] = 'review';
$wgAvailableRights[] = 'stablesettings';
$wgAvailableRights[] = 'unreviewedpages';
$wgAvailableRights[] = 'validate';
$wgGrantPermissions['editprotected']['movestable'] = true;
// flaggedrevs.php
wfLoadExtension( 'FlaggedRevs' );
$wgFlaggedRevsAutopromote = false;
$wgHooks['MediaWikiServices'][] = static function () {
	global $wgAddGroups, $wgDBname, $wgDefaultUserOptions,
		$wgFlaggedRevsNamespaces, $wgFlaggedRevsRestrictionLevels,
		$wgFlaggedRevsTags, $wgFlaggedRevsTagsRestrictions,
		$wgGroupPermissions, $wgRemoveGroups;

	$wgFlaggedRevsNamespaces[] = 828; // NS_MODULE
	$wgFlaggedRevsTags = [ 'accuracy' => [ 'levels' => 2 ] ];
	$wgFlaggedRevsTagsRestrictions = [
		'accuracy' => [ 'review' => 1, 'autoreview' => 1 ],
	];
	$wgGroupPermissions['autoconfirmed']['movestable'] = true; // T16166
	$wgGroupPermissions['sysop']['stablesettings'] = false; // -aaron 3/20/10
	$allowSysopsAssignEditor = true;

	$wgFlaggedRevsNamespaces = [ NS_MAIN, NS_PROJECT ];
	# We have only one tag with one level
	$wgFlaggedRevsTags = [ 'status' => [ 'levels' => 1 ] ];
	# Restrict autoconfirmed to flagging semi-protected
	$wgFlaggedRevsTagsRestrictions = [
		'status' => [ 'review' => 1, 'autoreview' => 1 ],
	];
	# Restriction levels for auto-review/review rights
	$wgFlaggedRevsRestrictionLevels = [ 'autoconfirmed' ];
	# Group permissions for autoconfirmed
	$wgGroupPermissions['autoconfirmed']['autoreview'] = true;
	# Group permissions for sysops
	$wgGroupPermissions['sysop']['review'] = true;
	$wgGroupPermissions['sysop']['stablesettings'] = true;
	# Use 'reviewer' group
	$wgAddGroups['sysop'][] = 'reviewer';
	$wgRemoveGroups['sysop'][] = 'reviewer';
	# Remove 'editor' and 'autoreview' (T91934) user groups
	unset( $wgGroupPermissions['editor'], $wgGroupPermissions['autoreview'] );

	# Rights for Bureaucrats (b/c)
	if ( isset( $wgGroupPermissions['reviewer'] ) ) {
		if ( !in_array( 'reviewer', $wgAddGroups['bureaucrat'] ?? [] ) ) {
			// promote to full reviewers
			$wgAddGroups['bureaucrat'][] = 'reviewer';
		}
		if ( !in_array( 'reviewer', $wgRemoveGroups['bureaucrat'] ?? [] ) ) {
			// demote from full reviewers
			$wgRemoveGroups['bureaucrat'][] = 'reviewer';
		}
	}
	# Rights for Sysops
	if ( isset( $wgGroupPermissions['editor'] ) && $allowSysopsAssignEditor ) {
		if ( !in_array( 'editor', $wgAddGroups['sysop'] ) ) {
			// promote to basic reviewer (established editors)
			$wgAddGroups['sysop'][] = 'editor';
		}
		if ( !in_array( 'editor', $wgRemoveGroups['sysop'] ) ) {
			// demote from basic reviewer (established editors)
			$wgRemoveGroups['sysop'][] = 'editor';
		}
	}
	if ( isset( $wgGroupPermissions['autoreview'] ) ) {
		if ( !in_array( 'autoreview', $wgAddGroups['sysop'] ) ) {
			// promote to basic auto-reviewer (semi-trusted users)
			$wgAddGroups['sysop'][] = 'autoreview';
		}
		if ( !in_array( 'autoreview', $wgRemoveGroups['sysop'] ) ) {
			// demote from basic auto-reviewer (semi-trusted users)
			$wgRemoveGroups['sysop'][] = 'autoreview';
		}
	}
};

–Novem Linguae (talk) 09:41, 6 November 2024 (UTC)Reply

I basically came here to ask if this is even possible or if it would need WMMF devs involvement or whatever.

For those unfamiliar, pending changes is not the same thing as the flagged revisions used on de.wp. PC was developed by the foundation specifically for this project after we asked for it. We also used to have WP:PC2 but nobody really knew what that was supposed to be and how to use it and it was discontinued. Just Step Sideways ^{from this world ..... today} 21:21, 6 November 2024 (UTC)Reply

Is PC2 an indication of implementation being possible? Aaron Liu (talk) 22:27, 6 November 2024 (UTC)Reply

Depends on what exactly is meant by "implementation". A configuration where edits by non-extendedconfirmed users need review by reviewers would probably be similar to what was removed in gerrit:/r/334511 to implement T156448 (removal of PC2). I don't know whether a configuration where edits by non-extendedconfirmed users can be reviewed by any extendedconfirmed user while normal PC still can only be reviewed by reviewers is possible or not. Anomie⚔ 13:32, 7 November 2024 (UTC)Reply

Looking at the MediaWiki documentation, it is not possible atm. That said, currently the proposal assumes that it is possible and we should work with that (though I would also support allowing all extended-confirmed to review all pending changes). Aaron Liu (talk) 13:56, 7 November 2024 (UTC)Reply

I think the RfC summary statement is a bit incomplete. My understanding is that the pending changes feature introduces a set of rights which can be assigned to corresponding user groups. I believe all the logic is based on the user rights, so there's no way to designate that one article can be autoreviewed by one user group while another article can be autoreviewed by a different user group. Thus unless the proposal is to replace autoconfirmed pending changes with extended confirmed pending changes, I don't think saying "enabled" in the summary is an adequate description. And if the proposal is to replace autoconfirmed pending changes, I think that should be explicitly stated. isaacl (talk) 22:06, 6 November 2024 (UTC)Reply

The proposal assumes that coexistence is technically possible. Aaron Liu (talk) 22:28, 6 November 2024 (UTC)Reply

The proposal did not specify if it assumed co-existence is possible, or enabling it is possible, which could mean replacement. Thus I feel the summary statement (before the timestamp, which is what shows up in the central RfC list) is incomplete. isaacl (talk) 22:31, 6 November 2024 (UTC)Reply

While on a re-read, It is assumed that it is technically possible to have PCECP does not explicitly imply co-existence, that is how I interpreted it. Anyways, it would be wonderful to hear from @Awesome Aasim about this. Aaron Liu (talk) 22:42, 6 November 2024 (UTC)Reply

The key question that ought to be clarified is if the proposal is to have both, or to replace the current one with a new version. (That ties back to the question of whether or not the arbitration committee's involvement is required.) Additionally, it would be more accurate not to use a word in the summary that implies the only cost is turning on a switch. isaacl (talk) 22:49, 6 November 2024 (UTC)Reply

It is assuming that we can have PC1 where only reviewers can approve edits and PCECP where only extended confirmed users can approve edits AND make edits without requiring approval. With the current iteration I don't know if it is technically possible. If it requires an extension rewrite or replacement, that is fine. If something is still unclear, please let me know. Awesome Aasim 23:06, 6 November 2024 (UTC)Reply

I suggest changing the summary statement to something like, "Should a new pending changes protection level be added to Wikipedia – extended confirmed pending changes (hereby abbreviated as PCECP)?". The subsequent paragraph can provide the further explanation on who would be autoreviewed and who would serve as reviewers with the new proposed level. isaacl (talk) 23:19, 6 November 2024 (UTC)Reply

Okay, done. I tweaked the wording a little. Awesome Aasim 23:40, 6 November 2024 (UTC)Reply

I think inclusion of the preemptive-protection part in the background statement is causing confusion. AFAIK preemptive protection and whether we should use PCECP over ECP are separate questions. Aaron Liu (talk) 19:11, 7 November 2024 (UTC)Reply

Particularly on low traffic articles as well as all talk pages. WP:ECP would still remain an option to apply on top of PCECP. Awesome Aasim 19:58, 5 November 2024 (UTC)Reply

• Support for my reasons in Q1. Awesome Aasim 19:58, 5 November 2024 (UTC)Reply

  Also to add on there needs to be some enforcement measure for WP:ARBECR. No technical enforcement measures on WP:ARBECR is akin to site-banning an editor and then refusing to block them because "blocks should be preventative". Awesome Aasim 19:42, 13 November 2024 (UTC)Reply

  Blocking a site-banned user is preventative, because if we didn't need to prevent them from editing they wouldn't have been site banned. Thryduulf (talk) 21:16, 13 November 2024 (UTC)Reply

• Slightly ambivalent on protecting talk pages, but I guess it would bring prominence to low-traffic pages. Aaron Liu (talk) 20:13, 5 November 2024 (UTC)Reply

  Per isaacl, I only support preemptive protection on low-traffic pages. Aaron Liu (talk) 23:21, 12 November 2024 (UTC)Reply

• Support, including on talk pages. With edit requests mostly dealt with through pending changes, protecting the talk pages too should limit the disruption and unconstructive comments that are often commonplace there. (Changing my mind, I don't think applying PCECP on all pages would be a constructive solution. The rules of ARBECR limit participation to extended-confirmed editors, but the spirit of the rules has been to only enforce that on pages with actual disruption, not preemptively. 20:49, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:21, 5 November 2024 (UTC)Reply
• Support I'm going to disagree with the "no" argument entirely - we should be preemptively ECPing (even without pending changes). It's a perversion of logic to say "you can't (per policy) do push this button", and then refuse to actually technically stop you from pushing the button even though we know you could. * Pppery * _{it has begun...} 20:52, 5 November 2024 (UTC)Reply
• Support (Summoned by bot): While I disagree with ECR in general, this is a better way of enforcing it as long as it exists. Constructive "edit requests" can be accepted, and edits that people disagree with can be easily reverted. I'm slightly concerned with how this could affect the pending changes backlog (which has a fairly small number of active reviewers at the moment), but I'm sure that can be figured out. C F A 💬 23:41, 5 November 2024 (UTC)Reply

• No, I don't think this is necessary at this time. I think it should be usable there, but I don't feel like this is a necessary step at this time. We could revisit it later. WhatamIdoing (talk) 20:37, 5 November 2024 (UTC)Reply

No, we still shouldn't be protecting preemptively. Wait until there's disruption, and then choose between PCXC or regular XC protection (I would strongly favour the former for the reasons I gave above). Cremastra (u — c) 20:43, 5 November 2024 (UTC)Reply

• Mu - This is a question that should be asked afterwards, not same time as, since ArbCom will want to look at any such proposal. —Jéské Couriano v^_^v ^{threads critiques} 02:38, 6 November 2024 (UTC)Reply
• No, I feel this would be a bad idea. Critics of Wikipedia already use the idea that it's controlled by a select group, this would only make that misconception more common. -- LCU ActivelyDisinterested «@» °∆t° 14:36, 6 November 2024 (UTC)Reply
• Preemptive protection has always been contrary to policy, with good reason. Just Step Sideways ^{from this world ..... today} 21:26, 6 November 2024 (UTC)Reply
• Absolutely not. No need for protection if there is no disruption. The number of protected pages should be kept low, and the number of pages that cry out "look at me!" on your watchlist (anything under pending changes) should be as close to zero as possible. —Kusma (talk) 21:44, 6 November 2024 (UTC)Reply

  No need for protection if there is no disruption. Trouble is, the ECR restriction is enacted in response to widespread disruption, this time to the entire topic area as a whole. Disregard for POV, blatant inclusion of unverifiable or false (unreliable) information, and more all pose serious threats of disruption to the project. If WP:ARBECR was applied broadly without any protection I would agree, but WP:ARBECR is applied in response to disruption (or a serious threat of), not preemptively. Take this one for example, which is a long winded ANI discussion that ended in the WP:GS for the Russo-Ukranian War (and the ECR restrictions). And as for Arbitration Committee, ArbCom is a last resort when all other attempts to resolve disruption fail. See WP:ARBPIA WP:ARBPIA2 WP:ARBPIA3 WP:ARBPIA4. The earliest reference to the precursor to ARBECR in this case is on the third ArbCom case. Not protecting within a topic area that has a high risk of disruption is akin to having a high-risk template unprotected. The only difference is that carelessly editing a high-risk template creates technical problems, while carelessly editing a high-risk topic area creates content problems.

  Either the page is protected technically (which enforces a community or ArbCom decision that only specific editors are allowed in topic areas) or the page is not protected technically but protected socially (which then gives a chance of evasion). I see this situation no different from banning an editor sitewide and then refusing to block them on the grounds that "blocks should only be used to prevent disruption" while ignoring the circumstances leading up to the site ban.

  What PCECP would do is allow for better enforcement of the community aspect. New editors won't be bitten, if they find something that needs fixing like a typo, they can make an edit and it can get approved. More controversial edits will get relegated to the talk page where editors not banned from that topic area can discuss that topic. And blatant POV pushing and whatnot would get reverted and would never even be seen by readers.

  The workflow would look like this: new/anon user make an edit → edit gets held for review → extended confirmed user approves the edit. Rather than the current workflow (and the reason why preemptive ECP is unpopular): new/anon user makes an edit → user is greeted with a "this page is protected" message → user describes what they would like to be changed but in a badly formulated way → edit request gets closed as "unclear" or something similar. Awesome Aasim 14:21, 11 November 2024 (UTC)Reply

  Consider this POV change made to a topic that I presume is covered under WP:ARBPIA and that is not protected. The whole reason that there is WP:ARBECR is to prevent stuff like this from happening. There already is consensus either among arbitrators or among the community to enact ECR within specific contentious topic areas, so I don't see how it is productive to refuse to protect pages because of "not enough disruption" when the entire topic area has faced widespread disruption in the past. Awesome Aasim 18:18, 23 November 2024 (UTC)Reply

  Simple, everyday vandalism is far from the levels of disruption that caused the topic to be marked Contentious. Aaron Liu (talk) 19:20, 23 November 2024 (UTC)Reply

  That example I provided isn't vandalism. Yes it is disruptive POV pushing but it is not vandalism. Wikipedia also exists in the real world, and Wikipedia does not have the technical tools to fight armies of POV pushers and more. One example is Special:PermaLink/1197462753#Arbitration_motion_regarding_PIA_Canvassing. When the stakes are this high people feel entitled to impose their view on the project, but Wikipedia isn't the place to right great wrongs. Awesome Aasim 19:32, 23 November 2024 (UTC)Reply

• Per my vote above. Ratnahastin (talk) 09:00, 7 November 2024 (UTC)Reply
• Absolutely not. Protection should only ever be preventative. Kusma puts it better than I can. Thryduulf (talk) 13:49, 7 November 2024 (UTC)Reply
• Per my comment above. jp×g🗯️ 18:17, 7 November 2024 (UTC)Reply
• No; see my comment above. I prefer to see disruption before protecting. Lectonar (talk) 08:51, 8 November 2024 (UTC)Reply
• No. We should be quicker to apply protection in these topics than we would elsewhere, but not preemptively except on highly visible pages (which, in these topics, are probably ECP-protected anyway). Animal lover |666| 17:18, 11 November 2024 (UTC)Reply
• No, that would create a huge backlog. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)Reply
• Oppose per Kusma Andre🚐 01:30, 17 November 2024 (UTC)Reply

@Jéské Couriano Could you link to said ArbCom discussion? Aaron Liu (talk) 03:51, 6 November 2024 (UTC)Reply

I'm not saying such a discussion exists, but changes to Arbitration remedies/discretionary sanctions are something they would want to weigh in on. Arbitration policy (which includes WP:Contentious topics) is in their wheelhouse and this would have serious implications for WP:CT/A-I and any further instances where ArbCom (rather than individual editors, as a discretionary sanction) would need to resort to a 500/30 rule as an explicit remedy. —Jéské Couriano v^_^v ^{threads critiques} 04:58, 6 November 2024 (UTC)Reply

That is not my reading of WP:ARBECR. Specifically, On any page where the restriction is not enforced through extended confirmed protection, this restriction may be enforced by...the use of pending changes... (bold added by me for emphasis). But if there is consensus not to use this preemptively so be it. Awesome Aasim 05:13, 6 November 2024 (UTC)Reply

• While I appreciate the forward thinking that PCECP may want to be used in Arb areas, this feels like a considerable muddying of the delineation between the Committee's role and the community's role. Traditionally, Contentious Topics have been the realm of ArbCom, and General Sanctions have been the realm of the Community. Part of the logic comes down to who takes the blame when things go wrong. The Community shouldn't take the blame when ArbCom makes a decision, and vice versa. Part of the logic is separation of powers. If the community wants to say "ArbCom, you will enforce this so help you God," then that should be done by amending ArbPol. Part of the logic is practical. If the community creates a process that adds to an existing Arb process, what happens when the Arbs want to change that process? Or even end it altogether? Bottomline: Adopting PCECP for ARBECR is certainly something ArbCom could do. But I'd ask the community to consider the broader structural problems that would arise if the community adopted it on behalf of ArbCom. CaptainEek ^{Edits Ho Cap'n!}⚓ 05:18, 7 November 2024 (UTC)Reply

  Interesting. I'd say ArbCom should be able to override the community if they truly see such action fit and worthy of potential backlash. Aaron Liu (talk) 12:30, 7 November 2024 (UTC)Reply

  Just a terminology note, although I appreciate many think of general sanctions in that way, it's defined on the Wikipedia:General sanctions page as ... a type of Wikipedia sanctions that apply to all editors working in a particular topic area. ... General sanctions are measures used by the community or the Arbitration Committee ("ArbCom") to improve the editing atmosphere of an article or topic area.. Thus the contentious topics framework is a form of general sanctions. isaacl (talk) 15:22, 7 November 2024 (UTC)Reply

  Regarding the general point: I agree that it is cumbersome for the community to impose a general sanction that is added on top of a specific arbitration remedy. I would prefer that the community work with the arbitration committee to amend its remedy, which would facilitate keeping the description of the sanction and logging of its enforcement together, instead of split. (I appreciate that for this specific proposal, logging of enforcement is not an issue.) isaacl (talk) 15:30, 7 November 2024 (UTC)Reply

  Extended confirmed started off as an arbcom concept - 500 edits/30 days - which the community then choose to adopt. ArbCom then decided to make its remedy match the community's version - such that if the community were to decide extended confirmed were 1000 edits/90 days all ArbCom restrictions would update. I find this a healthy feedback loop between ArbCom and the community. The community could clearly choose (at least on a policy level, given some technical concerns) to enact PCECP. It could choose to apply this to some/all pages. If it is comfortable saying that it wants to delegate some of which pages this applies to the Arbitration Committee I think it can do so without amending ArbPol. However, I think ArbCom could could decide that PCECP would not apply in some/all CTOP areas given that the Committee is exempt from consensus for areas with-in its scope. And so it might ultimately make more sense to do what isaacl suggests. Best, Barkeep49 (talk) 16:02, 7 November 2024 (UTC)Reply

  The "contentious topics" procedure does seem like something that the community should absolutely mirror and that ultimately both the community and ArbCom should work out of. If one diverges, there is probably a good reason why it diverged.

  As for the broader structural problems that would arise if the community adopted it on behalf of ArbCom, there are already structural problems with general sanctions because of the community's failure to adopt the new CTOP procedure for new contentious topics. Although the community has adopted the contents of WP:ARBECR for other topic areas like WP:RUSUKR, they don't adopt it by reference but by copying the whole text verbatim. Awesome Aasim 17:13, 7 November 2024 (UTC)Reply

  That's not the same structural problem. The community hasn't had a lot of discussion about adopting the contentious topic framework for its own use (in my opinion, because it's a very process-wonky discussion that doesn't interest enough editors to generate a consensus), but that doesn't interfere with how the arbitration committee uses the contentious topic framework. This proposal is suggesting that the community automatically layer on its own general sanction on top of any time the arbitration committee decides to enact a specific sanction. Thus the committee would have to consider each time whether or not to override the community add-on, and amendment requests might have to be made both to the committee and the community. isaacl (talk) 17:33, 7 November 2024 (UTC)Reply

  Prior to contentious topics there were discretionary sanctions. Those became very muddled and so the committee created Contentious topics to help clarify the line between community and committee (disclosure: I help draft much of that work). As part of that the committee also established ways for the community to tie-in to contentious topics if it wanted. So for the community hasn't made that choice which is fine. But I do this is an area that, in general, ArbCom does better than the community because there is more attention paid to having consistency across areas and when a problem arises I have found (in basically this one area only) ArbCom to be more agile at addressing it. But the community is also more willing to pass a GS than ArbCom is to designate something a CT (which I think is a good hting all around) and so having the community come to consensus about how, if at all, it wants to tie in to CT (and its evolutions) or if it would prefer to do its own thing (including just mirroring whatever happens to be in CT at the time but not subsequent changes) would probably be a good meta discussion to have. But it also doesn't seem necessary for this particular proposal. Best, Barkeep49 (talk) 17:41, 7 November 2024 (UTC)Reply

• Support as a second option, but only to articles. Talk pages can be enforced solely through reverts and short protections so I see little reason why those should be protected. Awesome Aasim 19:58, 5 November 2024 (UTC) Moved to oppose. Awesome Aasim 19:10, 23 November 2024 (UTC)Reply
• Support for articles per Aasim. Talk pages still need to be open for edit requests. (Also changing my mind, per above. If anything, we should clarify ARBECR so that the 500-30 limit is only applied in cases where it is needed, not automatically, to resolve the ambiguity. 20:52, 7 November 2024 (UTC)) Chaotic Enby (talk · contribs) 20:20, 5 November 2024 (UTC)Reply
• Support per my comment in the previous section. * Pppery * _{it has begun...} 20:52, 5 November 2024 (UTC)Reply
• I agree with Chaotic Enby and Pppery above and think all CT articles should be protected. I am generally not a fan of protecting Talk pages, but it's true that many CT Talk pages are cesspools of hate, so I am not sure where I sit on protecting Talk pages. Toadspike [Talk] 20:57, 5 November 2024 (UTC)Reply

  Under the current wording of ARBECR, When such a restriction is in effect in a topic area, only extended-confirmed editors may make edits related to the topic area. We should protect pages, rather than letting new editors edit and then reverting them for basically no reason. This is a waste of their time and very BITEy.

  I am not opposed to changing the wording of ARBECR to forbid reverting solely because an editor is not extended confirmed, which is a silly reason to revert otherwise good edits. However, until ArbCom changes ARBECR, we are stuck with the rules we have. We ought to make these rules clear to editors before they edit, by page protection, instead of after they edit, by reversion. Toadspike [Talk] 10:55, 16 November 2024 (UTC)Reply

• Support preemptive ECP without PCECP (for article space only). If we have a strict policy (or ArbCom ruling) that a class of user is forbidden to edit a class of page, there is no downside whatever to implementing that policy by technical means. All it does is stop prohibited edits. The consequences would all be positive, such as removing the need for constant monitoring, reducing IP vandalism to zero, and reducing the need to template new editors who haven't learned the rules yet. What I'd like with regard to the last one, is that a non-EC editor sees an "edit" button on an ECP page but clicking it diverts them to a page that explains EC and how to get it. Zero^talk 05:53, 17 November 2024 (UTC)Reply

• Oppose because I think this is a bad idea. For one thing, just making a list of all the covered articles could produce disputes that we don't need. (This article might be covered, but is it truly covered? Reasonable people could easily disagree about whether some articles are "mostly" about the restricted area vs "partly", and therefore about whether the rule applies.) Second, where a serious and obvious problem, such as blatant vandalism, is concerned, it would be better to have an IP revert it than to mindlessly follow the rules. It is important to remember that our rules exist as a means to an end. We follow them because, and to the extent that, they help overall. We expect admins and other editors to exercise discretion. It is our policy that Wikipedia:If a rule prevents you from improving or maintaining Wikipedia, ignore it. This is a proposal to declare that the IAR policy never applies to the rule about who should normally be editing these articles, and that exercising discretion is not allowed. WhatamIdoing (talk) 20:42, 5 November 2024 (UTC)Reply

  I am neither Arb nor admin, but I think the words "broadly construed" are specifically chosen so that if a topic is "partly" about the restricted area, it is included in the CTOP. @WhatamIdoing, could you please show me an example of a case where CTOP designation or ECP was disputed? Toadspike [Talk] 10:59, 16 November 2024 (UTC)Reply

  I avoid most of those articles, but consider "the entire set of Arab-Israeli conflict-related articles, broadly interpreted": Does that include BLPs who come from Israel/Palestine? What about BLPs who are in the news because of what they said about the Israel–Hamas war? IMO reasonable people could disagree about whether "every person living in the affected area" or "every person talking about the conflict" is part of "the entire set of Arab-Israeli conflict-related articles, broadly interpreted". WhatamIdoing (talk) 19:54, 16 November 2024 (UTC)Reply

  David Miller is what we call a "partial" Arbpia. So while it's a BLP in general, parts of it are subject to Arbpia/CT, not a particularly unusual situation. The talkpage and edit notices should, but don't always, tell you whether it is or isn't, part of. Selfstudier (talk) 20:59, 16 November 2024 (UTC)Reply

  WP:IAR applies to content not to conduct. ArbCom is empowered to take action against poor conduct. You can't claim WP:IAR for example to reverse engineering a script that requires specific permissions to use. Likewise a new editor cannot claim "IAR" to adding unverifiable (albeit true) information to an ARBECR protected article. Awesome Aasim 15:25, 16 November 2024 (UTC)Reply

  IAR stands for IgnoreAllRules. The latter two cannot be claimed valid based on IgnoreAllRules because they don't have strong IgnoreAllRules arguments for what they did, not because IgnoreAllRules somehow only applies to content. Aaron Liu (talk) 16:07, 16 November 2024 (UTC)Reply

  I meant ignore all rules applies to rules not to behavior. Point still stands as ARBPIA addresses behavior not content. Awesome Aasim 21:04, 16 November 2024 (UTC)Reply

  I agree that "ignore all rules" applies to rules – including rules about behavior. ARBPIA is a rule about behavior. IAR therefore applies to ARBPIA.

  Of course, if breaking the rule doesn't prove helpful to Wikipedia in some way, then no matter what type of rule it is, you shouldn't break the rule. We have a rule against bad grammar in articles, and you should not break that rule. But when two rules conflict – say, the style rule of "No bad grammar" and the behavioral rule of "No editing this ARBPIA article while logged out, even if it's because you're on a public computer and can't remember your password" – IAR says you can choose to ignore the rule that prevents you from improving Wikipedia. WhatamIdoing (talk) 21:34, 16 November 2024 (UTC)Reply

• While there's already precedent for preemptive protection at e.g. RFPP, I do not like this. For one, as talk pages (and, by extension, edit requests) cannot use the visual editor, this makes it much harder for newcomers to contribute edits, often unnecessarily on articles where there are no disruption. Aaron Liu (talk) 23:47, 5 November 2024 (UTC)Reply
• Oppose (Summoned by bot): Too strict. C F A 💬 00:03, 6 November 2024 (UTC)Reply
• Mu - This is basically my reading of the 500/30 rule as writ. Anything that would fall into the 500/30'd topic should be XCP'd on discovery. It's worth noting I don't view this as anywhere close to ideal but then neither did ArbCom, and given the circumstances of the real-world ethnopolitical conflict only escalating as of late (which in turn feeds the disruption) the only other - even worse - option would be full-protection across the board everywhere in the area. So why am I not arguing Support? Because just like the question above, this is putting the cart before the horse and this is better off being discussed after this RfC ends, not same time as. —Jéské Couriano v^_^v ^{threads critiques} 02:47, 6 November 2024 (UTC)Reply
• Oppose Preemptive protection of any page where there is not a problem that needs solving. Just Step Sideways ^{from this world ..... today} 21:28, 6 November 2024 (UTC)Reply
• Absolutely not, pages that do not experience disruption should be open to edit. Pending changes should never become widely used to avoid situations like dewiki's utterly absurd 53-day backlog. —Kusma (talk) 21:53, 6 November 2024 (UTC)Reply
• Very strong oppose, again Kusma puts it excellently. Protection should always be the exception, not the norm. Even in the Israel-Palestine topic area most articles do not experience disruption. Thryduulf (talk) 13:50, 7 November 2024 (UTC)Reply

  WP:RUNAWAY sums up some of the tactics used by disruptive editors: namely Their edits are limited to a small number of pages that very few people watch and Conversely, their edits may be distributed over a wide range of articles to make it less likely that any given user watches a sufficient number of affected articles to notice the disruptions. If a user is really insistent on pushing their agenda, they might not be able to push it on the big pages, they may push it on some of the smaller pages where their edits may get unwatched for months if not years. Then, researchers digging up information will come across the POV article and blindly cite it. Although Wikipedia should never be cited as a source, it still happens. Awesome Aasim 14:35, 11 November 2024 (UTC)Reply

• Per my comment above. jp×g🗯️ 18:18, 7 November 2024 (UTC)Reply
• No, see my comment to the other questions. Lectonar (talk) 08:52, 8 November 2024 (UTC)Reply
• No, we should never be preemptively protecting pages. Cremastra (u — c) 16:35, 10 November 2024 (UTC)Reply
• No, except on the most prominent articles on each CT topic (probably already done on current CTs, but relevant for new ones). Animal lover |666| 19:47, 11 November 2024 (UTC)Reply
• Absolutely not. See above comments for details. ~~ AirshipJungleman29 (talk) 20:50, 14 November 2024 (UTC)Reply
• Comment - The number of revisions within the PIA topic area that violate the ARBECR rule is not measured. It is not currently possible to say anything meaningful about the amount of 'disruption' in the topic area by non-EC IPs and accounts. And the way people estimate the amount of 'disruption' subjectively depends on the timescale they choose to measure it. Nobody can see all of the revisions and the number of people looking is small. Since the ARBECR rule was introduced around the start of 2020, there have been over 71,000 revisions by IPs to articles and talk pages within the subset of the PIA topic, about 11,000 pages, used to gather statistical data (ARBPIA templated articles and articles that are members of both wikiproject Israel and wikiproject Palestine). Nobody has any idea how many of those were constructive, how many were disruptive, how many involved ban-evading disposable accounts etc. And yet, this incomplete information situation apparently has little to no impact on the credence we all assign to our views about what would work best for the PIA topic area. I personally think it is better to dispense with non-evidence-based beliefs about the state of the topic area at any given time and simply let the servers enforce the rule as written in WP:ARBECR, "only extended-confirmed editors may make edits related to the topic area, subject to the following provisions...". Sean.hoyland (talk) 17:22, 16 November 2024 (UTC)Reply

  Make sense, but I am not sure if this is meant to be an oppose. Personally, since there hasn't been much big outrage not solved by a simple RfPP, anecdotally I see no problem with the status quo on this question. Aaron Liu (talk) 01:24, 17 November 2024 (UTC)Reply

• Oppose per Thryduulf and others Andre🚐 01:29, 17 November 2024 (UTC)Reply
• Oppose. Preemptive protection is just irresponsible.—Alalch E. 23:22, 22 November 2024 (UTC)Reply
• As nominator I am actually starting to lean weak oppose unless if we have a robust and new-user-friendly edit request system (which currently we don't). We already preemptively protect templates used on a lot of pages for technical reasons, and I don't think new users are at all going to be interested in templates so our current edit request system works decent for templates, modules, code pages, etc. When we choose to protect it should be the same as blocking which is the risk of disruption for specific pages or topic areas, using previous disruption to hope predict the future. Users already have a hard time submitting edit requests for pages not within contentious topic areas, so as it stands right now preemptive protection will do more harm than good. Awesome Aasim 19:10, 23 November 2024 (UTC)Reply

I think this question should be changed to "...articles under WP:ARBECR topics?". Aaron Liu (talk) 20:11, 5 November 2024 (UTC)Reply

Okay, updated. Look good? Awesome Aasim 20:13, 5 November 2024 (UTC)Reply

As I discussed in another comment, should this concept gain approval, I feel it is best for the community to work with the arbitration committee to amend its remedy. isaacl (talk) 15:34, 7 November 2024 (UTC)Reply

And as I discussed in another comment while I think the community could do this, I agree with isaac that it would be best to do it in a way that works with the committee. Best, Barkeep49 (talk) 16:03, 7 November 2024 (UTC)Reply

This behaves a little like pending changes, but with a few different things:

1. There would be an additional option entitled "allow users to submit edits for review" in the protection window. There could also be a specific user group able to accept such edits.
2. Instead of the standard "protected page text" informing the user is protected, when this option is enabled, the user is given a message something like "This page is currently protected, so you are currently submitting an edit request. Only when your change is approved will your edit be visible." An edit summary as well as a more detailed explanation into the review can be provided. Same for title blacklisted pages. However, the "permission error" will still show for attempting to rename the page, as well as for cases where a user cannot edit a page for a reason other than protection (like being blocked from editing).
3. All the changes submitted for review end up in some namespace (like Review:1234567) with the change id. Only users with the ability to edit the page or accept the revision would be able to see these changes. There would also be the ability to discuss each change on the talk page for that change or something similar. This namespace by design will be unprotectable.
4. Users with the ability to edit the page (or when a higher accept level is selected, users with that accept level) are given the ability to merge these changes in. Administrators can delete changes just like they can delete individual revisions, and these changes can also be suppressed just like individual revisions.

This would be a major improvement over our edit request system which ONLY allows a user to write what they want changed, and that is often prone to stuff that is not WP:CHANGEXY. If there are merge conflicts preventing a clean merge then the person who submitted the edit or the reviewer will have to manually fix it before it merges cleanly. If this path is chosen we can safely retire pending changes. Awesome Aasim 18:52, 23 November 2024 (UTC)Reply

• Support failing Q1, as it streamlines the experience for making edit requests, especially for new users. I have had ideas for scripts to make the experience of submitting an edit request a lot easier but none has really come to fruition. I still don't entirely agree with the arguments with Q2 and Q3, but I am starting to agree that that is putting the pen before the pig and thus can be closed as premature, unless if there is an emerging consensus that pages being within a topic area should not be protected for being within that particular topic area. Awesome Aasim 18:52, 23 November 2024 (UTC)Reply

If additional proposals come (seems unlikely), I wonder if this might be better split as a "pending changes review" or something similar. Awesome Aasim 18:52, 23 November 2024 (UTC) I really think this should be straight-up implemented as whatever first instead of being asked in an RfC. Aaron Liu (talk) 19:32, 23 November 2024 (UTC)Reply

Since we're assuming that PCECP is possible and the last two questions definitely deal with policy, I feel like maybe this should go to VPP instead, with the header edited to something like "Extended-confirmed pending changes and preemptive protection in contentious topics" to reflect the slightly−larger-than-advertised scope? Aaron Liu (talk) 23:53, 5 November 2024 (UTC)Reply

I think policy proposals are also okay here, though I see your point. There is definitely overlap, though. This is both a request for a technical change as well as establishing policy/guidelines around that technical change (or lack thereof). Awesome Aasim 00:26, 6 November 2024 (UTC)Reply

If this proposal is accepted, my assumption is that we'd bring back the ORANGELOCK which was used for the original incarnation of Pending Changes Level 2. There's a proposed lock already at File:Pending_Changes_Protected_Level_2.svg, though it needs fixes in terms of name (should probably be something like Pending-level-2-protection-shackle.png or Extended-pending-protection-shackle.png), SVG code (the top curve is a bit cut off), and color (should probably be darker but still clearly distinguishable from REDLOCK). —pythoncoder (talk | contribs) 21:43, 8 November 2024 (UTC)Reply

I think light blue is a better color for this. But in any case we will probably need a lock with a checkmark and the letter "E" for extended confirmed. Awesome Aasim 22:22, 8 November 2024 (UTC)Reply

Courtesy ping all from the idea lab that participated in helping formulate this RfC: @Toadspike @Jéské Couriano @Aaron Liu @Mach61 @Cremastra @Anomie @SamuelRiv @Isaacl @WhatamIdoing @Ahecht @Bunnypranav. Awesome Aasim 19:58, 5 November 2024 (UTC)Reply

I am actually starting to wonder if "protection" is a bit of a misnomer, because technically pages under pending changes are not really "protected". Yeah the edits are subject to review, but there are no technical measures to prevent a user from editing. It is just like recent changes on many wikis; those hold edits for review until they are approved, but they do not "protect" the entire wiki. Awesome Aasim 23:40, 11 November 2024 (UTC)Reply

The main proposal is basically deadlocked and has been for six days, and the sub-proposals are clearly failing. Seems like we have a result. Just Step Sideways ^{from this world ..... today} 23:09, 22 November 2024 (UTC)Reply

I was about to withdraw Q2 and Q3 for putting the pen before the pig, but I did realize I added a couple more comments particularly to Q2. I did add a Q4 that might be more actionable and that is about making the experience of submitting edit requests a lot better. I am starting to agree though for Q2 and Q3 everything that has needed to be said has been said so the proposals can be withdrawn.

We do need to consider the experience of the users actually being locked out of this. I understand the opposition to Q3 (and in fact just struck my !vote because of this). But Q2? Look at the disaster that WP:V22RFC, WP:V22RFC2, and WP:V22RFC3 is. These surveys are barely representative of new users, just of experienced editors. We should absolutely be bringing new editors to the table for these discussions. Awesome Aasim 19:13, 23 November 2024 (UTC)Reply

Please don't pre-close. 4 of the opposers to the main proposal seem to address only Q2 instead of Q1, and I don't see anyone addressing the argument that it's less restrictive than ECP. It's up to the closer to weigh the consensus. Aaron Liu (talk) 19:30, 23 November 2024 (UTC)Reply

AI certainly improved a lot by now. It can translate to many non-english language better than traditional translators . My suggestion is to add AI translation option for translating from English to non-English article. User will review the AI translation to see if its correct. It will increase the translation quality. I dont suggest using AI for English article, that could have a devastating impact. Dark1618 (talk) 18:50, 7 November 2024 (UTC)Reply

That's out of scope here, and would need to be asked on each and every individual language-edition of Wikipedia, as those would be the ones dictating policy for translations into their respective languages. —Jéské Couriano v^_^v ^{threads critiques} 19:10, 7 November 2024 (UTC)Reply

Why would a translation into English be devastating, but a translation from English into any other language be acceptable? English just happens to be that most used language in the world by some measures: beyond that it has no special status. Anyway, we can not decide here what is appropriate for other language Wikipedias. Phil Bridger (talk) 19:33, 7 November 2024 (UTC)Reply

Good Idea! That’s actually what I was going to propose but you took it. To add to your amazing proposal, I suggest that every wiki translation must be approved by a speaker. Like If someone translated an article from English to Arabic, the translated article goes to an Arab speaker, by algorithm when the person would press a button that says “send for approval” or something like that, and the Arab person who gets the translated article will read the Wikipedia page and look for any errors, then the Arab corrects it and it gets published to the world. And why can’t the opposite happen, when an article gets translated to say french To English the same thing happens the French person machine translates the article, it gets sent to approval, a fluent English speaker goes and corrects it, then it gets published. If it is an extinct language, a person who is a professional in the language will correct it, and as for rates, I mean Wikipedia has at least 1 person who knows the language. Anyway have a good day! Cheers! Datawikiperson (talk) 10:10, 10 November 2024 (UTC)Reply

Doesn't WP:CXT already do this somewhat? Lee Vilenski ^{(talk • contribs)} 10:36, 10 November 2024 (UTC)Reply

I'm not sure of the technical backend for that tool, but I do see at English Wikipedia a constant inflow of articles translated from sister projects, usually without proper attribution, sometimes with broken templates.

Some of these translations are pretty good, up to idiomatic phrasing; others have the appearance of raw machine translation, with errors no one fluent in the target language would leave in.

As to the original proposal / idea, a flow of machine translations from this project to sister Wikipediae, that is indeed out of scope here, and would have to be brought up individually at each language project. Except maybe Cebuano Wikipedia. Folly Mox (talk) 14:49, 10 November 2024 (UTC)Reply

I occasionally translate from English to Chinese and vice versa, and take on some bits from Japanese and Korea projects to be translated on to here if the information and sources can be used on here. And I strongly discourage automated AI translations from English to other languages, which you are proposing, without further inputs from the targeted language projects. AI translations to other languages from English are not perfect and can have the same devastating impact you don't want to see on English Wikipedia. – robertsky (talk) 14:30, 11 November 2024 (UTC)Reply

Machine translation from English to most other languages is already enabled (and where it isn't it is a choice of the to project, not of the English Wikipedia). I don't think there is anything for us to do about this proposal? — xaosflux ^Talk 10:33, 16 November 2024 (UTC)Reply

• Oppose see also WP:CXT. We should never be using AI to translate works; always humans. Yes AI is good, but just by the nature of how LLMs and neural networks work, they can't necessarily be better than humans. AI does not have any understanding of context, cultural norms, and so much more that humans do have, it just finds patterns in data to see what comes next. Awesome Aasim 19:17, 23 November 2024 (UTC)Reply

Hello! I have made an infobox for artist collectives (inspired by my own frustration trying to use the regular artist one for graffiti crews) and would like feedback from the community before publishing it. The old infobox proposal page is now defunct and suggests posting here instead.

The draft is currently in my sandbox. -- NotCharizard ^🗨 00:22, 12 November 2024 (UTC)Reply

Personally, I'd much rather not see this, or anything like it, used. Almost everything in it will be disputable or disputed, or is really vague. It seems a classic example of where an infobox is just unhelpful clutter, and will displace or make too small an image that would be more helpful. Are you asking at the VA project, & if not, why not? It's not really for here. Johnbod (talk) 05:03, 12 November 2024 (UTC)Reply

Okay, I will try at the VA project. -- NotCharizard ^🗨 14:30, 17 November 2024 (UTC)Reply

Heya, I noticed a couple of weeks ago that while interface administrators and central notice administrators need 2FA, bureaucrats, who can grant interface admin don't need 2FA. To me this seems a bit weird, because if you wanted to compromise an account with access to interface admin tools, bureaucrats may not all have 2FA. Hence, I'm proposing requiring all enwiki bureaucrats to enable 2FA as a precaution. Zippybonzo | talk | contribs (they/them) 09:24, 12 November 2024 (UTC)Reply

If this is the case then they absolutely should begin to require 2FA (although I'm sure in practice they all have it anyway) Gaismagorm (talk) 13:35, 12 November 2024 (UTC)Reply

Yeah, that's my thoughts, I imagine they do all have it, but formalising it as a requirement seems to make sense IMO. Zippybonzo | talk | contribs (they/them) 14:30, 12 November 2024 (UTC)Reply

Hold. This is being evaluated upstream (phab:T242555 (restricted task)) - if WMF ends up requiring it we won't need a local project rule. — xaosflux ^Talk 13:51, 12 November 2024 (UTC)Reply

I see non-restricted adjacent bugs T242553 and T242556 were both created on 12 Jan 2020. Would it be accurate to describe this as an evaluation which has been unresolved for about 5 years? -- zzuuzz ^(talk) 13:58, 12 November 2024 (UTC)Reply

Hold—for another five years  :) SerialNumber54129 14:39, 12 November 2024 (UTC)Reply

Before GTA6 maybe lol Zippybonzo | talk | contribs (they/them) 17:02, 12 November 2024 (UTC)Reply

There's no reason we can't impose a local requirement for this independently of the WMF. And the current system is utterly illogical. Support doing so. * Pppery * _{it has begun...} 17:07, 12 November 2024 (UTC)Reply

Support per pppery and zippybonzo - should be a requirement locally. Waiting for phab tickets could take years while I imagine a RFC would pass pretty quickly. BugGhost🦗👻 19:44, 12 November 2024 (UTC)Reply

Easy support. They have to much potential power to not have max security on accounts. Kingsmasher678 (talk) 19:54, 14 November 2024 (UTC)Reply

No knowing when WMF might implement. Support. ~~ AirshipJungleman29 (talk) 21:02, 14 November 2024 (UTC)Reply

The fact that 'crats can assign interface admin (a role which requires 2FA) but are not required to have 2FA personally enabled is wild. Support a local rule (and hopefully the largest WMF project implementing such a rule will encourage others to make such a change). HouseBlaster (talk • he/they) 00:43, 15 November 2024 (UTC)Reply

Definite support. I am personally in favor of a 2FA requirement for any privileged group, but it is something I doubt will happen anytime soon. Crats should absolutely have it enabled. EggRoll97 ^(talk) 01:51, 15 November 2024 (UTC)Reply

Question. How are you going to check whether the user enabled 2FA or not? This information is not public. Only WMF can confirm this. Ruslik_Zero 20:02, 15 November 2024 (UTC)Reply

Technically stewards can do it too. And, of course, trusting people not to lie to us. * Pppery * _{it has begun...} 20:10, 15 November 2024 (UTC)Reply

If someone's a crat and lies about having their 2FA enabled then that's probably breaching the trust we have in them as crats. Zippybonzo | talk | contribs (they/them) 09:12, 16 November 2024 (UTC)Reply

Haven't heard that nickname before Gaismagorm (talk) 13:32, 16 November 2024 (UTC)Reply

Yes, stewards can check this, and we periodically audit this for compliance on projects. Also, 'crats will very likely soon be able to check this as well - just some paperwork in that way right now (primarily so they can check it before assigning intadmin to others). — xaosflux ^Talk 10:29, 16 November 2024 (UTC)Reply

• Oppose, because the last time I checked, WMF's self-developed version of 2FA was not really fit for purpose. It's not like they're using Duo or Google or something. If anything, I'd support removing it from the roles requiring it now. --Floquenbeam (talk) 20:16, 15 November 2024 (UTC)Reply

  It works OK, but is certainly not ready for large-scale deployment due to the support model and capacity. Staff is generally responsive to recovery requests for those that WMF requires enrollment though. — xaosflux ^Talk 10:30, 16 November 2024 (UTC)Reply

• Support in theory - I use 2FA as a crat. Makes all the sense to me. As Xaos says above it's not ideal how it's setup. If it was just a "should this user group use 2FA", then I think yes. And, I'd argue administrators should as well. I can't support the technical solution we currently have being rolled out further without more Dev time. Lee Vilenski ^{(talk • contribs)} 13:37, 16 November 2024 (UTC)Reply

Support now. This is an security oversight. Regardless of the issues with WMF's 2FA this is still a flaw in the current security model since an attacker could gain interface admin without bypassing 2FA Chess (talk) (please mention me on reply) 00:44, 19 November 2024 (UTC)Reply

• Oppose per Floq, plus it's not clear how we're enforcing this: either we're revoking permissions (in which case several crats will lose the bit on inactivity alone) or we're not (in which case we're no more secure than before). A much better solution would be to just put the stewards in charge of adding/removing intadmin. Extraordinary Writ (talk) 06:13, 21 November 2024 (UTC)Reply

  I mean, I support implementing phab:T282624, which would make IA a steward-only thing. 2FA for interface admins is required by WMF, and only stewards can check whether the requirement is being followed. Letting 'crats check whether 2FA is enabled is stuck in phab purgatory, though there has been some movement in 2024. HouseBlaster (talk • he/they) 05:25, 22 November 2024 (UTC)Reply

I think we should have infoboxes for rituals and cultural practices, as studied in anthropology and religious studies. Parameters like associated culture, associated religion, purpose, origin, place, whether or not it is extinct, and when it is observed could be included. Examples of articles that could benefit are Akazehe, Savika, Sikidy, Haka, Bar Mitzvah, Quinceañera, Nggàm, and Hajj. ꧁Zanahary꧂ 19:17, 14 November 2024 (UTC)Reply

Can you perhaps make an example? Polygnotus (talk) 23:24, 14 November 2024 (UTC)Reply

I like infoboxes but I don't think these topics need it. PARAKANYAA (talk) 09:26, 15 November 2024 (UTC)Reply

I agree, there’s not really enough fields they’d have in common. Although I personally believe that every article that has an applicable infobox should use it, there’s also many articles that work best without them.  novov talk edits 10:38, 15 November 2024 (UTC)Reply

Yes, infoboxes work best when there are a number of basic uncontroversial factual characteristics that are shared by a group of articles. That's very far from the case here. Johnbod (talk) 14:06, 15 November 2024 (UTC)Reply

Johnbod said it well. To that I would add info that easily reduces to a short factoid. North8000 (talk) 14:11, 15 November 2024 (UTC)Reply

Unless it's been changed recently, we don't have a policy that infoboxes have to exist on any page, so I don't think we can put into policy for a specific subset. Lee Vilenski ^{(talk • contribs)} 13:38, 16 November 2024 (UTC)Reply

I’m confused by what you mean here ꧁Zanahary꧂ 19:23, 16 November 2024 (UTC)Reply

@Lee Vilenski Even the most diehard of infobox supporters recognise that infoboxes don't work on every page (broad, abstract concepts like Love and Existence for example) and that is one reason why we don't have (and never will have) any requirement for every article to have an infobox. That doesn't in any way preclude setting a policy that specific subsets of articles where they are uncontroversially useful (e.g. countries and NFL teams) must have an infobox if we wanted to. Some of the types of articles mentioned could have useful infoboxes (Hajj already does for example) not all of them can, so the OP's suggestion would not be a good set for such a policy, but that's not an argument against any set being appropriate. Thryduulf (talk) 20:58, 16 November 2024 (UTC)Reply

A recent attempt to impose an all-infobox policy failed emphatically, reinforcing the long-standing position the they are not compulsory. And in many areas, the approach using a specific template will not be suitable, for the reasons I gave above. If many "helpful" editors see a template with blank fields, they will attempt to fill them, regardless of appropriateness. Johnbod (talk) 17:22, 17 November 2024 (UTC)Reply

In re "editors see a template with blank fields, they will attempt to fill them": I think I see less of that these days than I used to. I'm not sure why (infoboxes are less empty? Fewer stray fields are listed? The visual editor hides the 'missing' lines from new editors? I dunno, but it's been a long while since I noticed someone filling in all the blanks on any article in my watchlist.) WhatamIdoing (talk) 00:43, 18 November 2024 (UTC)Reply

Maybe, or perhaps most of the blank fields are now filled? Johnbod (talk) 01:19, 18 November 2024 (UTC)Reply

Possibly. Or even if they're not filled in the wikitext, I think there's a certain amount of content that feels "normal", and if it displays some low but still normal-ish amount when reading, then people don't think that something's missing, so they don't try to "improve" it. WhatamIdoing (talk) 01:48, 18 November 2024 (UTC)Reply

 

Wikipedia talk:WikiProject Articles for creation has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. JJP_Master (she/they) 19:12, 15 November 2024 (UTC)Reply

Over at Wikipedia:Village_pump (policy), Graywalls raised an issue that I also independently encountered at Wikipedia:Articles for deletion/Jayson Sherlock. That is, that WP:BAND currently circumvents WP:GNG. That Village pump discussion is here. In light of that discussion, I am formally proposing an update to WP:BAND. Please see that proposal here. I have highlighted the addition to existing policy in green.--3family6 (Talk to me | See what I have done) 13:17, 18 November 2024 (UTC)Reply

Unless I'm misunderstanding something, then this proposal passing will be the equivalent of replacing criteria 2-11 with "they must meet the GNG"? Per several comments in the discussion at Wikipedia:Village_pump (policy)#Issues with antiquated guideline for WP:NBAND that essentially cause run of the mill non-notable items to be kept I'm not convinced that there is currently a problem that can be solved in this manner. Thryduulf (talk) 16:03, 18 November 2024 (UTC)Reply

Yes, this is basically saying that to have an article, the subject must meet GNG. There is an example in the article deletion discussion I mentioned above where NBAND was argued as an exception to GNG.--3family6 (Talk to me | See what I have done) 16:07, 18 November 2024 (UTC)Reply

A single discussion where somebody argues something that does not gain consensus is not evidence of a problem, let alone evidence that the proposed change would solve that problem. Thryduulf (talk) 16:26, 18 November 2024 (UTC)Reply

I would like to emphasize a key part of WP:N:

A topic is presumed to merit an article if:

1. It meets either the general notability guideline (GNG) below, or the criteria outlined in a subject-specific notability guideline (SNG); and
2. It is not excluded under the What Wikipedia is not policy.

This is a feature, not a bug; "or" does not mean "and". That WP:BAND currently circumvents WP:GNG is either trivially true (as creating subject-specific notability guidance outside of the GNG is the whole point of a WP:SNG) or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. — Red-tailed hawk _(nest) 16:50, 19 November 2024 (UTC)Reply

or arises from a fundamental misunderstanding of the purpose of the subject-specific notability guidelines. That might actually be what is at issue - there seem to be two different understandings of what SNG's are - supporting GNG or an alternative to it.--3family6 (Talk to me | See what I have done) 18:17, 19 November 2024 (UTC)Reply

Some SNGs take one approach; others take different approaches. WP:SNG was written to allow for the diversity of approaches represented by the current SNGs. Newimpartial (talk) 22:10, 22 November 2024 (UTC)Reply

I posted this in the other village pump thread, but while I'm generally fine with this proposal, I don't think it's coming from a place of understanding.

Basically, there's an assumption happening that record labels work off some kind of predictable tier system, where the Big 3 labels are home to the most famous artists, indie labels are home to the semi-famous ones, and everyone else is a non-notable bottom feeder. That's not how it works. One of the more notable albums of the year is Cindy Lee's Diamond Jubilee, which was self-released. Meanwhile, there are artists on the Big 3 who I would guess probably don't have significant coverage. This is because music journalism is dying, no one has staff and no one has money, and the range of artists being covered has shrunk dramatically. See this Columbia Journalism Review article for further on that.

So in other words, I don't think criterion 5 in NBAND is good or useful, but for the opposite reasons that this proposal suggests. The problem is not that people's random garage bands will be considered a "label." The problem is there is less and less correlation between being signed to a label and having significant coverage. (Ironically, the "albums" criterion is probably the more stringent one, because labels are less and less likely to put out a full-length album by an artist that isn't already established via singles and streaming tracks.)

I don't know what to do with that. (I honestly think the collapse of journalism and the shrinking scope of what gets reported on is a ticking time bomb for notability criteria across the board, but that's a whole other topic.) The most straightforward solution is to use WP:GNG, but I think it's important to have a correct understanding of exactly what musicians we're talking about here. The bar is way, way, way higher than "run of the mill non-notable items" now. The bar is one or two tiers below Sabrina Carpenter. Gnomingstuff (talk) 21:26, 19 November 2024 (UTC)Reply

Addendum: One way that this criterion could have value is to serve as a reminder that one Google search is not a sufficient WP:BEFORE check, because artists on notable labels are likely to have received coverage in print. (Another way this proposal is misinformed

- removing NBAND #5 will primarily affect older bands, not newer ones.) But alas, people do not do thorough checks even when they're reminded. Gnomingstuff (talk) 21:33, 19 November 2024 (UTC)Reply

I'd love to make BEFORE specifically include looking where sources are most likely to be found and explicitly state that looking at the first few pages of Google do not constitute a proper check. This always gets shot down in howls of protest at how dare I require people nominating pages for deletion to do more work than they imagine it took to create a three line sub-stub. I don't know how we get past this. Thryduulf (talk) 21:45, 19 November 2024 (UTC)Reply

I mean, it already does: The minimum search expected is a normal Google search, a Google Books search, a Google News search, and a Google News archive search; Google Scholar is suggested for academic subjects. The problem is that WP:BEFORE is not considered binding so there are no consequences to ignoring it. Gnomingstuff (talk) 21:51, 19 November 2024 (UTC)Reply

Gnomingstuff, there seems to be a lot of agreement that #5 as it stands does not make much sense for newer bands, but does make sense prior to the rise of streaming services. I'm seeing cut-offs suggested for the mid- to late-2000s.--3family6 (Talk to me | See what I have done) 12:53, 22 November 2024 (UTC)Reply

Yeah I get that. I don't agree with the reasoning but I basically agree with the conclusion. Gnomingstuff (talk) 17:27, 22 November 2024 (UTC)Reply

Your proposal operatively eliminates the SNG for bands. And also creates an even tougher GNG requirement than GNG by requiring that GNG compliance be demonstrated. I would like there to be some at least partial demonstration requirement added to GNG, but that's a whole 'nother issue and a secondary one in this case.

It also sort of misses the main point discussed at the linked pump discussion which was eliminating one or two items / "ways in" in the SNG.Sincerely, North8000 (talk) 18:04, 18 November 2024 (UTC)Reply

in line with this, NBAND can be eeaily fixed to makes sure that the idea that the criteria are a presumption of notability is added. I do not see any language like this though the intent seems to be there. That would quickly resolve one conflict. Mind you, deprecating or time gating criteria that do not make sense in modern music distribution is also a reasonable step though I would not remove them outright for historical purposes. Masem (t) 19:02, 18 November 2024 (UTC)Reply

this was precisely the intent. Am allowed to modify proposals if there have been no votes yet?--3family6 (Talk to me | See what I have done) 19:05, 18 November 2024 (UTC)Reply

I was amazed by how much our guidelines were written with Western popular musicians in mind when I started editing 17 years ago and it seems that nothing has changed since. It is so much easier for such a person to have an article about them than for other types or nationalities of musician. This is so obviously caused by Wikipedia's demographics that I hesitate to say anything further. Phil Bridger (talk) 19:18, 18 November 2024 (UTC)Reply

I wonder what effect imposing GNG would have on that. I've heard from some African editors that much of the real news for music and pop culture is posted on social media (i.e., actually posted on Facebook itself, not some website that's sorta kinda social media-like). So if you take away an objective but non-source-oriented criteria and substitute 'must have the kind of sources that are usual enough in the US and UK but are unusual in Nigeria', will that tip even further towards overrepresenting Western popular musicians?

My impression of the two albums/two films kinds of rules from back in the day is that the advice had more to do with WP:Build the web than with writing full articles. The expectation was that (if there weren't significant sources to justify writing more), the articles would usually be very brief ("Joe Film is an American actor who appeared in Film and Example" or "The Band is a British band who released Album in 1998 and Cover album in 2001") but that we'd still be able to provide non-red links in related pages and still not have to duplicate information. Consequently, I think the traditional thinking is closer to how we think of spinning off a list or splitting a long article, than about trying to justify the subject as "worthy" of a full, stand-alone article via extensive sourcing.

I could imagine people opposing this merely for fear of the resulting red links, and of course the idea of going beyond the GNG to require "demonstrating" it will turn off other editors. WhatamIdoing (talk) 19:36, 18 November 2024 (UTC)Reply

If it is established that reliable third party sources covering African music are going to include posts on social media rather than print or web publishing, then we should work to accomodate that so that we are more inclusive, rather than expect the more traditional forms of media. Masem (t) 20:05, 18 November 2024 (UTC)Reply

speaking for myself, I never had issues with using a third party posting via something like Facebook. I've always considered that to be a statement by that third party, they're just using Facebook as the medium. Am I understanding this example correctly?--3family6 (Talk to me | See what I have done) 20:18, 18 November 2024 (UTC)Reply

@3family6, user-generated content (including social media) is not a reliable source, except in limited instances (WP:ABOUTSELF). Schazjmd (talk) 20:31, 18 November 2024 (UTC)Reply

A statement by the band('s representatives) on the band's official facebook page is no more user-generated content and no less reliable than if that same statement was made by the same people was posted on the band's official website or quoted verbatim in a newspaper. Thryduulf (talk) 20:55, 18 November 2024 (UTC)Reply

Yes, Thryduulf, that's partly what I'm referring to. Schazjmd, I am indeed familiar with that guideline. In fact, my first edit on Wikipedia was removing content that I had generated as a user on another site. I'm referring to established media outlets posting something on Facebook. Like, say, Salon posted a story on Facebook rather than on their official site. It's gone through an editorial process, they just are using Facebook as a publishing medium.--3family6 (Talk to me | See what I have done) 21:00, 18 November 2024 (UTC)Reply

There isn't a wiki-requirement for the type of source that sources used, or even that they have sources. Of course such things still matter regarding regarding actual/ real world reliability of of the source. North8000 (talk) 21:36, 18 November 2024 (UTC)Reply

So keeping in mind that I have never had a Facebook account and have no experience with social media, my impression from these editors was that when they say they get news on Facebook, it's not necessarily the band that's posting (which wouldn't be Wikipedia:Independent sources) or even news articles being shared. Instead, it could be an ordinary comment by someone whom their followers believe is knowledgeable but who is not necessarily "official". For example – and I completely make this example up; the African editors who told me about this dilemma two years ago are welcome to disavow and correct anything I say – imagine a post by a professional DJ: They'll know things about music and bands, and they'll probably know more than a magazine writer assigned to do a piece on pop music in that city/country. They are "reliable" in the sense that people "rely on" them every day of the year. But it's outside the kinds of formal structures that we use to evaluate official sources: no editor, no publisher, no fact-checker, no peer review, etc. WhatamIdoing (talk) 05:33, 20 November 2024 (UTC)Reply

I'm all for adapting guidelines and policies for geographic and cultural considerations. However, I don't think this would get far, because it's essentially a using self-published sources for BLPs issue, and that's going to be a steep climb to weaken that policy.--3family6 (Talk to me | See what I have done) 12:55, 22 November 2024 (UTC)Reply

Yeah, I don't see any easy solution here. Even if it's not BLP-related, it relies on already knowing which accounts are the trustworthy ones, and there's no impartial way to evaluate an unfamiliar source. The post could say something like "This village is best known for cloth dyeing" or "The bus service there doesn't run on Sundays", and you'd still have to know whether that source is a good source of information. What if one person posts that the bus runs on Sundays and another person posts that it doesn't? An outsider would have no way of knowing which to trust. WhatamIdoing (talk) 23:28, 22 November 2024 (UTC)Reply

I always thought the the reason "two or more" was specified was that if there was only one the name could be redirected. Since that time there seems to have developed a dislike for stubs. I don't know where that came from (most articles in most traditional encyclopedias only consisted of one or two sentences, if that) but in order to satisfy that dislike maybe criterion 6 should be an encouragement to create a disambiguation page (or maybe a set index page, if you want to be pedantic) for the title. Phil Bridger (talk) 19:43, 22 November 2024 (UTC)Reply

I think that is correct. If there's only one, then you could:

• Have an article about the album
• Redirect the band's name to it
• Put the little bit of information you have about the band in the album article

but if there are multiple albums, then:

• You can have an article about each album
• But which one do you redirect the band's name to?
• And do you duplicate the information about the band in each of the album articles?

So it seemed easier to have an article. Now, of course, when the median size of an article is 13 sentences and 4 refs, and when we have a non-trivial minority of editors who think even that is pathetic, there is resistance to it. WhatamIdoing (talk) 23:33, 22 November 2024 (UTC)Reply

Comment I am interpreting this section as an RfCBEFORE, and contributing in that spirit.

Having briefly reviewed the linked discussions, I do not see a problem with NBAND itself that would justify deprecation (rather than revision). And turning NBAND into a predictor of GNG rather than a standalone SNG seems to me essentially akin to deprecation. Fixing specific criteria seems much more appropriate to me, given the issues raised to date.

There are what seem to me to be evident reasons why NBAND operates according to the same logic as NCREATIVE, which is explicitly excluded from WP:NOTINHERITED. These SNGs reflect the reality that creative people produce creative works, and that therefore the people creating those works gain encyclopedic relevance directly from having created them.

In addition, it seems to me that there are practical, navigational reasons (having to do with the affordances of hypertext, Wikipedia's list system, and Wikipedia's category system) to offer more consistent treatment rather than leaving each individual musician, each musical group and each album up to the vagaries of WP:NBASIC, WP:NORG and the WP:GNG.

There may be problems with specific NBAND criteria and the way they are sometimes used at AfD, but it seems entirely incommensurate to deprecate the whole SNG based on such marginal concerns. Newimpartial (talk) 20:31, 18 November 2024 (UTC)Reply

IMO the Wikipedia norm for a "just barely made it" band has sourcing that meets a slightly lenient interpretation of GNG, and the decision is influenced by somewhat meeting an SNG criteria, thus being more conducive to artists than for example a for-profit corporation. And the "norm" means that is is how Wikipedia as a whole wants it. There are folks out there who are at the extreme deletionist end of the spectrum and they will typically say that the above is not the case and piece together an unusually strignent "letter of the law" demand, even adding some things from essays saying that three sources that 100% meet GNG is the expectation. And so while I really think that the burden should shift to providing some GNG-ish sources (vs. just saying "they are out there" without actually supplying any) I'm loath to shift the balance too much, keeping the folks at the deletionist end of the spectrum in mind.

The pump discussion started with talking about how being signed by a label is no longer as indicative as it used to be and to remove it as being a key to the city of SNG compliance. I think there was support for that.

Sincerely, North8000 (talk) 21:16, 18 November 2024 (UTC)Reply

I agree with everyone else above that this proposal would gut WP:BAND, which I am not okay with. If you want to remove some criteria of WP:BAND, like #5, which I agree is a little opaque and outdated, fine. But this seems like a sneaky way of demolishing WP:BAND without openly saying so. Toadspike [Talk] 21:36, 18 November 2024 (UTC)Reply

I like the point North made, that our notability rules are set up to be more conducive to artists than for example a for-profit corporation. I've never thought of our guidelines on artists as particularly lax, but I know that NCORP is purposely stringent and that is the way things should be. Toadspike [Talk] 21:41, 18 November 2024 (UTC)Reply

• I'm not disappointed at the consensus emerging here, and hopefully it might help clarify discussions. there does seem to be some consensus to ditch criterion 5. I'm happy to amend it to that particular criterion disappearing and everything else stays.--3family6 (Talk to me | See what I have done) 21:48, 18 November 2024 (UTC)Reply

  I wonder if the most practical thing with criterion 5 (the one about releasing two albums on a label) would be to give it an end date. It was a useful criterion in the pre-streaming music world, so why not say "two albums on a label before 2010", or at whatever point editors decide that labels became less relevant? WhatamIdoing (talk) 16:42, 19 November 2024 (UTC)Reply

  Something like that I think makes sense.--3family6 (Talk to me | See what I have done) 18:14, 19 November 2024 (UTC)Reply

  I think this is a good idea but the cutoff should be earlier. The iTunes music store was founded in 2003, Spotify was founded in 2006, sometime around there would make more sense. Gnomingstuff (talk) 21:39, 19 November 2024 (UTC)Reply

  I cheerfully leave the determination of the date to someone else, but I note that Spotify#History says that Spotify reached the US market in July 2011, so I'm not sure that it had much effect in 2006. WhatamIdoing (talk) 05:37, 20 November 2024 (UTC)Reply

  Fair point. iTunes probably had the bigger impact anyway.

  If we are specifically concerned about self-published labels (again, I think the "more important indie" labels part already rules that out anyway, but whatever), the digital distribution companies making that happen DistroKid in 2012 and CDBaby in 2004. But even those had their main impact by partnering with Spotify and iTunes respectively. Gnomingstuff (talk) 17:32, 22 November 2024 (UTC)Reply

• What problem would this solve? – Joe (talk) 16:54, 19 November 2024 (UTC)Reply

  Articles which don't have reliable sources but that are defended by citing SNG as warranting inclusion, anyway.--3family6 (Talk to me | See what I have done) 18:18, 19 November 2024 (UTC)Reply

  Since the band's own website and the albums themselves are "reliable sources", we probably don't have any NBAND articles with no reliable sources. I would think that the main concern is the absence of Wikipedia:Independent sources, and especially of independent sources that have WP:SIGCOV and are notWikipedia:Interviews. WhatamIdoing (talk) 05:39, 20 November 2024 (UTC)Reply

  WP:DELPOL allows for deletion of "articles for which thorough attempts to find reliable sources to verify them have failed" – isn't that sufficient? – Joe (talk) 06:50, 20 November 2024 (UTC)Reply

  AIUI the problem there isn't that deletion isn't one of several available options according to policy; instead, the problem is that other editors do not agree to delete it. DELPOL allows such deletions, but it does not require them, and if I want to delete the article for being IMO undersourced, but other editors show up at AFD saying things like "qualifies under NBAND 5", then the article won't actually get deleted. WhatamIdoing (talk) 22:18, 21 November 2024 (UTC)Reply

  This is precisely the issue - NBAND is cited to contest deletions of content that doesn't have significant independent coverage.--3family6 (Talk to me | See what I have done) 12:57, 22 November 2024 (UTC)Reply

  That's what I thought. The rules don't result in the deletions "I" want; therefore, we must change the rules so other editors can't prevent the deletions "I" want. WhatamIdoing (talk) 23:36, 22 November 2024 (UTC)Reply

• Strongly opposed to the proposal as written by 3family6 as it's written at Wikipedia:Band_notability_proposal now, because it still contains the same text from #5 and #6, which are the two criteria from NBAND that I am objecting to that SNG's presence in the first place. I am unfamiliar with proposal process, but 3family6 went ahead and put it together on his own and doesn't want anyone editing it now. As I said, I don't know how proposals work, but if one user puts it together and quickly puts it out for a vote, is it off limits to editing? Graywalls (talk) 22:09, 21 November 2024 (UTC)Reply

  @Graywalls I didn't remove 5 and 6 because instead what I did is propose that 5 and 6 be supported with significant independent coverage from reliable sources.--3family6 (Talk to me | See what I have done) 12:58, 22 November 2024 (UTC)Reply

  Making criteria 2-11 contingent on also meeting criterion 1 is a much larger (and seemingly unnecessary) change compared to removing or reformulating 5 and 6. Newimpartial (talk) 13:08, 22 November 2024 (UTC)Reply

  I agree that it's a much larger change.--3family6 (Talk to me | See what I have done) 18:52, 22 November 2024 (UTC)Reply

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia technical issues and templates Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should the (mergehistory) permission be enabled for the importer group? Chaotic Enby (talk · contribs) 12:26, 20 November 2024 (UTC)Reply

1. Support. During Graham87's re-request for adminship, it was brought up that some of the more technical imports he performed required history merges. For now, this permission is only available to administrators, limiting the technical capabilities of non-administrator importers. A technical solution to this would be to enable the (mergehistory) permission for both administrators and importers. Chaotic Enby (talk · contribs) 12:26, 20 November 2024 (UTC)Reply
2. Yeah, why not; I didn't really see the point back then, I'm not sure, honestly, that I do now, but enough people have said it's useful work that who am I to deny it? And Graham87's obviously both good at it and committed to it. Support this proposal. SerialNumber54129 12:42, 20 November 2024 (UTC)Reply
3. Importers can be trusted to do this adjacent and very important work. Aaron Liu (talk) 12:46, 20 November 2024 (UTC)Reply
4. I was about to come propose this myself, but you beat me to it. QuicoleJR (talk) 12:57, 20 November 2024 (UTC)Reply
5. Support File importers are trusted enough. – robertsky (talk) 13:03, 20 November 2024 (UTC)Reply
6. Support; histmerges are often an essential part of importation work, as noted by Chaotic Enby. JJP_Master (she/they) 13:07, 20 November 2024 (UTC)Reply
7. (edit conflict) Support. Importers are editors who are highly trusted to undertake a very specialised role and it makes sense that they be given the rights needed to fully do the job properly. Thryduulf (talk) 13:09, 20 November 2024 (UTC)Reply
8. Support obviously – thanks, wow, did not expect this and I didn't know this would be feasible. As I said at my RRFA, I have my own issues with this tool (which explain why I didn't use it so much), but access to it is way better than no history-merge access at all. Graham87 (talk) 13:25, 20 November 2024 (UTC)Reply
9. Support if technically feasible. I really opposed the RRFA because Graham87 was asking for a role we didn't have. If they can do their importing/merging work without being able to block users, I would support that. (Normally I wouldn't support a one-off solution like this but, given the rareness of this, I think it makes sense here.) Note that I would also favor further unbundling admin powers beyond this nom. - RevelationDirect (talk) 13:35, 20 November 2024 (UTC)Reply

   Yes, it is feasible. — xaosflux ^Talk 13:39, 20 November 2024 (UTC)Reply

   Oops, just asked that question below. "Thanks for the prompt rely! RevelationDirect (talk) 13:41, 20 November 2024 (UTC)Reply

10. Support - clear benefit, and I don't see any reason not to. Tazerdadog (talk) 13:40, 20 November 2024 (UTC)Reply
11. Support sure. This is super niche, but basically: if someone can be trusted to be able to do an xmlimport, this is related and much less dangerous. If we're going to touch it I'm find also adding it to transwiki importers as well (even though we don't have any currenty) for parity. transwiki import is less dangerous, and most of the WP:RFPI items are able to be done that way -- in case any non-admins were looking to work in that area. — xaosflux ^Talk 13:44, 20 November 2024 (UTC)Reply
12. Support If somebody is a importer, they can be trusted with not messing up the databases any further while apply (merge-history). Sohom (talk) 13:58, 20 November 2024 (UTC)Reply
13. Support, makes sense to give this group the tools they need to do the job properly. CapitalSasha ~ talk 14:12, 20 November 2024 (UTC)Reply
14. Support. It just makes sense to do it. ~~ Jessintime (talk) 14:50, 20 November 2024 (UTC)Reply
15. Support. Makes sense if the two are so interlinked. If an editor is trusted with one, they should also be fine to have the other. ---- Patar knight - ^chat/_{contributions} 15:41, 20 November 2024 (UTC)Reply
16. Support. This seems like a bit of an exceptional case, but I do think that it's worthwhile to allow importers to merge histories for practical reasons. And the role is so restricted that I don't have trust issues here. — Red-tailed hawk _(nest) 15:53, 20 November 2024 (UTC)Reply
17. Support: Makes perfect sense from my perspective. Hey man im josh (talk) 16:06, 20 November 2024 (UTC)Reply
18. Support, sensible unbundling. Nobody becomes an importer without scrutiny so this seems fine to me. WindTempos _they ^{(talk • contribs)} 17:02, 20 November 2024 (UTC)Reply
19. Support per xaosflux.—Alalch E. 17:32, 20 November 2024 (UTC)Reply
20. Support. Graham's tireless work in this area is the demonstration of why this should be permitted.  — Hex • talk 17:41, 20 November 2024 (UTC)Reply
21. I got to support Graham's importer request once upon a time. Pleased to support this request as well. Even setting aside the direct impetus, this is a logical bundling of the tools that does not raise the required trust level for this small user group. -- Tamzin^{[cetacean needed]} (they|xe) 17:53, 20 November 2024 (UTC)Reply
22. Support --Redrose64 🌹 (talk) 21:05, 20 November 2024 (UTC)Reply
23. Support See no reason not to. -- Pawnkingthree (talk) 21:18, 20 November 2024 (UTC)Reply
24. Suppport. A logical part of the bundle. Sincerely, Dilettante 21:33, 20 November 2024 (UTC)Reply
25. Clearly yes. There's very low risk of collateral damage here and obvious benefits.—S Marshall T/C 23:23, 20 November 2024 (UTC)Reply
26. Graham (the only non admin importer) is trusted enough for this, no reason not to. charlotte ^👸♥📱 06:05, 21 November 2024 (UTC)Reply
27. Support. Let's at least permit Graham to continue his archaeological work. No one else does this, and it requires the mergehistory perm. Folly Mox (talk) 11:15, 21 November 2024 (UTC)Reply
28. Graham has a clear use-case for this so I have no objections. JavaHurricane 13:49, 21 November 2024 (UTC)Reply
29. Support I see no problems with this. EggRoll97 ^(talk) 14:56, 21 November 2024 (UTC)Reply
30. Support Seems like this is a necessary change given that importing often requires these merges. Noah, BSBA^Talk 15:53, 21 November 2024 (UTC)Reply
31. Support and would go for a WP:SNOW close as well, given the margin.– Closed Limelike Curves (talk) 21:28, 21 November 2024 (UTC)Reply
32. Support, obviously, this is invaluable work and it would be a clear negative for it to stop being done, which is effectively what would happen otherwise. Gnomingstuff (talk) 01:51, 22 November 2024 (UTC)Reply
33. Support My gut doesn't like this (mergehistory feels like a distinct permission from importer), but I do trust Graham87 to use the tool and think the chance of us ever getting any other non-admin importers is negligible, so I guess I support this. * Pppery * _{it has begun...} 01:54, 22 November 2024 (UTC)Reply
34. Support seems like a sensible thing to do. LEPRICAVARK (talk) 12:29, 22 November 2024 (UTC)Reply
35. Support Importers are already highly trusted and it is granted by a steward, so this would be a narrow unbundling that would probably satisfy any WMF legal requirements. And I would trust Graham87 with this tool. Abzeronow (talk) 20:58, 22 November 2024 (UTC)Reply
36. Support Importers already can fuck with the page history a lot more than someone with history merge rights can. I see no reason to not allow importers to merge history. ThatIPEditor ^{Talk · Contribs} 02:04, 23 November 2024 (UTC)Reply

1. Oppose the current system works just fine. I'm not seeing any compelling reason to carve out an exception for two users. Isaidnoway (talk) 16:27, 20 November 2024 (UTC)Reply

   Because importing is importing a bunch of revisions into the history of the page. It's quite similar and often needed. Those two users are the only ones who maintain this area critical to Wikipedia, and that's the system, which has persisted due to their being able to merge history; now that Graham's been stripped of history merging, half of his duty and thus a quarter of this system, we need to rectify it or risk destabilizing of the system. Aaron Liu (talk) 16:37, 20 November 2024 (UTC)Reply

   There is no risk of destabilizing the system, that's hyperbolic nonsense. Isaidnoway (talk) 20:29, 20 November 2024 (UTC)Reply

   The system is only two people doing this work, and we're otherwise taking away half of what one of them does. I don't see any reason not to do this. Aaron Liu (talk) 20:36, 20 November 2024 (UTC)Reply

   It no longer "works fine". Your information may be outdated. Folly Mox (talk) 11:17, 21 November 2024 (UTC)Reply

   My information is not "outdated". Thanks. Isaidnoway (talk) 20:52, 21 November 2024 (UTC)Reply

• Scope Clarification Are @Xaosflux: and Graham87 the only two editors with this permission? What is the process for getting the importer permission? - RevelationDirect (talk) 13:40, 20 November 2024 (UTC)Reply

  @RevelationDirect yes, criteria is basically a user-specific RFC. This is a super niche area; though I'd be open to expanding this permission to the less dangersour transwiki-importer group -- which also requires a per-user rfc to add too, but with a lower bar to entry. — xaosflux ^Talk 13:46, 20 November 2024 (UTC)Reply

  @RevelationDirect: (after EC) Yes, we're the only ones; the permission has historically been obtained either through a request to this page (as I did) or Wikipedia talk:Requests for page importation (as Xaosflux did). Graham87 (talk) 13:55, 20 November 2024 (UTC)Reply

  @Graham87: Since the topic has come up, I've actually wanted to jump into importing for a while (I'll be quite honest, probably transwiki importing, given it seems like a better place to start out at than XML import), but how does one really get into that line of work? I presume the common answer would probably be the direction of WP:RFA, but that seems like a bit much given a right already exists that is outside of the sysop group. EggRoll97 ^(talk) 20:54, 20 November 2024 (UTC)Reply

  @EggRoll97 transwiki comes with admin, so most people that want to deal with it go that route, WP:RFA. It is possible to add transwiki in isolation - to do so start a discussion (suggest over at Wikipedia talk:Requests for page importation). The discussion will need to be well advertised (WP:AN and WP:VPM are good places), run for a reasonable time to allow feedback (about a week), be well attended, and show a good consensus of support (someone else should 'close' the discussion with such showing). The bar for transwiki is generally less than for sysop, while the bar for importxml access is generally higher than sysop. At that point, it would get processed over at m:Steward requests/Permissions#Miscellaneous requests. — xaosflux ^Talk 11:51, 21 November 2024 (UTC)Reply

  @Xaosflux: Yeah that. @EggRoll97:, I did notice your ping, but I wasn't sure how to respond (given that no-one,, especially a non-admin, has asked such a question before) then got distracted by other things. If you have a good idea how/where you'd like to use the import tool, feel free to float your proposal as noted in the message above. Graham87 (talk) 15:52, 21 November 2024 (UTC)Reply

  I would also support it. If more users are interested in doing this kind of work, it could be useful for them to have the relevant tools. Chaotic Enby (talk · contribs) 13:49, 20 November 2024 (UTC)Reply

• Technical Feasability Is this request technically feasible, i.e. can the proposed permissions be granted à la carte? - RevelationDirect (talk) 13:40, 20 November 2024 (UTC)Reply

  (It is, see above.) RevelationDirect (talk) 13:42, 20 November 2024 (UTC)Reply

  It is, and no. The only way we can assign permissions is to add the permissions to a group, then users can be added to the group. It would be possible to create an entirely new group that has this permission - but that seems overkill here unless it was going to do a whole lot more (like a "technician" group that had a bunch of other sub-admin permissions). — xaosflux ^Talk 13:49, 20 November 2024 (UTC)Reply

  Yes. It'd involve a small patch to https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/master/wmf-config/core-Permissions.php#714 –Novem Linguae (talk) 23:09, 21 November 2024 (UTC)Reply

• I'm concerned by the fact that Graham has said Special:MergeHistory results in sub-optimal outcomes (that it is better to use Special:Delete and Special:Undelete) and how this step would encourage non-admin page importers (Graham, and anyone else who might obtain the right in the future) to use an inferior process for history merges. —Compassionate727 ^(T·C) 14:03, 20 November 2024 (UTC)Reply

  @Compassionate727 those are certainly case-by-case. Sometimes historymerge is the right tool for the job. Any complicated merge/imports that require deletion are going to have to be handled by admins unless we want to make some new sub-admin technician group in the future (the community has repeatedly rejected such proposals though) which could have extra tools (like delete/undelete and others) but only be permitted to use them for certain purposes. — xaosflux ^Talk 14:09, 20 November 2024 (UTC)Reply

  Graham believes that the MergeHistory tool is inferior simply because it doesn't log a merge on the target page. I see no problem with this view. Aaron Liu (talk) 14:11, 20 November 2024 (UTC)Reply

  Not everyone agrees with my view, such as Pppery; see this Phabricator comment. Graham87 (talk) 14:48, 20 November 2024 (UTC)Reply

  I've started an RfC below regarding this issue; I do think it would be useful to have community input if there is any desire to ever build this functionality. — Red-tailed hawk _(nest) 15:52, 20 November 2024 (UTC)Reply