Closed cburgdorf closed 6 years ago
@ethereum/snake-charmers
I'm 👍
Can we write a script to do this which can be run against a repository using github API keys which will populate missing labels.
We can totally create a script that just airdrops the labels into a repo. However, for this specific repo I'd prefer to take the migration kind of approach and start by renaming existing labels because then all the issues that are currently labeled with existing labels will automatically end up with the correct new labels already applied.
This looks nice to me. Pretty well organized.
This is how it looks like now:
I kept "Bounty" and "Good First Issue" the way they were and think it is ok if these stand out. I also kept the sharding ones as they are mainly used by the researchers for now. We may revisit that once the dust settles.
We can easily push these labels into other repos using a tool such as https://github.com/jvandemo/copy-github-labels-cli.
Should we do that for ethpm and possibly others?
Closing this as the job seems done for this repo. Let's just discuss if / where to push these labels to (with slight changes regarding comp: xxx
) and then I'll happily take care of that.
What is wrong?
The way we currently use labels could be improved to enable better issue discovery.
How can it be fixed
I'd like to overhaul and unify the labels in this repo and potentially apply the same rules to other repos as well. This is inspired by https://github.com/machinelabs/machinelabs which in turn is inspired by https://github.com/angular/angular
Here are two secreenshots to give an idea what it could look like.
The gist of it goes like this.
We would create labels that fall into the following categories:
comp: <component-name>
(e.g.comp: p2p
,comp: trinity
,comp: benchmark
)type: <type>
(e.g.type: feature
,type: bug
,type: docs
)effort: <effort-estimate>
(e.g.effort: hours
,effort: days
,effort: weeks
)prio: <prio>
(e.g.prio: P0-critical
,prio: P1-urgent
,prio: P2-required
)PR-state: <state>
(e.g.PR-state: wip
,PR-state: needs review
,PR-state: blocked
)All the labels that fall into the same category share the same color (as seen on the screenshot). Nothing set in stone regarding concrete labels but I like the core idea of it. I'm happy to do the migration work we want to go that way.