See community discussion.
It is requested that a new usergroup be added, autopromoted once after 30 days and 500 edits, and that a new userright e.g. editrestricted be created and added to this group, bots and sysops. Sysops should also be able to add/remove this usergroup. In addition, a new edit restriction level is requested, requiring the new userright to edit pages under this protection.
The name of the usergroup hasn't been really discussed.
Description
Details
Related Objects
Event Timeline
How's this: establishededit, group with autopromotion for users with 30 days + 500 edits, grantable/revokable by sysops, and as a protection level between semiprotected and fully protected?
Change 270660 had a related patch set uploaded (by Alex Monk):
New group/right/protection level for the English Wikipedia: establishededitor (?)
Change 270661 had a related patch set uploaded (by Alex Monk):
Add new messages for new enwiki group/right/protection level - proposed name 'establishededitor'
Change 270661 merged by jenkins-bot:
Add new messages for new enwiki group/right/protection level - proposed name 'establishededitor'
Multiple concerns about "established" being in the name are being discussed - perhaps "extendedconfirmed" or something much more literal? This request is not very clear on the "mechanics" - will every user be checked for this group immediately, on their next edit? If 'removed' will it stay removed or will it re-autopromote?
Someone needs to make a decision.
Autopromotions occur on-edit.
If 'removed' will it stay removed or will it re-autopromote?
I believe it will stay removed.
Change 279761 had a related patch set uploaded (by Dereckson):
"Established editor" → "Extended confirmed user"
Perhaps the most appropriate priority for the task right now, as they're people working on it, but does not seem very urgent.
Change 279761 merged by jenkins-bot:
"Established editor" → "Extended confirmed user"
So the localisation is fixed. Next step is to prepare the actual config change.
@Luke081515 You want to do it as you're already handling that kind of request for fr.wikipedia?
Change 281807 had a related patch set uploaded (by Luke081515):
Add 'extendedconfirmed' protection level on enwiki
Change 270660 abandoned by Alex Monk:
New group/right/protection level for the English Wikipedia: establishededitor (?)
Reason:
Doing in Ibeb3d0d8 instead
This should be in wmgAutopromoteOnceonEdit instead of wmgAutopromoteExtraGroups and not be granted to those in groups with the right.
'enwiki' => array( 'extendedconfirmed' => array( '&', array( APCOND_EDITCOUNT, 500 ), array( APCOND_AGE, 30 * 86400 ), // 30 days * seconds in a day array( '!', array( APCOND_INGROUPS, 'sysop' ) ), array( '!', array( APCOND_INGROUPS, 'bot' ) ), ), ),
Change 281807 merged by jenkins-bot:
Add 'extendedconfirmed' protection level on enwiki
Change 281846 had a related patch set uploaded (by Alex Monk):
"Established editor" → "Extended confirmed user"
Change 281846 merged by jenkins-bot:
"Established editor" → "Extended confirmed user"
Can we keep automatic promotions out of the user rights log (similarly to the way that autoconfirmed is silent); it'll be a far too common event that spams the log and watchlists.
Pages under this new level of protection have a .mw-textarea-protected CSS class, giving it a pink background like template and fully protected pages. Could we remove this? The protection is used on normal collaborative articles where extended confirmed users are welcomed to edit as they please, as opposed to some high-risk template or interface page.
Maybe there could be an extra class added identifying the level of protection. But not unless there's a separate ticket for adding such a thing to MediaWiki core.
I have no idea why MW core even recognises semi-protection as a concept... But maybe we could add it to wgSemiprotectedRestrictionLevels and therefore it'd get mw-textarea-sprotected instead (among other things)?
Yes, define $wgSemiprotectedRestrictionLevels should work:
… $semi = $wgSemiprotectedRestrictionLevels; … return !array_diff( $restrictions, $semi );
… # Is the title semi-protected? if ( $this->mTitle->isSemiProtected() ) { $classes[] = 'mw-textarea-sprotected'; } else { # Then it must be protected based on static groups (regular) $classes[] = 'mw-textarea-protected'; } …
Looking at everything that uses $wgSemiprotectedRestrictionLevels, it does look like exactly what we want. Let's do that.
Change 281967 had a related patch set uploaded (by Dereckson):
Set wgSemiprotectedRestrictionLevels for en.wikipedia
I reopened the task as there is a need to tweak the configuration. So to implement this wgSemiprotectedRestrictionLevels, you suggest @Jackmcbarn or @MusikAnimal opens a new task for wgSemiprotectedRestrictionLevels, and perhaps also discuss the issue on en.wikipedia?
I'm safely assuming enwiki wants the pink removed. I don't think anyone knew that was going to be a consequence. I brought it up at WP:VPT and the two who replied were in agreeance. Happy to open up a formal discussion if you feel it's needed, though!
I don't really mind, I just think we really shouldn't have completed requests continually getting reopened over followup requests until everything about them is completely perfect.
Well, the task status is the reflect of the state of the task. As such, if there is some task to do, an open task should exist. This could be the initial task from a "goal" point of view, but if we consider, as you seem to prefer, the initial task has been completed and any follow-up isn't a part of the former task, a new task should be open for better tracking. I'm fine with both options, so as you don't like the first, let's open a new task.
@MusikAnimal No, a formal vote doesn't seem to be needed in this case; as the subject is already discussed you can add on the follow-up task the link.