Labels in the monorepo

[the-right-joyce]

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.

[bkchr]

• 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

I'm still somewhat in favor of reducing the number of labels. We are still having a lot of them and not sure that is that helpful. Providing proper changelog information could hopefully be done better with some kind of "changelog bot" or just some more manual process.

[juangirini]

I think that labels should represent immutable characteristics of the issue/PR instead of mutable ones.
As pointed out by @the-right-joyce Status and Priority are good examples of those mutable characteristics. I guess the 'Action' labels represent the former and 'Urgency' represent the later, but there other ones out there like 'D1-audited' for instance.

[kianenigma]

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)

If we want to follow on the mindset that @juangirini shared here, I would not need a label for the docs audit, and instead rely on a rule along the lines of:

• any PR that is tagged as note_worthy needs 1 approval from the github team paritytech/devrel.

Although, we could also just have devrel-audit be the label that we listen to. The reason that for sr-labs we use labels to signal "audited" is that we didn't want to give them access to the repo.

[kianenigma]

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

100%, I think it should be much more fine-grained.

[bkchr]

• any PR that is tagged as note_worthy needs 1 approval from the github team paritytech/devrel.

Not sure this scales. As with my recent changes to the contribution guide, I want that we put much more on note_worthy. All the time we have seen these labels for the Polkadot release notes, which is wrong. We should signal to everybody on what is done and then create the Polkadot specific release notes based on these release notes. Aka mentioning what changed for Polkadot itself.

[the-right-joyce]

as it's tightly linked to it: here is the new contribution guideline for the Polkadot SDK, please leave your comments on the document - once it's finalised I will add it to the monorepo