From 05d5aade25cbf53a403593ce1fa394f261cf3e33 Mon Sep 17 00:00:00 2001 From: cevheri Date: Mon, 7 Sep 2026 17:24:26 +0300 Subject: [PATCH] docs(contributing): say that a claim is a courtesy, not a lock Two contributors reached #621 ten minutes apart: it was claimed at 13:04 UTC and #627 arrived at 13:16 with a commit dated 13:14. The author of the pull request could not have seen the claim, because GitHub sends no notification for a comment on an issue you already have open. The claim bullet read as an exclusive hold and said nothing about that case, so it left the outcome looking like a judgement of one of the two people. It is not one. State the rule the collision was actually decided by: the clock rather than the claim, delivered work reviewed on its merits, nobody asked to write the same change twice, and the nearest open issue plus review credit for whoever does not land it. No test. The paragraph carries no cross-file invariant to guard, and pinning its prose verbatim would fail on the next honest edit while proving nothing. The two-week staleness window above it is unchanged and still open to review. --- CONTRIBUTING.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ae775eff..8bf9b51b 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -76,6 +76,14 @@ label have not been vetted for outside pickup; ask in an issue first if one inte - **Claim before you start.** Comment on the issue so two people do not build the same fix. A claimed issue with no activity for two weeks is open again. +- **A claim is a courtesy, not a lock.** It cannot reach somebody who already had the issue open, + because GitHub sends no notification for a comment on a page you are already reading. So two + people do occasionally arrive at the same issue, and when that happens neither of them did + anything wrong. We decide by the clock rather than by the claim: work that was already in flight + when the claim was posted is not queue-jumping, and a pull request that is already delivered is + reviewed on its merits. Nobody is asked to write the same change twice, so whoever does not land + it is offered the nearest open issue instead, and a review on the other pull request is credited + here the same as code. - **What counts.** A PR that references its issue, includes tests and passes the gate above. During October we also add `hacktoberfest-accepted` to merged PRs from the labeled list, for participants whose program still looks for it.