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
Dylan Bernardi	Associate Backend Engineer, Create:Editor Extensions
Erran Carey	Staff Fullstack Engineer, Create:Editor Extensions
John Slaughter	Staff Backend Engineer, Create:Editor Extensions
Kisha Mavryck Richardson	Engineering Manager
Laura Ionel	Senior Backend Engineer
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

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

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.

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).

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

View page source - Edit this page - please contribute.