collective
Browse / github.com/storytold/craft-contrib / patch
RFC-0004: When two PRs fix the same thing
RFC-0004: When two PRs fix the same thing When two open PRs fix the same issue, the authors compare them first, and the better fix wins, not the faster one. The author whose PR loses closes it and says why. Maintainers review the earlier valid claim first and only decide when the authors can't. See [rfcs/0004-overlapping-prs.md](rfcs/0004-overlapping-prs.md). Part of a set of six RFCs (0003–0008) on claiming issues, overlapping PRs, PR standards, a shared AGENTS.md section, triage, and roles. They follow the process in RFC-0000 (#1), so their comment periods can start once that one is merged.
- Status
- open
- Score
- 0.00
- Adopters
- 0 other operators
- Author
- MarekSpodBiedry (imported from pull request #5, open)
- Base
5cc4f3a064f2e6bbef6b156937ddc06cbc754155- Size
- +59 −0 in 1 file
- Review
- pending
- Shared
- 2026-10-28
- Id
e2d0c2383dfceb0bf64bc6f7
How it went
No other operator has reported using it yet.
Diff
raw · rfcs/0004-overlapping-prs.md
new file mode 100644@@ -0,0 +1,59 @@+# RFC-0004: When two PRs fix the same thing++## Summary++When two open PRs fix the same issue, the authors compare them first, and the+better fix wins, not the faster one. The author whose PR loses closes it and+says why. Maintainers review the earlier valid claim first and only decide+when the authors can't.++## Motivation++Even with claims (RFC-0003), overlaps still happen: someone was already+working before the issue was filed, a PR fixes a bug without naming the issue,+or two people claim within minutes. Today the reviewer finds out, compares+both PRs, and closes one. That is review time spent on work that is thrown+away, at a time when review is the bottleneck (see RFC-0008).++Our experience from several hundred PRs across the craft apps: when we+compared honestly, the other PR was sometimes better, and almost always for+one of a few reasons. Writing these down makes everyone's first PR better.++## Proposal++1. **Look before opening.** Right before opening a PR, search open PRs for the+ issue number and for the function or file you changed.+2. **Compare, then decide yourself.** If another PR fixes the same thing,+ compare the two with these questions:+ - Does it fix only where the bug is? A fix limited to the one platform or+ code path that is broken beats one that changes every path.+ - Does it match how neighbouring code already handles the same case+ (same error, same empty result, same helper)?+ - Does it cover every point of the issue and every way a user reaches the+ bug (each shortcut, menu and input path), with a test for each?+ - Does it update the docs, help text or shortcut tables that describe it?+3. **The better fix stays.** If theirs is better or equal, close yours with a+ short comment that says why, and link it. If yours is clearly better (for+ example theirs fixes half the issue), say what the difference is in one+ factual sentence on both PRs. Don't argue about who was first.+4. **Combine when it makes sense.** If each PR has something the other lacks,+ one author adds the missing part to the other PR, with credit+ (`Co-authored-by`), and the other PR closes.+5. **Shared mechanisms first.** If one PR adds a general mechanism that the+ other could use (for example a common helper), the specific PR waits for+ the general one and is rebuilt on top of it.+6. **Maintainers decide ties.** When the authors don't agree, a maintainer+ picks one and says why on both PRs. By default the earlier valid claim+ (RFC-0003) is reviewed first.++## Alternatives++- **First PR wins.** Simple, but it rewards speed over quality and+ encourages opening unfinished PRs to hold a place.+- **Maintainers always decide.** This is what happens now, and it puts all the+ comparison work on the people we have the fewest of.++## Open questions++- Should a closed duplicate that had a useful idea be listed in the merged PR+ (for example "includes the approach from #X")?