学習パス：Trusted Committer

Trusted Committer セクションでは、InnerSource Trusted Committer であり、コントリビューターをサポートする方法について説明します。

Trusted Committerロールの紹介

Trusted Committer (TC) は、InnerSource コミュニティにおける重要な役割の1つです。 Trusted Committersは、重要な技術的決定とコントリビューターを信頼し、最終的にフィニッシュライン上の貢献を得るコミュニティの人々として考える。 Trusted Committerの役割は、要求とやりがいの両方です。 InnerSourceコミュニティの成功のための単なる意見のゲートキーパーであり、楽器です。

一般的に言えば、Trusted Committer の役割は、その特権ではなく、その責任によって定義されます。 Trusted Committersは、InnerSourceコミュニティとコミュニティが構築する製品の両方の利益を表しています。コミュニティとプロダクトの健全性を懸念しています。 Trusted Committerとして、技術とコミュニティ指向の責任の両方を持っています。次のセクションでは、これらの寸法を両方調べます。

Trusted Committerが実際に何をするのか詳しく説明する前に、Trusted Committerの役割をInnerSourceのほかの役割と大まかに比較し、この名称が適切で重要だと考える理由を説明しましょう。始めましょう。 コントリビューター ロール。ツイート コントリビューター — 名前が示すように、InnerSourceコミュニティへの貢献をします。これらの貢献は、バグレポート、機能リクエスト、文書などのコードまたは非コードアーティファクトであってもよいです。

貢献者コミュニティの一部ではない場合があります。チームのニーズを具現化するために、別のチームによって送信される場合があります。私たちが時々も参照している理由貢献者としてスタッフまたは一部としてゲストチームお問い合わせふりがなコントリビューターコミュニティの期待とプロセスに合致する責任を負います。

ふりがなTrusted CommitterInnerSourceコミュニティのメンバーで、時々呼ばれることもあります。ホストチームお問い合わせこのアナログでは、Trusted Committerは、家を建て、そのゲストが快適で効果的に働くことができることを確認するために家ルールを設定するために責任があります。貢献者と比較して、Trusted Committersは、生産に近いコードをプッシュする責任を獲得しており、一般的にそれらに関連するリスクの高いレベルを持つタスクを実行することができます。

ふりがな プロダクトオーナー (PO) InnerSourceの3番目のロールです。 POは、アジャイルプロセスと同様に、コミュニティが実施する要件とストーリーを定義し、優先する責任があります。 PO は Trusted Committer と頻繁に相互作用します。 (例えば、要求されたか、または貢献された特徴が実際にプロダクトに属していることを確認してください)。特に小さく、草の根InnerSourceコミュニティ、Trusted Committerは通常POとして機能します。お問い合わせプロダクトオーナー学習パスセグメント詳細情報

Trusted Committerの役割は、すべての成功したInnerSourceコミュニティに存在するが、すべてのコミュニティがその名前を使用するわけではありません。一部のコミュニティでは、Motainer という用語を使用しますが、この用語は、たとえば、GitHub で定義されている「Maintainer」の役割など、他の技術的なロールと競合します。 Apache は用語を使用するコミッタ, あまりにも, しかし、彼らは、その役割に少数とほとんど技術指向の責任を添付. Trusted Committerは、コミュニティ指向の責任で、それを超えて行く。 Trusted Committerの「信頼される」とは、この人が信頼され、その管理とコミュニティの両方が自分の仕事をするために役立っています。 Trusted Committersは、オープンネスと透明性を促進することにより、プロセスにおける信頼と製品の構築にも貢献しています。

ネーミングがソフトウェアの書き込みにどのように重要であるかと同様に、ロールの正しい名前を選択し、誰もがコミュニティで果たした役割について同じ理解を持っていることを確実にします。

Trusted Committerの用語を使用する理由は、ロールの基本的な理解を持っているので、Trusted Committerがソフトウェアプロジェクトで他の一般的な役割と相互作用する可能性がある方法を知っているので、Trusted Committerの責任を見てみましょう。

Trusted Committersには、以下のようなさまざまな責任があります。

製品の品質確保
コミュニティを健康に保つ
貢献をするために障壁を減らす
コミュニティのアップレベルアップ
コミュニティのニーズを提唱する

この記事の最後にTrusted Committerになるというパスを、次のページで詳細にこれらの責任を見てみましょう。

製品の品質の確保

Trusted Committerの役割に最も頻繁に関連した責任から始めましょう:製品の品質を確保します。

InnerSourceコミュニティでは、Trusted Committersオーナーすべての技術関連の決定、特に製品品質に関するそれら。所有権は、場所の決定が続くことを確認する必要性を意味します。これには、コミュニティの内側と外側のこれらの決定のために、必要に応じて、コミュニケーションと-を含みます。しかし、Trusted Committersは、必ずしもすべての技術関連の決定を自分自身にするか、それらを実行するためにすべての仕事をしていません。

Trusted Committerは、コミュニティの品質基準を伝え、明確化し、理解しやすく、実用的な方法でそれらを形成する仕事です 貢献者お問い合わせこれは、これらの品質基準を通信するために、もちろん、Trusted Committersの最も効果的な方法は、例えば書かれています。 InnerSourceコミュニティの目標は、開発を整理するだけでなく、生産するソフトウェアの品質だけでなく、伝統的なソフトウェア開発プロジェクトからそれを試してみる価値のある目標になると思います。 InnerSourceコミュニティの信頼を確立し、維持するために、ソフトウェアの品質の高いレベルは、ユーザーとその管理の一部に不可欠です。悪いリリースがこの信頼を瞬時にシャッタリングできるのは、すべて知っています。

Trusted Committersはコミュニティがインフラと品質ソフトウェアを生成するために必要なツールを持っていることを確認してください。ピアレビューは、通常、プルリクエスト(PR)の一部として実行され、品質を確保するために最も頻繁に使用されます。通常、必要な改善点を指摘し、プルリクエストを開始して参加することができますが、通常は、最終的に貢献を承諾し、マージしたり拒否したりできるTrusted Committerだけです。「Trusted Committers は、生産に近いコードをプッシュできる」と述べたとき、これは以前意味したものです。 Trusted Committers も助けるべきです 貢献者 PR中、フィニッシュライン上での貢献を得る。

とはいえ、最終的にはコントリビューターの仕事で、それが起こるようにする。 Trusted Committerのジョブは、デフォルトですべての貢献を受け入れるものではありませんが、品質とスコープの用語で定義された基準を満たしているものだけを受け入れます。そして、Trusted Committersは、コントリビューターのコードを書き換えることを避けて、できるだけ「フィット」するべきです。つまり、より多くの時間を費やすという意味でも、 貢献者 広報担当 Trusted Committersは長期的な視点をとり、このサポートがコミュニティの長寿に投資していることを理解し、長期的にコミュニティの発展スピードを上げます。

プロジェクトの要件や制限が前向きではなく、開発中に発見されることもあります。 Trusted Committersは、これらの発見が両方のために捕獲され、文書化されていることを確かめるためにも責任があります 製品所有者 そして、 貢献者.

しかし、品質に対するTrusted Committerの追求は、プルリクエストを超えて行く。 Trusted Committersは戦略的レベルの品質について考え、構築されているソフトウェアの長寿を保証します。これは、コードの清潔さを確保し、全体的なソフトウェアの概念的な完全性を維持するためのコード指向の責任を伴います。また、コミュニティがソフトウェアを再ファクタリングするのに十分な時間を与えているか、必要に応じて品質改善のためにリリース日を移動するなど、管理指向のタスクを伴います。 Trusted Committerの有効性は、コード健康に強く関連しています。

後者のTrusted Committersは、バグや脆弱なアーキテクチャの回避策を検証し、文書化する貴重な時間の大部分を費やす必要がありますし、オンボーディングやメンタリングに費やす十分な時間はありません 貢献者.

結論として、製品の品質を確保することは、Trusted Committersの重要な責任です。彼らは品質基準を設定し、例えばリードします。プルリクエストとヘルプに参加する 貢献者 質の基準を満たして下さい。また、ソフトウェアの長期的健康に責任を負います。

コミュニティを健康に保つ

Trusted Committersは技術指向とコミュニティ指向の責任の両方を持っていることを指摘した導入。コードとコードの健康だけに集中するのは十分ではありません。 Trusted Committersは、長期的に成功を収めるために、コミュニティがソフトウェアを健全に構築するよう努めるべきである。そのためには、製品の品質を確保し、健康なコミュニティを成長させるためのバランスをとらなければならない。

健康なコミュニティはどんな感じですか? 単に、健康なコミュニティで、 貢献者 周りに固執する傾向があります。, ソフトウェアを開発するほとんどの時間を費やすことができます。, 能力を向上することができます。. その結果、健全なコミュニティは継続的に成長します。

なぜ? 貢献者 コミュニティに参加し、周りを固執しますか? 彼らは目的やコミュニティの使命を購読するので、いくつか行います。 Trusted Committerは、この目的を明確に解釈し、促進するための仕事です。この重要性はしばしば認められていませんが、コミュニティとその製品をマーケティングすることは本当に不可欠です。

他の人が周りに固執するより明らかな理由は、彼らはTrusted Committersを含むコミュニティの他のメンバーと働くことを楽しむことです。繁栄するコミュニティは、メンバーが最大限の敬意をもって互いにやり取りし、コミュニケーションをとる1つです。寄付は、贈答品や寄付ではなく、贈答品や寄付金として扱われ、特に第一次寄付金は賞味されます。 Trusted Committer のジョブは、主に、想定されるソフトウェアの品質のレベルの例を設定するのと同様に、他の例を設定することです。必要に応じて、Trusted Committersは、コミュニティのために行動規範を作成し、制定しなければならないものです。コミュニティの健全性に反する行動が有害であるか、または有毒であるコミュニティメンバーがいる場合、Trusted Committerの責任はこれに対処することです。 Trusted Committersは、定期的に(個人または事実上)一緒に取得する人々のための機会を作成すべきであり、個人的に互いに知り合い、そして平和に彼らが発生したように対立を解決するために取得します。

また、InnerSourceコミュニティで働くと、新しいスキルを身につけ、個人的に成長する機会が得られる傾向があります。これは、Trusted Committerの役割が本当に重要である再びです。 Trusted Committersは、多くの場合、ジュニアデベロッパーのメンターになり、プルリクエスト中に時間を大幅に費やすだけでなく、改善のための領域を指摘するだけでなく、何かが改善され、それを行う方法を説明する。変化の背後にある理論や経験を提供し、それを実装するための最良の方法を提案します。これにより、Trusted Committersは、従来のソフトウェア開発プロジェクトにおいて、これまでのコミュニティにおける学習速度を向上させることができます。

我々は、Trusted Committersは、それほど良い理由がない場合を除き、伝達されたリリースの日付に達するために、プルリクエストのオンボーディングとメンタリングを優先すべきであると考えています。プルリクエスト時のグッドメンタリングは、より高いレベルの信頼とエンゲージメントにつながる 貢献者つまり、より多くの貢献につながる。「コミュニティのアップレベリング」で議論します。

最後に、InnerSourceコミュニティでは、オーバーヘッドや廃棄物を考慮した活動の代わりにソフトウェアの開発に焦点を合わせることができるため、特に大規模な企業がプロセスに重点を置いています。このコンテキストでTrusted Committerのジョブは、 貢献者 有益な貢献ガイドラインを伝え、制定することで、実際にプロジェクトに集中することができます。

これらのガイドラインの1つの重要な側面は、私たちが何を呼ぶかを説明することですシグナル伝達プルリクエスト:コメントはどのように見えるか? 私はそれが私が言うと意味するものお問い合わせまたは+1コメント /FYI 接頭辞を使うと /CC 接頭辞が異なる @mentioning はどのようになりますか? 一般的に言えば、Trusted Committersは、貢献プロセスがより多くの問題を作成しないことを確認する必要がありますが、代わりに問題を特定し、解決するコミュニティをサポートしています。最終的には、Trusted Committers は、そのコミュニティがプロセス関連の問題を見つけ、可能な限りコミュニティとして適応し、改善するために役立つはずです。

Trusted Committersでは、これらのすべての責任を果たすことができるため、コミュニティメンバーと定期的に通信し、地面に耳を傾けておくことが重要です。「コミュニティのニーズを提唱する」のセクションで詳しく説明します。

要約では、Trusted Committersは、彼らのために歓迎され、鑑賞的な環境を作成するために努力する必要があります 貢献者 それは、他のコミュニティメンバーから学ぶ機会を作成することによって、ソフトウェアの作成と個人的に成長することに集中することができます。

コミュニティメンバーのレベルアップ

InnerSourceコミュニティへの参加の継続があります。コミュニティに気付いていない人がいます。 ニューコーマーズ コミュニティとその製品に興味があるかもしれませんが、まだ使用していません。 消費者向け ソフトウェアを使用するが、コントリビューションをしていない可能性があります。それからそこにあります 貢献者 少なくとも1つの貢献を成し遂げ、そして最後に Trusted Committersソフトウェアとコミュニティの両方に責任を負っている人。 Trusted Committerとして、この継続に沿って個人を移動し、貢献をするための能力を上回る責任があります。この意味では、Trusted Committers は、コミュニティの力マルチプライヤーとして機能します。

Trusted Committersは、新製品や消費者の数を増やすために、製品やコミュニティを販売することが重要です。彼らはまた、消費者への貢献をするために機会を通信し、潜在的な利益をelicitにしようとする必要があります 貢献者 コミュニティと共に。よく働くものは 貢献者 社内の部署や役割にふさわしい何かに取り組むことができます。開発ツールと自動化は良い例です。

最後に、Trusted Committerの責任で識別し、サポートします。 貢献者 チャレンジングなタスクに取り組むことで成長する可能性と、完了に向けてそれらをメンター。 Trusted Committerとコントリビューターの両方で、これは私たちの意見では、Trusted Committerの最も貴重な責任であり、それは報酬です。 Trusted Committersは、メンタリングと人々が自分の能力をレベルアップしていると述べています。

前のセクションで述べたように、学習と個人的な成長は、人々がInnerSourceコミュニティに参加し、周りに固執する理由です。自分のレベルアップ 貢献者 Trusted Committersは、コミュニティの速度、出力、長寿を高めるために、最も強力なツールの一つである。また、従業員がInnerSourceコミュニティに参加できるように管理を説得する重要な引数の1つです。これにより、従業員が社内全体により価値のあるサービスを提供し、トップの才能を維持するのに役立ちます。

要約では、Trusted Committersは新しいを引き付ける必要があります 貢献者 そして貢献をするために能力を水平にして下さい。この活動は、コミュニティの能力を最大限に高め、より良いソフトウェアをより迅速に作成します。貢献する機会を共有し、貢献者を支援し、メンタリングすることで、成長できるようにします。

バリアを埋め込む

InnerSourceコミュニティへの貢献は、オープンソースコミュニティに数の理由があるよりも困難です。

潜在的なせん断の数 貢献者 InnerSourceのコミュニティで下がっています。
コントリビューターは、作業時間中に貢献したいと考えています。これは、より多くの時間を節約することを意味します。
InnerSourceでは、必ずしもコントリビューターの公式のパフォーマンス目標の一部ではないかもしれないので、InnerSourceで働いた時間は、それらの目標を達成することを妨げる可能性があります。

そのため、Trusted Committersが貢献とオンボーディングを作るプロセスを作ることが大切です。 貢献者 可能な限り摩擦なし。助けることができるものの数があります。

各コードリポジトリに良いREADME.mdを持っています。良いREADME.mdは、リポジトリにあるものと、それが使用できるものを説明します。また、ライセンスに関する情報を含む、リポジトリ内のソフトウェアの取得、ビルド、テスト、および使用方法についての詳細な手順を提供する必要があります。
期待されているものを概説する良いCONTRIBUTING.mdを持っている コントリビューターお問い合わせ次のような一般的な質問に答えるべきです。
- バグ報告や機能リクエストを提出するにはどうすればよいですか?
- 質問がある場合、誰に連絡すればいいですか?
- コードスタイル、ブランチング、またはコミットメッセージの規約は何ですか?
- 貢献のための「ドン」の定義は何ですか?
- 貢献を管理するプロセス手順は何ですか?
- 貢献が受け入れられた後、貢献されたコードを支持するという点で私の期待は?
- 行動規範とコミュニティの運営に関するガイドラインは何ですか?

社内ライセンスをソフトウェアに添付している場合、一部の企業は、法的企業間でソフトウェアを共有するための前提条件であり、そのライセンスのコピーを含みます。そして、laymanの用語における権利と義務の説明。

これらのドキュメンタリータスクに加えて、オープンソースソフトウェア開発と同様に、ソフトウェアの実行とテストは簡単かつ簡単です。 貢献者そのため、できるだけ少しの労力で貢献の実装と検証を開始することができます。

貢献のための2つの共通モデルがあります: 共有リポジトリ そして、 フォークと参加お問い合わせ Trusted Committerとして、両方の利点があり、あなたの潜在的なおよび流れの異なった必要性を収容するために両方のモデルを支えたいと思う 貢献者お問い合わせあなたのコントリビューターは、貢献プロセスやコミュニティ自体についての質問がよくあり、誰かがこれらの質問に答えるために利用できる必要があります。そのため、InnerSourceコミュニティでは、そのような質問に答えるために利用可能な1つ以上の連絡先を持つことが重要です。 Trusted Committersのグループからの誰かが、通常、連絡先の人、またはコミュニティメンバーが「通話中」であることを確認する必要があります。

潜在的な助けを借りることも重要です 貢献者 どのような貢献が必要かを決定します。これらは、文書の作成、アートワークの作成、またはイベントの整理など、コードのコントリビューションだけでなく、非コードのコントリビューションを行うことができます。これを行うための1つの一般的な方法は、コミュニティで使用される問題のトラッカーで「新しい作業」をタグ付けするか、オープンタスクのコントリビューターが使用できる市場を実装することです。

要約では、InnerSourceのコミュニティが企業環境において、貢献できる限り多くの人が貢献できる限り、できるだけ低く貢献できるという障壁を維持することが非常に重要です。つまり、コミュニティの役に立つ文書や人々へのアクセスを、質問に答え、コラボレーションを促すことができることを意味します。要約すると、Trusted Committersは、オンボーディングと貢献が肯定的な経験であることを確かめるべきです。

コミュニティのニーズに応える

InnerSource コミュニティは企業コンテキストに存在し、オープンソースコミュニティよりも多くの制約を受けています。時々、ビジネスユニットの利益はコミュニティのそれらとオッズにあります。 Trusted Committersは、プロジェクトの長期的視点をとります。彼らは健康なコミュニティが健康なコードの前提条件であることを理解しています。これは、InnerSourceのイニシアチブがApache Wayでモデル化された理由です。「コードに対するコミュニケーション」モットー一方、ビジネスユニットは、InnerSourceコミュニティによって生成された製品に自然に関心を持ちます。それらは、下線を助ける中長期的な結果に短いものを見ることを好む。

Trusted Committerが重要な役割を果たしている紛争のこの潜在的な領域にあります。 Trusted Committersは組織と信頼を築き、その信頼に基づいて構築し、コミュニティの利益と社内のソフトウェアの長期的健康を提唱する。これらは、技術、コミュニティ関連、管理に対するリスクの伝達に責任があります。同時に、Trusted Committersは、企業が有する自由度の範囲内で戦略的かつ作業する必要があります。

Trusted Committersはコミュニティと個人を確かめる必要がありますコントリビューター作品のパブリッククレジットを入手してください。パブリッククレジットは、その貢献者が自発的に貢献する通貨です。重要なコントリビューターを公に共有し、管理者が貢献を意識していることを確認するのは良い方法です。クレジットを贈ることは、個々のコントリビューターのためにイライラすることができ、コミュニティの健康に専念することができます。これは、まだInnerSourceの作業モデルに慣れていない企業や、InnerSourceコミュニティが開発しているソフトウェアが実行されているときに起こることができます 舞台裏で そして、管理者はコミュニティの貢献を単に認識していませんでした。 Trusted Committerは、公共クレジットの管理と提唱を行います。信用を贈る失敗は悪い信仰でほとんど行われず、修正するのは簡単です。

Trusted Committerのアドボカシーを求めるもう1つの一般的なケースは、いつコントリビューター貢献する時間や許可を与えていません。コミュニティがコントリビューターの部門の外で製品に取り組んでいるときに起こり、管理者の目標に関係しない。この場合、Trusted Committerは、代替決定のためのコントリビューターのマネージャーとロビーとの議論に従事する必要があります。

要約では、Trusted Committersが個人の利益のために提唱する必要がある多くの状況がありますコントリビューターコミュニティ全体のために。 Trusted Committersは、コミュニティが組織に提供できる価値がコミュニティの健康と長寿に依存し、最終的には両方の信頼できる関係に依存していることを理解しています。

Trusted Committer に対応

Trusted Committerの役割は、要求が厳しいが、役割を果たす。この学習パスがあなたに興味を持たれたら、実際にTrusted Committerになる方法が疑問に思うかもしれません。もしあなたが仕事の正しい人なら。

InnerSourceコミュニティは、同じ原則に従うオープンソースコミュニティは、その1つは慈悲的です。権威ある力は、才能、努力、業績に基づいて個人を育てています。つまり、Trusted Committer のロールに付属する電力と特権は獲得する必要があります。透明性、別のオープンソースの値も、才能、努力、成果をコミュニティ全体に表示させる重要な役割を果たしています。

Trusted Committerの正式なプロセスはコミュニティからコミュニティに異なり、InnerSourceの旅にいる場所に依存し、時間をかけて進化する可能性があります。草の根のコミュニティでは、創設者はしばしばTrusted Committerの役割を仮定します。コミュニティが成長するにつれて、またはより大きなコミュニティでは、Trusted Committersは通常、コミュニティからノミネートまたは投票されますコントリビューターお問い合わせしかし、Trusted Committer の役割は、時間の膨大な量とそれで成功するために献身を必要とするので、自発的に取られるべきです。

推薦で適用する条件は何ですかコントリビューター Trusted Committerの役割のために? Trusted Committerの役割を首尾よく満たすために取るものは? まず、Trusted Committersの潜在能力は、コミュニティでの作業中に深い技術的能力を発揮する必要があります。それに加えて、コミュニティの仲間と効果的にコミュニケーションする能力を証明し、理想的には製品所有者と管理と。

同じ静脈では、彼らは自分のスキルを使用し、意図的な時間のアップレベリングコントリビューターを費やす意欲と忍耐を示す必要があります。最後に、Trusted Committerの役割を果たすには、ストレスの多い社会的な状況に対処するために特定の感情的な成熟度が必要です。これらの基準を満たすコントリビューターは、私たちの意見でTrusted Committersの潜在的な可能性が高いです。

Trusted Committer の役割は、より少ない時間のコーディングを費やすことを意味しますので、いくつかのコントリビューターに魅力的であることがすべて表示されません。 Trusted Committer の役割にノミネートされると、いくつかの感情やコーディングスキルに関する負のフィードバックとして認識される可能性があります。しかし、反対は本当です。 Trusted Committerのロールにノミネートされていることは、通常、誰かがあなたの貴重な貢献を認識し、成長し、リードする可能性をあなたに見ていることを意味します。 Trusted Committer の役割は、コードベースの進化により多くの影響を及ぼし、最終的にはより完全な開発者になります。ソフトウェアがTrusted Committerの一部に新しいインサイトをもたらすものではなく、ソフトウェアがどのように機能するかを説明し、ソフトウェアを改善するための機会を特定するのに役立ちます。

Trusted Committersが1人か複数人かは、InnerSourceコミュニティが開発するソフトウェアの規模とリスクによって決まります。 Trusted Committerの役割は時間がかかりますが、誰もが喜んでいるか、そのタイプの約束を作ることができません。そのため、一部の企業では、Trusted Committer回転複数のTrusted CommittersがTrusted Committerロールのワークロードを共有し、Trusted Committersが存在しないシステム義務について技術志向の仕事に専念できます。 Trusted Committerを1つ以上持つと、誰かが会社を離れたり、ロールから何かをするために移動したりする際も簡単になります。その場合、既に他のTrusted Committersが存在することが重要であり、コミュニティの継続性を引き継ぎ、確保することができます。

要約では、Trusted Committer の役割は、技術と社会の両面から、コミュニティの利益のために、貴重な貢献をすることによって獲得しなければなりません。健康なコミュニティでは、Trusted Committersの仲間がいます。 Trusted Committer として、コードに時間がかかりませんが、パワーマルチプライヤーとして機能することで、最終的にコミュニティへの価値貢献を高め、独自の成長を加速することができます。

コンクルージョン

前の章では、Trusted Committersの責任について学びました。これらの責任の一部には、製品の品質を確保し、コミュニティを健康に保ち、貢献をするために障壁を減らし、コミュニティを強化し、組織内のニーズを支持することが含まれます。また、Trusted Committerになる方法や、その役割を果たすためにかかることについても話しました。 Trusted Committerとして働くことは要求されますが、最終的にあなたの会社のあなたの価値貢献を増幅します。

Trusted Committerになるための道に立ち向かうように感じました。また、InnerSourceイニシアチブの成功と、この役割が必要とするエンパワーメントのレベルのために、Trusted Committersの能力を持つことの重要性を理解してもらいました。

InnerSource学習パスで他の記事や動画を調べて、InnerSourceについてもっと知りたいです。そしてもちろん、私達は歓迎することを興奮しています InnerSource Commonsコミュニティ.

ソースがあなたとあるかもしれません。

ワークブック

コミットをプロジェクトにするために信頼される唯一のものです。
ソフトウェアとコミュニティを健全に発展させることは信頼されています。
Apache と GitHub で使われるロール名です。
それらはプロダクト所有者によって最も重要な特徴を託すために信頼されます。

なぜ1が間違っているのか:良いInnerSourceプロジェクトは、プロジェクトにコミットを提出する人々のコミュニティを持っています。信頼できるコミッタの信頼できる性質は、生のコーディング活動を超えて行きます。

なぜ2が正しいのか:信頼できるコミッタの役割は広く、微妙な人間の相互作用を伴います。彼らの技術的および対人的スキルのために選ばれた後、信頼できるコミッタは、貢献を解放し、コントリビューターの自信とスキルを構築し、コミュニティ全体で肯定的な相互作用を確保するための幅広いプラクティスを採用しています。そのような作品の仕様はありません。コミュニティやプロダクトオーナーが信頼関係を築きます。

なぜ3が間違っているのか:ApacheとGitHubは、信頼できるコミッタの責任の一部を包含するロールの異なる名前を持っていますが、フルセットではありません。 InnerSource に「信頼できるコミッタ」という役割名は意図的に一意です。

なぜ4が間違っているのか:プロダクトオーナーは、コミュニティのストーリーを実装するようなお気に入りを再生しません。

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

貢献がエンドユーザーのニーズを反映していることを確認する
独自の投稿と他のコントリビューターで高いコード品質を確保
コミュニティのコーディングと参加基準を守る
これらの基準を文書化

なぜ1が間違っているのか:コントリビューターは通常、コードが認識されたエンドユーザーのニーズを満たしていることを確認するためにプロジェクトに参加することを決定します。したがって、エンドユーザーのニーズを決定する責任を持つコントリビューター(またはマネージャー)であり、信頼できるコミッタは、いかなる貢献も良い理由で行われると仮定しています。

なぜ2が正しいのか:InnerSourceがコントリビューターとそのコミュニティにどのような利点をもたらすのか、最終的には最高品質のアプリケーションを生成して実行できるようにする必要があります。それはプロセスの究極の目標です。

なぜ3が正しいのか:コードは、スタイルと品質で基準に従わなければ、コントリビューターがバグとメンテナンスが困難になります。信頼できるコミッタは、そのことを保証します。

なぜ4が正しいのか:潜在的なコントリビューターは、貢献を提出しようとする前に明示的な基準を表示する権利を有します。ドキュメンテーションはキーであり、信頼できるコミッタは、ドキュメントを書くか、他の知識のある人々を雇うべきです。

リリースの日付を追跡し、必要に応じてこれらの日付の変更を推奨します
他のコントリビューターの時間を調整する
外部コントリビューターの採用
コントリビューターのプロモーションの推奨

なぜ 1 が正しいのか: 信頼できるコミッタは、コードがどの状態であるか、それがいかに堅牢であるか、そして彼らがユーザーの要件を満たしているかを知る。したがって、リリース日が不当である場合、他の誰よりも早く認識することができます。経営へのシフトの必要性を伝える責任です。

なぜ2が間違っているのか: ホストチーム外からのコントリビューターはボランティアで、プロジェクトを見るための独自のモチベーションを持っているので、プロジェクトに参加してください。外部のコントリビューターやマネージャーが自分の時間を費やす方法を伝えます。

なぜ3が正しいのか:InnerSourceは、ホストチームのドアに賭ける外部者によって頻繁に運転されるが、チームは助けることができる外部者に連絡し、見つけることからも利益を得ることができます。信頼できるコミッタは、そのチームが参加することで利益を得ることができる潜在的な貢献者に説明することができます。

なぜ4つが間違っているのか:他の人員のような昇進は、InnerSourceが置かれているとき、チームマネージャーによってまだ処理されます。 InnerSourceは、生産的なコミュニティを構築し、正式な報酬ではなく、そのメンバーを教育することです。信頼できるコミッタはコントリビューターがコントリビューターが示す価値と専門知識についてコントリビューターのマネージャーに知らせるかもしれませんが、信頼できるコミッタの役割外に報酬が残っていることを推奨しています。

独自の行動モデル
コード変更を承認するための管理構造の層
成功した貢献を記述する方法についての情報源
コントリビューターの提案を実装するエキスパートコーダ

なぜ1が正しいのか:信頼できるコミッタは、コーディングスキルとインタラクションの両方で、良いコミュニティメンバーのすべての特性を具現化する必要があります。そのため、コントリビューターは信頼できるコミッタの行動を具現化し、信頼できるコミッタになるよう願っています。

なぜ2が間違っているのか:InnerSourceは、適切に行なわれ、コードの変更と変更方法を決定するためのコントリビューターに責任を置きます。信頼されたコミッタは、コードがスタイルガイドラインに従っており、他に何かを破らないようにすることができます。しかし、信頼できるコミッタは管理の一部ではありません。 InnerSourceは、管理者が詳細なレベルでプロジェクトを指示する必要性を減らします。

なぜ3が正しいのか:コントリビューターは、そのコードや他のコントリビューションをホストチームのコードベースに取得したいと考えています。信頼できるコントリビューターは、それを行なった人であり、どのように説明することができます。

なぜ 4 が間違っているのか: 貢献者は InnerSource のコードについて責任を負います。信頼できるコミッタは、コントリビューターの仕事を結集するためにテンテーションに抵抗しなければなりません。信頼できるコミッタはアドバイスを提供できますが、コントリビューターはアイデアを実装します。

プルリクエストの見直し
コミュニティ規格の文書化
コミュニティの意思決定が高品質であることを保証する。
各貢献の一環としてコードを書く。

なぜ 1 が正しいのか: リクエストプルは、自分の個人的なサンドボックスをコントリビューターに与えます。コントリビューターは、ホストチームに結果を提供します。結果の貢献は、必要な品質に達するためにいくつかの反復を必要とし、信頼できるコミッタからのフィードバックを必要とするかもしれません。

なぜ2が正しいのか:ドキュメントは、すべてのコントリビューターが何をすべきかに同意するのに役立ちます。コントリビューターは、コントリビューターが貢献を開始する前に文書を読むのに役立ちます。信頼できるコミッタは、コントリビューターがコントリビューターの変更を要求する際にこの文書を指すのに役立ちます。

なぜ3が正しいのか:コミュニケーションと相互作用は、InnerSourceでより重要になります。貢献者は、コードが何をすべきか、どのように機能するかについて意見を持っているので、信頼できるコミッタは、コミュニティがすべてのニーズを満たす決定に到達するのに役立ちます。

なぜ 4 が間違っているのか: 健康プロジェクトは、独立して働く多くの人がいます。もしコントリビューターが自分のコードに対して完全な責任を負うことができれば、彼らはもっと学び、より多くの貢献をすることができます。可能な限り、信頼されるコミッタは、他のコントリビューターが責任を負うための貢献を扱いません。

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

参加の楽しさとやりがいを
コントリビューターに次の作業をする
コミュニティの困難または破壊的なメンバーに頼る
コントリビューターを作ることは、投稿を作成するためにちょうど良い感じます

なぜ 1 が正しいのか: 肯定的な雰囲気は、緊張または衰退するよりも多くの貢献をもたらします。実際には、緊張し、プロジェクトを廃止する傾向があります。そして、どんな場合でも、チームは、そのコントリビューターを持ち上げて、経験を肯定しています。信頼できるコミッタは、ネガティブに対する防衛の最初の行です。管理は、サポートのトップダウン文化を作成する必要があります。

なぜ2が間違っているのか:コントリビューターは、コードを変更するための独自のモチベーションを持っている必要があります。彼らは信頼できるコミッタの従業員ではありません。信頼できるコミッタは、プロジェクトが助けを必要とするか、タスクが良い学習経験になるので、コントリビューターが特定の変更リクエストやバグで動作することを示唆することができますが、コントリビューターは最終的な決定を下します。

なぜ3が正しいのか:人々は一時的に、またはその処分のために、他人を心理的に傷つけます。単一のネガティブなインタラクションは、コミュニティ全体に深刻なダメージを与えることができます。信頼できるコミッタは、肯定的な雰囲気を作成する方法を学び、実行中のネガティブな交流を中止し、行動する方法について他の人を明示的に導くために迅速に介入しなければなりません。

なぜ 4 が正しいのか: 一部のコントリビューターは、チームで必要な品質のコードを作成するスキルを欠いているか、時間などの他の要因によって制約されることがあります。しかし、InnerSourceは外部の貢献者のために繁栄しているので、誰もが試してみることを奨励すべきである。エンゲージメントは、コントリビューターがアドバイスを聞き、コントリビューターが貢献作品まで再試行することを動機としています。

豊かで楽しいコミュニティ
スキルを学び、改善するチャンス
よりオープンな計画プロセス
チームに必要な機能の迅速な実装

なぜ 1 が正しいのか: 誰も不快なグループにいることを望んでいません。良いコミュニティは、成功した貢献をすることができる人を引き付けます。

なぜ2が正しいのか: フォーマルトレーニングは、学習者が実際の生活の中でスキルを適用しようとするまで、限られた値を持っています。別のプロジェクトへの貢献は、経験から学ぶための優れた方法であり、追加の寸法をトレーニングに提供します。

なぜ3が正しいのか:組織計画の慣習的な観点では少なくとも、機能セットのノッティ質問と優先順位は、高レベルの管理会議から現れます。 InnerSource では、チームまたは個人が何かを行なう必要があることを決定し、それを実装することができます。人々は、彼らが望むので、重要なことに取り組んでいます, そして、優先順位は、オープンから出現します, 文書化された議論.

なぜ 4 が正しいのか: 必要な機能を実装するために別のチームを待っているのではなく、コントリビューターはコードを勉強し、自分のチームがそれを必要とするときに機能を書き上げることができます。これは分離で行われていませんが、ホストチームとのディスカッションとコラボレーションで。

コントリビューターの道を抜ける。
ラウド・ファーストタイムと優秀な貢献。
マイルストーンのオンボーディングとメンターシップを優先します。
修正をするときは、提案された変更の背後にある理論を説明してください。

なぜ 1 が間違っているのか: 信頼できるコミッタからステディのファシリテーションとメンタリングは、実際にコミュニティの健康を改善します。

なぜ2が正しいのか:透明性はInnerSourceのvirtuesの1つです。コミュニティと組織のマネージャーの両方がそれについて知っておくべきださったとき。

なぜ3が正しいのか:信頼できるコミッタは長期的に考えます。それぞれの機能を得るのは重要なことですが、採用とトレーニングは、より多くの貢献をもたらすために何年も費やされます。したがって、信頼できるコミッタは、いくつかの小さな貢献のためのコントリビューターを募集またはメンターする時間を置くことができます。おそらく個々の貢献よりも時間がかかります。メンターになり、コントリビューターがより多くのために戻って来る可能性を敬意的に高める扱われます。

なぜ4が正しいのか:レビューはコードベースの品質を維持する重要なタスクですが、信頼できるコミッタはタスク中に長期的に考えています。信頼できるコミッタは、コントリビューターがこの経験から学び、将来の貢献にレッスンを適用したいと望んでいます。

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

定期的にコミュニティの新しい目標を設定
外部の人たちがコミュニティとそれが提供することを知らせる
より大きなタスクを取るために貢献者を奨励
破壊的なコメントを無視するメンバーを奨励する

なぜ1が間違っているのか:目標は管理によって設定されます。信頼できるコミッタは、他の人が行う作業を容易にしますが、目標を設定しません。

なぜ2が正しいのか:InnerSourceの目標と利点を、特に前にその考えに露出されていないとき、多くのスタッフは理解できませんでした。信頼できるコミッタは、一般的にInnerSourceのevangelistsであり、特にチームのためにいます。 InnerSourceの取り組みを再生するために、特別な会議やランチタイムのセッションを開催するほど遠くに行きます。

なぜ3が正しいのか:仕事で成長するすべての人が欲しい。貢献者は通常小さじ始めますが、より大きな貢献が可能です。信頼されたコミッタは、彼らが行くように、より高い影響力のある仕事を取るためにそれらを奨励することができます, そして、彼らはその仕事で成功するようにそれらをメンター. エンドの結果は、より広い適用性、より高い品質、そして潜在的により多くの特徴のコード基盤です。

なぜ 4 が間違っているのか: 破壊的な人は非常にコミュニティに損害を与えることができます。敵対的であるコメント, 否定的, または単に気を散らすべきではありません. 信頼できるコミッタは、破壊的なコメントを無視したり、他の人にそうするように指示しません。彼は、コメントが不適切であるとコミュニティに通知し、その行動が再び起こらないように、破壊的な人と一緒に建設的な方法で行動する。

それは重要ではありません – コミュニティは、その作業を完了するために、それが必要とするものを行います。
コミュニティメンバーは、お互いに助け合い、より大きなコミュニティを可能にし始めることができます。
より成熟したメンバーで構成されたコミュニティは、より良いソフトウェアを生成します。
上位の個人は、そのロードマップを配信するホストチームの能力を増強することができます。

なぜ 1 が間違っているのか: コミュニティは自発的に形成しませんが、それの必要性はあります。信頼できるコミッタの役割の重要な部分は、コミュニティとメンバーが一緒に働くための社会的なつながりと励ましを供給しています。

なぜ2が正しいのか:スキルと自信を両立させるので、これらのスキルを他の人に提供することができます。コントリビューターは、コミュニティ標準を維持し、他のメンバーを教育することで、信頼できるコミッタのように行動することができます。

なぜ3が正しいのか:メンタリングの重要な目的の1つは、各コントリビューターが毎回より良いことを可能にし、プロジェクトでより大きなスコープを取ることです。

なぜ4が正しいのか:コントリビューターがより洗練されたものになると、生産性が増加し、その貢献がより重要になります。さらに、プロジェクトの全体的な健康を改善する目標を設定するのに役立ちます。

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

日々の仕事で忙しすぎて貢献する
従業員のレビュー中のInnerSourceの貢献に対する考慮の欠如
コントリビューター独自の環境でソフトウェアの構築とテスト
他のチームによるコントリビューターのコードの使用

なぜ 1 が正しいのか: 開発者は、一般的に、管理者がそれらを割り当てるものを行なったフルプレートを持っています。 InnerSourceの約束は、プロジェクトが別のチームのプロジェクトに必要な機能を追加することで、自分のチームの生産性と、あなたが貢献しているチームのコードを向上させることができます。 InnerSourceのオープンなコミュニケーションは、両方のチームに時間をかけて支払います。コントリビューターは、別のチームのコードベースでの作業がコントリビューターのチームを助け、同社はより速く、より効率的に目標を達成するという管理を説得する必要があるかもしれません。

なぜ2が正しいのか:会社が認識され、明示的に報酬を受けるべき利益をもたらすすべての努力。これは従業員が重要な新しいタスクを取ることを奨励する。 InnerSourceの先頭では、会社のタスクの基本的な理解に組み込まれていないため、管理者は、従業員が他のプロジェクトに取り組む貢献を認識しません。 InnerSourceが理解し、管理が認めるまで、従業員は参加を困難と判断します。

なぜ3が正しいのか:各チームが異なるツールやリポジトリを使用するかもしれません。チーム間で共有されるリポジトリは、共有されたコードで作業するのがはるかに簡単です。リリースのビルド、バグレポート、リクエストの変更、テストなどの関連プロセスは、他のチームから人々が慣れ親しんでいる方法で作業できるように設計する必要があります。コミュニティのローカルの習慣を説明するCONTRIBUTING.mdファイルのような有用な文書を追加し、コントリビューターの独自の環境でソフトウェアをセットアップする方法を記述することで、他のチームから人々がより速く感じ、そして大いに推薦されるように助けることができる。

なぜ4が間違っているのか:InnerSourceの大きな利点の1つは、他のチームによって設計され、コードされた機能を使用するすべてのチームの能力です。企業は、関連するすべてのユーザーにコードへのアクセスを提供することで、各コードの貢献の値を最大化するために、主にInnerSourceを採用しています。 .

READMEファイル
コントリビュートファイル
ステップバイステップファッションの貢献プロセスを説明する
潜在的な貢献者からの質問に答える

なぜ 1 と 2 が正しいのか。これらのファイルの両方が参加を開始する前にコントリビューターによって読み込まれるべきであり、両方ともチームのガイドラインに良い場所です。

なぜ3が正しいのか:ステップバイステップの手順、定義できるところ、抽象をコンクリートに変えるのを助けます。一般的な原則を適用するよりも明確な手順に従う方が簡単です。

なぜ4が正しいのか:信頼できるコミッタはコントリビューターに個人的な指導を提供します。他のコントリビューターがそれらを読んで希望的に学ぶことができるどこかに書かれた形でそのような相互作用を保存するのに便利です。

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

コントリビューターの作業がチーム自身の目標に直接関係していることを確認してください
貢献者のための認識を得る
潜在的なコントリビューターとその管理者が貢献するメリットを発揮する
より多くの責任を取るために貢献者を奨励

なぜ1が間違っているのか:コントリビューターは、コントリビューターのチームのニーズを満たすために、別のチームのコードで動作します。貢献は、当然のことながら、信頼できるコミッタのチームの目標に対する直接的な矛盾ではないべきではありません。しかし、関連性は、信頼できるコミッタのチームではなく、コントリビューターのチームに適用されます。

なぜ2が正しいのか:認識は個人的に満足しており、ボーナスやプロモーションなどの正式な報酬へのステップです。バージョン管理やバグ報告データベースなどのツールには、貢献の歴史的記録が含まれていますが、信頼できるコミッタは、プロジェクトの通信チャネルにおける重要な貢献を認識する必要があります。

なぜ3と4が正しいのか:コントリビューターは、プロジェクトがそれらに利益をもたらし、組織全体で認められていると見れば、時間と労力を投資する可能性が高い。

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

貢献の狭い範囲での作業
より多くの時間のコーディングを過ごして下さい
プロジェクトのストレスの多い状況を処理する
コミュニティがあなたの行動を台無しにすることを可能にします

なぜ 1 が間違っているのか: 信頼できるコミッタは、スコープを狭くしないように、作業の範囲を拡大する傾向があります。信頼できるコミッタとして、さまざまなチームからさまざまな人々と仕事をします。

なぜ 2 が間違っているのか: どこから来るべきか。信頼できるコミッタは、他のコントリビューターのコードをチェックし、コントリビューターをメンターし、計画を実行するために、いくつかのコーディング時間を与える必要があります。しかし、信頼できるコミッタは、自分のスキルを維持し、チームのコードベースの知識を維持するため、いくつかのコーディングを行う必要があります。一部の人々は、限られた期間にわたって信頼できるコミッタロールを採用し、フルタイムコーディングに戻ります。

なぜ3が正しいのか:信頼できるコミッタはコミュニティの健康のために個人的な責任をとり、すべてのコミュニティはストレスを経験します。そのようなストレスは、個人的な議論、優先順位の衝突、時間とリソースの制約、または他の多くのソースから来ることができます。信頼できるコミッタは、これらの問題に落ち着いて対処しなければなりません。

なぜ4が正しいのか:信頼できるコミッタは単なる技術的な専門家ではなく、行動のためのロールモデルです。そのため、プロジェクトの参加者からフィードバックを受け取るため、行動を透明にする必要があります。

信頼できるコミュニケーターの価値を認識する
少数の信頼できるコミッタに各チームを制限する
信頼できるコミッタを作るのではなく、コーディングタスクで最高のプログラマを維持
経営陣が定める期限をすべて満たす

なぜ 1 が正しいのか: 多くの技術的なプロジェクトは、技術的なスキルに大きな価値を置きます。それは確かに必要です。しかし、コミュニケーション、問題解決、トレーニングなどの「ソフト」のスキルを失望的に呼び出すことを強調します。 InnerSourceはコミュニティであり、コミュニティはこれらの追加のスキルを必要としています。信頼できるコミッタは、貢献を誘発するために必要なスキルのフルレンジのために選ばれ、認識されます。

なぜ2が間違っているのか:多くの人が役割を共有したときにInnerSourceの繁栄。健康なチームは信頼できるコミッタになる多くの修飾された開発者を励ます。また、信頼できるコミッタロールから、他のチームメンバーと共有することもできます。全員のスキルアップ

なぜ 3 が間違っているのか: 信頼できるコミッタは、他のコントリビューターコードをベットし、コントリビューターをメンターするので、管理者は、最高の開発者が、少なくとも時間の一部で信頼できるコミッタになるようにしたい。

なぜ4が間違っているのか:InnerSourceは、期限ではなく、品質コードとコミュニティビルディングに焦点を当てています。 InnerSourceは、チームが重要なタスクの他のチームから一時的に人々をリクルートすることができるので、チームがその期限を満たすのに役立ちます。しかし、他の時、信頼できるコミッタは品質を確保するために期限に延長を要求します。

すでにプロジェクトへの貢献を成功させました。
プロジェクトのためのホストチームです。
コミュニティの他の人に質問を積極的に助けます。
プロジェクトロードマップと管理に関する会話に参加します。

なぜ1が正しいのか:信頼できるコミッタの主な責任の1つは、他の人がプロジェクトにうまく貢献できるようにすることです。信頼できるコミッタは、他の人が同じことをするのを助けるために修飾されるように自分自身をやることの歴史を持っている必要があります。

なぜ2が間違っているのか:これは要件として引用されなかった。ホストチームは、プロジェクトが初めてInnerSourceコミュニティに提供されている場合、信頼できるコミッタを提供するでしょうが、プロジェクトについて強く気をつけている他のチームから信頼できるコミッタをリクルートすることができます。信頼できるコミッタを採用するチームに関係なく、管理者と参加する時間とリソースを整理し、プロジェクト代表者としてより大きなコミュニティと組織全体に行動する必要があります。

なぜ3が正しいのか:信頼できるコミッタの責任の大部分は、貢献者に社会的支持を伴います。優れた候補者は、信頼できるコミッタとして公式の指定の前に、すでにこの社会的行動の一部を展示しています。

なぜ4が正しいのか:信頼できるコミッタに置かれる信頼は純粋に技術的な考察を越えて伸びます。信頼できるコミッタは、製品所有者と管理と通信します。これらの領域に興味は、信頼できるコミッタである可能性がある人を示しています。

プロジェクトのさらなる責任を取ると、会社の拡張されたリーダーシップのために準備します。
他の人を教える立場にいると、あなたはプロジェクトを理解し、自分自身をコードするのに役立ちます。
Trusted Committerの責任を仮定した時点での金銭補償の増加を期待できます。
プロジェクトへの影響は、自分が書いた時間よりも多くの貢献をせん断し、導くのに役立つため拡大します。

なぜ1が正しいのか:信頼できるコミッタとして行動することは、後でフルタイムのリーダーシップの役割を追求することを決めたならば、必要な同じリーダーシップスキルを構築するための大きなストレッチの役割です。

なぜ2が正しいのか:すべての領域で、他の人に何かを教えることは、あなたが自分自身をよく知っている必要があります。これは信頼できるコミッタであることで本当を保持します。他の人に教えることは、あなたが作業しているプロジェクトとコードの上にマスタリーを追加与えます。

なぜ 3 が間違っているのか: 即時の収益増加は、信頼できるコミッタの役割に直接縛られることは一般的ではありません。しかし、信頼されるコミッタになるために必要なスキルと、企業が発展するスキルは、企業にとって非常に価値があります。そのため、信頼できるコミッタになるのは、より価値のあるリーダーを作るスキルの構築に良いキャリアになる傾向にあります。

なぜ 4 が正しいのか: 信頼できるコミッタであることは、プロジェクト内のインパクトに及ぼす力マルチプライヤーです。メンターとレベルコントリビューターとして、各コントリビューターがマークを運び、それらに影響を及ぼします。この効果は、ヘッドダウンのコーディングだけでできるよりも、プロジェクトに何度も高速化して追加します。

会社の経営は、プロジェクトをロールに導いたい人を動かします。
コミュニティまたはそのリーダーシップは、新しい信頼できるコミッタを指しています。
ボランティア募集
プロジェクトファウンダーはロールを想定しています。

なぜ 1 が間違っているのか: meritocracy の原則は、信頼されたコミッタシップが付与されていないことを教えます。また、Trusted Committer がロールに記述されるのではなく、サービスへの招待状を自発的に受け入れるべきである場合です。

なぜ2が正しいのか:コミュニティは、そのメンバーがTrusted Committerとして役立つ興味と適性を実証したかを評価するための最良の位置にある。

なぜ3が間違っているのか: 興味だけで信頼できるコミッタシップの唯一の前提条件ではありません。マリトクラシーの原則は、コミュニティで実証された肯定的な活動を通じて信頼されたコミッタシップを教えています。

なぜ 4 が正しいのか: コミュニティと歴史のないアウトセットでは、プロジェクトファウンダーは、初期コミュニティを構築するために Trusted Committer の役割を想定しています。このプロジェクトを立ち上げるだけでなく、コミュニティメンバーとやりとりする新しい潜在的なTrusted Committersを構築します。