My first open-source PR got closed, and the maintainer was right

Muhammad Abdullah Shah — Sun, 11 Oct 2026 07:51:57 +0000

This week I did something I had been putting off for years: I fixed two real bugs in open-source projects and opened the PRs myself.

The two were repowise-dev/repowise#3251 and sktime/sktime#11437.

The repowise bug: doc_anchors only registered the first anchor when a document had repeated headings. GitHub-style suffixed anchors (slug-1, slug-2) were just missing. The sktime bug: LagLlamaForecaster._update was loading the entire series history on every update instead of keeping just context_length rows. Unbounded memory growth hiding inside a method nobody looks at twice.

Both fixes were small. Both took longer than I expected, because the real work was reading the codebase long enough to be sure I was not breaking something else. The repowise fix needed 2 regression tests to prove the anchors were right. The sktime fix needed 5 direct cases. Ruff clean, existing tests still green.

Here is the part I did not expect. This morning the repowise maintainer closed my PR without merging it.

The reason was fair, and I will give it to him straight. Another contributor had claimed the issue in the thread first, and their version handles an edge case mine missed: a heading that literally reads ## Usage 1 written out. With a plain counter, that collides with the auto-generated usage-1. Their version gives the third ## Usage a proper usage-2. Mine would have shipped a subtle duplicate-anchor bug. So, yes, closing mine was the right call.

And then the maintainer did something I will remember: he personally pointed me at another issue, #3283, and said it was mine if I claimed it. Importing one helper from ingestion.git_indexer drags in the whole package and all of GitPython. The fix is lazy imports. I have already written it in my fork, tests pass, and it is waiting on me to claim the issue and open the PR. The sktime PR is still open, awaiting review.

Two lessons I keep turning over.

First: writing the fix is the easy half. The other half is the process around it. Claim the issue in the thread before you start, read how maintainers respond, and treat every edge case in a review comment as something you should have thought of first.

Second: a closed PR is not a failed PR. Mine found the bug, confirmed the fix shape, and got a maintainer to hand me a better issue. That is a net win by any measure that matters.

If you are thinking about starting: pick a project you already use, look at its good-first-issues, and read more code than you write. The reading is the work.

I built a merge-conflict predictor that ignores lines and reads the AST instead

Muhammad Abdullah Shah — Sun, 04 Oct 2026 07:51:35 +0000

Git's idea of a merge conflict is narrower than it should be. Two branches change the same lines, you get a conflict. Two branches touch the same function from different files and never collide, git merges cleanly and congratulates you. Then production breaks.

That's the merge I've learned to fear most: the clean one. One person refactors a function while another adds a call to it, the merge goes through without a peep, and you find out a week later from a bug report.

I'm building PRISM, an AI-powered git time machine, and this week I shipped a conflict predictor built around a simple idea: lines are the wrong unit. Symbols are better.

The approach

Parse the merge-base and both branch heads into ASTs with tree-sitter, extract the symbols (functions, classes, methods), and flag overlap between the two sides. Both branches touching the same symbol is risk, even across different files. The score saturates so one hot file can't dominate the whole prediction. It's exposed as POST /repos/{id}/predict-conflict, and there's a branch-compare UI with a risk bar and the overlapping symbols listed, so the number is inspectable instead of magic.

The unglamorous parts took most of the time

Tree-sitter grammar packages aren't always installed on the machine. The first version crashed when one was missing, which made it a demo, not a tool. Now the service degrades to line-level scoring when a grammar is missing. Boring engineering, but it's the difference between something you can actually run and something you can't.

Method detection inside class bodies broke twice before my tree-sitter queries finally caught it. Queries for methods are fiddlier than function queries, and I learned that through two rounds of debugging. Skill issue on my part, honestly.

9 new tests, 39 passing overall.

What it's actually for

The predictor doesn't replace tests or review. It answers one narrow question: did these two branches step on the same symbols? That's cheap to answer, and it catches exactly the class of breakage that git itself can't see. Next up I'm working on semantic code ownership with embeddings, which should catch the cases where even the symbol names diverge.

If you merge a lot, you know the feeling of a clean merge that wasn't. What's the worst one you've shipped?

DEV Community: Muhammad Abdullah Shah

My first open-source PR got closed, and the maintainer was right

I built a merge-conflict predictor that ignores lines and reads the AST instead

The approach

The unglamorous parts took most of the time

What it's actually for