Define standard for issue labels

jgvictores commented 5 years ago

Define standard for issue labels.

Additionally specify if any specific repository/project will have a different set of labels.

Personal thoughts which lead to no specific direction:

At #57 we found out https://github.com/destan/github-label-manager is not perfect, but useful for copying issue labels
I've been doing some priority (idea/low/high/critical) and complexity (easy/hard/tedious) labeling myself, which I think is related to scrum/agile but the main motivation is it really helps sort things out.
At https://github.com/roboticslab-uc3m/developer-manual/blob/master/asking-questions.md (perma) teo-main establishes the reference pattern. We can speak about this!
- Maybe https://github.com/roboticslab-uc3m/project-generator/labels is a better place to put the reference pattern!
Think if spaces should be acceptable (as well as other characters: :, -...), and alternatives if not (camelCase, etc)
status: in progress is redundant wrt project column, see https://github.com/search/advanced (only issue labels), so I'd like to keep this to recommend queries such as checking WIP at personal or organization-wide level.
I was thinking of splitting upstream to describe two situations:
1. Blocked due to factors that are external to https://github.com/roboticslab-uc3m (could be blocked: upstream or upstream: blocked, each would have corresponding color)
2. Code broken due to upstream modifications (e.g. YARP new deprecated function, etc)

jgvictores commented 5 years ago

Some things commented with @David-Estevez (very related to #74)

We use spaces. Example: priority: critical
Remove status: in progress as soon as we are sure we can access kanban column info via GitHub API.
Under same premise as (2), remove blocked, rename blocking->priority: blocking
regression: upstream is simply a regression, we are the ones who have to fix it anyway.
For labels, we define the basics, but new can be added per repo.

jgvictores commented 5 years ago

Additional note: For handling blocked/blocking issues, it seems like the ideal solution would neither be labels nor project columns (see #74), but instead a dependency tree. :smile:

PeterBowman commented 5 years ago

+1 for a regression label.

jgvictores commented 5 years ago

Notes:

jgvictores commented 5 years ago

Lots already at https://github.com/roboticslab-uc3m/developer-manual/blob/master/best-practices-github.md#github-issues (rendered at http://robots.uc3m.es/gitbook-developer-manual/best-practices-github.html#opening-a-github-issue)

PeterBowman commented 5 years ago

I was thinking of splitting upstream to describe two situations:

Also: broken code due to an upstream bug, found local workaround, local (RL-side) issue closed (https://github.com/roboticslab-uc3m/WBPCwaiter/issues/2#issuecomment-474417097).

PeterBowman commented 5 years ago

See also https://gist.github.com/Isaddo/7efebcb673a0957b9c6f07cd14826ea4 (a JS web-based label editor).

PeterBowman commented 5 years ago

Idea: rename tracking (an "issue of issues") to horizontal (affects multiple repos, perhaps even orgs).

jgvictores commented 5 years ago

Idea: rename tracking (an "issue of issues") to horizontal (affects multiple repos, perhaps even orgs).

I'll begin to apply this

PeterBowman commented 4 years ago

roboticslab-uc3m / questions-and-answers

Define standard for issue labels #76