CI is passing but my PR was rejected because of "code style" and "philosophy" reasons. How is this different from a normal rejection?

[augustbreay]

🏷️ Discussion Type

Question

Body

My PR passes all tests and CI, the feature works perfectly. But the maintainer said it "doesn't fit the philosophy of this project" and "goes against our minimalist approach." I don't really understand this. What does it mean and is there anything I can do?

[augustdev290]

"Doesn't fit the project philosophy" is one of the hardest rejections to hear because it feels vague and personal, but it's actually one of the most legitimate reasons a technically correct PR can be rejected.

What it actually means:

Every project has an implicit or explicit philosophy what it is, what it isn't, how complex it should be, what belongs in core vs plugins. A rejection on philosophy grounds means: "This feature works, but it's not something this project wants to be."

Examples:

A minimalist library that rejects a PR adding 5 new config options (complexity creep)
A CLI tool that rejects a GUI PR (scope creep)
A zero-dependency project that rejects a PR adding a dependency
These rejections are valid and they're not about your code quality.

What you can do:

Ask for clarification before your next PR: "Before I invest more time here's what I'm thinking about building. Does this align with the project's direction?" One issue/discussion comment can save you weeks.

Read the project's philosophy documents: README, CONTRIBUTING.md, blog posts, the maintainer's conference talks. Many projects have explicitly written their design philosophy somewhere.

Propose it as a plugin/extension many projects have an ecosystem model: core stays lean, extras go in plugins. Ask if there's a plugin API you could use instead.

Accept it and fork. This isn't a failure. If you need the feature and the project won't have it, forking is a legitimate outcome. Thousands of successful projects started as "opinionated fork of X."

The lesson: alignment on direction is as important as code quality in open source.

[35974-netizen]

Great

[lucamro]

Ai answer

[florin55555]

its better ai answer

[LinLin2020-h]

is not ai answer

[lunafance]

i love your answer

[hacklerliver]

A CI failure is technical (tests, build, errors).
A code style/philosophy rejection is design preference (how the project wants code written or structured).

Difference:

• CI rejection: "Your code doesn't work."
• Style/philosophy rejection: "Your code works, but doesn't match our standards."

What to do:

• Follow project coding style
• Read contributing guidelines
• Adapt to maintainer preferences

Rule: In open source, maintainers decide the style, not contributors.

[lorevbracer]

It’s basically a subjective rejection, not a technical failure.

• CI failing rejection → Your code is broken (tests fail, bugs, errors).
• Code style rejection → Your code works, but doesn’t match the project’s formatting, structure, or conventions.
• Philosophy rejection → Your approach conflicts with how maintainers prefer the project to be designed (architecture, simplicity, patterns).

In short:
Your code is technically correct, but it doesn’t fit the project’s taste or direction.

[xxxlencerfence]

CI passing = code works. Rejected for style/philosophy = code doesn’t match the project’s conventions or design principles. Fix formatting, naming, or design approach as per reviewer feedback.

[florin55555]

its better to give a answer with grock

[maimenrence]

Great distinction to understand:

Normal rejection = objective issues (bugs, security, performance, wrong approach). There's a clear fix.

Style/philosophy rejection = subjective disagreement about how code should be written, not whether it works. This is trickier because:

• CI can't catch it linters only enforce what's configured
• The "right" answer is the maintainer's opinion, not a spec
• It often reflects unwritten project norms you couldn't have known

What to do differently vs. a normal rejection:

• Ask, don't just fix understand why before rewriting. "Can you point me to an example in the codebase that matches the style you prefer?" saves you a second rejection.
• Look for patterns browse merged PRs to reverse-engineer the unwritten rules.
• Pick your battles carefully if it's a strong philosophical disagreement, it may not be worth continuing. Some projects have a very specific vision.
• Accept it might be "no" a style rejection is sometimes a soft way of saying the feature doesn't fit the project's direction at all.

The frustrating reality is that style/philosophy rejections often mean the bar wasn't documented that's on the project, not you.

[olivena2000]

Style/philosophy rejection:
Your code works but it bumped into unwritten rules. Unlike a normal rejection, there's no clear fix so ask first, rewrite second. And sometimes it's a soft "this doesn't fit our vision," so read between the lines before investing more time.