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-12-04 |
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. We are presently 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 introduce commenting on wiki pages.
One of our primary personas 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.
Another of our primary personas is Parker, the Product Manager. Product Managers require a place to develop, organize, and share their knowledge, and a wiki is often considered a perfect location. Leveraging templates, autocomplete connection of Wiki pages to GitLab Issues and Epics, Product Managers can seamlessly plan and develop their ideas using the GitLab wiki.
Last fiscal year we finalized Jobs to Be Done (JTBD) for the category which help us to narrow down customer priorities. Some recent items that we've completed as a result include, improvements to the wiki sidebar, separate wiki page title and url fields, and improved wiki user experience.
Next we will introduce comments on wiki pages. Comments provide an avenue for effective discussion, questions, and collaboration, and ultimately allow projects to move forward more efficiently.
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 9 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. |
| Knowledge Documenter | When I am reviewing a Page I want to be able to comment my thoughts on improvements or ask questions related to the documentation, so I can improve my own efficiency and the efficiency of the organization. |
We are actively working on maturing the Wiki category. In the past the category was in maintenance mode, however, due to reprioritization and a need for a competitive tool to compete against Confluence we have been actively investing in the category. We recently completed advancements in our product via the introduction of templates and an autocomplete feature. We are using our JTBD Epic to drive progress forward for the category. Please take a look at that Epic to view some of our priorities.
We compete with the following knowledge management tools (not and exclusive list):
GitLab does not primary leverage a wiki for knowledge management, but instead leverages GitLab Pages functionality. Knowledge Group within Plan Stage 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. One Issue that we could wrap up that would support more dogfooding could be comments on wiki pages. Comments provide an avenue for effective discussion, questions, and collaboration, and ultimately allow projects to move forward more efficiently.
Our top strategy item is to continue addressing the identified JTBD for the category. This includes wiki advanced page permissions, page analytics, improved Confluence importer, and real time collaboration.