proposal: add proposal for issue/PR label convention#65
Conversation
jan--f
changed the title
jan--f
force-pushed
the
issue-pr-labels
branch
from
79b6366 to
6f7c5a7
Compare
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
jan--f
force-pushed
the
issue-pr-labels
branch
from
6f7c5a7 to
86fd9cc
Compare
beorn7
left a comment
beorn7
left a comment
There was a problem hiding this comment.
Looks good to me in general. However, I also don't feel very strongly about the details here. I guess once we see in in practice, we will see what works well and what needs changes. We shouldn't shy away from cutting out unused parts later. We have way too much label cruft already.
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
jan--f
force-pushed
the
issue-pr-labels
branch
from
8c23d92 to
6aec48f
Compare
beorn7
left a comment
beorn7
left a comment
There was a problem hiding this comment.
Two smallish comments left.
In doubt, I would just go forward with this. We can always iterate on it.
In any case, it would be great if somebody else would look at this.
jan--f
force-pushed
the
issue-pr-labels
branch
from
64c33f8 to
e97d357
Compare
Signed-off-by: Jan Fajerski <jfajersk@redhat.com>
jan--f
force-pushed
the
issue-pr-labels
branch
from
e97d357 to
a3a38b8
Compare
| **Proposal**: Keep the `component/` and `area/` prefixes and leave the suffixes | ||
| unspecified so that developers can add them as needed. Move any current labels | ||
| to use the prefixes where needed. |
There was a problem hiding this comment.
Would it be better to be explicit on the label casing, for instance, preventing a duplicate label creation for component/service discovery/kubernetes and component/service_discovery/kubernetes, where creators for both may not know about the existence of the other and unknowingly diverge (or enforcing a *case in general, so creators have a better idea on which casing to adhere to)? Consequently, someone relying on the same "space-based" formatting may expect area/ci cd instead of a hyphenated one.
(this follows up on a recent Slack discussion)
There was a problem hiding this comment.
I wonder if being implicit on the granularity levels could lead to instances where that ends up becoming a concern, for instance, say, some maintainers use component/service discovery as is the case now, some end up using component/service discovery/kubernetes, and some end up using component/service discovery/kubernetes/endpoints? There's also the case where, as I do currently, to not break any existing triage boards or just label expectations in general, I add both component/service discovery and component/service discovery/kubernetes labels (and not just the former one) to all K8s SD issues I want to pull into my triage board.
Multiple labels for multiple (unknown) levels of granularity could lead to more issues missing the correct "chain" of labels (in case we want to keep the current behavior), or unknowing specifying it (redundant labels, in case we want component/service discovery/kubernetes/endpoints only instead of all three going forward).
There was a problem hiding this comment.
I'm likely being overly cautious here, there's probably a good portion of this we can safely leave to the label creators' discretion.
| - Maintain an efficient review and triage workflow | ||
|
|
||
| A systematic approach to labels helps contributors and maintainers quickly | ||
| understand the state of any issue or PR and take appropriate action. |
There was a problem hiding this comment.
Can we expand PR to pull request throughout the document for consistency?
| understand the state of any issue or PR and take appropriate action. | |
| understand the state of any issue or pull request and take appropriate action. |
|
|
||
| #### 1. Triage Labels | ||
|
|
||
| These labels indicate whether an issue has been evaluated and is ready for work: |
There was a problem hiding this comment.
Maybe a note that these labels are not meant to be used on pull requests?
|
|
||
| Component labels indicate which part of the codebase an issue or PR affect. | ||
| Area labels provide additional categorization for cross-cutting concerns. | ||
| A few examples of currently used labels: |
There was a problem hiding this comment.
| A few examples of currently used labels: | |
| A few examples of currently used labels: |
|
|
||
| #### Component and area Labels | ||
|
|
||
| Component labels indicate which part of the codebase an issue or PR affect. |
There was a problem hiding this comment.
I think it would be worth mentioning that these are optional. Not all repos need them.
4 participants
No description provided.