-
Notifications
You must be signed in to change notification settings - Fork 2.6k
Rethink Labels. #6175
Comments
Based on the labels that we already have I propose the following automated process as well for the issues and labels. This is based on the fact that we now have teams internally within Parity.
Then we have the following categories for issues: Then, we can have a bot that does the following:
|
Agree with everything here - labels and issue handling could do with some love. I'll add a Github Action for auto-assigning issues submitted by people outside of the organization the Additional automation could be done, but not without a little more information available. For example, if someone from team X confirms the issue, does that issue get auto-assigned to the team that dev is in? To do that would require more granular team definitions in the Paritytech org. Also I'm not sure we can enforce the presence of a label on issue creation. At a minimum, I suppose we could have a bot comment on the issue informing the dev to assign an appropriate label. |
That would be too hard I think. Whoever reads the issue from team X is way better aware of which team the issue belongs to.
Yes indeed, I don't think it can be prevented either, but we can have a bot that nudges at you if you don't :) |
I would also add that I have to idea which |
update from @gavofyork:
|
One step forward #6333 |
PRs
Issues
I have removed the |
This is progressing fast and I think the core problems are resolved. @s3krit please re open if you want this issue as tracking for the CI implementation, otherwise it is done IMO. |
I would like to propose re-creating the |
Would these be for classifying both PRs and issues? |
Just issues, e.g. |
Cool. What labels should we add @kianenigma ? |
I settled for adding a new project column. Thanks! |
Substrate is almost at an important release. While issue management is still something that we need to figure out improvements upon, I think better labels is a good and easy way to start this.
I brought this up a while ago internally as well, yet the conversation did not go anywhere. Here, I will try to rephrase everything given our new recent labels:
Basically, I have two main proposals:
M
group, introduce new ones that show the denote locality.CONTRIBUTING.md
and make sure it is being respected.My current interpretation of labels:
A
: Only for PRs, shows the progress of the PR.B
: Only for PRs, shows the impact zone of the PR. What does it break. Who should be informed. AFAIK we use this to generate release notes.F
: Only for issues, shows the broad domain of the issue.P
: Only for issues, shows the time-criticality of the issue.Q
: Only for issues, shows the difficulty.Z
: Only for issues, should technically be used per each closed issues, basically saying how and why it was closed.and then we have the infamous
M
which I can barely make any sense thereof:As far as I can think:
M6-rpcapi
,M7-signer
,M8-contracts
,M8-dapp
,M7-ui
.M9-deploy
,M2-installer
,M2-config
,M1-ci
,M0-build
M5-binaries
,M3-docs
is duplicate and we have a better label inF
group for docs.M4-Core
is assigned to what seems to me a random set of non-runtime issues. The term core itself used to be folder name in substrate that no longer exists.I think the best replacement for
M
is to have add a group of labels that show the locality of the issue. For example now we have a label for refactoring. But there's no way to distinguish between where this refactor might happen. Well.. except thisM4-core
for all the no-runtime stuff.Perhaps we can come up with a better grouping that explains locality
F0-Consensus
)Probably some of the team leads or elder devs who have a better big picture of the project can come up with the above list, or even argue that it is pointless and we should not have such locality labels. Heck, maybe we should reformat
M
to actually be fine grained stuff, and have many of them. Even so, this must be documented somewhere. For example, I would love to have an issue that groups all the issues related to weights. They are a recent effort that will probably not fit into a coarse grained grouping, yet I don't know if I can/should make one etc. One way or another though, I think theM
should be cleaned. Either replaced, or it should be clarified why it is there and what is its purpose.All in all, I know that this sounds like a pointless effort at the moment, but I think it is a right step and we need to start taking better care of our issue at some point. We currently have two issues with.. issues:
At least, if have proper issues, with well defined rules (probably in our
CONTRIBUTING.md
) of how to assign them (i.e. I think theZ
is totally underrated and should be used more) we can solve at least one part of the problem.The text was updated successfully, but these errors were encountered: