In T418484#11655519, @mszwarc wrote:

I think an option to consider may be to make this change only on wikis which have $wgAutoConfirmCount greater than 0, so where no autoconfirmed user is likely to lose their status

Given the potential problems that @Xaosflux pointed, we'll reduce this change only to wikis where $wgAutoConfirmCount is greater than 0.

Seems like a good first start. For community notification:

On wikis that require edits and age to be autoconfirmed, the aging will now begin after the first edit.

Or something to that affect. There are likely local documentation pages ( https://www.wikidata.org/wiki/Q4616064 ) that will need to be reviewed for revisions.

If fighting sleeper accounts is the main reason for that change, why does it have to effect any old accounts at all? Couldn't it be also connected with the global account age (and/or number of global edits [in case we can finally request that number]), for example? That would reduce the problem for experienced users on some wikis to contribute to other wikis, while still blocking low-edit/new global accounts from creating sleeper accounts.

Oh, well, and please give all of us more time to think about potential problems. We could also add that to the agenda of the next steward call, for example.

In T418484#11659573, @DerHexer wrote:

If fighting sleeper accounts is the main reason for that change, why does it have to effect any old accounts at all? Couldn't it be also connected with the global account age (and/or number of global edits [in case we can finally request that number]), for example? That would reduce the problem for experienced users on some wikis to contribute to other wikis, while still blocking low-edit/new global accounts from creating sleeper accounts.

Given that autoconfirmed status is given dynamically and not recorded anywhere, it would be nontrivial to encode a rule "meets the conditions or has been autoconfirmed before".

Based on the Xaosflux' comments above, we're happy to limit this config change only to wikis, which already require some edits for autoconfirmed status. In this case almost no accounts will lose autoconfirmation – this will be limited mostly to accounts created a few days prior to the change (or accounts whose first edit was made in this period). I don't expect many established community members to be in this group.

Incorporating global account information in the conditions is IMO something worth considering, especially for smaller project where "external contributors" are more common.

The idea behind just this change was to try out a low-hanging fruit, which is possible to configure now (without implementation work), and may potentially inform further approach towards autoconfirmation status. And, especially in this reduced model, we didn't expect significant side effects to happen.

I have previously suggested at T323948#9103374 that we should raise the default $wgAutoConfirmCount to at least 1, which also have some support at T411263#11423084.

From db perspective, autoconfirmed is an implicit group. A concept I‌ never liked because it gets calculated on every single index.php request. Even for page views. It is something I wish to fix that but at least the queries currently are just direct straightforward and fast queries of the user table. This change makes it much more complicated because now you need to query the revision table on every page view.

Suggestion:

• Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I‌ haven't kept track of recent refactorings in that area)
• Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.

In T418484#11662889, @Ladsgroup wrote:

From db perspective, autoconfirmed is an implicit group. A concept I‌ never liked because it gets calculated on every single index.php request. Even for page views. It is something I wish to fix that but at least the queries currently are just direct straightforward and fast queries of the user table. This change makes it much more complicated because now you need to query the revision table on every page view.

Suggestion:

• Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I‌ haven't kept track of recent refactorings in that area)
• Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.

Thanks about the comment. I see that the change is not as straightforward as we originally thought. We won't deploy it, then. The idea in itself is, I think, still worth considering, but will need rethinking.

Make autoconfirmed a non-implicit user group.

This will inflate the user groups table with large number of users that never edited.

• If this it chosen, we should consider require user to have at least one edit to be autoconfirmed - this will make size of table much smaller.
• Another issue is community may alter the threshold of autoconfirmed. If it becomes a nonimplicit group, previously confirmed users (by default this will mean most of users) will remain confirmed, defeating the purpose of raising threshold.

In T418484#11662889, @Ladsgroup wrote:

• Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I‌ haven't kept track of recent refactorings in that area)

This would probably be helpful for various usecases, especially for research, where autoconfirmed status needs to be hacked around currently. However, it'll inflate the user_groups and logging tables. I have checked on enwiki and there are 5.5M autoconfirmed accounts there. On the other hand, user_groups has only 103k rows, which means it would grow 50 times with this change. And the rights log would probably become a pile of trash (about 98% of it would be autoconfirmation records).

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count(*) from user where user_registration < '20260228' and user_editcount >= 4;
+----------+
| count(*) |
+----------+
|  5455767 |
+----------+
1 row in set (2 min 33.923 sec)

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count(*) from user_groups;
+----------+
| count(*) |
+----------+
|   102613 |
+----------+
1 row in set (0.203 sec)

• Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.

Using e-mail confirmation status for autoconfirmed group will probably make life harder for users who (for various reasons) don't want to put e-mail address in their preferences.

What if we applied caching in the code looking for first edit timestamp? It can be assumed to be constant, so that we could use quite long TTL (e.g., one day). Then, the revision table would be hit only once per day per user. Is that an acceptable direction?

In T418484#11666824, @mszwarc wrote:

In T418484#11662889, @Ladsgroup wrote:

• Make autoconfirmed a non-implicit user group. Use auto promote (if that's already the case, great. I‌ haven't kept track of recent refactorings in that area)

This would probably be helpful for various usecases, especially for research, where autoconfirmed status needs to be hacked around currently. However, it'll inflate the user_groups and logging tables. I have checked on enwiki and there are 5.5M autoconfirmed accounts there. On the other hand, user_groups has only 103k rows, which means it would grow 50 times with this change. And the rights log would probably become a pile of trash (about 98% of it would be autoconfirmation records).

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count(*) from user where user_registration < '20260228' and user_editcount >= 4;
+----------+
| count(*) |
+----------+
|  5455767 |
+----------+
1 row in set (2 min 33.923 sec)

mysql:research@dbstore1008.eqiad.wmnet [enwiki]> select count(*) from user_groups;
+----------+
| count(*) |
+----------+
|   102613 |
+----------+
1 row in set (0.203 sec)

5.5M rows is not that big as user_groups has low number of columns and not many indexes so it's not that big of a problem. I'd say it'll be just full of bloat. That's a bigger problem.

• Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.

Using e-mail confirmation status for autoconfirmed group will probably make life harder for users who (for various reasons) don't want to put e-mail address in their preferences.

I‌ understand but having a confirmed email is important for password reset, getting notification specially login notification and more. That's why we are trying to nudge people to actually confirm their emails:‌ T58074: Echo: Generate periodic web notification to nudge users to confirm an unverified email address

What if we applied caching in the code looking for first edit timestamp? It can be assumed to be constant, so that we could use quite long TTL (e.g., one day). Then, the revision table would be hit only once per day per user. Is that an acceptable direction?

Yeah, go even with a month if you ask me.

In T418484#11667812, @Ladsgroup wrote:

• Not mutually exclusive with the previous suggestion: Do this instead T395207: Make confirmed email part of being auto confirmed. Querying user_email_authenticated is fast and probably already loaded when the user object gets loaded.

Using e-mail confirmation status for autoconfirmed group will probably make life harder for users who (for various reasons) don't want to put e-mail address in their preferences.

I‌ understand but having a confirmed email is important for password reset, getting notification specially login notification and more. That's why we are trying to nudge people to actually confirm their emails:‌ T58074: Echo: Generate periodic web notification to nudge users to confirm an unverified email address

I am interested in this, but let's move that discussion to a separate task as it's a bigger change to implement.

Change #1250563 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] UserEditTracker: Offer cached first edit timestamp

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

Change #1250564 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Invalidate UserEditTracker first edit cache on page delete

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

for a day if user doesn't have edits (this is cheaper, as most often it's sufficient to read user_editcount, which is preloaded for the current user)

One note: We had a pretty nasty perf bug because WANObject cache interface assumed "false" (or more falsey values) meant the value shouldn't be cached (so in every pageview we were querying the same row 34 times...) so please make sure that won't happen here.

@mszwarc I see that this upcoming change is in review. Would it be ready for tech news this week? And how should we word it?

In T418484#11748356, @STei-WMF wrote:

@mszwarc I see that this upcoming change is in review. Would it be ready for tech news this week? And how should we word it?

No, it won't be ready for this week.

Change #1250563 merged by jenkins-bot:

[mediawiki/core@master] UserEditTracker: Offer cached first edit timestamp

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

Change #1250564 merged by jenkins-bot:

[mediawiki/core@master] Invalidate UserEditTracker first edit cache on page delete

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

Change #1272720 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[mediawiki/core@master] Add ::getFirstEditTimestamp to mock in ChngeTrackingUpdateSpyTrait

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

Change #1272720 merged by jenkins-bot:

[mediawiki/core@master] Add ::getFirstEditTimestamp to mock in ChangeTrackingUpdateSpyTrait

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

In T418484#11666824, @mszwarc wrote:

What if we applied caching in the code looking for first edit timestamp

Caching has been implemented and merged. Given that, I think we may be ready to deploy the config change no sooner than Apr 30 (when wmf.26 rolls out to wikis).

In T418484#11832647, @mszwarc wrote:

In T418484#11666824, @mszwarc wrote:

What if we applied caching in the code looking for first edit timestamp

Caching has been implemented and merged. Given that, I think we may be ready to deploy the config change no sooner than Apr 30 (when wmf.26 rolls out to wikis).

@mszwarc can you please propose some wording for tech news?

I have added the following text to the next Tech News issue:

There is a new change in how new users are autoconfirmed that will improve anti-vandalism protection. Currently, users who have had an account for a few days and made a few edits are automatically added to the Autoconfirmed users group. This configuration tends to be exploited by some vandals, who create accounts and start to use them only after some time. To mitigate this, the configuration will be updated next week so that – for the purpose of becoming autoconfirmed – the account age will be counted from their first edit, instead of registration date. The numeric value of the age threshold will remain the same. This change will be deployed only to wikis which require at least one edit as part of the autoconfirmation conditions.

does this change apply to the extended-confirmed right?

In T418484#11865229, @lettherebedarklight wrote:

does this change apply to the extended-confirmed right?

This change will affect only the autoconfirmed group, as it's the lowest hanging fruit, I think. I'm not saying that XC shouldn't be changed but probably it would be better to do it separately (so that we will already feel if change to AC has the expected impact).

(Relay from viwiki)

Is this an immediate and required change for wikis with the above settings?

Change #1282850 had a related patch set uploaded (by Mszwarc; author: Mszwarc):

[operations/mediawiki-config@master] Switch 'autoconfirmed' to use APCOND_AGE_FROM_EDIT on certain wikis

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

Change #1282850 merged by jenkins-bot:

[operations/mediawiki-config@master] Switch 'autoconfirmed' to use APCOND_AGE_FROM_EDIT on certain wikis

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

Mentioned in SAL (#wikimedia-operations) [2026-05-05T13:03:35Z] <mszwarc@deploy1003> Started scap sync-world: Backport for [[gerrit:1282850|Switch 'autoconfirmed' to use APCOND_AGE_FROM_EDIT on certain wikis (T418484)]]

Mentioned in SAL (#wikimedia-operations) [2026-05-05T13:05:41Z] <mszwarc@deploy1003> mszwarc: Backport for [[gerrit:1282850|Switch 'autoconfirmed' to use APCOND_AGE_FROM_EDIT on certain wikis (T418484)]] synced to the testservers (see https://wikitech.wikimedia.org/wiki/Mwdebug). Changes can now be verified there.

Mentioned in SAL (#wikimedia-operations) [2026-05-05T13:11:30Z] <mszwarc@deploy1003> Finished scap sync-world: Backport for [[gerrit:1282850|Switch 'autoconfirmed' to use APCOND_AGE_FROM_EDIT on certain wikis (T418484)]] (duration: 07m 55s)

Let's keep in in QA for a moment, to ensure that there are no side effects (shouldn't be any).

In T418484#11871719, @.nhals8 wrote:

(Relay from viwiki)

Is this an immediate and required change for wikis with the above settings?

Sorry for the late response, I missed this question as it coincided with me going to the Hackathon.

Even though the conditions for autopromotions have been configurable for quite a long time, no community decided to change the types of conditions used (all wikis relied on the default set of APCOND_EDITCOUNT and APCOND_AGE). Therefore, we treat this change as an update of default values for the configuration – not overriding a consensus from wiki (which was really about the parameters to conditions).

So, going back to your question, the change went live yesterday and is the new default, but if a wiki really wants to change that default, I think it's possible to go back to the previous scenario. However, in the Product Safety and Integrity opinion, the new setting makes more sense for at least a vast majority of situations (as account creation is a very cheap action and not that much inspectable with respect to the user being potentially a vandal).