Remove Spaces from GitHub Labels

[jeffhandley]

There have been several offline conversations recently about the spaces in use within labels in this repo. Common comments include:

1. Spaces in labels are annoying because it requires quotes around the label when searching/filtering
2. We are inconsistent between our use of spaces and dashes, but dashes are used far more often

I propose that we standardize on dashes and update existing labels with spaces to conform to dashes instead. Here is what would be affected if we adopted that approach:

• Bottom Up Work ➡️ bottom-up-work (requires themesof.net change)
• Continuous Improvement: Unused; could be deleted or changed to continuous-improvement (requires themesof.net change)
• Design Discussion ➡️ design-discussion
• diagnostic global tooling: Only used by 7 closed issues; could be deleted or changed to diagnostic-global-tooling
• feature request ➡️ feature (for symmetry with bug) or feature-request
• FollowingUp ➡️ Very low usage with only 1 (stale) open issue; could be deleted, changed to following-up, or merged with needs-further-triage
• hard problem ➡️ hard-problem (or consider difficulty:hard with easy ➡️ difficulty:easy)
• in pr ➡️ in-pr (impacts automation)
• needs further triage ➡️ needs-further-triage (impacts automation)
• needs more info ➡️ needs-more-info (impacts automation)
• * NO MERGE * ➡️ -NO-MERGE- or NO-MERGE
• * NO SQUASH * ➡️ -NO-SQUASH- or NO-SQUASH
• NO REVIEW ➡️ -NO-REVIEW- or NO-REVIEW
• no recent activity ➡️ no-recent-activity (impacts automation)
• release notes ➡️ release-notes
• test bug ➡️ test-bug
• test enhancement ➡️ test-enhancement
• User Story ➡️ User-Story (requires themesof.net change)

/cc @terrajobst, @jeffschwMSFT, @danmoseley, @marek-safar

[terrajobst]

• * NO MERGE * ➡️ -NO-MERGE- or NO-MERGE
• * NO SQUASH * ➡️ -NO-SQUASH- or NO-SQUASH
• NO REVIEW ➡️ -NO-REVIEW- or NO-REVIEW

I'd opt for no surrounding dashes. Color + ALL-CAPS should be enough to make those pop.

[danmoseley]

changes are fine with me, when we've changed label strings in the past there was little fallout: it seems that not many people bookmark queries.

[danmoseley]

BTW, I wonder whether there are any emerging standards across other dotnet repos, or repos in general?

It looks like https://up-for-grabs.net/ is fairly agnostic.

It looks like https://github.com/microsoft/vscode/labels standardized on lower case kebab.

[danmoseley]

cc @eiriktsarpalis @captainsafia

[jeffhandley]

Thanks for the notes there, @danmoseley. I'm going to wait a couple days into next week before taking any action to make sure folks get to see this after the long US holiday weekend.

[karelz]

Given that we plan to rename "feature request" ... why do we even have this label? It is duplicate of 'enhancement' label. Instead of renaming, should we just merge it? (happy to take it separately if needed / desired)

[eiriktsarpalis]

By the way -- with FabricBot configuration being moved to Config-As-Code (#62297) it should be fairly straightforward to bulk rename labels that are touched by automation.

[danmoseley]

My 2c I have no objection to any of the changes proposed.

[eiriktsarpalis]

I just merged #64048 which completed conversion of all labels impacted by FB automation.

[teo-tsirpanis]

Copying a discussion item from the dotnet-runtime-triage team, I noticed that some labels in dotnet/runtime actually came from issues transferred from other repositories (like Roslyn or ASP.NET Core), and are effectively unused. They can be noticed by their incompleteness (e.g. there is "4 - In Review" but not the other three), inconsistent coloring or casing, irrelevant name or low issue population. These labels are:

• 4 - In Review
• area-blazor
• Area-Compilers
• Area-NetSDK
• area-runtime
• area-web-frameworks
• blazor-wasm
• feature-httpclient-extensions
• New Feature - Warning Waves

Somebody with the necessary permissions could evaluate each label and delete it from dotnet/runtime if so decided.

---

The dotnet/perf-autofiling-issues repository is also introducing some labels that have a more plentiful dotnet/runtime equivalent but are named differently:

• arm64 clashes with arch-arm64. I changed the only issue with this label (Regressions in System.Text.Tests.Perf_StringBuilder #64751).
• CoreClr clashes with runtime-coreclr.
• x64 clashes with arch-x64.

Also the Regression label's name is misleading; it is applied on issues that represent performance regressions, while the term "regression" means something broader.

Somebody with the necessary permissions could evaluate each label and synchronize its naming on dotnet/perf-autifiling-issues and the performanceautofiler bot if so decided.

[jeffhandley]

I've made all of the changes (including the cleanup identified by @teo-tsirpanis) except for those that require changes to themesof.net. That will need to be coordinated with @terrajobst and it potentially affects other repos as well.

[jeffhandley]

Since Bottom Up Work Not part of a theme, epic, or user story and https://github.com/dotnet/runtime/labels/Continuous%20Improvement are waning in usage, we won't worry about renaming those. This leaves only User Story A single user-facing feature. Can be grouped under an epic. with a space; the disruption from that is not justifiable.