Create:Source Code FE チーム

共通リンク

チームのビジョン

GitLab ユーザーのエクスペリエンスの中心的な部分として、DevOps ライフサイクルの Create ステージの Source Code グループに属するすべてのプロダクトカテゴリに対して、革新的で喜ばれるエクスペリエンスを維持します。プロダクトの方向性については、カテゴリ方向 - Source Code Management ページをご覧ください。

チームのミッション

実装、技術的負債の管理、ディスカバリーフェーズでのタイムリーなフロントエンドの知見提供など、フロントエンドエンジニアリングの専門知識ですべてのカウンターパートをサポートします。

一般的に監視している Issue リスト

• Source Code + フロントエンドの Issue
• マイルストーン計画 Issue
• トリアージレポート
• フィーチャーフラグレポート
• OKR（機密）

チームメンバー

以下の人々は Create:Source Code FE チームの恒久メンバーです:

チームメンバー情報は 原文 (英語) を参照してください。

安定したカウンターパート

以下のメンバーは他の機能チームのメンバーで、私たちの安定したカウンターパートです:

チームメンバー情報は 原文 (英語) を参照してください。

主な責任

• プロダクトと UX とのコラボレーションによるアイデア出し、リファインメント、関連作業のスケジューリング
• Source Code Management プロダクトカテゴリでの機能開発、バグ修正のためのフロントエンドサポートの提供
• バグレポートとリグレッションへの対応
• 開発者エクスペリエンスを改善するためのメンテナンス作業の特定と準備
• フロントエンド部門全体にわたる取り組みへの協力

AI プロンプト

私たちは効率化のために使用する共通 AI プロンプトのリストを管理しています。

プロジェクト

アクティブプロジェクトテーブル

アーカイブプロジェクトテーブル

エンジニアリングオンボーディング

作業

一般的に、私たちは標準的な GitLab エンジニアリングワークフローを使用します。Create:Source Code FE チームと連絡を取るには、関連するプロジェクト（通常は GitLab）に Issue を作成し、~"group::source code" と ~frontend ラベル、および他の適切なラベル（~devops::create、~section::dev）を追加することが最善です。その後、上記にリストされた関連プロダクトマネージャーおよび/またはエンジニアリングマネージャーに自由にピンしてください。

より緊急な事項については、Slack の #g_create_source_code または #g_create_source_code_fe を利用してください。

サポートするカテゴリ別機能についてはこちらをご覧ください。

コードレビュー

知識のサイロ化を防ぎ、チーム外からの意見を受け取るために、以下の原則に従います:

• すべてのマージリクエストがチームを通じる必要はありません
• ただし、チームが認識すべき重要なマージリクエストについては、レビューの少なくとも 1 つがチームメンバーを通じるようにします

チームにとって重要な MR: これらはアプリのロジックへの変更や意味のあるコンポーネント変更です。大きなエピックでの継続的な作業もチーム内のピアからの監視が有益です。しかし、最終的には自分の判断で行ってください。

Issue のリファインメント

1. 問題を検証したら、プロダクト、UX、エンジニアリングが協力してソリューションを提案し、技術的に実現可能なものを決定します。提案されたソリューションは、問題を解決するかどうかを検証するためにユーザーと共有される場合があります。
   1. デザイン作業が必要な Issue は UX と workflow::ready for design でマークされます。
   2. デザインプロセス中の Issue は workflow::design でマークされます。
   3. デザインが準備でき、提案されたソリューションが実現可能と判断されたら、workflow::planning breakdown ラベルが適用されます。
2. 提案されたソリューションが実現可能であることを確認したら、できる限り分解する段階に移ります。Issue がこの段階に準備できたら、PM は workflow::refinement ラベルを Issue にマークして次のステップを示します。
3. 「マイルストーンごと」の定期バックログリファインメントセッションが 1 回あります。その際、バックログの Issue を一緒にレビューします。各エンジニアも、配信候補としてチームが取り組む価値があると考える Issue を提案します。
   1. Issue にさらなるリファインメントが必要な場合、workflow::refinement ラベルのついたタスクをエンジニアに配分します。
   2. Issue にさらなるリファインメントが必要ない場合、workflow::ready for development ラベルが適用されます。
   3. チームが次のマイルストーンで Issue に取り組むべきと考える場合は、マイルストーンを設定します。そうでない場合は scm-backlog ラベルを適用して %backlog マイルストーンに配置します。
4. EM はリファインメント Issue を作成し（例）、workflow::refinement ラベルのついたタスクをエンジニアに配分します。
5. エンジニアまたは EM は割り当てられた Issue のチェックリストに従い、必要に応じて PM、UX、その他のエンジニアリングカウンターパートと協力して質問や懸念事項に対処します。
6. Issue の計画された実装をさらに分解できる場合、エンジニア/EM は PM と協力してスコープを縮小し、そうなるまで新しい Issue を作成します（PM またはエンジニア/EM のどちらも新しい作業アイテムを作成できます）。
7. Issue が完全にリファインされたら、エンジニアまたは EM は適切な重みを追加し、workflow::ready for development としてラベルを付けます。これらの Issue はマイルストーンに追加できます。

図

flowchart TD
    A[Problem Validation] --> B[Solution Collaboration]
    B --> C{Design Required?}
    C -->|Yes| D[Mark with UX and workflow::ready for design]
    D --> E[Issue in design process with workflow::design]
    E --> F[Designs ready]
    C -->|No| F
    F --> G[Mark with workflow::planning breakdown]
    G --> H[Solution Viable?]
    H -->|Yes| I[Mark with workflow::refinement]
    I --> J[Per Milestone Backlog Refinement Session]
    J --> K{Needs Further Refinement?}
    K -->|Yes| L[EM creates refinement issue]
    L --> M[Engineers assigned to refinement tasks]
    M --> N[Engineers follow checklist]
    N --> O{Can be broken down further?}
    O -->|Yes| P[Reduce scope and create new issues]
    P --> N
    O -->|No| Q[Add weight and mark workflow::ready for development]
    K -->|No| Q
    Q --> R{Work in next milestone?}
    R -->|Yes| S[Set milestone]
    R -->|No| T[Apply scm-backlog label and place in %backlog milestone]

    %% Adding colors to different stages
    style A fill:#d4f1f9,stroke:#05a,stroke-width:2px
    style B fill:#d4f1f9,stroke:#05a,stroke-width:2px
    style C fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style D fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style E fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style F fill:#e1d5e7,stroke:#9673a6,stroke-width:2px
    style G fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style H fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style I fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style J fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style K fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style L fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style M fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style N fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style O fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style P fill:#fff2cc,stroke:#d6b656,stroke-width:2px
    style Q fill:#d5e8d4,stroke:#82b366,stroke-width:2px
    style R fill:#ffe6cc,stroke:#d79b00,stroke-width:2px
    style S fill:#f8cecc,stroke:#b85450,stroke-width:2px
    style T fill:#f8cecc,stroke:#b85450,stroke-width:2px

Issue リファインメントチェックリスト

リファインメントが必要な Issue に対して、エンジニア/EM はこのテンプレートを使用してコメントを追加し、すべてのチェックリストアイテムを完了させる必要があります。

これらのステップのいずれかを完了できない場合は、EM/PM にピンしてください。

# Issue Refinement Checklist

## Problem verification
- [ ] Issue label is ~"workflow::refinement"
- [ ] Issue title clearly describes the feature or change
- [ ] Issue description defines requirements and expectations
- [ ] Required permissions and access levels defined
- [ ] Desktop design is defined (if needed)
- [ ] Mobile design is defined (if needed)

## Implementation plan

- [ ] A comment with an implementation plan is created
- [ ] Implementation plan includes accessibility specification (if needed)
- [ ] Implementation plan includes proposal for ~"analytics instrumentation" (if needed)
- [ ] A separate issue is opened for adding ~"analytics instrumentation" and linked to this issue (if needed)
- [ ] Implementation plan includes ~documentation changes (if needed)
- [ ] Implementation plan includes proposal for adding feature tests (if needed)
- [ ] Implementation plan includes feature tests (if needed)
- [ ] Issue is small and doesn't need to be broken down

## Final steps
- [ ] This issue has a weight
- [ ] There are no blockers
- [ ] Issue has ~"workflow::ready for development" label

バグリファインメントチェックリスト

リファインメントが必要なバグレポートに対して、エンジニア/EM はこのテンプレートを使用してコメントを追加し、すべてのチェックリストアイテムを完了させる必要があります。

# Bug Refinement Checklist

## Bug verification
- [ ] Issue label is ~"workflow::refinement"
- [ ] Issue label is ~"type::bug"
- [ ] Issue title clearly describes the bug
- [ ] Steps to reproduce are documented
- [ ] Issue is still reproducible
- [ ] Severity labels are defined
- [ ] Related logs or error messages are attached

## Technical analysis
- [ ] Root cause has been identified or hypothesized
- [ ] Affected components/services are identified
- [ ] Potential side effects of the fix are considered

## Implementation plan
- [ ] A comment with an implementation plan is created
- [ ] Fix scope is contained and doesn't require larger refactoring
- [ ] Test cases to verify the fix are defined

## Final steps
- [ ] This issue has a weight
- [ ] There are no blockers
- [ ] Issue has ~"workflow::ready for development" label

実装計画

リファインメント中の Issue に対して、提供されたテンプレートを使用してコメントを追加してください。

### Implementation Plan

**1. Approach**

<!-- Provide a high-level description of the implementation idea -->

**2. Dependencies**

- [ ] Requires ~backend
- [ ] Requires ~frontend
- [ ] Requires ~database
- [ ] Requires ~documentation
- [ ] Requires ~UX work
- [ ] External service dependencies identified
- [ ] Requires ~API changes

**3. Implementation Steps**

<!-- Provide step by step description of what needs to be done -->

- Task 1
- Task 2
- Task 3

**4. Edge Cases**

<!-- Does the implementation cover all scenarios (success, failure) -->

- Success scenarios:
  - Case 1
  - Case 2

- Error scenarios:
  - Case 1
  - Case 2

- Edge conditions:
  - Case 1
  - Case 2


@engineer_username please review this implementation plan.
<!--
Pick a peer engineer following this criteria:
1. is a subject matter expert.
2. might have some familiarity with the topic. or
3. ask on slack who'd be available to review this plan before the due date of the issue
-->

キャパシティ計画

重み

重みの例

w1: Blame ビュー - 「authored」行が次の行にリーク

w2: 大きなファイルの CSV レンダリングがビューアをハング

w3: ブランチルールの編集: Deploy Keys の検索をサポートするようにセレクターを更新

Source Code のコンテキスト

Blob ビューに関連する Issue に重みを付ける際は、Blob の二重性を考慮してください。Blob ビューのレンダリングには HAML と Vue の両方を使用しています。変更を両方に実装することになる可能性が高いです。ほとんどのファイルタイプは Vue アーキテクチャを使用します。ただし、バックエンドの構文ハイライターが必要なファイルタイプがあり、それらは HAML でレンダリングされます。エラーが発生した場合も同様です。

この二重性は highlight.js で依存ファイルを表示する際にパッケージマネージャーへのリンクで解決される予定です。

スパイク Issue

ワークフローラベル

ワークフローラベルは 原文 (英語) を参照してください。

非同期スタンドアップ

Source Code グループのグループは、毎月曜日に #g_create_source_code_standup チャンネルで非同期スタンドアップを行います。

目標は、これらのグループのメンバーが個人レベルでつながることをサポートすることであり、人々の進捗を確認したり、状況を伝えたり助けを求めるための既存のプロセスを置き換えるものではありません。質問はその点を念頭に置いて書かれています:

• 前回話してから仕事以外では何をしましたか？
• 今日は何をする予定ですか？
• 進捗や生産性を妨げているものはありますか？

詳細については、Create ステージの Issue トラッカーの非同期スタンドアップフィードバック Issue を参照してください。

レトロスペクティブ

「マイルストーンごと」の定期レトロスペクティブが 1 回あり、特定のケースを分析する、通常はイテレーションアプローチに焦点を当てた「機能ごと」のアドホックなレトロスペクティブを行う場合もあります。

マイルストーンごと

レトロスペクティブは 原文 (英語) を参照してください。

マイルストーンキックオフとレトロスペクティブレビュー

各マイルストーンの開始時に、すべての IC が新しいマイルストーンの成果物の計画を発表する同期型のキックオフセッションがあります。

これは、すべての成果物が割り当てられてから少なくとも 2 営業日後に行われ、マイルストーンの初日に割り当てが行われます。

デザインから追加の情報が必要な場合は、ミーティング後にデザイナーへのリクエストリストが発行されます。

このコール中に、非同期の Issue で議論されたハイライトを振り返る簡単なレトロスペクティブレビューも行います。

関連ページ

Issue

• 2020 年 4 月: フロントエンド: イテレーションレトロスペクティブ (Source Code)

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