As of now we have for each repo a set of labels that has grown historically and are used in different scripts and projects with a different meaning.
Together with @chevdor and @alvicsam, we tried to reduce the amount of labels and set up new rules showing how these labels should be used. Still, the quality is very poor and we could reduce only a very little amount (due to usage in history or needs in processes/bots).
For the new repo I wish for us to first think about for what we actually require the labels for organising our work, before creating them. With that being said here comes a list of usage that comes now to my mind when thinking about the labels (feel free to comment/correct/add):
- Contribution labels
- Security audit labels
- CI/bots - will be defined by Vlad’s and Mak’s team
- Release analysis of delivery services: as of now, I know it’s a huge manual work for @hbulgarini and @al3mart to create the release analysis, with new labels and automations this could be improved and relief both for other projects
- Documentation - @kianenigma brought up that it would be good to have an audit label for documentation, meaning that DevRel could be notified when a PR is tagged with this label and then decide if to include this to their project board (or not)
- Topics: these labels are very heavily used and now that everything will be in one repo I think it’s even more important to keep them, but the classification will need to be improved
Where I don’t see the usage of labels needed:
Priority and Status - as we use Github projects, every project can decide for themselves the priority of the issue/PR and in which state it currently is, especially when it comes to status everyone has a different flow in their project and I don’t believe we need redundant information displayed as labels.
As of now we have for each repo a set of labels that has grown historically and are used in different scripts and projects with a different meaning.
Together with @chevdor and @alvicsam, we tried to reduce the amount of labels and set up new rules showing how these labels should be used. Still, the quality is very poor and we could reduce only a very little amount (due to usage in history or needs in processes/bots).
For the new repo I wish for us to first think about for what we actually require the labels for organising our work, before creating them. With that being said here comes a list of usage that comes now to my mind when thinking about the labels (feel free to comment/correct/add):
Where I don’t see the usage of labels needed:
Priority and Status - as we use Github projects, every project can decide for themselves the priority of the issue/PR and in which state it currently is, especially when it comes to status everyone has a different flow in their project and I don’t believe we need redundant information displayed as labels.