Skip to main content

GitHub でのコミュニケーション

GitHub 上でさまざまな種類のディスカッションを用い、特定のプロジェクトや変更について、そしてもっと幅広くアイデアや Team のゴールについて話し合うことができます。

はじめに

GitHub には、コミュニティと密接にやり取りできる、コラボレーション可能なコミュニケーション ツールが組み込まれています。 このクイックスタート ガイドでは、ニーズに適したツールの選択方法について説明します。

行いたい会話の種類に応じて、 行いたい会話の種類に応じて、issue、pull request、および GitHub Discussions を作成して参加できます。

GitHub Issues

  • バグ報告や改善計画、フィードバックなど、プロジェクトの特定の詳細についてのディスカッションに役立ちます。
  • リポジトリに固有であり、通常は明確なオーナーがいます。
  • 多くの場合、GitHub のバグ追跡システムと呼ばれます。

Pull Request

  • 特定の変更を提案できます。
  • 他のユーザーが提案した変更について直接コメントできます。
  • リポジトリに固有です。

GitHub Discussions

  • フォーラムのようなもので、コラボレーションが重要なオープン形式のアイデアやディスカッションでの使用に最適です。
  • 多数のリポジトリにまたがる場合があります。
  • コードベースの外部でコラボレーション エクスペリエンスを提供し、アイデアのブレーンストーミングとコミュニティのナレッジ ベースの作成を可能にします。
  • 多くの場合、明確なオーナーはいません。
  • 多くの場合、操作可能なタスクは発生しません。

どのディスカッション ツールを使用すべきか

issue のシナリオ

  • タスク、機能強化、バグを追跡したい。
  • バグ報告を提出したい。
  • 特定の機能に関するフィードバックを共有したい。
  • リポジトリ内のファイルについて質問したい。

問題の例

この例では、GitHub ユーザーがどのようにしてドキュメント オープン ソース リポジトリに issue を作成してバグを認識させ、修正プログラムについて話し合うかを示しています。

"通知内の青いリンクのテキストが青の背景で読み取れない" というタイトルの issue のスクリーンショット。

  • あるユーザーが、中国語版の GitHub Docs のページ上部にあるバナーの青い色で、バナー内のテキストが読めなくなることに気付きました。
  • そのユーザーはリポジトリに issue を作成し、問題について述べ、修正プログラム (バナーに別の背景色を使用する) を提案しました。
  • ディスカッションが続き、最終的には、修正プログラムの適用に関する合意に達します。
  • これで、共同作成者が修正プログラムを含む pull request を作成できます。

pull request のシナリオ

  • リポジトリの入力ミスを修正したい。
  • リポジトリに変更を加えたい。
  • 変更を加えて issue を修正したい。
  • 他の人によって提案された変更についてコメントしたい。

プル要求の例

この例では、GitHub ユーザーがどのようにしてドキュメント オープン ソース リポジトリに pull request を作成して入力ミスを修正するかを示します。

pull request の [会話] タブで、作成者が pull request を作成した理由を説明します。

pull request の [会話] タブのスクリーンショット。

pull request の [ファイルの変更] タブには、実装された修正プログラムが表示されます。

pull request の [ファイルの変更] タブのスクリーンショット。

  • この共同作成者は、リポジトリの入力ミスに気付きました。
  • このユーザーが、修正プログラムを含む pull request を作成します。
  • リポジトリの保守担当者は、pull request を確認し、それにコメントを付けてマージします。

GitHub Discussions のシナリオ

  • リポジトリ内の特定のファイルに必ずしも関連していない質問がある。
  • コラボレーターやチームとニュースを共有したい。
  • 自由回答の会話を開始または参加したい。
  • コミュニティで発表を行いたい。

GitHub Discussions の例

この例では、GitHub Docs オープン ソース リポジトリの GitHub Discussions ウェルカム投稿を示し、チームがコミュニティとどのようなコラボレーションを望んでいるかを示しています。

ディスカッションの例のスクリーンショット。"Welcome to GitHub Docs Discussions" (GitHub Docs のディスカッションへようこそ) というタイトルです。

このコミュニティ保守担当者は、コミュニティを歓迎し、メンバーに自己紹介を求めるディスカッションを始めました。 この投稿は、訪問者と共同作成者が参加しやすい雰囲気を生み出します。 この投稿では、チームがリポジトリへの投稿を喜んで支援することも明らかになっています。

次の手順

これらの例では、GitHub で会話に最適なツールを決定する方法を示しました。 しかし、これは始まりにすぎません。これらのツールをニーズに合わせて調整するためにできることは、他にもたくさんあります。

たとえば、issue の場合は、より迅速に検索できるように issue にラベルをタグ付けしたり、共同作成者が有意義な issue をオープンできるように issue テンプレートを作成したりできます。 詳細については、「Issueについて」および「Issueとプルリクエストのテンプレートについて」を参照してください。

pull request の場合、提案された変更がまだ進行中の場合は、下書きの pull request を作成できます。 下書きの pull request は、レビュー準備完了としてマークされるまでマージできません。 詳しくは、「pull requests について」を参照してください。

GitHub Discussions の場合は、行動規定を設定し、コミュニティの重要な情報を含むディスカッションをピン留めすることができます。 詳しくは、「ディスカッションについて」を参照してください。

コミュニケーションに役立つ高度な形式については、「GitHub 上での書き込みに関するクイックスタート」を参照してください。