This is an exploratory idea, not implemented yet — take it as a line of thinking only.
My company has a persistent headache: a large org with a mixed population and scattered knowledge often ends up with several teams building several applications for the same thing across several projects. Take workflow engines — we have three of them, functionally more or less identical, each developed separately by a different team on a different project.
The root cause is that knowledge and capability are locked inside each team and project group, with no effective shared knowledge base. And it’s not just developers — sales and pre-sales roles too.
What We Need a Knowledge Base For
Technical knowledge goes without saying: writing and reading docs is basic practice for programmers. But a project involves more than programmers. From the sales stage at the start to pre-sales solution design later, projects stay isolated from one another and no knowledge gets shared. Plenty of times a sales or pre-sales engineer spots a new standard or spec and wants to share it — but ask him to write a Wiki on GitLab? Basically impossible. Or expect programmers to watch some cloud document every day? Also basically impossible.
What they want from a knowledge base:
- Sales and pre-sales: to share what they see and learn in the simplest way possible — sending one email, say — not to write Markdown.
- Programmers: to share docs, code snippets, and case studies in Markdown
- Everyone: search, and preferably smart search, not title-only
How JH GitLab Fits
First, JH GitLab can receive email: Service Desk converts emails into issues and can notify our program via webhook.
Second, GitLab lets us write Wikis and .md files freely, on a familiar UI and flow.
Finally, JH GitLab gives us decent search and complete API automation.
My Idea
Write my own program to receive JH GitLab webhook notifications, fetch issue details through the JH GitLab API, check the content format to tell a URL from an attachment, fetch page content if it’s a link, then automatically create a Wiki or add a new .md file to the repo. Once content piles up, generate static files for browsing. For search, JH GitLab’s own search should mostly suffice.
A good reference case is JH’s own Handbook. But why not just copy it directly? Because JH’s own staff all use GitLab anyway, while we need to accommodate departments that don’t. Right now the best I can think of is sharing through Service Desk email; I haven’t thought of other channels yet. Anyone got better ideas?