エディター拡張機能: VS Code グループ

私たちは VS Code、WebIDE のコードエディター拡張機能を所有・保守し、Language Server にも貢献することで、GitLab のコア機能と AI 機能を開発者のワークフローに直接届けます。

注: エディター拡張機能: マルチプラットフォーム チームと共に、私たちは DevOps ライフサイクル の AI-Powered ステージ における エディター拡張機能グループ に属する製品カテゴリーのあらゆる側面を担当しています。

グループ概要

グループメンバー

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

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

以下のメンバーが AI-Powered:Editor Extensions グループの 安定したカウンターパート です:

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

製品カテゴリー

エディター拡張機能グループは以下の 製品カテゴリー を担当します:

コミュニケーション

私たちはチームとして週に1回の同期ミーティング（ノート（内部））を、AMER/EMEA と AMER/APAC の時間帯を週ごとに交互に切り替えながら開催しています。 録画は GitLab Unfiltered の Editor Extensions Category プレイリストにアップロードされます。

議論が終わったら録画を停止し、残りの時間はそのままコールに残ってグループの コーヒーチャット を行います。

共有カレンダー

クロスグループのオーナーシップと境界

エディター拡張機能のシステムは、異なるグループが所有する機能やモジュールをホストしています。

オーナーシップと境界 ページでは、私たちのシステムで機能を作成・保守するすべての関係者の間に明確さと期待値を提供しています。

グループプロセス

私たちのグループプロセスは本セクションに文書化されています。 あるプロセスが使われているのにここに記載されていない場合は、プロセスの進化 のガイダンスに従って文書化してください。

私たちのグループは比較的新しく、現状ではプロセスは軽量です。 プロダクト開発フロー や エンジニアリングワークフロー に文書化されている共通プロセスとは、いくつかの運用上の違いがあります。

プロセスの進化

私たちはプロセスに対して イテレーション のアプローチを取ります。 すべてを一度に定義するのではなく、ギャップや問題が見えたときにプロセスを追加します。 効率性 のため、役目を終えたプロセスを削除することも厭いません。

プロセスを進化させるには、このページに対して具体的な提案を含む MR から始めて フィードバックを求めてください。 議論には Issue のほうが向いている場合は、meta プロジェクト で作成してください。

Epic と Issue

私たちは計画された作業の 単一の信頼できる情報源として Issue/Epic の説明を排他的に使用 しています。

Epic と Issue は、可能な限り狭い範囲のスコープに合致するプロジェクトで作成します。以下のプロジェクトを使用しています:

優先順位付け

私たちは マイルストーン計画 Issue を使用して、現在/今後のマイルストーンの目標を定義します。 PM と EM が目標のすり合わせを担当します。 計画 Issue は毎月 自動的に作成 されます。

Editor Extensions 優先度ボード を使用して、相対的な Issue の優先度 を追跡します。列の上部にある Issue ほど優先度が高くなります。

別途、このグループのテクニカルライターはオープンな Issue を、ドキュメントや UI テキスト変更の可能性についてトリアージし、テクニカルライティングの トリアージプロセス に従います。レビュー後、各 Issue には ~tw::triaged ラベルが付けられます。

技術的負債

技術的負債は ~tech-debt ラベルでマークします。

Language Server ＋ VS Code Extension

技術的負債の優先順位付けは、月次の TypeScript Contributors ミーティング（ミーティング Issue 例）で行います。 このミーティングはチームカレンダー（フロントエンドおよび Create ステージのカレンダーにも）で確認できます。

ミーティング設定の詳細プロセスは、こちらの チームスニペット で確認できます。

すべての技術的負債 Issue に絵文字リアクションで投票し、優先度の高い Issue をミーティングで議論します。最も多くの票を得た Issue が（キャパシティが許せば）次のマイルストーンで優先されます。

見積もり

Issue の複雑さの大まかな見積もりを示すために、3つのウェイトを使用します。ウェイトは2つの要素から構成されます:

ベースウェイト

これらはコードベース／システムに精通している人向けの見積もりです。

  • 1 - 1〜2日の作業
  • 2 - 1週間の作業
  • 3 - 1.5週間の作業

ベースウェイトが 3 を超えるものはすべてスパイクとして扱い、結果として見積もり付きの1つ以上の Issue を生成すべきです。

主観的ウェイト

チーム／コードベース／システムに新しい場合は、ベースウェイトに 1 または 2 の追加ウェイトを足すことができます。

例:

  • Bob はチームに新しく、ウェイト 1（つまり単純な）の Issue を担当します。技術は知っていますが、私たちのシステムは知りません。2 の主観的ウェイトを追加して、最終ウェイトは 3 になります。
  • Alice はシステムに精通していますが、認証に触れる Issue（ウェイト 2）を担当します。Alice は私たちの認証パターンに不慣れなので、既存のアプローチをレビューする時間を確保するため 1 の主観的ウェイトを追加します。最終ウェイトは 3 になります。

開発ワークフロー

進行中の作業は ワークフローボード でキャプチャされます。 Issue がこのボードに表示されるためには、~"group::editor extensions" ラベルと現在のマイルストーンが必要です。

Issue の作業時には ワークアイテムステータス を使用します。

  • Planning breakdown - Issue は優先順位付けの準備ができている。
  • Ready for development - Issue は説明・見積もり・スケジュールが完了し、ピックアップされて作業される準備ができている。
  • In dev - Issue には実装を開始した担当者が割り当てられている。
  • In review - スパイク／実装が完了し、誰かがスパイク結果または最後の MR をレビューする必要がある（最後の MR と表現するのは、複数の MR を実装している場合、最後の MR のみがワークフローラベルの変更を引き起こすべきだからです）。

ワークアイテムステータスが利用できない場合は、スコープ付き ~workflow ラベルを使用します:

  • ~"workflow::ready for development"
  • ~"workflow::in dev"
  • ~"workflow::in review"

レトロスペクティブ

コードレビュー

コメントの重大度レベル

私たちは MR レビューで以下のレベルのコメントを使用します。MR レビュアーは自分のコメントの重大度を判断し、その判断を MR 作成者と議論します。

immediate follow-up と follow-up のレベルには、より複雑なプロセスが付随しています。レビューでこのページにリンクすることで、フォローアップをどのように追跡し対処すべきか説明できます。

  • blocking - (blocking) - 同じ MR で対処する必要があります。装飾子のないすべてのコメントは blocking 扱いなので、(blocking) 装飾子を追加するのは任意です。
  • immediate follow-up - (non-blocking, immediate follow-up) - コメントが重要なため、修正は作成者が次に作る MR としてすぐに実装すべきです（クリティカルな本番バグなどの緊急事態はフォローアップより優先されます）。
  • follow-up - (non-blocking, follow-up) - この問題は対処すべきですが、その重大度は他のすべての技術的負債やフォローアップとの兼ね合いで判断すべきです。
  • optional - (non-blocking) - このコメントは個人的な好みか、MR に大きな影響を与えないものです。フォローアップ Issue を作成するかは任意です。
immediate follow-up を使用するタイミング

blocking コメントの代わりに immediate follow-up を選ぶ理由は次のとおりです:

  • 元の MR が複雑すぎて再フォーカスを試みている場合 - MR レビューに多数のコメントが付き、何日も続いている場合、immediate follow-up に取り組むことで認知負荷を減らし、フォーカスを改善できます。
  • 元の MR が緊急の場合 - MR が緊急／クリティカルな機能を提供しており、機能は動作するもののコードを私たちの基準に合わせて変更する必要がある場合。緊急性がなければ、同じ MR で作業することを好むでしょう。
immediate follow-up プロセス

未対処の immediate follow-up コメントを持つ MR がマージされた場合:

  • MR 作成者はこのコメントに対する Issue を作成し、Issue が以下を満たすことを確認します:
    • MR 作成者がアサインされている
    • 作業を捉えるタイトルと説明がある
    • 元の MR に関連付けられた blocking issue としてマークされている
    • ~immediate および ~follow-up ラベルが付けられている
  • immediate follow-up が実装されるまで、元の MR の GitLab Issue はクローズすべきではありません。
follow-up プロセス
  1. MR 作成者は follow-up Issue を作成し、フォローアップが何についてのものかを 明確に文書化（タイトルと説明に）し、~follow-up ラベルを追加します。
  2. MR 作成者は コード内の // FIXME コメント で Issue を参照します。
コメント例

“(immediate follow-up): これはシングルトンを導入していますが、私たちはシステム全体でシングルトンから移行しようとしています（Issue リンク）。アンチパターンの拡散を防ぐため、これに迅速に対処すべきです。”

これらのコメントの重大度レベルは静的ではありません。例えば、最初は blocking としてマークしたコメントを、MR 作成者との議論後、follow-up に変更することに同意するかもしれません。

FIXME コメントによるコード内の Issue 追跡

私たちは // FIXME コメントを使ってコード内で既存の Issue を直接追跡します。これらのコメントは2つの方法で作成されます:

  • エンジニアが開発中に 既存の Issue に気付き、すぐに修正できない場合。コードベースに // FIXME コメントを追加し、任意で Issue を参照します。
  • MR レビュー中に フォローアップコメント が作成され、このフォローアップを Issue と // FIXME コメントの両方で追跡する場合。

メンテナーは、レビューサイクルを増やさないため、マージ前の最後のコミットとして MR に // FIXME コメントを追加することが許可されています。

FIXME と TODO のコメントは互換的に使用します。

このアプローチのより詳細な説明と利点のリストについては、提案 を参照してください。

知識共有

このセクションには、各拡張機能で同じ情報を簡単に見つけられるようにするためのリンクがあります。 これは最初のイテレーションであり、最終的にはこのコンテンツは別の場所に置かれるでしょう。

Code Suggestions がサポートする言語

各拡張機能はサポートする言語の配列を定義します。

使用中の Language Server バージョン

採用情報

現在の募集職種については 求人ページ をご覧ください。

オーナーシップと境界 - エディター拡張機能
このページは、エディター拡張機能のシステムで機能を作成・保守するすべての関係者の間に明確さと期待値を提供します。
最終更新 May 6, 2026: Merge pull request #100 from kyama0/fix/upload-images-tolerate-upstream-missing (70970e1a)
ページのソースコードを見る - ページの編集 - please contribute. Creative Commons License