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.
| Stage | Plan |
| Content Last Reviewed | 2024-01-08 |
Welcome to the Knowledge group direction page! Knowledge group is in the Plan Stage of GitLab and contains the Wiki and Pages categories, as well as the Rich Text Editor. These categories fall within the knowledge management (KM) market as defined by Gartner. The focus of KM is to provide visibility and access to a flow of information across a variety of operations, enabling collaboration that has traditionally existed in silos. Commonly used products in the KM market include Confluence and Notion.
If you have feedback related to Knowledge group please comment and contribute in the following linked issues, or create a new issue if you find none fit your criteria. Make sure to tag @mmacfarlane, Product Manager for Knowledge group, so he can read and respond to your comment. Sharing your feedback via issues is the one of the best ways to contribute to our strategy and vision!
As always, this direction page is a work in progress, and everyone can contribute.
At GitLab, our vision is to become the AllOps platform, a single application for all innovation. Knowledge group is a signficant contributor to this vision given its focus on enabling collaboration across users regardless of their role. An overview of how each Knowledge group category aligns with this vision is as follows:
Pages: Our vision for Pages is to provide an experience that guides and supports users to host static assets on the web, regardless of their level of development experience. At the moment we are wrapping up work on two major customer asks, GitLab Pages Multiple Deployments and GitLab Pages without DNS Wildcard, which will further enable us to provide the aforementioned experience. We are already evaluating future opportunities around improving the experience of creating and configuring Pages sites and making content management and collaboration easier for non-developer personas. Two ideas include User Authentication and Authorization and Offering Audit Logs.
Rich Text Editor: We've broken down our prioritization of Rich Text Editor work into two buckets aligned with the theme of improving product usability (a theme which roles up to the vision of an AllOps platform). The first bucket, creating feature parity with the markdown editing experience, involves introducing the Rich Text Editor across more areas of GitLab. We're confident creating feature parity will improve accessibility and allow users who traditionally feel GitLab is too technical a better opportunity to contribute. We'll then focus on the second bucket, advanced editing and performance stabilization. This bucket will allow us to focus on features such as adding support for text editing features such as aligning text, RTL support, editing footnotes and reference style links.
Wiki: We see the Wiki as a major opportunity for improved in the GitLab product. The Wiki was in stable maintenance mode for much of FY23 and early FY24. We've recently enhanced the Wiki to include a print PDF feature and introduced the rich text editor within it. We've also recently presented an Opportunity Canvas around a key feature to be developed and finalized the JTBD for the category. We are now conducting a Spike on the top two JTBD we've identified.
Pages: Our 1 year plan for Pages can be broken into two distinct themes, stability and improvement.
Our first theme, stability, focuses on the breakdown of existing bugs and maintenance items, as well as updating documentation related to previous releases. Specific to documentation, we've come to understand that some previous feature rollouts did not include updates to technical documentation, which has caused some confusion to users in utilizing the product.
Our second theme, improvement, focuses on new feature development. We are acutely aware of four major customer requests as detailed on the Pages Direction Page. We aim to prioritize these items to improve our customer experience, and are thankful to our customers for their patience and feedback as we look to deliver these items.
Rich Text Editor: Our 1 year plan for Rich Text Editor revolves around the theme of GitLab as an AllOps plaftorm. We hope to implement the new Rich Text Editor across GitLab to improve accessibility and efficiency for all users of GitLab. You can follow our progress in the following General Availability Epic.
Wiki: In FY24Q2 we completed research on the Wiki category in order to develop JTBD. We've finalized these JTBD and will utilize them to inform our Wiki strategy. We will decide how to allocate engineering capacity in the future from Pages, or via another route, to Wiki so we can properly meet the demands of our customers.
Rich Text Editor: Rich Text Editor: Release Rich Text Editor Generally, Display and Edit Markdown Comments in the Rich Text Editor, Insert Table of Contents in the Rich Text Editor.
Wiki: Draw.io/diagrams.net integration with wiki, Editing Sidebar in Project or Group Wiki Removes Existing Sidebar,Relative Links are Broken On Wiki ASCII Pages
Pages: GitLab Pages without DNS Wildcard in Experimental state, GitLab Pages Multiple Deployments in Experimental state.
Pages: GitLab Pages Multiple Versions Support, GitLab Pages without DNS Wildcard
Rich Text Editor: Enabling the rich text editor across GitLab
Wiki: We have iniated a Spike on the existing Wiki codebase to understand how to best approach product enhancement.
Pages: As noted under our 1 year vision, we are focusing on the core themes of stability and improvement. Stability focuses on resolution of bugs and maintenance, and improvement focused on resolution of our top 4 customer issues. We are actively working on GitLab Pages Multiple Versions Support and GitLab Pages without DNS Wildcard.
Rich Text Editor: Our plan is to continue integrating the Rich Text Editor into the GitLab workflow. We are tracking progress on this initiative via the Rich Text Editor GA Plan.
Wiki: Wiki was transitioned from Create Stage to Plan Stage at the beginning of FY24. The future direction of Wiki, as a result of this transition, is being evaluated. We've recently completed JTBD for the category and have honed in on our first priority for development (which was presented to product leadership via an opportunity canvas).
Real-time Collaborative Editing: 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.
Knowledge Group Competitive Statement: The ocus of Knowledge group is to provide visibility and access to a flow of information across a variety of operations, enabling collaboration that has traditionally existed in silos. Commonly used products in the market include Confluence, Notion, and GitHub. We believe that fundamental improvements in our Pages, Rich Text Editor, and Wiki categories enable use to deliver a more competitive Planning experience against industry leaders.
Pages: We are invested in supporting the process of developing and deploying code from a single place as a convenience for our users. Other providers, such as Netlify, deliver a more comprehensive solution. There are project templates available that offer the use of Netlify for static site CI/CD, while also still taking advantage of GitLab for SCM, merge requests, issues, and everything else. GitLab offers configurable redirects, a well-loved feature of Netlify, made available in gitlab-pages. We are seeing a rise in JAMStack and static site generators partnering in the media. This trend toward API-first, affirms our modernization effort of Pages, reinforcing our cloud native installation maturity plan. GitHub also offers hosting of static sites with GitHub Pages. Key differentiators between the two are that GitHub Pages configuration and deployment is more "automatic" in that it doesn't require you to edit a CI configuration file, and that GitHub Pages has limits placed on bandwidth, builds, and artifact size where GitLab currently does not.
Rich Text Editor: Rich Text Editor aligns as a competitor against both the aforementioned and to-be-mentioned competitors of Pages and Wikis.
Wiki: We currently most closely compete with GitHub Wiki but we would like to compete with Confluence, Notion, Roam Research, and Google Docs. We've heard from customers that managing wikis with tens of thousands of pages can be challenging. And while a full-featured product like Confluence has advanced features and integrations, the GitLab wiki would be a stronger competitor if we fixed some low-hanging fruit related to page title and redirects and improved the functionality of the sidebar to aid navigation.
Pages: Pages is currently considered Complete maturity. The next step would be lovable. We believe we are moving toward this state via introduction of the WYSIWYG experience.
Wiki: Wiki is currently considered Viable maturity. Our research indicates to us that we have several key features to develop in order to begin moving the categeory toward Complete. We are continuing to refine our direction to most optimally get us to Complete maturity.
Our current offering best serves Sasha, the Software Developer, but we strive to provide a delightful experience for all personas. One example of a feature aimed at non-developers is the Rich Text Editor.