Simplify bors-ng/bors-ng's label system

Development Approved RFCs
#1

Summary: Clean up GitHub Issue labels.

I allow this RFC document to be modified and redistributed under the terms of the Apache-2.0 license, or the CC-BY-NC-SA 3.0 license, at your option.

Motivation

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 issue label a special, but knows nothing about E-easy, which predates it. Dependabot uses plain old elixir and javascript labels, which are redundant with L-elixir and L-javascript. Doing a bunch of bespoke configuration is annoying, and it would be better to integrate with others' defaults.

  • 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.

Guide-level explanation

We should change this to just be a redirect:

Bors Starters - Whet your appetite with these easy tasks :arrow_right: Contribute to bors-ng/bors-ng · GitHub

Also:

If you're looking for an issue to work on, look for the good first issue, mentored, and help wanted issues, indicating that any pull requests fixing the issue will definitely be merged.

Reference-level explanation

  • 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
  • javascript — indicates an issue or pull request that primarily relies on JavaScript code (sometimes added by dependabot to pull requests)
  • 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

Drawbacks

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

Prior art

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:

Unresolved questions

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?

Future possibilities

I can't think of any.

#2

Seems fine to me.

#3

crickets

Okay. This RFC is entering the Final Comment Period. It will probably be accepted. Speak now, or forever hold your peace!

#4

This topic was automatically closed after 13 days. New replies are no longer allowed.