Pull requests often bring valuable changes or new features, and sometimes merging them is straightforward. But there are situations where I decide not to merge a pull request. Here’s why.
Features aren’t always missing by accident
When a pull request introduces an unexpected feature or changes the behavior of the software, it raises questions. There are usually reasons why the software doesn’t already include that feature.
If maintainers needed it, they would have added it. Your contribution might genuinely aim to improve the software for everyone, but without prior discussion, it can look like you’re trying to shift maintenance burden.
The hidden cost of pull requests
Contributors often submit pull requests to avoid maintaining their own forks. Forking creates work, so integrating changes into the main project passes that burden to maintainers.
Even if you care about your contribution initially, your involvement will likely fade once your need is met. Maintainers inherit the responsibility to support a feature they might not use, ensuring compatibility with future updates and satisfying users who rely on it.
This ongoing commitment blocks development of other features or requires trade-offs to avoid breaking changes.
Style, documentation, and compatibility challenges
Even well-intentioned pull requests introduce inconsistencies:
-
Coding Style: Open-source projects rarely enforce strict coding standards, but maintainers know the existing conventions. Your code may not align, leaving maintainers to rewrite it or accept an inconsistent codebase.
-
Documentation: Pull requests rarely update user-facing documentation. The contributor understands the changes, but other users need clear documentation. Maintainers end up writing it.
-
Cross-Platform Compatibility: Your pull request might introduce issues on platforms or configurations you didn’t test. Maintainers have to fix them.
-
Review Overhead: Reviewing pull requests takes more time than writing the code from scratch. A simple change can involve multiple rounds of feedback, conflict resolution, and testing.
Declining a pull request sucks
Behind every pull request is someone who invested time. Declining it feels personal. The work might be excellent, but if it doesn’t align with the project’s priorities or creates maintenance burden, it’s not the right fit.
Discussion before submission
Open an issue or start a conversation before submitting a pull request. This lets maintainers evaluate the idea and provide feedback before you do significant work.
Don’t take it personally
If your pull request isn’t merged, it doesn’t mean your contribution wasn’t valuable. It might simply reflect the challenges of maintaining a project over time.
Don’t take it personally if your pull request is declined or reimplemented. These decisions are made with the long-term health of the project in mind.