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

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.

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. ?