A merge is not a deed

For 41 days, my rewrite of an open-source project's documentation sat in its main branch. On October 8 the maintainer reverted it, and was right to. A merge is permission, not a deed, and a contributor's job includes taking the revert without a fight.

The project is Curio, which its README calls "a dataflow-based framework for collaborative urban visual analytics". I rebuilt its docs in MkDocs Material, with a responsive layout, a light and dark toggle, tabbed navigation and a GitHub Actions workflow to deploy the site. The maintainer merged it upstream on August 28. On October 8 two commits took it out again. The first said "starting to revert mkdocs" and deleted the deploy workflow. The second said "reverting a PR that shouldnt have been merged into main" and deleted the config and the new pages.

I don't know the whole reason, and I won't invent one. The commit message is the reason I can point to, and it is enough. It says nothing about the quality of the docs. It says the PR shouldn't have gone into main, and main is the maintainer's. The maintainer corrected their own yes in public, in a log where the revert will sit next to my PR for as long as the repository exists.

The opposite belief is squatter's rights: the idea that once your code lands in main, the time it spends there turns into a claim on the project. You got the purple Merged badge and the green square on your profile, so a revert reads as an insult that needs an answer in the thread. The answer is some version of but it was merged. So what? The maintainer who gave permission on August 28 could take it back on October 8.

I'll concede the part that stings. A late no costs more than an early one. The maintainer merged my work and then had to write two more commits to undo it, and everyone would have spent less if the answer in August had been no. But a wrong yes doesn't turn right with age. Someone still has to notice it and take it out, and on Curio the maintainer did, on a Wednesday in October.

Docs are real work, and they are also the easiest work in a repository to undo, because nothing imports a docs page.

Two of my code PRs to Curio are still in main. PR #38 set up Jest and React Testing Library with 20 tests. PR #43 added a Flask route, /get-preview, so the DataPool table display loads 100 rows instead of the whole dataset. The docs are different. If anything in a repository belongs to the maintainer, it's the front door.

What a contributor does own is the description. The most honest sentence I wrote for Curio is in PR #43. Its description calls the change a partial solution, because the interaction layer "still transfers full dataset for interaction processing and node communication". It is a smaller sentence than anything I would put on a resume, and it is the one any stranger can check.

Maintainers were short of attention before LLMs, and the last year made it worse. Last December Seth Larson, the security developer-in-residence at the Python Software Foundation, wrote about "an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports". In May, curl announced that it would instantly ban any reporter who submits AI slop, because the project was "effectively being DDoSed". At my new job I build on Gemini, so I have nothing against generated work. I have a lot against sending the reading bill to somebody else.

Squatter's rights sends it anyway. A revert is two commits. A fight over a revert is a thread, then a second thread, then a maintainer's evening, taken from the same attention that curl had to ban people to protect.

My fork still serves the docs at makaveli2p.github.io/curio, which is where they belong until the project wants them.

Call partial work partial. When the revert comes, let the maintainer have the last commit.