-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels in the monorepo #25
Comments
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. |
I think that labels should represent immutable characteristics of the issue/PR instead of mutable ones. |
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:
Although, we could also just have |
100%, I think it should be much more fine-grained. |
Not sure this scales. As with my recent changes to the contribution guide, I want that we put much more on |
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 |
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.
The text was updated successfully, but these errors were encountered: