はじめに

InnerSourceが助けることができる問題の種類、それを行う方法、あなたが参加することによって期待できる利点の種類、およびそれすべての仕事をする基礎的な原則について学ぶために紹介をチェックしてください。

はじめに

この学習パスはInnerSourceへの導入を与えます。 InnerSourceは、オープンソースの実践と企業内のソフトウェア開発への原則の適用です。 InnerSourceソフトウェアは、会社に専念していますが、その中には誰がそれを使用し、それに貢献するために開いています。 この戦略は、さまざまな内部の利害関係者のニーズに応答し、ニブルであるソフトウェアを生産し、広く効果的なコラボレーションを可能にします。

この学習パスは、InnerSourceの候補者である状況を認識する方法を教えています。 InnerSourceがこれらの状況でどのように役立つかを高レベルで概説します。 InnerSourceを議論するときに使われる共有条件に精通します。 また、InnerSourceが基づいている主原則と、有効に適用されると見られる利点を列挙します。

InnerSourceが解決する問題は何ですか?

InnerSourceは、会社の組織構造の立場に関係なく、コラボレーションとコードの再使用を奨励し、報酬を与えます。 このアプローチは、社内の階層とそのサイロの境界内で、アイデアや作品が閉じ込められている伝統的な組織で見られるものとは異なります。 この考えの一例を挙げる1つの状況を見てみましょう。

同じ会社で2つのチームを想像して、他社のソフトウェアを1つのチームに分けて配信します。 たとえば、表示用のデータを取得するための API サービスに依存するユーザーエクスペリエンスが考えられます。 この状況は、ソフトウェアを製造する単一のチームが数十人や何百人もの消費者を持つことができる大規模な企業で共通しています。

チームを消費する場合に多くの機能が必要, チームを正常に作成するいくつかの要件と優先順位付けプロセスは、彼らが動作する機能を決定するために. 即時作業を優先しない重要な機能要求のために、消費チームは一般的に3つのオプションのいずれかを選ぶことができます。それぞれが独自の欠点が付属しています。

1. お問い合わせお問い合わせ 消費チームは要求された機能なしで一緒に何もし、鳴らすことができません。 このオプションは、少なくともその側の作業量を必要とします。 機能リクエストの恩恵に応じて、待ち時間はわずかに良いかもしれません。 しかし、特に要求された機能性が決して配信されていない場合、それは痛みの実量と来るかもしれません。
2. トレーニングお問い合わせ 待たせたくない人達は、要求された機能の欠如を補うために、別の場所で余分な作業を行うかもしれません。 この作業は、消費プロジェクトの変更として発生する可能性があります。 また、ニーズに合った新しいプロジェクトを作成したり、チームのシステム(コード/プロジェクト重複)の全部または一部を交換したりすることも可能です。 この戦略により、消費チームは要求された機能を自分の努力でのみ取得することができます。 しかし、いくつかの欠点が付属しています。
   1. 消費するチームによって行われるあらゆる仕事は同じ特徴の要求の他のどの消費者にも利用できません。
   2. 消費チームは、中核チームの能力の領域にない、新しく書かれたコードを維持するための長期の負担のために不注意に署名しました。
   3. 同社は、同じ問題領域で重複したプロジェクトとコードを取得しています。
3. エスカレートお問い合わせ 消費チームは、回答のために「いいえ」を取ることができないし、代わりに、プロデューサーの管理階層内の誰かに提唱して、作業を行うために生産チームに影響を与える(または力)。 このオプションは、作業を実行したり維持したりすることなく、要求された機能を得るため、消費チームにとって魅力的です。 しかし、それは必ずしも彼らの注意の一部を転換し、エスカレーションの非工学的作業に取り組むので、チーム上ではまだドラッグです。 また、このオプションは、消費者が自分の信頼性を損なう前に、機能リクエストをエスカレートできるほどに数回しか存在しません。 エスカレーションは、通常のワークフローと優先化方法からエスカレーションされた機能要求に対処するために、製造チームのメンバーにとって同様に混乱しています。

このディスカッションでは、InnerSourceのステージを設定します。 InnerSourceは、消費チームが機能リクエストを介して必要なものを得ることができない状況の同じタイプに適用されます。 InnerSourceはチームのメリットを得るための方法を提供します待ちます, トレーニングとエスカレート関連する欠点なし。

InnerSourceは、エンジニアが様々な新しい技術と人々と働ける機会を持っているので、エンジニアリング文化への一般的な改善を提供しています。 開発者は、組織的なサイロを横断するアイデアやソリューションを共有し、互いにメンターを学びます。 エンジニアやチームは、内部ソリューションをコモディティの問題に再利用することができます。これにより、組織の作業効率が向上します。

InnerSourceはどのように機能しますか?

チーム A は、チーム B によって生成されたソフトウェアを使用しているとしましょう。 チーム A は B をチームに依頼するが、チーム B はチーム A の時にその機能を実装できません。 InnerSource 設定では、A がこの機能リクエストを取得できない場合、代わりにプルリクエストを送信します。 つまり、チーム A は、チーム B のソフトウェアで直接機能を実装し、コード変更でプルリクエストを送信します。 チームBパートナーは、提出されたコードを見直し、承諾します。

この例では、チームAを呼び出します。ゲストチームとチームBホストチーム。 利用規約ゲストそして、ホスト自宅で訪問者を受け取るために状況をアナログに提案します。 その状況では、ほとんどの人は良いホストになりたいです。 滞在客の到着を期待して、物事をきちんと保ち、整頓されていることを確実にします。 ご宿泊者様は、お客様がお出迎えいたします。 自宅の公共エリアにある機能やユーティリティを使用することができます。 ご宿泊者様がお伺いするハウスルールは一部ございます。 同様に、ほとんどのゲストは家庭やホストに関して敬意を表したいと思います。 家のアイテムに気をつけ、滞在期間の規則に従う。 礼儀と礼儀をされている限り、彼らは戻って招待状を期待するか、または期待することができます。 訪問の周りのこれらの概念は、チームがコードベースにゲストの貢献を作る別のホストとして持って来るべき態度と行動のためのメタファーです。

InnerSourceプロセスの仕組みを詳しく見ていきましょう。 今回の説明では、ゲストやホストチームにいくつかの重要な個人を名前付けます。 まずは、 プロダクトオーナー ホストチームが貢献として受け入れる機能を決定する。 ふりがな コントリビューター ホストチームによるレビューのためのコードの貢献を提出するゲストチームの個人です。 ふりがな Trusted Committer コントリビューターがプルリクエストを正常に送信するために必要なタイムリーなサポートとメンターシップを提供することでホストチームを表します。 小さな草の根は、一人の人がしばしば満たされる努力 両方とも 製品の所有者と信頼できるコミッタの役割。

これらの定義では、InnerSourceの貢献の基本的な輪郭はここにあります。

• ゲストチームまたはコントリビューターは、ホストチームからの機能をリクエストします。
• 製品所有者は、ゲストチームまたはホストチームのメンバーによって、機能リクエストを代表するユーザーストーリーが作成されることを確認します。 これらの物語は、ゲストチームへの同意可能な条件で要求された機能を説明する必要があります。 彼らはまた、受け入れられる作業のために、機能がどのように配信されるべきかについて、ホストチームから任意の詳細をリストします。 アーキテクチャの制約、コーディングの規則、依存関係の使用、データ契約など、そのような詳細の例
• 信頼できるコミッタでサポートされているコントリビューターは、要求された機能を実装するためにプルリクエストを提出します。

これらの手順は、チームの時間や優先順位の一般的な組織の特定のシステムではないことに注意してください。 InnerSourceは、すでに組織の既存の方法を持ち、ゲストチームがホストにコードを貢献することを望んだ場所を一緒に働く方法のフレームワークを提供すると仮定しています。

このオプションは、ソリューションのメンテナンスの長期負担をかけずに必要な機能を得るため、ゲストチームのためにうまく機能します。 彼らはより良いスケールと消費者にサービスを提供することができるので、それはホストチームのために動作します。 共有の問題が共有され、集中的に維持された場所で終わるため、社内で大規模に機能します。 より多くのエンジニアリングタイムは、機能交渉とエスカレーションプロセスのメカニズムではなく、企業の問題を解決するコードの作成に焦点を合わせています。

• ホストチームは、コアチームパターン。
• ふりがなTrusted Committerパターン。

InnerSourceのメリットは何ですか?

InnerSourceによるコラボレーションには多くの利点があります。 InnerSourceは企業にスケーラブルな戦略を与えます必要なときに機能リクエストを取得するゲストチームメンテナンスの長期負担なく。 ゲストチームが利用するコードに入れる時に、会社全体が勝っています。

その結果はInnerSourceの輝く利点ですが、定期的なInnerSourceの貢献を受け取るホストには多くの利点があります。 InnerSourceのプロセスの一環として、ホストチームの製品所有者は、関連する機能が良好で望ましいアウトセットから同意することに注意してください。 InnerSource はホスト チームが受け取ることを可能にしますより良い製品を作るのに役立ちます消費者のために!

InnerSourceはホストチームにスケーラブルな戦略を提供します多くの消費者から要求されるさまざまな機能を満たすため。 ホストチームのフルタイムのメンバーの固定能力を与えられた、それは、時には、その消費者のコンバインドされたビジネスのロードマップは、ホストチームの製品で行われる大量の作業を非常に(または不当に)要求する可能性が高いです。 InnerSourceがなければ、この状況は、そのリーダーにエスカレーションされた多くの機能要求に対処する、ストレスの多いチームに簡単につながります。

しかし、ホストチームがInnerSourceを経由して運営する場合、それらの機能を構築するために必要なエンジニアリングリソースは、ゲストコントリビューターの形での重要性に比例して表示されます。InnerSource は強制マルチプライヤーになりますこれにより、ホストチームは、需要が高い時間帯に実際のサイズよりも一時的に大きく機能することができます。 要求が終了したら、チームスループットはチームヘッドカウントや作業アイテムの微小管理なしで、通常のレベルに戻ります。 InnerSourceは、組織が特定の時間でそれを必要とする場所で、エンジニアリング時間を有機的に流れることを可能にします。

ホストチームがそのシステムで達成することができるという作業を超えて、通常のInnerSourceの貢献はホストチームを与えますすべての消費者とのよりよい条件そして優先順位付けの直線お問い合わせ ホストチームは、それが生成する仕事で収集する最高の要件を行うことができますが、消費者自身が仕事を送信するとき、その結果の変更が消費者のニーズだけに整列される可能性がはるかに高くなります。 変更を提出する唯一の1人のゲストチームであるかもしれませんが、そのチームは他の多くの消費者の代表的である可能性があります。

このアライメントに加えて、一般的なトレーニングと教育もあります コントリビューター 彼らが一緒に働き、学ぶように 信頼できるコミッタお問い合わせ このインタラクションは、コントリビューターが自分のキャリアで学び、成長するのに役立ちます 高い仕事の満足お問い合わせ プロジェクト文書は、これらの貢献をスケールで有効化できるように改善します。 貢献者は、ホストチームプロジェクトでステークを感じます。 同僚や参加する新しいチームに勧めることは何かです。 彼らはプロジェクトをよりよく理解し、他の人にそれに関する質問に答えることができ、その負担の一部のホストチームを信じています。 より一層のプロジェクトに貢献している人達が、社内のアイデアを横断する。 この学習とクロスチームアライメントは、時間の経過とともに役立ちます 従来の会社のサイロを破壊して下さい.

InnerSourceの原則

企業、チーム、プロジェクト、個人が異なる。 そのため、InnerSourceの概念が1つの状況から別の状況に変化するという正確な方法。 しかし、そのコアでは、InnerSourceの成功事例の岩盤を形成する4つの原則です。 これらの原則は、成功したオープンソースプロジェクトにインスピレーションをもたらし、InnerSourceのために必要です。

原則は次のとおりです。

• オープンネス
• 透明性
• 優先的メンターシップ
• ボランティアコードの寄付

これらの各原則を詳しく見ていきましょう。

オープンプロジェクトの構成により、スムーズな貢献が可能 プロジェクトは、リポジトリのルート内の README.md と CONTRIBUTING.md ファイルをよく理解できるはずです。 組織内の誰もが目的のプロジェクトを見つけることができ、ホストチームメンバーからの直接的なガイダンスの不当な量なしでランプアップすることができます。 ホストチーム連絡先情報は、プロジェクトの感覚を作るため、多くのチャネルと同等である必要があります。 ホストチームは、InnerSourceの貢献を彼らのプロジェクトに受け入れることを意図して、関連する組織チャネルを通じて、意識を高めるために共有する必要があります。 特に、InnerSource で通常の「ブロードキャスト」を確立したいという小さな設定では、あなたのチームがやっています。 しかし、より大きな設定では、そのような放送は多くのノイズを生成し、プロジェクトが使いやすいツールで発見可能であることを確認するためにより適切かもしれません。 目標は、あなたの会社で働く適切なチャネルを使用することを意識しています。

つまり、上記の排気リストです。 プロジェクトのオープン性は、プロジェクトがInnerSourceの観点からどのように成功するかに直接関連します。 より多くの開いている、少数の障壁は見込み客のための場所に置かれます。 開口部が少ないほど、誰が貢献するのかが難しくなります。

ゲストチームがプロジェクトに有意に貢献できるようにするため、主催者は必ず参加してください。トランスペアレントお問い合わせ これは、ゲストチームが理解できるようにすることを意味します。

• プロジェクト/リポジトリとその方向
• 顕著な特徴の条件
• 機能要件の進捗
• ホストチームの意思決定

可能であれば、上記は明確かつ詳細に伝えるべきです。チームの内部定義から、プロジェクト固有の特別なケースのシナリオまで。 このコミュニケーションは、ホストチームの一部ではなく、容易に明確に理解できる方法で行われるべきです。

メンターシップ ホストチームからゲストチームまで 信頼できるコミッタ InnerSourceの重要な側面です。 貢献者 ゲストチームでは、ホストチームのプロジェクト/レポについて十分に理解できるように、チームを上回っています。 そのためのプロセスでは、ホストチームのソフトウェアシステムがプロジェクト/ソフトウェアのための一般的な消費者および大使としてよりよく理解したいと考えています。 この個々のコントリビューターは、時間とともに経験を持ち、信頼できるコントリビューターとしてプロジェクトでより広範な役割を果たします。

これは、コントリビューターのためのこのメンターシップが重要なことです優先順位付けホストチームによる 主催者チームは、ゲストチームのコントリビューターに時間を作るように努力する必要がありますコントリビューターがそれを必要とする時ホストチームに便利なときとは対照的に。 時には、単に自分自身をコーディングするのではなく、他の人がコードに助ける時間を費やすために、ホストチーム上のエンジニアのための文化的な変化かもしれません。 このメンターシップは、個々のコントリビューターとホストの両方に価値があり、うまくいく価値があります。 それは長期的に相互に有益であることを証明します。 コードを改善することにより、コントリビューターは、そうでなければ存在していない組織内の関係を強化または改善します。 オープンソースは、この点を容易に認識し、プロジェクトの信頼できるコミッタステータスを達成するための名誉として考慮します。

最初の単語ボランティアInnerSourceでは、ゲストとホストチームの両方が自分の自由意志で発生することを意味する。 ゲストチームは、ホストチームとホストチームにコードを自発的に寄付します。 このオプトインの性質は、各チームは、その関与が他の人の目的に値を追加することを確認する必要があることを意味します。 全体ミッションとの究極のアライメントではなく、貢献を受け入れるために必要なホストチームではありません。 自らの使命や優先事項を究明しない貢献を提出する必要がないゲストチームです。

単語コードコードゲストとホストとの間のコラボレーションがコードの全ての方法であることを強調します。 開口部の問題へのゲスト関与、要件の更新、ドキュメントの修正などは良いですが、コラボレーションは、私たちが議論したすべての利点を達成するためにコードを提出する限り到達する必要があります。

コンクルージョン

この学習パスでは、InnerSourceの紹介をしました。 InnerSourceは、オープンソースのベストプラクティスと内部ソフトウェア開発の原則を適用します。 必要な機能要求を提供することができないチームを作成するときに、消費者に追加のオプションを与えます。 InnerSourceの成功は、 プロダクト オーナー そして、 信頼できるコミッタ から ホストチーム 同様に コントリビューター から ゲストチームお問い合わせ InnerSourceは、参加チームの両方に多くの利点をもたらします。 InnerSourceの有効な仕事がであるそれら主主義 自主コードの貢献 そして、 優先メンターシップ.

このトレーニングはInnerSourceのハイレベルな概要を含んでいますが、InnerSourceを実際にあなたのチームのために働かせることで有用なより多くの細部があります。 InnerSourceとそのベストプラクティスに関する継続的な会話につながりたい場合は、参加してください。InnerSource Commonsの特長お問い合わせ Commons は、Slack チャネル、InnerSource パターンワーキンググループ、および複数人のグループを毎年スポンサーしています。 共通点への参加は、InnerSourceの最新の接続を維持する素晴らしい方法です。

InnerSourceは私のプロジェクトのために右ですか?

InnerSourceは、社内ソフトウェア開発へのオープンソース原則の適用です。 右側に、共有サービスとモジュールの進捗をブロックし、採用を容易にします。 この記事では、プロジェクトを実行するためのInnerSourceアプローチの採用を検討する際に自分自身に尋ねるガイダンスと質問が含まれています。

InnerSourceのアプローチは、プロジェクトのユーザーの貢献が期待される場合にのみ意味をします。 利用者がプロジェクトエリアで指示するエネルギーの顕著な量を見たり、予測したりする貢献を期待できます。 いくつかの例:

• プロジェクトの使用量と採用量が高まる。
• チームよりも多くの機能の要求が満たされる時間があります。
• プロジェクト内の機能の欠如を補うために、ワークアラウンドを行うユーザー。
• 実装するだけのように説明する時間がほとんどかかる機能要求。
• プロジェクトの複数のロードマップの依存関係。

対談者でも、コードは流れません。 次のような活動を通じて貢献を奨励し、支援する必要があります。

• ユーザーのシナリオを理解し、プロジェクトにどのような貢献がそれらのシナリオを満たすのに役立つかを提案します。
• ユーザーが必要な貢献をし、それらがそれらを確実にするためにそれらに従うようにするために招待する。
• 維持するお問い合わせエンジニア全員がプロジェクトに貢献するために必要な文書。
• 与えられた貢献を実装する方法として、対面ガイダンスと方向性を与えます。
• 任意のアドホックの質問のための定期的な時間の間に利用可能であること 貢献者がある.
• 着信プルリクエストのタイムリーなレビュー。
• 提出されたコードの維持管理(後)保証窓).

InnerSourceプロジェクトは、プロジェクトが会社に固有の場合や、その排他的な使用が企業に戦略的なビジネス上の優位性を与えるとき、意味を作る。 他の共同プロジェクトは、貢献プールとインパクトを高めるためにオープンソースとして実行する必要があります。

貢献が来たらそして、これらの貢献をサポートいたしますそして、あなたのプロジェクトは会社固有のものであり、InnerSourceはプロジェクトに適しています。

InnerSourceの死亡率

InnerSourceは、共有の必要性 – ビジネスまたは技術的な当社の複数のチームがある場合に役立ちます。 誰もが活用できる一つの共有プロジェクトをしたい。 この共有は、各チームが、以前に何をしたかを再考する代わりに、独自のビジネスエリアでできるだけ多くの時間を費やすことができます。

共有プロジェクトをInnerSourceで管理します。つまり、オープンソースの慣行と原則を実行する方法に適用します。 これらのプロジェクトは、会社全体で再利用と貢献のために開いています。 理論的には、InnerSourceプロジェクトであっても、InnerSourceポータルにリストされている一般的なInnerSourceプロジェクトを見つけることができます。

InnerSourceは、私たちが働く方法の一部である必要があります。 ソフトウェアロードマップを配信する際には、他のチームと共有する可能性があり、停止して考える必要があるときに。 すでに会社に何か(ほとんど)がこのニーズを解決しているか? もしそうなら、そのプロジェクトへのオンボードであっても、そのプロジェクトが最初にそのプロジェクトに貢献して使用例を満たしたとしても。 既存のプロジェクトがない場合、最初のコンシューマーとして自分自身と密接な方法でビルドし、InnerSourceポータルにリストします。

この方法で働くと、私たちがすべて入れたエンジニアリング時間を最大限に活用し、当社のユニークな使命により多くの時間を費やすことができます。 InnerSourceの死亡率を採用します。

ワークブック

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

1. あなたのチームは、そのコアソフトウェアを作成するリソースが不足しています
2. 高いレベルのマネージャーがソフトウェア変更を実施するために別のチームを得るのを悪用しています
3. ほとんどのソフトウェアは、ビルドではなく購入されます
4. ソフトウェア変更がチームに提出されていない

なぜ 1 が間違っているのか: InnerSource では、他のチームがソフトウェアをアップグレードして、ニーズを満たすことができます。 自分の優先順位を取るために他のチームに依存することはできません。また、別のチームにプロジェクトを割り当てることができます。 InnerSourceは自発的な貢献に頼りになり、ゲストとホストチームの関心が整列するところを動作します。

なぜ2が正しいのか:コードベースの異なる部分に異なるチームを割り当てる大規模な組織は、常に優先順位上の戦いに苦しむ。 あなたのチームのビジネスプランに重要なのは、コードを所有するホストチームへの余計な迷惑として見られるかもしれません。 InnerSource では、他のチームのプロジェクトに直接必要なコードを追加できますが、そのガイドラインやホストチームをフォローする責任があります。

なぜ 3 が間違っているのか: サードパーティが独自のソリューションを配信する場合、その開発に参加することはできません。 ただし、第三者からの無償およびオープンソースソフトウェアは、コラボレーションのための優れた機会を提供します。 InnerSourceを学習するスキルは、あなたの会社外のソースプロジェクト、およびその逆に適用することができます。

なぜ4が間違っているのか:InnerSourceは、ソフトウェアを強化するために他のチームの欲求を悪用します。 ソフトウェアが成熟し、多くの変更を必要としない場合、あなたや他のチームが強化する理由はありません。 あなたのスキルは、新しいプロジェクトに向けることができます。

1. 複数のチームが異なるソリューションを実装し、共有の問題を防ぐ
2. チームが優先順位を決めるのを助けるために、高レベルのマネージャーをもたらす
3. 少数の開発者が同じ量のコードを作成する必要があります
4. コードベースをよく知る人へのメンテナンスを制限

なぜ1が正しいのか:各チームが単一のコードベースを担当する場合、異なるチームは同じ機能を実装するために特定のコードベースにコードを追加する傾向があります。 これは無駄なだけでなく、互換性につながることができます。 InnerSource では、コードを単一のコードベースに追加して機能を実行します。

なぜ2が間違っているのか:InnerSourceは、チームメンバーが自分の優先順位を設定することができます。 草の根の参加を特徴とする自主システムです。 実際、そのベストでは、ハイレベルマネージャーの関与を減らし、組織の他の戦略的ニーズに取り組みます。

なぜ3が間違っているのか:InnerSourceは魔法ではありません。 数千行のコードを書くには、同じ作業が必要です。 InnerSource では、プロジェクトに必要なコードを取得し、必要な時間を投資して記述します。

なぜ 4 が間違っているのか: InnerSource の全体的な考え方は、メンテナンスや新機能の周りに広がることです。 問題を見ている会社は、それを修正するために機能しています。 チームでは、InnerSource を使用しており、広範囲にわたる参加を強みとしています。

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

1. エンドユーザ
2. コントリビューター
3. 信頼できるコミッタ
4. 製品所有者

なぜ 1 が間違っているのか: InnerSource は、開発者(コントリビューターと信頼できるコミッタの両方)が製品所有者によってサポートされる技術活動です。 エンドユーザーのニーズを満たしているのは究極の目標ですが、エンドユーザーは誰が仕事をするか、それがどのように行われるのかを判断しません。したがって、InnerSourceを構成するコミュニケーションと活動の一部ではありません。

なぜ2、3、4が正しいのか:InnerSourceの3つのキーの役割は、基本的な貢献(コード、文書、ガイドライン)、メンターのコントリビューター、および組織のニーズを表す製品所有者を作成するコントリビューターです。

1. すべてのエンジニアがコードベース全体を知るための厳格なトレーニング
2. 各変更をベットする製品所有者を取得する
3. 信頼できるコミッタによるコードレビュー
4. 企業外の専門家によるレビュー

なぜ 1 が間違っているのか: すべてのエンジニアがすべての会社のコードを理解できるとは思えない。 各エンジニアは、自分の仕事に即座に影響を与えるコードだけを理解する必要があります。 しかし、InnerSourceは、エンジニアが他のチームから望む深さまでコードを探索し、その限られた理解を持っている間、他のチームのコードに貢献することができます。 エンジニアは、単に1つの機能を読み、例えばバグ修正を提供することができます。

なぜ2が間違っているのか: 信頼されたコミッタは各変更をベットします。 InnerSourceは、組織の階層に低下し、製品所有者が戦略と要件に集中する責任を負います。

なぜ3が正しいのか:信頼できるコミッタは、優れたコード、コミュニケーション、メンタリングスキル、そしてコードとチームの目標の知識を書くための実証済みの能力のためにコミュニティによって選ばれています。 それらはコードベースにそれらを許可する前に、すべての貢献を見直します。

なぜ 4 が間違っているのか: InnerSource は、オープンソースとは異なり、社内のコードを保持します。 もちろん、チームは外部の専門家(セキュリティレビューなど)を持たずに、InnerSourceの一部ではありません。

1. コードがチームのスタイルガイドラインに一致していることを認識
2. コントリビューターが要求するコードを書く
3. コントリビューターの指導
4. コントリビューターのコードをチームのコードベースに統合

なぜ 1 が正しいのか: 開発チームは、プログラミングのスタイル、構造、品質、セキュリティ、および一般的な遵守のための基準を維持する必要があります。 これらはコントリビューターと書かれ、共有されていますが、信頼できるコミッタは、チームが外部にガイドラインを伝えている主要な伝送ポイントです。

なぜ2が間違っているのか:InnerSourceの目標は、外部にチームのコードに貢献し、品質管理のメンタリングだけでなく、標準とガイドラインを提供することです。 チームのメンバーが外部に要求した書き込みをしたならば、それはInnerSourceの約束全体に根絶するだろう。それは単に機能要求に対する伝統的な応答である。 さらに、信頼できるコミッタがコードを書いた場合、InnerSourceは、プログラミングの負担を取り除きることなく、新しいコミュニケーションの負担を課すだけです。

なぜ3が正しいのか:コントリビューターのコードはコントリビューターを訓練するための優れた出発点です。 メンタリングは、コードコントリビューション自体よりもさらに有益である教育および個人的成長を作り出すことができます。 そしてコントリビューターは、コードベースとチームの目標について有能で知識が豊富であっても、チームの目標と基準に沿って貢献をもたらすためのガイダンスの恩恵を受けることができます。

なぜ4が正しいのか:信頼できるコミッタは、教育とメンタリングの責任と共に、プロジェクト上のコミッタの典型的な役割を担い、コードがうまく機能し、アプリケーションで何かを破らないことを保証します。

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

1. ユーザーからの貢献でコードを改善
2. ユーザーのニーズを理解しているから解放されます
3. 大量の活動の期間中に数え切れない中断が受けられます。
4. より大きな組織の重要性を強調

なぜ 1 が正しいのか: ホストチームはコードベースを他の人に開き、そのコードがより良くなり、すべてのコーディング自体を行なったよりも多くの機能を持つので、正確に貢献をベットするように努力します。

なぜ2が間違っているのか:InnerSourceは要件と優先事項の定義に影響を与えません。 プロのソフトウェア開発と同様に、開発者はユーザーを理解しています。

なぜ3が間違っているのか:多くのチームからのコントリビューターは、大量の活動期間中に、コード、希望の変更を提出します。 つまり、ホストチームは外部と多くのやり取りをしなくてはなりません。 結果は、しかし、短期間でより多くのコードです。

なぜ 4 が間違っているのか: 外部の人たちは、彼らが重要であると認識するプロジェクトに参加し、重要なことはコードの自発的な寄付を優先する。 InnerSourceは自発的な貢献を勧誘するので、外部の人たちは重要なプロジェクトだけに取り組む。 しかし、プロジェクトが重要であるということを説得することで、外部の人たちに貢献を求めることができます。

1. マネージャーはチームにより多くのお金を割り当てます
2. 社内外の方からコードを閲覧・コメントすることができます。
3. 貢献者は、チーム自身のコードベースでホストチームの作業を補うことができます
4. それはチームの永久的な拡大につながります

なぜ 1 が間違っているのか: InnerSource は、チームのための資金に影響を与えません。 他のチームのマネージャーは、自分のチームメンバーが他のチームでハイプライティコードで作業できるように、お金を割り当てることができるのは事実です。 チームメンバーは、他のチームのメンバーではなく、コードで動作するようにしています。

なぜ2が間違っているのか:InnerSourceはオープンソースではありません。 社内外のコードは公開されていません。 しかし、一部の企業では、コードを一部開いて、InnerSourceプロジェクトをオープンソースに変えることを選択しています。

なぜ3が正しいのか:InnerSourceはホストチームのコードで働くためにホストチーム外の会社員を招待します。 ホストチームは、ユーザーや消費者のニーズの外部の理解から恩恵を受けており、新しい機能が追加されました。

なぜ 4 が間違っているのか: InnerSource は、時間のパンチの間に貴重な力乗数になることができます。多くのチームから人々 を一緒に持って来ると、高優先度コードをすぐに完了することができます。 しかし、パンクの後、人々は自分のチーム内のプロジェクトに戻って行きます。

1. チームの責任間の明確な障壁を確立して下さい
2. 伝統的なトレーニングをメンタリングで置き換える
3. チームを別のチームに紹介する
4. あらゆるコーディングが始まる前にすべての条件を確立して下さい

なぜ 1 が間違っているのか: InnerSource は、各チームが取り上げた責任を負います。 その目標は、一人のチームから別のチームとコラボレーションできるようにすることです。 外部は、ホストチームのコードだけでなく、そのスタイルと基準を学習します。 InnerSourceでは、ホストチームは、外部にそのコードに対する責任を高めることを奨励しています。

なぜ2が間違っているのか:伝統的なトレーニングは、プログラミング言語、開発ツール、そして優れたソフトウェアエンジニアリング技術などの基本的なスキルのためにまだ重要です。 しかし、メンターはこのトレーニングを強化し、InnerSourceの重要な部分です。

なぜ3が正しいのか:大きなプロジェクトでは、他のチームによって消費されるサービスを頻繁に作成します。 サービスをコーディングするチームは、多くの場合、究極の目的と要件とサービスに基づいて構築するチームを理解していません。 InnerSource はチーム間のコミュニケーションを改善し、ホストチームによるベッティング後のコードベースに直接コードを置くユーザーの最大の知識を持つチームを可能にします。

なぜ4が間違っているのか:要件はInnerSourceを使用する決定に密接に関連していません。 たとえば、InnerSource では、開発者がチーム内外で機能を交渉できるようにします。 堅い条件の設定(滝モデル)か緩い条件の設定(敏捷モデル)と互換性があります。 しかし、InnerSourceは、個々の開発者を含む組織の外側の葉に電力と意思決定を低下させる傾向があるため、プロジェクトのコンテキスト内で独自の要件を設定し、環境の新しい側面を満たすためにそれらを変更することをお勧めします。

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

1. 役割モデルとしての役割
2. 自分のコーディングを止めてロールを取る
3. 貢献したコードのスクラッチ性を高める
4. 自分のチームによって書かれたレビューコード

なぜ 1 が正しいのか: 信頼できるコミッタは、タスクのコーディングとコミュニティの構築へのコミットメントで優れたパフォーマンスのために選ばれています。 したがって、行動は、より良いコードとより強いコミュニティの追求で他の人にモデルとして機能します。 多くのコントリビューターが信頼できるコミッタになることを目指しています。

なぜ2が間違っているのか: 信頼できるコミッタは、チームのすべての活動に引き続き参加しています。 信頼できるコミッタロールは、それらを交換するのではなく、貢献を集中させます。 彼らはまた、彼らのチームのコードを理解するために、コーディングを維持する必要があります (おそらく前にあまりありません) 外部の貢献者を支援し、自分の仕事を判断するのに十分十分に. 最後に、信頼できるコミッタロールは開発者にとって一時的であり、フルタイムのコーディングに戻ります。

なぜ 3 が正しいのか: 1 つのチームが独自のコードを開発する場合、チームのメンバーは、コードとその目標の理解を共有する傾向があります。 それらはベッティングを必要としない、または最低のベッティングを提供するかもしれない。 InnerSourceは、自分のコードのより慎重なチェックを必要とする外部のコーダをもたらします, 彼らは自分のビューと経験でプロジェクトに来るので、.

なぜ4が正しいのか:すべての貢献は、目の2番目のペアから利益を得ることができます。 そのため、信頼できるコミッタは、外部とチームの両方からコードをレビューします。

1. 建設的なフィードバックとアドバイスでコード投稿に対応。
2. 優れたコード自体を書く。
3. 個人研修やプレゼンテーションを実施
4. ペアプログラミング。

なぜ1が正しいのか:学習者が特定のプロジェクトに焦点を合わせ、自分の努力から一般的なレッスンを導き出すとき、教育は最も効果的で長持ちすることが多いです。 学習経験の深刻化は、コードを書くために誰かに尋ねるよりも強力であり、それがどのように改善できるかを説明しています。 これは信頼できるコミッタの重要な役割です。

なぜ2が間違っているのか:素晴らしいコードを書くことは、信頼できるコミッタであるために素晴らしい準備と前提条件ですが、メンターシップは例よりも多くあります。 メンターシップは、積極的に他の人に教え、プロジェクトでコードする能力を改善しようとしなければなりません。

なぜ3が間違っているのか:各信頼できるコミッタの役割は特定のプロジェクトに結合され、個々のコードの貢献がコードベースに受け入れられる必要があるサポートを持っているのを助けるように設計されています。 ほとんどのトレーニングとプレゼンテーションは、大きな聴衆を念頭に置いて設計されており、より一般的なトピックを持っています。 信頼されたコミッタメンターシップは、主に1対1レベルで起こります。

なぜ4が間違っているのか:ペアプログラミングはリモートで行うことができますが、コントリビューターが信頼できるコミッタで特定の時間を調整できるという保証はありません。 信頼されたコミッタメンターシップは、ほとんど非同期かつデジタル的に起こります。