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.
Welcome to the Knowledge group direction page! Knowledge group is part of the Plan Stage in GitLab and encompasses three categories, Wiki, Pages, and 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, Notion, and SharePoint.
This direction page is a work in progress, and everyone can contribute.
If you have feedback, please comment and contribute in the 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.
At GitLab, our vision is to become the AllOps platform, a single application for all innovation. Knowledge group can be a major contributor to this vision, given its focus on enabling collaboration across users (regardless of their role) and breaking down traditional knowledge silos. An overview of how each Knowledge group category aligns with this vision is as follows:
Pages: Our priority 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. We can fulfill this strategy by immediately focusing on improving the stability and security of Pages. Afterward, we'll address our most popular issues and compelling blockers for those hosting static content and documentation. Further down the line, we'll validate bigger opportunities around improving the experience of creating and configuring Pages sites and making content management and collaboration easier for non-developer personas.
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 current editing experience, involves introducing the Rich Text Editor across 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. After creating feature parity we'll focus on the second bucket, advanced editing and performance stabalization. This bucket will allow us to focus on features such as adding support for text editing features not yet present, aligning text, RTL support, editing footnotes and reference style link. Additionly, this second bucket will allow time to focus on the frontend deserializer (ie preserving source markdown), which provides performance improvements.
Wiki: For an extensive period of time Wiki has been in stable maintenance mode. We are actively evaluating future opportunities by first understanding what our existing users are missing and enjoy the most. In FY24 Q2 we conducted a Problem Validation with an Opportunity Canvas and JTBD framework as the intended output. We are actively seeking to complete this Opportunity Canvas and finalize the JTBD in FY24 Q3.
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 drafted 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: 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 Multiple Versions Support
Rich Text Editor: Enabling the rich text editor across GitLab
Wiki: Finalizing JTBD for category and presenting opportunity canvas to product leadership.
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 will next work on 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 already made good progress in defining JTBD for the category and have honed in on our first priority for development (which will be 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)[https://about.gitlab.com/handbook/product/personas/#sasha-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.