自分のチーム以外からのコントリビューションを受け入れる場合、チームが書いていないコードの責任を持つことに抵抗があることは自然なことでしょう。 「30日の保証期間」プラクティスを利用すると、コードにコントリビュートしたチームはコードを受け取ったチームに対してバグフィックスを提供することを承諾することになります。 そうすることで、両チーム間の信頼度が高まり、コントリビューションが受け入れられる可能性が高くなります。 あるチームが、組織全体で使用されるコンポーネントを開発しています。 このチームはコントリビューション(機能への要求を含む) を受け入れることに抵抗したり、完全に拒否したりします。 この振る舞いは進行を妨げたり、エスカレーションによる頻繁な混乱につながります。

あなたが読んでいるインナーソースパターンは初期のリリースフェイズです。リンクが壊れていたりスペルミスやエラーがある可能性があります。 できる限りベストな本を作成するために是非修正にご協力ください。本へのコントリビューション方法についてはこちらをご参照ください。 インナーソースパターンブックへようこそ。 この本では、インナーソースのベストプラクティスを理解しやすい特定のフォーマットで体系化し、評価し、あなたの環境で適用しやすくまとめています。このフォーマットを私たちは "パターン" と読んでいます。 インナーソース は、長年にわたってこれらのパターンを収集し、この本で最も成熟したパターンを公開しています。また、コミュニティのメンバーが、少なくとも一つの事例をもって、それぞれのパターンをレビューしています。 このイントロダクションでは、インナーソースとは何か、パターンとは何か、そしてあなたの組

Qiitaで周りを見るとほんとすごい人ばっかりですよね。 しかし、凡百のエンジニアもいます。 私はとくに大手につとめているわけでもなく、さりとてイケイケスタートアップでもなく、AtCoderで色をもっているわけでもありません（※あったらいろいろはかどると思います）。 フツーなりに、「エンジニアになってみてよかった」、と思ってはいたりするので、ぬるいエンジニアの生態をご紹介します。 ロールモデルにはならないけどサンプルにはなるんじゃないかなー。 自己紹介 新卒から5年～くらい、北海道の中小企業につとめています。 北の大地にいると、「S県」などであらわされる匿名性がちょっとうらやましいです。 春からシーランド公爵（になる予定）！ どうしてエンジニアを選んだのか 大学は地方国公立で、文系です。 完全に未経験からこの業界に入りました。 しいて言えばパソコンで遊ぶのが好きだったので、基本的な操作はで