Many of these considerations are similar to those you would follow on any project. It can be especially important, however, when not working amongst direct peers to be courteous of a community resource and the time those put into it.
1. Keep PRs lean.
Keeping commits made to a codebase clean can be extremely helpful. No one wants to parse through unnecessary, stylistic changes when spending their free time reviewing changes. If a pull request isn’t direct when addressing the point, you create opportunities for bugs to slip through and make the review that much more tedious.
Oftentimes, the changes you make are associated with a topic under discussion. By honing in the scope of changes made to target one specific goal, you also reduce personal development time while still submitting great, necessary work.
2. Associate your PR with an open issue.
As I mentioned in #1, associating a pull request with an open issue can significantly impact the organization, direction, and scope. It can also improve visibility and increase the likelihood of someone reviewing your work sooner rather than later.
For example, say a bug is “hot,” and people using an open-source tool or project need a fix. Then, there’s a good chance the community is already looking for someone to do that work (if they’re not working on it themselves).
By associating code changes with an issue, you also communicate implicitly that work is happening. It also directly lets the person(s) reporting know someone is working on resolving the issue.
3. Be patient.
The last piece of advice I have to offer is to be patient. Sometimes it takes a while for others to review and approve changes. Sometimes you’ll be stuck in a back-and-forth discussion for a while to ensure quality. Exercising patience allows everyone using open-source community tools to benefit from the worldwide insight and varying perspectives, making it even more worth it.