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-04-15 |
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.
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.
We recently finalized Jobs to Be Done (JTBD) for the category which help us to narrow down customer priorities. In 16.10 we released templates for wiki, and in 16.11 we are releasing autocomplete feature to connect Wiki pages to issues/epics.
In the past, even as of the March 2024 update, we covered extensively how we were not planning on working on collaborative editing. However, given the emphasis on this from users and insights from research, there is a clear need for collaborative editing within the platform. We've created a small POC as of 2024-04-15, and hope to begin testing this internally sometime in 17.x. There is still quite a bit of work to be done here, but we are moving toward a solution. The first place we would place collaborative editing would be within the Wiki.
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 Mainteance Mode, however, due to repriotization and a need for a competitive tool to compete against Confluence we have begun investing in this category. We recently completed advancements in our product via the introduction of templates and an autocomplete feature. We have plans to continue maturing the category, including completing Uncoupling wiki page slugs, filename and title which is one of the most outstanding Issues with the Wiki.
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 2024-04-15, is to continue addressing the identified JTBD for the category. This includes wiki advanced page permissions, page analytics, improved Confluence importer, real time collaboration, and page comments.