Wiki functionality is substandard
A wiki page is a better tool for product requirements than an issue, because features need ongoing tracking. Unlike buts they don't get finished and disappear. However wiki pages on gitlab leave a lot to be desired. It is not on par with other widely used wikis.
Problem to solve
Wikis are a crucial tool for project management. In particular they are excellent for documenting requirements. Issues are not a fit for requirements because they are designed to be closed rather than updated.
However the wiki at Gitlab is not ready for prime time, which forces developers to find tools outside of Gitlab, and these tools have poor integration with gitlab teams, issues, pipelines and boards.
Target audience
A product manager documenting requirements for developers.
A QA person maintaining functional test documentation.
A security analyst defining threat models for developers and product managers.
Proposal
- The URL of an article changes when you change the title, so links break. There is no method to restore the previous link, so you can't unbreak them. There is no tool to find inbound links, so you can't fix them.
- In Page History the commit hash (like 51d78fe4) is linked to the original page, not the page in history. There is no way to see prior versions rendered as HTML. You can't get back the markdown, you can't compare them, and you can't restore them.
- There is no way to get a diff between two different versions of a page, which can be a big obstacle. For example, on a wiki page being used for requirements, the PM may add a requirement and a programmer needs to be able to see what is new.