Wikipedia:Requests for comment/Extended confirmed definition

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 proposals
Wikipedia policies and guidelines

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.

Shall we change the extended confirmed user right from 500 edits + 30 days (current setting) to 500 edits + 90 days? WhatamIdoing (talk) 20:08, 25 May 2025 (UTC)[reply]

Description

Extended confirmed (WP:XC) is a user rights group that has been automatically given to editors with 500 edits and whose accounts are at least 30 days old since 2016. It is similar to autoconfirmed:

Comparison of Extended Confirmed and Autoconfirmed
User right	Requirements	Protection level	Applies to	Uses
Autoconfirmed	10 edits + 4 days	WP:SEMI ("silver lock")	~64800 pages (~18100 articles) ~435 abusefilters	Mainly used to prevent vandalism. Required to create or move articles in the mainspace.
Extended confirmed	500 edits + 30 days	WP:ECP ("blue lock")	~11400 pages (~7800 articles) ~55 abusefilters	Often used to prevent edit warring by newer editors. Important for the Wikipedia:Extended confirmed restriction (applies to articles about Arab–Israeli conflict and Armenia-Azerbaijan).
Proposal for extended confirmed	500 edits + 90 days	(same as it is now)	(same as it is now)	(same as it is now)

Numbers

More than a third of accounts that make 500+ edits in the first month (and thus achieve XC on Day 30) get blocked. These are often banned socks. This is almost three times as many blocks as the overall block level for XC accounts (which is about 13%).
Blocked XC accounts were four times as likely to reach XC early. Only 2.5% of non-blocked XC accounts reach XC at the end of the first month, but 10% of blocked XC accounts do.
Almost 10% of blocked XC accounts reached XC at the end of the first month. For non-blocked accounts, it took about 90 days for the first 10% of accounts to reach XC. The median XC account took about a year to reach that status.
There is a significant decline in the chance of ban-evasion blocks by 90 days.
Most currently active editors with XC have been editing for over a decade. (No one who currently has this user right should be affected by this proposal.)
We have used 90 days for autoconfirmed editors who are using a Tor network for many years.
Page impact derived from quarry:query/91606. Thank you Rampion! — xaosflux ^Talk 22:37, 25 May 2025 (UTC)[reply]

Thank you to Cryptic and Sean.hoyland for most of the numbers in this section.

Questions and discussion

Please ask questions! WhatamIdoing (talk) 20:08, 25 May 2025 (UTC)[reply]

No corresponding increase in edit count? – robertsky (talk) 20:27, 25 May 2025 (UTC)[reply]

Where is the WP:RFCBEFORE discussion? ~~ AirshipJungleman29 (talk) 20:32, 25 May 2025 (UTC)[reply]

Special:PermanentLink/1292215089#Statistics voorts (talk/contributions) 20:33, 25 May 2025 (UTC)[reply]

I saw that, and was wondering if I was missing something. That seems to be a discussion between two editors, with a third opining once. That cannot be appropriate pre-RfC discussion for a change of this magnitude? ~~ AirshipJungleman29 (talk) 20:37, 25 May 2025 (UTC)[reply]

Can we even do this? Not technically - that's just changing a 30 to a 90 in a config file - but can we accomplish anything here other than either A) petition arbcom to modify all its decisions that impose what's come to be called the extended confirmed restriction but actually predates the user group and is why the numbers are what they are; or B) leave all of arbcom's 500/30 rules intact but remove the ability to protect pages to that level? —Cryptic 20:40, 25 May 2025 (UTC)[reply]

By my reading of the rules, yes -- the 2021 amendment to ArbCom rules explicitly left the definition of "extended confirmed" to the community. * Pppery * _{it has begun...} 20:50, 25 May 2025 (UTC)[reply]

(edit conflict) In partial response to your first point, at Special:Permalink/1292217021#RFC on extended confirmed Daniel stated We [Arbcom] actually voted on this (with the same proposed 500 + 90) at Wikipedia:Arbitration/Requests/Case/Palestine-Israel articles 5/Proposed decision#Changes to extended confirmed, where the opposition was largely (but not exclusively) based around it not being our decision - but rather the community's at an RfC. so (assuming they are speaking for the Committee and not personally) if we [the community] can choose to change the definition of "extended confirmed" as proposed here and anything protected/restricted at that level by arbcom will change accordingly. What happens to restrictions explicitly phrased at 500 edits and 30 days is (or at least might be) a different matter I have not looked into. The simplest would likely be for ArbCom to change all such restrictions to 500/90 (or "extended confirmed") by motion. Of course the simplest solution is not always the most appropriate solution.

This is all independent of whether we should do this (I haven't formulated an opinion yet). 20:55, 25 May 2025 (UTC) Thryduulf (talk) 20:55, 25 May 2025 (UTC)[reply]

Was speaking for myself, not the Committee - was simply an observation of the recorded votes at that proposed decision. Daniel (talk) 23:35, 25 May 2025 (UTC)[reply]

Any guesses as to how likely it is that this would reduce sock problems for 60 days, then we'd be right back at the same levels? i.e. that the only effect of this is that sockmasters would have to let their EC socks age a bit longer before using them? Anomie ⚔ 21:37, 25 May 2025 (UTC)[reply]

Anomie makes a good point. Also, separately, is there a history of edit restriction changes for similar reasons? JuxtaposedJacob (talk) | :) | he/him | 23:52, 25 May 2025 (UTC)[reply]

Survey

Support. I think this strikes a good balance between not delaying too far (about 90% of non-blocked XC editors wouldn't see any practical difference) and making it a bit slower for bad actors to get XC status. I don't think it will help with the compromised accounts, but it should help with the more common sockpuppet account. WhatamIdoing (talk) 20:10, 25 May 2025 (UTC)[reply]
Oppose The sorts of people who are willing to make 500 edits and wait a month before performing their mischief will likely also be willing to wait the extra two months; the fact that they aren't doing so now cannot be extrapolated in the way you are attempting to. * Pppery * _{it has begun...} 20:32, 25 May 2025 (UTC)[reply]
Oppose per Pppery. Also, thirty days helps us catch the socks sooner. voorts (talk/contributions) 20:33, 25 May 2025 (UTC)[reply]
Good point--Having them wait at least 90 days would most likely make the IP data of the sockmaster stale. Some1 (talk) 20:42, 25 May 2025 (UTC)[reply]
I don't think that's true, unless you're assuming that they make 500 edits on day one, and then nothing until day 91, and use a different IP for the edits on day 91. WhatamIdoing (talk) 00:25, 26 May 2025 (UTC)[reply]
Oppose because the CheckUser data retention period is globally set to 90 days. JensonSL (SilverLocust) 20:45, 25 May 2025 (UTC)[reply]
Oppose because of the CheckUser problem, an issue which could have been easily identified if the RFCBEFORE had involved more than two (and a half) editors. ~~ AirshipJungleman29 (talk) 20:59, 25 May 2025 (UTC)[reply]
Oppose. Part of the rationale is There is a significant decline in the chance of ban-evasion blocks by 90 days. Well yeah, that's when CU data goes stale. Why that's a reason for putting XC at 90 days is a mystery to me. -- asilvering (talk) 21:16, 25 May 2025 (UTC)[reply]
Oppose I had much the same thoughts as Pppery. There will be an initial decline for 60 days after implementation and then the sock accounts will hit 90 days and nothing will have changed. After that point new 90 day sock accounts will come up as regularly as 30 day sock accounts do now. So the only effect will be that actual new editors have to wait longer to edit in contentious areas, something I doubt will help with editor retention. -- LCU ActivelyDisinterested «@» °∆t° 22:18, 25 May 2025 (UTC)[reply]
Oppose because of the checkuser data expiration problem. Otherwise a good idea, nicely documented. Someone might want to watch a list of freshly extended-confirmed accounts < 45 days old. —A. B. ^{(talk • contribs • global count)} 23:15, 25 May 2025 (UTC)[reply]
Support. Checkuser data expiry is already well known, and this RfC is just making it more well known for people who are actually trying to avoid it. I would, however prefer 60 days as a trial/test run, and see if that helps more. I agree with the concept here, but would prefer either CU data be kept for longer (this is probably a pipe dream) and/or a trial of a lower extension of timeframe first. -bɜ:ʳkənhɪmez | me | talk to me! 23:33, 25 May 2025 (UTC)[reply]
@Berchanhimez The CU data retention period is baked into the WMF Data Retention Guidelines. I believe changing that would require a WMF board resolution. To say that's unlikely to happen would be an understatement. RoySmith (talk) 00:35, 26 May 2025 (UTC)[reply]