Common labels across repos

Developers
#1

Hi all,

There have been numerous requests, particularly in the newer repos, to standardize on a set of labels. I’ve gone through all of the core manageiq-* repos, and created a set of common labels with common colorings. Eventually I’ll create a smaller, but consistent subset of labels for the various rubygems and nodejs packages we have. Below is a chart describing all of the common labels and colors. If you have any other suggestions, whether it be new labels, consolidation of redundant labels, or anything, please let me know here, or create a PR/Issue in the manageiq-release repo.

Thanks,
Jason

cc @abonas @blomquisg @chriskacerguis @dclarizio @gmccullough @martinpovolny @rpo @simaishi @simon3z @tzumainn

Common labels across the repos

Label Color Description
blocker Blocker for the next release.
bug A bug.
bug/sporadic test failure A bug that manifests as test failures in an unpredictable way.
cleanup Changes only making the code cleaner and that do not change how the code works nor the outputs produced (e.g. rubocop or eslint changes).
developer Changes that affect developers only, including non-customer-facing tools (e.g. changes to bin/setup)
documentation Changes to documentation only (e.g. README.md).
duplicate The issue is a duplicate. When applied, the duplicate issue should be referenced in a comment.
enhancement An enhancement.
help wanted An issue that could be handled by anyone, even new members of the community.
internationalization Changes that are for internationalization only (e.g. updating the *.po gettext files).
notabug The issue is not a bug as reported or not reproducible. When applied the issue should be closed.
performance Changes that are for performance improvements only.
question Issues that are just questions. When the question is resolved, the label should be changed and/or the issue should be closed.
refactoring Changes in the way the code works internally without changing the output produced. Contrast to "cleanup".
stale The issue is old and hasn't had activity in 3 months. This label will be automatically applied by @miq-bot once that bot feature is completed.
technical debt Changes that remove or significantly update old unused code and/or dependencies.
test Changes to test code only.
tools Changes to customer-facing tools (e.g. tools/pruge_metrics.rb). Contrast to "developer".
unmergeable The PR is unmergeable. This label is automatically applied and removed by @miq-bot.
verified The bug issue was reviewed and is verified to have the problem stated and a PR should be created. This label is not necessary on a bug PR.
wip The PR is a WIP. This label is automatically applied and removed by @miq-bot based on PR title having "[WIP]" or not.
wontfix The issue will not be fixed or otherwise handled. When applied, the issue should be closed.

About the label colors

Color Description
Scope - Bugs
Scope - Enhancement
Scope - Testing and tools: “test”, “developer”, “tools”
Scope - Other: “cleanup”, “performance”, “refactoring”, “technical debt”
Positive statuses: “help wanted”, “verified”
Negative statuses: “duplicate”, “notabug”, “stale”, “unmergeable”, “wip”, “wontfix”
Questions and discussions: "question"
Component: Repo specific labels that categorize what parts of the application are being changed. See the repos for specifics.
Alternate component: A secondary, repo specific categorization (e.g. in manageiq-ui-classic, dark purple represents a specific UI tab being changed, whereas light purple is used for general components like toolbars or buttons)
Special component: A component that requires more careful handling and possibly a specific reviewer or merger. Right now this is only "gem changes" and "sql migration".
Backporting and release: “blocker”, “fine/yes”, “fine/no”, “darga/yes”, “darga/no”, etc
3 Likes
#2

@martinpovolny:

  • I’m thinking the color of “pending core” should be to green as it falls under “Positive statuses” in my opinion. Thoughts?
    • I’m wondering if maybe it should change from “pending core” to something more generic like “dependencies” or “dependent prs”, and then it can be common across all of the repos.
    • Alternately, we keep it “pending core”, but give it and all other “pending X” labels a dedicated color.

@chriskacerguis:

  • I’m thinking the color of “ux/approved” and “ux/review” either be the maroon color for “questions/discussions” or perhaps the green color for “Positive statuses” (or perhaps maroon for ux/review and green for ux/approved). Thoughts?
  • Do you think “needs discussion” would be useful in the other repos? Have you used it much?
  • The “housekeeping” label is currently purple, but perhaps it can just be replaced with the existing “developer”, “tools”, or “cleanup”?
#3

Question for all: one thing I’d like to change is the “gem changes” label. As we have added npm packages to manageiq-ui-classic and manageiq-ui-service, I’d like to change the name of the label to something a little more generic like “dependencies”, and change the color to light purple (from the slate-blue-gray of “special component”)

Additionally, once the migrations are removed from manageiq and into their own repo, then we can remove the “special component” slate-blue-gray color entirely.

@himdel @martinpovolny @chriskacerguis Thoughts from the UI repos?

#4

gem changes

For ui-classic, gems are never going away, and for frontend deps we will be using both bower & npm for a while (hopefully not when gaprindashvili comes but…), eventually settling on npm only.

Not sure if it makes sense to have separate labels for each, or just one for dependencies…

internationalization

Maybe i18n would be easier to spell, not an issue for people who can see the dropdown, but I’d expect many more comments from miq-bot about unknown label internalization or similar :slight_smile: . (Though I guess that ship has already sailed with gaprindashvili :slight_smile: .)

#5

Ah yes, I forgot to mention I changed the i18n one in the ui-classic repo
for consistency. I’m good with changing it to i18n everywhere. However I
think only @mzazrivec is the one that uses it.

Jason

#6

I’m quite fine with either label (internationalization / i18n).

#7

a general pending dependencies label sounds good to me (although right now I see all pending labels are missing)
BTW when the “bugzilla needed” should be applied?

#8

That is part of the release process, so much like fine/backported, the release team will handle that. I changed it to be colored black to fall into the "release process"category.

#9

Q on test label: is it appropriate for PR that has functional changes, but also significant test additions, or is it reserved for tests-only PRs?
Similar question can be asked about refactoring — can we ever have enhancement refactoring or bug refactoring labels?

(my intuition is that something that could have been 2 PRs but was done as 2 commits in 1 PR ought to have the union of the labels those 2 PRs would have. but I can see utility in other interpetation.)

cc @moolitayer who asked

#10

I agree, if a PR is both a refactor and an enhancement it should have both labels (splitting such a PR allows faster & more accurate code review)

#11

test is typically just test-only PRs. I would expect all bugs & enhancements to include tests anyway, so adding test there is redundant. However if the PR added a bunch of additional, unrelated, tests, I could see adding the label.

Otherwise I don’t see why you couldn’t have 2 labels from the same category (e.g. Scope), if the PRs spans multiple things (e.g. refactoring and bug). Typically 2 labels implies the PR should be split up, but sometimes it’s necessary, and that’s ok.