Documentation process and/or channel
Closed this issue · 2 comments
As a Nitean,
I want an extensive documentation of what we have produced so far (cronly, vortex, DMon, etc),
so that we can use them or extend them easily.
Description
Some things which are pretty ubiquitous are kind of black boxes right now.
For instance recently I didn't know how to call the cronly malware function from the command line to check ~40 blogs out of ~120, it was not documented anywhere.
Zupo evoked an idea a few months ago : having a documentation channel on Slack, we would ask application/process specific questions in there and if nobody could refer to a link to get that question answered, that would mean we were lacking documentation about that and should create it.
Definition of Done
- 100% test coverage.
- Write/Update tech docs.
- Write/Update support docs.
- Write/Update Help Center article.
- Write/Update Intra/Handbook docs.
- Deployed.
Acceptance Criteria
- Create a "documentation" channel
- Invite everyone in it
I'm +1 for a #documentation channel (not two!). This needs to be added to Handbook also since it would be an important part of our process.
I think that whoever will need to write the most documentation will start to ignore #documentation. Documentation is not something you slap onto existing processes. It needs to be an integral part of processes.
What I am saying is, any question in any channel, that cannot be answered by a link to Handbook, Intra, tech docs, Help Center or our blogs, needs to become documentation. If someone helps you by giving you an answer, it is your responsibility to put that in the documentation. The best way to learn something is to try to explain it and/or to write it down. This way we combine both.