Ben Balter’s article 15 rules for communicating at GitHub presents fifteen communication rules that GitHub employees follow to improve their overall workflow---rules that establish a communication strategy from which modern software development can greatly benefit.
| Resource information | Details |
|---|---|
| Article Title | 15 rules for communicating at GitHub |
| Author | Ben Balter |
| Focus | Version control |
From Ben Balter’s article 15 rules for communicating at GitHub, here are three that stand out:
Be flexible with tickets.
Many of us think of tickets as fully completed thoughts that require time and money to resolve. However, a ticket can be a question, a suggestion, an early idea that flowers into a great new feature, etc. A ticket is just the start of a conversation, and software teams can improve by cultivating an environment that promotes communication via tickets.
Asynchronous communication means that everyone can get involved in the conversation.
Instead of engaging a single @employee, you can engage the entire @team on a distributed and easy-to-track platform (such as GitHub issues). This opens up the conversation to whomever on the team is willing to get involved. This leads to another point:
Contribute to a discussion only if you have the time to give the communication the thought it deserves.
That is, put your money (time) where your mouth is. If you have thoughts on an issue, make sure you have the time to back them up. Otherwise, your comments can sidetrack or stall the conversation. As Balter says, “Avoid drive-by opinions.”
Finally, its worth reiterating that communication policies matter only if the team is dedicated to following them. There are many ways to break every one of Balter’s fifteen rules. For example, you can enforce PR reviews by locking the merge button without approval. But, this matters only if the team is dedicated to actually reviewing PRs instead of blindly approving them (say, because of lack of time). For communication policies to effect positive change, the team must understand the context of the rule--why it is needed or useful--and must agree to practice it. A team that can come together on a set of communication strategies can experience a significant boost in the pursuit of Better Scientific Software.
