Proposed Issue Label Scheme

[christophermaier]

In order to better triage issues and provide some guidance for would-be contributors, I'd like to propose that we adopt an issue labeling scheme like the ones used by the Rust project, the Habitat project, and the Kubernetes project.

Reasoning for this scheme (for the Habitat project, at least) can be found here and here

For Habitat, we use repo_man to manage the labels in an automated way. One nice thing about this tool is that it operates across multiple repositories, meaning that we could maintain a consistent set of labels across all the Cog-related repositories. Additionally, it is driven from a configuration file, meaning that we can manage our scheme as code, perhaps in this very repository.

Below is a list of proposed labels that we could use. Please suggest additional labels as you see fit:

• area/executor
• area/adaptor
• area/adaptor/slack
• area/adaptor/hipchat
• area/api
• area/commands
• area/rules
• area/relay
• area/build (e.g. CI, release tooling, etc)
• area/testing (things to help command authors test easily)
• area/documentation
• effort/easy
• effort/medium
• effort/difficult
• type/bug
• type/chore
• type/feature
• language/elixir
• language/go
• language/ruby
• language/python

In addition to the "scoped" labels above, there are probably a few general labels we could use, as well:

• help-wanted
• needs-discussion
• waiting-for-response

If we adopt this scheme, we should also document the intention and meaning of each label.

[christophermaier]

@operable/maintainers What do you think?

[ohaiwalt]

this is great! One thing we would need to look out for using repo_man from multiple workstations would be someone not pulling changes from the community repo if we're keeping a central record of labels could have an effect across an entire repository or set of repositories. Somewhat mitigating that, I wouldn't expect the label set to change much once we have something in place.

LGTM.

[christophermaier]

@ohaiwalt Yeah, I wasn't anticipating there being a lot of churn once the initial additions were made (one never knows, though). I figured that deciding to run that tool look something like:

• "Oh, we should add label X to the repos... @ohaiwalt, can you take care of that?"
• "Yeah, cool"

😄

[ohaiwalt]

If I'm understanding repo_man correctly it's something that we would run once first to migrate labels to desired state, and then also continually in order to add labels to new issues created. The second instance was where I thought we might run into the issue.

1. I make a requested/PR'd change
2. Two weeks later someone else runs repo_man without first grabbing the updated toml, and resets all the changed labels.

Does that sound correct?

[christophermaier]

@ohaiwalt Ah, I see what you're saying. Yeah, that could potentially be an issue, but I feel like it could be mitigated with communication and/or a bit of scripting (e.g., you don't run repo_man directly, you run it in a script that does a pre-flight check that your local Git repo is in sync with the current master branch).

Or you have some kind of mergebot run it after the PR merges, or you write a Cog command to do it 😉

[jesselang]

I like where this is headed! I guess I'd love to see us use Cog for our repo management at some point. Another way we can dogfood.