GithubのLabelsをGUIでなくjsonで一括登録する方法

GithubのLabelをjsonファイルで定義し一括作成する方法を説明します。

環境

Mac / Linux
その他でも基本的に実装可能だと思います
ghが入っている前提とします

手順

※ 後からでも良いですが、先に既存のラベルはすべて削除しておくと便利

1. Labelの定義用のjsonファイルを作成

labels.jsonというファイルを作成し、以下のようにLabelを定義します。

参考

[
  {
    "name": "bug",
    "color": "d73a4a",
    "description": "Something isn't working"
  },
  {
    "name": "documentation",
    "color": "0075ca",
    "description": "Improvements or additions to documentation"
  },
  {
    "name": "duplicate",
    "color": "cfd3d7",
    "description": "This issue or pull request already exists"
  }
]

2. （入っていなければ）Github CLI（`gh`コマンド）をインストール

Github CLIを使うと、コマンドラインからGithubの操作ができるようになります。
インストール方法は公式ドキュメントを参照してください。

3. スクリプトを作成してLabelを一括作成

以下のようなシェルスクリプト（create_labels.sh）を作成します。

#!/bin/bash

REPO="ユーザー名/対象のリポジトリ名"

for row in $(jq -r '.[] | @base64' labels.json); do
  _jq() {
    echo ${row} | base64 --decode | jq -r ${1}
  }

  name=$(_jq '.name')
  color=$(_jq '.color')
  description=$(_jq '.description')

  gh label create ${name} -c "${color}" -d "${description}" -R ${REPO}
done

REPO変数にLabelを設定したいリポジトリを指定します。
このスクリプトを実行すると、labels.jsonで定義されたLabelがリポジトリに一括で作成されます。

4. スクリプトを実行

以下のコマンドでスクリプトを実行します。

bash create_labels.sh

Labelが正しく作成されたかは、Githubのリポジトリ上で確認できます。

まとめ

以上の手順で、GithubのLabelをjsonファイルで定義し、グローバルに管理・一括作成することができます。
jsonファイルを変更することで、Labelの追加・修正・削除が簡単にできるようになります。

複数のプロジェクトで同じLabelを使う場合に便利な方法です。

参考に、フロントエンドからUIUX領域がメインのレポジトリとした、以下のような設定をよく使います

[
  {
    "name": "docs",
    "color": "0075ca",
    "description": "ドキュメント系の追加、更新"
  },
  {
    "name": "Front",
    "color": "008672",
    "description": "フロントエンド自体の課題=BFF課題/U|課題は含まない"
  },
  {
    "name": "CSS",
    "color": "e4e669",
    "description": "Ul-Design CSS設計UIデザイン自体の課題"
  },
  {
    "name": "UI Library",
    "color": "0052CC",
    "description": "UIライブラリ自体が主題の課題。組み込み、UIの拡張など"
  },
  {
    "name": "UI Test",
    "color": "7057ff",
    "description": "UI検証、デザイン確定はしていない状態で仮Uの設計/実装"
  },
  {
    "name": "Layout",
    "color": "EE0E52",
    "description": "UIレイアウト構造がメインのU課題"
  },
  {
    "name": "UX Design",
    "color": "d876e3",
    "description": "非機能なUIUX課題、ユーザビリティ、アクセシビリティ対応"
  },
  {
    "name": "bug",
    "color": "d73a4a",
    "description": "バグ、不具合の対応"
  },
  {
    "name": "env",
    "color": "16C9F5",
    "description": "パッケージの追加、選定検証、変更、アップデート"
  },
  {
    "name": "BFF",
    "color": "bfdadc",
    "description": "Backend for FrontEnd"
  },
  {
    "name": "BackEnd",
    "color": "9F28C3",
    "description": "バックエンド課題"
  },
  {
    "name": "Draft",
    "color": "cfd3d7",
    "description": "進行中"
  }
]

配色ツール

ラベルの色の采配で迷うことがあると思います。
ツールは多々あると思いますが、ひとまずざっくり色相環がバラけるようなHEXカラーリストが欲しい時、自作でβ版ではありますがこのようなツールも活用してみてください

Pallet Pally（パレットパレー）

主な用途はデザインシステム構築などに使うカラージェネレーターです
明度と彩度が一定の規則性を持って分布生成されます
1-12個の総数を任意に設定できます（13個以上は検証中です）

https://pallet-pally.vercel.app/

各カラーセットの命名、感覚的な微調整も可能です
メインカラーを決めれば相対的な明度、ダークやライトが同じ色相のまま連動して変化します
完全に静的なのでサーバーは持っていません。Reactで作成し、Vercelにデプロイしているだけです。
永続性の担保としてjsonのimport/exportに対応させています。ドラクエ1の復活の呪文のような形式です。

色の定義、心理的効果

GitHubラベルに色彩心理の原則を応用すると、ラベルが視覚的にわかりやすくなるだけでなく、チーム全体の生産性向上や意思決定を促進する効果も期待できます。

以下に、Web開発者がGitHubのラベルに色を付ける際に応用できる、色彩心理の知識をまとめます。

1. 赤（Red）

応用例: 高優先度、バグ、クリティカルな問題
理由: 赤はエネルギッシュで目を引く色であり、緊急性や注意を促します。重要なバグや直ちに対応が必要なIssueにこの色を使うことで、チームの注意を引きやすくなります。
ラベルの例: high-priority, critical-bug

2. 青（Blue）

応用例: ドキュメンテーション、知識共有、情報整理
理由: 青は信頼感と冷静さを示す色です。プロジェクトの安定した部分や信頼性を求めるタスク、例えばドキュメントの改善やコードベースの整理などに適しています。
ラベルの例: documentation, refactor

3. 黄色（Yellow）

応用例: 注意が必要な問題、警告、改良
理由: 黄色は注意を引きつつ、緊急性まではないタスクに最適です。今すぐ対処は不要だが、無視すると問題が大きくなる可能性のあるIssueに使用します。
ラベルの例: warning, enhancement

4. 緑（Green）

応用例: 成功したタスク、完了、承認されたPull Request
理由: 緑は成長や安定を象徴する色で、ポジティブな結果や成功を示すのにぴったりです。タスクが完了したり、プルリクエストがマージされたときに使用できます。
ラベルの例: completed, approved

5. 紫（Purple）

応用例: 創造的なタスク、新機能開発
理由: 紫は創造性や革新性を示す色で、新しいアイデアや実験的な機能、UI/UXの改善に関連するIssueに適しています。チームがクリエイティブに取り組むべきタスクを強調します。
ラベルの例: feature-request, UI/UX-improvement

6. オレンジ（Orange）

応用例: 中優先度のタスク、レビュー待ちのPR
理由: オレンジは活気があり、エネルギーを感じさせますが、赤ほどの緊急性はありません。中程度の優先度のタスクや、今後の対応が必要なレビュー待ちのPull Requestなどに適しています。
ラベルの例: medium-priority, needs-review

7. ピンク（Pink）

応用例: デザインやフロントエンドに関するタスク
理由: ピンクは優しさや感情を引き出す色で、フロントエンドのデザイン改善やユーザー体験の向上に関連するタスクに使用すると、柔らかな印象を与えます。チームにとって、UIやビジュアルに関わるタスクを区別するのに役立ちます。
ラベルの例: UI-enhancement, design

8. 黒（Black）

応用例: 技術的なデッドエンド、破棄されたアイデア、Deprecated
理由: 黒は強力で厳しい印象を与え、終わりや取り下げを示すのに適しています。たとえば、廃止された機能やデッドエンドに陥った技術的なアプローチに使用すると、はっきりと「ここは終わり」というメッセージを伝えられます。
ラベルの例: deprecated, won't-fix

9. 白（White）

応用例: 中立的なタスク、未分類
理由: 白はシンプルで中立的な色です。まだ分類されていないタスクや、特定のカテゴリに属さない課題に使用できます。後で整理や分類が必要なタスクに使うことが多いです。
ラベルの例: unclassified, needs-triage

10. グレー（Gray）

応用例: 保留中、低優先度、無期限延期
理由: グレーは冷静で中立な色で、優先度が低く、今すぐ対応する必要がないタスクに適しています。無期限延期や、いつ対応するか未定のタスクに使用されることもあります。
ラベルの例: low-priority, on-hold

色彩心理をGitHubラベルで効果的に活用するポイント

一貫性を保つ: 同じ色を一貫して使うことで、視覚的な整理が容易になります。たとえば、常に赤を「高優先度」、緑を「完了」に使うなど、意味を統一しておくと、誰が見ても直感的に理解しやすくなります。
優先度や重要度を示す: 色の明度や彩度を使い分けて、タスクの優先度や緊急性を区別できます。例えば、赤は高優先度、オレンジは中優先度、黄色は低優先度といった具合に使うと、色だけでタスクの優先度が明確になります。
チームにとって直感的な配色を選ぶ: 色彩心理は文化や個人によって感じ方が異なるため、チーム全体で色の意味に同意しておくことが重要です。ミーティングなどで、色の使い方を統一するルールを決めると、チーム内でのコミュニケーションがスムーズになります。
過度な色の使用は避ける: すべてのタスクに異なる色を使うと混乱を招くことがあります。色の種類を制限して、わかりやすい配色にすることが大切です。

色彩心理を活用することで、GitHubラベルをより直感的で効果的に整理でき、プロジェクトの進捗状況やタスクの重要度を一目で把握しやすくなります。
色の選択が正しく行われると、チームの効率が向上し、プロジェクト管理がよりスムーズに進むでしょう。