| > There are plenty of things that happen on any company that have no relation to the code Some more details about our approach that addresses your concerns:
(1) for content changes unrelated to code, anyone (tech or non-tech) is able to open a new MR, and after approval it automatically gets merged into our reference branch and deployed
(2) for content changes related to new (unreleased) code, the input from non-tech people (e.g. customer support) is usually requested via an already existing merge request (via a mention), they can then add their input/content via gitlab's interface straight into the markdown files (and see a live preview), this way we ensure this sort of content goes live along with the code and requires no extra coordination > I am not telling you that what you are doing is wrong, but scalable it is not. I hope with my clarification above it makes more sense. > when you say "our use case": are you speaking on behalf on the whole company or just the tech team? On behalf of the whole company: we have a single product/platform that is continuously increasing in complexity, and it really helps to have a single process in order to maintain a knowledge base that covers as many aspects as possible (tech and non-tech). We believe this approach will also minimize replication of content across departments (facilitates cross-linking), and we're intending to also create an aggregated search (next to the individual search) across all categories of our knowledge base (product/engineering/support/sales/..), in order to more easily retrieve relevant content. > Beware the usage of the Royal We when you say "our use case" I am not implying this is set in stone, we (as a whole team) thought long about this flow, and for now it seems to work great, and I hope (responsible for maintaining this technically) that it scales up to some point far enough in the future. I'd say we were mostly inspired by Gitlab, they seem to adopt a similar approach, and that seems to be scaling quite okay over there :). We've noticed ourselves that the general "documentation mindset" has definitely grown among the team because of this specific process and the ease of adding content, updating content and retrieving content. |
As for Gitlab, their work processes are interesting, but I assume that most of the non-technical work there goes to issue tracker and the wiki? I am failing to see where there a strong connection to the code repository is required there.