Escalating privileges: proposal for initial version

See also more extensive vision-type proposal at Escalating privileges system

Goals

The goals for later versions will be to help with the administrative burden. The initial version will be focused on improving the quality of requests. The idea is to:

• Encourage good quality requests
  • ...but without censoring anything
• Specify and implement a first version release promptly
  • ...but ensure we provide solid foundation for future iterations (and envisaged future features such as a public request queue, and a bulk request system to which access is limited, perhaps in part depending on privileges, or support/approval from those with privileges)

Risks

• Appearance of, or actually, turning using Alaveteli sites into a game where people make requests for the purpose of obtaining points on our site. Awareness of this risk ought lead to caution eg. with publicly displaying user's "scores" and in respect of any leader boards etc.

Tactics

• Make good quality requests stand out throughout the system
• Conversely, make bad quality requests less visible
• Provide incentives to people to ask good quality requests for information in the form of privileges.

Specifically

• Provide upvote and downvote buttons for requests. When a button is clicked for the first time, ask people to check our "guidelines for a good request" first. (An alternative to a binary up or down vote would be a score say 1-5 stars with possibly other options eg. -2 for contrary to site policies). Consider a "report to admin" button for use with subject access requests / personal info published, else people may wonder how to score such requests? )

  • On Authority pages and Search pages, list only requests with a score of 0 or more unless explicitly asked otherwise via some UI widget (TBC)
  • Prominently highlight requests with a score of 1 or more
  • On Home page, list only recent requests with a score of 1 or more
  • On requests with a score of less than 0, include a banner that says "This request has been marked down by other site users because they feel it doesn't meet the [guidelines for a good request]" (I'd rather the trigger for such a notice was of a higher magnitude eg. -3 - RT)

• Incentives:

  • Privileges: privileges should be making multiple requests, the ability to vote, and the ability to comment
    • Users with negative points can't make any requests
    • Users with 0 points can only make one request per day
    • Users with 1 point can make up to 5 requests per day
    • Users with 20 points can make up to 20 requests per day
    • Users with 5 points can comment on other peoples' requests (can comment on their own from the start)
    • Users with 15 points can vote requests and comments up
    • Users with 30 points can vote requests and comments down
  • Points can be earned or lost by:
    • Filling in your profile (+1)
    • Having a request voted up (+5)
    • Having a request that's been voted up at least once enter a finished state (successful, unsuccessful) (+3)
    • Having comments voted up (+1)
    • Having requests voted down (-2)
    • Having comments voted down (-1)

• Seeding:

  • All current site admins have 200 points to start with
  • All site users who have previously made a comment get the privilege to make comments anyway
  • All requests with more than one person following them count as if they have 1 upvote
  • Anything else? Hard to think of ways to classify 100,000 existing requests!
    • Make a game to vote on requests
    • Definitely go through a list of "power users" (> 10 requests?) and classify their requests, so they can continue to use the site as before (e.g. more than one request per day, etc)
    • Review unsuspended users who have had requests or annotations hidden. Perhaps score them down for this, if the reason for hiding was their fault?

• Maintain current admin features eg. enabling a user to be suspended completely

• Would we want to highlight controversial requests, ie those many people upvote and many people also downvote?

Implementation

• Put some thought into designing user authorization system: roles, permissions, groups? (see Fine grained user roles and permissions. Should be able to grant privileges on a per-user basis): 1d
• Design the points earning data structure (around events, so we can explain them to users?): 1d
• Wireframe / design new UI components: 1d
  • earning new privileges (and losing them): flash for letting user know it's happened
  • encouraging earning new privileges: flash letting them know how to reach next level? (e.g. "if you earn [10 more points] you can post multiple requests per day"
  • badges or similar for listing privileges on user profile page
  • list points-earned-history for user profile page
  • flash for pointing out new features (e.g. highlighting new upvote/downvote buttons, etc)
  • upvote/downvote on requests: ensure it's obvious if/why you can't use it (yet)
  • unhiding downvoted requests on results page (or maybe they are still returned but very subtly compared with upvoted?)
  • asserting that a given request is demoted and making it clear how to find out why
• Implement base authorization system: 10d
  • implement API
  • admin backend for editing all permissions directly
  • integrate / refactor / migrate current admin permissions into new system
• Implement upvote/downvote for requests: 6d
• Implement request hiding / demoting / promoting: 3d
• Implement user-profile related changes (list of privileges, history of points earned, etc): 5d
• Integrate same into admin backend: 1d
• Implement "game" to help classify old requests, in order of recent-power-user-ness: 3d
• HTML mucking around: 3d
• Testing, bug fixing, iterating: 10d

Total: 44d