プロジェクトに不慣れなときに基本的な設計上の欠陥に対処する
約30人の開発者が参加するオープンソースプロジェクトに取り組み始めたところです。私は「ループ」に入り、プロジェクトの定期的なコミッターになる方法として、いくつかのバグの修正に取り組んでいます。問題は、私が取り組んでいるバグの1つを引き起こしている根本的な設計上の欠陥を発見したと思うことです。しかし、これをメーリングリストで爆破すると、傲慢になってしまうような気がします。この問題について私が話し合ったいくつかの議論は、何人かの人々と頭を悩ませています。どうすればいいですか？
これが「基本的な設計上の欠陥」であると確信している場合でも、あなたは部外者であることを忘れないでください。それは正当な理由でそこにある可能性があります。または、プロジェクトの古さによっては、当時の正当な理由でプロジェクトがそこに入れられた可能性がありますが、現在は歴史的な理由でまだ存在しています。
「これをメーリングリストで爆破する」代わりに、質問してみてください。何かのようなもの：
「ねえ、私はちょうどXに遭遇しました、そしてそれは私には意味がありません。これを実装する正しい方法はYであるように思われます、しかしそれから私はここで私が新しいことを知っています、そして私はしたくありません結論にジャンプします。これはデザインの間違いですか、それとも私が欠けているものがありますか？誰かが私に記入できますか？ありがとう。」
エンジニアリングは、謙虚さが今でも真の美徳と見なされている世界でも数少ない場所の1つであり、この方法で「明らかな問題」について質問することは、良い答えを得て新しいことを学ぶための本当に良い方法です。
引数ではなく、アクションで勝つ
議論を通じて得られたと思う瞬間的な勝利は、実際にはピュロスの勝利です。あなたがかき立てる恨みと悪意は、瞬間的な意見の変化よりも強く、長く続きます。言葉を言わずに、あなたの行動を通して他の人にあなたに同意してもらうことははるかに強力です。実演し、説明しないでください。
これは私が多くの無意味な議論の後で難しい方法を学んだものです。
この特定のケースでは、機能するはずの非常に単純で具体的なコードを考え出すことをお勧めしますが、この設計上の欠陥のために機能しません。古いことわざにあるように、「コンパイラ/インタプリタと議論することはできません」。
もう1つは、グループに影響を与えるには、グループのメンバーとして 認識される必要があるということです 。あなたが入社したとしても、人々はあなたをまだグループのメンバーとして認識していません。したがって、彼らがあなたを彼らの一人として認識することを学ぶまで、確立されたグループと一緒に行く方が良いかもしれません。
特定のデザインが使用された理由についてお問い合わせください。そうすれば、あなたが知らない何かが選ばれたいくつかの正当な理由があるかもしれないので、あなたはより多くの裏話を得るかもしれません。あなたはデザインを分解できる専門家ではないという考えに賛成ですが、質問することで詳細を知ることができ、最終的には見つけた欠陥について質問してメッセージが表示されないようにすることができます。フレームベイトまたはトローリングとして。
あなたはおそらくこれを気に入らないでしょう...しかし、ここに行きます...
私は「ループ」に入り、プロジェクトの定期的なコミッターになる方法として、いくつかのバグの修正に取り組んでいます。問題は、私が取り組んでいるバグの1つを引き起こしている根本的な設計上の欠陥を発見したと思うことです。
いいえ、あなたはしませんでした。もしそうなら、あなたはそれについてそれほど躊躇しないでしょう。あなた自身が「根本的な設計上の欠陥」について確信が持てないという事実は、あなたがそれを発見していないことを意味します。他の誰かの間違いを指摘しようとしても、最上級（「基本的」など）を使用するために友達を買うことはありません。
あなたmayが発見したのは、あなたが抱えている問題に対して、わずかに優れた設計です。ただし、おそらく徹底的にテストする必要があります。プロジェクトに不慣れなので、何について話しているのかわからない可能性よりも優れています。
でもこれをメーリングリストで爆破したら傲慢になってしまう気がする
それを「基本的な設計上の欠陥」と呼ぶことは、間違いなく傲慢なものとして出くわすでしょう。さらに言えば、それがmayバグである可能性があることを指摘することさえ、最善の考えではありません。それが問題であることを事実を知らない（そしてそれをバックアップできる）場合は、謙虚に質問し、調査する必要がありますそれを理解する完全に。あなたが説得しようとしている人よりも優れています。
...そしてこの問題について私が行った議論のいくつかは、何人かの人々と頭を悩ませています。どうすればいいですか？
やめる。これは道徳的な問題ではなく、誰も殺していません（私は推測します）。プロジェクトの長期メンバーになる予定の場合は、質問する前にまず信頼を得る必要があります。バグを修正し、（グループが評価するメトリックによって）驚くべき仕事をし、いくつかの機能を設計し、テーブルの席を獲得します。
次に、指を指したり、壊れたものを呼び出したりせずに、グループにデザインを改善するための提案を謙虚に提示します。そして、あなたはすべての結果とそれらに対する解決策を熟考したほうがよいでしょう。さもないと、「ナイーブ」であるために撃墜されるでしょう。なぜあなたのデザインが優れているのかについての議論の準備をしてください。負ける準備をして、優雅に負けてください。
あなたのアイデアが本当に優れている場合、それは最終的にグループに受け入れられるか（おそらく元のデザイナーには受け入れられないかもしれませんが）、グループは気にしないか、グループは愚かです。後者のどちらの場合でも、とにかく、なぜあなたはグループの一員になりたいのですか？
.。
あなたが能力を持っているなら、代替案は、彼らがあなたのコーディングの腕前に驚いて震え、あなたのデザインのエレガントなシンプルさと永遠の真実を受け入れるしかないように、ひどいものを非常に見事にコーディングすることです。開発者doは能力を尊重しますが、注意する必要があります-無能（または不当な傲慢）に対する罰はかなり厳しいです。しかし、あなたがこの質問をしているので、私は、華麗で恥ずかしがらない傲慢なルートは実際には選択肢ではないと思います。 ;）
「こんにちは、私をあなたの家に迎えてくれてありがとう。私がドアを通り抜けるとき、私は家族全員に彼らの赤ちゃんが醜くて誰かが彼に面白い服を着せたことを知らせたいです。」
バグはバグであり、それをそれと呼んでもかまいません。それが「設計上の欠陥」によって引き起こされていると言うことは、あなたの前の男（最も「パパ」のように）に指を向けて、彼がばかだと言っていることです。
不必要で逆効果です。私は提案します：
「問題#blahに関しては、X YとZを実行することで修正できると思いますが、それがプロジェクトの残りの部分にどのように影響するかはわかりません。これで問題ありませんか？」
XYとZが問題を修正する場所。それは設計上の欠陥だったと彼らに言わせてください。別の解決策があるかもしれません。または、「欠陥」の背後にある仮定がプロジェクト全体で非常に深く実行される可能性があるため、それを変更するとバグは修正されますが、他のすべては壊れます！