search

tendermint / coding

14 stars 10 forks source link

Github label system #48

Open jaekwon opened 6 years ago

jaekwon commented 6 years ago

Priority (color #fad2fa)

Type (color #d2d2fa)

Highlight (color #e6fad2)

Concerns (color #fafad2)

Meta (color #e6e6e6)

Documentation (color #d2fafa)

Dont use

faboweb commented 6 years ago

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:

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:

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 commented 6 years ago

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".

image

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

faboweb commented 6 years ago

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 commented 6 years ago

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

zramsay commented 6 years ago

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

faboweb commented 6 years ago

Good point @zramsay

jaekwon commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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)