Page MenuHomePhabricator

Solution ideas for wish #7 - page protection switches
Open, Needs TriagePublic

Description

This task is for collecting solution ideas to solve the page protection wish.

Background:
Wish #7 of the 2015 German-speaking community survey was T142209: Semi-protected pages that were fully protected should automatically return to previous state (#7)

Event Timeline

Lea_WMDE created this task.Aug 8 2016, 1:29 PM
Lea_WMDE updated the task description. (Show Details)
Lea_WMDE added a subscriber: Jan_Dittrich.
Restricted Application added a project: Design. · View Herald TranscriptAug 15 2016, 12:42 PM
Lea_WMDE updated the task description. (Show Details)Aug 17 2016, 9:45 AM
Lea_WMDE renamed this task from Investigate what can be done to solve wish #7 - page protection switches to Strategies to solve wish #7 - page protection switches.Sep 1 2016, 10:23 AM
Jan_Dittrich moved this task from Incoming to IncomingTCB on the WMDE-Design board.Sep 5 2016, 1:25 PM
Lea_WMDE renamed this task from Strategies to solve wish #7 - page protection switches to Solution ideas for wish #7 - page protection switches.Sep 26 2016, 12:21 PM
Lea_WMDE updated the task description. (Show Details)

Hypothesis:
Maybe is is all about making sure that protections that are set to "infinity" are abolished due to another protection that ends some day. E.g.: An always semi-protected page should after a pre-defined month of full protection return to the semi protected state and not be unprotected indefinitely

Solution proposal:
Have multiple protections in place at the same time, with only the last one entered being valid, or with the union of all protections being valid

Evaluation:

  • This solution would probably change the code a lot, and would most likely spend a lot of time in review
  • This solution allwos preemptive page protection, which might got against the wiki principle of allowing everyone to do everything

Hypothesis:
Maybe is is all about making sure that protections that are set to "infinity" are abolished due to another protection that ends some day. E.g.: An always semi-protected page should after a pre-defined month of full protection return to the semi protected state and not be unprotected indefinitely

Solution proposal:
Similar to the first one, but there may always be just one protection level for a page at a time.

Evaluation:

  • The change in the code base would probably not be as massive as for the first idea
  • It still allows preemptive page protection, if not to an equally strong degree
Lea_WMDE added a comment.EditedSep 26 2016, 12:34 PM

Hypothesis:
Maybe is is all about making sure that protections that are set to "infinity" are abolished due to another protection that ends some day. E.g.: An always semi-protected page should after a pre-defined month of full protection return to the semi protected state and not be unprotected indefinitely

Solution proposal:
Temporary protection settings do not change infinte protection settings, but are set seperately

Evaluation:

  • Would need clear communication
  • Is this the current behavior? Admins we talked to so far could all see the problem stated in the hypothesis, some had this in mind when thinking of problems with page protection, but nobody could remember encountering the problem themselves.
  • This solution would encourage using the infinity setting. However, there are many good reasons why admins never use it - if the protection automatically expires after a year or two, the need for the protection is automatically evaluated

Hypothesis:
Sometimes pages are protected for a longer time than necessary, since admins cannot be following all pages they protect and unprotect

Solution proposal:
Reminder service for admins: "Remind me to unprotect this page", so they can have a look at it later.

Volker_E moved this task from Incoming to WMDE on the Design board.Jan 5 2017, 5:54 PM

Workshop with CommTec (late March 2017):

[Assumptions]
! People are already used to setting multiple protection levels (through pending changes)
! you always want to respect other administrators’ decisions

[Ideas]

  • Ping me when it expires
  • Alert people when Protection is about to expire

[Levels]

  • There were quite many discussion around when you need how many levels [over time] of protection.
  • Number of levels of concurrent protection might be configurable on a per wiki basis
  • Idea: dont allow higher protections as baseline protections
  • One idea was having two at a given time as suggested by existing mockups by the WMDE UX team
  • One concern was that suggesting additional levels [over time] in the UI may encourage people to protect prematurely
  • One concern (as expressed by Jan/me) was that we might assume we need just 2 levels, but it is easy to imagine a case where you need 3 or so – why put an arbitrary constraint of 2?
  • One combination was having only one level of possible protection exposed in the UI and an additional +Button. So we would not encourage people to fill out some empty "2nd level protection fields" (they only appear after pressing +) and we would not decide on a fixed level of protections (we could still create constraints, but they would thus not be backed in the UI themselves)

PLAN: Sketch 2 options:

  1. One level exposed, more to add via +
  2. Two exposed levels (permanent/tempoary)
  3. ?

Hanna_Petruschat_WMDE changed the task status from Open to Stalled.Nov 13 2017, 3:05 PM
Lea_WMDE changed the task status from Stalled to Open.Nov 15 2017, 4:05 PM

changed to open as ideas/info is still welcome

Charlie_WMDE moved this task from Reported TCB to IncomingTCB on the WMDE-Design board.