When you have a popular repository on github, you can get a lot of Pull Requests.

Some of these are good, some need work and some should never be merged. As the maintainer it is your job to figure out what category each PR fits in to, work with the original author to fix any issues and finally do the merge.

But how do you decide what PRs should actually end up in the project?

The naive view would be to merge every feature. But what if that feature is only useful to one person? Is the person submitting that PR going to stick around to maintain their code in the future or (more likely) is maintaining that code going to fall to you? Is the feature even something that other users want?

Every change adds extra weight to the project that must be carried and updated when any refactoring is done. These features also add complication to the project that can hinder further changes. Sometimes the best change is one that makes the project more extensible without adding any features itself.

The way I deal with PRs that I’m not certain about is to let them sit. If someone else wants them they’ll hopefully come along and comment on them. Usually this works well, PRs that add or fix urgently needed things tend to have people on there asking for them to be merged.

Sometimes your PR won’t get merged or looked at because the maintainer has other things to do. The people who maintain projects on Github are people, they only have a limited amount of time in their day and they probably have a job they should be doing.

And finally sometimes the maintainer will miss the notifications so your PR never gets looked at. So don’t get too upset when things don’t get merged, wait a while

TLDR

Ways to help your PR be merged

• Explain why your change exists
• Add tests
• Fix build errors
• Change anything that is requested
• Bump it after a weeks in case the maintainer has missed it

Ways to help your PR not be merged

• Break the build
• Do a large amount of changes
• Include automatically generated files