| title | tags | desc |
|---|---|---|
Better team communication |
teams teammates communication project management github remote software agile slack |
A few small rules for communicating with teammates while working on software & design projects. |
A few small rules for communicating with teammates while working on software & design projects.
Multi-tasking doesn’t actually work well.
Fully dedicating to a task will produce better & faster results.
Async communication prevents interruptions for dedicated tasks.
Write an Issue or it won’t get done.
Decisions shouldn’t be made in person—people need time to think.
Tasks shouldn’t be assigned in person—people will forget.
Reserve face-to-face communication for engaging with people: brainstorming, personal feedback, etc.
Issue or it doesn’t exist.
- Have a question? Open an Issue.
- Have an idea? Open an Issue.
- Something wonky? Open an Issue.
Issues are cheap, easy, permanent, searchable & linkable.
Too many notifications is distracting.
Contribute to Issues you can make in impact on—avoid drive-by comments.
Only comment if you have something to add—use “reactions” for support.
Always provide context in Issues, Pull requests & Commits: “A few edits” isn’t enough information.
Being obvious is always better.
If an Issue is blocked, use todo lists to mention the reasons—and whom.
Don’t close an Issue until it’s resolved.
Issues are a task that needs to be completed or a placeholder for a task.
Make Issues active: use a verb in the title.
Long-lasting Issues are completely okay if they still need to be completed.
Don’t dump everything into a single Issue.
Keep Issues as focused as possible—one single purpose.
If a concern enters the Issue’s discussion that’s not directly related, open a new Issue and guide people there.
It’s your obligation to find the URL.
People are busy, they shouldn’t have to dig around for the URL of the thing you’re talking about.
Pull request or it won’t get changed.
Everything should be reviewed by a peer before entering the master branch.
Create a pull request early to get feedback right away.
Pull requests are team property: the code isn’t yours it’s everybody’s to make better.
Polite, courteous, honest.
- Use well constructed sentences
- Remind people gently
- Don’t ping, just ask politely
- Overcompensate for tone
- Be human
Inspired & tweaked from “15 rules for communicating at GitHub”.
© 2016 Ben Balter
CC-BY-3.0