We assume that you are working with a team on a product (more likely to be long-lived) as part of a project (more likely to be short-lived).

While working on a product (i.e. during the project), the team needs to communicate all sorts of technical and organizational information, much of which has a short half-life. Such short-term communication often occurs on an ad-hoc basis and is immensely important to the progress of project work and product development. Therefore, keep the barriers for this kind of documentation as low as possible: For project communication and documentation, avoid formalisms as much as possible. Clutter is fine here, as long as the people involved can understand the information and use it to support their current project work.

We call this part of the documentation volatile because teams need much of it only as support for their project work - and many of these topics are not even relevant for the permanent documentation of the system.

For the permanent documentation of the system, on the other hand, different standards apply: the rules of good documentation should apply here, a structure based on req42 and a minimum of order and consistency. A responsible person (the docu-gardener from tip B-1) should define this structure (according to req42) and fill it with appropriate content together with the team.

As the docu-gardener, you take over interesting and relevant documentation parts from the volatile (project) area as soon as their content has stabilized. If necessary, you or the original authors must adapt the form and/or notation to the needs of the product documentation. In doing so, however, observe tip B-2 (sparingly)!