What is the recommended style of knowledge sharing? This includes both product-related knowledge (“we used to do foo using bar in the past”, “we are handling this using foo 3rd-party service”) and development-related (“always prefer granular MQ poll-handlers”, “passing configs this way is considered legacy”, “the future way of implementing foo was agreed to be bar“).
In many shops there are multiple meetings with various team members during a day. Outcome of these meetings often concerns the whole project and thus should be saved & shared. The info often floats around in emails, meeting chat history, “new channels”, etc.
It’s certainly possible to force, for instance, code-standards via tools and a code-review process. However, the code-reviewing person still has to be kept up-to-date. Also many aspects should be prevented/avoided way earlier than during a code-review.
- A wiki(-like) solution effectively forcing a structural approach upon the knowledge base?
- Forcing one of meeting attendees to write the meeting outcome to a single structured knowledge base + updating all the related topics? This seems to be a time consuming chore.
- How to handle connecting the high-level (description in the knowledge base) with low-level (actual implementation in tickets/issues) intentions? Tickets/issues often get reorganized (split, merge, move, etc.) so simple issue-tracker hyperlinks would die soon.
- Weekly re-caps to keep everyone up-to-date? Adding a “big meeting” always sounds unproductive.
Are there any best practices?