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

はじめに

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

行いたい会話の種類に応じて、issue、pull request、チー�  ディスカッションを作成して参� できます。

GitHub Issues

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

Pull Request

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

Team ディスカッション

• プロジェクトをまたぎ、特定の issue または pull request に属していない会話に対して、チー� のページで開始できます。 アイデアについてディスカッションするためにリポジトリでIssueを開く代わりに、Teamディスカッションで会話することでTeam全体を巻き込めます。
• 計画、分析、設計、ユーザー調査、一般的なプロジェクトの意思決定に関するチー� のディスカッションを 1 か所で行うことができます。
• コードベースの外部でコラボレーション エクスペリエンスを提供し、アイデアのブレーンストーミングを可能にします。
• 多くの� �合、明確なオーナーはいません。
• 多くの� �合、操作可能なタスクは発生しません。

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

issue のシナリオ

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

問題の例

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

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

pull request のシナリオ

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

プル要求の例

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

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

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

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

チー�  ディスカッションのシナリオ

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

チー�  ディスカッションの例

この例は、octo-team チー� のチー� 投稿を示しています。

octocat のチー�  メンバーはチー�  ディスカッションを投稿し、さまざまなことをチー� に通知しました。

• Mona というチー�  メンバーがリモート ゲー�  イベントを開始しました。
• チー� が GitHub Actions を使用してどのようにドキュメントを生成するのかを説明するブログ記事があります。
• April All Hands に関する資料を、すべてのチー�  メンバーが閲覧できるようになりました。

次の手� �

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

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

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

チー�  ディスカッションの� �合は、チー� のページでディスカッションを編集または削除したり、チー�  ディスカッションの通知を構成したりできます。 詳細については、「チー�  ディスカッションについて」を参照してく� さい。

通信に役立つ高度な書式設定機能については、「GitHub での記述に関するクイックスタート」をご覧く� さい。