LogoLogo
Contribute to InnerSource PatternsJoin the community
🇯🇵 日本語
🇯🇵 日本語
  • イントロダクション
  • 目次
  • パターンの一覧
  • この本へのコントリビューション
  • パターン
    • 30日の保証期間
    • RFCを用いたチーム横断的な意思決定の透明化
    • イシュートラッカーの使い方を多様化する
    • インナーソースポータル
    • インナーソースライセンス
    • ギグマーケットプレイス
    • クロスチームプロジェクト評価
    • コアチーム
    • コミュニケーションツーリング
    • コントラクトコントリビューター
    • コントリビューションの功労を称える
    • サービス対ライブラリ
    • スタンダード・ベース・ドキュメンテーション
    • トラステッドコミッター
    • リポジトリアクティビティスコア
    • レビュー委員会
    • 共通要件
    • 基本原則ガイダンスの文書化
    • 実験として始める
    • 成熟度モデル
    • 持続可能な成長のためのエクステンション
    • 正式なコミュニティリーダー
  • 付録
    • パターンテンプレート
    • その他
      • README テンプレート
      • CONTRIBUTING テンプレート
  • リソース
    • GitHub
    • InnerSource Commons
GitBook提供
このページ内
  • Title
  • Patlet
  • 問題
  • 状況
  • 組織に働く力学
  • 解決策
  • 結果の状況
  • 事例
  • 著者
  • 謝辞 (Acknowledgment)
  • ステータス
  • 同種の例
  • 翻訳の履歴

役に立ちましたか?

GitHubで編集
PDFとしてエクスポート
  1. パターン

30日の保証期間

Title

30日の保証期間

Patlet

自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。

問題

あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。

状況

  • コントリビューションを受け入れる側のチームによって生み出されたコンポーネントを、コントリビュートした側のチームが使えるかどうか、それは他のチームが受け入れてくれるかに依存してしまいます。

  • 受け入れる側のチームが、コントリビュートされたコンポーネントや機能に対するリソース・知識・許可を持っていないか、もしくは(それに加えて) それらのコンポーネントや機能を自分自身で書く意欲がない場合があります。

組織に働く力学

  • 過去に不正行為があったため、コントリビューションに対する不信感があります。例として、チームは中途半端にしたコントリビューションを提供し、その後に本番で使えるように修正するよう要求してきました。

  • チーム外からコードを提供された場合、他のチームはチームの期待に沿うようなコードの書き方を知らないのではないかという疑念を持つことは自然なことです。

  • 各チームは、自分のリーダーが目標を達成するための活動を第一に考えます。この忠誠心の方向性が、この問題の解決を複雑にすることがあります。

  • 自分で書いていないコードに責任を持つことに抵抗があることは自然なことです。

  • コントリビュートされたものは、コードベースに受け入れる前に大きく書き換える必要があります。

  • コントリビュートした後、バグフィックスなどのサポートが受けられなくなる恐れがあります。

  • コントリビュートされたコードが高いメンテナンスコストにつながることを恐れているが、それをどのように管理すればよいのかわかりません。

  • 受け入れ側のチームは、他の人にコードを提供する方法を教えることで、自分たちのシステムの技術的負債が露呈し、それによって損害が発生することを恐れています。

  • 受け手のチームは、いくら指導しても納得のいくコードが得られるとは思っていないかもしれません。

  • どちらのチームも、リスクを測定したり、コントリビューションの中でリスクが軽減されていることを証明することに自信を持てないかもしれません。例えば、システム自体がややもろいなどの理由が挙げられます。(テストが完全でなかったり全ての問題を拾いきれてないかもしれません。)

解決策

コントリビュートしたコードが本番稼動した時点から 30日の保証期間 を設けることで、受け入れた側とコントリビュートした側の双方の不安に対処します。この保証期間中、コントリビュートしたチームは受け入れたチームにバグフィックスを提供することに同意します。

なお、保証期間は45日、60日、100日のいずれでもかまいません。この期間は、プロジェクトの制約、プロジェクトのソフトウェアライフサイクル、顧客との約束事項、その他の要因に基づいて変化される可能性があります。

結果の状況

  • 受け入れ側のチームがコントリビューションを受け入れ、初期適応/修正の作業負担を分担することができます

  • 透明性と公平性が高まります

  • エスカレーションが重荷になりすぎないようになります

事例

  • これは PayPal で試みられ、成功したことが証明されています。

  • GitHub は社内でこのパターンを使っており、6週間という修正された保証タイムラインを使っています。

  • Microsoft はこのパターンを原則として推奨しています。チームは自分たちのニーズと自信にマッチするよう具体的な時間目標を設定します。

著者

  • Cedric Williams

謝辞 (Acknowledgment)

  • Dirk-Willem van Gulik

  • Padma Sudarsan

  • Klaas-Jan Stol

  • Georg Grütter

ステータス

  • Structured

  • Drafted at the 2017 Spring InnerSource Summit; reviewed 18 July 2017.

同種の例

翻訳の履歴

  • 2023-06-18 - 最終更新

前へこの本へのコントリビューション次へRFCを用いたチーム横断的な意思決定の透明化

最終更新 1 年前

役に立ちましたか?

さらに、受け入れ側のチームとコントリビュートする側のチームの期待値を明記した、明確なを提供することも役に立ちます。

複数の、功績至上主義的に任命されたが責任を持つことで、依存するチームの協力をコミュニティ化することで保証する。

2022-05-26 - 翻訳

コントリビューションのガイドライン
トラステッドコミッター
Yuki Hattori
30 Day Warranty