I've struggled with this personally at our company. A sibling comment mentioned a README for each project/process. That's definitely a solid start for building this up from nothing. Copy open source project README files:
1) what is it? (A web project, an automation script, an ansible deployment repo?)
2) what dependencies do I need to run it? (Make, NPM, Java 1.8?)
3) how do I run it? (docker-compose up? make && ./a.out?)
We started with this. Then for the bigger projects/monorepos, we started adding README files in relevant subfolders.
Recently I've been converting these README files in the larger projects into mkdocs subfolders that get hosted in our repository tooling (GitHub/GitLab pages).
Start small. Go slow (if it's institutionally difficult). Build up to more complexity as you get more written material to work with.
I've started creating an "index" project, that links to all the projects that have documentation.
And finally, focus on the pain points first. One of our monorepos was fiendishly difficult to deploy correctly, either locally or in a test / production environment. The very first tutorial I wrote was setting up that environment in a step-by-step, repeatable manner, and it's by far the most oft-used documentation we have. With that out of the way, I can focus more on the esoteric details (and, yes, unfortunately, it's a bit of a thankless, "skunk works" project, but it's worth it)
1) what is it? (A web project, an automation script, an ansible deployment repo?)
2) what dependencies do I need to run it? (Make, NPM, Java 1.8?)
3) how do I run it? (docker-compose up? make && ./a.out?)
We started with this. Then for the bigger projects/monorepos, we started adding README files in relevant subfolders.
Recently I've been converting these README files in the larger projects into mkdocs subfolders that get hosted in our repository tooling (GitHub/GitLab pages).
Start small. Go slow (if it's institutionally difficult). Build up to more complexity as you get more written material to work with.
I've started creating an "index" project, that links to all the projects that have documentation.
And finally, focus on the pain points first. One of our monorepos was fiendishly difficult to deploy correctly, either locally or in a test / production environment. The very first tutorial I wrote was setting up that environment in a step-by-step, repeatable manner, and it's by far the most oft-used documentation we have. With that out of the way, I can focus more on the esoteric details (and, yes, unfortunately, it's a bit of a thankless, "skunk works" project, but it's worth it)