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 _______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev