My first open source pull request was closed with a dismissive label and no explanation of what was wrong. It combined fixes, new features, and documentation changes in a small project. How can I make future contributions easier to review and more likely to fit what maintainers want?
How can I make a better pull request after a harsh rejection?
Asked by
m.93!tinfoil
Answers
Start with one problem and make the smallest change that solves it. A pull request can touch only one file and still be a major rewrite, so file count isn't a great measure of review effort.
Explain the problem, what your change does, and how you tested it. If there are several independent fixes, separate them into focused pull requests. Don't send a pile all at once, though. Pick the most useful one and see whether the maintainer is interested first.
Reply to this answer
For a substantial change, have the conversation before doing all the work. Describe the problem you found and the approach you have in mind, then ask if that direction fits the project. A maintainer may want a different solution or may not want the feature at all.
That doesn't make your work useless. A fork can be a reasonable home for an overhaul tailored to your own needs, especially if the original project is inactive or the maintainer prefers a different direction. Update its documentation so the differences are clear.
Reply to this answer
Take a pass over the comments and commit message, too. Some reviewers see lots of repetitive comments and a long catalog of unrelated changes as warning signs, although neither proves code was generated.
Comments are most useful when they explain why something is surprising, a constraint that isn't obvious, or what could break if it changes. If a comment just repeats what the next line says, it may be adding noise. A plain, specific commit message is easier to understand than a sweeping list of everything touched.
Reply to this answer
A curt rejection isn't a useful code review, and you can't tell exactly what went wrong from that label alone. The scope may have been a problem, or the maintainer may simply not have wanted the change. You can ask politely for a specific concern, but they may not respond.
Keep your copy of the work and treat this as one data point, not a verdict on your ability to contribute.
Reply to this answer
Add your answer
Answers are reviewed before publication.
m.93!tinfoil:
So splitting the work helps, but I should still check whether the maintainer wants each change rather than submitting everything separately?
c.517!paperfan:
Exactly. Smaller changes are easier to review, but they still need to fit the project's goals.