3 ms·

Maybe the problem can be reframed? > the problem is more for processes. Things like "How do I create a build from my commit?" With well set up CI and automate

Maybe the problem can be reframed? > the problem is more for processes. Things like "How do I create a build from my commit?" With well set up CI and automated builds, would you need this documentation at all? Could other processes which you currently document also be automated? In my (limited) experience there's no great way to handle documentation, apart from reducing the need for it as much as possible. The team I'm on (as a PM, I'm not a programmer) used to use Confluence for almost all technical documentation, apart from the odd Readme file. We use it for product, product range and other team documentation too, which makes choosing sensible top level hierarchy difficult! I don't recommend trying this. But we finally have decent automated builds in place, and it's made a world of difference. We will soon have decent CI set up too (with Gitlab), at which point lots of project specific technical documentation will move to Gitlab wikis, living alongside the repo it relates to.

dalemyers 9y ago
> With well set up CI and automated builds, would you need this documentation at all? We have that. But how would you know that we have that without documentation telling you? How would you know where to find the resulting builds or to check the status?
- timlloyd 9y ago
  Fair enough. We currently document such systems details in Confluence, which I can't recommend for all the reasons given by others here. > We could have the documentation in a separate repository, but if we are going to be making this leap, we want to be sure we are using the right tools for the jobs. If you haven't considered this yet, it would be very easy to set up a Mkdocs[1] site for testing, using all of your existing documentation. Should be as simple as making a new site and dragging your current docs folder contents into the docs dir. It has good search built in with Lunr[2]. Try the Material theme[3] if looks are important. [1] http://www.mkdocs.org http://www.mkdocs.org [2] https://lunrjs.com https://lunrjs.com [3] https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/

dalemyers 9y ago

> With well set up CI and automated builds, would you need this documentation at all? We have that. But how would you know that we have that without documentation telling you? How would you know where to find the resulting builds or to check the status?

timlloyd 9y ago
Fair enough. We currently document such systems details in Confluence, which I can't recommend for all the reasons given by others here. > We could have the documentation in a separate repository, but if we are going to be making this leap, we want to be sure we are using the right tools for the jobs. If you haven't considered this yet, it would be very easy to set up a Mkdocs[1] site for testing, using all of your existing documentation. Should be as simple as making a new site and dragging your current docs folder contents into the docs dir. It has good search built in with Lunr[2]. Try the Material theme[3] if looks are important. [1] http://www.mkdocs.org http://www.mkdocs.org [2] https://lunrjs.com https://lunrjs.com [3] https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/