Repo labels and label use policy #184
Comments
blackfalcon
changed the title
blackfalcon
changed the title
|
Scope to consider:
|
|
What is the value of adding a label with the name of the repo? Isn't that redundant since the issue/PR is already in that repository? |
|
The name of the element will be removed from the title. Doing so was a way to easier see what issue belongs to what repo in the Project view. Another value add is, labels allow for click-filter functionality in Project. |
|
Something that I want to consider is having a consistent policy for label use with each issue and pull request.
|
|
I definitely find the current label structure confusing, and I'm never quite sure what labels I need to add. The more we can automate with this (e.g. each issue/PR automatically having the repo label attached), the better. I'm a heavy contributor to Auro, and I can barely keep track of which labels are necessary, so my guess is other contributors are in a similar (if not more confused) state. I also think there's too many status labels at the moment. IMO, the essentials are
I think everything else can be conveyed by issue/PR state (e.g. open, closed, merged, etc). Having too many status labels means they won't get applied consistently. Also, if possible, I think most labels (e.g. "type of update") should only be applied to the original issue. Also applying it to the PR is duplicative, and PRs are short-lived compared to their associated issues. For all these suggestions, I'm speaking as a contributor to Auro. If it's not expected that I set most of these labels, then great, disregard my comments and label away! In the end, I want it to be clear what labels I am responsible to add, and I want to have to manually add as little labels as possible. |
|
I think with this we need to also review our new vX.x-rc policy when it comes to PRs. Issues are assigned to a RC milestone. Should PRs also be assigned too? IMHO, no. PRs are assigned to issues. Issues are assigned to milestones. |
|
We have a label for |
|
@braven112 it's not a PR by PR choice, it's a repo setting. All or nothing as far as I understand. |
|
Looking into it a bit more, it seems like enabling the option is a repo setting. And it does allow anyone with write access to turn off auto merge on a PR by PR basis. But it seems to work the opposite of ADO which allowed us to have manual merge by default and turn it on when needed. Here it seems to only allow auto by default and can be manually changed to manual on a PR by PR basis. Given that difference I'm not sure, that would actually be better than the label and seems to go beyond the scope of the labels discussion, regardless. |
|
In reviewing the new projects beta from GitHub they include status automatically from the view so we should be able to get rid of these labels once we move to that and have our board setup.
|
|
Here is the final list we arrived at...
|
# [3.10.0](v3.9.5...v3.10.0) (2021-11-09) ### Bug Fixes * **marked:** update marked api call [#250](#250) ([5d3d76a](5d3d76a)) * **stylelint:** update selector max pseudo class to be less restrictive [#246](#246) ([19d54aa](19d54aa)) ### Features * **docs:** auto generate md docs with mardown-magic ([79e77eb](79e77eb)) * **git:** use custom namespace in settings.yml ([93df625](93df625)) * **labels:** update pre-defined labels for new repo [#184](#184) ([39dfa8e](39dfa8e)) * **postcss:** add alert message if -fixed files != .css files [#255](#255) ([3f74db0](3f74db0))
Is your feature request related to a problem? Please describe.
Labels are showing some age.
Describe the solution you'd like
Repository labels are a core part of Auro's communication of processes. The scope of the work here is to review all labels, review label use policies, and ensure that the labels are being shown on the Auro docsite correctly reflect the actual labels in use with the Generator.
Additional scope is to work with Auro's design support to have appropriate labels that reflect that work.
The text was updated successfully, but these errors were encountered: