Understanding Why Pull Requests Get Rejected in Open Source Projects
Tags: opensource, codenewbie, webdev
Published: 2023-06-01 12:57:00

---
title: Understanding Why Pull Requests Get Rejected in Open Source Projects
published: true
description: Uncover the common reasons why pull requests face rejection in open source projects. Explore misalignment with project goals, code quality issues, testing shortcomings, communication challenges, licensing violations, and the impact of duplicative or outdated changes. Enhance your understanding of open source collaboration and increase the chances of having your contributions accepted.
tags: opensource, codenewbie, webdev
cover_image: https://dev-to-uploads.s3.amazonaws.com/uploads/articles/7vi6eu1hx9z8v0op40yl.png
# Use a ratio of 100:42 for best results.
published_at: 2023-06-01 12:57 +0000
canonical_url: https://opensauced.pizza/docs/community-resources/understanding-why-pull-requests-get-rejected-in-open-source-projects/
---


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](https://opensauced.pizza/) or check out our [Intro to Open Source course](https://github.com/open-sauced/intro) today.