[Nix-dev] NixOS/Nixpkgs repository labels

[Shea Levy]

No opinion on the specifics of colors/categories, but +1 for the 
general idea.

On 2015-11-21 19:59, Nicolas Pierron wrote:
> 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