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 |
| Maturity | Viable |
| Content Last Reviewed | 2024-01-08 |
Thanks for visiting the Wiki category direction page in GitLab. This page belongs to Knowledge group in Plan Stage. This page is maintained by Knowledge group PM Matthew Macfarlane (E-Mail). More information can be found on the Knowledge group direction page.
This page and associated strategy are a work in progress, and everyone can contribute to it:
The GitLab Wiki is a great place to store documentation and organize information, and an alternative to tools like Confluence and Notion. Each GitLab project and group includes a Wiki.
We want the wiki to serve as a single source of truth for project and group-level documentation that is approachable and easily accessibly by anyone. As we look to future plans, we will be exploring ways to encourage collaboration across all personas by improving the editing and navigation experience.
Specifically, we are looking to better integrate the wiki experience with the rest of GitLab. One immediate opportunity is to better integrate with Issues and Epics.
Our primary persona is Sasha, the Software Developer, but all personas can use wikis for storing information. Everyone should be able to quickly and easily contribute to a wiki page. As the wiki matures we may need to investigate other non-developer personas as our research found they are frequent users of wikis.
We recently finalized Jobs to Be Done (JTBD) for the category which help us to narrow down customer priorities. We are now conducting a Spike in milestone 16.9 on the top two identified JTDB.
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.
A Job to be Done (JTBD) is a framework, or lens, for viewing products and solutions in terms of the jobs customers are trying to achieve. It's about understanding the goals that people want to accomplish. It lets us step back from our business and understand the objectives of the people we serve. It opens the door to innovation.
At GitLab, we have our own flavor of JTBD and use it throughout the design process, but most notably to:
JTBD come directly from research and customer conversations with those people who do the tasks/jobs we need to design for. Problem validation is one of the most effective ways to confidently inform the writing of a JTBD.
For wiki category we've identified 8 core JTBD after two research studies. The following Epic provides additional details about the construction of and research behind Wiki JTBD.
| Job Performer | Description |
|---|---|
| Knowledge Consumer | When I am writing code, I want to find knowledge related to common roadblocks, so that I can minimize the likelihood of a security incident and increase development efficiency. |
| Knowledge Admin | When I am onboarding a new colleague, I want to ensure they are provided the right view and edit permissions related to knowledge we have stored, so I can minimize the likelihood of a security incident or release of material non public information. |
| Knowledge Documenter | When I am conducting a retrospective, I want to document the situation in a manner consistent with other retrospectives, so I can ensure colleagues are easily able to understand the situation and path to resolution. |
| Knowledge Admin | When I am reviewing knowledge my team is consuming, I want to review which assets are utilized the most, so I can ensure the content most digested is accurate and providing insights that create informed decisions. |
| Knowledge Consumer | When I am examining open work items for my engineering team, I want to review the knowledge documented for each item, so I can understand the broader context around prioritization and background knowledge for resolution. |
| Knowledge Admin | When I am tasked with importing knowledge from what tool to another tool, I want to efficiently view what knowledge has moved, so I can ensure that no knowledge was lost in transition. |
| Knowledge Consumer | When I am on call, I want to understand who created the documentation in the knowledge base, so I can easily reach out to them if the incident becomes critical. |
| Knowledge Documenter | When I am reviewing a document, I want to understand who is actively contributing to the documentation, so I can ensure I do not overlap with their changes and am more efficient with my efforts. |
Wiki transitioned from Create Stage to Plan Stage in GitLab in early FY24. The future direction of Wiki, as a result of this transition, is being evaluated. Prior to this change Wiki was in Maintenance Mode.
We compete with the following knowledge management tools (not and exclusive list):
GitLab does not have any organization-wide wikis, but some teams do use them for various purposes.
Knowledge group utilizes the GitLab Wiki for Opportunity Mapping via the recent introduction of diagrams.net. More information can be found on this integration via our Unfiltered channel.
Our top strategy item, as of 2023-12-04, is to understand the existing state of the Wiki and if we can accomplish the JTBD we've identified and mentioned previously. We are conducting a Spike on the Wiki Code in FY24 Q4 to create a POC for two of the JTBD, and understand if the other six would be feasible with the Wiki in its given state.