More labels to mark issues as important

[riya-17]

I believe having a large number of issues come with their own issues. Whenever an issue is created it is marked with some labels. The labels must be able to point the viewer of the issue to the right indication.

Main concern that I deal with when I scroll down the issues list is that it is unending and not helping. Labels must be the way how we can make this easier. We do have some labels that does help like, 'bug', 'enhancement', 'help-wanted' but none of them signifies the criticality of the issue.

I believe there is this label name 'help wanted' which signifies that this issue is important and needs to be taken care of. All 'help-wanted' issues are diferent and must be having some or the other priority. One must be taken care before the other. The priority is the one I think we should think and consider about. This will help to track the most important and important issues separately. The labels would be good to mark them as a 'Critical' issue if it needs to be taken care of fast as possible. Maybe we can consider most important -> critical and important -> help wanted.

Just wanted to bring this up for Discussion.

[dbutenhof]

Yes, we have an enormous list of issues and it's difficult to sort out what's important. It'd be nice if there was a priority popup.

You're right that we could approximate this with labels like "critical", "important", "useful", in combination with the "bug" and "enhancement" labels.

Remember that we also have the "project" and "milestone" fields; which, if used right, can help to narrow down your search. That is, look for 0.71 bugs first, then 0.72 bugs, then 0.72 enhancements. (There may occasionally be "enhancements" for older versions; in a way your put-shim qualifies as an "enhancement" for the 0.69 project; but those should generally be rare.)

Filtering for 0.71 server bugs, for example, narrows down the list to three. Filtering for 0.72 server enhancements gives a list of 16: that's manageable, but adding a priority filter would make it a lot easier to pick out the most important. And, arguably, some of those 16 really ought to be tagged "nice when someone has time", but probably are unlikely to be feasible for 0.72.

[portante]

We have not been grooming as a team, but we should start that process.

Basically, the set of invariants I have been trying to maintain is:

• Alls PRs are assigned to a milestone
• PRs that are not active are marked as Draft mode
• If an issue is important, it is assigned to a milestone and does NOT have the Backlog label
• If an issue is not important, it is NOT assigned to a milestone and DOES have the Backlog label

Further, we have been using Projects parallel to milestones. Every major milestone has a project, with one exception: the b0.69 branch work has milestones but no project. We might want to consider changing that.

some of those 16 really ought to be tagged "nice when someone has time"

They should be in the Backlog, and labeled with Help Wanted.

[pravins]

Agree, grooming will be helpful. We can either spend start of the month or end of the month for it.

[portante]

We have started using Jira internally at Red Hat, but it is not public. This has largely left this issue unresolved from the GitHub side.

I'd like to see us use GitHub's new projects and actions to do prioritize and plan more in GitHub for the public project.

[dbutenhof]

We should really make our Jira project public. I don't like the idea of duplicating, and for all Jira's problems, GitHub is so far behind it for actual planning that I don't see the point of even trying.

[portante]

We should really make our Jira project public. I don't like the idea of duplicating, and for all Jira's problems, GitHub is so far behind it for actual planning that I don't see the point of even trying.

It makes no sense to me to require folks to have a GitHub login AND a Jira login, where they won't be able to participate fully with using Jira since it is Red Hat specific.

I believe the "public" Pbench project should be managed and planned in GitHub along side the repository. We already have been burned by issues not being tracked in one from the other, missing updates, etc.