GitHub Labels that are logical, colorful and sensible.
TL;DR: Want beautiful GitHub Labels like these? Want to have them unobtrusively synced with your repos? Want to persist them indefinitely? Want to maintain your own labels? If the answers have been yes, this is definitely not too long, please read on.
- Run;
npm install -g github-label-sync
- Provide env-vars;
GITHUB_ACCESS_TOKEN
,GITHUB_NAME
,REPO
- Run;
github-label-sync -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}
The default GitHub Labels are, well... not ideal. This has been described many times:
There are many very good examples of GitHub Label strategies. Almost all of them are an improvement over the default. But for several reasons or another few, in practice, none of them have felt truly great or sustainable.
@seantrane/github-label-presets
were designed according to the following thoughts and principles:
- GitHub Labels are used for both Issues and Pull Requests (PR), therefore the label context should be agnostic.
- An Issue/PR without labels should not require labels to solicit attention, therefore the default state should be label-less.
- Issue/PR labels should only provide important context; priority, effort and the state of solution and/or decision-making.
- "High Priority", sure, but "Low Priority" is a joke; go label-less instead.
- Labels and their associated colors should have a logical connection that is intuitive at-a-glance.
- Labels should be lowercase. It's easier to type and less competitive with Label-names.
- Prefixes matter. Labels get chaotic without them. The chosen are;
effort
= relative effort involved, fibonacci from1
to13
priority
= designate immediacy;now
,2day
orsoon
state
= describe decision;approved
,blocked
,inactive
orpending
type
= describe type;bug
,chore
,discussion
,docs
,feature
,fix
,security
,testing
work
= describe situation;chaotic
,complex
,complicated
orobvious
- The only labels without prefixes are;
breaking
,good first issue
,greenkeeper
,help
andsemantic-release
Standard | Effort | Priority | State | Type | Work |
---|---|---|---|---|---|
Standard labels commonly used in most repositories. | Describes the relative effort to complete an issue or pull request. | Priority labels, but focused on describing the immediacy of attention required. | Describes the decision state of the issue or pull request. | Describes the type of issue or pull request. | Describes the kind of work involved in resolving the issue, using the Cynefin framework. |
github-label-sync
is used to synchronize your GitHub labels with as few destructive operations as possible - similar labels get renamed.- The label config is loaded via path or URL, or more specifically; the config file supplied by
@seantrane/github-label-presets
. - The
github-label-sync -l 'https://git.io/fAe5i' ${GITHUB_NAME}/${REPO}
command is run to have the label config applied to yourprofile/repo
. - The command can be run anywhere and anytime, but it's recommended during a CI plan. This will automatically keep your labels clean and synchronized with your chosen configuration - depending on how often your plan is run, of course.
Required: Generate a GitHub Access Token, provide it via GITHUB_ACCESS_TOKEN
environment variable. If you cannot provide token as env-var, you may also pass it via CLI.
- Install
npm install -g github-label-sync
- Dry-run
github-label-sync -d -l 'https://git.io/fAe5i' <github_name>/<github_repo>
- Run
github-label-sync -l 'https://git.io/fAe5i' <github_name>/<github_repo>
- optional: provide token via param;
github-label-sync -a <github_token> -l ...
You can use your CI/CD process to automate the periodic syncing of your repository labels. This can help persist order automatically.
Make sure GITHUB_ACCESS_TOKEN
env-var is available.
before_install: npm install -g github-label-sync
script: github-label-sync -d -l 'https://git.io/fAe5i' <github_name>/<github_repo>
deploy:
provider: script
script: github-label-sync -l 'https://git.io/fAe5i' <github_name>/<github_repo>
You can provide your own labels.json
via the [ -l, --lables ]
argument.
Contributions are always appreciated. Read CONTRIBUTING.md documentation to learn more.
Release details are documented in the CHANGELOG.md file, and on the GitHub Releases page.
Copyright (c) 2018 Sean Trane Sciarrone