The linked article is quite helpful. Especially the section about meetings is intriguing. Having a meeting with no set goal initially and all information present is never a good idea. It only leads to a follow-up meeting in the future.

The person who called the meeting is responsible for contextualizing the outcomes and porting relevant snippets to relevant GitLab issues and/or merge requests.

By placing this burden on the meeting organizer, it acts as a filter for whether or not a meeting is truly necessary.

I like this idea, whoever wants to have a meeting is also required actually to make sure the documentation afterward is present. And having a meeting where the outcome is not written down is too bad as nobody remembers its results.

A common frustration in large organizations — regardless of what stage of remote they’re in — is the chaotic splintering of communication. Projects frequently end up strewn across email, chat, text messages, unrecorded meetings, design tools, Google Docs, etc. While there are a litany of unified communication tools available which attempt to wrangle all of that, you’re best served by choosing a single system for communicating project progress.

Yep, all documentation needs to be at a single point. Otherwise, chaos ensues.

⤑ Embracing asynchronous communication