Ideas for improving async communication on Purchase team
Since the Purchase team is geographically dispersed, asynchronous communication is even more important to work effectively. For this reason, I would like to open discussion on improving in this area. I have a couple ideas, but we can expand on this list.
1) Provide concise and actionable summary before going into details
Since we are often required to keep a large number of issues in progress simultaneously, it can be difficult to parse important information from dense comments and issue descriptions, to determine if the comment is actionable. Before going into details about an issue, provide a summary as to why it is important
2) Provide time to prepare before synchronous meetings
If we are going to discuss a topic synchronously, document the topic and notify those who maybe interested in the topic well in advance of the discussing synchronously. This will allow valuable synchronous time be be used more wisely
3) Read previous comments before rehashing a topic
Keep conversations efficient and prevent them from going in circles, review the previous conversation before adding additional comments. If something is unclear in the previous conservation, quote the unclear example and request clarification from the author
4) Move off topic or orthogonal topics to a separate issue
At times it seems discussion in issues grows to encompass solving all related problems. Issues should be well targeted to a specific problem or feature request. If the conversation meanders outside the bounds of problem at hand start a new issue to discuss the additional problems
5) Keep issues' descriptions up to date
Especially for an issue with many discussions, it is hard to go through each of them to understand the latest status of what action is required for the issue. Regularly updating the issue's description can help people get key information quicker.
6) The title of the issue should describe the problem and not the solution
In engineering it can be tempting to jump to the solution when considering a problem and use the solution as a title of the issue. We should avoid this temptation and instead focus on problem when giving an issue a title. This allows other readers to understand the context of the solution without reading the entire issue.
Also skipping to the solution may prevent us from thinking about other solutions and limit creativity. Also see the handbook entry on the topic: https://about.gitlab.com/handbook/communication/#issues
7) Follow the issue template format
When creating issues, following the outline provided by the issue template. If you feel that the template does not apply to issues we typically create, then let's propose and discuss updating the templates.