Why submit a PR instead of building my own
It started with wanting to build an AI-assisted toolkit for medical research. After surveying what was already out there, I changed my mind: this field already has mature projects, and the piece I wanted to add — clinical-study reporting guidelines, journals' policies on disclosing AI use, and citation parsing for Chinese-language literature — was an extension point the project had explicitly left open and no one had filled. Rebuilding a shell of my own was worse than slotting these three pieces into something people already use.
So I opened issues first instead of dumping code: one overall proposal stating the direction and boundaries, and three sub-issues each making clear which file would change, why it belonged in the core rather than as a plugin, and what it would not do. The maintainer ruled on each point under the overall proposal, and I opened the PRs to match.
What each of the three PRs solved
- Medical publishing policy and fail-closed disclosure: added 9 medical-publishing policy targets, and changed AI-use disclosure from "best effort" to stopping output when information is incomplete — when a journal's current policy can't be found, better to stop and say so than to output a disclosure suggestion that looks complete but may actually be outdated.
- Chinese-literature parsing client: a standalone parsing client plus an API protocol document — the biggest of the three changes.
- EQUATOR reporting-standards guide: added three condensed guides to the deep-research module — CARE (case reports), STARD 2015 (diagnostic accuracy), TRIPOD+AI (prediction models) — plus a routing sequence for picking a guideline by study design. Every section marks the source it paraphrases; no original text is passed off as my own words.
The hardest part: a widely misunderstood premise
I got stuck on Chinese-literature parsing: every time I looked up a Chinese journal's DOI, the API returned 404. Common sense said "these DOIs are broken" or "Chinese literature never entered the DOI system."
Digging further, the premise itself was wrong — DOI isn't run by a single organization. It's run jointly by multiple registration agencies, and the one most often treated as "the DOI database" is only one of them. Chinese journals register their DOIs with a different agency, so of course the lookup missed them — but going through DOI's official content negotiation resolves the metadata just fine.
That judgment was the foundation the whole PR stood on. If I'd accepted "can't find it means it doesn't exist," this feature would never have existed. And it wasn't produced by writing code — it came from asking "why" all the way down.
Multiple rounds of adversarial review
Not one of the three PRs passed on the first try. The maintainer's review style was to check items one by one against primary sources and the repo's own rules: whether a policy entry's wording could be found on the journal's official site, whether newly added files violated existing contracts, whether the promised alphabetical ordering actually held, and whether the tests really tested behavior rather than implementation.
Each round I went through his checklist item by item, then pointed him to the exact revised commit for re-review instead of vaguely saying "fixed." The three PRs were merged on 2026-08-01 and 08-02, and the maintainer closed the overall proposal issue as completed.
One more thing worth stating plainly: I also opened a follow-up issue proposing deterministic test coverage for this policy set. The maintainer agreed with the direction, but that part was ultimately implemented and merged by him — it wasn't my PR. I'm writing this here because taking credit for someone else's work is both the easiest and the least worthwhile thing to do.
Honest boundaries
- The code implementation and every round of revision were done with AI coding tools; my part was topic selection, boundary judgment, source verification, and the trade-offs in each round of edits.
- The upstream project's 40,000+ stars are the project's own achievement, not mine. My part is only the three merged PRs.
- A merge doesn't mean these three pieces are correct from here on. Medical policies change and journal requirements get updated; the real maintenance responsibility lies with the upstream community.
What I took away from it
More useful than the merge records were those rounds of review. They forced me to replace "I think it should be this way" with "this file's current rules say it should be this way, and here's the source" — training that's hard to come by in my own projects, because in my own projects nobody questions me like that.