Git プロジェクトにおける意思決定プロセス

このドキュメントでは、 Git プロジェクトにおける現在の意思決定プロセスについて説明します。 これは、 規範的な文書ではなく、 説明的な文書です。 つまり、 特定のプロセスや現在のプロセスへの変更を明示的に推奨するのではなく、 実際に物事がどのように機能するかを説明したいと考えています。

ここでは、(SubmittingPatches 文書で完全に網羅されている、)個々のパッチシ・リーズよりも大きな規模で、プロジェクトが(パッチの有無にかかわらず)、議論のためにどのように決定を下すかを文書化します。

それぞれのパッチのシリーズに伴う議論と同様、 大規模な議論を開始するには、 多くの場合、 パッチまたはシリーズをメーリング・リストに送信することから始めます。 これは、 初期設計ドキュメントの形式をとり、 その後のシリーズの繰り返しで実装が行われる場合(例えば adding unit tests or config-based hooks)もあれば、 最初から完全な実装が含まれる場合もあります。 いずれの場合も、 合意に達するかトピックが取り下げられるまで、 個々のパッチ・シリーズについて同じように議論が進行します。

場合によっては、 関連するパッチ・シリーズなしで大規模な議論が行われることがあります。 これらは単一の大規模なパッチ・シリーズの範囲を超えた非常に大規模な技術的な決定である場合もあれば、 より自由なポリシー指向の議論である場合もあります(例: introducing Rust or improving submodule UX)。 いずれの場合も、 一般的なパッチ・シリーズについては上記で説明したように議論が進みます。

パッチ・シリーズやその他の具体的な実装を伴わない大規模な議論の場合、 公式のガイドラインがないため、 いつ合意に達したかを判断するのが難しい場合があります。この時点で議論が行き詰まった場合は、 より簡単に議論できる RFC パッチ・シリーズ (部分的で未完成の実装や概念実証など) を使って議論を再開すると役立つかもしれません。

その提案が良いアイデアであるという合意に達した場合、 最初の提案者は、 必要に応じて、 議論に参加した他の人の助けを得ながら、 それを実現するための取り組みをコーディネイトすることが期待されます。

コードの変更が必要な決定の場合、 最初の提案者が一連のパッチをフォローアップ送信することがよくありますが、 他の利害関係者が実装(または非常に大規模な変更の場合は実装の一部)を提供することもよくあります。

コミュニティの規範やプロセスなどの非技術的な決定については、 合意された変更を実装し維持するかどうかはコミュニティ全体にかかっています。 プロジェクト指導委員会 (PLC) は、 政策決定の実施を支援する場合があります。

場合によっては、 決定案がメーリング・リスト外で提示されることもあります。 たとえば準定期的に開催される貢献者サミットです。 帯域幅の広い対面での議論は、 出席者間で迅速に合意に達するのに役立つことがよくありますが、 一般的には議論をノートに要約し、 後でメーリング・リスト上で提示できるようにすることが期待されます。 例えば、 次のスレッドを参照してください Notes from Git Contributor Summit, Los Angeles (April 5, 2020) by James Ramsay.

私たちは、 コミュニティ全体が議論に参加する機会を得るために、 メーリング・リスト上で「公式」の議論が行われることを好みます。 これは、 メーリング・リストのアーカイブには、 プロジェクトの議論と決定に関する多かれ少なかれ完全な履歴が含まれていることも意味します。