フィーチャーフラグ使用ワーキンググループ

属性

チャーター

このワーキンググループは、GitLab の開発におけるフィーチャーフラグの使用を改善するための取り組みを調整・組織化します。フィーチャーフラグの内部使用に関して、組織内で多くの非同期的かつ現在進行中の議論が存在します。私たちはこれらの議論を収集・調整し、GitLab 内でのフィーチャーフラグ使用に関する統一的なポリシーとプロセスを作成することを目的としています。こうしたポリシーの統一性は、内部のステークホルダー、コミュニティメンバー、そして顧客が GitLab 機能の利用可能性についてより一貫した洞察を得るために不可欠です。

スコープと定義

このグループは、エンジニアがフィーチャーフラグを使用する方法がすべてのステークホルダーのニーズを満たすように、できる限りリーンなプロセスとポリシーを作成します。フィーチャーフラグのステークホルダーは一般的に、GitLab.com および特定バージョンのセルフマネージド GitLab インスタンス上の機能の現状を気にする人々です。

定義

• フィーチャーフラグ - これは必ずしもフィーチャーフラグ機能を指すのではなく、GitLab の開発においてフィーチャーフラグを使用する方法を指します。

終了基準

1. ✅ フィーチャーフラグのアーキテクチャーブループリントの達成
2. ✅ GitLab.org および GitLab.com 上のワーキンググループスコープラベルが付いたすべての Issue の完了
3. ✅ GitLab エンジニア向けのフィーチャーフラグトレーニングおよびフィーチャーフラグ監視トレーニングの改良と割り当て
4. ✅ GitLab 開発におけるフィーチャーフラグドキュメントの監査・改良・周知
5. ✅ GitLab の開発に置かれているフィーチャーフラグプロセスの状態に対して各機能リードが満足していること
6. ✅ フィーチャーフラグのライフサイクルを監視し、適切なタイミングで対応できるよう、長期的なフィーチャーフラグ管理を支援するデータの提供

進行中の作業

• 現在のフィーチャーフラグライフサイクルの把握

役割と責任

機能リードの責任：

• 各部門/サブ部門の個々のステークホルダーのニーズを代表すること
• 各部門/サブ部門から特定の提案に対するフィードバックを収集・統合すること
• ワーキンググループの成果（あれば）を伝達し、各部門/サブ部門からの質問に回答すること

機能リードは理想的には、策定されるポリシーの影響を受ける可能性のある IC（個人貢献者）であることが望ましいですが、上記の方法で部門やサブ部門を代表できる人であれば誰でも歓迎します。

以下の表のステークホルダー部門はアーキテクチャーブループリントで特定されたものであり、参考として記載しています：エンジニア、エンジニアリングマネージャー、エンジニアリングディレクター、プロダクトマネージャー、テクニカルライター、デリバリーエンジニア、SRE。

ページのソースコードを見る - ページの編集 - please contribute.