Docs Engineering: 機能の優先順位付けとプロセス
概要
Docs Engineering チームは、カンバン とマイルストーンベースの優先順位付けを使用して GitLab プロダクトドキュメントプラットフォームを維持しています。私たちは、新機能、プラットフォームの健全性、チームの生産性のバランスを取るテーマに作業を整理します。
GitLab のプロダクト原則 と プロダクト開発フロー から着想を得て、それを私たちのチームコンテキストに適応させています。
Issue ライフサイクル
Issue を作成する
誰でも Docs ウェブサイト用の Issue を作成 できます。バグには bug テンプレート を、それ以外にはデフォルトテンプレートを使用してください。トリアージ時にラベルを追加するので、正しく入力することを心配する必要はありません。
ウェブサイト自体ではなく、docs コンテンツに問題がある場合は、該当ページの下部にある “Suggest updates” ボタンを使用して、適切なプロジェクトで Issue を開いてください。
トリアージプロセス
テクニカルライティングの Staff エンジニアが、すべての新しい Issue を週 2 ～ 3 回レビューし、次の作業を行います。
- 作業タイプラベル を適用
- 追加のカテゴリー分類のための docs 固有のラベル を追加
- 機能の工数見積もりのためのウェイト（1/3/8）を設定。ウェイトは優先順位付けに使用され、キャパシティ計画や完了日の見積もりには使用されません。
- 優先度とキャパシティに基づいてマイルストーンをアサイン。
- 実行可能になったら Ready for development としてマーク。
優先順位付けフレームワーク
優先度要因
- 顧客に成果をもたらす こと
- インパクト対工数
- テクニカルライティングチームロードマップ との整合
- 技術的依存関係とブロッキング作業
- R&D ガイドライン ごとの 60/40 機能/メンテナンス目標
開発者ワークフロー
作業選択
チームメンバーは、機能作業、メンテナンス、バグ修正のバランスを取りながら、Ready for development カンバン列から自己選択します。利用可能なキャパシティに合う作業を選び、必要な際にはためらわずにガイダンスを求めてください。
カンバンプロセス
Issue を Ready for development → In dev → In review → Closed の順に進めます。一般的に、作業はデプロイされ、ドキュメントが完了したときに「完了」となります。
レビューとテストのガイドライン
すべてのコード変更は別のエンジニアによってレビューされるべきです。これらのレビューは、一般的な GitLab の コードレビューベストプラクティス に従うべきです。複雑な変更や、チームワークフローに影響を与える可能性のある変更については、複数のレビュアーをタグ付けすることを検討してください。
サイトの見た目や感じへの変更、特にユーザビリティに影響を与える可能性のあるグローバルな変更は、Staff+ テクニカルライターまたはマネージャーによる UX レビューも受けるべきです。
新しいショートコードやその他のライター向け機能は、Staff+ テクニカルライターまたはマネージャーによってテストされ、その後スタイルガイド に文書化されるべきです。
bfd74782)