In the discussion on design-independent graduation, which stemmed into a more general discussion on the graduation process, it occurred to me that there's an obvious solution to the reputation-change problem: make reputation thresholds scale automatically to meet demand.
This isn't a solution without its problems, though, so I'd like to see if we can figure out how to make it work. This isn't a working feature-request quite yet; it's a discussion on how to make (or whether it's possible to make) the feature request work.
When I say 'automatically scaling reputation thresholds,' I imagine a system wherein edit, close vote, review queues, tag wiki, trusted user, possibly even downvoting, etc. privileges scale automatically to meet the demands of the site. This is a complicated proposal with a lot of moving parts, so bear with me for a bit.
Why do we want this at all?
Yes, it's a complicated proposal. However, it solves a couple major problems:
- It improves site graduation. Instead of sites experiencing a huge privilege shock when they graduate, they'd experience a nominal transition. (Remember that when a site graduates, a lot of users lose the privileges they've already been granted.)
- It improves the process of site growth. From private beta into public beta, there are (often long) interim periods where the community moderation needs are not being fulfilled. This can result in some bad community standards which need to be cleaned up later, but would be better addressed at the outset.
- It brings on active community moderators only as necessary to fill the needs of the site. When too many people are afforded unrestricted privileges, things can occasionally get a little awry, and it can be hard to spot. By having a smaller influx of privileged users, not only will those users have more experience but they'll also have an easier time learning by example from existing reviewers.
Obviously these things are a little less effective on larger sites, but in a lot of respects, larger sites are a lot more chaotic than smaller sites, so that's probably to be expected.
Here are some of the major points about such a system, and some of the unsolved problems I've been pondering:
My initial suggestion was that once a privilege is granted, it isn't revoked. The reason I had suggested this was to avoid confusing users.
However, it was pointed out by HDE and Scimoster that this might not be the best approach, as the base of users able to review should change to match who's currently active on the site. Scimonster suggested a notification when you're about to lose a privilege, which makes sense to me.
Consequently, if you stop being active on the site, you'll lose the associated privileges that are afforded at your reputation level.
That also avoids the problem wherein there is a potential to have users late into the site's existence with long-term privileges and very little reputation. Granted, the only way they could end up there is by being inactive, which is a self-solving problem.
- Heuristics need to be developed for what the "demand" for each privilege actually means. For review queues, this is easy: lower the threshold until enough people have the privilege to cover the queue. For voting, closing, and edits, it's a little more complicated, and I'm not sure how to do it.
- Consideration of inactive users: As sites age, they develop a larger base of less-active users. A general metric for the activity of each user with regards to each automatically-scaling action needs to be created and balanced. This has to feed into whatever algorithm is determining how many users to add; it's not just about how many users there are, but how active those users are at moderation.
- Minimum thresholds need to be set. There has to be a minimum reputation for each privilege, otherwise a site like Stack Overflow would set the close-votes queue to 10 reputation. Those could probably stay the same.
Finally, this last one is the most significant and hardest to solve:
The raw reputation thresholds need to be presented in a non-confusing way. I'm not sure how to accomplish this, and it's a major holding point on this idea.
A couple ideas which occur to me are to hide reputation thresholds for privileges entirely, presenting solely their order, or alternately to show that the top M users have been granted a privilege.
I do realize this needs work, which is why this isn't a feature-request yet. I'm trying to figure out how to solve these problems here, not proposing it as a feature request or full solution.
The task is a bit too much for me to piece together in my head, so please feel free to answer with whatever feedback and information you think is necessary to make this work.