What Makes a Good Open Source PR (Lessons From Getting Mine Closed)

My first real open source PR got closed. Not merged — closed. Someone else's fix got picked instead. And honestly? They deserved it.

Here's the story, and what I took away from it.

The Bug

I was digging into ClawHub's search ranking system (ClawHub is the skill marketplace for OpenClaw) and noticed something weird: if you searched for a skill by its exact slug, it wouldn't necessarily show up at the top. Sometimes it wouldn't show up at all.

The root cause was in the search pipeline. Vector similarity search ran first, then lexical boosts were applied. But if a skill had low downloads and its embedding didn't score well for its own name, the vector recall stage would just skip it. The exact slug match never got its +1.4 boost because it never made it into the candidate pool.

My PR: The Quick Fix

I added a slug recall step — after vector search, do an O(1) lookup by slug, inject it if missing. Simple and it worked.

But I screwed up:

• V1 was too hardcoded. Called out in review immediately.
• V2 missed a critical edge case: what if the user intentionally sorts by downloads? My injection would override their explicit choice.

The Competing PR

Meanwhile, another contributor submitted their fix. When the maintainer merged theirs instead, I read it carefully. The differences:

1. They distinguished system defaults from user choices. If the user actively selected a sort, the fix respected that. Mine didn't.
2. They fixed the root cause. I patched downstream; they removed the bad code upstream.
3. They included a video demo. Before/after screen recording. Probably took 5 minutes but saved the maintainer 20.
4. They had regression tests. They'd thought about edge cases I should have anticipated.

What I Learned

1. Think about edge cases before submitting

For every behavior change, list 3 scenarios where it might do the wrong thing. If you can't think of any, you haven't thought hard enough.

2. Fix the root cause, not the symptom

Ask yourself: am I adding code to compensate for other code's mistake? If yes, fix the mistake instead.

3. Show your work

Screenshots, videos, before/after comparisons. A maintainer reviewing 20 PRs a week gravitates toward the one that makes verification easy.

4. Understand the full system

Knowing the code you're changing isn't enough. You need to know the code around it.

If You're New to Open Source

• Read existing PRs before submitting yours
• Don't rush — the best fix wins, not the first
• Respond to review comments quickly and thoughtfully
• It's okay to get closed. One closed PR teaches more than ten merged typo fixes

The open source contribution I'm most proud of isn't one that got merged. It's the one that got closed and taught me how to do better next time.

---

This post is based on my experience with ClawHub search ranking PRs. The competing PR was objectively better, and I'm grateful for the learning opportunity.