You have just coded, implemented, and submitted a pull request. A short while later the request is declined by an upstream maintainer and you feel crushed. We have all been there. Today I'm going to show you a better way. This article will teach you how to create pull requests that get approved.
You need to earn trust with the maintainers. Your first commit should be a small change which they cannot reject. Try to write a missing test or re-factor duplicate code. Correct a comment's accuracy or rename a variable to better reflect its purpose. Your first pull request should not alter how the program works.
Additional whitespace will alter the diff output. This causes version control systems to flag lines as changed which is irritating and sometimes misleading.
Minimize the number of changes to accomplish your goal. People are busy and at times lazy. Reduce the work the maintainers must do to perform a merge. Lowering the amount of lines to review should increase the chance of approval.
Do not break the program, only commit working code. If the project has tests make sure they work before you commit.
Try to mimic the maintainers. Follow the coding style and project layout even if it seems wrong. This is not your playground... yet. Before you commit, review the VCS logs to learn how verbose or terse your commit messages should be. When in Rome do as the romans do. This silly game of follow the leader reduces friction of an outsider committing to the project.
Write about the change, give reasons and examples. Include a link to your blog post in the pull request.
If you were writing an essay, you would split up your ideas into separate paragraphs. A pull request has many qualities similar to a paragraph. Each commit should be related to the pull request's main objective. Commits of a pull request should stay focused and on topic.
A pull request is to a program as a paragraph is to an essay.A commit is to a pull request as a sentence is to a paragraph.
In an essay, if you have more then one topic you should have more then one paragraph. Likewise when coding, only one idea or change per pull request.
Separating your ideas into different pull requests will grant the maintainers greater flexibility when they begin to integrate. They will have the ability to pick-and-choose which requests to merge and everybody wins!