Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Blog
Q&A
Posts Tags Edits
Ask Question

Welcome to Codidact Meta!

Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.

Post History

81%
+7 −0
Q&A Scoring System for Trust Level Requirements

Update: Based on this question, this answer, feedback on both, the original spec for trust levels, and lots of discussion in chat, I've posted a new specification for privileges on the wiki. Key d...

posted 4y ago by Monica Cellio‭  ·  edited 4y ago by Monica Cellio‭

Answer
#5: Post edited by user avatar Monica Cellio‭ · 2020-07-30T03:05:38Z (over 4 years ago)
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N top-level posts (questions, articles) per day (3ish, if we go with what we worked out in the previous spec)
  • - post any number of answers per day (within rate limits)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • **Question:** Should downvotes have a higher requirement than upvotes? That is, should we insert a "Downvote" privilege with a criterion of "higher score for posts"?
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
  • **Update:** Based on this question, this answer, feedback on both, the original spec for trust levels, and lots of discussion in chat, I've posted a new [specification for privileges](https://github.com/codidact/docs/wiki/Functional-Spec:-Granting-Privileges-(Abilities)-(Take-2)) on the wiki. Key differences:
  • - All privileges are derived from scores based on your posts, suggested edits, and/or flags. Thresholds remain configurable per-site.
  • - More decoupling (the old TL3 was overloaded and that was a symptom).
  • - We've nailed down some interactions with other site features (categories, rate limits, ability suspensions).
  • ----
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N top-level posts (questions, articles) per day (3ish, if we go with what we worked out in the previous spec)
  • - post any number of answers per day (within rate limits)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • **Question:** Should downvotes have a higher requirement than upvotes? That is, should we insert a "Downvote" privilege with a criterion of "higher score for posts"?
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
#4: Post edited by user avatar Monica Cellio‭ · 2020-07-16T21:07:06Z (over 4 years ago)
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N questions per day (3ish, if we go with what we worked out in the previous spec)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • **Question:** Should downvotes have a higher requirement than upvotes? That is, should we insert a "Downvote" privilege with a criterion of "higher score for posts"?
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N top-level posts (questions, articles) per day (3ish, if we go with what we worked out in the previous spec)
  • - post any number of answers per day (within rate limits)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • **Question:** Should downvotes have a higher requirement than upvotes? That is, should we insert a "Downvote" privilege with a criterion of "higher score for posts"?
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
#3: Post edited by user avatar Monica Cellio‭ · 2020-07-16T21:02:38Z (over 4 years ago)
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N questions per day (3ish, if we go with what we worked out in the previous spec)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N questions per day (3ish, if we go with what we worked out in the previous spec)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • **Question:** Should downvotes have a higher requirement than upvotes? That is, should we insert a "Downvote" privilege with a criterion of "higher score for posts"?
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
#2: Post edited by user avatar Monica Cellio‭ · 2020-07-15T00:20:17Z (over 4 years ago)
updated to respond to comments
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. Communities can still modify the constants. *I have not yet specified thresholds*, e.g. how high the such-and-such score needs to be; I'm going to leave that to the more mathematically-inclined. Let's see if the approach works before we dive into that.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N questions per day (3ish, if we go with what we worked out in the previous spec)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize. We also lined those privileges up in a sequence, *ordered* trust "levels". It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.
  • We already had a problem brewing at Trust Level 3, which says:
  • > Requirements:
  • > At least 50 accepted flags.
  • At least 50 accepted edits.
  • At least 15 well-received questions/answers.
  • >
  • > There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.
  • I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other? On the dev team I've already brought up that we need a 3A and 3B.
  • But even that doesn't seem quite right. We're trying to pack too much into a few bundles. People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags. Yeah, I think I just jammed tags in there because they had to go *somewhere*.
  • Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be. Let's take advantage of that.
  • My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows.
  • ----
  • Privileges are earned independently. For each one I list the factor to score and the resulting abilities. I do not specify what the score threshold *is*; we would need to work out defaults for these that emulate our original trust-level spec, but also, sites could change these thresholds.
  • Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit. So if we set the thresholds right we don't also need to specify minimum numbers of events.
  • Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc. Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc. I think we should defer that until after we have privileges in use for a while so we can collect data.
  • Anybody (no privilege required) can:
  • - flag (can be revoked; see note)
  • - suggest edits (can be revoked; see note)
  • - suggest a duplicate question
  • - post N questions per day (3ish, if we go with what we worked out in the previous spec)
  • - vote on answers to own questions
  • - comment on answers to own questions
  • - comment on own posts
  • Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities. I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.
  • Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
  • - Criteria: score for posts (all types, all categories)
  • - Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere
  • Privilege: Edit
  • - Criteria: score for accepted edits
  • - Can: edit directly, review edits
  • Privilege: Edit tags
  • - Criteria: a *higher* score for accepted edits
  • - Can: create tags, create tag descriptions
  • Privilege: Vote to close or keep open
  • - Criteria: score for posts (to demonstrate some site familiarity) *and* score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
  • - Can: vote to close, vote to open/keep open (review close votes)
  • Privilege: Review flags
  • - Criteria: score for posts *and* a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
  • - Can: handle flags except "other/for moderators" (which are reserved for moderators)
  • Privilege: Moderator
  • - Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
  • - Can: do all the things, pretty much
  • I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with. These "stray" privileges are:
  • - deleting posts (outside of flag-handling)
  • - locking posts
  • We could initially make these moderator privileges, though I'd like to find a way to push them down to the community too.
  • We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development. For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.
  • ----
  • Responses to questions and concerns:
  • - I added post score as an additional criterion for close votes and handling flags, so people have to have had some constructive first-class activity on the site to moderate in these ways. I did *not* do so for editing, because if you've actually had enough suggested edits approved, that's already a good indicator that you can be trusted to edit.
  • - Categories can set posting and viewing restrictions based on old-style trust levels. I would suggest changing this to specify the privilege(s) needed. A site that wants to minimally restrict a category could require "remove new-user restrictions"; one that wants a higher bar for its blog could require one of "edit" or "vote to close". For the meta blog category (currently set at TL5), the posting requirement would be "moderator". Category configuration is infrequent and restricted to admins, so if we create this *system* I'm not too worried about people messing it up.
  • - I have not built in any score decay over time. That's something we should look at, but I propose to look at it *separately*. It'll be a while before it will be relevant, so let's first get some practical experience with the system without decay and then decide what to do there.
  • - Users do not need to do these calculations, though they're free to check our math. We would provide a clear indication of progress, whether graphically as suggested in the question or textually (or, probably, both).
  • - New sites should be able to automatically grant certain privileges (such as "remove new-poster restrictions") and/or temporarily lower the thresholds, so that they are not unduly hindered in getting up and running.
#1: Initial revision by user avatar Monica Cellio‭ · 2020-07-09T03:01:13Z (over 4 years ago) 
Our original trust levels grew out of long discussions on the forum, where we tried to work out baseline thresholds for different privileges and identified where communities could customize.  We also lined those privileges up in a sequence, *ordered* trust "levels".  It all ended up being a little complicated, and with apologies to the team member who has already put a lot of work into writing documentation about them (at my request!)... I think you have a really good point here and I'd like to revisit them.

We already had a problem brewing at Trust Level 3, which says:

> Requirements:  
> At least 50 accepted flags.  
At least 50 accepted edits.  
At least 15 well-received questions/answers.  
>
> There was discussion somewhere of an either/or approach to flags and edits, but I can't find it right now.

I wrote, or compiled, those words, and when I went back to look at it later, I asked myself: what do flags and edits have to do with each other?  On the dev team I've already brought up that we need a 3A and 3B.

But even that doesn't seem quite right.  We're trying to pack too much into a few bundles.  People at this trust level, according to our spec, get these privileges: edit directly, review edits, vote to close, create tags.  Yeah, I think I just jammed tags in there because they had to go *somewhere*.

Not *everything* on the site can be "scored" in the way the question proposes, but posts (up/down votes), suggested edits (accept/reject), and flags (accept/reject) can be.  Let's take advantage of that.

My radical, haven't-consulted-with-anybody-else-on-the-team proposal for a revamp of trust levels follows. 

----


Privileges are earned independently.  For each one I list the factor to score and the resulting abilities.  Communities can still modify the constants.  *I have not yet specified thresholds*, e.g. how high the such-and-such score needs to be; I'm going to leave that to the more mathematically-inclined.  Let's see if the approach works before we dive into that.

Note: higher scores automatically require more events; it's impossible to get an edit score of 0.9 on a single edit.  So if we set the thresholds right we don't also need to specify minimum numbers of events.

Also note: assume there are daily rate-limits on most things -- comments, votes, flags, etc.  Eventually we could have rate limits scale with your activity/score -- if you have a great track record with flags you get more, etc.  I think we should defer that until after we have privileges in use for a while so we can collect data.


Anybody (no privilege required) can:
- flag (can be revoked; see note)
- suggest edits (can be revoked; see note)
- suggest a duplicate question
- post N questions per day (3ish, if we go with what we worked out in the previous spec)
- vote on answers to own questions
- comment on answers to own questions

Note: to prevent floods of bad flags/suggestions, we could set a score threshold at which you temporarily *lose* these abilities.  I think it's important that anybody be able to participate in these ways by default, even though we don't know anything about you -- but if you build up a bad record, that's different.


Privilege: Remove new-poster restrictions (usually the first one earned but doesn't have to be!)
- Criteria: score for posts (all types, all categories)
- Can: make any number of posts, subject to rate-limiting, daily thresholds, and category restrictions; upvote and downvote anywhere; comment anywhere

Privilege: Edit
- Criteria: score for accepted edits
- Can: edit directly, review edits

Privilege: Edit tags
- Criteria: a *higher* score for accepted edits
- Can: create tags, create tag descriptions

Privilege: Vote to close or keep open
- Criteria: score for flags on posts (all flags, not just "should be closed" flags; comment flags do not count)
- Can: vote to close, vote to open/keep open (review close votes)

Privilege: Review flags
- Criteria: a *higher* score for flags (posts and comments, unless we decide these should be separate privileges)
- Can: handle flags except "other/for moderators" (which are reserved for moderators)

Privilege: Moderator
- Criteria: be chosen by the community :-) (or be appointed as a pro-tem until the community is ready to choose its own)
- Can: do all the things, pretty much


I've had trouble fitting some actions into this score-based scheme, which might be how our trust levels became somewhat eclectic to begin with.  These "stray" privileges are:

- deleting posts (outside of flag-handling)
- locking posts

We have [use cases and wireframes](https://github.com/codidact/feature-development/projects/1) for many of these activities, in various stages of development.  For example, you might have noticed that I separated "suggest duplicate" from "close", because on Codidact those will be two different things -- poke around in the "wireframes for review" column there, and sorry for the clutter.