Page MenuHomePhabricator

Insights/ Voices from the Community for the page protection wish (#7)
Open, Needs TriagePublic

Description

This task is for collecting all the information necessary to fulfill wish #7 of the German-speaking community's technical wishlist of 2015 T142209.

If you think we should know something or want to let us know about what you think about page protections, and your current way of working with them, please post below!

Event Timeline

Lea_WMDE created this task.Aug 19 2016, 2:32 PM
Lea_WMDE renamed this task from Investigate how to solve Wish #7: Dealing with page protection to Insights/ Voices from the Community for the page protection wish (#7).EditedSep 26 2016, 10:35 AM
Lea_WMDE updated the task description. (Show Details)

Basics about page protection:

  • The wiki default is "everybody can do everything". However, there are different protections that take away some of rights for some of the users.
  • Protection rights are hierarchical. However, user roles (groups) may mix protection rights in whichever manner they want. Therefore groups are not necessarily hierarchical.
  • Right now, per protection level, one (or no) group is defined for protection, i.e. "autoprotect"...
  • Which user roles and page protection types exist differs from community to community. There is the default of semi-protection/ full-protection throughout the wiki, but e.g. de-wiki has another right for "sighters" in between the two. It looks like usually the number of protection rights (including unprotected) is between 3 and 6

What we know codewise:
This variable contains a list of permission keys that can be selected for each restriction type on the "page protection" page (action=protect).
https://www.mediawiki.org/wiki/Manual:$wgRestrictionLevels
wgRestrictionLevels https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L4323

A page can only be protected with cascading protection if the requested restriction level is included in this array. Should be a subset of $wgRestrictionLevels.
https://www.mediawiki.org/wiki/Manual:$wgCascadingRestrictionLevels
wgCascadingRestrictionLevels https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L4345

This variable contains a list of permission levels that should be considered as "semi-protection" rather than "full protection". Should be a subset of $wgRestrictionLevels
https://www.mediawiki.org/wiki/Manual:$wgSemiprotectedRestrictionLevels
wgSemiprotectedRestrictionLevels https://github.com/wikimedia/operations-mediawiki-config/blob/master/wmf-config/InitialiseSettings.php#L4350

Lea_WMDE added a comment.EditedSep 26 2016, 10:44 AM

From conversations with 7 admins of de-wiki:

  • The principle of "trust first" is very important. Often times there is also pages with an infinite protection whose protection has simply been forgotten. This should not happen. A page should have the least protection necessary. "If the page protection prevents one good edit, it has already been a bad idea"
  • Sometimes it is necessary to protect a page for long periods of time, e.g. pages that are used in school context (e.g. articles about building tools, animals...), pages about famous people (e.g. Angela Merkel) or controverse topics (e.g. abortion). They need to be protected for long periods of time, because there is a high likelihood that they are vandalized
  • Which protection level is set also depends on the history of protections for this page.
  • Admins have different strategies of page protection. E.g., some never use the infinite protection status, but only 1 year or 2, so that the page has more chances of losing its protection again.
  • It is not really that pages are watched to be able to protect them at some point, but more alerts admins receive and react upon, e.g. requests for protection, or requests for taking away protections.

There are different protection types:

  • edit protection
  • move protection: This is actually the hardest to clean up. It is mainly about articles that have been renamed, or worse, split
  • upload protection

Since admins are more reacting to outside demands "protect this page!", "unprotect this page", and have different strategies, they may accidentally be undoing each other's actions