Go async-first with your team
Use the filters below to find async-first methods that are relevant to your team. For detailed articles, check out the blog.
Pull requests
Pull requests are a feature that most source control systems provide (GitLab calls it a “merge request (MR)”). This feature allows anyone who wants to contribute code to a project, to package their changes so someone else can review their code before merging it into the codebase.
Business decision records (BDRs)
By documenting every business decision you make for your project, you help your present and future colleagues understand the rationale of why things are a certain way for your team.
Commit messages
Effective commit messages are a way for developers to communicate to each other about the changes they’re making to a codebase. These messages can be useful when fixing issues or when finding the root cause of a bug or even when troubleshooting a broken build.
Architectural decision records (ADRs)
Your architecture will change with time and in the future you may have to investigate why your architecture is a certain way. Architectural decision records (ADRs) help by providing an archaeology of your project.
Meeting minutes
By going async, you’ll limit the number of meetings you have. For the meetings you keep, you must afford your teammates, present and future, the courtesy of a meeting summary; a.k.a meeting minutes.
“Go DEEP” with artefacts
Distributed projects are chaotic to run without artefacts. The DEEP acronym provides you a mnemonic to remember what to document.