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.