コミュニティの役割 ¶

完全コミットアクセスの付与方法 ¶

誰かがいくつかの重要なパッチを正常に寄稿した後、通常は、その寄稿者からの最も多くのパッチをレビューおよび適用したコミッターが、コミットアクセスを提案します。この提案は他の完全アクセスコミッターのみに送信されます。続く議論は非公開であるため、誰もが自由に意見を述べることができます。異議がないと仮定すると、寄稿者にはコミットアクセスが付与されます。決定はコンセンサスによって行われます。手順を規定する正式なルールはありませんが、一般的に、誰かが強く反対した場合、アクセスは提供されなかったり、暫定的に提供されたりします。

完全コミットアクセスの主な基準は、良好な判断力です。

完全コミッターになるために、テクニカルウィザードである必要も、コードベース全体の深い知識を示す必要もありません。自分が知らないことを知っているだけで十分です。パッチがこのファイルのガイドラインに従っており、コーディングの通常の定量化できないすべてのルール（コードは可読性が高く、堅牢で、保守可能であるなど）に従っており、ヒポクラテスの誓い「まず、害をなさない」を尊重している場合、おそらくすぐにコミットアクセスを得られるでしょう。パッチのサイズ、複雑さ、量は、バグを回避し、コードの残りの部分への不要な影響を最小限に抑えることに示す注意の程度ほど重要ではありません。多くの完全コミッターは、大きなコードの貢献をした人ではなく、多くの小さな、クリーンな修正をした人々です。それぞれがコードへの明確な改善でした。（もちろん、これは、プロジェクトがコミットアクセスを得る唯一の目的である非常に些細なパッチをたくさん必要としているという意味ではありません。どの修正がパッチ投稿に値するのか、どの修正がそうでないのかを知ることは、良好な判断力を示す一部です :-) 。）

開発者が新しいコミッターを発見するのを支援するために、特別なクレジット形式でパッチやその他の貢献を記録しています。これは、ブラウザフレンドリーな貢献リストを生成するために解析され、毎晩更新されます。コミットアクセスを提案することを考えていて、すべての変更を確認したい場合は、貢献リストが最も便利な場所かもしれません。

部分コミットアクセスの付与方法 ¶

完全アクセスコミッターが部分アクセスコミッターをスポンサーします。通常、これは完全アクセスコミッターが提案された部分アクセスコミッターから同じ領域にいくつかのパッチを適用しており、その人が直接コミットした方が簡単だと認識していることを意味します。招待状を出す前にprivate@に候補者を提示するのが慣例であり推奨されていますが、必須ではありません。スポンサーは、良好な判断力を使用することが信頼されています。

スポンサーは、すべてが順調に進んでいることを確認するために、部分アクセスコミッターの最初のいくつかのコミットを監視します。

部分アクセスコミッターによって提出されたパッチは、その人のドメイン外であっても、そのコミッターによってコミットできます。これには、少なくとも1人の完全アクセスコミッターからの承認（多くの場合、+1投票として表現されます）が必要です。そのような場合、承認はログメッセージに次のように記載する必要があります。

   Approved by: lundblad

任意の完全アクセスコミッターは、いつでも実験ブランチへのコミットアクセスを誰にでも提供できます。実験ブランチがtrunkにマージされる可能性が高い必要はありません（ただし、常に目指すべき目標です）。完全アクセスコミッター—実際にはすべての完全アクセスコミッター—がそのようなブランチを、コミットに関するフィードバックを与えることで、新しい開発者のためのトレーニンググラウンドと見なすことも同様に重要です。軽量ブランチに関するセクションとこのメールも参照してください。

   https://svn.haxx.se/dev/archive-2007-11/0848.shtml
   From: Karl Fogel <kfogel@red-bean.com>
   To: dev@subversion.tigris.org
   Subject: branch liberalization (was: Elego tree conflicts work)
   Date: Tue, 20 Nov 2007 10:49:38 -0800
   Message-Id: <87y7cswy4d.fsf@red-bean.com>

contrib/領域 ¶

ツールがcontrib/領域に受け入れられると、その作成者には、そこでツールを維持するための部分コミットアクセスが自動的に提供されます。任意の完全アクセスコミッターがこれをスポンサーできます。通常、議論や投票は必要ありませんが、異議がある場合は、通常の意思決定手順が適用されます（最初にコンセンサスを得ようとし、コンセンサスを得られない場合は完全アクセスコミッターの間で投票します）。

contrib/下のコードはオープンソースである必要がありますが、Subversion自体と同じライセンスや著作権所有者である必要はありません。

"明らかな修正"ルール ¶

完全アクセスコミッターと部分アクセスコミッターのいずれのコミッターも、ウェブページ、APIドキュメント、コードコメント、コミットメッセージなど、どこにいても、明らかなタイプミス、文法ミス、フォーマットの問題を修正できます。「明らか」とは何かを判断する際には、コミッターの判断に依存します。確信が持てない場合は、尋ねてください。

"明らかな修正"ルールを呼び出すときはいつでも、コミットのログメッセージでそうしてください。例えば

------------------------------------------------------------------------
r32135 | stylesen | 2008-07-16 10:04:25 +0200 (Wed, 16 Jul 2008) | 8 lines

Update "check-license.py" so that it can generate license text applicable
to this year.

Obvious fix.

* tools/dev/check-license.py
  (NEW_LICENSE): s/2005/2008/

------------------------------------------------------------------------

ゲストコミッター ¶

SubversionはASFの一部であり、100以上の他のASF プロジェクトと同じリポジトリを共有しています。これらのプロジェクトのコミッターは、Subversionの完全アクセスコミッターまたは部分アクセスコミッターとは見なされませんが、明らかな修正や、提出したパッチ（パッチが+1を完全アクセスコミッター（またはそのドメイン内の部分アクセスコミッター）から受け取っている場合）をコミットできます。どちらの場合も、ログメッセージのガイドラインに従ってください。