Turn autoconfirmed into a usergroup with autopromotion
Closed, ResolvedPublic


We would like at en.wikipedia that 'autoconfirmed' becomes an explicit usergroup instead of an implicit permission, with an autopromotion method similar to the one used by the extension FlaggedRevs for the 'editor' usergroup. The autopromotion would happen after the current autoconfirmed requirements, on enwp: 4 days and 10 edits (90 days and 100 edits through TOR), and not being currently blocked.

This is motivated by the increasing importance and use of 'autoconfirmed' in various domains (abuse filter, bots, scripts, tools, apps, flagged protection, etc) and so the need for a reliable way to determine if a user is autoconfirmed, and the usefulness of a list of autoconfirmed users, a log of autoconfirmations and so on.

Autoconfirmations should be logged in the user rights log, but since it could risk to clog the log, it should be possible to filter them out, so for those a LOG_ACTION "autoconfirm" could be used, see also bug 17293.

Autoconfirmed shouldn't be manually grantable or removable. We would still use the confirmed group, which could be renamed to preconfirmed, as it's a source of confusion with other items.

The abuse filter has a way to suspend autoconfirmed, which could be affected.

Version: unspecified
Severity: enhancement
URL: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29/Archive_52#Turning_Autoconfirmed_into_an_explicit_usergroup


bzimport set Reference to bz21093.
bzimport added a subscriber: Unknown Object (MLST).
Cenarium created this task.Oct 11 2009, 2:08 AM

(In reply to comment #0)

We would like at en.wikipedia that 'autoconfirmed' ...

I don't see enough consensus. In order for the autoconfirmed to be 'logged' accurately, a task would need to frequently check every user to see whether they meet the configured conditions for the group.


The FlaggedRevs implementation is moving towards Autopromote. (bug 24948)

Anyway, this is essentially the same enhancement request as bug 15702 comment 4.

  • This bug has been marked as a duplicate of bug 15702 ***

Add Comment