Replies: 14 comments 17 replies
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
[UNDECIDED] Size labels for PRs
Example labels (the limits are arbitrary, this just shows the general idea):
AlternativesWe could add 3 labels with one indicating a small PR, one indicating a big PR, and one indicating a huge PR (huge one meaning it's very likely to need splitting) |
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
[NEEDS ORG'S BLESSING] Resolution labelsThis set of labels is meant to indicate the resolution of a closed issue. The currently proposed set of labels
|
Beta Was this translation helpful? Give feedback.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
-
[NEEDS ORG'S BLESSING] Improve the life cycle of issues with better "Status" and new "Needs" labelsCurrently, our Status labels aren't working for us. Many issues stay in "Status: Needs Triage" for too long because we don't have a next good stage to put them in after labeling the issue. For example, there's no much difference between the proposed feature being accepted but needing more discussion (i.e. on design), and a feature that we are not even sure we want. Sometimes they are marked as "needs triage", sometimes as "needs discussion", and sometimes as "accepted" despite needing more thought put into how. To add to the confusion, there's a "Status: PRs Welcome" that is most often assigned in addition to "Status: Accepted" rather than be treated as a separate status. And it is not wrong to not treat it as separate status either, because the issues with "PRs Welcome" often don't actually differ from the issues that are only "Accepted" - both are accepted and could really be PRed by a contributor. Some issues are easier than others but that should be signified with labels like "good first issue" (or some other solutions), not with the Status of the issue. Below I propose some enhancements to the whole life cycle of the issue that I think should help this a lot. It might still be missing some things that would make it a better process but I think it is vastly better than the current mess where most Status labels blend into each other, making it hard to work with them. The currently proposed set of labelsSee also: https://red-devguide--5.org.readthedocs.build/triaging-issues/#life-cycle-of-an-issue New "Needs" labels
New "Status" labels (the order indicates the life cycle of the issue)
Rejected ideasAt an earlier stage, there were plans for having "Status: Needs Author Feedback", "Status: Needs Attention", and "Status: Needs Decision" labels. This was considered problematic because "Status" labels are only meant for issues but what these labels indicate would be useful to have for PRs as well. While we could use those 3 labels on PRs despite the labels being meant only for issues, this seemed a bit confusing. There was one other potential solution for the problem with the needs labels other than the currently proposed one - we could have gone for separate "Needs" labels for PRs. An advantage of this solution is that the issues could have kept their full status within the Status label, while the currently proposed solution requires a "Needs" label as well. This did not really seem like much of a problem though and there were no other advantages found. As for problems, one of them was duplicating the labels and with the amount we already have, we would want to avoid that to minimize the confusion. Additionally, filtering for specific Needs on both issues and PRs (at the same time) would have not been possible which would hurt the filtering capabilities. |
Beta Was this translation helpful? Give feedback.
-
[NEEDS ORG'S BLESSING] Add "Needs: Label Fix" to be auto-applied when missing required label
For example, each issue would require Category, and Type labels (except for issues marked as duplicates) |
Beta Was this translation helpful? Give feedback.
-
A tracking discussion with all the ideas for improvements of the triaging process. See below for more.
The comments with rejected and done ideas are minimized ("hidden").
Beta Was this translation helpful? Give feedback.
All reactions