Create:Editor Extensions Group

The Create:Editor Extensions Group is responsible for all aspects of the product categories that fall under the Editor Extensions group of the Create stage of the DevOps lifecycle.

Group overview

Group members

Name	Role
Andrei Zubov	Senior Frontend Engineer, Create:Editor Extensions
Anna Springfield	Senior Backend Engineer, Create:Code Creation
Bohdan Parkhomchuk	Backend Engineer, Create:Editor Extensions
Dylan Bernardi	Associate Backend Engineer, Create:Editor Extensions
Elwyn Benson	Senior Frontend Engineer, Create:Editor Extensions
Erran Carey	Staff Fullstack Engineer, Create:Editor Extensions
John Slaughter	Staff Backend Engineer, Create:Editor Extensions
Juhee Lee	Fullstack Engineer
Karl Jamoralin	Backend Engineer
Kisha Mavryck Richardson	Engineering Manager
Laura Ionel	Senior Backend Engineer
Marvin Gay	Backend Engineer, Create:Editor Extensions
Olena HK.	Senior Frontend Engineer, Create:Editor Extensions
Tomas Vik	Staff Fullstack Engineer, Create:Editor Extensions
Tristan Read	Senior Frontend Engineer, Create:Editor Extensions

Stable counterparts

The following people are stable counterparts of the Create:Editor Extensions Group:

Name	Role
Dasha Adushkina	Senior Product Manager
Amy Qualls	Senior Technical Writer, Create (Editor Extensions, Code Review)
Jay McCure	Senior Software Engineer in Test, Dev:Create
Taylor Vanderhelm	Senior Product Designer

Product categories

The Editor Extensions group is responsible for the following product categories:

• Editor Extensions

Communication

We have a sync meeting as a team once per week. Recordings are uploaded to the Editor Extensions Category playlist on GitLab Unfiltered. When the discussion is finished, we stop the recording and stay on the call for the remaining time to have a group coffee chat.

Additionally to our main team’s slack channels, each extension/project we work on has its own slack channel:

• Team:
  • #g_editor-extensions - Sync Agenda
  • #g_editor-extensions_social
  • #g_editor-extensions-standup
• Projects
  • Language Server: #f_language_server
  • VS Code extension: #f_vscode_extension
  • Visual Studio extension: #f_visual_studio_extension
  • JetBrains extension: #f_jetbrains_plugin
  • Neovim extension: #f_neovim_plugin

Cross-group ownership and boundaries

Editor extensions systems host features and modules owned by different groups.

The Ownership and Boundaries page provides clarity and a clear expectation between all parties who author/maintain features in our systems.

Group processes

Our group processes are documented in this section. If a process is in use but not described here, please follow the guidance in Evolving the process to document it.

Our group is relatively new, and currently light on processes. There are several differences between how we operate and the shared processes documented in the product development flow and engineering workflow.

Evolving the process

We take an iterative approach to our processes. Instead of defining it all at once, we add process when we see a gap or identify a problem. For efficiency, we also don’t shy away from removing a process that has outlived its usefulness.

To evolve the process, please start with an MR to this page which contains your specific proposal, and ask for feedback. If an issue is better suited for the discussion, it should be created in the meta project.

Epics & Issues

We exclusively use issue/epic descriptions as the single source of truth for our planned work.

• Epics: GitLab Epic Search
• Issues: GitLab Issue Search

Epics and issues are created in the project that matches their scope in the narrowest possible way. We use the following projects:

• Work specific to a single extension or to the Language Server:
  • Language Server
  • Visual Studio Extension
  • VS Code Extension
  • JetBrains Extension
  • Neovim Extension
• Other projects:
  • Editor Extensions Meta - Extensions work that isn’t specific to a single extension, and general team-related issues
  • Code Suggestions - Code Suggestions work that isn’t specific to Extensions
  • GitLab - Monolith work

Prioritizing

We use Milestone Planning Issues to define our goals for the current/upcoming milestone. The PM and EM are responsible for aligning on the goals. The planning issues are created automatically every month.

We use the Editor Extensions Priority Board to track the relative priority of issues. Issues at the top of a column have the highest priority.

Separately, the technical writer for this group also triages open issues for potential documentation and UI text changes, and follows the Technical Writing triage process. After review, each issue receives the ~tw::triaged label.

Technical debt

We mark technical debt with the ~tech-debt label.

Language Server + VS Code Extension

We prioritise technical debt in the monthly TypeScript Contributors meeting (example meeting issue). This meeting can be found in the team calendar (also in the frontend and Create stage calendars).

The detailed process for setting up the meeting can be found in this team snippet.

We vote on all technical debt issues with emoji reactions and then discuss the top priority issues in the meeting. The most upvoted issues are prioritised (if capacity allows it) in our next milestone.

Estimates

We use three weights to give a rough estimate of the issue’s complexity. The weight is made out of two parts:

Base weight

These are estimates for someone familiar with the codebase/system.

• 1 - day or two of effort
• 2 - week of effort
• 3 - week and a half of effort

Everything with a base weight above 3 should be a spike that will result in one or more issues with estimated weight.

Subjective weight

You can add extra weight 1 or 2 to the base weight if you are new to the team/codebase/system.

Examples:

• Bob is new to the team, they are picking up an issue with weight 1 (i.e. simple). They know the technologies, but not our system. They’ll add 2 subjective weight making the final weight 3.
• Alice is familiar with the system but is picking up an issue (weight 2) that touches authentication. She’s unfamiliar with our authentication patterns and adds 1 subjective weight to have enough time to review the existing approaches. That makes the final weight 3.

Development Workflow

The work in progress is captured on our Workflow Board. For issues to appear on this board, they must have ~"group::editor extensions" label and current milestone.

We use the following subset of the workflow labels to indicate the state of the issue:

• ~"workflow::ready for development" - the issue has been described, estimated and scheduled, and it’s ready to be picked up and worked on.
• ~"workflow::in dev" - the issue has an assigned person who started implementing it.
• ~"workflow::in review" - the spike/implementation is finished, and someone needs to review the spike result or the last MR (the last MR because if there are more MRs to implement, only the last one should result in the change of the workflow label).

Code review

Comment severity levels

We are using the following levels of comments in our MR reviews. The MR reviewer decides on the severity of their comments and discusses this judgement with the MR author.

Immediate follow-up and follow-up levels have more complex processes attached to them. You can link to this page in your reviews to explain how the follow-ups should be tracked and addressed.

• blocking - (blocking) - Must be addressed in the same MR. All comments without any decorator are blocking, so adding the (blocking) decorator is optional.
• immediate follow-up - (non-blocking, immediate follow-up) - The comment is important enough that the fix should be implemented as the very next MR the author creates (emergencies like critical production bugs still take priority over the follow-up).
• follow-up - (non-blocking, follow-up) - This issue should be addressed but the severity should be weighed against all other technical debt and follow-ups
• optional - (non-blocking) - this comment is either personal preference or doesn’t have a large impact on the MR. Creating a follow-up issue is optional.

When to use immediate follow-up

These are the reasons why we would choose immediate follow-up over a blocking comment:

• The original MR was too complex and we are trying to re-focus - The MR review has many comments and it has been going on for many days, then working on an immediate follow-up might reduce the cognitive load and improve focus.
• The original MR is urgent - The MR delivers an urgent/critical feature, the feature works but the code needs to be still changed to match our standards. If it wasn’t for the urgency, we would prefer to do the work in the same MR.

Immediate follow-up process

When an MR with an unaddressed immediate follow-up comment is merged:

• MR author creates an issue for this comment and ensures the issue:
  • Has the MR author is assigned to it
  • Has title and description that captures the work
  • Is marked as blocking issue associated with the original MR
  • Is labeled ~immediate and ~follow-up
• Until the immediate follow-up is implemented, the GitLab issue for the original MR should not be closed.

Follow-up process

1. The MR author creates a follow-up issue and clearly documents (in title and description) what the follow-up is about and adds the ~follow-up label.
2. The MR author references the issue in a // FIXME comment in the code.

Comment Example

“(immediate follow-up): This introduces a singleton and we are trying to move away from singletons in the whole system (issue link). We should address this quickly to prevent the anti-pattern from spreading.”

These comment severity levels are not static. For example, you might initially mark a comment as blocking, but after discussion with the MR author, you may agree to change it to a follow-up.

Tracking issues in code with FIXME comments

We track existing issues directly in the code using // FIXME comments. These comments are created in two ways:

• An engineer notices a pre-existing issue during development that they can’t fix immediately. They add a // FIXME comment to the codebase and optionally reference an issue.
• A Follow-up comment has been created during an MR review, and we track this follow-up with both an issue and a // FIXME comment.

Maintainers are allowed to add // FIXME comments as the last commit to the MR before merging it to avoid an extra review cycle.

We use FIXME and TODO comments interchangeably.

For a more detailed explanation and list of advantages of this approach, see the proposal.

Temporary silos

Our team owns several projects, written in different languages (Typescript, Kotlin, C#, Lua) and targeting different platforms.

We are currently intentionally working in silos, by assigning engineers to the project/technology that they can contribute to most efficiently. This increases speed of development as we aim to reach GA for Code Suggestions, at the cost of knowledge sharing and team resiliency.

This intentional siloing is a temporary measure. While we do need to cultivate deep expertise in each project, the mid-term vision for the team is to provide opportunities for everyone to contribute across each project. This will increase collaboration, team resiliency, and provide opportunities for growth.

Knowledge sharing

This section contains links to make it easier to find the same information for each extension. This is a first iteration, this content should probably live somewhere else eventually.

Languages supported by Code Suggestions

Each extension defines an array of supported languages.

• VS Code: AI_ASSISTED_CODE_SUGGESTIONS_LANGUAGES
• Visual Studio: LanguageManager
• JetBrains: SUPPORTED_EXTENSIONS
• Neovim: auto_filetypes

Language Server versions in use

• Visual Studio: the server binary is versioned directly: GitLab.Extension/Resources/gitlab-lsp-win-x64.exe
• VS Code: the server is pulled as a package: package.json
• JetBrains: N/A - see issue
• Neovim: the server is pulled as a package: lsp/package.json

Hiring

Check out our jobs page for current openings.

Engineering metrics