より広いコミュニティからのコントリビューションを育てる
より広いコミュニティからのコントリビューションが持つ意義
GitLab がより広いコミュニティからのコントリビューションを育む環境を整えることへの取り組みは、その成功と魅力において重要な要因となっています。より広いコミュニティからのコントリビューションは、自然にサイロを防ぎ、開発速度を向上させ、エンジニアがより高い保守性の基準を維持するよう促します。
私たちの Editor グループは、GitLab プロダクトの自分たちの担当領域において、より広いコミュニティからのコントリビューションを育てることで多くの恩恵を得られます。
Editor グループにおけるより広いコミュニティからのコントリビューションの現状
この文章を執筆した時点では、GitLab のコミュニティコントリビューション全体のうち、Editor グループのコードベースを対象としたものは 2% 未満です
（Editor グループへのコントリビューションを見る、全コントリビューションを見る）。
devops::create ステージ全体の中でも、Editor グループは GitLab コミュニティコントリビューション全体の約 15% を占めています（create ステージを見る）。
Editor グループはコミュニティコントリビューション全体の中で非常に小さなシェアしか持っていないようです。これはより根本的な問題の症状であり、または見逃している機会かもしれません。
問題の分析
注意: この分析では、GitLab 全体としてはより広いコミュニティからのコントリビューションが健全な基盤を持っていると仮定しています。ここでは Editor グループ固有の問題のみを考慮します。
以下は、この問題を考えられる原因要因とその関係性、そして考えられる解決策に分解した相互依存グラフです。
提案: グラフを読む際は、複数の矢印が指し示しているノードに注目してください。これらは小さな変化が大きな波及効果をもたらせる領域です。
グラフの説明
- Issue の可視性の欠如: Issue は私たちの組織にとって主要な作業項目です。Editor グループの Issue がより広いコミュニティに可視化されていなければ、当然コミュニティコントリビューションは少なくなります。
- コントリビューターのモチベーションの欠如: Editor グループの Issue を見つけたコミュニティメンバーが、取り組む意欲を持てない場合があります。これは関連する機能自体（例：ニッチであり広い採用がない）が原因の場合もあれば、単に Issue のトリアージや記述の仕方（例：重みがない、前提知識を仮定している）が原因の場合もあります。
- コントリビューションできる能力の欠如: コミュニティメンバーが Issue に取り組む意欲があっても、進展できない場合があります。これは目的が不明確な Issue、実装ステップが不明確な Issue、および/またはコードベースが初心者には理解・修正しにくい場合に起因します。
- Issue が初心者向けでない: この問題は、Issue が初心者には簡単に理解したり取り組んだりできない形で書かれている状況を指します。これは Issue の説明に不明確な要件が含まれていたり、前提知識を仮定していたり、Issue の重みが特定の人物向けに設定されている場合に起こりえます。
- コードが初心者向けでない: コードベースが初心者には簡単に理解・修正できない場合、コントリビューションのコストが高いため、より広いコミュニティからのコントリビューションは自然に阻害されます。
- 機能の採用率の欠如: ある機能のユーザー採用率が低い場合、コミュニティコントリビューションに対する見返りの期待値が他の Issue に比べて相対的に小さくなります。
サイロの症状
サイロの中で進化するコードベースは、長期的には保守が困難になります。
サイロとは、知識を生み出すが、その知識を内部に留めておくシステムです。これは組織にとって単一障害点を生み出します。また、システムが外部のフィードバックやシステム外部の知識を受け取れないため、品質が時間とともに低下する恐れがあります。
より広いコミュニティから健全なコントリビューションが流れ込んでいると、コードベースはサイロ化から自然に守られます。一方、より広いコミュニティからのコントリビューションが少ないことは、コードベースが他のサイロ的な振る舞い（最も顕著なのは保守性の低下）を示すようになる指標となりえます。これによってさらに外部からの関与が妨げられ、負のフィードバックループが生まれます。
解決策
以下のセクションでは、上記の問題に対処するための解決策を説明します。これらの解決策は互いに排他的ではなく、必要に応じて優先順位をつけて採用するべきです。
より広いコミュニティを主要なオーディエンスとして扱う
より広いコミュニティからのコントリビューションを育てるために最も大きな効果があるのは、Issue を書く際に、より広いコミュニティを主要なオーディエンスとして扱うことです。これは Issue に取り組もうとするコントリビューターのモチベーションを直接向上させます。このように書かれた Issue は:
- 明確で簡潔です（例：最も関連性の高い情報が最初に置かれ、議論のコメントに埋もれていない）
- 前提知識を仮定しません（例：リンクや詳細なしに新しいパターンを名前だけで参照するコードのリファクタリング）
- 重みが付けられており、その重みは時間の見積もりや特定のアサイン対象者から切り離されています（関連するガイドラインを参照）。Issue が特定の個人向けに重みを付けられている場合、コミュニティの参加が阻害され、サイロが強化されます。
より広いコミュニティを主要なオーディエンスとすることで、Issue を書く人は、その Issue を担当する人がどこから始めればよいかさえ知らないかもしれないということを考慮せざるを得なくなります。これは関連するコード行や問題を解決できる可能性のあるアクションを調査し、実装ガイドを残す素晴らしい動機となります。
実装ガイドに含まれるものは何ですか？
このガイドは非常に簡潔なものでかまいません。単に、関連するコード行と問題を解決できる可能性のあるアクションの非公式な調査結果を含みます。また、MR を反復的なチャンクに分解するためのステップを含めることもできます。
最終的には、実装ガイドは実装者を導くものですが、裁量と創造性のための十分な柔軟性と余地を残すものです。
著者が実装ガイドを残せない場合はどうすればよいですか？
Issue の著者が自分で調査して実装ガイドを残す必要はありません。代わりに、著者はドメイン知識を持つ人に協力を求めるべきです。
@<NAME_HERE>, could you please help me investigate and leave a brief implementation guide for this issue? Thanks!
これはかなりの作業量に見えます。
ドメイン知識を持つ人が Issue の実装ガイドを実行可能かつ迅速に作成できない場合、要件のギャップや固有の課題がある可能性があります。これらの固有の課題は実装ガイドに記録され、コントリビューターが全体像を把握できるようにするべきです。
実装ガイドを残す努力（特に調査の努力）は、計画、重みの見積もり、実装、レビュー、テストまで、すべてのステークホルダーに Issue の真の性質を伝える上で大きな意味を持ちます。
Hackathon でのプレゼンスを改善する
GitLab Hackathon は、分散した速度と生産性の素晴らしい仮想イベントです。多くのベテランおよび初めてのコントリビューターを引き付けます。
GitLab Hackathon の参加者はこのイベント中に多くの MR を作成するインセンティブを持っているため、非常に明確な要件、明確な実装ガイド、そして少ない作業量の MR を求めています。GitLab のフロントエンド全体で、Hackathon 中に大規模なプロジェクト全体の取り組み（例、別の例）で素晴らしい進捗がありました。これは関連する Issue やエピックがより広いコミュニティ向けに設計され、そのスケールを活用しているためです。
Hackathon での Editor グループの Issue プレゼンスをどのように改善できますか？
- より広いコミュニティを主要なオーディエンスとして Issue やエピックを書く。
quick winラベルを適切に適用できるよう、Issue の範囲を絞る機会を探す。- 明確な指示と各ディレクトリ/ファイルに対応した Issue を持つ単一のエピックに大規模なリファクタリングをまとめる（例）。
これはかなりの作業量に見えます。何を得ることが期待できますか？
Hackathon は新しいコントリビューターとベテランコントリビューターを引き付け、GitLab だけでなく Editor グループの関連 Issue にも貢献するよう人々をメンタリングする素晴らしい方法です。コントリビューターが良い経験をすると、類似した経験（例：同様のラベルや関わっている人物のある Issue を検索するなど）を求める傾向があります。
Hackathon への投資は、長期的なコミュニティを育てることへの投資です。
コードの保守性を改善する
Issue が初心者のコントリビューターにとって魅力的によく書かれていても、一部のコードベースへのコントリビューションは単純に難しい場合があります。保守性を考えるとき、私たちは通常、将来の自分たちのことを考え、「これを保守し続けられるだろうか？」と問います。オープンソースソフトウェアにおいては、自分たちを超えて考え、「自分のグループの外にいる人でもこれを保守し続けられるだろうか？」と問うべきです。
自分たちを超えてコードベースを保守可能に保つにはどうすればよいですか？
- テスタビリティ。変更が加えられた際、変更が何かを壊したかどうかを知るために特別な知識は必要ないはずです — テストスイートが失敗するはずです。
- 変更のしやすさ。コードベースを微調整して変更を加えることは簡単ですか？特定のモジュール間の結合度は高いですか？単一の責任が一つのまとまったモジュールに集まっていますか？
- 理解しやすさ。コンテキストが全くない人でもモジュールが理解できますか？コンテキストが必要な場合、そのコンテキストへのトレーサビリティはありますか？
