# トラステッドコミッター ### Title トラステッドコミッター ### Patlet 多くのInnerSourceプロジェクトは、コントリビューターからフィードバック、機能、バグフィックスを一貫して受け取る状況にあります。このような状況で、プロジェクトのメンテナーは、単一のコントリビューションを越えてコントリビューターの仕事を認識し、報酬を与える方法を模索します。 ### 問題 * プロジェクトメンテナーは、プロジェクトをサポートする力をスケールする方法を探しています * プロジェクトメンテナーは、プロジェクトが提供する価値を高める方法を見つけたいと思っています * プロジェクトメンテナーは、頻繁に貢献している人に目に見える形で報い、彼らの価値貢献を拡大させる力を与えたいと考えています * 組織内のチーム間の貢献を認識するための仕組みや言語がない ### 状況 * あなたはチーム横断的なライブラリ、サービス、または共有リソースのメンテナーです * あなたは定期的にコントリビューションを受けます * あなたは定期的に機能のリクエストを受けます * あなたは定期的にバグフィックスのリクエストを受けます * InnerSource プロジェクトを通じて専門知識を身につけようとする意欲的なコントリビューターがいます ### 組織に働く力学 * プロジェクトのライフサイクルの中で、変化するビジネスの優先順位に対応するため、メンテナーのフォーカスがずれることがあります * コントリビューターは、自分たちのコントリビューションが目に見える形で認められ、その価値が示されることを求めています * 小規模なチームにとって、それなりに複雑なプロジェクトを維持することは大きな負担になります * プロジェクトの機能を大規模に開発することは、小規模なチームにとって負担になります ### ソリューション #### プロジェクトの トラステッドコミッターの役割を定義する トラステッドコミッターが何を担当するかは、各プロジェクトとそのメンテナー次第です。トラステッドコミッターの役割の範囲について、プロジェクト内で文書化することを忘れないようにしましょう。明確な文書化によって、新しいコミュニティのメンバーに対する期待値を設定し、将来の候補者のために役割を確立します。 トラステッドコミッターの候補者を特定するためのガイドラインは以下のとおりです。 * コミュニティチャネル (Slack、JIRA issue triaging など) に積極的に参加している人はトラステッドコミッターになり、コミュニティサポートにおける役割を正式に決定することができます * コード、ドキュメント、その他のリポジトリの変更を頻繁に提供する人をプルリクエストに参加させることから始めましょう。この人が積極的にプルリクエストに参加している場合、プロジェクトにおけるさらなるコラボレーションの機会についてアプローチすることを検討してください #### 信頼できるコミッターを正式に認定する 最初のステップは、トラステッドコミッターになることについて候補者にアプローチすることです。メンテナーは候補者にトラステッドコミッターの役割について理解してもらう必要があります。候補者がトラステッドコミッターの役割を引き受けることを期待してはいけません。各候補者は、自分がその責任を果たすために必要な余剰リソースを持っているかどうかを判断する必要があります。 候補者がその役割を引き受けた場合、"ユーザー" からトラステッドコミッターへの移行を公の場でアナウンスするかはプロジェクトのメンテナー次第です。また、プロジェクトの README にある \[トラステッドコミッター] セクションに名前を追加することもお勧めします。 例としては以下のようなものがあります。 ```markdown # プロジェクト名 ... Readme ... ## プロジェクトリーダー ### メンテナー - チームメンバー ###トラステッドコミッター - 新しいトラステッドコミッター [トラステッドコミッター]: https://example.com/link/to/your/trusted/committer/documentation.md ``` #### トラステッドコミッターとの関係を維持する トラステッドコミッターを正式に決めたら、 その人たちをプロジェクトの輪の中に入れておくとよいでしょう。プロジェクトの輪を保つには、プロジェクトチャンネルに招待するといった簡単なものから、企画セッションに参加させるといったものまであります。参加する機会を増やすことで、トラステッドコミッターが望めばメンテナーになる道も開けます。 トラステッドコミッターに情報を提供するだけでなく、定期的にチェックインをするのもよいでしょう。最初は一週間に一度、そして徐々に数週間に一度のペースをおすすめします。 これらのチェックインの目的は、トラステッドコミッターが新しい役割において自分が周囲からのサポートを受けていると感じられるようにすることです。上司との1:1ミーティングと同じように、何か問題があれば、耳を傾け、共感して、トラステッドコミッターが成功するのを妨げているものを理解しようと努めましょう。プロジェクトを成功に導くための[トラステッドコミッターのチームへの継続的な貢献に感謝し](/ja/praise-participants.md)、新しいチェックインの日付を設定しましょう。 #### トラステッドコミッターの退任 トラステッドコミッターが以下のような場合、トラステッドコミッターを退任させなければならないことがあります。 * 参加する意思がなくなった * 責任を果たせなくなった * 会社の従業員ではなくなった プロジェクトのリソースへのアクセス権を解除するプロセスについては、プロジェクトの **トラステッドコミッター** セクションにあるエントリを"過去のコントリビューター"のリストに移行させるなど、両者で事前に合意しておく必要があります。 アクセス権を解除する際には、[トラステッドコミッターの参加に対して公の場で感謝の意を表する](/ja/praise-participants.md)ことで、移行と継続性をコミュニティ内で明確に周知することができます。 ### 結果の状況 #### コントリビューターに対して プロジェクトのトラステッドコミッターとなることは、コミュニティプロジェクトにコントリビュートするイニシアチブを示すことになります。このような貢献は、上司との年次レビューでの評価に組み込むなどの利用が可能です #### メンテナーに対して プロジェクトが成熟するにつれて、 メンテナーはプロジェクトの重要な側面についてあまりよく知らなくなることがあります。トラステッドコミッターはこのようなギャップを埋め、プロジェクトのあらゆる側面をより良くすることができます。 トラステッドコミッターを健全に組織に配置することは、メンテナンス担当者が進むにあたり、職務遂行のための責任がある管理計画の所在を保証することになります。 ### 事例 この事例は、試行錯誤のすえ以下の企業で成功しています。 * Nike * PayPal ### ステータス * Structured * Nike の社内で公開、2018年6月にプルリクエストで起草 ### 著者 * [Fernando Freire](https://github.com/dogonthehorizon) ### 謝辞 * [Russell Rutledge](https://github.com/rrrutledge) * [Loren Sanz](https://github.com/mrsanz) * [Noah Cawley](https://github.com/utanapishtim) * [Jeremy Hicks](https://github.com/greatestusername) * [Doron Katz](https://github.com/doronkatz) ### 翻訳の履歴 * **2022-05-30** - 翻訳 [Yuki Hattori](https://github.com/yuhattor) * **2023-06-18** - 最終更新 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://patterns.innersourcecommons.org/ja/trusted-committer.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.