Github label system

[jaekwon]

Priority (color #fad2fa)

• bug
• priority? - use to tag what might be priority

Type (color #d2d2fa)

• proposal - feature requests, enhancement, etc
• question
• task
• policy - process or policy issues
• milestone - an issue describing the milestone

Highlight (color #e6fad2)

• feature - something worth featuring in publications
• bounty - person doing the tagging, or representing some bounty program, will pay a bounty for it.
• help wanted - help wanted from anyone
• good first issue - good entry-level bug, to get familiar w/ the codebase

Concerns (color #fafad2)

• p2p
• rpc
• consensus
• ... project specific, go nuts

Meta (color #e6e6e6)

• duplicate
• wontfix
• fixed

Documentation (color #d2fafa)

• docs - need (updates to) documentation
• spec - need (updates to) specification

Dont use

• invalid -> use wontfix
• enhancement -> use proposal
• priority - high -> use priority? or bug or milestones (codeowner)

[faboweb]

Thoughts on the labels:

I like the colors. It is a good answer to the eye-cancer concerns the team had before.

proposal
A proposal is for me a suggestion to change or implement things. So basically every issue. I think this is too general. If we tag only issues not yet approved to be implemented, that would be a valid use-case for me. We had the "idea"-label fulfilling this purpose before.

feature and enhancement
To understand the complexity of a ticket and assist the understanding of a ticket we introduced those two label:

• feature (major improvement): a new implementation or complete overhaul of an existing implementation that will create breaking changes or could end up in a new newsletter as a major improvement
• enhancement (minor improvement): an improvement to an existing implementation that is not necessarily worth mentioning in a newsletter and will not break other code based on this repo

help
I think in the "basar"-model we basically want help on every ticket, right?

duplicate, wontfix, fixed
Isn't it enough to close those issues stating this as a comment?

policy
Policy to me has more the meaning of "rules". You relabeled several issues in the UI repo with this label where I don't think they fit:

• establish a e2e testing strategy
• create a competition comparison spreadsheet

As we use GitHub as out ticket-system we also need these tasks in the repo. I propose the label "task" to label issues, that will not produce code.

I am pro labeling every issue. Issues not label are to me unfinished creations probably done by an outside contributor.

[jaekwon]

proposal
A proposal is for me a suggestion to change or implement things. So basically every issue. I think this is too general. If we tag only issues not yet approved to be implemented, that would be a valid use-case for me. We had the "idea"-label fulfilling this purpose before.

Not every issue is a proposal. Bugs are generally not proposals, though they imply a proposal to fix it. A question is not a proposal, etc. A proposal that gets accepted into a project can get the flag dropped. A bad proposal can get closed. Ideas seem too half-baked. I feel like it should get baked into a question, bug, or proposal, task, or something else more concrete.

feature (major improvement): a new implementation or complete overhaul of an existing implementation that will create breaking changes or could end up in a new newsletter as a major improvement

Sounds fine, to have a "feature" alongside "proposal". We can feature anything, even a question.

help
I think in the "basar"-model we basically want help on every ticket, right?

Yeah, but some won't be as important. I think it's fine for the project owners(s) to label issues as requiring any help possible.

duplicate, wontfix, fixed
Isn't it enough to close those issues stating this as a comment?

I thought the same, but some people seem to really want them. I think it could serve as a marker for what is about to happen... if it's "duplicate" or "wontfix", then they're about to get closed. If it's "fixed", it's about to get closed too. So these can serve as pending decisions.

policy
Policy to me has more the meaning of "rules". You relabeled several issues in the UI repo with this label where I don't think they fit:

establish a e2e testing strategy
create a competition comparison spreadsheet
As we use GitHub as out ticket-system we also need these tasks in the repo. I propose the label "task" to label issues, that will not produce code.

OK, I guess they aren't policy. I'm not sold on needing "task" but ok, lets try it out.

BTW, I realized that GitHub shows a modal for "help wanted" and "good first issue".

So we should s/help/help wanted/g and also introduce "good first issue".

[faboweb]

Sorry for taking too long to answer! I agree with the current status! Sounds like a good set of labels. :)

Should we close this issue?

[adrianbrink]

Me too. Let's merge the PR and then close this

[zramsay]

whats the purpose of the milestone label when GH already has a full-fledged milestone feature?

[faboweb]

Good point @zramsay

[jaekwon]

Lets keep these open and use the issues list under tendermint/coding as a live policies list? If we need to prioritize any of these issues, we can bring them up during meetings, or it could be announced on Slack etc, so lets use open/closed to denote in-effect/not-in-effect.

[jaekwon]

If I tag something as "bounty" it means that I am tasked by a bounty program to put out bounties and pay them. Or, it means that you care so deeply about some issue that you will pay out of your own pocket for someone else to implement something.

[zramsay]

IMO we shouldn't leave issue open as live policies lists - that's the point of commiting the result of the discussion to the repo itself. Open issues are TODOs, and, well, this conversation is done. Removing assignees so these issues don't show up on everyone's personal GH issue todo list (https://github.com/issues/assigned)