私は2015年11月にDomCodeで講演しました（ちなみに、すばらしい会議です。小さな美しい町で開催されました）。オープンソースコミュニティを構築するためのルールのリストについて話しました。 ある人は後で、継続的インテグレーションのテストが完了するのを待たずに、コードを再確認せずに、パッチをすばやくマージすることを勧める理由を説明するように頼みました。 この戦略を楽観的統合（OM）と呼びます。 そして、その利点のいくつかについてお話します。
多くのコミュニティの標準的なプラクティスは、悲観的マージ（PM）です。 これは、継続的な統合テストが完了するまで最初に待機する必要がある場合です。次に、コードを確認し、ブランチでパッチをテストし、作成者にフィードバックを行います。 その後、彼だけがパッチを修正でき、このサイクル全体が新たに始まります。 この段階では、メンテナーは簡単に言うことができます：「私はあなたがこれをどのようにしたのが好きではない」または「これはプロジェクトのビジョンと一致しません。」
最悪の場合、パッチが受け入れられるまで数週間から数か月かかる場合があります。 まあ、あるいは、彼らは決して受け入れられないかもしれません、そして、彼らは何千もの異なる理由で拒絶されます。
多くのプロジェクトで、PMの概念は多少誤解されているように思えます。 PMが作成する問題をリストしてみましょう。
- 彼は、参加者に「他の方法で証明されるまであなたは有罪である」と言っています。 そして、このネガティブなメッセージはネガティブな感情を引き起こします。 安心している参加者は、常にこのプロジェクトの代替案を探します。 参加者を追い払うのは悪いことです。 しかし、さらに悪いことに、静かで静かな敵になってください。
- 彼は 、多くの人が虐待している貢献者に対して 、 ある程度の保護を提供しています。 彼らは無意識のうちにこれを行うことができます。 ただし、この問題は広まっています。 本質的に同行することは、常にプロジェクトの主要なものであり続けるよう努めます。 また、潜在的な競合他社を遠ざける機会があれば、それを行います。
- それは差別に道を譲ります。 プロジェクトは付随するものに属しているため、彼らは誰と仕事をするかを選択する機会があると主張することができます。 私の意見：参加者の間に不一致があるプロジェクトは死に、それに値するでしょう。
- 学習サイクルが遅くなります。 イノベーションには、高速で実験的に成功するサイクルが必要です。 それらのいくつかは、問題を発見したり、製品が効果的でないことを理解するのに役立ちます。 修正を行うものもありますが、それらはテストされ、動作するか、失敗します。 だから私たちは何か新しいことを学びます。 このサイクルが速くなるほど、プロジェクトはより速く、より正確に進みます。
- 部外者がプロジェクトを「トロール」する機会を提供します。 これは、次のパッチが拒否されたときと同じように起こります：「私はこのコードが好きではありません。」 詳細を議論することは、コード自体を書くよりもはるかに多くの労力を要する可能性があります。 さらに、完成したパッチを書くよりも非難する方がはるかに簡単です。 これはすべて、トロールにとっては蜜であり、正直な貢献者にとっては罰です。
- 彼はそれぞれの貢献者に別々の仕事を負わせていますが、それはオープンソースになると同時に皮肉で悲しいものです。 「私たちは協力したいのですが、バグを個別に修正するように求められました。」
では、これがOptimistic Merge（OM）でどのように発生するかを見てみましょう。
まず、すべてのパッチとすべての貢献者が異なることを理解しています。
オープンソースプロジェクトでは、少なくとも4種類の貢献者がいます。
- ルールを知っていて、すばらしいパッチを書いてくれる良い貢献者。
- 間違いを犯し、大量のバグを含む有用なパッチを作成する良い貢献者。
- 誰も必要としないパッチを書く平凡な貢献者。
- ルールを無視して悪意のあるパッチを作成する密輸業者をトロールします。
PMの概念は、クリーンで有用であると認識されるまで、すべてのパッチが悪意があるという事実に基づいています。 実際には、ほとんどのパッチは最初は有用であり、改善する価値があります。
PMとOMを比較しましょう。 4種類すべての貢献者が一貫してプロジェクトに参加するとどうなりますか？
- PM：任意の基準に応じて、マージパッチは高速または低速になります。 そして、少なくとも1人の良い貢献者は不幸なままです。
OM：良い貢献者は喜んで感謝し、プロジェクトに合格するまですばらしいパッチを書き続けます。 - PM：貢献者は引き返し、パッチを修正し、やや戻ってきます...屈辱。
OM： 2番目のタイプの貢献者が参加して、最初のパッチを修正します。 短いクールなパッチパーティーがあります。 新しい貢献者には、プロジェクトに友人とメンターがいます。 - PM：私たちは口頭での小競り合いと、社会が敵対的である理由の理解不足に陥ります。
OM：誰もが平凡な貢献者を無視します。 パッチを修正する必要がある場合、これは遅滞なく行われます。 寄稿者は興味を失い、最終的にプロジェクトを去ります。 - PM ：私たちは、トロルが引数のブルートフォースによって勝つ小競り合いを獲得します。 コミュニティは嫌なパッチを押しています。
OM：すべての既存の貢献者はすぐにプロジェクトに戻ります。 議論はありません。 トロールは再び攻撃を試みる可能性があり、最終的には禁止されます。 悪意のあるパッチは、gitaの歴史に永遠に残るでしょう。
これらの状況のそれぞれにおいて、OMの結果はPMの結果よりもはるかに優れています。
ほとんどの場合（まだ多くの作業が必要なパッチの場合）、OMはトレーニングとメンタリングの条件を作成します。 そして、これはまさにZeroMQプロジェクトで見られるものであり、彼らと仕事をするのがとてもクールな理由です。
参照：
ZeroMQ（http://rfc.zeromq.org/spec:22)、C4.1：集団コード構築契約。
さらにいくつかのヒント：
- 最初に人々、次にコード。 適切なコミュニティを収集すると、必要なコードが作成されます。
- 最初に進捗状況、次にコンセンサス。 あなたが達成する最終的な進歩は、最初に確立された合意よりも重要です（ルールは考慮しません）。
- 最初の問題、次に解決策。 プロセスは、解決される問題に基づいている必要があります。
- 最初のルール、次に期待。 開発プロセスを記録するか、ルールC4.1を使用します。
- 最初のメリット、次に権限。 全員を公正かつ公平に扱います。
- 最初に市場、次に製品。 製品を作成するだけでなく、競合する共同プロジェクトの市場を目指してください。
翻訳：アレナ・カルナウコワ
出版サポート-Edisonは 、 プロバイダー向けの課金システムを 開発し、インターネットを介した税申告用ソフトウェアも開発しています 。