Design notes: Abilities (take 3)
Abilities (take 2) was an improvement, but there are still challenges. Abilities based on Wilson scores for all time can be hard to earn; that one declined flag three years ago will haunt you forever on communities where you can't overwhelm it with hundreds of accepted flags. They're also hard for users to understand. Wilson scores are great for sorting but not so great for making specific determinations. We need a better way.
We did some initial exploration in the GitHub issue for Abilities 2.0 (which is really take 3 I guess). We want to, for now, supplement the existing abilities with some new ones, and then we can look at migrating existing ones if the idea seems sound. That way we don't disrupt anything but we do add some new capabilities.
The big idea here is to count not all-time Wilson score but "at least X% positive of the last N". For example, at least 80% of the last 20 flags to unlock comment curation, or at least 90% of the last 10 suggested edits to unlock adding related links. Those numbers are just examples; as with existing abilities, these would be configurable. We'll call these new parameters "recency thresholds" (percent and number).
The existing abilities system actually has one ability that does not depend on Wilson scores: Moderator. It's treated as an ability and you could set score requirements (please don't), but it's this sort of un-Wilson ability nestled in there with all the others, using the same infrastructure for ability pages, listing abilities on the user profile, etc. It seems like we could hook into that.
Abilities are configured in db/seeds/abilities.yml with name, icon, summary, help text (linked file), and 3 score thresholds (can be ~). For example:
- name: Vote on Holds
internal_id: flag_close
icon: lock
summary: >
Vote to place questions and articles on hold, or vote to reopen posts
description: $FILE abilities/flag_close.html
post_score_threshold: 0.9 # min +16/-0
edit_score_threshold: ~
flag_score_threshold: 0.95 # min +36/-0To this we would add fields for the score/number pairs for each of post, edit, and flag. This would let us define new abilities, like this:
- name: Edit Related Posts
...
post_recent_number_threshold: 10
post_recent_percent_threshold: 80
edit_recent_number_threshold: 20
edit_recent_percent_threshold: 90
flag_recent_number_threshold: ~
flag_recent_percent_threshold: ~TBD: add all fields to all abilities, using ~ for the ones that don't apply, or define only the ones we're going to use for that ability? Regardless of which we do, no ability shall set both Wilson and threshold values. This is a hard requirement within type (post, edit, flag) and a strong preference across types; we might be able to do Wilson posts and recency flags, but doing so comprehensibly would be a challenge and we don't need that complexity.
Abilities are defined in the YAML file; this is necessary, not sufficient. The Qpixel code also needs to know how to apply abilities. For better or worse, we hardcode specific ability names in the controllers that apply them and the models that check them. This will all be true of abilities defined via recency thresholds, too -- the code that decides whether you can see recent comments would check a "curate_comments" ability.
There's code (and a scheduled job) to recalculate abilities, which ignores abilities that don't have any score thresholds to check (i.e. Moderator). We'll need to extend this code to recalculate recency-threshold-based abilities too. It appears that the recalc queue already supplies the necessary inputs, so we probably don't need to change anything about how that queue gets populated.
The existing abilities pages will need to work with these new ones too. I don't know what that means for the "how do I earn this?" part of the page that shows your progress. That seems to be pretty tied to scores for posts, edits, and flags; what do we need to do to support recency thresholds?
There is an admin page for setting the thresholds for the Wilson abilities. It looks like this:
We need something similar for setting the recency thresholds, something like this:
We do not want to combine Wilson and recency criteria in the same ability. Whether this means we should have two tables on the same page or try to combine everything in one is TBD.
The user mod tools "privileges" page supports granting, suspending, and revoking abilities (and other things like admin and staff status). That page needs to work with the new abilities too. It's possible that we would get this "for free"; I haven't looked at how that code works, specifically where it's getting its list.