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.
Thanks for visiting the Wiki category direction page in GitLab. This page belongs to the Editor group of the Create stage and is maintained by Eric Schurter (E-Mail). More information about the Editor group's priorities and direction can be found on the Editor group direction page.
This strategy is a work in progress, and everyone can contribute to it:
Please comment and contribute in the linked issues and epics on this page. Sharing your feedback directly on GitLab.com is the best way to contribute to our strategy and vision.
Please share feedback directly via email, Twitter, or on a video call. If you're a GitLab user and have direct knowledge of your need for Wiki, we'd especially love to hear from you.
GitLab Wikis are a great way to share documentation and organize information via built-in functionality. Each GitLab project includes a Wiki rendered by Gollum, and backed by a Git repository.
Walkthrough of GitLab wikis (starts at 9 minutes):
Where we are Headed
We are beginning to explore a Confluence integration and testing Confluence Cloud with our own projects. Work on this can be seen in this epic.
As we look to future plans beyond 2021, we will be exploring ways to encourage collaboration by improving the editing experience.
Target Audience and Experience
All personas can use Wikis for storing information
As we currently focus on the Software Developer persona, we may need to investigate other, non-developer personas as our research found they are frequent users of wikis
What's Next & Why
We are currently working on:
Introducing a Rich Text Markdown Editor - The Content Editor is a new WYSIWYG, rich editor for Markdown content developed for the Static Site Editor but we're dogfooding it on Wiki first. With the ability to write Markdown with real-time visual previews and rich formatting options while maintaining the ability to switch back and forth between the raw source and WYSIWYG mode, our goal is to reduce the uncertainty that can come with writing in Markdown and make it easier for those who aren't fluent in Markdown to contribute.
Afterward we'll be focused on:
Improve AsciiDoc, RDoc and reStructuredText - Many of our customers rely on specific formats to support their wikis. We should make sure our wiki's support these formats so that they can use their Group Level wikis as a company.
Simplify wiki editing - Currently wiki editing is inconsistent with every other page, both visually and from a workflow perspective. This makes wiki less approachable for users familiar with the rest of GitLab. We should fix these inconsistencies as a priority.
Improve wiki navigation - As wikis grow with more and more content, GitLab is not providing the tools necessary to make them easy to navigate and use. This is a problem that can be resolved with support for macros and a few other small improvements. We're adding a layer of meta data into wiki pages that will help us with search and navigation and exploring how to upgrade wiki search.
Deeper integration of wikis with GitLab Once the immediate usability is addressed by the epics above, next we make sure that Wiki's can embed Issues, Designs or display other objects from GitLab.
What is Not Planned Right Now
We know that our new WYSIWYG Markdown editor can support real-time collaborative editing, but we may need an entirely new backend to support collaborative editing of Wiki pages. Ideally, we want to solve the problem of collaborative note taking, be highly approachable for everyone, but also offer the tremendous benefits of storing the content in a portable plain text format that can be cloned, viewed and edited locally (properties of Git). However, we are not actively working on a new architecture that can support this experience.