Wikipedia talk:Protection policy/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

Revised proposal to improve extended confirmed grants

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

There is community consensus for the proposals. As noted in the discussion, system administrators might give additional scrutiny for security or necessity (particularly as to the last bulletpoint) and details may need to be adjusted. I'll notify WP:EFN and leave implementation to experienced edit filter people. ~ Jenson (SilverLocust 💬) 19:28, 30 October 2025 (UTC)

---

Background:

• The main issue with extended confirmed protection (ECP) is that it's trivial to run up edit counts to 500 edits very quickly. Even though most extreme gaming is detected relatively quickly in several different ways, just a few minutes is long enough to seriously disrupt ECP articles, and some accounts slip through even with the new measures we have in place.
• Full protection is not a good solution for this because it prevents editing to important articles and vandals gaming ECP will shift to other pages when their target is fully protected (as happened while Donald Trump was fully protected).

Revised proposal:

• Update the site configuration so the autoconfirmed group is required before an account is granted extendedconfirmed. It's a small modification to the wmgAutopromoteOnceonEdit setting (see the enwiki settings).
• We allow several high accuracy edit filters to revoke autoconfirmed. This is already supported natively. The edit filter managers would also update MediaWiki:Abusefilter-degrouped to be more general and less accusatory.
• Remove blockautopromote from wgAbuseFilterActionRestrictions so the blockautopromote action won't be disabled when the filters have a high rate of matches (which already happens because ECP gaming happens at a high rate). This will also allow non-administrator EFMs to edit these abuse filters (they can already restore autoconfirmed when a filter removes it so this is not a big deal).

This will help address the biggest problem we have right now with ECP: the 5-30 minute delay between ECP being granted and an administrator at AIV acting on an automated report from one of several edit filters. Daniel Quinlan (talk) 20:47, 22 September 2025 (UTC)

Survey (extended confirmed grants)

• Support, I think this would me an improvement in stopping some of the worst abuse and disruption. ScottishFinnishRadish (talk) 21:54, 22 September 2025 (UTC)
• Support, obviously. This is a no brainer.—S Marshall T/C 23:18, 22 September 2025 (UTC)
• Support, obviously per above. -- Sohom (talk) 23:46, 22 September 2025 (UTC)
• Support, as an EFM. – PharyngealImplosive7 (talk) 00:56, 23 September 2025 (UTC)

• Comment (Summoned by bot): I'm leaning support, but reserving my final !vote until I've mulled over implications of the technical changes, which are not as second nature to me as perhaps they are to the admins and functionaries who have responded already. That said, I do have some procedural concerns. First and foremost, is this really the appropriate place for this discussion? It is not concerned with making changes to the protection policy but rather user rights management. Of related concern, is this proposal being advertised in appropriate community fora? This would be package of non-trivial changes with implications to the threshold at which new users gain important indicia of initial community standing. I think it is very much deserving of a WP:CENT listing, and at the very least should be promoted via WP:VPP. SnowRise ^{let's rap} 05:41, 23 September 2025 (UTC)

  @Snow Rise: Immediately after posting this RFC, I posted notices on both WP:EFN and WP:VPP. As the changes are focused on the extendedconfirmed group which is only used to allow edits to extended-confirmed protected pages (see Special:ListGroupRights), this page seemed like the most appropriate place. I also considered WP:EFN. This page is also watched by more people (2,447 compared to 351 for EFN). Daniel Quinlan (talk) 06:17, 23 September 2025 (UTC)

  Thanks for the extra info, Daniel. I still think WP:UG was probably the right place for this discussion, but insofar as there is a listing at VPP, I think that is the more important piece. That said, I have some reservations in the discussion section below about the ambiguity concerning how the filters would be adapted; perhaps you could shed some light there? SnowRise ^{let's rap} 21:49, 23 September 2025 (UTC)

  I've posted a notice on WP:UG, and I've responded below. Daniel Quinlan (talk) 00:56, 24 September 2025 (UTC)

  Thank you again, Daniel; I appreciate the indulgence. I respect where this proposal is coming from (I've seen some flabbergasting displays of organized disruption of late that are almost off the charts compared to what I have historically observed in my time with the project), and I don't mean to be a spanner in the works just for the sake of it. I just want to make sure we are not moving so fast on this as a solution that we fail to create appropriate safeguards to prevent unintended consequences. SnowRise ^{let's rap} 01:31, 24 September 2025 (UTC)

• Support I have seen people who created several accounts, waited 30 days, then made 500 edits in a very short time. They then run wild. More tools are needed. Johnuniq (talk) 09:31, 23 September 2025 (UTC)
• Support given the nature of the LTA disruption this is intended to combat I've feeling this will only end up being one part of a more extensive solution, but it's a good start and the implementation costs are low. 184.152.65.118 (talk) 00:52, 23 September 2025 (UTC)
• Support, the background suggests a need for changes. --TenWhile6 21:37, 23 September 2025 (UTC)
• Oppose. I agree that the background suggests a need for change. Per SnowRise, however, I am unconvinced that the proposed change in its current form is the correct and proportionate response to that need. I'm concerned we've got a case of the politician's syllogism here. Thryduulf (talk) 23:41, 23 September 2025 (UTC)
• Support points 1&2. Only support point 3 if there's no other option. Removing the throttle on autoconfirmed revocations would remove a major failsafe. A single misconfigured filter could lead to up to 100% of autoconfirmed users having the permission revoked upon edit. Yes, we could fix that relatively quickly, but it seems like something to be avoided if at all possible. Otherwise this is an xkcd:2677 problem. I've talked to Daniel Q by email and it seems to me—I'm not 100% sure—that the throttling issues that justify point 3 could equally be fixed by splitting the AC-revocation logic from other functions of the filter in question. I think how we should approach it is this: Consensus in this RfC should constitute community consensus to allow removing blockautopromote from wgAbuseFilterActionRestrictions, but whether we actually do this should be decided in a private Phabricator ticket where edit filter managers and sysadmins can discuss the use cases that might necessitate the change, and whether alternative options exist. -- Tamzin^{[cetacean needed]} (they|xe|🤷) 01:44, 24 September 2025 (UTC)

  I think that's reasonable, and the RfC should certainly not be invoked to hand-tie details if problems emerge or a better technical implementation becomes available that achieves the same objective. Authorizes if necessary, but does not require. 184.152.65.118 (talk) 20:52, 25 September 2025 (UTC)

  IP, For what it is worth, these RFCs are considered advisory, the sysadmins/deployers take the final decisions and if there is a strong technical reason to not do something, it will be brought up. Also, another thing to note is that the way the process works within the technical community works is that RFCs are mandatory/heavily encouraged for these kinds of configuration changes. (See Requesting_wiki_configuration_changes) If a better technical implementation surfaces that is significantly different, consensus would typically be required if it is a long-term configuration option change. (There are obvious exemptions for security and WMF reasons but for the purposes of this RFC it is better to think of it as authorizing this specific way to be used if required rather than a "do what it takes" scenario). Sohom (talk) 02:50, 26 September 2025 (UTC)

• Support. I admit I don't fully understand what's going on here, but I understand enough to see that these changes could be beneficial and I trust that Daniel and the EFM team knows what they're doing. Per Tamzin this should be seen as consensus allowing these changes, not requiring them. Toadspike [Talk] 11:20, 24 September 2025 (UTC)
• Support it's definitely better than what we have now, and I also recommend having someone review the edits before granting extended confirmation to users (partially to ensure no sleeping before activity begins). SNUGGUMS (talk / edits) 12:29, 24 September 2025 (UTC)
• Support I do agree with Toadspike, this shouldn't be seen as a requirement. If we can't make a filter that is sufficiently free from false positives, we shouldn't have one set to revoke autoconfirmed at all. At the same time, this is a pressing issue on a scale that isn't feasible for our current admin numbers, and frankly is overwhelming for anyone trying to slow down the disruption, so I'm not opposed to revoking autoconfirmed with very finely-tuned filters. EggRoll97 ^(talk) 23:41, 24 September 2025 (UTC)

  The question is, what does a 'finely tuned' tuned filter look like? Part of the issue here is that a substantial portion of the general community has adopted an aggress posture on "gaming ECP status", but the community at large has never bothered to work through what exactly that consists of, let alone define clear metrics for detecting it in a consistent and reasonably fair fashion. It's a very nebulously defined problem. We have a crystal clear, community-sanctioned standard for the thresholds that are meant to normally trigger ECP: 30 days, 500 edits. But the idea that some people are doing wrong by complying with the word of that standard, while actually engaged in block evasion (or otherwise planning disruption), while reasonable in the abstract, leads to some rather obvious issues since distinguishing these motives through edit data is no simple task, with few super reliable metrics.

  We have people saying that this can be done with well-calibrated filters, but there has always been a dearth of evidence as to why we should treat these tests as based on empirically valid analytics. Certainly there has been no public facing research (or even detailed reasoning) that I have ever seen in any of the discussions on this topic to prove (or even indicate) why the "evidence" relied upon to distinguish bad actors from run-of-the-mill new users are reliable. Worse, I'm not even certain that many of the most strident activists for relying on these tools even know precisely how they function. I'm more than a little concerned that every time I have asked for even a bare bones description of the filters, I have been met with utter silence. There are plenty of innocent reasons why that may be happening, but I do worry it is entirely possible that many supporting this proposal (and others that have gotten us to this point) don't even really know how they operate, and can't give a cogent, detailed answer on why we can be confident on their reliability in catching bad actors or avoiding false positives. Or for that matter, some may be aware that the false positives are actually non-trivial (or highly unknown and subject to speculation), but are not eager to relay that fact, because they have decided themselves that the cost-benefit is worthwhile, in their personal views on the broader-level issues.

  This whole process is very insular and non-transparent so far, and that should be serious reason to consider pumping the breaks on going further whole-hog on letting an automated system slow down full authorization of new editors, given the implications for the project, ideological and practical. That's all the more a concern where ArbCom has independently expanded the implications/applicability of ECP massively in the last two years. I really think we need clearer answers on how all of this works before we just rubber stamp a proposal like this. There's a rush to do something, because something is clearly needed (believe me, I've seen it; the manner in which huge swarms of sock- and meat-puppets can be readily organized to overwhelm regular good faith editors has led to some astounding displays of disruption lately). But we could end up doing more harm than good if we don't base this particular decision on sound data. And meaning no disrespect to those who have supported this proposal already, but where is it? It really should come with or parallel to the proposal, and there should be no rush to greenlight this 'solution' until we have some more significant proof that it will do what is claimed, and that we have a clear idea of what the collateral consequences might be. SnowRise ^{let's rap} 17:40, 25 September 2025 (UTC)

  @Snow Rise, with respect, you're bringing some almost completely unrelated anxieties into this discussion. The EFMs are talking about ways to reduce bot-facilitated vandalism, not humans who might maybe be gaming to get into PIA. -- asilvering (talk) 18:39, 25 September 2025 (UTC)

  Well, I don't see how we could reasonably describe the concerns as unrelated; these filters (however they are calibrated) are going to impact all users who match a certain use profile. The rate of false positives will be a constant, relative to the coding of the filters, regardless of what the ultimate motives of the bad faith actors are, and regardless of what our motives are for implementing or altering the system. If there's something in the detection algorithms that specifically looks for conduct highly-indicative of machine-assisted gaming, that's great; I'd love to see that as it would be one point in favour of a presumption of a system that is conservative in its flagging and well-engineered to avoid false positives.

  The problem is, we haven't had confirmation of that here. It should really have come with the proposal, and its not heartening that no one with that knowledge has stepped up to provide it since. And there's another concern here: once the community greenlights this change, it takes oversight substantially out of the hands of the general community, unless this proposal is augmented to include periodic review of the filters themselves. If not, the filter devs and maintainers have functionally unrestricted ability to change the criteria by which people get ECP status and depending un just how drastic the changes are, it is unlikely that almost anyone in the community would even be aware, let alone someone inclined to question these changes. That's an awful lot of influence over the gates to full participating in the project consolidated in a few hands with essential no community review. And even if we presumed that every one of those devs was so committed to community transparency that they would hold a meaningful community consult for every change (and come on, unlikely, right?), there would still be pretty significant potential for human error (per Tamzin's concerns raised above).

  So, regardless of the category of bad actor this proposal is meant to target, the implications about the potential side effects remain a serious concern, because we just don't know what the net itself looks like. I'm by no means per se opposed to this proposal: I've tried to make that clear. But we really should have some more answers about the current technical implementation of the filters before we rubber stamp it. And very possibly some back-end protections to that once this system becomes automated, technical decisions which further clamp down on when new users become full-rights users have some sort of transparent review process, be it automatic or periodic. SnowRise ^{let's rap} 19:04, 25 September 2025 (UTC)

  Non-admin EFM here. Without revealing too many details of private filters, the filters we are talking about enabling blockautopromote are exceptionally accurate. Some of them have had no false positives for months at a time.

  The edit filter community already requires a very low amount of false positives and consensus either at WP:EFN (public filters) or the mailing list (private) to enable a disallow filter, which stops the action (edit, move, etc.) without removing any permissions. In that way, we are already quite conservative. For anything removing rights, we would probably be even more cautious and ensure that the filter has had almost zero or no false positives.

  Besides, all admins and non-admin edit filter helpers have view access to private filters, so it is quite likely that if anything is being changed unfairly, someone will speak up.

  A transparent review process would be nice for these filters; I know, but the problem is LTAs are also looking at the filter logs and would use any opportunity to make the efficacy of the filters lower, potentially leading to false positives.

  Hopefully this has clarified how these actions would work without revealing the fine machinery of the filters themselves. – PharyngealImplosive7 (talk) 01:00, 26 September 2025 (UTC)

  Thank you, Pharyngeal--that is indeed helpful. Honestly, I still have misgivings. Combining a lack of transparency on the specific functionality of the edit filters themselves (even for reasonable WP:OPAQUE reasons) with the grant of a blank check to make those same filters automated in perpetuity (because let's be honest, once greenlit, this way of doing things is all but certain not to ever be rolled back) leaves a lot of uncertainty and more or less permanently commits the project to a more hardline approach to ECP enforcement without corresponding oversight checks from the general community. I have nothing but great faith in the EFM community's intentions to act in good faith in the project's best interests, but at the same time, you all might make decisions hardening access to EC status that the larger community would not support, but can't object to, because only the EFMs and admin corps would ever know about them.

  And I'd probably be a lot less nervous about that, if this were not coming so close on the heels of ArbCom essentially making every CTOP topic subject to ECP. For years a vocal minority has been trying to convince this project to adopt a "registered editors only" policy, which has been roundly rejected by the broader community. And yet, so much access to the project has been made into the exclusive purview of the veteran editor, bit-by-bit in ArbCom decisions and arguably overzealous proposals meant to protect against disruption, that the distinction has increasingly less and less meaning. The community nominally continues to be strongly committed to the "encyclopedia anyone can edit" ethos, and continues to generally affirm the rights of unregistered editors to contribute, but in practice it does not want to do anything to put the brakes on ArbCom's increasingly sprawling remit as it places every half-way-controversial subject matter under CTOP and ECP. And the same time, our fears of the barbarians at the gates cause us to increasingly support more and more restrictive measures in general community proposals as well. And the most frustrating part? I can't even bring myself to oppose this proposal outright, because despite my reservations, I also can't convince myself it is unnecessary, in light of some of the disruption I have seen lately.

  All I know for certain is that I am deeply depressed that these are our options. I know it's not a 1:1 relationship by any means, but I'm distressed that the slow but steady roll-back of the open participation and diversity of perspective principles on this project are such a mirror of what is happening in our societies at large. I just don't like this feeling. And while I don't feel that the perspectives of the support !votes are unreasonable, I am bothered that I seem to be part of such a small minority of community members who have such heavy reservations about this increasing consolidation of access to shaping our content and even participating in the consensus process. Each individual step we take on this road might seem entirely reasonable in the context in which it is taken, but I cannot shake the feeling that they are collectively slowly choking the life out of the future of the project as a whole. Anyway, that's my last word on the subject. I am officially, but ambivalently, Neutral. SnowRise ^{let's rap} 05:42, 26 September 2025 (UTC)

  Sometimes there is no good option. We want to be open and transparent. Trolls want to troll. Denying tools to combat the trolls ends up driving away good editors who are fed up with wasting their time on a project that can't defend itself. Johnuniq (talk) 05:56, 26 September 2025 (UTC)

• Support all 3 per nom FaviFake (talk) 18:47, 25 September 2025 (UTC)
• Support points 1 & 2 per nom. Neutral on point 3 as I don't think I'm knowledgable enough to comment. Graham11 (talk) 00:22, 1 October 2025 (UTC)
• Oppose items 2–3 as written, prefer a bright-line cooldown – I share the goal of stopping ECP gaming, but items 2–3 effectively change a clear, predictable 30/500 threshold into 30/500 + pass an opaque, evolving “authenticity” test. Several experienced editors in this thread explicitly say they can’t evaluate how these filters work or their false-positive rates, and others raise oversight concerns about revoking autopromotion before admin review. That should give us pause.

Alternative (an ECP cooldown period): If the core problem is that EC can be gamed and acted upon before a human reviews filter reports, a simpler and more transparent fix would be to introduce a short cooldown after 30/500 (e.g., 72 hours–1 week) before EC is granted. During that window, filters can still flag and admins can act. Absent action, the account is automatically promoted. This preserves a bright-line rule new editors can understand, avoids a hidden moving target, and directly addresses the reaction-time gap without relying on complex filters or vesting gatekeeping in a small technical cohort. spintheer (talk) 05:16, 5 October 2025 (UTC)

@Spintheer: The problem with a cooldown or delay approach (which was discussed prior to this proposal) is that it would require rather significant code additions to MediaWiki. I think it's a great approach (I may be biased as one of the people who proposed it), but it's also not an option any time soon. And under this proposal, even if there is a rare mistake, it will be easily remedied on WP:EFFPR (users will receive a notification with links on how to appeal). In addition, because these accounts will be reported to WP:AIV, administrators will also have an early opportunity to undo any mistakes. And the goal is zero mistakes. The alternative and status quo is full protections. For example, the Donald Trump article was fully protected for a week in September because the ECP gaming and vandalism was so bad, and other articles have had the same issue recently. We have an option right now to remedy that without any code changes. Daniel Quinlan (talk) 06:38, 5 October 2025 (UTC)

@Daniel Quinlan:

Technical: If there’s a public link to the earlier discussion, could you share it? My understanding is that we can get the desired cooldown without core changes by adding another AbuseFilter: match when an account first meets >=500 edits and >=30 days and is not yet in extendedconfirmed, then apply blockautopromote for 5 days. AbuseFilter actions run in the same request, so the hold is in place before the edit completes; after the hold expires, the normal autopromotion would grant EC on the next edit. If I’m mistaken about that sequencing, I’m happy to be corrected.

Policy: I agree the underlying problem is real and urgent. My concern is that items 2–3 would move a major (and increasingly broader) gate behind opaque, freely-changing criteria maintained by a small technical cohort. Even with the best intentions, that risks turning the practical EC requirement into “30/500 + pass an undisclosed authenticity screen,” which is hard for newcomers to understand or review. If we use filters at all: (1) could we keep it deterministic and transparent (i.e., a fixed short cooldown)? (2) publish basic running hit/appeal stats? (3) time-box this whole idea pending a real cooldown fix (which you agree makes more sense)? That would help address the abuse without permanently turning EC into an opaque moving target. spintheer (talk) 13:05, 7 October 2025 (UTC)

Appeals (and thus hit rates?) will be onwiki and transperant at WP:PERM/EC. If the community feels there are too many of them, folks will scream. To reiterate, the number of false positives we want (and have) from the aforementioned filters is 0 and we do not expect to use it outside of cases of persistent abuse. The cool down idea while it sounds great on paper is going to either devolve into a "existing EC deadline + 7 days" (and nobody looks at the accounts) or a massive backlog for administrators having to go through every single EC promoted user's contribution history which imo is unworkable. Sohom (talk) 14:11, 7 October 2025 (UTC)

Thanks for the reply, but I think we’re talking past each other on what a cooldown would do. In the version proposed, the 3–5 day window doesn’t mean admins must vet every new EC candidate. It’s either:

(A) A targeted hold, where a short blockautopromote is applied only when an EC-gaming filter matches. That gives admins time to act only on the flagged accounts. If, as you say, filters are near-zero FP and used sparingly, the volume should be tiny and not create a backlog.

(B) A deterministic hold, which is a neutral, short hold for everyone who first meets 30/500, with automatic promotion when the window expires.

In either case, admins only attend over people for whom the hand-crafted admin filters triggers, not everyone.

I agree we should act quickly on abuse, but I’m wary of turning EC into "30/500 plus pass an undisclosed authenticity screen." I’d be willing to reconsider my !vote if items 2–3 are made a time-boxed stopgap (with published metrics and a scheduled community review/sunset) while we pursue a proper cooldown solution. spintheer (talk) 14:08, 10 October 2025 (UTC)

@Spintheer, How is the targeted hold different from the current proposal ? Again to remind you whenever the right is yanked, folks will get a big red notification in their notification box. If they feel like they have done nothing wrong, they can rush to WP:PERM/EC (which will be linked to in the notice) and get their rights back. The "undisclosed authenticity screen" does not exist, because a edit filter hit will be disclosed to them, and will show up in the technical logs which can be accessed by every administrator. This is not to mention that the logs are typically monitored by EFM and technically minded admins who also scan for false-positives themselves. I don't see a valid reason here to let the vandals in this context have any leeway of being able to game our system by waiting 7 days and hoping a admin misses them especially considering the damage they have done. Remember, the vandals in these context are using automated tooling, if we try to add a "human check" element, they are gonna be able to bypass it purely by sheer luck, by evading manual checks or by throwing numbers at the problem and we are back to square one with a actual "undisclosed authenticity screen" because now a admin needs to use their discretion to weed out the vandals during the 7 day period. Sohom (talk) 13:46, 15 October 2025 (UTC)

There will also be an entry at WP:AIV/TB2 which will be reviewed by an admin when checking if the account is actually gaming and needs to be blocked, so there's essentially an automatic review. ScottishFinnishRadish (talk) 13:51, 15 October 2025 (UTC)

I hope that this clarifies:

• What the RFC proposes now (revocation model): EC is granted at 30/500, and then a filter can revoke it. Restoration depends on humans (PERM/EC, AIV/TB2). That creates an open-ended gate whose duration is whatever the current backlog happens to be.
• What I’m proposing (targeted hold model/cooldown): When a filter matches on an account that has just met 30/500, apply a short hold (e.g., 3–7 days) before EC is conferred. During that fixed window admins can act; if no action is taken, EC is granted automatically.

The two approaches use the same tooling, but the targeted hold model has a guaranteed off-ramp: revocation has no time guarantee. Good-faith editors can sit in limbo until someone reviews their case. A hold has a predictable, auditable window (e.g a week) after which rights are granted if no action is taken. That preserves a bright-line, newcomer-comprehensible rule: 30/500 -> short wait (if flagged) -> EC.

On the "vandals will just wait 7 days" concern: during the hold they cannot use EC-only tools or edit ECP pages, which is the immediate harm that this RFC is aiming to prevent. If there is somehow no admin action within 7 days, that is a signal that (i) the filter's flag wasn’t actionable enough to justify continuing to withhold a core right or (ii) there is a backlog, which we received assurances won't happen because the filter is very good.

On filter health metrics: Notifications are good, but appeals volume alone won’t tell us if calibration is right. Hoping that newcomers will have the confidence, patience, and knowhow to appeal is optimistic. Whatever path we take, we should commit to basic rolling metrics (hits, upheld/overturned, median time to resolution) and a scheduled community review.

Again, I recognize we may need a near-term fix. If the community prefers the current revocation model, I’d support it only as a time-boxed stopgap (with published metrics and a sunset/review), while we pursue the deterministic hold as the longer-term, more transparent solution. spintheer (talk) 19:42, 18 October 2025 (UTC)

• Support 1 & 2, conditional 3: 1 is unobjectionable groundwork and makes hierarchical sense. 2 has a potential for causing issues in the form of false positives, but my fears are alleviated by three factors: I trust that the edit filter team can construct filters with a low false positive rate, when fps occur the impact to an individual editor will be generally low, and when fps occur they will be entirely correctable with no side effects upon petition and review. 3 I will support in the same conditional manner as Tamzin. fifteen thousand two hundred twenty four (talk) 06:33, 5 October 2025 (UTC)
• Support per nom, this seems reasonable. Dr vulpes (Talk) 02:35, 8 October 2025 (UTC)
• Support All Three We need to limit disruption and this should do a good job in doing tackling the issue and the edit filter managers points above allayed any concerns I had on false positives. GothicGolem29 (talk) 23:54, 12 October 2025 (UTC)
• Support. Just to be clear, I support all three points as the proposer. Daniel Quinlan (talk) 01:05, 29 October 2025 (UTC)

Discussion (extended confirmed grants)

• Are we sure that third bullet point is necessary? Is the match rate really so high it'd hit a throttle based on a percentage of all recent edits? -- Tamzin^{[cetacean needed]} (they|xe|🤷) 21:58, 22 September 2025 (UTC)

  Yes, 100%. I'll send you some details via email. Daniel Quinlan (talk) 22:17, 22 September 2025 (UTC)

• "We allow several high accuracy edit filters to revoke autoconfirmed." – This is the most vague part of the proposal, as a general idea what would such edit filters look like? fifteen thousand two hundred twenty four (talk) 08:25, 23 September 2025 (UTC)

  I'm years behind current edit filters but they would be standard filters that detect certain patterns of edits or behavior, and which have the ability to remove the autoconfirmed status of the editor as a response. The comment about accuracy would mean that manual checking of what the filter decided has shown that the filter is very accurate. Johnuniq (talk) 09:33, 23 September 2025 (UTC)

  Wouldn't it make more sense to have the filters trigger a notification which admins could then decide whether or not to act on? While I think there is a principled argument for tightening scrutiny of the EC confirmation process, I'm more than a little concerned about the degree of automation involved here, and the fact that respondents are being asked to provide blanket endorsement of the filters involved without the specifics of those filters being worked out for vetting in advance of authorizing the proposal. It seems to me that there is substantial possibility of false positives or just far too onerous a standard for qualification of EC status in a manner that could have broad implications for new user involvement and retention. Shouldn't we at least make sure that an actual human signs off on each denial of EC status to an account that otherwise meets the agreed community metrics for the granting of said status? Maybe I am just lacking the technical background on these filters and missing something obvious as a consequence, but taken as a whole, with the ambguities in the current version of the proposal, this feels a little calvalier. SnowRise ^{let's rap} 21:43, 23 September 2025 (UTC)

  That's how the filters work now (with scant few false positives), and then we have to full protect major articles for days at a time. The issue is that they're gaming EC before anyone has a chance to review the filter reports. ScottishFinnishRadish (talk) 21:47, 23 September 2025 (UTC)

  So no amendments to the filters themselves are immediately contemplated? We're just talking about changing the process so that technical revocation happens before admin review, rather than the other way around? SnowRise ^{let's rap} 21:54, 23 September 2025 (UTC)

  The filters are constantly being adjusted, tuned, and created. It's insufficient. ScottishFinnishRadish (talk) 22:20, 23 September 2025 (UTC)

  You don't have concerns that asking for the admin approval of withholding a user right (the usual criteria for which is defined by substantial community consensus) to be moved to the end of the process (or possibly obviated altogether, if admins/functionaries just stop keeping up with the log), creates a situation where there is a complete deficit of oversight here? This would mean that a small number of editors maintaining the filters would be able to put a very heavy thumb on the scale of who gets extended confirmed status. This in turn would put them in a position of substantially restricting the access of the new users to significant portions of the encyclopedia, since ECP has vastly expanded in scope of application under ArbCom rulings and other developments on the project over the last couple of years.

  If we are not going to couple this proposal with some sort of more robust vetting of the development of the filters, this strikes me as too much idiosyncratic decision making vested in too few hands (that are not expressly authorized by the community to make these kind of broad decisions about what looks like suspicious/gaming behaviour). At a minimum, I think we need to discuss what happens if no admin reviews the filter log on an automated withholding of the user group membership, after x amount of time. I also think we need way more public discussion of what the current filters look like and what 'scant few false positives' look like, and how we can even be confident of such an appraisal with limited insight into whether a given user's actions were good or bad faith, other than begging the question on the assumption that they were attempting to game the system.

  Understand that I have seen a lot of the type of abuse that this proposal is attempting to address, so I appreciate both the motivation and the need, and I'd like to support on that basis. But we have, between community discussions and decisions implemented unilaterally by ArbCom, already greatly restricted access to huge swaths of the project, including essentially the entirety of CTOP areas. This is yet another heavy step in the direction of locking down the project increasingly as the sole purview of veteran editors, with huge consequences to diversity of view points, editor recruitment, editor retention, and the workload deficit. I'm a little concerned about how light all of the details are for this proposal, considering the breadth of likely implications for all of those practical concerns. SnowRise ^{let's rap} 23:03, 23 September 2025 (UTC)

  We wouldn't enable the blockautopromote action except for filters verified to be exceptionally accurate. The goal of this proposal is to make Wikipedia more welcoming and open, not less so. Right now, it's possible to game ECP and disrupt a high-profile article to the point where nobody can improve it. It's possible to game ECP so that you can keep harassing someone indefinitely on their talk page. And our only recourse is to cut even more editors off from editing those pages. And those issues have gotten much worse in the last year.

  Some people are already clamoring for an even higher level of protection than ECP, and I don't blame them because of how bad these issues are, but I think a better approach is to take aim at the small number of bad actors who are gaming ECP to be disruptive and abusive. These filters will only take action on accounts which are extreme outliers compared to typical new editors and not on ordinary contributions. When accounts trigger these rules, they are already posted to AIV for review, false positives can be reported to WP:EFFPR, users will also be able to appeal any revocation at a noticeboard, and administrators, edit filter managers, and edit filter helpers all regularly review filters and filter hits. All of these mechanisms have been in place for years to make sure filters are working properly and are being used properly, and I believe these mechanisms will continue to be effective. Daniel Quinlan (talk) 23:47, 23 September 2025 (UTC)

  I don't disagree that what you describe is a reasonable strategy for trying to serve the twin aims of short-circuiting disruption while simultaneously preserving access to as many editors as possible--at least in the broad strokes. But I'm still none the wiser on the specifics that I for one would say are crucial to making sure that the cure doesn't become more problematic than the disease. What are the criteria by which these filters assess contributors as bad actors, based on 'extreme outlier' metrics? Where should I be looking to understand the present analytics by which these filters operate? Or better yet, can you summarize the behaviours which would typically trigger the filters? I can't imagine I'm the only respondent who would have these reservations and is not a complete technical dope, but would nevertheless benefit from a more detailed explanation of the current criteria / rules by which the filters parse the data.

  Again, believe me, I see the need. And if the responses so far are any indication, you won't need my !vote for a consensus here. But personally, I can't rubber stamp this with my support without a more thorough understanding of under what conditions the user rights would be denied. You have spoken about protections on the back end, but let's bear in mind that when we are considering unintended negative consequences here, we are specifically talking about the community members who will have the lowest level of understanding of how to challenge an error. SnowRise ^{let's rap} 01:22, 24 September 2025 (UTC)

  @Snow Rise, currently we are dealing with a particular vandal who makes 500 edits in mere moments, 30 days after account creation, by adding numerals to their sandbox. They move so fast that in the time it takes a human admin to look at their edits, they've already reached extended confirmed. When I was unfamiliar with this particular vandal and someone reported an ongoing run-up to me, they got from 100ish edits to 400ish edits in the time it took me to check my Discord messages and open the "editor's" contributions history to show 500 edits. I assure you that this behaviour is not even remotely like any human editor who could plausibly be operating in good faith. -- asilvering (talk) 18:44, 25 September 2025 (UTC)

  That's great, and if the filters are substantially engineered towards sending up a flag in only those kinds of situations, that's the kind of detail which could reassure me that the system is well-calibrated towards catching obvious bad actors with minimal false positives. The problem is, no one who has the requisite familiarity with the technical implementation of the filters at present has yet spoken up in this discussion to give even a basic description of how they operate. And until they do, I for one do not feel comfortable supporting the proposal. And if they do, it may be enough to shift my !vote, but it won't exactly dissipate my concerns altogether, since there is no oversight function (that I am aware of, anyway) for reviewing changes to those filters by the general community. Meaning once we authorize full automation of the withholding of EC status, the rules by which that automation is conducted could be radically changed to not be consistent with the status quo we had in mind when we permitted that change. SnowRise ^{let's rap} 19:14, 25 September 2025 (UTC)

  The LTA that asilvering is referring to is Salebot1 (WP:LTA/SB1), in case you didn't already know. SuperPianoMan9167 (talk) 21:11, 25 September 2025 (UTC)

• Question EC happens after 500 edits plus 30 days. How are editors getting EC not already autoconfirmed? I think I missed something. RudolfRed (talk) 00:24, 24 September 2025 (UTC)

  Currently, EC is granted solely based on edit count and account age. It doesn't matter whether the account is autoconfirmed. If we add autoconfirmed as a requirement for EC being granted, it would mean that we could automatically revoke AC from accounts in the process of gaming EC via rapid edits, and keep those accounts from gaining EC until they can be reviewed by an administrator. For good faith users, it will have no effect because they will still have autoconfirmed when they reach the standard EC requirements. Daniel Quinlan (talk) 00:51, 24 September 2025 (UTC)

  Thanks for clarifying it for me. RudolfRed (talk) 01:50, 24 September 2025 (UTC)

  @RudolfRed: Also, admins are able to grant various rights to users, even to newly-registered accts with no edits yet. There are about sixteen of these, and they include: confirmed user; extended confirmed user; template editor. --Redrose64 🌹 (talk) 20:24, 24 September 2025 (UTC)

• Question: What kind of edits do users typically make when they're gaming the system? If they are mostly userspace edits, would it be helpful to change the requirements for the EC user right to a minimum number of mainspace edits? If they are mainspace edits, are they constructive? Are the filters just catching them because they are made quickly, or are the edits vandalism or something repetitive like adding an extra space where it's not needed? I can envision a scenario in which someone who is really determined to vandalize a high-profile page could get around these proposed changes by, for example, making a small number of inconsequential grammar changes per day until they reach 500 edits. I think the only foolproof way to prevent this from happening would be to create a new protection level above ECP that requires users to have an administrator-granted permission (e.g. rollback, or create a new one for this purpose) to edit the highest-risk pages. I₂Overcome ^talk 06:13, 24 September 2025 (UTC)

  Sometimes they edit main space articles with more innocent-looking contributions, and other changes are to sandboxes. I haven't seen user page edits as often prior to being granted auto-confirmed rights or extended confirmation. SNUGGUMS (talk / edits) 12:29, 24 September 2025 (UTC)

  Trolls can and do choose to attack any kind of page, not just high profile ones. Edit filters can detect many of the persistent trolls but they cannot currently stop a troll from gaming their way to EC. This proposal is for some simple changes which could be implemented quickly. The result would that edit filters could stop a new editor from reaching EC. People who maintain those filters will check what they do and ensure that false positives are rare. The penalty of a false positive would be that someone reaches 500/30 but is not extended confirmed—they can still keep editing and become EC after a manual review. Other plans (such as altering the way EC works) could take over a year to implement and would have zero flexibility. Johnuniq (talk) 01:45, 25 September 2025 (UTC)

• I want to say that continuing to rely on humans to play King Canute against this incoming tide is not a viable option, and that doing this is not going to resolve the problem. It will suppress some of the ECP gaming but a significant chunk of it will just be displaced or delayed. At some point, we will have to give up and make EC a right to be granted or revoked by humans.—S Marshall T/C 07:28, 25 September 2025 (UTC)

  So sort of like encyclopedia Brittanica, except without the free market incentive structure to produce a superior product. That's a concerning combination. spintheer (talk) 13:25, 15 October 2025 (UTC)

• Slightly tangential, but it may be worthwhile to assess potential collateral if the max permissible non-XC rate were reduced to the max permissible non-AC rate, assuming something to that effect has not already been done. 184.152.65.118 (talk) 00:52, 23 September 2025 (UTC)
• Honestly, whatever makes admin's work easier based on tweaking configurations sounds good to me, even if technicals go slightly over my head at the same time (hence I'll refrain from survey for not being clued up enough). Overall I'm much more interested in filling the protection level gap between ECP and Full Protection, or even understanding why there is such an enormous gap in the first place, but that's a completely different another topic. CNC (talk) 21:42, 26 September 2025 (UTC)

  I always felt that ECP should have a higher threshold to move it more midway between semi and full. ~Anachronist (who / me) (talk) 23:16, 26 September 2025 (UTC)

While we're waiting for a close, I wanted to add a few technical notes:

1. It's worth clarifying that blockautopromote doesn't technically "revoke" permissions in the way people are used to thinking about permissions. As background, it helps to understand that autopromotion doesn't actually add users to a group. MediaWiki dynamically checks whether a user meets the conditions for autopromotion when it's checking a user's rights or groups. The blockautopromote action prevents those conditions from being met for a temporary period of time (five days). The rights are effectively revoked during that period, but once the period ends, autopromotion works normally and the "revoked" rights are restored to the user. The confirmed permission can also be granted manually during that period. Additionally, as mentioned above, edit filter managers have an interface to undo blockautopromote mistakes.
2. With some help from other editors, I did some testing on test.wikipedia.org and verified that blockautopromote works as expected and that with the current site configuration, it unfortunately won't prevent extendedconfirmed from being granted (which is the reason for point 1 of the RFC).
3. Also relevant to point 2 of the RFC, enabling blockautopromote for one or two filters as proposed here will have another immediate effect (i.e., without any additional configuration changes): it will lower the edit rate throttle for the five day period from the user edit rate limit to the newbie edit rate limit. Based on the current settings, that would shift the rate limit from 90 edits per 60 seconds to 8 edits per 60 seconds.
4. While I believe there's consensus for point 3 without any conditions (and even stronger consensus for points 1 and 2), we will assess whether it's technically necessary once we begin implementation. If it doesn't prove necessary for a solid implementation, there's no reason to move forward with that change.

I've done my best to explain a few additional technical details in a straightforward way, but the code is complex and corrections are welcome! Daniel Quinlan (talk) 01:15, 29 October 2025 (UTC)

When blocking autopromotion happens, it shows MediaWiki:Abusefilter-autopromote-blocked, not MediaWiki:Abusefilter-degrouped (Remove from groups). Codename Noreste (discuss • contribs) 03:00, 29 October 2025 (UTC)

Not sure how I made that mistake, but thanks! That error message is definitely more appropriate already too. I'm not sure it even needs to be changed, but I'd be open to softening it a bit. Daniel Quinlan (talk) 04:06, 29 October 2025 (UTC)

@Daniel Quinlan: I'm curious, what exactly is the configuration change for point 1? At a quick glance I'm not seeing anything that would allow for requiring membership in an autopromoted group. APCOND_INGROUPS calls getUserGroups(), not getEffectiveUserGroups(), so it can't check for an autopromoted group like autoconfirmed, and I don't see any other condition that seems relevant. Anomie⚔ 03:26, 29 October 2025 (UTC)

@Anomie: That was the next thing I was planning to test, but it sounds like a small code change will be needed to allow point 1 to work. Obviously, that means that even if point 1 of the RFC passes, it will not be something we can do soon, but it's still good to have an RFC to refer to in an enhancement request. Thanks for pointing this out. Point 2 will still be a significant improvement that doesn't require code changes because of the newbie rate limit. Daniel Quinlan (talk) 04:03, 29 October 2025 (UTC)

@Daniel Quinlan: Regarding the code change, I'd suggest requesting that AbuseFilter add a condition for "autopromote is blocked" rather than trying to request that APCOND_INGROUPS look at getEffectiveUserGroups(), as the latter seems likely to wind up in a loop where the code might have to know the autopromoted groups to evaluate whether autopromotion should happen. Or you could request that AbuseFilter's blockautopromote block wgAutopromoteOnce directly. Anomie⚔ 04:15, 29 October 2025 (UTC)

I was planning to define the problem first and mention possible solutions second, but that sounds reasonable. I hadn't considered your first alternative, but I was planning to mention the second alternative as an possible solution. Thanks again. Daniel Quinlan (talk) 04:26, 29 October 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion at Wikipedia:Village pump (proposals) § Should we adopt the new "protection padlock" feature?

 You are invited to join the discussion at Wikipedia:Village pump (proposals) § Should we adopt the new "protection padlock" feature?. Thryduulf (talk) 19:51, 11 November 2025 (UTC)

Lock icon does not show unless /doc is transcluded

This page says: A protected page is marked at its top right by a padlock icon, usually added by the {{pp-protected}} template. I recently stumbled across Template:AFL Col, which has 2,500 transclusions and was protected in 2024 by MusikBot. I noticed that it was not showing the lock icon. I added documentation to the template, but did not add {{pp-protected}} to the documentation, and the padlock icon appeared.

This automated appearance of the icon, and the lack of the icon when /doc is not transcluded, seems like a hidden feature to me. Is it documented somewhere? Should we explain that feature here, or link to an existing explanation? – Jonesey95 (talk) 21:51, 17 November 2025 (UTC)

Template:Doc#Automatic functions: "This template also automatically adds {{pp-template}} to a protected template page." —Cryptic 23:32, 17 November 2025 (UTC)

@Jonesey95: The documentation box has automatically added a prot icon (when appropriate) since February 2010. Unfortunately I can't point you to the exact edit where the feature was added, because it was done in a subtemplate which has since been deleted. But I can direct you to the edit to the metadocumentation, which was here. Search for pp-. --Redrose64 🌹 (talk) 21:53, 18 November 2025 (UTC)

Thanks for those links. I have added a short sentence to this page so that this feature is less of an Easter egg. – Jonesey95 (talk) 22:25, 18 November 2025 (UTC)

"Move Protection" listed at Redirects for discussion

The redirect Move Protection has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2025 December 8 § Move Protection until a consensus is reached. - BᴏᴅʜıHᴀᴙᴩ (talk, contributions) 19:37, 8 December 2025 (UTC)

Long-duration protections

There's a discussion started by Femke at Wikipedia:Village pump (idea lab) § Re-evaluate long-duration protections that may be interesting to anyone watching this page. Regards. Daniel Quinlan (talk) 22:48, 23 January 2026 (UTC)

i have an unpopular opinion id like to share

i think extended confirmed should be lowered to 300 edits

i really think 500 is too much

you would have to be on wikipedia for years to do such a thing Metro8102 (talk) 11:56, 28 January 2026 (UTC)

not really. you only need to be around for 30 days for that criterion. the edit criterion is pretty easy to reach. you can get, say, 30 or so edits done per day, be it via plain ol' copyediting, adding stuff to articles, or using gadgets to maintain stuff

this is to say, it's one of those cases in which you just need to get the hang of stuff, at which point you'll be there before you know it

consarn _{(talck) (contirbuton s)} 12:04, 28 January 2026 (UTC)

if you do it too quickly they will call it "gaming" and revoke your access to ecp pages Metro8102 (talk) 12:07, 28 January 2026 (UTC)

what do you do if you find a typo or dead link on such page? without asking someone else to do it on your behalf? Metro8102 (talk) 12:08, 28 January 2026 (UTC)

If you find a typo or dead link on an ECP page, you'll need to request someone make the edit for you. Primefac (talk) 00:14, 29 January 2026 (UTC)

if you do it too disruptively, they'll call it "gaming". for example, creating multiple blatantly implausible redirects (for example, "honagongalogongas" for breast), repeating the same edit (bonus points if you revert yourself over and over), writing an essay in userspace one character at a time, etc. standard edits are fair game

consarn _{(talck) (contirbuton s)} 12:11, 28 January 2026 (UTC)

If you really want to, you are welcome to revert this edit, but I trimmed it down for reasons. No point in printing the playbook. Primefac (talk) 00:16, 29 January 2026 (UTC)

regardless of whether or not that would actually apply (i'm veering on no, since it would first require that metro be a blatant, proud, and easily impressionable vandal), editing others' comments is an even worse idea here. it can be justified if it's to handle personal attacks or fix jank, but this isn't really either of those. that is to say, yes, i've reverted it on both procedural and non-procedural grounds

consarn _{(talck) (contirbuton s)} 00:23, 29 January 2026 (UTC)

require that metro be a... vandal... or, you know, anyone reading this thread, but it's not a hill I feel like dying on. I'm sure those wanting to game ECP already have plenty of ideas of how to do it, but I also don't really want to make it easy for them. Primefac (talk) 00:25, 29 January 2026 (UTC)

if it helps, i may have actually done a fucky wucky here in referring to one of the methods. that said, whether or not it actually is a bad idea to suggest it is apparently a topic of inconclusive debate (barely anyone seems to bother considering it), and most cases i've seen of people engaging in it and still getting blocked for disruption are over issues that aren't actually deliberate vandalism per se (cir, incivility, copyvios, etc.), so even if it's not besides the point of ec criteria being relatively easy to achieve, it's probably not going to attract a lot of vandal eyes anyway, so it's best not to name or try to draw more attention to it consarn _{(talck) (contirbuton s)} 01:53, 29 January 2026 (UTC)

You could also do WP:Recent changes patrolling. Some1 (talk) 03:00, 31 January 2026 (UTC)

I oppose the idea of 300 edits as that threshold would be too lenient, and if anything, I recommend increasing it from 500 to at least 1,000 edits to reduce risks of disruption. SNUGGUMS (talk / edits) 22:40, 6 February 2026 (UTC)

UNPROTPOL's "will normally be declined"

A few weeks ago I made an edit (Special:Diff/1334471711) that changed Note that such requests will normally be declined if the protecting administrator is active and was not consulted first. to Note that such requests may be declined if the protecting administrator is active and was not consulted first. ("such requests" referring to requests for unprotection). This was reverted by @Daniel Quinlan on the grounds that this is a change to policy and should be discussed. Here is that discussion.

This policy is attempting to describe common practice at RfPP, and failing miserably. Searching the RfPP archives of January and February 2026 for "Unprotected:" shows that not a single unprotection request was declined because the protecting admin had not been consulted, which the current wording portrays as the "normal" result. Many requests were granted despite no consultation taking place (perhaps even most requests – I didn't keep count). In some cases the protecting admin was pinged to offer an opinion, but ultimately the failure to consult them never seemed to affect the outcome of the request.

Policy should also follow common sense and WP:NOTBURO. The change I made still allows admins to decline solely for a failure to consult the protecting admin, but does not state the frequency of that decision. A failure to exactly follow the recommended procedure should not stand in the way of fulfilling reasonable requests. Toadspike [Talk] 19:28, 19 February 2026 (UTC)

I don't think the history shows what you're saying. In the vast majority of cases (46 out of 48 44 out of 46 (updated 11:41, 20 February 2026 (UTC)) requests in the sample I analyzed, see below), the protecting admin was no longer active, the (active) protecting administrator was pinged and responds, or the request is quickly declined making a ping superfluous. More importantly, the archives don't show the requests that never reach RFPP because the user followed the process and made a request to the protecting administrator.

The two cases in this sample where an unprotection was done without consulting an active protecting sysop were both pages that were unnecessarily fully protected over 15 years ago.

Finally, will normally be declined is not trying to describe the RFPP outcome in a vacuum. It sets an expectation: if you bypass an active protecting sysop, you should not expect success. That shapes behavior upstream and it's a fairly accurate prediction of the outcome. It also helps reduce the load on RFPP by allowing administrators with more context to quickly decline or accept requests on their user talk pages.

And it helps discourage administrator shopping and dubious requests. Daniel Quinlan (talk) 22:37, 19 February 2026 (UTC)

January 2026 requests

Article	Outcome	Protecting sysop status	Notes
Iron Man 2	Declined	Active	Declined outright
Love the Way You Lie (song)	Unprotected	No longer sysop
Garrulax milnei	Unprotected	Active	Fully protected redirect?
I Kissed a Girl (Katy Perry song)	Declined	Active	Edit made by sysop
Ronen Segev	Declined	N/A	Office action
Ronnie Segev	Declined	N/A	Office action
Template:Infobox ballet company	Unprotected	Active, but pinged	Unprotected by protecting sysop
Template:Infobox law school	Reduced	No longer sysop
Lamar Odom	Reduced	No longer sysop
Enes Kanter	Declined	Active	Declined outright
Template:Glottolog	Declined	Active, but pinged	Declined by protecting sysop
Ray William Johnson	Reduced	No longer sysop
Fuel Freedom International	Unprotected	No longer sysop
Staples High School	Unprotected	N/A	Failed previous unprotection
List of Canadian Hot 100 number-one singles of 2011	Unprotected	No longer sysop
Triple J Hottest 100, 2000	Unprotected	Active, but pinged	Okayed by protecting sysop
User:Mcjakeqcool	Unprotected	Active	Fully protected user page?
User:TheRescuers	Unprotected	No longer sysop
Anti-pedophile activism	Declined	Active	Declined outright
App Store (Apple)	Declined	Active	Declined outright
Atlanta	Declined	Active	Declined outright
Bob the Builder	Declined	Active	Declined outright
Caracalla	Declined	No longer sysop	Declined outright
Charli XCX	Declined	Active	Declined outright
Chitral	Declined	Active	Declined outright
Daniel Andrews	Declined	Active	Declined outright
East Spring Primary School	Unprotected	No longer sysop
Europe of Sovereign Nations Group	Declined	Active	Declined outright
Gagan Thapa	Declined	Active	Declined outright
Jordan Love	Declined	Active	Declined outright
Julia Domna	Declined	No longer sysop	Declined outright
Lady Gaga	Unprotected	Active, but pinged	Protecting sysop pinged and unprotected
Livonia, Michigan	Declined	Active	Declined for not contacting protecting administrator
Amanda Jiroux	Unprotected	No longer sysop
Matt Kalinski	Declined	No longer sysop	Declined outright
Opinion polling for the next United Kingdom general election	Declined	Active	Declined outright
Pete Hegseth	Declined	Active	Declined outright
Noodle	Declined	Active	Declined outright
Reindeer	Reduced	Ex-sysop, but pinged
Rihanna	Declined	No longer sysop	Declined outright
Killing of Renee Good	Declined	Active	Declined outright
Super Aids	Declined	Active	Declined outright
Talk:Killing of Renee Good	Declined	Active	Declined outright
Teacher's Pet (2004 film)	Declined	No longer sysop	Declined outright
The Guardian	Declined	Active	Declined outright (removed by sysop)
United States dollar	Declined	Active	Declined outright
Vairankode Vela	Declined	Active	Declined outright
Valy Hedjasi	Reduced	No longer sysop

Daniel Quinlan (talk) 22:25, 19 February 2026 (UTC)

The status of the protecting admin is not "N/A" simply because the request was declined (and goodness that yellow is hard to see). All of those requests were declined for a good reason that had nothing to do with whether the protecting admin was consulted. This is good – it shows that requests are being considered on their merits regardless of whether consultation took place, a perfect application of WP:NOTBURO. Toadspike [Talk] 10:03, 20 February 2026 (UTC)

Sorry about that, I replaced the yellow and filled out the column. I also removed a few requests where the page wasn't protected.

Most of the time when an active protecting administrator isn't asked first, there's a decline for a multitude of reasons: it's more efficient to just decline a dubious request, reasonable requests are generally routed through user talk pages as per the policy, etc. Anyhow, for the 29 cases where the protecting administrator was still an active sysop:

• 23 were declined
• 3 had the protecting administrator pinged, and were unprotected
• 2 were unprotected
• 1 had the protecting administrator pinged, and was declined

That's about 83% being declined, which seems consistent with will normally be declined. The policy doesn't require a specific procedure for declining requests, it just informs users about the likely result. If there's a more straightforward reason to cite, administrators are free to use it. This part of the policy isn't bureaucratic. It's meant to encourage contacting the protecting administrator first because it's more efficient, prevents admin shopping, helps avoid conflicting administrator decisions without discussion, and reduces RFPP workload. Daniel Quinlan (talk) 11:41, 20 February 2026 (UTC)

Regardless of whether a protecting admin is active or still has admin rights, it baffles me how anybody at all willingly reduces indefinite semi-protection or ECP; doing that is asking for trouble to resume. To be blunt, such reductions are never a risk worth taking when such trouble is what led to such protections in the first place. Don't be surprised when pages that go through "trials" of pending changes or being completely unprotected quickly see upticks in bad edits. In my opinion, it would be best to only allow reduction requests from full-protection emerging from content disputes, and semi-protection or ECP can be resumed if they were already indefinite beforehand. SNUGGUMS (talk / edits) 22:44, 20 February 2026 (UTC)

Some protections outlive the reason for their protection. As the blocking policy says, Indefinite does not mean "infinite" or "permanent"; it just means that no automatic expiration time (or duration) for the block has been set. The same should be true for protections. Daniel Quinlan (talk) 23:20, 20 February 2026 (UTC)

Not sure how comparable the blocking policy is, but I've never seen anything good come from reducing indefinite semi-protection or ECP. Lifting those comes off as reckless. When somebody decides to temporarily lift those as a trial, it becomes a magnet for disruption (sometimes including vandalism) to return, and there unsurprisingly have been many cases of such trials being short-lived due to lots of bad edits being made before protection gets restored. We could've avoided lots of needless trouble for articles by never reducing these protections once they're made indefinite. SNUGGUMS (talk / edits) 03:31, 21 February 2026 (UTC)

References

There existed a protection level called CheckUser protection?

Was looking at the edit history for PeterSymond's user page and saw a protection level I never saw before: require CheckUser access. (see Special:PermaLink/320405065) Thoughts? - SimpleObjects-9ei (talk) 00:01, 3 March 2026 (UTC)

That wasn't a protection; it was an ordinary edit adding an empty line with a deceptive edit summary. Diff, Logs for that page, surrounding protection log entries. —Cryptic 00:59, 3 March 2026 (UTC)

I am likely sure about that, as before somewhere in the late 2000s protecting a page would show this text inside the edit summary:

[edit=<protection level, autoconfirmed or sysop>] [move=<protection level, autoconfirmed or sysop>]

However, somewhere in the early 2010s, it was changed to include this:

[edit=<protection level, autoconfirmed or sysop>] (<duration>) [move=<protection level, autoconfirmed or sysop>] (<duration>)

And as of today, this is what it looks like:

[Edit=<protection level; Require autoconfirmed or confirmed access, Require extended confirmed access, Require template editor access, or Require administrator access>] (<duration>) [Move=<protection level; Require autoconfirmed or confirmed access, Require extended confirmed access, Require template editor access, or Require administrator access>] (<duration>)

This is weird because at the time this page was protected, CheckUser protection wasn't mentioned in the protection policy page. I have actually burrowed through protection history before, but I wasn't expecting to see a protection level this weird. The reason of protection was reasonable (likely Grawp vandalism, but this was after the Willy on Wheels vandalism trend ended), but when protecting a page, you have to specify why you protected it. Example:

...23,456 bytes) . . Protected "Example": Your reason of protection. ([Edit=Require autoconfirmed or c...

Oh, and can't we forget the fact that this was before Twinkle became popular? PeterSymonds didn't use Twinkle to protect the page, and the [edit=autoconfirmed/sysop] summary is true (see the page information for Haggar Clothing, whose protection summary is the 2009-style one and is still labeled "Require administrator access (no expiry set)") Yet most admins use Twinkle to protect pages nowadays.

Also, to show I'm not cuckoo crazy, check the protection log for this page. See? It is protec- oh no. So maybe I was actually lying and CheckUser protection was just a nightmare I had in my head. However, I still hope you learned a valuable lesson. - SimpleObjects-9ei (talk) 01:48, 3 March 2026 (UTC)

A lesson for whom? When somebody makes an edit that alters the page text in any way - such as by adding a newline - the edit summary is free-form, it allows absolutely any text to be entered. Even something that looks like the contents of a log entry. You could use an edit summary like protected [[Wikipedia talk:Protection policy]] [Edit=Require SimpleObjects-9ei access] (expires 08:52, 3 June 2026) and it would be accepted by the MediaWiki software. But the page protection wouldn't be altered one bit. --Redrose64 🌹 (talk) 08:52, 3 March 2026 (UTC)

I don't think that a post-201X protection summary like:

...protected "Wikipedia talk:Protection policy": [Edit=Require SimpleObjects-9ei access] (expires 08:52, 3 June 2026) [M...

may as well be considered that. There are currently 5 levels of protection: pending changes protection (for uncommonly vandalized pages), semi-protection (the most common one; for vandalized pages by unregistered and new accounts), extended confirmed protection (for contentious topics and vandalized pages by (auto)confirmed accounts), template editor protection (for high-risk templates) and full protection (for edit warring/content disputes and vandalized pages from extended confirmed accounts).

You can as well put SimpleObjects-9ei protection level like if it was invented from nowhere, then log in to a temporary account (IP address prior to 4 November 2025) to see that the "Edit" button is not the "View source" button. This may be considered some sort of joke thing, however Wikipedia does not allow empty changes. The only way you can make the "(No difference)" message appear when switching revisions is by moving a page or protecting a page, not by typing an edit summary, editing nothing and pressing Publish changes.

So technically you can still edit pages even if the fake protection summary literally says "Require oversighter access". I was not around in 2009 so I couldn't check if the CheckUser protection evidence was true. - SimpleObjects-9ei (talk) 19:33, 3 March 2026 (UTC)

Please note that (a) the diff in question shows a newline being added - something that cannot happen when a loggable action occurs; and (b) I wrote an edit that alters the page text in any way - such as by adding a newline. It was, quite simply, a user-entered edit summary that was written to have the appearance of a log entry. Exactly like this. --Redrose64 🌹 (talk) 22:43, 3 March 2026 (UTC)

Ooh... So you mean a protection example like this? Okay, now I get it. However, the edit has a zero-byte difference, and it is truly impossible to get a zero-byte difference, huh? Because when admins protect the page using Twinkle, there is a literal zero-byte difference. Even still, before Twinkle existed, when protecting a page also a zero-byte difference because clearly the protection button is from the Tools dropdown button. Another cool example of a zero-byte difference is this, despite the fact the edit summary is suppressed. - SimpleObjects-9ei (talk) 23:15, 3 March 2026 (UTC)

However, the edit has a zero-byte difference - it's not a zero-byte difference, the [https://en.wikipedia.org/w/index.php?title=Wikipedia:Sandbox&action=history page history shows "(+1)". --Redrose64 🌹 (talk) 23:21, 3 March 2026 (UTC)

Zero byte edits used to be possible (I won't tell you how). I think it changed in the last few years. These types of edit summaries have been used a number of times for comedic effect. -- zzuuzz ^(talk) 23:32, 3 March 2026 (UTC)

BTW I think one of the earliest examples was this. Also that second example you provide was the result of a page move, per the log. -- zzuuzz ^(talk) 00:13, 4 March 2026 (UTC)

My goodness, I would have never known that since I am not extended confirmed and didn't sign the Wikimedia Foundation's confidentiality agreement for nonpublic information, which means I'm not an oversighter, but may want to be like one soon. Now, the second example I gave was several vandalism by BestToWaitSomeMore, which I didn't know was a page move since all log details have been suppressed.

Either thing or thing, it appears that the example you gave was an actual page move: despite the fact, this page was actually moved for real. I have actually burrowed through pagemove history before, such as (and please don't cancel me for saying it) massive use of a word during 2008, and in spaces because that's what the edit said: H A G G E R ?, Example on WHEELS!!! and a user trying to get extended confirmed rights by repeatedly typing 1 in their user talk page, and all to move the page Charlie Kirk.

Because this message is related to the CheckUser protection mystery, I have to not keep it off-topic. So maybe, the CheckUser evidence might be true. We will have to go back to 2009 if we want to see how CheckUser protection felt like. - SimpleObjects-9ei (talk) 01:09, 4 March 2026 (UTC)

User-right logs are not always on-wiki. The editor apparently was a CU in the past. . And I don't know if it is still the case, but my recollection is that there were indeed other types of protections. - jc37 13:16, 3 March 2026 (UTC)

As someone who has been active since there was only one protection level, I feel confident in saying that bureaucrat, checkuser, oversight, and steward protection levels have never existed. The closest you'll find was superprotect, which is mentioned overleaf. -- zzuuzz ^(talk) 01:19, 4 March 2026 (UTC)

I have to correct you for a moment, but steward isn't a user level in the English Wikipedia. Only Meta-Wiki has this feature. SimpleObjects-9ei (talk) 01:26, 4 March 2026 (UTC)

Enwiki stewards have existed (m:Special:Redirect/logid/18030), but I accept it's another example of things that don't exist. -- zzuuzz ^(talk) 01:37, 4 March 2026 (UTC)

explain ECP

I think we ought to add a sentence to WP:ECP explaining the idea behind this, ie. that someone gains experience and proficiency in editing, which should discourage gaming. Idk which wording would be best though, and idk whether adding it to WP:XC would be better, depends which is linked to when a newbie tries to edit an ECPed page Kowal2701 (talk, contribs) 12:49, 12 March 2026 (UTC)

I don't think adding a sentence to state the obvious to either of those policies is going to discourage gaming. If there's any place to add a sentence, Template:Protected page text is more likely to be seen. Adding something along these lines might actually make gaming a more common response, though. Daniel Quinlan (talk) 02:07, 13 March 2026 (UTC)

Too strong

The recent edit is a bit strong IMHO. First, the word "allowed" is not really suitable when talking about something which ultimately boils down to judgement. Editors are not allowed to abuse each other but a page should not be protected unless certain conditions apply. A minor point is that "be set to" is extraneous—the original wording was fine and less is more. The wording is tipping towards prohibiting protection unless a major attack is under way. That is not how things work at WP:RFPP where minor articles are routinely (and correctly) protected when only a small amount of disruption occurs, provided it is repeated. Good editors have to be supported and telling them to suck it up is not a good outcome. Protection is often needed simply to break some bored person's habit. Johnuniq (talk) 02:09, 5 March 2026 (UTC)

Agreed. It's effectively a policy change, but it's not well-formulated and it's unnecessarily wordy. Leading with not allowed is the least of the problems because the policy said that before. Worse is either currently in progress or currently ongoing and is occurring at a rate or frequency where page protection is clearly warranted. The currently in particular doesn't reflect how page protections are done or how durations are chosen. The previous text was better in every respect. Daniel Quinlan (talk) 17:04, 6 March 2026 (UTC)

Johnuniq, Daniel Quinlan - Thanks for discussing this, and I appreciate the input and the feedback! :-) In hindsight and after looking at it again, I completely understand your thoughts regarding the wording changes. The changes weren't meant at all to be any kind of "policy change" or anything that would restrict our ability to use judgment in order to gauge whether or not protection would be appropriate given... shenanigans. :-) My intent was to articulate how we make the determination as to whether or not to protect a page, and in a way that better describe the overall process? ...If that makes sense? An example being, either currently in progress or currently ongoing and is occurring at a rate or frequency where page protection is clearly warranted. The intent was to convey, "disruption is happening, lots of disruptive edits in a small time frame", like we see all the time where a page is getting hammered with 20+ disruptive edits over the span of an hour. Anyways, like I said - I completely understand your thoughts and how you interpreted the changes, and I thank you both for sharing them. ~Oshwah~^{(talk) (contribs)} 22:18, 9 March 2026 (UTC)

Oshwah, the phrasing of is occuring at a frequency that warrants protection does seem to be a bit circular. Would something like is occurring at a frequency significantly above typical address your concern without sounding like a policy change? Daniel Quinlan (talk) 01:17, 10 March 2026 (UTC)

Daniel Quinlan - That phrase looks good to me! :-) ~Oshwah~^{(talk) (contribs)} 01:29, 10 March 2026 (UTC)

I probably thought about this change much longer than warranted, but I ended up using mitigate persistent to replace the circular occurring at a frequency that warrants protection. Compared to my last suggestion, it's a bit less wordy, more to the point, and it includes the goal of mitigation. Daniel Quinlan (talk) 01:53, 16 March 2026 (UTC)

Template editor protection usage on non-templates/modules

I was wondering whether template editor protection should be used on pages in the main namespace as an alternative to full protection (such as pages that are being vandalised by extended confirmed users) as template editors are trusted users and is not a user right that you can automatically be assigned. There are about 111 pages in non-template/module namespace that have this protection level and some articles have been in the past such as here. --Prothe1st (leave me a message)-- 14:36, 22 March 2026 (UTC)

I haven't looked at every page, but broadly speaking, the following are basically templates or are template-adjacent: AnomieBOT (directly TFD-related), Article Wizard/TEA stuff (basically a template series in WP space), DYK/TFA (same as the 'wiz), and I suspect the db-X template talks are because we really want to force people to discuss at the centralised talk page.

To answer the direct question, though, no, I do not think we should be template-protecting Articles (or their talk pages); the higher scrutiny for granting TPE is because those users are expected to be able to analyse a template change request and determine if the code is appropriate; they should not be evaluating the consensus of article content disputes. Primefac (talk) 19:19, 22 March 2026 (UTC)

The Template talk:Db-xxxxx pages are protected because, IIRC, newbies were either using them to contest a speedy of an unrelated page, or were playing "what happens if I press this button?". --Redrose64 🌹 (talk) 09:32, 23 March 2026 (UTC)