Change #1293705 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/ConfirmEdit@master] Support a minimum edit count for skipcaptcha right

https://gerrit.wikimedia.org/r/1293705

Change #1293705 merged by jenkins-bot:

[mediawiki/extensions/ConfirmEdit@master] Support a minimum edit count for skipcaptcha right

https://gerrit.wikimedia.org/r/1293705

Change #1294243 had a related patch set uploaded (by STran; author: STran):

[operations/mediawiki-config@master] Set minimum edit count for skipcaptcha right to 10

https://gerrit.wikimedia.org/r/1294243

Change #1294243 merged by jenkins-bot:

[operations/mediawiki-config@master] Set minimum edit count for skipcaptcha right to 10

https://gerrit.wikimedia.org/r/1294243

Mentioned in SAL (#wikimedia-operations) [2026-05-28T09:40:47Z] <dreamyjazz@deploy1003> Started scap sync-world: Backport for [[gerrit:1294243|Set minimum edit count for skipcaptcha right to 10 (T426973)]], [[gerrit:1294937|CheckUserLookupUtils: Fix error introduced by strict types (T427480)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-28T09:42:32Z] <dreamyjazz@deploy1003> dreamyjazz, stran: Backport for [[gerrit:1294243|Set minimum edit count for skipcaptcha right to 10 (T426973)]], [[gerrit:1294937|CheckUserLookupUtils: Fix error introduced by strict types (T427480)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-05-28T09:48:24Z] <dreamyjazz@deploy1003> Finished scap sync-world: Backport for [[gerrit:1294243|Set minimum edit count for skipcaptcha right to 10 (T426973)]], [[gerrit:1294937|CheckUserLookupUtils: Fix error introduced by strict types (T427480)]] (duration: 07m 37s)

I'm inclined to agree with JJMC89. This makes little sense, both as a technical and a social matter.

Technical: Extensions shouldn't build ad-hoc exceptions to core's user rights system like that. It makes things more complicated, breaks Special:ListGroupRights, etc. for no clear value.

Social: This feels like it's inappropriately usurping a matter that should belong to the local wiki, especially with an instrument this blunt. It means individual wiki admins can't say that this user is trusted regardless of how many edits they made, that individual communities can't rely on their own definitions of autoconfirmed, etc. And it's unclear what actual problem this is meant to solve.

If you insist on doing this it probably deserves a tech news announcement.

Oppose. It is better to raise $wgAutoConfirmCount to 10 globally instead.

I oppose that even more strongly. Wikis should decide for themselves who should be autoconfirmed

This feels like it's inappropriately usurping a matter that should belong to the local wiki, especially with an instrument this blunt. It means individual wiki admins can't say that this user is trusted regardless of how many edits they made, that individual communities can't rely on their own definitions of autoconfirmed, etc. And it's unclear what actual problem this is meant to solve.

The reason we're pursuing this now is because the captcha is no longer a blunt instrument, the way that you correctly note that it historically has been, and was when skipcatcha permissions were created and this whole system was devised. FancyCaptcha was always challenging a user when it was presented, so a skipcaptcha right provided non-trivial relief to trusted users.

We've since replaced FancyCaptcha with hCaptcha across the wikis, where hCaptcha is configured to generally operate in 99.9% passive mode -- it only rarely challenges human users. So, even though this is raising the skipcaptcha threshold, the friction increase for regular users should in practice be minimal. This is the same reason we also recently commented on a meta RFC about exempting users with filemover rights, saying we want to see if our switch to hCaptcha addresses the friction that led to the RFC existing in the first place.

The value here is that raising the threshold adds friction to bad-faith actors working around the wikis' bot detection system (hCaptcha), which provides technical signals that are used by volunteers to detect abusive behavior. Unlike FancyCaptcha, where this was just a binary yes/no stop/go system, this architecture collects signals that are useful (alone or in combination with other things) even if the client was able to get through without a challenge. The more reliably that we can ensure that account creations, edits, and other sensitive actions go through this system, the more useful it will be.

Setting $wgSkipCaptchaMinimumEditCount locally, I have checked that an autoconfirmed user with less than the required number of edits still sees hCaptcha challenges on normal and AbuseFilter edits. With more than the required number of edits, they do not see the challenge on normal or AF edits. I have only tested WikiEditor, as I assume the editing interface will make no difference.

Agreed that this is quite confusing on the user-facing side. I just fielded a complaint from someone who was frustrated that they were getting a captcha despite being autoconfirmed and having the skipcaptcha right. Currently both individual project documentation as well as official documentation (including e.g., Special:ListGroupRights—"Perform CAPTCHA-triggering actions without having to go through the CAPTCHA") describe something very different from what's now live in production.

I really feel that as a minimum this should be given a tech news announcement, as well as this documentation getting updated. I also share similar concerns with this going against individual projects' wishes.

In T426973#11995627, @EMill-WMF wrote:

The more reliably that we can ensure that account creations, edits, and other sensitive actions go through this system, the more useful it will be.

I get that, but also the more edits that go through this system, the more false positives will occur that will both add friction to good-faith contributors (such as the one I mentioned, who did say this discouraged them from making their edit—it's a years old, autoconfirmed account on the project in question). The priority in my opinion should be letting projects figure out what is best for their circumstances.

I just fielded a complaint from someone who was frustrated that they were getting a captcha despite being autoconfirmed and having the skipcaptcha right. ... it's a years old, autoconfirmed account on the project in question

It's likely that this was affected by a different anti-abuse rule - we have some conditions that might bring in hCaptcha despite the presence of skipcaptcha, for particular situations that may be associated with abuse. It's unlikely to persist for them indefinitely. Bear in mind, this also means they triggered hCaptcha's challenge despite this having a measurably very low rate (we saw ~2% in testing) of challenging human users overall. We don't know exactly how evenly that's distributed, and perhaps they're using a client that for some reason triggers it more often. But the presence of hCaptcha does not itself mean the user is likely to actually be challenged, which is part of our rationale for being more willing to introduce specific anti-abuse conditions where skipcaptcha is overridden.

We're prepared for the impact of this on good-faith users to not be strictly zero, and I'm sorry you had to field a complaint about it, but overall, we do not think this is likely to pose significant challenges to many users.