One of the reasons I love open source is because of the collaboration, community, and growth that often happens. Part of that growth includes having your pull request (PR) rejected. In fact, I think we should embrace this as part of the learning experience. To fully learn, you need to understand why your PR was rejected and what you can do to increase your chances of having your contributions accepted the next time you submit a PR. Below you'll find some of the reasons PRs are rejected.
Misalignment with Project Goals
I like to think of open source projects like a puzzle. Pull requests that are out of sync with the project's objectives are like a misplaced puzzle. Each pull request should contribute meaningfully to the larger picture the project is trying to achieve. Make sure you take the time to understand the project's scope, roadmap, and guidelines, so your changes fit into the project's vision.
Lack of Code Quality
Sometimes our code isn't strong enough to be merged in. Think of it like a foundation of a building. You want quality materials, and strong craftsmanship to ensure the strength of the building. Code that doesn't follow established conventions, lacks proper documentation, or contains bugs can undermine the stability and maintainability of the project. To build a solid structure write clean, readable code, adhere to coding standards, and provide comprehensive documentation if necessary.
Insufficient Testing
Often, projects require passing tests before a PR can be merged in. Submitting a pull request without testing is like releasing a product without quality control checks. Testing ensures the reliability of your changes and helps identify and prevent potential issues. Think of testing as stress-testing your contribution to guarantee it can hold up to real-world scenarios.
Poor Communication
Communication holds open source projects together. Submitting a pull request without a clear description or failing to address reviewer feedback is like sending a letter without an address or not responding to an email. Your ability to communicate demonstrates whether or not you'd be a good teammate, repeat contributor, or community member. Some tips for maintaining positive community include: provide context for your changes, respond to comments constructively, and demonstrate your willingness to collaborate effectively.
Violation of Licensing or Legal Issues
Including code that violates licensing restrictions or raises legal concerns in your pull request will result in an automatic rejection. Although I haven't personally seen this happen, it's worth noting and emphasizing the importance of respecting the project's chosen license and any legal requirements.
Duplicate PRs or Outdated Changes
This is one of the most common reasons I've seen issues or PRs rejected. Before creating a PR, ask to be assigned an issue to avoid both circumstances. If you want to raise an issue, check the project's existing issues and pull requests. Stay up to date on the repository and keep your fork up-to-date with the main branch of the project.
It's ok to not have your PR merged in. It might not feel great, but it's part of the journey. And thinking of it as a learning experience that will guide your next PR or the revisions of your current PR, is an important part of that process. If you have questions about the open source journey, check out opensauced.pizza or check out our Intro to Open Source course today.
Top comments (5)
Great, Blog.
Thank you!
Your PR gets rejected? How lucky!
(Recently I navigated around a lot of projects that had stale PRs that were never even answered, and in one case I had to use the github link to a fork that fixes a simple thing as the maintainer of the codebase just vanished.)
It’s rough when that happens. It’s hard being a maintainer, so there’s a lot of burnout.
That is super understandable and should not be in any way normal. Personally I think we should rethink open source with some kind of subscription service - in the age of almost daily discovered critical security vulnerabilities, we are past the date when hobby-engineering is enough.