The following page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features or functionality remain at the sole discretion of GitLab Inc.
Content last reviewed on 2022-05-10
This is the direction page for the Editor group which is part of the Create stage of the DevOps lifecycle and is responsible for the following categories:
| Category | Direction | Description | Maturity |
|---|---|---|---|
| Web IDE | Direction page | A web-based multi-file code editor | Viable |
| Remote Development | Direction page | Server-side runtime environments | Planned |
| Snippets | Direction page | Small, sharable bits of code saved for easy access | Complete |
| Wiki | Direction page | Built-in, git-backed knowledge base | Viable |
| Pages | Direction page | Deploy and host static sites | Complete |
| Static Site Editor (deprecated) | Direction page | Visual editor for Markdown content hosted in a static site | Viable |
In support of these categories, the Editor group created and maintains two core editing components. These editors are intended to be flexible, extensible, and reusable across GitLab and while they don't meet the traditional definition of a category, they do have distinct strategies and backlogs. They are:
| Component | Direction | Description | Strategy epic |
|---|---|---|---|
| Source Editor | Direction page | Our underlying code editor |
Epic |
| Content Editor | Direction page | A visual Markdown editor | Epic |
With 4 categories and 2 foundational editor components, the Editor group has to prioritize aggressively. In general, the group's goals revolve around consolidation and standardization of editing experiences to improve consistency and maintainability. Our current focus areas and engineering investment are broken down by category below, percentages represent how much engineering time on average is allocated in each milestone. Since the Source Editor and Content Editor span multiple categories, investment in those is included in the most relevant category.
The Web IDE has now been refactored to use Source Editor which enables us to work on creating a more consistent, cohesive code editing experience to GitLab. One of the primary goals for the category is to bridge the gap between the Single File Editor (the experience of editing a single file from the Repository view) and the more complex but powerful Web IDE. We believe that breaking down the barrier between these two editing paths will drive adoption and overall satisfaction with the merge request and review experience. While we tackle that larger concern, we will also focus on extending the underlying Source Editor itself and enabling more advanced workflows like live Markdown preview or inline merge request discussions.
The Web IDE makes it possible for anyone to contribute to a project right from their web browser. Editing the actual code, however, is only a small part of a developer's workflow. Local IDEs, combined with properly-configured development environments, make it possible to run tests, lint code, generate previews, and offer features that improve developer efficiency like code completion. Without these features, developers can't fully adopt a tool. Remote Development is an early stage category that aims to provide a server-based runtime environment that can be accessed from the Web IDE or your local IDE, eliminating the need for managing a complex set of dependencies on your local machine.
In GitLab 14.0, we introduced a WYSIWYG Markdown editor, what we've come to call the Content Editor, that provides a rich text editing experience to make it easier for everyone to contribute. Initially available in the Wiki, the highest priority for the Editor group here is to build complete support for GitLab Flavored Markdown so that the Content Editor can be used as a production-ready, default editing experience for Wiki. Afterward, the Content Editor can be introduced anywhere Markdown content is written in GitLab. This includes issue and epic descriptions, comments, and even when editing Markdown files directly in the Repository view or Web IDE.
GitLab Pages offers a streamlined way to deploy and host your statically generated website on our shared infrastructure. The current implementation is focused primarily on making the connection between the CI build process and the deployment of static assets, there is huge potential to improve the user experience around managing, editing, and collaborating on static assets from within GitLab. Pages is a critical piece of the Editor group's strategy for enabling everyone to contribute.
The Wiki is one of our most used categories and there are several opportunities to improve the experience and drive growth. We are wrapping up an effort to migrate the wiki functionality to native Gitaly RPCs, which will bring performance and stability improvements. Following that, however, we will reduce our investment in Wiki to support only the most critical and severe bug fixes while we shift our attention to building an MVC for Remote Development.
Snippets reached Complete maturity in late 2020 with the introduction of versioned and multi-file snippets. Snippets are powered by Source Editor, so improvements to that experience can in turn benefit the editing experience of Snippets. The next category-specific features we would like to focus on are around organization and sharing but the team will focus first on categories with larger user bases and wider potential reach.
The Static Site Editor reached Viable maturity in late 2020, however we identified a need for a more scalable and extensible WYSIWYG editor. This technical investigation resulted in what is now known as the Content Editor — an HTML-based rich text editor that is currently implemented in the Wiki. We have deprecated the Static Site Editor as a category and intend to remove the feature from GitLab in an upcoming release. In its place, we plan to deliver the same value to a wider audience by using the Content Editor to edit Markdown content across GitLab and invest further in the Pages experience to realize the static site content management vision.