[Nix-dev] NixOS/Nixpkgs repository labels

[Nicolas Pierron]

Hi everybody,

I spent a day doing triage of newly created bugs and I think the
labels [1] of our repository are currently a big mess.  I think the
meaning of our labels are not clear for multiple reasons. I will take
a few examples to illustrate my point, and then propose a solution to
fix that.

1/ Currently our labels are color-coded but most of them have
inconsistent colors.  For example,

work-in-progress
duplicate
invalid
wontfix

are all dealing with the state of the pull request / issue, Or worse,
some times they have the same color but they do not express the same
thing

closure-size (topic)
needs-changelog (need)

2/ Our labels appear in alphabetic order, which makes it harder to
spot the status of a pull request. For example:

blocker (severity) will appear before nixos (topic), while security
(serverity) appears after.


On the other side, if we look at other projects which have a lot of
contributions on Github, such as rust [2], they are using a single
prefix letter to force the ordering of the labels and use identical
colors for each group.

I think this kind of organization makes it clear that labels are
missing or not, and thus easier to spot the completion of pull request
/ issues based on the remaining set of color coded labels.  On the
other hand, I wonder if a gradient of color for severity / completion
might not be better.

I suggest that we should reorganize our labels as follow (with prefix
letters to keep the ordering of categories).

severity: (red) [one per issue/pr]

blocker
security
mass-darwin-rebuild
mass-rebuild

kind: (light-blue) [one per issue/pr]

bug
question
enhancement

skill: (pink) [one]

good-first-bug
trivial
sprintable

topic: (sticky notes color) [one or many per issue/pr]

closure-size
darwin
documentation
gnome3
grsecurity
haskell
kde
kernel
nixos
darwin
non-nixos
python

status: (light gray) [one per issue/pr]

* new
work-in-progress
duplicate
invalid
wontfix

has: (green) [one or many per issue/pr]

documentation
* changelog
new-package
update-package
* new-module
* update-module
* clean-up

needs: (light-red) [one or many per issue/pr]

feedback
changelog
documentation
* new-module
* new-package
* update-module
* update-package


If people agree that this is better than what we have today, I will
proceed and rename the labels and reset the color as described above.
The idea of the above is that each issue / pull request should have at
least one of each label, and the last 2 categories are used to figure
out in a simple color-coded way if the issue / pull-request still
needs some work to be done before being merged. (thus if there is some
light-red, do not land)

What do you think?

[1] https://github.com/NixOS/nixpkgs/labels
[2] https://github.com/rust-lang/rust/labels

-- 
Nicolas Pierron
http://www.linkedin.com/in/nicolasbpierron - http://nbp.name/