Approach to Documentation

The general approach of WARG is that nothing needs to be documented until we have an issue or foresee having an issue. As we are growing and most of our members are new to their positions this ends up with lots of things requiring documentation. Documentation is also a great resource to prevent having to repeat yourself and facilitate the onboarding of new members to the team!

Documentation is not meant to be set in stone. It’s meant to be discussed and improved upon over time. If possible adding reasoning and justification to documentation is an excellent way to reinforce the knowledge! This is specifically applicable to the documentation of policies which may be frequently questioned. On the other hand, technical documentation for a system requires little if any justification.

Documentation is not meant to be a punishment. Try to work it into your normal workflow instead of delegating itself as a separate task to be done before or after something else as much as possible. For example, as you are figuring out how a new relevant system works we would recommend documenting links to relevant resources to facilitate others learning how the system works in the future. Another example would be if you’re working on getting a license for something then simply as you’re working on it aggregate the appropriate links into a document.

Documentation doesn't need to be paragraphs on paragraphs of perfectly written sentences. Often times it is merely a few photos of a whiteboard, or a series of links to other resources, or a few bullet points strewn together. The goal is to put in the minimal amount of documentation effort into the documentation and get the maximum result of helping others in the future!

This policy is heavily related to Confluence & Individual Reliance which should be read for reference.