Review of current labels and proposing new ones

[jcastill]

Following up from our discussion in IRC - lets discuss what new labels can we create to make the life of maintainers and developers easier. At the moment we have 14 labels:

ACK (Ready for merge)
affects ubuntu
Canonical Eng
Changes Needed
enhancement
feature request
Good First Issue
Needs Review
Needs second ACK
Patch formatting
Quick Change
release note
RH QE
security

From Red Hat side, we'll need at least:
affects redhat
Red Hat Eng

@arif-ali Do you need a "Canonical QE" label?

Regarding new labels that could help maintainers, here are some ideas:

• One label for 'plugins', so we can use it for changes within plugins or adding new ones (or removing obsolete ones)?
• One label per-subsystem so 'collect', 'cleaner', etc.
• A "need_help" label that contributors could use when stuck or with doubts/questions.
• Tests, to cover changes/suggestions on the test suite?
• LGTM so non-maintainers can review PRs and give a hand reviewing/acking code. An example of a situation where this could help is when we have a plugin for, lets say, OCP, and we want some expert to review it. This engineer could tag is a LGTM so we can focus on the code, style, etc, without having to understand the internals of what's done at the same level as the expert.

The 'plugins' one may not be so useful, only for organization purposes and as opposition to subsystem ones (unless 'report' covers 'plugins'). But if we can get statistics in GH based on labels, we could find out where we spend our time.

Any other suggestions?

[arif-ali]

I created Canonical Eng and Needs Review today, to reflect the current status of some of the PRs.

I think having affects RH and RH Eng is cool as well.

We can also add Canonical QE as well, but would need to see what this label would mean for us.

I use gitea, and that has a concept of nested labels, but some of these could be useful, and will give us a good indication of the current status of PRs

Below are my rough ideas, I am sure others will also have ideas here as well

Types of PR (This is not as important)

• Kind/Documentation Updates and Fixes documentation
• Kind/Bug Something is not working, and this fixes the issue
• Kind/Obfuscation Fixes an Obfuscation issue
• Kind/New plugin New plugin being added
• Kind/Testing Related to Testing
• Kind/Ubuntu Ubuntu related item
• Kind/RedHat RedHat related item
• Kind/cleaner cleaner component of sos
• Kind/collect collect component of sos
• Kind/Good First Issue Good issue from first timers

Review Based labels (These could help with review statuses) (exclusive labels)

• Reviewed/Confirmed Issue has been confirmed
• Reviewed/Duplicate This issue or pull request already exists
• Reviewed/NM Ack Non-maintainer ack
• Reviewed/Needs 2nd Ack require a 2nd ack from a maintainer
• Reviewed/Ready for Merge 2 maintainers have reviewed so can be merged

Status Based labels (so that we can clearly reflect the current of PRs) (exclusive labels)

• Status/Abandoned Somebody has started to work on this but abandoned work
• Status/Blocked Something is blocking this issue or pull request
• Status/Need More Info Feedback is required to reproduce issue or to continue work
• Status/Needs Review This issue still needs a review from project members
• Status/RedHat Eng RedHat Engineering has been requested to review
• Status/Canonical Eng Canonical Engineering has been requested to review
• Status/RedHat QE RH QE has been requested to review
• Status/Canonical QE Canonical QE has been requested to review

[pmoravec]

I like the nested / taxonomic labels idea, that helps understanding the meaning of a label and prevents confusion when having multiple labels on one PR. I dont have particular preferences what labels are worth to add or remove. We can try something and review it after a while if it fits our needs.

Maybe just small nitpick on one particular label:

Reviewed/NM Ack is not self-explanatory. What the NM stands for? Does sound Reviewed/LGTM better, or even rather Reviewed/Other Ack?

On a similar note: I feel we shall improve the way of merging process to prevent stalled PRs, improve the slow(er) pace of upstream, more motivate authors to further contribute. Using proper labels is part of that. But so far this is very rough idea I have problems to anyhow formalize or propose particular ideas of potential improvement.

[arif-ali]

@pmoravec It was an idea, I and 100% open to the labels we use, and I had a concept of NM == Non-Maintainer, but not everyone understands that. I think Reviewed/Other Ack or Reviewed/LGTM sounds good, I'm not overly precious with naming.

On a similar note: I feel we shall improve the way of merging process to prevent stalled PRs, improve the slow(er) pace of upstream, more motivate authors to further contribute. Using proper labels is part of that. But so far this is very rough idea I have problems to anyhow formalize or propose particular ideas of potential improvement.

This was the main reason for encouraging a start on something, I am sure we can put in more ideas to improve.

The key thing here is that we are probably not all working 100% on sos, and this it the expectation some contributors need to be aware of, and the fact this is an open-source project, so sometimes there is some patience requried; but on the other hand we may need to improve on some aspects.

[jcastill]

My vote would be for Reviewed/Other Ack but I have to wonder if at the end of the day I'm going to be the only one using this label, because I don't see other non-maintainers doing reviews and acking PRs.
But we can just add this one and the others, and do a run for the next six months, or perhaps the next two releases (so we can start after December 16th), and re-evaluate if they are enough, we need more, or we haven't used any of them at all.