Page MenuHomePhabricator

Add a new level of article protection on en.wikipedia.org
Closed, ResolvedPublic

Description

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.

Event Timeline

Cenarium raised the priority of this task from to Needs Triage.
Cenarium updated the task description. (Show Details)
Cenarium added subscribers: Cenarium, Jackmcbarn.
Dereckson renamed this task from Add once-autopromoted group to enwiki and edit restriction so that only users in the new group, bots and sysops can edit these pages to Add a new level of article protection on en.wikipedia.org.Feb 11 2016, 2:45 PM
Dereckson set Security to None.

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?

oh, and below templateeditor I guess. establishededitor?

Change 270660 had a related patch set uploaded (by Alex Monk):
New group/right/protection level for the English Wikipedia: establishededitor (?)

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

Change 270661 had a related patch set uploaded (by Alex Monk):
Add new messages for new enwiki group/right/protection level - proposed name 'establishededitor'

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

Change 270661 merged by jenkins-bot:
Add new messages for new enwiki group/right/protection level - proposed name 'establishededitor'

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

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?

Multiple concerns about "established" being in the name are being discussed - perhaps "extendedconfirmed" or something much more literal?

Someone needs to make a decision.

This request is not very clear on the "mechanics" - will every user be checked for this group immediately, on their next edit?

Autopromotions occur on-edit.

If 'removed' will it stay removed or will it re-autopromote?

I believe it will stay removed.

Per this discussion, let's go with extendedconfirmed.

Krenair removed a project: Patch-For-Review.

Change 279761 had a related patch set uploaded (by Dereckson):
"Established editor" → "Extended confirmed user"

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

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"

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

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?

Ok.. a few more tasks like that, and I will get routine :)

Change 281807 had a related patch set uploaded (by Luke081515):
Add 'extendedconfirmed' protection level on enwiki

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

Change 270660 abandoned by Alex Monk:
New group/right/protection level for the English Wikipedia: establishededitor (?)

Reason:
Doing in Ibeb3d0d8 instead

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

Okay, plan is to deploy this at evening SWAT today.

@Luke081515:

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

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

Change 281846 had a related patch set uploaded (by Alex Monk):
"Established editor" → "Extended confirmed user"

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

Change 281846 merged by jenkins-bot:
"Established editor" → "Extended confirmed user"

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

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.

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.

No, that would need a change to MediaWiki core itself.

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.

No, that would need a change to MediaWiki core itself.

Then how does autoconfirmed work? I know the abuse filter can revoke that right.

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.

No, that would need a change to MediaWiki core itself.

Then how does autoconfirmed work? I know the abuse filter can revoke that right.

$wgAutopromote instead of $wgAutopromoteOnce['onEdit']

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.

@Krenair So you're saying as it stands now, there's no quick and easy fix? :(

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:

Title::isSemiProtected

$semi = $wgSemiprotectedRestrictionLevels;

return !array_diff( $restrictions, $semi );
EditPage::showTextbox1

# 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

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

This was resolved.

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?

We shouldn't reopen tasks for such followups.

Okay, but should we work on a closed task or open a new task?

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.