オープンソースプロジェクトに参加する難しいプログラマーに対処するにはどうすればよいですか？
特定のサイト用のオープンソーススクリプトがあります（ここでは名前で何も呼び出さないようにしています）。私と他の数人の開発者が最近GitHubに移動しました。特に非常にアクティブなシステムを含め、新しいシステムに移行してから数人の新しい開発者を獲得しました。しかし、このアクティブなプロジェクトは、プロジェクトの多くを変え始めました。
まず、バージョン管理システムを削除しました（Gitとは異なりますが、そのように-バージョンと呼びますv4.1.16）そして、準備ができたと思ったら、単にコードをサイトにプッシュする方が良いと述べました。現在、煩わしくなったリリースノートを一元的に配置する場所はありません。
バッグを詰め込んですぐに使えるようになったのは、Pushスクリプトでした。プロジェクトの別の開発者が、Pythonベースの単純なプッシュスクリプトを作成しました。スクリプトの複数のバージョンをさまざまな場所でオンラインに保持しているので、Javaスクリプトに代わるグラフィカルインターフェイスを備えた、より大きなPythonプログラムをコーディングしました。 IRCについてそれをみんなに通知しました、そして私はプログラマーから非常に迷惑な応答を受け取りました、古いPythonベースのスクリプトは私のことができるすべてを行うことができ、はるかに軽量です（彼はPythonはJavaなど）より優れていると彼が考えたという事実についてもコメントしました。）古いPushスクリプトのコードを調べてみたところ、どれも見つかりませんでした彼が存在すると言っていた特徴がそこにあった。
だから今私は何をすべきかを知りたいです。私はこのプロジェクトに多くの時間を費やしてきたので、立ち上がって去るだけではなく、この新しい開発者と一緒に仕事をするのは難しいと感じています。反対に、彼は現在、プロジェクトの＃1コミッターであり、主任開発者よりも多くのコミットがあります。私はこれについて何をすべきか本当にわからない。他の誰かがこの問題を経験しましたか？もしそうなら、あなたは何をしましたか？
PDATE 1：全員のコミットアクセスを無効にし、プルリクエストを実行するように要求しています。他の問題を修正するためのいくつかの対策も提案しました。他の誰もそれに対するサポートを示していません。厄介な開発者は、「コミットアクション」を厳密に守らない人は、プロジェクトが実際にはそうでない場合でも無秩序であると考えることができると単純に述べています。私は明らかにこれに同意しないので、プロジェクトの辞任を真剣に考えています。
PDATE 2：主要な開発者が、私のコミットの1つがコード内の3つの改行を削除したと思われるという事実について怒鳴り始めました（元に戻すコミットは、ディスカッションを投稿した直後に表示され、私を参照していません"commit"）、その後、2人は私のコミットアクセスを取り消すかどうかについて話し始めました。それで、私は論理的なことをしてプロジェクトを去りました。みなさん、助けてくれてありがとう！
終了できます。最も建設的なことではありませんが、それが唯一のオプションである場合もあります。もしそうするなら、周りに座って、それをあきらめなければならなかった方法についてうめき声を出さず、そのエネルギーを取り、それを他の何かにまっすぐに入れてください。
あなたはそれをフォークすることができます。誰かと協力しなければならない理由はありません。フォークして、コードを改善し、他の人たちが自分自身の小さなエゴフェストを持ち続けるようにしましょう。あなたの新しいプロジェクトは、あなたがそれを成功させるかどうかにかかわらず、古いものとその次第で単純に競争します、または古いものはユーザーと機能の点であなたを打ち負かします。
あなたは従事することができますプロジェクトの残りの開発チームと一緒にあなたの懸念を表明してください。個人的なことはしないでください。ただし、コードのチャーン、または確立された品質プロセスの欠如に不満があること、または新しい決定が全員の同意なしに押し出されたことに不満があることを確認してください。変更するのに十分な問題はないと言われるか、チームが問題を修正する必要があると同意する人が何人かいます。それは、破壊的な男がコミットアクセスを失うことになるかもしれません。たぶん皆さんは、一部の変更が改善ではなく、プロジェクトを元に戻す必要があることに同意するでしょう。 （この後者のオプションは、定着した意見の大規模な議論にならない限り、最も可能性の高い結果です。）
誰かがやって来て、慣れ親しんだ安全で快適なルーチンを変更するのは難しいかもしれませんが、誰かが一緒に来て古い居心地の良い習慣を揺さぶることは、それ自体が良いことだと言えるでしょう。
あなたは自分の役割がここで何であるかを正確に少し不明確にしました。答えはあなたがどのように適合するかに依存します。
プロジェクトをリードしていて、gitリポジトリを制御している場合
コントロールを取り戻す。この男があなたに相談せずにあなたが好きではないコミットをしているなら、彼の直接コミットアクセスを削除してください。彼はプロジェクトをフォークし、プルリクエストを作成してコミットをマージできます。これは、ユーザーが信頼を築くまでのオープンソースの動作方法です。すぐに完全なアクセス権を与える必要はなく、与えるべきではありません。
他の誰かがリポジトリを制御している場合
懸念を表明する人に表明し、変更を計画および承認するためのより規律のあるプロセスを奨励します。リーダーシップがプロセスの影響を受けない場合は、現状を受け入れて貢献し続けることを選択できます。プロジェクトをフォークして、独自のバージョンで作業する（同意する人を連れて行く）か、そのままにするかを選択できます。そして、他のものに取り組みます。いずれにしても、これに対処し続ける必要はありません。
私の鈍さを許してください、しかしあなたの投稿は暴言のように読みます。
あなたはそれが無頓着な変更を望んでいる他の男だと言います、しかしあなたはこのあなたのこの新しい光沢のあるJavaプログラムについて話すときあなた自身と矛盾します。
休憩する;それは一方通行ではありません妥協点を見つけてください（プロジェクトで作業を継続したい場合-フォークするのが最も簡単な決定ですが、ストロークする可能性はありますが、役立つ場所はありません。あなたの自我）。
プロジェクトの労働の分割についても十分に検討してください-誰が何に対応できるかを告げる明確な境界線がない場合、芝生戦争は避けられません。はい、時々他の人の判断を信頼する必要があります。
労働の分割は紛争を減らすための1つの方法であると、いくつかの回答ですでに言及されています。ここにいくつかの具体的な例があります：
- 生産性と安定性のバランスをとります。戦略ゲームから類推を借りるには、チームは ブーム、タートル、ラッシュ の組み合わせで構成される必要があり、チームメイトは状況に応じて役割を変更する準備をしてください。
- 1つが生産性の大流行にあるとき、他の人は次のことに取り組むことができます。
- その他の特徴
- バグ修正
- 仕様（新機能のリクエストを管理し、ソフトウェアが合意された基準を満たしていることを確認する）
- 品質保証
- 手動（探索的）テスト
- 自動テスト
- ドキュメンテーション
- リファクタリングとコードのクリーンアップ
- ユーザー調査を実施して改善のためのアイデアを収集する
- 等.
- プロジェクトはモジュール化（ソフトウェアアーキテクチャのように）、またはコンパートメント化（プロジェクト管理のように）することもできるため、各モジュールを個別に処理できます。
- 一般に、フロントエンドとバックエンドの両方を含むほとんどのソフトウェアは、開発速度が異なるため、モジュール化する必要があります。
- UXが豊富なソフトウェアは、モジュール間のイベントルーティングを頻繁に使用するため、モジュール化が難しい場合があります。
- プロジェクトのメンテナは、モジュール化を回避することにより、プロジェクトをシンプルに保ちたい場合があります。
- 機能ブランチ。各開発者はプロジェクトをフォークし、自分のお気に入りのペット機能に取り組み、実装が完了したらマージを要求できます。主要開発者は、マージを受け入れるかどうかを最終的に決めることができます。
紛争回避の側面を除けば、プロジェクトには不十分な governance がある可能性があることは明らかです。
なぜガバナンスが重要なのですか？ある日、元チームメイトがソフトウェアの一部を取り、チームを侵害で訴えたとします。または、チームは特許トロールで訴えた。または、DMCAの通知をプロジェクトのホスティングサイトに送信し、プロジェクトのソースコードの消去を要求することに決めた誰もが知りません。
最低でも：
- 寄稿されたすべてのソースコードで使用されるライセンス
- プロジェクトのソースコードを公開できるライセンス
- 新しいパブリックライセンスが求められる場合、すべての貢献者から同意を得る方法
- プロジェクトへの管理アクセス権を持つことができる人
- 法的要求（DMCA通知や特許トロールなど）に対応するように指名される人
- プロジェクトの資金を誰が管理するか（サーバーの費用の支払いと広告収入や寄付の簿記）
- 新しいメンバーを含め、メンバーを除名する投票権を誰が持つか。
- 等.
ほとんどのオープンソースプロジェクトサイトは、既成のプロジェクトガバナンス憲章を提供できます。
以前に問題を見たことがあります。しかし、数年後、あなたは本当にプロジェクトに飽きてきたので、私の解決策はプロジェクトを去るでした。それはあなたにとってはうまくいかないかもしれませんが、問題は根本的に異なる人々が異なる方法で考えることです。あなたが非常に重要だと思う機能は、他の人にとってはまったく重要ではありません。
良い計画は、さまざまな人々のタスクを分割するにすることです。プロジェクトのどの部分が各人の責任であるかについて同意できる場合、プロジェクトの特定の部分について決定を行うのは1人だけです。しかし、チームワークは常に困難です。他のプログラマーが下した決定を気に入ることは決してありません。最善の解決策は、他のプログラマーが決定したことを決して見ないことです。彼らが正しいことをするのを信頼するだけで十分です。
共通の目標は、重要なことに集中して取り組みます。誰もが同じ方向に向かって取り組むのは難しく、とにかく紛争が起こります。共通の目標を決定するには、プロジェクトの現在の状態を把握し、しばらくしてからそれがどこにある必要があるかを決定する必要があります。
回避すべき事項の例を次に示します。たとえば、多数のc ++プログラマは、STLライブラリを使用していないコードが壊れていると考えています。他のプログラマーは、STLを含め、外部ライブラリへのすべての依存関係が壊れていると考えています。そのような対立は適切に解決できません。両方の状況を同時に満たすことはできません。そして最も問題のある人々は、どんな反対に遭遇しても、意見をプッシュします。
4つの選択肢があると思います。
- 彼を追い出す。あなたは（申し立てによると）このプロジェクトの主役です。彼のプッシュ特権を取り消し、それを1日と呼びます。最も可能性の高い結果は、彼がプロジェクトを分岐し、そのコミュニティを分割し、その後戦争が解け、粉塵が落ち着くと、フォークの1つが人気のものになるでしょう。
- フォークして他の場所に進みます。 1.よりも攻撃的ではありませんが、結果は同じです。人々をあなたの側に引き寄せるために、あなたはコミュニティで活発でなければなりません。
- そのままにしておきましょう。ただ彼がやっていることをやらせて、落ち着いて、最善を尽くしてください。
- コミュニティと話し合い、必要に応じて妥協し、状況を解決します。
個人的には、オプション4を選択します。
Googleは数年前にこれについていくつかの技術的な話をしました。それらを見る： 1 、 2 。手短に：
- 理解：コミュニティがプロジェクトに取り組む動機と他のすべての機会費用を理解し、それらの理由を保存します。
- Fortify：礼儀正しさ、敬意、信頼、謙虚さという社会規範を備えた健全なコミュニティを構築します。
- 特定する：有毒な人々の明確な兆候を探します（リストするには多すぎますが、この質問をしている場合、おそらくすでに多くのことを知っていますそれら）。
- 消毒：冷静に立ち、地面に立ち、侮辱、軽微、挑戦、軽視などに反応せず、コミュニティの規範を強化することに固執します。
時計ではなく読みたい場合は、 包括的な書面による概要 も利用できます。
あなたはあなたの懸念や困難を表明するための努力をせずにただ辞めることはできません。私はそれが難しいことを知っています。もしあなたとあなたのチームメンバーが、開発チームで起こっている多くの社会問題を直接経験しないほど若ければ、それは本当に難しいかもしれません。
そうは言っても、あなたの懸念を表明するべきだと私は強く信じています。メールにそれらを書き留めて、チームに参加しておらず、自分の行動にまったくまたはほとんど関心がない信頼できる友人に見せることができます。この場合、メールの文言が厳しすぎないように、適切なフィードバックが得られる場合があります。しかし事実に固執してください。非難または非難しないでください。 「何とか」が欠けているためにあなたのために何かをするのは難しいという事実だけです。 「何とか」が欠落している理由は、すべてのチームメンバー、つまり、「新しいプログラマー」が削除したか、何かを達成しなかった場合に明確でなければなりません。
繰り返しになりますが、このメールを送信するのは難しいですが、それ自体は素晴らしい経験であり、今後の作業に非常に役立ちます。学ぶべき素晴らしい教訓。
PS：私は親しすぎるように聞こえるつもりはありませんでした。しかし、それは確かに私の子供たちを含む誰にでも言うことです。