Wikinews talk:Privilege expiry policy

From Wikinews, the free news source you can write!
Jump to navigation Jump to search

Privilege exposure limitation[edit]

This discussion has been moved here from the policy water cooler. --Pi zero (talk) 12:15, 20 September 2012 (UTC)



Technical issue of "not ready"[edit]

Any ideas on how we spot not-ready reviews?

My initial thought was a couple of hidden categores on the article talk inside the not ready template. But, just now we frequently end up zapping those articles when they become stale.

Looks like another to-do for NewsieBot (talk · contribs) that we've wondered about for a while - userspacing abandoned/stale articles - would be needed. --Brian McNeil / talk 16:27, 20 September 2012 (UTC)

Not-ready reviews via EzPR are easily spotted in Special:Contributions by string-searching for either "not ready when" or "article needs improve". If necessary one can switch from most-recent-50 to most-recent-500, of course. The edit summary is generated by EzPR and is always the same.
Special:Contributions/Pi zero&limit=500
No need for a bot for this. :-)  --Pi zero (talk) 17:14, 20 September 2012 (UTC)
<facepalms> --Pi zero (talk) 17:47, 20 September 2012 (UTC)

'slight' expansion[edit]

This isn't intended to wikilawyer the proposed policy, just to frame it more in-line with other policies. --Brian McNeil / talk 21:15, 20 September 2012 (UTC)

Proposed page content[edit]

The Wikinews Privilege expiry policy is one where some elevated privileges on-project may be removed due to inactivity/lack of use.

Introduction[edit]

Any wiki project changes over time. The community's consensus moves; rules and policies evolve, and methods of carrying out tasks change. Thus any individual entrusted with elevated privileges who becomes inactive, or does not use a privilege over a prolonged period of time, ceases to be familiar with current practice.

Unused privileged accounts, excluding those with extremely strong passwords, also pose a security risk through an increased attack surface. Good security practice dictates that such accounts should have unused privileges removed.

Application of the policy[edit]

The following table summarises the policy's rules governing privilege removal.

Privilege Status action to be taken
Bureaucrat No edits past nine months Request steward downgrade to admin[1]
Administrator No edits past nine months Downgraded to 'normal' user
Either of the above No use of either priv in past 12 months Downgraded, or privilege removed[1]
Reviewer No reviewer actions past 12 months[2] Reviewer privilege removed
Accredited No edits past nine months Accreditation revoked
  1. Once a bureaucrat is downgraded to administrator, the clock starts for inactivity as an administrator.
  2. A not-ready review via the Easy Peer Review tool is a reviewer action, although it does not appear in Special:Log/review.
  3. CheckUser and Oversight are currently excluded from this policy.

Notifying affected users[edit]

To avoid conflict, a note should be left on the talk page of any user who loses privileges under the policy. This should explain the privilege has been revoked due to lack of use; not as a reflection of, or comment on, the user's standing in the community.

Regaining privileges[edit]

Re-granting of privileges revoked due to lack of use should be less-onerous than initially obtaining the privilege. A period of re-acclimatisation with the project, being active, becoming familiar with current policies and observing current use of said privileges can be followed with fast-tracked request for the rights to be reinstated.

Comments[edit]

  • I've got a clarification to request, and a qualification to suggest.
  • Clarification: Do we (as I would suspect) intend to exempt users with checkuser or oversight, or intend merely that those privileges are not removed by the policy? In the latter case we might, say, de-sysop a checkuser.
  • If the users themselves are exempt, I suppose I should ask whether we mean Arbs to be covered.
  • Qualification: The idea of fast-tracking, in section "Regaining privileges", is properly an addition to the policy, since there was no provision for it in the proposal we've been voting on up till now. If we're going to provide explicitly for fast-tracking, perhaps we should place explicit bounds on it similar to those on my proposal last April. That proposal was only for reviewer inactivity. The warily limited fast-tracking provision then, as amended at suggestion of BRS, read:
  • Under certain limited circumstances, such a request may be "expedited".
  • To qualify, the user must be in good standing, have had the bit removed only for inactivity, and have actually used the bit before its removal.
  • If at least two trusted users (admins, reviewers, etc.) support restoring the bit, and the request has been open for a couple of days with no doubts expressed nor expected, there's understood to be no need to keep it open longer.
Will give some thought to how these principles might be cleanly phrased here.
--Pi zero (talk) 22:04, 20 September 2012 (UTC)
  • Good questions, and a most-reasonable qualification of 'fast-tracking' back to a privved status.
Let me try and tackle them in easiest order:
  • I am of the opinion ArbCom membership is distinct from any privileges.
That means a non-admin ArbCom member may require an admin disclose information to them only available as an admin - should an ArbCom case require they have that information.
  • CheckUser and Oversight are, I believe, a superset of admin rights. One could not function effectively in either role without the same access to data (such as deleted pages) as an administrator.
I've assumed that means we wouldn't mess with the priv-bits of those people.
In theory, CheckUser could operate without delete, revdel, and block. In practice, not. Oversight can't be separated from delete as it's a super-delete. --Brian McNeil / talk 23:16, 20 September 2012 (UTC)
Those answers fit with my understanding of the issues. I've proposed a draft on the page, with the following differences from your draft above: diff. --Pi zero (talk) 00:21, 21 September 2012 (UTC)

┌────────────────┘
That looks spot-on. I suggest we give this another week or so. I very much doubt anyone who has expressed an opinion will object to these clarifications.

My outlining of the policy in an as-simple-as-possible format (the table) was aimed at putting the concept across quickly, and with a minimum of drama. --Brian McNeil / talk 08:51, 21 September 2012 (UTC)

Just one more thing ...[edit]

Accreditation has a raft of off-(this)-wiki implications:

  1. Reporters' email address.
  2. Access to the JWS closed wiki.
  3. Possible access to the Editors' blog.

Obviously I'll manage the necessary technical aspects of this. What anyone with these 'perks' would see is:

  1. An email notice their account is being closed down (with some grace period to retrieve email for those who rely on webmail).
    Following the grace period, the account would be deleted, and a same-name forwarder created pointing to scoop.
  2. Full blocking of the account; account renamed to a _closed-salt to prevent any level of access.
  3. Downgrading of Editors' blog account to basic subscriber.

--Brian McNeil / talk 09:03, 21 September 2012 (UTC)

Making keeping track easier[edit]

I've created a new template, {{Privved-user}}, and applied it on the list of administrators to make checking easier. --Brian McNeil / talk 12:18, 23 September 2012 (UTC)

Template[edit]

I'd welcome any, and all, input on the formulation of {{PeP applied}}. --Brian McNeil / talk 09:08, 28 September 2012 (UTC)

I like it. Added a cross-reference from the notice section of the policy. --Pi zero (talk) 12:33, 28 September 2012 (UTC)
  • Glad to hear that. I'm tempted to do an edit on the graphic to show a desk overflowing with paperwork. One of our most-common causes for losing regular contributors is they start in the final years of school and college simply overwhelms them to the extent they can't keep up.
I would welcome as-wide input as possible on this being a "friendly" template. I'm out to allay the concerns Craig raises above, to act as a 'gentle push' to get re-involved — even if at a far-lower level, and to ensure that people don't view privilege reduction as any sort of vindictive or victimising process. --Brian McNeil / talk 13:24, 28 September 2012 (UTC)

Proposed change to the inactivity period[edit]

In light of the proposed removal of bureaucrat privileges from three users today, I propose that we change the privilege expiry policy.

  • The current policy is too restrictive in my honest opinion.
  • At the very least, the inactive period should be 1 year, as shown in option 1.
  • However, when the stewards carry out administrative activity reviews for many wikis, the maximum allowed period of inactivity without community review is 2 years.
  • Given that this wiki is not as large as others, I suggest we go for option 2, where all of the requirements would be increased to two years.
Current policy
Privilege Status action to be taken
Bureaucrat No edits past nine months Request steward downgrade to admin[1]
Administrator No edits past nine months Downgraded to 'normal' user
Either of the above No use of either priv in past 12 months Downgraded, or privilege removed[1]
Reviewer No reviewer actions past 12 months[2] Reviewer privilege removed
Accredited No edits past nine months Accreditation revoked
Option 1
Privilege Status action to be taken
Bureaucrat No edits past 12 months Request steward downgrade to admin[1]
Administrator No edits past 12 months Downgraded to 'normal' user
Either of the above No use of either priv in past 12 months Downgraded, or privilege removed[1]
Reviewer No reviewer actions past 12 months[2] Reviewer privilege removed
Accredited No edits past 12 months Accreditation revoked
Option 2
Privilege Status action to be taken
Bureaucrat No edits past 2 years Request steward downgrade to admin[1]
Administrator No edits past 2 years Downgraded to 'normal' user
Either of the above No use of either priv in past 2 years Downgraded, or privilege removed[1]
Reviewer No reviewer actions past 2 years[2] Reviewer privilege removed
Accredited No edits past 2 years Accreditation revoked

  1. Once a bureaucrat is downgraded to administrator, the clock starts for inactivity as an administrator.
  2. A not-ready review via the Easy Peer Review tool is a reviewer action, although it does not appear in Special:Log/review.
  3. Users in the CheckUser and Oversight user groups are currently excluded from this policy.

I have deliberately not included any vote sections yet, in order to allow discussion to take place first. --Green Giant (talk) 03:17, 13 April 2020 (UTC)

Discussion[edit]

  • Comment Two thoughts.
  • Given the nature of the policy, I suggest tweaking the wording of the rightmost column heading from "action to be taken" to "action allowed" (doesn't actually change the meaning, as the sentence at the top of the policy governs, but may be clearer).
  • Although I have no concerns going to 2 years on most of these privs, I'm not so sure about reviewer, which is a highly technical skill requiring the user to be very currently in-touch with what they're doing.
I may propose, after pausing to be sure of my step, an option three. --Pi zero (talk) 04:01, 13 April 2020 (UTC)
An option 3 would be welcome. The phrase "action allowed" would suggest it can be decided that privileges do not need to be removed. The question then is how such a decision is reached. My first instinct is it could be done in a similar way to how the privilege was gained e.g. a discussion for perhaps seven days to gauge what regular contributors and the inactive user think? --Green Giant (talk) 18:54, 13 April 2020 (UTC)
For reviewers I'm not sure about differentiating the inactivity period for reviewers because part of the motive behind this proposal is to give maximum allowable leeway for inactive users. I understand the rust problem but I think that makes more sense if the inactive user has barely user the reviewer tool or not at all. It it’s an experienced reviewer, I suspect they would become proficient again quite quickly. --Green Giant (talk) 18:54, 13 April 2020 (UTC)
As an afterthought I’m going to suggest we add bots to the table. Operating such an account should be treated as a privilege and lack of use over a defined period should be grounds for removal. --Green Giant (talk) 18:54, 13 April 2020 (UTC)
  • Brian and Skenmy have made no edits in over 2 years, and should be desysopped under both current policy and the new one. Brian_McNeil has made edits in the last 2 years, but not in the last 9 months, and is clearly inactive, and should be desysopped per the current policy (if a new policy is adopted and made retroactive, can be resysopped). --DannyS712 (talk) 19:47, 13 April 2020 (UTC)
  • It would seem reasonable to use option three, to me, here; news writing is a big commitment, time wise, which requires having large uninterrupted time slots. Sometimes reasonably experienced contributors disappear because of family commitments, and it is more difficult for them to come back to Wikinews than another wiki. I would support two year expiry here, an increase from the current time frames. --Gryllida (talk) 11:02, 21 April 2020 (UTC)

Proposed change to notification[edit]

This is a separate proposal to change the notification requirement. It does not currently require the notification even after removal has happened. Instead, in light of the above section, I propose we add a compulsory notification requirement.

Current wording
Cquote1.svg To avoid conflict, a note should be left on the talk page of any user who loses privileges under the policy. This should explain the privilege has been revoked due to lack of use; not as a reflection of, or comment on, the user's standing in the community. See: {{PeP applied}}; feel free to add a personalised encouragement for people to re-involve themselves when using this template. Cquote2.svg
Proposed wording
Cquote1.svg A note must be left on the talk page of any user who could lose privileges under the policy, at least one month before the request for removal of privileges. This should explain the privilege may be revoked due to lack of use; not as a reflection of, or comment on, the user's standing in the community. If the privileges are removed, the summary in the user rights log should state that the removal is purely procedural.

See: {{PeP applied}} for after removal of privileges; feel free to add a personalised encouragement for people to re-involve themselves when using this template.

Cquote2.svg

As above, I’ve not created a vote section yet to enable discussion. --Green Giant (talk) 03:17, 13 April 2020 (UTC)

Discussion[edit]

  • Comment
  • Not for reviewer. Expiry of the reviewer priv is about a user having gotten rusty on the project, not about individual sentiment.
  • For crat, this might makes sense, yes.
I'm going to want to give this some more thought, before making a specific recommendation. --Pi zero (talk) 04:17, 13 April 2020 (UTC)
  • I am not sure a notification like this would be helpful. If I was in such a situation and got a warning of privilege expiry one month beforehand, I would possibly make an edit or two (i.e. stay active for this one month) and then family/work/another commitment would possibly make me inactive again. How could this possibly be avoided? Notifying of privilege expiry after it occurred partially resolves the problem, as the contributor can contribute for some time, after losing the privilege, and re-apply only if their other commitments allow to continue their work in their privileged capacity.
This is just the first thought; I have not seen how this is done at other wikis. --Gryllida (talk) 11:09, 21 April 2020 (UTC)