Wikinews talk:Permission expiry policy/Archive 1


Privilege exposure limitation

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



Technical issue of "not ready"

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)Reply

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)Reply
<facepalms> --Pi zero (talk) 17:47, 20 September 2012 (UTC)Reply

'slight' expansion

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)Reply

Proposed page content

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

Introduction

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

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

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

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

  • 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)Reply
  • 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)Reply
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)Reply

┌────────────────┘
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)Reply

Just one more thing ...

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)Reply

Making keeping track easier

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)Reply

Template

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

I like it. Added a cross-reference from the notice section of the policy. --Pi zero (talk) 12:33, 28 September 2012 (UTC)Reply
  • 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)Reply
Return to the project page "Permission expiry policy/Archive 1".