Working in large groups of people who are all in different timezones can be challenging at first but it doesn't have to be. There are ways around this, some of the solutions that I have seen working in the wild quite a lot are
- Asynchronous communication
- Clear project goals
- Elaborate issue templates
When we are working across timezones we should look at asynchronous communication as a first solution, this means no contributor has to accomodate for other timezones to have a call, ... However to do this well we'll need to be very explicit, everyone understands concepts differently, some are visual learners, some need examples and some can derive concepts just from text. When we review/draft up responses we should keep in mind that the person reading next or an external person coming into the issue could be missing context. Linking to other issues, using examples, ... will ensure that you're all on the same page.
Next up in the communication department is how you review code, we can all get attached to the code we're writing so it isn't fun if a reviewer swoops in and bashes on this little nit, keeping feedback constructive and accessible is key to being a good reviewer. Personally, I try to explain the comment I'm making as well so the person can follow my thinking when they read my review and won't think I'm just trying to stop their PR.
Last of all, providing context for a PR can be hard as you've been through the code and bringing others up to speed in a similar way is hard. Good pull request descriptions are an art and if you don't feel comfortable you can try contextualizing the PR by leaving comments on relevant pieces of code, this can help reviewers understand why you've gone on a thinking path and they can level with you and help with an alternative solution or see why your solution is good.
Goals are one of the most important things when on-boarding new users, when people can see what we are making, why we're making it
and how we're making it a lot of question marks can dissapear even before checking out the code/examples/... this is a form
of asynchronous communication and often will come in the form of a README.md and a CONTRIBUTING.md these files will explain
the project and important pieces like setting up, changelogs, publishing, ... an important part of a project is to be as accessible
as we possibly can to new people as that's how a project grows, many hands help ease the burden of maintenance.
Another way to be as accessible as possible, this is quite opinionated, is to leverage project templates to their best capacity. The
easiest project I've been a part of to maintain has had a pretty strict flow for suggesting features. We outline in the CONTRIBUTING.md
that people need to create an RFC before implementing
a feature, this way people who have similar needs can come in and respond as well as people who are looking for this feature can come
in and see the reasoning behind it, having this trail prevents a lot of issues being created and a lot of duplicate replies.
One last thing that has helped us as well is using issues exclusively for RFC's and actual bugs (only ones with a reproduction) while
using discussions for usage questions, ...