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 focuses on three categories, Wiki, Pages, and Content 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 GitHub.
This direction page is a work in progress, and everyone can contribute.
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 is aligning its strategy against the organizational theme of improving product usability in order to contribute to this vision. Most specifically, Knowledge Group is aligning priorities to improve GitLab's enterprise planning workflow. A breakdown of priorities by category can be seen below:
Pages: We recognize Pages as a popular feature and one that people really enjoy engaging with as part of the GitLab experience. It exists at the intersection of multiple stages of the DevSecOps lifecycle: Create, Plan, Verify, Package, and Release. Our priority for Pages is to provide an experience that guides and supports users to host static assets on the web, regardless of your 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.
Content Editor: Within the Content Editor category we have three priority buckets aligned with the theme of improving product usability. Those buckets are, creating feature parity with current editing experience, frontend deserializer or mapping markdown editing to content editing output exactly, and other related items to editing text including new features. The first bucket, creating feature parity with the current editing experience, involves introducing the content editor in comments, replies, issues, MRs, and Epics. The second bucket, frontend deserializer, focuses on preserving source markdown. An example of this is when you edit a small portion of a large document only that little portion should change relative to the whole. The last bucket, other related items, focuses on features such as adding support for text editing features not yet present, aligning text, RTL support, editing footnotes and reference style links.
Wiki: For an extensive period of time Wiki has been in stable maintenance mode, we are actively evaluating future opportunities here by first understanding what our existing users are missing and enjoy the most. As we look to future plans, we will be exploring ways to encourage collaboration across all personas by improving the editing and experience of navigating wiki content.
Pages: Evaluating 1 year plan for Pages.
Content Editor: Evaluating 1 year plan for Content Editor.
Wiki: Evaluating 1 year plan for Wiki.
Pages: Transition GitLab Pages to Object Storage Instead of NFS, Kubernetes Deployments for GitLab
Content Editor: Display and Edit Markdown Comments in the Content Editor, Insert Table of Contents in the Content Editor
Wiki: Editing Sidebar in Project or Group Wiki Removes Existing Sidebar,Relative Links are Broken On Wiki ASCII Pages
Pages: GitLab pages deploys greater than ~15MB fail sometimes with pages:deploy - PG::UnableToSend: no connection to the server, 404 errors on application start, Lookup Pages Sites by the Unique Domain
Content Editor: GitLab Flavored Markdown extensions for Content Editor
Wiki: No active issues in development as of Milestone 15.10.
Pages: Evaluating future priorities for Pages.
Content Editor: Evaluating future priorities for Content Editor.
Wiki: Wiki was recently transitioned from Create Stage to Plan Stage in GitLab. The future direction of Wiki, as a result of this transition, is being evaluated. Prior to this change Wiki was in Maintenance Mode.
This section of the Knowledge Group page is currently in progress for Page and Content Editor as we evaluate which aspects we want to prioritize and not prioroitze moving forward.
Wiki: 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.
Knowledge Group Competitive Statement: As state prior, the focus 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, Content Editor, and Wiki catgories 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 the 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.
Content Editor: Content 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 Wikis 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, Content Editor, and Wiki: We are actively evaluating the maturity plan for Pages, Content Editor, and Wiki.
Pages, Content Editor, and Wiki: Our primary persona is Sasha, the Software Developer, but all personas can use Wiki, Pages, and Content Editore. As these categories mature, we may need to investigate other, non-developer personas as our research found they are frequent users.