-
Notifications
You must be signed in to change notification settings - Fork 7
Functional Spec: Granting Privileges (Abilities) (Take 2)
After we created the spec for trust levels and started to think about how to implement it, we realized we didn't get it quite right. There was also this Meta discussion. We realized we needed to decouple some things and not assume that there is one sequential path. The result is this new spec.
Users earn privileges (or abilities) based on success in related activities on a site. To determine "success" in a related activity, we use the same idea of Wilson scores that we use for ranking posts. An edit privilege, for example, plugs "accepted edits" and "rejected edits" into the formula in place of "upvotes" and "downvotes".
A user who has a privilege has that privilege on all categories on the site, except that a category definition can restrict posting and visibility. (See "Category Restrictions".)
Earning a privilege depends on one or more score types reaching designated thresholds. (Usually a privilege depends on a single score type.)
The same score type can contribute to more than one privilege at different thresholds. A series of privileges all based on the same score type is a privilege family.
We define the following score types. For each type, we list the name (used in the definitions of privileges) and the positive and negative inputs to the Wilson formula.
- Edit score: accepted suggested edits and rejected suggested edits
- Flag score helpful flags and declined flags, posts only (not comment flags)
- Post score (all posts): number of posts with Wilson score > 0.6 and number of posts with Wilson score <= 0.4 (to do: check that these values are reasonable; the goal is to not be volatile based on the first vote or two but wait for a little more consensus to emerge)
(In principle we could add post score, specific type, but we do not currently have any planned privileges that would use it.)
A site specifies the set of categories from which events of these types are drawn when computing scores. A site might, for example, want to exclude Meta. This category list applies to all criteria for all privileges; a site can't say that edit score is site-wide but post score is Q&A-only.
Most of these inputs are immutable; an edit suggestion, once accepted, never becomes unaccepted. A flag, once declined, does not become helpful. The exception to this is post scores; the number of posts above/below the Wilson baseline changes as votes are registered. This will probably be our most expensive calculation.
Also, notice that post score is based on the number of posts that are or aren't well-received. The actual scores of those posts do not matter. A post with a Wilson score of 0.65 contributes the same weight to privilege evaluation as one with a Wilson score of 0.99. Vote distortion from one post hitting the Reddit jackpot cannot give a user a fistful of new privileges.
Grants are not immediate. Checks for new privileges are run in batches, possibly distributed through the day and divided up by privilege (e.g. run all the "Edit" checks at 02:00, all the "Vote on Holds" checks at 05:00, etc).
If practical, the check for "Participate Generally" should run more frequently.
For privileges in privilege families, for each user we only check the lowest one not already earned. There's no point in checking privileges for which the "prerequisites" haven't yet been earned. (This means that if you somehow manage to earn more than one related privilege at the same time, you might not receive them at the same time.)
Checks are for privileges the user doesn't already have. The periodic job checks for possible grants; it doesn't re-evalaute users who already have a privilege to see if it should be revoked. Moderators who want to block a user from performing certain activities can do so through targeted suspensions.
Design recommendation: for each user we store daily totals for the up and down values (accepted edits, rejected edits, etc). This has two benefits: first, if a user has no new events, there is no need to run the check. Second, it makes aggregation easier over time, counting one value per day instead of one value per event.
Privileges interact with certain other site features:
By default, a user has an ability anywhere on the site. However, a category might be restricted for both posting and visibility. For example, posting to the Meta blog is restricted to moderators. For a hypothetical example, a Writing Critiques category could restrict visibility to keep posts out of Google. For both restrictions, the category definition specifies a set of privileges, any one of which satisfies the restriction. (The UI can treat this as a multi-select, as for allowed post types.)
Moderators can suspend users either completely or from specific activities (editing without review, commenting, posting, voting to close, etc). Suspensions override a user's current privilege and are checked first.
Because there is no automatic revocation of privileges, the system should generate moderator alerts for certain conditions, such as too many declined flags. Specifying these alerts is beyond the scope of this feature.
Most or all activities will have daily limits and velocity limits. All privilege grants are to be read in the context of "within these limits".
New sites have a bootstrapping problem: new users haven't yet earned the needed privileges, but somebody has to be able to create tags, handle flags, make and review edits, and so on. There will be a configuration for this, so they can be handled as a group instead of communities having to adjust them individually. When a site has an established base, "new site" mode can be turned off. Some users might lose privileges at that time due to the raised thesholds.
For each privilege, we specify the score type(s) and the resulting abilities. A privilege specification also requires a score threshold for each score type (the score you must reach with that score type); we will provide defaults and some charts to help communities make informed decisions, and communities can change the score thresholds.
Score: N/A
Grants:
- flag
- suggest edits
- suggest a duplicate question
- post 3 top-level posts (questions, articles) per day
- post any number of answers per day
- vote on answers to own questions
- comment on answers to own questions
- comment on own posts
Score: Post score (calibrated to around +5/-0 or nearby)
Grants:
- post any number of top-level posts per day
- upvote anywhere
- downvote anywhere
- comment anywhere
Score: Edit score
Grants:
- edit posts directly
- review suggested edits
Score: Edit score (higher threshold than Edit Posts)
Grants:
- create tags
- create tag descriptions
Score: Flag score and Post score (much higher threshold than Participate Generally)
Grants:
- vote to put question on hold
- review hold votes / vote to keep open
Score: Flag score (higher threshold than Vote on Holds) and Post score (same as Vote on Holds?)
Grants:
- see and handle certain flags on posts and comments (excludes flags against own content and "other / for moderator attention" flags; need to review flag types to see if anything else should be excluded)
- temporarily lock posts
- unlock posts that were not locked by moderators
- vote to delete posts (handling flags can, separately, lead to deletion)
- vote to undelete posts (might be some restrictions TBD, like not posts with rude flags)
Score: N/A (elected by community, or temporarily appointed)
Grants:
- all other grantable privileges, regardless of whether individually earned
- additional mod powers (beyond the scope of this spec)