GitLab knowledge architecture

Problem

Modern organisations manage themselves across multiple dimensions (See https://gitlab.com/gitlab-org/gitlab/-/issues/351330#note_863518497). Hierarchies are too rigid to accommodate these needs. Full-on DAGs are often too confusing to adopt.

With the efficiency/opportunity afforded by namespaces on our backend, how might we structure GitLab's knowledge architecture?

• What factors are we optimizing for with our new knowledge architecture?
• Is adding/removing container object types (e.g. teams) a help or a hindrance for users? What might these look like?
• What is the MVC roadmap to transition to this new architecture?

Exploration

See Marcel's comment about Backstage: https://gitlab.com/gitlab-org/gitlab/-/issues/351330#note_863415639

Proposal

tbc

Resources

• https://fibery.io/blog/the-knowledge-organization/
• gitlab-com/Product#3842 (closed)

This 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.