Define guidelines for labels management#6
Conversation
romsi
changed the title
romsi
left a comment
romsi
left a comment
There was a problem hiding this comment.
@damienfraud we should have 2 more headlines (Immutability and Color). Use the pattern Preferred/Not Preferred to describe these sections.
|
|
||
| ## Label | ||
|
|
||
| We believe GitHub labels should define immutable informations about issues. |
There was a problem hiding this comment.
We should not use we or you to describe the guideline.
|
|
||
| We believe GitHub labels should define immutable informations about issues. | ||
|
|
||
| We consider having to change labels over time to be a bad practice. Indeed, changing labels manually multiple times on issues can be very time consumming and prone to errors. Moreover, we believe that if the information about the issue is changing, it is surely not a relevant information to have as a label. Almost everytime, you will see that variable informations about an issue can be managed in another way which will be much more efficient in the end. If you consider this, you will tremendously reduce useless labels creation, and see that you have more than enough information through it. |
There was a problem hiding this comment.
We should not use we or you to describe the guideline.
|
|
||
| We consider having to change labels over time to be a bad practice. Indeed, changing labels manually multiple times on issues can be very time consumming and prone to errors. Moreover, we believe that if the information about the issue is changing, it is surely not a relevant information to have as a label. Almost everytime, you will see that variable informations about an issue can be managed in another way which will be much more efficient in the end. If you consider this, you will tremendously reduce useless labels creation, and see that you have more than enough information through it. | ||
|
|
||
| We believe that labels should be regrouped into categories and that you only need three of them. We also recommend to use similar color styling accross categories for a stronger visual identification. |
There was a problem hiding this comment.
We should not use we or you to describe the guideline.
|
@romsi I added |
|
@damienfraud I updated the milestone section. We should find a pattern that is visual in order to quickly get the important information. Text is good, but visual should be our guideline. |
|
@romsi I updated the guidelines with a new formatting suggestion. |
|
@damienfraud we agreed on a new format. You need to fulfil the resources section and then we can merge it. |
- Add introduction for label section. - Fix typos. - Rearrange content for type of change section.
|
@damienfraud Please check my 2 latest commit. We should use the full title for links instead of using the source only. Preferred |
|
@damienfraud please check my latest commits. We should use the full title for links instead of the source name at the end. Preferred - [A better collaboration using Github](https://github.com/blog/a-better-collaboration).Not Preferred - A better collaboration using Github. [Github](https://github.com/blog/a-better-collaboration).Imagine you are blind and you only get the information inside the brackets. Try to figure out what is the context and where are you going to end up using this link. |
|
@romsi I'm ok with your changes. I will merge the PR. |
2 participants
Goals ⚽
Define GitHub guidelines in terms of labels use and management.
Inspiration 💡