<!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *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.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> ### Problem to solve Wiki pages have a single conflated notion of identity - they have a `title`, from which we generate a `slug` and a `filename`. This has a few issues of its own: - Some titles get mangled - Users cannot select their own slugs - Page renames break old links - Page renames break the history (we lose the ability to find old versions) More importantly it has performance and design implications for application developers: - the sole datastore is git, accessed through gitaly. This does not have the advanced query features of SQL - getting a page listing is expensive - filtering page listings is expensive/impossible - finding the pages in a directory is expensive/impossible We want to separate out these concerns, but preserve the git datastore and the ability for users to create files locally and push them to the app. ### Proposal We should allow wiki pages to specify metadata, which we keep in sync in the `WikiPage::Meta` records we now store in the DB and in front-matter blocks in wiki-pages. These will allow us to (gradually) transition to a world where a page may have a distinct `filename`, `slug` and `title`, with complete control over all of them if required. For this we need: - Storage of metadata outside git (done: see `WikiPage::Meta`) - Synchronization of metadata for UI actions (done) - Synchronization of metadata for git access (see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/26624) - Backfill of metadata records for existing wiki-pages - Import/export of metadata - Ability to specify slugs (and maybe filenames) in the UI - Ability to specify titles and slugs in the git repo (see https://gitlab.com/gitlab-org/gitlab/-/merge_requests/27706) Down the line we would want to use this to: - avoid changing filenames, or keep track of old filenames so that page history is preserved over renames. - allow multiple slugs to map to a page, using alternative slugs listed as non-canonical. When we route from these, we should have a notice on the page to inform the reader - Use old slugs to redirect readers to the current slug - Replace page listing APIs with DB calls ### Intended users I would also propose that this affects personae we don't have: - "Wendy (Wiki author)" - "Wallace (Wiki reader)" ### Documentation We need to add user facing documentation about how to use the front-matter sections, and documentation for using slugs. ### What does success look like, and how can we measure that? We would expect that success might mean greater performance on wiki pages, the ability to deliver features we cannot yet provide, and higher usage. ### What is the type of buyer? Presently wikis are a Core feature. Some features we might consider for premium: - redirecting old slugs - page aliases (one page owning more than one slug) - graph-like features, such as in/out links ### Links / references