How can you get your PR merged less than 10 comments?
I’m a contributor for some OSS GitHub repositories. However, when I write a PR, I usually get a lot of comments and take time to fix that. I notice that super cool developers get merged very quickly with a few comments. I ask them the secrets. I want to share what I learned.
I introduce you to 7 tips to get your PR merged less than ten comments.
Tip 1. Follow the Guidelines
Tip 2. Static analysis tools
Tip 3. Style of the code in the repo
Tip 4. Small
Tip 5. Visibility
Tip 6. Spell checking
Tip 7. Respect the repo owner
I hope you enjoy these.
Tip 1. Follow the Guidelines
The first step is to study the guidelines. It depends on the languages and what the repo builds. For example, I contribute a repo of Durable Functions which is an extension of Azure Functions that is Serverless platform. C# library project. In this case, you can refer to the Framework Design Guidelines.
This guideline is old; however, it is still essential and valuable. Many other senior developers also study this and expect people to understand these principals. You can find similar guidelines for your target repo.
Tip 2. Static analysis tools
Always use static analysis tools when writing code. This tool will train you to use a consistent coding style and also follow best practices. In my case, it will be the StyleCop and FxCop which is integrated with Visual Studio. Also, ReSharper helps me a lot.
Tip 3. Style of the code in the repo
A lot of senior developers mention the importance of this part. To minimize the number of comments related to style or formatting, the experts do their best to match the style/formatting of the surrounding code. It is not about general coding practice. The local style of the repo. You might have your coding style. Sometimes, you might found that the coding style of the repo is old fashioned. You might see that your coding style looks much cooler. However, some expert recommend me to be like the repo owner. If your code shows that your coding style and it is different from other code, it will be the “smell” of the refactoring. I was surprised that a repo owner commented to me that “You can’t use private.” The consistency of a repo is critical to understand the repo not only for the owner but also for other contributors.
Tip 4. Small
Imagine if you were a repo owner. You receive a lot of issues and PRs every day. If you have a big PR, if it is an exciting one, they might try to review it. However, even if the exciting one, reading a lot of code might be tough. Also very hard to imagine if it successfully works. You don’t need to implement all feature at once. Rather than a perfect big PR is coming, you can create several PRs that contains one objective. It is less risky to merge and easy to review it. Also even if something wrong happens, the repo owner thinks they can handle it.
Tip 5. Visibility
If the repo owner thinks you are reliable, your PRs will be merged quickly. If you help to answer the question from the users, to organize the issues, and submit PRs, it will help the owner to understand your skill level and personality.
Tip 6. Spell checking
This tip is for the second language learner of English. For me, one of the most challenging parts is writing a comment. I follow the style; however, it still requires some skills to write it in English. Proper word choice is very tough for second language learners. Use Spell/Grammar checking tools. You need to care the comment style consistency as well. I use Grammary for it.
Tip 7. Respect the repo owner
As I wrote, a repo owner is busy. They might get a lot of issues and PRs every day. They have priorities that are different from yours. Think about how to reduce their workload. Read the Contributor’s guideline, writing a unit/integration/e2e test if they exist. Automated Testing and CI helps the owner has confidence for the safety of the PR. One of my master sensei gives me advice. Rebase your commits before the PR. It helps to reduce a lot of ugly “fix typo” commit logs. Proper comment of the PR might help to understand the overview and tag it to the related issues and PRs. For a big PR, you can start with an issue to discuss the spec of the PR with the repo owner before start writing your PR.
This article help to understand what they think.
Conclusion
Generally speaking, it requires a lot of experience and understanding the expectations of the repo owner. However, I hope these tips to help you to accelerate your PR getting merged quickly and reduce the repo owners workload. If you still have a lot of comments, don’t worry about it. One of the best programmers in my life confessed that he recently had got over 60 comments. He got re-write whole PR for other PR. The best programmer in the world could have it. However, a lot of his PRs do get less than ten comments are merged quickly. You’ve got the secret already. If you have any other secrets for getting merged PR, please leave your comments on this post.
Enjoy coding.
Special Thanks
This article borrows a lot of ideas of the experts. What I did was, I interview them, ask them questions. I want to be the one who can quickly have done my PRs without any comments! I just learned from them and compile what they think. I appreciate all the contributors to my questions. Especially @cgillum and @peterhuene gave me a lot of insights. @xin9le, @sato_ryu, and @mumoshu give me fresh ideas. @ricardoserradas, @yu_ka1984, @shibayan, and @yoichiro give me a comment as an expert point of view. @azurekanio gave me some tips for effective PR.
All names are twitter handles.