Working on issues
Frequent communication is paramount when working in a distributed open source team. Because our team is not located in one geographical location, we make heavy use of distributed workflow principles.
Assignment is ownership
If an issue is assigned to you, it is assumed that you are actively working on the issue.
The inversion of this assumption is important: if you are not working on an issue, please unassign yourself from it.
We will periodically remove assignees from issues that do not appear to have progressed. Don’t be alarmed; you can always re-assign the issue in the future once you begin work on the issue. We do this simply to avoid cookie-licking.
Post updates to issues early and often
We encourage posting to issues early and often. This has many noticeable effects:
- Combats cookie-licking.
- Encourages asking for help.
- Helps avoid getting “lost in the weeds”.
Some recommendations on communicating early and often:
I’ve started working on the issue
Explain your plan, what considerations you’re making, and how long you expect the work to take.
This is also usually when you’d assign the issue to yourself.
I’m considering changing the direction of my work
It’s rare that an issue is perfectly defined. When you find yourself changing the scope of what you’re working on (I need this new tool; this bug has bigger ramifications; I need to try a completely new approach), post to the issue.
I’ve started working on something else
Context switching happens. When it happens, post to the issue. If you expect to be focusing on something else for a while, unassign yourself. This allows anyone else to start where you left off.
I’ve gotten stuck, help!
Explain how you got stuck, what alternatives you’re considering, and whether you need help (use @ mentions to ask for help).
Randomly
Random updates to the issue are a helpful way to let others know that the issue is being worked on. We encourage sharing emoji stories.