学習パス：貢献者

コントリビューターセクションでは、InnerSourceコントリビューターであることを意味し、成功したコントリビューター、コントリビューション・メカニカル、あなたのチームと組織のためのInnerSourceの利点を作る行動の側面について説明します。

はじめに

別のチームがシステムに機能を追加する時間がなかったので、次のコーディングタスクでブロックされていることはありますか? しばらく経つと、あなたのプロジェクトでいくつかの余分な仕事をしなければならなかったかもしれません。この方法でブロックされることはありませんか?

InnerSourceの原則を組み込んだプロジェクトでは、必要な機能を提供するために別のチームを待ってブロックされることはありません。あなたが必要なものを得ていない場合は、InnerSourceコントリビューターとして機能することにより、他のチームのコードリポジトリに直接必要な変更を行うことができます。

コントリビューターの役割は、InnerSourceコミュニティプロジェクトの再生に寄与する人について説明しています。この人は、コミュニティの一部として、または自分自身を見ることができない場合があります。しかし、コミュニティがコミュニティのプロダクトを使ってコミュニティのメンバーと交流し、最終的に貢献し始めることを知るだけで、コントリビューターが作ることができる一連の旅は、かなり少数の人々のためにあります。最後に、それらのいくつかは、 Trusted Committers.

InnerSourceコミュニティのコントリビューターとして、InnerSourceの他の役割を担っている人々と対話します。 Trusted Committer または プロダクトオーナー 他のコントリビューターとおそらく。これらの役割は、Trusted Committerやプロダクトオーナーなどの同じ人物で小さな草の根スタイルのプロジェクトで再生することができます。

このセクションでは、他の2つの役割について非常に短い概要を提供しますが、読みたいと思っています。 Trusted Committerの役割の入門記事、そして私達はあなたが読むことを推薦しました障壁をエントリに下げる記事、あまりにも、このセクションのコントリビューターの役割の詳細に深く掘り下げる前に。また、記事を読むのではなく、ビデオ(紹介、エントリへの障壁を下げる)を見ることができます。

Trusted Committerは、ホスティングコミュニティにご滞在いただくホストです。プロジェクトのコードリポジトリへのゲートキーパーであり、受諾した時に、貢献を近づけていきます。コミュニティに貢献するためのあなたの道であなたをメンターする役割です。彼らはあなたを助けるためにあなたを助けるために情報を直接または提供することができます。この情報は、あなたの貢献のために関連した文書やコードセクションに、より大きな変更、ポインタのためのレビュー、提案テンプレートのためのハウスルールを確立することができます。

また、製品の品質、持続可能性、プロジェクトが技術的だけでなく、一般的な観点から進化し、誰もが貢献する障壁を減らすこと、そして一般のコミュニティのために世話をすることについても注意する必要があります。コミュニティへの参加には、健康でレベルアップし、参加者をアップし、組織のニーズを提唱することが含まれます。

の役割 プロダクトオーナー あなたの平均プロジェクトのプロダクト所有者の役割と類似性があります。しかし、プロジェクトの規模に応じて、この役割は、信頼できるコミッタとして機能する同じ人によってしばしば満たされています。より大きなプロジェクトでは、InnerSourceを部分的に使用しているチームでは、貢献を受け入れることによってニーズを満たすためのアプローチとして、この役割は信頼できるコミッタとは別の人が満たされている可能性があります。

製品の所有者の役割とのあなたの相互作用は、一般的な製品とそのロードマップにあなたの貢献のフィットを働かせることに重点を置いています。製品の所有者の役割で、文書の一般的な側面、またはUI / UXの一貫性があなたの貢献をマージする際に保持されていることを確認することができます。

最後に、製品所有者として行動する人は、プロジェクト、その利点、コミュニティをあなたの注意に持ち込むことに関与しているかもしれません。

これらの他の役割について詳しく知りたい場合は、そのほかのセクションについて別のセクションを用意しました。 Trusted Committer そして、 プロダクトオーナー.

以下の5つのセグメントでは、ここで紹介した様々な側面について詳しく学べます。

次のセグメントは詳細になりますマインドセットと習慣機会を創出するInnerSourceコントリビューターになる.

3番目のセグメントでは、貢献者のエトス– i.e.の側面アクションそれはあなたとホストチームのための快適で生産的な時間につながるし、より多くのコラボレーションをスパークするかもしれません。紹介動画で提示されたゲストインホームアナログは、鮮やかな例として機能します。

4つ目のセグメントは、あなたの貢献を成功させるために行うための実践的なことについて説明しています。貢献の仕組みお問い合わせ開発中の貢献や開発中、プルリクエストで作業する準備をする際に活用する実用的なヒントを提供します。

私たちは、個人、インタラクション重視、およびコントリビューターの役割の技術的な側面を扱っていた後、5番目のセグメントは、貢献する努力をする利点を示します。私たちは、あなたのチーム、そして大企業の視点から、さまざまな視点から恩恵を発揮します。

最後のセグメントは、私たちがInnerSourceコントリビューターであることについて学んだことを要します。 InnerSourceの学習を他のオンラインビデオと記事と共有し、オンラインInnerSourceコミュニティへの参加を通して共有することができます。

InnerSourceコントリビューター

InnerSourceコントリビューターは、通常のチーム境界の外で動作し、彼らは組織サイロを交差するリンクです。そのため、この作業をより効果的にするいくつかの一般的な慣行に注意する必要があります。

だから – あなたのチームの製品のための新しい機能を実装しています。この機能を使用するには、いくつかの機能が必要です。実装にジャンプする代わりに、ビットをスローダウン:この機能は一般的な問題を反映していますか? 組織内の他のチームが、共有事業領域のために直面しているのでしょうか? プロジェクトのドメインにこの機能が整形されていますか? そのいずれかが適用される場合は、自分のチームを超えて見始める:あなたのニーズに合わせて使用できる共有ソリューションはありますか? 1つあるべきか。

「早く行きたいなら、一人で行く」というアフリカの証跡があります。あなたが遠くに行きたいなら、一緒に行きましょう。ソフトウェア開発チームは同じです。

素早く移動したい場合、依存関係を破るのは素晴らしい考えです。その欠点は、努力を複製することができる。特にコアロジックを再導入する場合、重複の費用の非常に実質的なリスクは独立の利益を上回ります。

他のチームと連携することで、開発コストをシェアできます。オープンソースプロジェクトと同様に、チームが達成できるよりも大きなものを作ることができます。

しかし、すべてのチームが異なるロードマップを持っています! 共有コンポーネントを以前使用しようとしました – 彼らはいつもそれを再実装するために取ったよりも、統合に時間がかかる。これらのコンポーネントは、常にいくつかの側面や別の点で欠けていました – そして、私の機能の要求は、他のチームのロードマップに優先しませんでした!

従来のプロジェクトとは対照的に、InnerSourceプロジェクトはコントリビューターの役割を果たしています。はい、共有ソリューションが新しい機能を持っていたい場合は、時間がかかります。コントリビューターとして、コンポーネントのソースコードをチェックアウトし、修正を行い、その結果改善されたバージョンを使用する自由があります。

はい、ホストチームで同じ優先順位を持っていないあなたのタイムラインにバグ修正を緊急に必要としたときに時間があります。貢献者になることで、そのバグを修正してホストチームを自分で行動し、サポートすることができます。

作業のこの方法は、問題を回避するのではなく、機能の実装やバグの修正を待つのではなく、多くの人のためのマインドセットの変化を必要とします。 InnerSourceプロジェクトで、ニーズが何であるかを確認し、共有プロジェクトに直接変更を加えるために時間とエネルギーを消費します。あなたのコーディングスキルに加えて、InnerSourceプロジェクトで成功するコミュニケーションスキルが必要です。あなたのニーズを明確に整理し、あなたのチームとホストチームの両方のために働くソリューションに来ます。

「しかし、私は単にプロジェクトをフォークし、そこに私の変更を作り、すべてのこのコーディネートオーバーヘッドから自分自身を保存することができます!」。 Sure – プロジェクトをフォークすることは、あなたの仕事を終わらせるための方法です。長い実行を除き、これは、あなたのチームのためにそのフォークされたバージョンを維持し、ホストチームが作る新しいリリースのためにあなたの変更を先に持ち運びます。ホストチームへの変更の貢献は、コンポーネントの深い知識から利益を得ることを意味します。彼らは、そうでなければ、生産で明らかになっただろうあなたのパッチで問題を見つけるかもしれません。

優れたコントリビューターは、技術とビジネスの両方を意味し、依存性を導入し、作業を複製する代わりにコンポーネントを再利用するときに快適にコールすることができます。 InnerSourceの貢献の恩恵を説明するために管理を話すことができます。

内側だからソースお問い合わせソースコード? もちろんです。あなたのチームのビジネスが外部のコンポーネントに依存している場合は、よく維持され、うまく実行されていることを確認してください。 InnerSourceコントリビューターとして、複数の方法でホストチームを支援できます。コンポーネントを使用する際のレポートの問題は、貴重な貢献です。コードが期待どおりに機能していないことを示すテストケースを作成または修正することは価値があります。そのため、ドキュメントの改善が進んでいますので、他の人はそれを使用して時間を費やし、それに貢献します。他のユーザーをサポートし、バグの兆しの助けを借りて貴重な貢献をすることができます。ビルドの改善は、貴重な貢献の別の例です。

貢献を要約しないために、貢献する余りに小さいです。ここに私が作ったものがありますtensorflow/モデルお問い合わせグラフのシンプルなラベル変更。

この記事では、コントリビューターになるために必要なことについて学びました。共有マインドセットを見ました。共有ソリューションのメリットに深く掘り下げました。最後に、InnerSourceのコントリビューションのスコープがよく見えるものを見てみましょう。

貢献者エトス

最後のセグメントでは、コンポーネントを再利用し、コントリビューターとしてアクティブにしたいという理由を説明します。この記事では、ホストチームのコードベースへの変更を成功させる方法についてのベストプラクティスを共有します。

InnerSourceのコントリビューターは、ホストチームへの貢献を試みることは、本質的に彼らの家のゲストです。一般的に、良いゲストは特定の方法で振る舞うと期待されます。

ドアにノック。
家のルールを守ります。
彼らは彼らが家所有者ではないことを理解し、それに応じて行動します。

これらの期待はInnerSourceプロジェクトに適用されますか?

隣人を訪問するときは、ドアが開いている場合でも、ドアベルをノックしたり、鳴らすことなく家に入る可能性が高いでしょう。同様に、InnerSource 訪問者として、任意のコードリポジトリに直接コミットする(または招待)できません。

代わりに、コードベースに変更を加えると、プルリクエストとして提出します。 InnerSourceでは、大幅な変化や近隣のホームへの改善を検討するなど、プロジェクトのコラボレーションガイドラインを予測し、フォローします。順番に、あなたのホストは、既存の信頼できるコミッタに翻訳するInnerSourceの方法で、メンターのゲストに時間を費やす方法を紹介します。

行き届いた素敵な夏のパーティーはどうですか? 通常、適切な日付と時間を選択する前にいくつかの計画があります。, 十分な食品を準備する, または、ゲストによって貢献した. 同じことがInnerSourceプロジェクトで大きな変化のために起こります:プロジェクトは、大規模な変更を行う前に、あなたのニーズと提案されたソリューションを記述する問題を提出するように求める可能性があります。実装に右にジャンプするのではなく、初期設計に時間を費やすと、コントリビューターが多くの作業をやり直すのに役立ちます。進行状況を早期に共有 – まだ終了していない場合でも、ホストチームがより良いソリューションに対するコントリビューターをメンターするのに役立ちます。いいねYonikの未完成パッチ法説明: “Jiraのハーフベイクドパッチ、文書なし、テストなし、後方互換性がまったくパッチなしよりも優れています。”

InnerSourceプロジェクトが顔に対面する価値がないことを意味していますか? そうではありません:参加者が直面する価値があります。すべての書面による通信は、人の中で会議と比較して帯域幅の多くを欠いていることを覚えておいてください:ジェスチャーはありません、ミミックは、理解を助けるために音声のトーンでさえありません。対人会議は、対人課題の解決、紛争の解決、誤解のために特に価値があります。しかし、プロジェクトの決定に関するコミュニケーションは、書き留めておくべきであり、他の人がプロジェクトをフォローし、影響する可能性があるため、その後、特定の決定が行われた理由を追跡することが可能である。

ここに私の一般的な親指のルール:コーヒーを介さずに感じます。多くの場合、特にチームが複数の物理的な場所に分割されると、より強力なチームを構築するのに役立ちます。すべての決定が透明で非同期な方法で行われているかどうかを確かめてください。ログインあなたの会話で – ジャンプして、アクティブな貢献者になることができます。たったの1つの例は、オープンな意思決定を取ることができるのは、いくつかの演習で説明されていますオープン組織のワークブック.

そこで、InnerSourceプロジェクトが変更や今後のプロジェクトの方向性について議論したいと判断する方法は? 多くのInnerSourceプロジェクトでは、それらがREADME.mdの潜在的なコントリビューターによってどのようにアプローチするかを説明します。そのドキュメントが処理に大きすぎると、コントリビュートのガイドラインは、CONTRIBUTING.mdファイルというファイルに分割される傾向があります。それらの推奨事項に従って、コントリビューターがオファーを販売するのに役立ちます。

これらすべてのインタラクションでは、ホストチームへの貢献を「セル」に準備します。貢献が生態系に与える価値をアーティキュレーションします。

ホストチームは、変更のためのメンテナンスをやり取りします。それは達成するために提供するために意味を作ります30日保証あなたの投稿に。これにより、コントリビューターがコントリビューション時にバグを解決できないというホストチームの恐怖を緩和できます。

あなたの隣人を訪問しているとき、彼らはあなたのアパートであなたを助けるでしょう:彼らはあなたのリビングルームとトイレが置かれている場所への道が表示されます。あなたが長く滞在している場合, 彼らはおそらくあなたにより多くの詳細を与えます: 私の場合では、例えば、食器洗い機をオンにし、ヒューズを吹くことを避けるために同時に電気ケトルを避けることになります.

同様に、すべてのソフトウェアシステムは、独自の知識と複雑さを備えています。多くの場合、最も明らかなものはよく文書化されています。小さなプロジェクトでは、このドキュメントはREADME.md にあります。より大きいものでは、ConTRIBUTING.md のドキュメントで特定の文書を作成することができます。

これらのファイルでは、プロジェクトをチェックしてビルドする方法、テストスイートを実行する方法、プロジェクトの変更を提出する方法に関する情報を確認できます。標準的なツーリングから大幅に逸脱する場合、または変更を加えるときに留意すべき事項がある場合、さらに文書化を指すかもしれません。

その文書を通すことは、通常、間違ったパスをダウンし、デッドエンドについて警告するのを止めているので、巨大な時間セーバーであることが判明します。あなたの経験に基づいて、物事が不足していることを見つけた場合 – その文書へのパッチは通常非常に歓迎されています:初めてプロジェクトを見ることができる新しいコントリビューターよりもそれを改善するために適していません。

あなたが念頭に置いた変更が全体的に理にかなっているならば、プロジェクトを好みの通信チャネルで一緒に把握してみてください。最初は、アーカイブされ、検索可能である企業パブリックメディアでこれらの会話を持っていることは怖いかもしれません。ここでのメリットは、同様の提案で来ている他の人とあります: 同じパスを再び歩く代わりに、彼らはすでに議論されたものを学び、そこから始めることができます。

貢献者であることは、単に機能を求める人よりも、ホストチームに近いことを意味します。それでも、コントリビューターは、彼らが貢献しているソフトウェアプロジェクトのために説明できません。

その結果、コントリビューションの最終呼び出しはホストチームと同じです。ホストチームに謙虚なマインドセットでアプローチするのに役立ち、全員が共有組織の目的に協力しているという前提があります。それは、実装されたものだけでなく、変更が必要だった理由だけでなく、開いて透明になるのに役立ちます。

贈り物として任意のフィードバックを扱います。他の人は、あなたのソリューションを改善しようとしています。

主催者チームがお客様の貢献を全く受け止めないチャンスがあります。その場合、チームで作業するのに役立ち、プロジェクトで解決できるニーズのサブ側面があるかどうかを把握します。そのサブアスペクトに連携し、残りの問題を解決するための別の方法を見つけます。

このセグメントでは、InnerSourceプロジェクトをコントリビューターとして最適にアプローチする方法を学びました。また、変更の必要性を最もよく伝達し、ホストチームと共に解決に取り組む方法を調べました。

貢献のメカニクス

他のチームプロジェクト/リポジトリへの貢献を始めましょうか? 管理エスカレーションではなく、コラボレーションでブロックを削減するのを楽しみにしていますか? このセクションでは、InnerSource の貢献をするときに覚えておくための実用的なアドバイスとハイライトを提示します。あなたとホストチームは、より多くの貢献と素晴らしいコラボレーションのための基盤を設定し、可能な限り快適な体験をすることができます。

この記事では、経験する可能性のある3つのステップに分かれています

貢献機会を受理し、それを準備する
実際に貢献を作成する
ギフトをうまく磨き、包み、ホストチームに提示します。

あなたの貢献が大きくなれば、あなたの共通の目標に向かって反復するようにこれらのステップ(一部)を繰り返します。あなたがこれを行うと、すべてがより自然を感じるだろう – 多分あなたが前に何かをやっていた理由さえ疑問に思います。

1つのキーの相違はターンアラウンドの時間です。初めてのコントリビューションで、新しい(ホスト)チームにやってきます。その結果、コードベース、技術使用、およびその好ましい開発環境(テストフレームワーク、ビルドシステム)を知る必要があります。このタイプのツーリングが標準化される場合でも、各チームが個々の特質を開発しています。技術的な面に加えて、コミュニケーションの違い(コードレビュー)に直面する場合があります。しばらく経って帰ってきたとしても、チームのやり方やメンバーが変わるかも。しばらく見ていない友人と、あなたが今訪問している人と一緒に追いつくためにあなたの時間を取る.

十分なリードタイムを自分で提供します。まずは、必要な時間に活用できるため、作業を早めに始めましょう。最初はスラック時間を追加することをお勧めします – ホストチームで作業したら、ターンアラウンド時間について感じます。多くの場合、そのホストチームにいくつかの成功した貢献をした後、ホストチームごとのターンアラウンド時間の削減に気づくでしょう。この効果は、オープンソースだけでなく、それについてもっと読むことができます観察することができます詳しくはこちら.

あなたの古典的なチームでは、誰もが予想されるリードタイムのアイデアを持っていました。 InnerSource コンテキスト内では、大幅なタイムゾーンの違い(例:)によるケースではないかもしれません。シアトル, PDT 対ベルリン, ドイツ CEST の CEST で) または、元のチームと同じ物理的な場所にある場合でも、フルタイムで利用できていない. したがって、双方の側面、不完全性および他の非信頼ビルディング効果に不満を防止するために、予想される反応時間に関して明示的に期待管理を行う必要があります。 1つのアプローチは、「私はそれを見て、私は次の数日でそれを得ることができません」とすぐに反応することです Trusted Committerの 数日でそれらに戻ることができるだけを知っている場合フィードバック。理想的には、入力を調べる時間を持っている可能性が高い場合は、それらをかなりの見積もりを提供できます。そのため、非物理的接触、長距離、または非同期媒体であっても、信頼性によって信頼を構築します。設立された信頼は、あなたの先の共同道路で不確実性バンプを克服することができます。

InnerSourceは、プロジェクトの決定に関しては特に、書面による通信に大きな重量を置く。相手のコミュニケーションが禁止されていることではありませんか?

明確ではありません: コミュニケーションを書いている間、それはアーカイブと検索性に関しては、コミュニケーションの帯域幅に関しては、個人通信が輝きます。名前の背後にある人々と会うために時間を作るようにしてください。可能であれば、お好みの飲料や食べ物に合わせましょう。人が話を聞くことができるとき、自分のイディオシクラシーを知っているとき、リモートコラボレーションがより簡単になるでしょう。

貢献したいという大きな特徴はありますか? お問い合わせすべての作品が無駄になったら、それは恐ろしいですか? ホストチームがすでによく似ている何かをビルドしているときには、ソフトウェアを非推奨にするか、プロジェクトに適したものではないかを計画しています。この課題は頻繁に一つであり、貢献が良いフィットであることを事前に合意しないと多くのチーム関係が苦しんでいる。

自分自身とホストチームを満足させる(そしておそらくいくつかの仕事を保存) 貢献のユーザー/技術設計上のホストチームから合意を得る前へ変更に取り組み、プルリクエストを提出する。ホストチームがこのために到達したいかどうかを理解する必要があります。お問い合わせするのが最善です Trusted Committer あなたの提案を最もよく議論する方法について。

あなたがあなたの提案を議論する方法を選択するために得るならば、あなたは、あなたの提案を議論する方法を選択するために得るならば、それはオープンソースのアリーナからタイムアンドアgain-proven知恵です。理想的には、アーティファクトが公開され、検索可能でパーマリンク可能な方法を選択して、この将来の貢献または他の貢献に関する後で議論で提案を参照できるようにします。

このタイプのハイレベル、初期の先行契約は、あなたのプルリクエストのリワークまたは拒絶の時間を節約します。

ホストチームのアプローチに精通し、プルリクエストの受け取りをお待ちしています。今あなたを待っていますか?

まず、それらとの直接接触が少なくなります。第二に、あなたのチームが所有するフルタイムのプロジェクトにいるかもしれないので、知識が豊富で有益であると期待されていません。今、このベストに対処するにはどうすればよいですか?

ホストチームからドキュメント、会話アーカイブ、コードアーティファクトを悪用して、ブロック解除してください。これは、一般的なOSSプロジェクトのいずれかを使用して、あなたが最も可能性が高い状況に似ています。

オープンソースプロジェクトでは、自分のブロックを解除しようとすると、物事がどこにも起こっているかどうかをホストチームに尋ねます。あなたが受け取る質問と答えは、あなたが同じ問題を解決した後、他の人が来ているのを助けます。プロジェクト自体に密接にリンクされている検索可能なアーカイブで通信が終わることを確認してください。まだ到達されていない場合、目標に到達する簡単な改善機会が表示されれば、あなたは非常に丁寧に試すことができます – あなたのホストチームへの改善を提案します。場合によっては、状況は、純粋な発症から上昇し、誰も異なるアイデアを持っていたり、十分に刻まれていないので、その方法を維持します。そのような場合、改善の提案は歓迎されるかもしれません。プロジェクトの知識が豊富にあれば、数分間の会話で解決できる問題に永遠にスピンするのは、あなたにとっては良いことではありません。お問い合わせはOKです。

しかし、1つの重要な違いがあります, 将来的にあなたと他の人々に有利をもたらす: ほとんどすべてのケースでは、プロジェクトの公式通信チャネルを好む必要があります – これはメーリングリスト、チャットルーム、問題追跡者または同様のものになることができます, より同期または非同期的なやり取りの方法を持っていることの目的に応じて、, またはコミュニケーションの構造のためのさまざまなニーズ. これらは、テキストベース、アーカイブ、検索可能であり、安定したリンクが付属していることが一般的です。これは、あなたの質問と回答がダウンされることを意味します。そして、それらの回答にリンクする参照は到達可能になります。この方法では、このパッシブにあなたの検索で知識を文書化し、将来のコントリビューターが同じ利点を持つのを助けることができます。このようなパッシブ文書は、「公式」の文書を豊かにする機能であっても、アドホックを作成した重要な定義など、特に貴重な宝石を含むことが起こるかもしれません。

あなたが働いているように、不足している(または最新の)文書が見つかられば、次のコントリビューターに賛同し、あなたが発見したことをアップデートしてください。プロジェクトチームは、既存の文書の追加、更新、修正を受け取ることはしばしば幸せです。あなたが貢献する別の機会を見つけました!(または、あなたの経験に対するフィードバックを丁寧に提供し、あなたを助けたもの)

コードスタイル、インデントなど、私たちの好みや意見があります。ホストチームのプロジェクトは、普段何をしているのかではなく、プロジェクトで指定されていない場合でも、それらの好みを適応し、一致させよう お問い合わせお問い合わせわからない場合は、必ず丁寧にお尋ねください。それにもかかわらず、機能またはバグ修正のためのゲストの貢献は、プロジェクトコードを構造化またはフォーマットするための新しい方法を導入する時間ではありません。

あなたは、すべての重要な仕事を完了しました, 問題のすべての癖を把握し、あなたが貢献しているプロジェクト, あなたが使用するために新しい機能のために計画した時間は、ニア来ます, そして、あなたは、あなたの貢献ができるだけ速く、滑らかに結合されることを確認するためにしたいです.

ここでは、レビューやマージを可能な限り簡単にするためにできることです。 Trusted Committer ホストチームこれは、すでに自分のプロジェクトで何をしているかとよく似ているかもしれません。その場合 – 素晴らしい、これはあなたに自然に来るつもりです!

ここでの基本ポイントは、有効にすることです。 Trusted Committer あなたの存在なしで貢献を検証し、容易な維持性を保障するため。信じられないほどの癖や、重要なパフォーマンスの微調整、そしてコードが完全に明らかでない(または一見ハッキー/誤って見えるかもしれません)。テストでこれをカバーしている場合 – そして理想的には、コメントでそれの背後にある合理にいくつかの単語を書いています – 将来のエディタは、コードの目的について思い出し、test(s)は、新しい実装であっても、あなたのコードが認識する値が保持されることを保証します。これを実現するには、以下を実行します。

コードのコントリビューションのテストを追加すると、他のプロジェクトで作業したり、このプロジェクトへの貢献を中止したりしても、他のプロジェクトであなたのコントリビューションの機能を有効化できるようにします。
- 多くの場合、プロジェクトは、これらのテストとコードカバレッジのレベルを使用してプルリクエストに対して自動チェックを行います。これらのテストが実施する基準を満たすようにしてください。
多くのプロジェクトでは、変更をローカルにテストできるようにプロジェクトビルドと検証スクリプトを提供します。
- プルリクエストを開く前に、あなたの貢献ができるだけ有効であることを確認するためにそれらを使用します。
- 欠陥のあるプルリクエストを簡単な修正エラーで確認することで、信頼されるコミッタをバグします。あなたのコードを修正するのではなく、そうするように依頼します。これは、より多くの往復を作成し、合併を遅くする可能性があります。
- しかし、誰も完璧ではありません。最善を尽くし、準備済みのバリデーションスクリプトを使って、何かあれば、プルリクエストで最高のショットをあげましょう!
- プルリクエストがテストを破り続けると、最適なショットを与えた後に理由を調べることはできません。プルリクエストコメントでそれらのテストをハイライトし、問題の現在の理解を説明し、それについて助けを求めるようにしてください。
最初の場所であなたの貢献をトリガーしたあなた自身のプロジェクトを忘れないでください。共有プロジェクトを変更し、それを消費する独自のプロジェクトで試してみましょう。

プルリクエストには、変更に関連するドキュメントの更新が含まれていることを確認してください。ドキュメントが異なる場所に住んでいる場合は、プルリクエストにそれらを追加してリンクしてください。

信頼できるコミッタや他の人がそれをレビューすることができるように、実際のコードレビューをできるだけ簡単にするために、次のヒントに従ってください。

プルリクエストは、完了した問題の関連変更のみが含まれていることを確認してください。
大規模なコミットを避けるために、未クリアなコミットメッセージ、ファイルのgazillions、固有の変更(例えば複数のトピックに触れる)でコミットしてください。
このプルの変更の明確な説明を提供, それがそうする理由, どの問題や設計文書 (もしあれば) それは参照します.
プルリクエストに珍しいものや予期しないものがある場合は、それを強調して説明を提供します。これは、レビュー担当者がレビュー中に持っている可能性がある潜在的なブロックの質問の理由と解決が容易になります。
- 同じことは、実装やアプローチがわからないというシナリオで、それを強調し、インサイトを尋ねます。
- 市民であり、市民性を期待する Trusted Committerの レビュー
プルリクエストを広くし、大きすぎると、レビューが難しくなりますので、受け入れる前にはるかに時間がかかるでしょう。
- あなたが貢献しているより大きな機能を持っている場合は、多くの場合、提出された複数のプルリクエストでそれを分割するのに役立ちます, 審査および承認された順次. あなたが言及している問題と一緒にそれらを結合することができます。
  - 一部のツールには、Draft / WIP プルリクエスト機能も搭載されており、未完成品や非磨かれた作業を明示的にマークし、ホストチームからの早期フィードバックも取得できます。 Trusted Committers.
  - これにより、ホストチームが完了したらマージするのが嬉しいパスをダウンしていることを確認することができます。「早期リリース、頻繁にリリース」のアイデアに付着します。
  - ホストチームの責任は、非公正な仕事を共有し、議論する雰囲気を作成することです。安全に失敗しないと、革新できず、コラボレーションが非常に困難になります。
  - レビューを早めに依頼し、レビューに有意義な変更を提供してバランスをとりましょう。

これらのリソースの一部は、ペイウォールの後ろに隠される可能性があります。場合によっては、あなたの雇用主は、アクセスを可能にするサブスクリプションを持っています, それ以外の公的大学のライブラリは、多くの場合、ゲストへのアクセスを許可します, あまりにも.

InnerSourceコントリビューターの対応

貢献者はInnerSourceプロジェクトの命血です。 InnerSourceプロジェクトとして実行されるすべてのプロジェクトは、約束と、元の創設者を超えて開発チームを拡大するための究極の目標と、そのプロジェクトのユーザー(時々、法人の顧客と呼ばれます)の間で、さらなる共同作業者の可能性にタップします。

しかし、管理者の方向ではなく、プロジェクトに個人開発者が時間を費やす動機は? 管理者が自分の開発者が自分の意見の下で100%ではないプロジェクトを改善する時間を作る動機は何ですか?

最も明らかなモチベーションは、通常、オープンソースに初期のコントリビューターを描画するものです。

長い間働いていたバグを心配しないでください? これらの回避策のコストを維持する時間とエネルギー? 上流チームを待つ代わりに、将来的にその問題を解決するために何か、あなたは先に行き、それを自分で修正することができますか? この「独自の itch をスクラッチ」の状況では、初期のコントリビューターは、日常的な作業に応じてプロジェクトの問題を解決し始め、独自のコードベースで回避策の数を減らすことができます。

自分のワークアラウンドを維持するのではなく、修正を作成し、貢献するかどうかを決定するとき、貢献があなた自身の変化の質をもたらす利点を考える。分離で作業する代わりに、上流プロジェクトで作業する人は、レビューだけでなく、ソリューションを向上させることができます。自社開発の努力を飛躍的に加速するサポートとメンタリングを手に入れましょう。

他の人とより多くの時間を費やすことは、チームがどのように機能するか、それ自体を整理する方法を学ぶ時間をかけて、そのプロジェクトを構築するために使用するツールです。自分のプロジェクトがその経験から恩恵を受けることができます。新しいライブラリやビルドシステムだけを読んでいるのではなく、自分のプロジェクトを先に進んで導入する前に、実用的な経験を得ることができます。複数のコアプロジェクトに取り組むことで、より大きなエコシステムにさらされることによって、ベストプラクティスと課題に対するソリューションを引き出します。

他のチームであなたの時間を費やすことができる素晴らしい副作用は、あなたの評判と影響があなた自身のチームの境界を拡大することです。他の人から学び、自分自身を成長させるだけでなく、プロジェクトに影響を与えることができます。あなた自身の貢献によって直接影響し、プロジェクトツーリングやセットアップに関するあなたの経験と知識を共有することによって. この共有は、上流プロジェクトが開発サイクルを改善し、加速するのに役立ちます。

これらのすべての目的基準とは別に、測定が非常に難しいコンポーネントがありますが、InnerSourceとOpen Sourceプロジェクトの両方で報告されています。個人的に達成し、楽しくプロジェクトに取り組むため、人々は参加しています。ほとんどの場合、仕事のタスクを本当に選択する立場にある側面は重要な役割を果たします。このセルフセレクションは通常、コントリビューターのモチベーションを維持するために、ホストプロジェクトは非常に歓迎され、彼らの努力で支持的であることにつながります。

ついにアップストリームを固定されているバグを迷惑にすることを忘れないでください? なぜあなたのチームは上流プロジェクトにその修正を貢献するために余分な努力を費やすべきですか?

一つは、メンテナンスコストと時間が上流プロジェクトで今あることを意味します。すべての新しいリリースのために、それはあなたの変更と要件を操作し続けることを確認するために、あなたのチームではなく、それらにあります。

チームメンバーは、プロジェクトでアクティブなコントリビューターとして働いているということは、プロジェクトの方向とタイムラインで言うことができるということに依存します。

InnerSource チームを使用することで、「独立して自分で構築する」という中間パス(所有する新しいバグの数を含む)と「既存の実装に依存して時間とお金を節約する」間の中間パスを確立できます(限られた方法でのみ影響を受けることができる長期の依存性を作成するコスト)。そのため、再導入対再利用が容易になります。

会社のドメインに固有の機能を覚えていますが、社内全体で複数の実装で維持されていますか? 数十のバグの実装を回避し、共有資産にそれらを結合する方法があったら? 中央の依存関係がテーブルに持って来るエネルギーの通常の排水なしでこの共有資産のための開発プロセスが走ったらどうなりますか? 多くのオープンソースプロジェクトは、多数のプレイヤーによって使われています。デザインや開発に参加している人もいます。企業レベルでのInnerSourceプロジェクトでクロスチームコラボレーションを促進することで、組織のエッジから集中的なイノベーションを推進することができます。

一般的には、プロジェクトとプロジェクトがよく理解されているバス要因1人または2人の人が組織にリスクを課す – そのプロジェクトがビジネスの目的に集中することになったとき、より多くの。 InnerSourceは、このようなプロジェクトを透明にするだけでなく、コントリビューターベースをメンタリングし、拡大することにより、その状況を改善するためのツールを提供します。

チーム同士のコラボレーションは、個々の貢献をハードに評価する一方で、組織内での学習と知識の共有も可能になります。その結果、個人の影響が向上します。ベストプラクティスとプラスイノベーションは、組織全体でより簡単に広がります。作業環境の改善は、作業環境の改善が組織全体に容易に普及し、従業員の維持を支援します。

より多様な背景を持つ技術面では、コード変更がはるかに多くのスルチニーの下に置くことを意味し、全体的な品質とセキュリティの向上につながる。

最後に、プロジェクトユーザーと顧客が開発に参加できるようにすることに焦点を合わせると、これらのプロジェクトが簡単に始めるための非常に明確なインセンティブが提供されます:標準ツーリングに基づいて、簡単に理解しやすく、簡単に再使用し、その結果としてよりモジュラーおよび交換可能。

この記事で見てきたように、オープンソースで活動する個人や法人の多くの理由は、InnerSourceプロジェクトにも適用されます。また、InnerSourceプロジェクトで人々をコラボレーションさせるという理由だけでなく、このようなコラボレーションが多くの意味をもたらすときにビジネス上の理由を識別するのは簡単です。

コンクルージョン

InnerSource Commons学習パスのコントリビューターセグメントのレビューをありがとう。このセクションでは、コントリビューターの役割について学んだ – InnerSourceプロジェクトの命血。コントリビューターは、コンポーネントの所有者チームに外部で、プロジェクトに追加の貴重な入力をもたらします。

このセクションでは、貢献する機会を見つけることにより、貢献者になる方法を学びました。このような機会を見つけるか、作成するために必要な考え方と習慣を見直しました。我々はまた、成功した貢献につながる可能性が高い役割と提案されたアプローチのethosを議論しました.

正しいマインドセット、習慣、エトスを与えられた、まだあなたが成功した貢献からあなたを保つかもしれないいくつかの詳細があります – それゆえ、我々はより詳細なこれらのナットとボルトを議論しました。

最後に、チームメイトと組織をさまざまなレベルで結びつけることは困難です。そのため、さまざまな視点からの貢献のメリットについて議論し、このプロセスをより簡単にします。

動画を視聴したり、記事を読んだり、また、InnerSource への旅の新たな知見を発信したり、良いコントリビューターになったりすることができました。

すでに行っていない場合、InnerSource学習パスでInnerSourceの他の側面について詳しく知りたいです。 http://innersourcecommons.org/learningpath/

InnerSourceグループをチェックしてください InnerSource Commons オンライン – あなたの組織で学んだ経験とレッスンを共有し、ディスカッションに参加して自由に感じてください。

長く生きて、繁栄するプロジェクトを持っている!

ワークブック

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

プロジェクトを改善するために、他の人が私の提案に従う必要があることを確認してください。
ホストチームは、チームに代わって追加する機能を維持します。
チームのニーズに合ったソリューションを形作ります。
コード自体以外のプロジェクトのすべての側面(例えば、GitHubレビュー、バグのトリエージ、テスト、ドキュメント)を形作るのに役立ちます。

なぜ 1 が間違っているのか: コミュニティが dictatorship ではありません。貢献者として, あなたは成長し、繁栄するためのソリューションを支援コミュニティの一部であります. これは、時に妥協を伴うかもしれませんが、あなたとコミュニティに長期的利益を支払うことになります。

なぜ2が間違っているのか:InnerSourceの顧客機能を得るために必要な作業量を減らすことは、主な理由の1つです。ホストプロジェクトに変化をもたらすことは、ホストチームが変更を意識し、進行中のリファクタリングに考慮に入れることを意味します。つまり、コントリビューターとして、新しいバージョンに適応しなければならない作業が大幅に減少している。それでも、ホストチームを受け入れる上で、自分が投稿した変更を意図どおりに確認するために責任を負う唯一の人であることは意味しません。30日間の保証パターンは、提出された変更の問題を解決するための長いコントリビューターの責任を定義するための正式な手段を提供します。実践的なコントリビューターでは、多くの場合、ホストチームに近づくと、今後の専門知識を提供します。

なぜ3が正しいのか:共有ソリューションは、関心のある当事者からの貢献から発展しています。コントリビューターになれば、いつでも相談して、他のコミュニティメンバーとのコラボレーションをすることができます。

なぜ 4 が正しいのか: 貢献は単なるコードを超えて行きます。解決を健康に保ち、成功させるのに役立つ多くの側面があります、異なる側面は異なるスキルを必要としますが、別のものよりも1つを重要にしません。コードが機械の場合、機械がスムーズに動くことを維持するグリースとして貢献のこれらの分野を考える。

事業全体で共有されるニーズは、InnerSourceに適した候補です。
できるだけ少ない依存関係がある場合、プロジェクトが最速になります。
ホスティングチームは、必要な機能を実行します。
チームに必要な機能のみで作業する。

なぜ1が正しいのか:ビジネスの多くのチームが同じ必要性を持っているとき、InnerSourceプロジェクトは、重複した作業なしでスケールでそれらのニーズを満たすための素晴らしい方法です。

なぜ2が間違っているのか:すでに書かれているコードを活用するチャンスをスキップすると、チームに独自の値を追加するのではなく、既に解決している問題に時間を浪費します。

なぜ 3 が間違っているのか: 質問できますが、プロジェクトに次の必要性が、ホストチームが動作する次の優先順位ではありません。これらのケースでは、プロジェクトにInnerSourceの貢献をすることで、必要なものを得ることができます。

なぜ 4 が間違っているのか: プロジェクトの他の機能に取り組み、コードやドキュメントを再編成するなどのバックグラウンド作業を行うと、チームの成功に間接的に貢献する可能性があるため、それらのことに時間を投資する正当な理由があります。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

私のチームの仕事は会社の成功にとって非常に重要であるので、私のチームの声は他の人よりも共有ソリューションコミュニティにより多くの重量を持っています。
私はプロジェクトにゲストとして、私はホストチームから私の質問に迅速かつ包括的な回答をすることができます。
プロジェクトのゲストとして、関連する文書(スターティングが、制限されていない、README.mdとCONTRIBUTING.mdファイル)に記載されているように、ルールとガイドラインを理解し、遵守すべきです。明確化またはヘルプの後に質問をすることができます。
私の約束は、私が提供する変更です。私の貢献が私の仕事を受け入れられたら、私は再び自分のプロジェクトの中心に焦点を合わせることができます。

なぜ 1 が間違っているのか: チームが社内でもっと中心的な役割を果たしている場合でも、InnerSource プロジェクトとやり取りするときは、ゲストはまだゲストです。プロジェクトに関する決定のための究極の説明責任は、信頼できるコミッタです。

なぜ2が間違っているのか:良い質問をしても問題はありませんし、タイムリーな方法で対応する必要があります。しかし、あなたはゲストであり、コミュニティの他の人の時間と努力を尊重する必要があります。そのため、質問をする前に、利用可能なすべてのドキュメントを必ず読んで理解し、チームリーダーをホストするだけでなく、教育されたプロジェクトメンバーから回答のために準備してください。これにより、コミュニティのステータスが向上し、ランダム化を回避できます。

なぜ 3 が正しいのか: InnerSource は、文書の作成を強調し、作業の背景として (たとえば、README.md と CONTRIBUTING.md のように、個々の決定とコードの変更を正当化します。ドキュメントの文化の理由は、コントリビューターとして、プロジェクトに正常に変更に合う必要がある背景を提供することです。

なぜ4が間違っているのか:あなたの貢献を受け入れられることは祝われるべき達成です。しかし、あなたの関与は終わりません。最小限で利用できるようにして、30日保証あなたの変更(そして、その影響)、またはさらに改善:コミュニティの近くに滞在し、追加の貢献を支援します。

解決策の所有者とレビュー担当者は貢献に依存しているので、私はすぐに、コード変更(私が発見したバグや新しい機能への修正など)を投稿することによってプロジェクトを支援します。コードレビューは、任意の問題を揺るがします。
貢献が拒否されないと確信しています。これは、コントリビューターに対する敵対的な行動を構成するからです。
プロジェクトが変更をサポートし、プロジェクトを前進させるのに役立てています。
コラボレーションがより効率的になるので、私は仕事に慣れている人々とのみ仕事をしています。

なぜ1が間違っているのか:貢献する前に、他のプロジェクトメンバーにあなたの意向を伝える必要があります。プロジェクトのサプライズは、混乱、無駄な努力、そして刺激の大きな変化を生み出します。早期およびオープンなコミュニケーションは、意図の明確なメッセージを送信し、スムーズなコントリビューション経験のチャンスを増加させます。

なぜ2が間違っているのか:大きな貢献は、オープン、共有ソリューションで評価されますが、ゲストであることを念頭に置いています。コードの変更は、多くの理由で拒否される可能性があります。なぜなら、それらは解決策の意図に反対を実行するので、コーディング基準等を満たしていないからです。これは、あなたの個人的な反射ではなく、プロの決定です。プロジェクト文書(README.md、CONTRIBUTING.mdなど)の概略要件と今後のプロジェクト計画を理解してこれを軽減します。ドキュメントが見つからない場合、プロジェクトの基準、期待、計画について尋ねてください。あなたの最初の投稿は、不足している文書の書き込みやレビューによくあるかもしれません。

なぜ3が正しいのか:プロジェクトは、人々が参加し、オープンの問題のトップを維持し、問題の修正を支援し、計画に秤量する必要があります。従事者の滞在は、あなたは肯定的な評判を構築し、プロジェクトの問題の領域についてもっと学ぶ機会を提供します。

なぜ4が間違っているのか: 従事するときは、コミュニティ全体(すべてのゲストと私たちのメタファーのホスト)に従事し、オープンで作業する必要があります。物理的な場所や組織の場所は、あなたが従事しているか、あなたが従事しているかでの役割を果たすべきではありません。結局、InnerSourceは全員の成功のために境界を越えて一緒に働いています。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

InnerSourceプロジェクトへの貢献は、私のチームのプロジェクトへの貢献と同じ時間を取ることを理解しています。
ホストチームへの貢献を初期に伝え、スコープとタイミングに関する合意を確保します。
私はコードスタイルの均質であり、理解しやすいように、私の貢献作業中に遭遇したコードを再ファクターを計画します。
プルリクエストを絞って理解し、レビューし、統合しやすくする予定です。

なぜ1が間違っているのか:多くの理由から、オープンおよび共有ソリューションへの貢献は、クローズド、シングルチームプロジェクトへの変更よりも多くの時間がかかります。たとえば、ホストとの調整は、即時のチームと同じくらい簡単です。あなたの興味とホストの興味は簡単に整列できず、妥協は見つけられるかもしれません。物流は、単に異なるタイムゾーンで動作するように、オーバーヘッドを追加することもできます。これらの遅延を緩和するために、追加の時間で計画します。これは、ストレスと緊張を緩和し、成功したエンゲージメントのあなたのチャンスを増やすでしょう。

なぜ2が正しいのか:コミュニケーションを通して、誰もがあなたの意図を理解し、必要な助言を与えることを可能にします。コミュニケーションは、他の人の計画や目標を理解し、最大のインパクトのために最適に協力できるようにします。

なぜ 3 が間違っているのか: 機能やバグの修正の貢献は、異なるコーディングやドキュメントスタイルを紹介する時間ではありません。プロジェクト内でのコーディングスタイルや慣行を変更するのは、大きな取り組みです。そのため、プロジェクトのコーディングやドキュメントスタイルの変更を一直線に並べる必要があります。異なるコードスタイルが必要な場合は、問題としてそれを持参し、現在の貢献の外部のホスティングチームと他の参加者とのディスカッションを行います。

なぜ4が正しいのか:小規模な変更は、レビューに関与するコードだけでなく、提案された変更が解決策の残りの部分にある可能性がある影響について、理解しやすくなります。限られたスコープの議論は、変更の迅速な受諾につながるので、より迅速にソリューションに利益をもたらします。

立ち往生したら、ドキュメントとコードを見直して、再び行かなければならない。失敗した場合は、プロジェクトの公開チャネルの明確化やヘルプを依頼します。
私のコードは、私が貢献している変更のテストを持っています, 私は私が貢献する前に、私の変更をテストし、検証しました, そして、テストは、プロジェクトのためのCD / CIパイプラインに統合されています.
ドキュメントとテストを更新して、貢献したコードの変更と整列します。
プロジェクトのスタイルに合った貢献

なぜ 1 が正しいのか: 質問に答えるために提供される文書に委任する必要があります。回答がドキュメントから欠落しているか、説明が不明確でないと認識したら、プロジェクトへの質問は、次のステップです。これからのコントリビューターが手伝ってくれるだけでなく、

なぜ2が正しいのか:あなたが書いたコードの適切なテストを持つことは、コードが堅牢で維持可能であることを確認するための一般的な優れた工学的慣習です。 InnerSourceプロジェクトでは、テストでは、コントリビューターとして自信を持たせます。コード統合プロセスの一部としてテストを自動化することにより、InnerSourceプロジェクトは、プロジェクトのすべての信頼できるコミッタ間でメンテナンスを広めることを可能にします。InnerSourceプロジェクトは、そのメンバーのステータスを独立したものです。従って、連続的な統合および連続的な配達(CI/CD)はInnerSourceで貴重です。

なぜ 3 が正しいのか: 必要な変更に対するテストと文書のチェックは、固有な貢献の一部であり、将来のコントリビューターが正しいパスをガイドするのに役立ちます。

なぜ4が正しいのか:コード慣習は、すべての参加者がコードを素早く理解できるように配置されました。あなたの変更は、現在の既存のコードスタイルと条約と組み合わせて、あなたの貢献が他のすべての人にレビューし、維持することも容易であることを確認する必要があります。

TIP: 複数の回答は、いくつかの質問で正しいかもしれません。

チームの制約なしに好きなソリューションを実装できます。
私は他の人と開発の努力を共有し、したがって、私はそうでなければ、自分で実装し、維持するために必要な機能を得ます。
私は社内で私の評判を確立しています。
より良いエンジニアになることができます。

なぜ1が間違っているのか:共有プロジェクトの制約内で作業する必要があります。その点で、InnerSourceは、健康なチーム内での作業とはあまり異なります。

なぜ2が正しいのか:共有プロジェクトでは、リソースを効果的にプールし、インパクトと機能がロールアウトできる速度を乗じます。

なぜ3が正しいのか:あなたのチーム外の人々と相互作用するので、より多くの人々はあなたの仕事様式およびあなたの能力を知ることを学びます、従ってあなたの評判を造るのを助けます。

なぜ 4 が正しいのか: 異なるチームから他のエンジニアと相互作用すると、知識と範囲を広げ、より良いコードの設計と構築を支援します。

別のチームのコードベースへの貢献は、通常、自分のコードベースへの変更よりもあなたからのメンテナンスが少ない必要があります。
重要な知識の広がりは、組織的な記憶を失うリスクを人として残すことを抑えます。
他の人があなたの貢献に依存しているため、あなたのチームのミッションをサポートしている依存したチームを確かめることができます。
共有プロジェクトに影響し、使用シナリオのサポートを支援することができます。

なぜ1が正しいのか:貢献が別のチームのプロジェクトに統合されたら、それはそれの必要な部分になります。コントリビューターは、通常、合意されたアドオン猶予期間の新機能の責任を維持します。その後、ホスティングチームは、プロジェクトの残りの部分と同様にコードを維持します。しかし、あなたのチームは、あなたがコードに依存し、それをよく知っているので、従事している必要があります。これは、あなたの影響を維持し、道路を驚かせないようにするのに役立ちます。

なぜ2が正しいのか:組織的変化は人生の事実です。従業員は、雇用を変え、組織は新しい会社の方向に調整する必要があります。ひとつの個人やチームに鍵の知識が制限されている場合は、すぐに失うことができます。知識が共有コードベースを使用してコミュニティを通して広がるとき、プロジェクトやソリューションを一貫した方法で推進するのに十分な知識を持つ人は常にあるはずです。

なぜ 3 が間違っているのか: 貢献は他のものよりもレバレッジを得るための手段ではありません。すべての参加者の利益に共通パスを共有する手段です。利点を得るためのレバーとして貢献を使用する試みは、多くの場合、厳しい批判と会っています, でも、コミュニティとコードのフォークに分割をトリガー, この場合には、不健康なと望ましくありません.

なぜ4が正しいのか:InnerSourceプロジェクトへの貢献は、共有プロジェクトがあなたのシナリオに必要な機能を持っていることを確実にするための最良のチャンスを与えます。 InnerSourceプロセスは、あなたが望むものを達成するためのコードを貢献できるだけでなく、あなたの意見を考慮に入れる通信チャネルと意思決定手順を作成します。

Fewer 開発者は、プロジェクトを随時完了する必要があります。
ドキュメントの増加により、意思決定が行われた後方を判断し、新しい開発者がスピードアップできるようにします。
知識の広がりは、仕事の直近エリア外で学習し、重要なプロジェクトに関する専門家のサイロを排除することを奨励します。
共有プロジェクトは、チームと企業全体のクロスコラボレーション間の全体的なより良いアライメントにつながる。

なぜ1が間違っているのか:InnerSourceは、各チームの目標とより緊密な一直線的な開発のために採用されるべきであるが、コストの節約やスタッフの減少のためではない。 InnerSourceプロジェクトは、サイロ化されたプロジェクトよりもはるかにコーディング(そしてもう少しコミュニケーション)が必要です。しかしながら、満足度は、チームだけでなく、顧客の間で終わると高くなります。

なぜ2が正しいのか:InnerSourceは、オープンソースモデルから、すべての議論と決定が書かれ、保存されるべき原則を採用しています。メーリングリストやフォーラム、バージョン管理リポジトリのコメント、バグレポートを通して、組織はプロジェクトとトレードオフ開発者の目標に関する情報を保持しています。あとは大変です。

なぜ 3 が正しいのか: InnerSource の慣行は、開発者をコードとそれらが通常相互作用しない人の両方に接続します。これらのコネクションは、特定のプロジェクトに関する技術的な知識を広げ、将来の知識がより簡単に流れている新しい社会の道を作成します。これらは、社内のサイロ化知識を削減する結果です。

なぜ4が正しいのか:プロジェクトがより広く共有されるように、それらを使用してチームは同じ共有コードベースを使用する必要性としてより近い直線に来る傾向があります。この共有ビジョンは、重複した作業を削減し、同社の全体的な利益です。