3 ms·

Your problem (just about everyones problem) is the same problem. If you did it, document it. Make sure that what ever tool your using for documentation suppor

Your problem (just about everyones problem) is the same problem. If you did it, document it. Make sure that what ever tool your using for documentation supports full text search, and tagging.

OJFord 8y ago
> what ever tool your using for documentation supports full text search, and tagging. Any suggestions?
- iliaznk 8y ago
  nVALT
- eropple 8y ago
  Basically any wiki should suffice for those requirements. However, integrating those requirements with other workflows tends to be trickier. Atlassian's tools (Jira, Confluence, etc.) tend to win by default, but if you're willing to do some duct-tape work other solutions are fine too.
  - OJFord 8y ago
    Harder to keep in sync though, if it's not somehow derived from or embedded in the source code for the scripts.
- NickBusey 8y ago
  mkdocs with Material Theme. https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/ This way documentation changes go through the same code review process as actual code, and actual code pushes can be linked directly with changes in documentation.
- parthdesai 8y ago
  Maybe try this? https://slab.com/about https://slab.com/about
superfrank 8y ago
> If you did it, document it. You can document all you want and it won't matter if no one is looking in the right place. I think that is really the root of OPs question. At the companies I've worked at, I've seen utility scripts stored in the main repo with the code, in their own repo, in a gist, in confluence, in Google docs, and in OneNote. Often the same company is using more than one of these at the same time. It's like one person gets fed up with the current solution not doing what they want and decides to create their own standard. BTW, I'm not condoning any of these, it's just what I've seen over the years. I'm a firm believer that if you give people a solution that is easy to use and meets their needs, eventually they will gravitate toward it. On the flip side, if a solution is complicated or useless, they will eventually stop using it, even if it is company mandated. From what I've seen, all these solutions are either overly complicated or don't fully meet a companies needs. I think OP is looking for suggestions of tools that other people use and like, so they can try it on their team.

Your problem (just about everyones problem) is the same problem. If you did it, document it. Make sure that what ever tool your using for documentation supports full text search, and tagging.

OJFord 8y ago

> what ever tool your using for documentation supports full text search, and tagging. Any suggestions?

iliaznk 8y ago
nVALT
eropple 8y ago
Basically any wiki should suffice for those requirements. However, integrating those requirements with other workflows tends to be trickier. Atlassian's tools (Jira, Confluence, etc.) tend to win by default, but if you're willing to do some duct-tape work other solutions are fine too.
- OJFord 8y ago
  Harder to keep in sync though, if it's not somehow derived from or embedded in the source code for the scripts.
NickBusey 8y ago
mkdocs with Material Theme. https://squidfunk.github.io/mkdocs-material/ https://squidfunk.github.io/mkdocs-material/ This way documentation changes go through the same code review process as actual code, and actual code pushes can be linked directly with changes in documentation.
parthdesai 8y ago
Maybe try this? https://slab.com/about https://slab.com/about

superfrank 8y ago

> If you did it, document it. You can document all you want and it won't matter if no one is looking in the right place. I think that is really the root of OPs question. At the companies I've worked at, I've seen utility scripts stored in the main repo with the code, in their own repo, in a gist, in confluence, in Google docs, and in OneNote. Often the same company is using more than one of these at the same time. It's like one person gets fed up with the current solution not doing what they want and decides to create their own standard. BTW, I'm not condoning any of these, it's just what I've seen over the years. I'm a firm believer that if you give people a solution that is easy to use and meets their needs, eventually they will gravitate toward it. On the flip side, if a solution is complicated or useless, they will eventually stop using it, even if it is company mandated. From what I've seen, all these solutions are either overly complicated or don't fully meet a companies needs. I think OP is looking for suggestions of tools that other people use and like, so they can try it on their team.