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.
Top comments (0)