Hugo: Proposal: Redefine GitHub issue label set

[moorereason]

We have too many issue labels in GitHub. This proposal aims to redefine the label set.

Goals

1. Reduce the number of labels.
2. Shorten labels, if possible.
3. Urlize labels ("won't fix" becomes "wont-fix")

Proposed Label Set

• is/bug
• is/docs
• is/duplicate
• is/enhancement
• is/proposal
• is/wishlist
• needs/review
• needs/user-feedback
• status/already-works
• status/cant-reproduce
• status/please-contribute
• status/upstream
• status/wont-fix

Changes

| Open | Old (30 labels) | New (13 labels) |
| ---- | ---------------------------- | --- |
| 1 | area/assets | - |
| 3 | area/cli | - |
| 4 | area/content | - |
| 3 | area/cpu-architectures | - |
| 0 | area/helpers | - |
| 1 | area/nodes | - |
| 2 | area/server | - |
| 7 | area/templates | - |
| 0 | area/website | - |
| 3 | exp/beginner | - |
| 5 | exp/expert | - |
| 5 | exp/intermediate | - |
| 36 | kind/bug | is/bug |
| 5 | kind/discussion | - |
| 28 | kind/docs | is/docs |
| 155 | kind/enhancement | is/enhancement |
| 0 | kind/question | - |
| 26 | kind/wishlist | is/wishlist |
| 0 | priority/P0 | - |
| 1 | priority/P1 | - |
| 3 | priority/P2 | - |
| 0 | status/already works | status/already-works |
| 2 | status/can't reproduce | status/cant-reproduce |
| 0 | status/duplicate | is/duplicate |
| 3 | status/in progress | - |
| 6 | status/pending review | needs/review |
| 1 | status/pending user feedback | needs/user-feedback |
| 23 | status/please contribute | status/please-contribute |
| 10 | status/upstream | status/upstream |
| 0 | status/won’t fix | status/wont-fix |
| - | - | is/proposal |

Notes

1. Out of the 367 open issues, removing these labels would only potentially affect 46 issues (sum of labels counts above).
2. area/* labels are not used much and feel noisy. Update issue title instead.
3. exp/* labels are out. Use status/please-contribute instead.
4. kind/discussion is out. Use is/wishlist or is/proposal and direct extended discussions to forums.
5. kind/question is out. Use forums.
6. status/in progress is out. Assign issue to user instead. We can look at the issue timestamp to see if something is actually in progress. 2 of the 3 "in progress" issues are over 1 year old. :see_no_evil:
7. priority/P0 and priority/P1 are out. Assign to milestones instead.
8. priority/P2 is out in favor of is/wishlist.
9. is/proposal means you are proposing a change and intend to implement it (or at least help). Different from is/enhancement since I think of those as just feature requests where the user doesn't intend to do anything. Derek's "Standardized Author Data" proposal could use this label, and I would have used is/proposal for this issue. :grinning:

PS - I may start relabeling some issues now, such as changing all priority/P2 labels to kind/wishlist.

/cc @bep @spf13 @digitalcraftsman @anthonyfok

Update:

I failed to include status/already-works in my original Proposed Label Set. Increases label count from 12 to 13.

[bep]

I totally agree -- maybe add is/critical, but we can maybe wait with that when the need surfaces.

[moorereason]

Ha! I had is/critical in there to replace priority/P0 until the last minute. :smile:

I assumed that if we have a critical bug, we need to create a new patch milestone and do a release. The patch milestone can act as our critical queue.

[digitalcraftsman]

This is a great proposal so that we can use labels in a systematic manner. I also agree on the new subset of labels but I'm not quite sure how do you define "status/already-works".

[bep]

how you define "status/already-works".

For me that is status/cant-reproduce; a not so bombastic way of saying that it works.

[moorereason]

My understanding is that status/already-works means someone reported a problem, but it's already working because:

1. It's intended to work that way. I would use status/wont-fix.
2. "It Works For Me." I would use status/cant-reproduce.
3. Reported issue has already been fixed. Could use is/duplicate if there was an existing issue to reference or just close the issue.

We can get rid of this label (only used 4 times). I've never used the label, myself.

Can anyone make a case for keeping it?

[moorereason]

Updated original post. See "Update" note at the bottom.

[bep]

As the wont-fix and others should be reasons to eventually close an issue (we have too many open issues), I suggest we also add a status/stale -- feature requests etc. that aren't relevant anymore.

[moorereason]

I agree that status/already-works, status/wont-fix and status/cant-reproduce should denote a soon-to-be-closed issue, but the labels are there to make the situation known to the reporter. If they can't come up with more info to help us reproduce the issue or change our minds, we can close it.

kind/wishlist has become our "stale" label, so I didn't propose a new one. But now that I think about it, we should generally only have one is/* label per issue. So, what if we replace is/wishlist with status/wishlist? Items on the wishlist are inherently stale. If we don't intend to do something on the wishlist, we should label as status/wont-fix and close it. If we intend to implement something on the wishlist, we should remove the wishlist label.

I also see some overlap with status/please-contribute. We could just add these items to the wishlist and let people choose their own adventure.

Proposed amendments

1. status/already-works is out. Use status/cant-reproduce or status/wont-fix.
2. is/wishlist changed to status/wishlist.
3. status/please-contribute is out. Use status/wishlist.

Proposed Label Set

• is/bug
• is/docs
• is/duplicate
• is/enhancement
• is/proposal
• needs/review
• needs/user-feedback
• status/cant-reproduce
• status/upstream
• status/wishlist
• status/wont-fix

11 labels

[bep]

I put wishlist on bigger/maybe not realistic wishes for enhancements, features described a little vague ... like, maybe one time in the future, it would be cool to have ... enhancements is kind of obvious and "yea, we should do that".

stale would be used for old bug reports from Hugo 0.13 that probably don't exist/is relevant anymore etc.

[moorereason]

@bep,

I considered adding is/idea, but they're generally enhancements anyway. What if we manage obvious, "yea, we should do that" enhancements by adding them to release milestones (even if it's future). Other "wishlist" enhancements could just sit out there with no milestone (or create a wishlist milestone). We could do our "spring cleaning" of stale wishlist items by looking for enhancements without a milestone.

Proposed Amendments

Starting from my last comment...

1. Add status/stale as a step toward closing an issue later on if no activity happens after several months.
2. status/wishlist is out. Use is/enhancement and then don't assign to a milestone.
3. Generally, use milestones to set issue priority and interest.

Proposed Label Set

• is/bug
• is/docs
• is/duplicate
• is/enhancement
• is/proposal
• needs/review
• needs/user-feedback
• status/cant-reproduce
• status/stale
• status/upstream
• status/wont-fix

11 labels

[bep]

I guess the current wishlist fits fine into is/proposal

[moorereason]

Well, now I want to get rid of is/proposal! :rofl:

I added is/proposal because we don't really have a good way of creating proposals. For example, take Steve's Hugo Next PDF. It's hard to comment on and make revisions of. However, GH issues are not a gerat place to make a proposal (see this discussion as proof!). I like Go's proposal repo, but we don't have that. I'm not sure what we need to do with proposals, but by going through this proposal today, I can say with confidence that this is not a good way to deal with them.

Ok, last time (I hope)!

Revisions

1. is/proposal is out. Use is/enhancement or go do it somewhere else.

Proposed Label Set

• is/bug
• is/docs
• is/duplicate
• is/enhancement
• needs/review
• needs/user-feedback
• status/cant-reproduce
• status/stale
• status/upstream
• status/wont-fix

10 labels

[bep]

Well, you need a status to put on the current wishlist (they do not fit in the enhancement category).

A proposal is a discussion => i.e. it should start out in the forum, then end up as an issue pointing to that discussion. We're not Go stdlib -- much less formal.

[moorereason]

What do you think about creating a maybe or wishlist milestone? I'd rather use a milestone to track urgency instead of labels.

[bep]

Add a is/wish and we can wrap this up. Wish is NOT a milestone.

[bep]

"Future" isn't a milestone, either, but that is another discussion.

[moorereason]

Done :+1: