Learning patterns/Working with a dev team from different timezones

A learning pattern foronline engagement

Learning Pattern Library

Working with a part-time dev team from different timezones

problemWorking with a part-time dev team from different timezones presents unique challenges that most full-time teams that work in person (or even remotely from similar timezones) don't usually face.

solutionHandling multiple discussions in an organized manner is crucial, Zulip is a good tool for this.

creator• Misaochan

created on08:17, 7 December 2021 (UTC)

status:DRAFT

What problem does this solve?

Working with a part-time software development team from different timezones presents unique challenges that most full-time teams that work in person (or even remotely from similar timezones) don't usually face. With the Commons Android app, our team of grantee software developers comes from all over the world - currently, our team lives in Australia, Turkey, and India respectively. This is compounded by the fact that most of the team works part time and have day jobs, so the odds of all team members being around at the same time is very low, unless we explicitly arrange for it to happen (and when it does happen, people are usually making sacrifices for it to happen).

Over the years, we have tried several methods of communication and project management, and some worked better than others.

What is the solution?

The most important factor to consider for an asynchronous communication/collaboration tool is that there will almost certainly be discussions on various topics at the same time, running in parallel. This is because, unlike synchronous communication, we cannot afford to finish discussing one topic before moving on to the next, as the discussion is likely to take place over days rather than minutes. So handling multiple discussions in an organized manner is crucial - it necessarily excludes simple chat tools like IRC or Hangouts.

We considered various collaborative tools, before eventually settling on Zulip. The benefits of Zulip that factored into our discussion are:

• Streams and topics provide a convenient and efficient way to discuss multiple topics at the same time without confusion.
• Easy to search previous conversations for a particular keyword.
• The full product is completely free to use for open source projects. When I contacted the Zulip team to request full access, the response was very quick and we had access to the full product in less than a day.
• Integration with GitHub and Travis CI. We are able to link GitHub pull requests and issues directly, be notified when one is created, and when a Travis build fails, etc. There is also integration with our Google Play Store reviews.
• Zulip itself is open source.

Arranging for synchronous communication to happen does have benefits - we are able to conclude discussions faster and more efficiently, and it also helps with team bonding. However, this needs to be weighed against the costs - whenever a meeting happens, someone will likely have to be staying up late, waking up early, or taking time off from their day job. We initially tried to organize meetings once a month, but eventually found that 2-3 times per grant was much more sustainable. Being able to meet in-person was extremely valuable, e.g. in the Wikimedia Technical Conference and Wikimedia Hackathons, but this was not a possibility after the advent of Covid-19.

Things to consider

• The extent of "difference" in timezones will likely have a huge impact on the ease of synchronous communication. Teams that are full-time will also likely have an easier time with synchronous communication, since there are more potential hours in the day to work with.
• Synchronous communication is more efficient by far, if the costs are not too high.

When to use

When you need to collaborate with a team of geographically-distributed members.

See also