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
Currently, we're planning to implement a system for user privileges based on Trust Levels. These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [these requir...
#3: Post edited
by
Sigma
·
2020-06-28T23:39:22Z (over 4 years ago)
Currently, we're planning to implement a system for [user priviledges based on Trust Levels](https://github.com/codidact/docs/wiki/User-Privileges).- These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [[these requirements]](https://docs.google.com/spreadsheets/d/1RzHFAHEm2XEnUpkNVocAOHw5MNi3ABD8FxIIuTpLn_M/edit#gid=0) are generally of the form e.g. "at least 50 accepted edits".
- Continuing this example, what this *doesn't* take into account is the number of *rejected* edits - if a user has 50 accepted edits out of a total of 200 suggested edits (i.e. has 150 rejected edits), then I for one would be hesitant to give that user the ability to directly edit.
- At this point, it appears that the solution would be to come up with some method of figuring out the number of accepted edits in order to 'balance out' the rejected edits, or having some system of '> x accepted edits and < y rejected edits within the past [some time-scale]'. However, *we're already using* a system that estimates the probability of a successful outcome of a binary choice (e.g. 'accept' and 'reject'), given some data. That is, our [post scoring system](https://github.com/codidact/docs/wiki/Functional-Specification#votes-and-scores).
- I'm therefore proposing that we **use this same scoring system to 'score' each individual requirement in the Trust Levels**: (accepts + N) / (accepts + rejects + 2N), for N=2. The requirement of 'at least 50 accepted edits' could then be replaced with a requirement of 'an edit-score of at least 0.95'. This could similarly be applied to create a user post-score, where 'accepts' is the total number of upvotes across all posts and 'rejects' is the total number of downvotes.
- As we're planning on getting rid of rep and not replacing it with any number (other than trust levels), an individual user's score should perhaps only be visible to that user. For easy visualisation, it could also be displayed in a radar chart such as
- 
- Currently, we're planning to implement a system for [user privileges based on Trust Levels](https://github.com/codidact/docs/wiki/User-Privileges).
- These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [[these requirements]](https://docs.google.com/spreadsheets/d/1RzHFAHEm2XEnUpkNVocAOHw5MNi3ABD8FxIIuTpLn_M/edit#gid=0) are generally of the form e.g. "at least 50 accepted edits".
- Continuing this example, what this *doesn't* take into account is the number of *rejected* edits - if a user has 50 accepted edits out of a total of 200 suggested edits (i.e. has 150 rejected edits), then I for one would be hesitant to give that user the ability to directly edit.
- At this point, it appears that the solution would be to come up with some method of figuring out the number of accepted edits in order to 'balance out' the rejected edits, or having some system of '> x accepted edits and < y rejected edits within the past [some time-scale]'. However, *we're already using* a system that estimates the probability of a successful outcome of a binary choice (e.g. 'accept' and 'reject'), given some data. That is, our [post scoring system](https://github.com/codidact/docs/wiki/Functional-Specification#votes-and-scores).
- I'm therefore proposing that we **use this same scoring system to 'score' each individual requirement in the Trust Levels**: (accepts + N) / (accepts + rejects + 2N), for N=2. The requirement of 'at least 50 accepted edits' could then be replaced with a requirement of 'an edit-score of at least 0.95'. This could similarly be applied to create a user post-score, where 'accepts' is the total number of upvotes across all posts and 'rejects' is the total number of downvotes.
- As we're planning on getting rid of rep and not replacing it with any number (other than trust levels), an individual user's score should perhaps only be visible to that user. For easy visualisation, it could also be displayed in a radar chart such as
- 
#2: Post edited
by
Mithrandir24601
·
2020-06-19T19:02:26Z (over 4 years ago)
- Currently, we're planning to implement a system for [user priviledges based on Trust Levels](https://github.com/codidact/docs/wiki/User-Privileges).
- These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [[these requirements]](https://docs.google.com/spreadsheets/d/1RzHFAHEm2XEnUpkNVocAOHw5MNi3ABD8FxIIuTpLn_M/edit#gid=0) are generally of the form e.g. "at least 50 accepted edits".
- Continuing this example, what this *doesn't* take into account is the number of *rejected* edits - if a user has 50 accepted edits out of a total of 200 suggested edits (i.e. has 150 rejected edits), then I for one would be hesitant to give that user the ability to directly edit.
At this point, it appears that the solution would be to come up with some method of figuring out the number of accepted edits in order to 'balance out' the rejected edits, or having some some system of '> x accepted edits and < y rejected edits within the past [some time-scale]'. However, *we're already using* a system that estimates the probability of a successful outcome of a binary choice (e.g. 'accept' and 'reject'), given some data. That is, our [post scoring system](https://github.com/codidact/docs/wiki/Functional-Specification#votes-and-scores).- I'm therefore proposing that we **use this same scoring system to 'score' each individual requirement in the Trust Levels**: (accepts + N) / (accepts + rejects + 2N), for N=2. The requirement of 'at least 50 accepted edits' could then be replaced with a requirement of 'an edit-score of at least 0.95'. This could similarly be applied to create a user post-score, where 'accepts' is the total number of upvotes across all posts and 'rejects' is the total number of downvotes.
- As we're planning on getting rid of rep and not replacing it with any number (other than trust levels), an individual user's score should perhaps only be visible to that user. For easy visualisation, it could also be displayed in a radar chart such as
- 
- Currently, we're planning to implement a system for [user priviledges based on Trust Levels](https://github.com/codidact/docs/wiki/User-Privileges).
- These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [[these requirements]](https://docs.google.com/spreadsheets/d/1RzHFAHEm2XEnUpkNVocAOHw5MNi3ABD8FxIIuTpLn_M/edit#gid=0) are generally of the form e.g. "at least 50 accepted edits".
- Continuing this example, what this *doesn't* take into account is the number of *rejected* edits - if a user has 50 accepted edits out of a total of 200 suggested edits (i.e. has 150 rejected edits), then I for one would be hesitant to give that user the ability to directly edit.
- At this point, it appears that the solution would be to come up with some method of figuring out the number of accepted edits in order to 'balance out' the rejected edits, or having some system of '> x accepted edits and < y rejected edits within the past [some time-scale]'. However, *we're already using* a system that estimates the probability of a successful outcome of a binary choice (e.g. 'accept' and 'reject'), given some data. That is, our [post scoring system](https://github.com/codidact/docs/wiki/Functional-Specification#votes-and-scores).
- I'm therefore proposing that we **use this same scoring system to 'score' each individual requirement in the Trust Levels**: (accepts + N) / (accepts + rejects + 2N), for N=2. The requirement of 'at least 50 accepted edits' could then be replaced with a requirement of 'an edit-score of at least 0.95'. This could similarly be applied to create a user post-score, where 'accepts' is the total number of upvotes across all posts and 'rejects' is the total number of downvotes.
- As we're planning on getting rid of rep and not replacing it with any number (other than trust levels), an individual user's score should perhaps only be visible to that user. For easy visualisation, it could also be displayed in a radar chart such as
- 
#1: Initial revision
by
Mithrandir24601
·
2020-06-19T19:00:16Z (over 4 years ago)
Currently, we're planning to implement a system for [user priviledges based on Trust Levels](https://github.com/codidact/docs/wiki/User-Privileges). These are of the form of 'if you satisfy [these requirements], you get [these perks]', where [[these requirements]](https://docs.google.com/spreadsheets/d/1RzHFAHEm2XEnUpkNVocAOHw5MNi3ABD8FxIIuTpLn_M/edit#gid=0) are generally of the form e.g. "at least 50 accepted edits". Continuing this example, what this *doesn't* take into account is the number of *rejected* edits - if a user has 50 accepted edits out of a total of 200 suggested edits (i.e. has 150 rejected edits), then I for one would be hesitant to give that user the ability to directly edit. At this point, it appears that the solution would be to come up with some method of figuring out the number of accepted edits in order to 'balance out' the rejected edits, or having some some system of '> x accepted edits and < y rejected edits within the past [some time-scale]'. However, *we're already using* a system that estimates the probability of a successful outcome of a binary choice (e.g. 'accept' and 'reject'), given some data. That is, our [post scoring system](https://github.com/codidact/docs/wiki/Functional-Specification#votes-and-scores). I'm therefore proposing that we **use this same scoring system to 'score' each individual requirement in the Trust Levels**: (accepts + N) / (accepts + rejects + 2N), for N=2. The requirement of 'at least 50 accepted edits' could then be replaced with a requirement of 'an edit-score of at least 0.95'. This could similarly be applied to create a user post-score, where 'accepts' is the total number of upvotes across all posts and 'rejects' is the total number of downvotes. As we're planning on getting rid of rep and not replacing it with any number (other than trust levels), an individual user's score should perhaps only be visible to that user. For easy visualisation, it could also be displayed in a radar chart such as 