オープンソースプロジェクトに参加する難しいプログラマーに対処するにはどうすればよいですか？

特定のサイト用のオープンソーススクリプトがあります（ここでは名前を付けないようにしています）。私と他の少数の開発者が最近GitHubに移動しました。特に非常にアクティブなシステムを含め、新しいシステムに移行して以来、いくつかの新しい開発者を獲得しています。しかし、このアクティブなものはプロジェクトの多くを変え始めました。

まず最初に、彼はバージョン管理システムを削除し（Gitのようではなく、そのように-バージョンと呼びますv4.1.16）、準備ができたと思われるときにコードを単にサイトにプッシュする方が良いと言いました。今では、リリースノートを置く一元化された場所はありません。

荷物をまとめて行く準備ができたのは、プッシュスクリプトでした。プロジェクトの別の開発者は、単純なPythonベースのプッシュスクリプトを作成しました。さまざまな場所で複数のバージョンのスクリプトをオンラインで保持しているため、Pythonスクリプトに代わるグラフィカルインターフェイスを備えたより大きなJavaプログラムのコーディングを開始しました。私はIRCに行ってそれをみんなに通知し、古いPythonベースのスクリプトが私のできることをすべて行うことができ、はるかに軽量であると言って非常に迷惑な応答を得ました（彼はまた彼が考えた事実についてコメントしましたPythonはJavaなどよりも優れていました）。古いプッシュスクリプトのコードを調べたところ、彼が言った機能がどれも存在しないことがわかりました。

だから今、私は何をすべきかを知りたいです。私はこのプロジェクトに多くの時間を費やしてきたので、ただ立ち上がって去りたくありませんが、この新しい開発者と仕事をするのは難しいと感じています。反対に、彼は現在、プロジェクトのトップコミッターであり、主任開発者よりも多くのコミットを行っています。私はこれについてどうすればいいのかよく分かりません。他の誰かがこの問題を経験しましたか？もしそうなら、あなたは何をしましたか？

更新1：全員のコミットアクセスを無効にし、プルリクエストを通過するように要求しています。他の問題を解決するためのいくつかの手段も提案しました。他の人は誰もそれをサポートしていません。面倒な開発者は、「コミットアクション」に従わない人は、プロジェクトが実際にはそうでない場合でも混乱していると考えることができると単純に言っています。私は明らかにこれに同意しないので、プロジェクトから辞任することを真剣に考えています。

更新2：リード開発者は、私のコミットの1つがコード内の3つの改行を削除したという事実について暴言を始めました（リバートコミットはディスカッションを投稿した直後に表示され、「コミット」も参照しません）。 2人は私のコミットアクセスを取り消すかどうかの議論を始めました。だから、私は論理的なことをして、プロジェクトを去った。皆さんのご協力に感謝します！

1. 終了できます。最も建設的なことではありませんが、それが唯一の選択肢である場合もあります。もしそうなら、それをあきらめなければならなかったと嘆き悲しんではいけません。

2. フォークできます。誰とでも仕事をしなければならない理由はありません。分岐して、コードを改善し、他の人が自分自身の小さなエゴフェストを続けられるようにします。あなたの新しいプロジェクトは、あなたがそれを成功させるか、古いプロジェクトがユーザーと機能の点であなたを打ち負かすかどうかにかかわらず、単に古いものとあなた次第です。

3. あなたは従事することができ、あなたの懸念を表明するためにプロジェクトの開発チームの残りの部分。個人的にはしないでください。コードチャーンや確立された品質プロセスに不満を抱いていること、または新しい決定が全員の同意なしにただ押し出されていることに不満を抱いていることを確認してください。変更するのに十分な問題はないと告げられるか、チームが問題を修正する必要があることを他の人に同意してもらうことができます。その結果、破壊的な男がコミットアクセスを失う可能性があります。おそらく、変更の一部は改善ではなく、プロジェクトを元に戻す必要があることに同意するでしょう。（この後者のオプションは、確固たる意見の大規模な議論にならない限り、最も可能性の高い結果です。）

誰かがやって来て、慣れてきた安全で快適なルーチンを変えるのは難しいかもしれませんが、誰かが一緒に来て、古い居心地の良い習慣を揺さぶることは、それ自体で良いことです。

ここであなたの役割が何であるかを正確に理解していません。答えは、あなたがどのように適合するかに依存します。

プロジェクトを主導し、gitリポジトリを制御する場合

コントロールを取り戻します。この人があなたに相談せずにあなたが好きではないコミットをしている場合、彼の直接コミットアクセスを削除してください。彼はプロジェクトを分岐し、プルリクエストを行ってコミットをマージできます。それは、ユーザーが信頼を築くまでオープンソースがどのように機能するかということです。すぐに完全なアクセス権を与える必要はありませんし、そうすべきではありません。

誰かがレポを制御している場合

懸念を表明し、変更を計画および承認するためのより規律あるプロセスを奨励します。リーダーシップがプロセスを受け入れられない場合は、現状を受け入れて貢献し続けることを選択できます。プロジェクトを分岐して独自のバージョンで作業する（同意する人を連れて行く）ことも、離れることもできますそして他のことに取り組む。いずれにしても、これに対処し続ける必要はありません。

私の鈍さを許してください、しかしあなたの投稿は暴言のように読みます。

あなたは他の人が心のない変更を望んでいると言いますが、あなたのこの新しい光沢のあるJavaプログラムについて話すとき、あなたは自分自身に矛盾します。

休憩する; それは一方通行ではありません、妥協点を見つけてください（プロジェクトで作業を続けたい場合-分岐は最も簡単な決定ですが、エゴを打つ可能性がありますが、それはあなたを役に立つ場所に導きません）。

また、プロジェクトの分業についても十分に検討してください。誰が何で有能であるかを明確に示す境界線がない場合、芝の戦争は避けられません。はい、時には他の人の判断を信頼する必要があります。

いくつかの回答ですでに述べたように、分業は紛争を減らす一つの方法です。具体的な例を次に示します。

1. 生産性と安定性のバランスをとります。戦略ゲームから類推を借りるには、チームはBoom、Turtle、Rushの混合で構成され、チームメイトは状況に応じて役割を変更する準備ができていなければなりません。
   • 生産性が大流行しているとき、他の人は次のことに取り組むことができます。
   • その他の機能
   • バグ修正
   • 仕様（新機能のリクエストを管理し、ソフトウェアが合意された基準を満たしていることを確認する）
   • 品質保証
     • 手動（探索的）テスト
     • 自動テスト
   • ドキュメンテーション
   • リファクタリングとコードのクリーンアップ
   • ユーザー調査を実施して、改善のためのアイデアを収集する
   • 等
2. プロジェクトはモジュール化（ソフトウェアアーキテクチャのように）することも、プロジェクト管理のようにコンパートメント化することもできるため、各モジュールを個別に操作できます。
   • 一般に、フロントエンドとバックエンドの両方を含むほとんどのソフトウェアは、開発速度が異なるため、モジュール化する必要があります。
   • UXが豊富なソフトウェアは、モジュール間のイベントルーティングを頻繁に使用するため、モジュール化が難しい場合があります。
   • プロジェクトのメンテナーは、モジュール化を避けることでプロジェクトをシンプルに保ちたい場合があります。
3. 機能ブランチ。各開発者は、プロジェクトを分岐し、お気に入りのペット機能に取り組み、実装が完了したらマージを要求できます。リード開発者は、マージを受け入れるかどうかについて最終決定権を持つことができます。

紛争回避の側面は別として、プロジェクトのガバナンスが不十分である可能性があることは明らかです。

ガバナンスが重要な理由 ある日、元チームメイトがソフトウェアの一部を取り、侵害を理由にチームを訴えたと想像してください。または、チームがパテントトロールで訴えました。または、誰も知らない人がDMCA通知をプロジェクトホスティングサイトに送信し、プロジェクトのソースコードの消去を要求することを決めました。

最低でも：

• 提供されたすべてのソースコードで使用されるライセンス
• プロジェクトのソースコードを公開できるライセンス
  • 新しいパブリックライセンスが必要な場合、すべての貢献者から同意を得る方法
• プロジェクトへの管理アクセス権を持つことができる人
• 法的要求（DMCA通知やパテントトロールなど）に応答するために指定されるのは誰ですか
• プロジェクトの資金管理を誰が行うか（サーバー費用の支払いと広告収入または寄付の簿記）
• 誰が新しいメンバーを含め、メンバーを追放する投票権を持ちます。
• 等

ほとんどのオープンソースプロジェクトサイトは、既成のプロジェクトガバナンス憲章を提供できます。

私は前に問題を見たことがあります。しかし、数年後、あなたはプロジェクトに本当に飽きるので、私の解決策はプロジェクトを去ることでした。それはあなたにはうまくいかないかもしれませんが、問題は根本的に異なる人々が異なる方法で考えることです。あなたが非常に重要だと思う機能は、他の人にとってはまったく重要ではありません。

適切な計画は、異なる人々のタスクを分割することです。プロジェクトのどの部分が各人の責任にあるかについて同意できる場合、プロジェクトの特定の部分について決定を下しているのは1人だけです。しかし、チームワークは常に困難です。あなたはまだ他のプログラマーによって下された決定が好きになることは決してありません。最善の解決策は、他のプログラマーが決定したことを見ないことです。正しいことをするだけで十分です。

共通の目標は、重要なことにあなたの努力を集中させます。同じ方向に取り組むすべての人を獲得することは困難であり、とにかく対立は起こります。共通の目標を決定するには、プロジェクトの現在のステータスを把握してから、しばらくしてからプロジェクトの場所を決定する必要があります。

避けるべきものの例を次に示します。たとえば、多数のc ++プログラマーは、STLライブラリを使用していないコードが壊れていると考えています。他のプログラマは、STLを含め、外部ライブラリへのすべての依存関係が壊れていると考えています。そのような対立は適切に解決できません-両方の状況を同時に満たすことはできません-そして、最も問題のある人々は、彼らがどんな対立に直面しても意見を押し進めます。

4つの選択肢があります。

1. 彼を追い出します。あなたは（と言われていますが）まだこのプロジェクトの主人です。彼のプッシュ権限を取り消して、1日と呼びます。最も可能性の高い結果は、彼がプロジェクトをフォークし、コミュニティを分割し、その後戦争が解散し、埃が落ち着くと、フォークの1つが人気のものになります。
2. それをフォークして、他の場所で続行します。1より攻撃的ではありませんが、その他の結果は同じです。ただし、人々をあなたの側に引き寄せるためには、コミュニティで積極的に活動する必要があります。
3. そのままにしておきましょう。ただ彼に彼がしていることをさせて、落ち着いて、最高のことを願ってください。
4. コミュニティと話し合い、必要に応じて妥協し、状況を解決します。

個人的には、オプション4を好みます。

Googleは、数年前にこれについていくつかの技術的な講演を行いました。それらを見てください：1、2。手短に：

1. 理解：他のすべての機会費用対プロジェクト上で動作するようにあなたのコミュニティのモチベーションを理解し、それらの理由を維持します。
2. Fortify：礼儀正しさ、敬意、信頼、謙虚さの社会的規範を持つ健全なコミュニティを構築します
3. 識別する：有毒な人々の物語の兆候を探します（リストするには多すぎますが、この質問をしているのであれば、おそらくすでに多くの人々を知っています）。
4. 消毒：落ち着いて自分の立場を保ち、in辱、軽微、挑戦、無礼などに反応しないようにし、コミュニティの規範を強化することに固執します。

包括的な書かれたアウトラインがあなたの代わりに時計を読むことを好む場合は、あまりにも使用可能です。

心配や困難を表明する努力をせずに、ただやめることはできません。難しいことはわかっています。実際、あなたとあなたのチームメンバーが、開発チームで起こっている多くの社会問題を直接体験できないほど若ければ、それは本当に難しいことです。

そうは言っても、懸念を表明すべきだと強く信じています。それらをメールに書き留めて、チームのメンバーではなく、自分の活動にまったく関心がないか、ほとんど関心がない信頼できる友人に見せることができます。この場合、電子メールの文言が厳しすぎないように、良いフィードバックを得ることができます。ただし、事実に固執します。責めたり責めたりしないでください。「blah」が欠落しているため、あなたのために何かをするのは難しいという事実だけです。「blah」が欠落している理由は、すべてのチームメンバーに明確である必要があります。つまり、「新しいプログラマ」が削除されたか、何かを達成しなかったのです。

繰り返しになりますが、この電子メールの送信は難しいですが、それ自体は素晴らしい経験であり、今後のあなたにとって非常に役立つかもしれません。学ぶべき素晴らしい教訓。

PS：親のように聞こえるつもりはなかった。しかし、それは確かに、私の子供たちを含む誰にも言えることです。