Re-design label structure?

[rye]

After looking around at a lot of projects, I've started seeing patterns:

• kubernetes/kubernetes does the same thing we do. But they also have color coding for each label base, and every label (excepting GitHub's labels and words like accepted) is nested in some structure.
  • Moby does too.
• facebook/react-native uses emoji. Cool, I guess.

I want to remove guesswork on behalf of contributors, and make it easier to select labels by search. I also want us to be able to document the label scheme without going through and documenting each one. (leave descriptions on labels, and describe the different bases for each label)

Thoughts?

[hawkrives]

sure

[rye]

Here is what we have now, for the record:

• RFC, #1d76db
• bug/accessibility, #c2e0c6
• bug/data, #4534c9
• bug/general, #d93f0b
• bug/layout, #fef2c0
• bug/notifications, #d66524
• bugsnag, #ededed
• ccc-server, #92f44b
• component/analytics, #d4c5f9
• component/filter, #006b75
• component/markdown, #ba0371
• component/nav-buttons, #c2e0c6
• data/bonapp, #006b75
• data/bus, #b60205
• data/general, #bfdadc
• data/hours, #fbca04
• dep/js, #bfdadc
• dep/native, #c2e0c6
• dep/rb, #d10037
• design, #96f268
• docs, #fcaedf
• feature request, #c5def5
• good first issue, #fef2c0
• greenkeeper, #00c775
• help wanted, #c5def5
• platform/android, #d4c5f9
• platform/ios, #0052cc
• pr/don't merge, #f9d0c4
• pr/ready for review, #bfd4f2
• pr/welcome, #fef2c0
• pr/✓approved, #c2e0c6
• proposed, #fef2c0
• rebase, #ffb384
• release-note-worthy, #20d8b0
• renovate, #eecc44
• status/accepted, #a5bc2f
• status/discussion, #d4c5f9
• status/duplicate, #cccccc
• status/has-pr, #0e8a16
• status/in-progress, #fbca04
• status/invalid, #e6e6e6
• status/needs-verification, #e87366
• status/on hold, #f9d0c4
• status/pending rn upgrade, #0e8a16
• status/pending upstream, #bfd4f2
• testing, #3dcc9a
• tool/appveyor, #c5def5
• tool/bugsnag, #e2806f
• tool/build-scripts, #006b75
• tool/circle, #555555
• tool/codepush, #d4c5f9
• tool/danger, #fbca04
• tool/detox, #ad22c9
• tool/eslint, #5319e7
• tool/fastlane, #0e8a16
• tool/flow, #c5def5
• tool/gradle, #74bec9
• tool/prettier, #8dd5ef
• tool/renovate, #7cb5d6
• tool/script, #0052cc
• tool/testflight, #5319e7
• tool/travis, #f46f3a
• triage, #ededed
• type/bugfix, #c8e579
• type/documentation, #1d76db
• type/enhancement, #c5def5
• type/proof of concept, #fef2c0
• type/refactoring, #d4c5f9
• type/release, #4ba00b
• type/shipping hold, #b60205
• type/tracking, #5319e7
• view/calendar, #d4c5f9
• view/contacts, #e99695
• view/dictionary, #0e8a16
• view/directory, #f9d0c4
• view/edithome, #e874a0
• view/help, #d4c5f9
• view/home, #d93f0b
• view/hours, #bfd4f2
• view/map, #b60205
• view/menus, #006b75
• view/news, #5319e7
• view/orgs, #c5def5
• view/settings, #c2e0c6
• view/sis, #fbca04
• view/stoPrint, #e04c80
• view/streaming, #0052cc
• view/transportation, #bfdadc
• wontfix, #ffffff

[rye]

Here's a basic overview of what I'd be proposing:

• Rename prefixes that don't make sense (status/ can get removed from a lot of the status/ labels, since "status" describes "state", and every issue has state)
• Add descriptions for each (and every) label.
• Delete duplicate labels (status/in-progress, see Get rid of status/ labels? #3364.)
• Add new labels to expand granularity.
• Unify colors of bug/, view/, type/, platform/, dep/, component/, etc., keeping them the same if nothing should visually distinguish one label from the other (e.g. bug/general and bug/layout should probably be the same red color [maybe different shades] since they're both bad)
• Verify completeness of each view/, component/, etc.—make sure every View, Component, etc. has a label and vice versa.
  • Perhaps add a Danger rule to do this for us in the future? I.e. PR's that add a new Component or View would need to get a new label, somehow?
• Go back and label issues and PRs, adding new prefixes and the like.

[rye]

See also rust-lang/rust which does A- for area, T- for team, etc.