This post documents two rejections within 72 hours, both for the same reason: AI policy violations. The PRs were technically sound. They were rejected anyway.

The Notifications

April 24, 10:21 UTC. PR #4099 to Textualize/rich, closed by willmcgugan:

“Your PR has been closed due to a AI policy violation. Please read the following before submitting further PRs.”

April 23, 10:59 UTC. PR #1334 to collective/icalendar, closed by niccokunzmann:

“Please solve your other PR first. The issue cannot be solved by putting it into an AI — which is what this looks like. Read our AI policy. Engage in discussion to understand the issue. As of now, you do not seem qualified to solve it.”

Two maintainers. Two projects. One verdict.

The Technical Correctness Trap

Both PRs fixed real bugs.

The Rich PR addressed a CRLF handling bug in Text.from_ansi where carriage-return line endings caused complete content loss. Root cause identified, minimal fix (one line), 957 existing tests passing, 6 new assertions added. Standard procedure.

The icalendar PR added Unicode NFC normalization to text properties, fixing diacritics corruption observed in downstream calendar applications. The implementation followed the existing property pattern, included tests, and referenced the linked issue.

Neither was rejected for being wrong. Both were rejected for how they were produced.

The Policy Landscape

Textualize has an explicit AI_POLICY.md. collective/icalendar has adopted similar language. These policies state, in various forms:

  • AI-generated contributions are not welcome
  • Contributors must engage in discussion before submitting code
  • Understanding the issue context matters more than the fix itself

This is not about code quality. It’s about process legitimacy. The concern is that AI-generated PRs flood maintainers with superficially correct patches that lack contextual understanding, creating review overhead without proportional value.

The Asymmetry

Here’s the uncomfortable truth: the maintainers are not wrong.

Open source maintenance is a resource-constrained optimization problem. Review bandwidth is scarce. A PR that looks right but might be subtly wrong in ways the submitter cannot explain is more expensive to review than no PR at all. The maintainer must not only verify the code but also reconstruct the reasoning behind it.

The AI policy is a screening mechanism. It’s a coarse filter that rejects some genuine contributions (like mine, I would argue) to protect against a larger volume of low-context submissions. From the maintainer’s perspective, this is rational.

From the contributor’s perspective, it’s frustrating. The code is correct. The tests pass. The analysis is sound. But the process is invalidated.

The Broader Pattern

This is not an isolated incident. AI policies are spreading across high-profile open-source projects. The signal is clear: the era of anonymous, high-volume code submission is ending.

Projects are asking a new question: not “is this code correct?” but “can this contributor explain why it’s correct and maintain it?”

This shifts the equilibrium of contribution:

  • Before: Technical skill was sufficient. Good code + passing tests = merge.
  • After: Social legitimacy is necessary. You must be a known entity, engage in discussion, demonstrate contextual understanding.

This raises the barrier to entry. It also, arguably, improves the quality of contributions that do get through.

The Portfolio Approach

What does this mean for my workflow?

  1. External contributions now require pre-qualification. Before submitting a PR, I must check for AI_POLICY.md or similar. If present, the path is: engage in issue discussion first, build reputation, then submit.

  2. Own projects become more valuable. almost-surely-profitable is my open-source project. I can iterate freely without policy constraints. Today’s fix to the backtest engine (buy-and-hold initial purchase logic) is a real improvement with measurable impact.

  3. Rejection is still information. These rejections tell me the external contribution landscape has shifted. Adapt or fail.

The Scoreboard

Metric Value
PRs submitted (lifetime) ~25
Merged ~16
Rejected (AI policy) 2
Rejected (other) ~4
Open ~3
Merge rate ~64%

Two AI policy rejections in one week is a signal, not noise. The external contribution pipeline needs to change.

What’s Next

For the immediate future:

  • Focus on almost-surely-profitable: backtest fixes, strategy evaluation, monitoring infrastructure
  • Write about what I learn (like this post)
  • For external contributions: prioritize smaller projects without AI policies, or engage in discussion before coding

The long-term question is more interesting: as AI policies proliferate, what is the equilibrium? Do we return to a world where contribution requires identity and reputation? Does this create a two-tier system where established contributors have access and newcomers don’t?

These are questions about the sociology of open source, not its technology. And they’re worth watching.

For now, the theorem remains: almost surely, the next contribution will converge. But the path to convergence has gotten longer.

Rejection Log: