Summary: Clean up GitHub Issue labels.
There are a couple of big problems with them.
They're not consistently set. Only people with access to the repository can add them (which is mostly just me, plus a few other regulars). The amount of work required to maintain them, however, should be minimized if possible.
They're not the same as what other stuff uses. GitHub treats the
good first issuelabel a special, but knows nothing about
E-easy, which predates it. Dependabot uses plain old
They're too complicated. The only labels that anyone really cares about are something like "issue accepted", the language labels, E-easy, and maybe a high priority ones. The other schemata is not necessary.
We should change this to just be a redirect:
If you're looking for an issue to work on, look for the
good first issue,
help wantedissues, indicating that any pull requests fixing the issue will definitely be merged.
high priority— indicates an issue that impacts a lot of existing users, has security implications, or otherwise needs done NOW
blocked— indicates a pull request that should not be merged, or an issue that cannot be solved yet
elixir— indicates an issue or pull request that primarily relies on Elixir code (sometimes added by dependabot to pull requests)
css— indicates an issue or pull request that primarily relies on CSS code
html— indicates an issue or pull request that primarily relies on HTML and IEX code
good first issue— indicates that the fix should be easy, self-contained, and that someone is ready to guide you through fixing it
mentored— indicates that someone is ready to guide you through fixing it
help wanted— indicates that the issue is definitely a bug or accepted feature
dependencies— indicates that a pull request updates dependencies (added by dependabot to pull requests)
duplicate— indicates that an issue or pull request was redundant
This does remove a few labels, particularly the ones distinguishing between feature requests and bugs. This is mostly to avoid pointless categorization between the two, but it does remove some help with prioritizing.
Rationale and alternatives
This design is mostly modeled after what repositories other than Rust do. In particular, several of the labels are based on the ones that Dependabot and GitHub treat specially, so that we get better integration with them.
We could, alternatively, keep the
featurelabels, if anybody actually uses them.
Dependabot only seems capable of replacing the
dependencieslabel, not of actually changing the language labels, so making it use the
L-labels seems impossible.
Bazillions of them. Here's some I knew about and had in mind.
Also, I expect a decent number of users to learn through GitHub's documentation, so let's try to follow their recommendations wherever possible:
We should probably look at the other repos in more detail. I would really like some numbers:
How often are particular labels sorted on?
How often are particular labels applied?
How are labels used? For dev priorities? For newbie discovery?
I can't think of any.