Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Category Direction - Editor Extension

Editor Extension

   
Stage Create
Maturity Minimal
Content Last Reviewed 2020-10-20

Introduction and how you can help

Thanks for visiting this direction page on Editor Extension. This page belongs to the Editor group of the Create stage and is maintained by Kai Armstrong (E-Mail).

This direction is constantly evolving and everyone can contribute:

Overview

Code Editors are one of the most important tools in a software engineers toolkit because the majority of their work is writing and working with code. They're customized with extensions for programming languages, coding standards and frameworks and more for the type of work being done. They're also optimized for connecting to development runtime environments and services engineers need to do their work.

Engineers working on contributions often collaborate with product managers, designers and other engineers to complete their work. Initially this collaboration takes place in issues where engineers can ask clarifying questions, review designs and discuss solutions. When engineers begin to work on these contributions, issues serve as the reference document and requirements to complete their task.

Once those contributions have been worked engineers contribute those via a Merge Request. Merge Requests are a collaborative process that involves getting feedback on the work completed and then responding to that feedback through additional revisions and comments.

Configuration files are also common to software development and the tools of the DevOps life cycle. In GitLab there are files like .gitlab-ci.yml and CODEOWNERS which have specific syntaxes and parameters to properly configure. Making changes to these files often involves having documentation available and then validating content through commits or tools outside the editor.

GitLab supports teams collaborating and building software together, however that collaboration is only available inside the GitLab application.

Developers, on the other hand, spend the majority of their time working in local editors implementing work outlined in issues, responding to merge request feedback and testing/debugging their applications. These tasks are the core of the developer experience, but GitLab is missing from this experience in any integrated way.

Supporting Categories

Work in this category is related to that of the Live Preview category. Extending editors and providing developers with an experience to see and understand the changes they're making. Progress in that category can be tracked against What's Next.

Target Audience and Experience

The software development process involves many people working across various parts of configuration, contribution and review. All of these users work together to advance software projects in their organization.

Engineering personas who are contributing to development, configuring or interacting with continuous integration and reviewing contributions from other team members. Users performing these tasks need tools that allow them to deeply understand the changes and provide meaningful feedback of both comments and code suggestions. These are specifically addressed by the following GitLab Personas:

Challenges to address

Configuration Users who configure projects or GitLab need editing tools to help them be efficient at this process. Creating specialized configuration files for working with GitLab CI or other areas of GitLab benefit from feedback provided directly in the editor.

Contribution Engineering personas who work on contributing directly to the code in projects need to action feedback from the review process. Having easy access to the feedback from reviewers and CI jobs inside of the editor should ensure that it's easy to action.

Review The code review process encompasses both engineering personas and non-engineering personas who contribute through design, product and other feedback. In solving for these users it will be important to make sure that people who want to give feedback are able to easily accomplish that.

Where we are headed

GitLab should support developers closer to where they're doing their meaningful work and enable them to be more efficient in the delivery of that work.

Problems to Solve

There are many specific problems that can be solved by focusing on local developer tooling:

  1. Developers working in local editors
  2. Developers working locally with local runtime
  3. Developers working locally with remote runtime

What's Next & Why

In Progress: VS Code Webview Cleanup &4604

The current GitLab Workflow extension for VS Code supports interacting with issues and merge requests through experimental webview features. There are some known issues and this feature needs to be defaulted on so more users can begin working with issues and merge requests inside of VS Code.

Upcoming: Merge Request Reviews in VS Code &4607

Merge requests are an essential part of the development process. Extending the ability to comment and leave feedback on merge requests from VS Code will be an important part of meeting developers in their tools. This allows for more efficient reviews and less context switching for both reviewers and contributors.

What is Not Planned Right Now

We're not currently focused on extensions for any other local editors or IDEs. We recognize there are a variety of these environments and we'll continue to monitor demand and market trends to look for other opportunities to support developers.

The editor group is also not looking to connect our existing Web IDE to any runtime environments or local tools for further development. We may continue to explore a more advanced Web IDE that could support these itmes in the future.

Competitive Landscape

Local Editors

Local Runtime

Remote Runtime

Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license