From cccedfdf542b931780f21ddead2a26f603220af8 Mon Sep 17 00:00:00 2001 From: smb Date: Fri, 4 Sep 2026 23:42:43 +0200 Subject: [PATCH 1/2] docs: check an issue's assignee before working on it Nothing in the repository said to claim an issue or to look at who already had. The omission cost real work today: #28 was filed from a reviewer's suggestion and implemented an hour later by someone else, with no assignee and no comment on it in between to say the work was taken. The rule is therefore two-sided. Look first, because an issue somebody else holds is a conversation, not a race; then take it, because an assignee is the only signal the next person gets. It sits with the rest of the issue workflow, so it applies to everyone who works here rather than to one contributor. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index c3f7b10..bc03aa0 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -105,6 +105,11 @@ substitute for this list: it cannot see steps 3, 4 or 7. Work that answers a GitHub issue goes onto its own branch and into a pull request that references the issue. Never push it to `main` directly. +- **Check the assignee before you start, then assign yourself.** An assignee is + the only signal other people have that the work is taken; without one, two + contributors can spend an evening on the same defect. If the issue is already + assigned to somebody else, ask before you begin rather than working in + parallel with them. Unassign yourself if you stop. - Reference the issue in the pull request: `Closes #N` when the change fully resolves it, `Refs #N` otherwise. - **Never merge a branch and never close a pull request.** Whether the work From ec8c8cdb43f5b27c23efac947000b54fbd87bda5 Mon Sep 17 00:00:00 2001 From: smb Date: Fri, 4 Sep 2026 23:45:19 +0200 Subject: [PATCH 2/2] docs: do not force-push a branch that has already been pushed Twice today I rewrote commits on a pushed branch and force-pushed them, once to correct commit messages and once to fold a change into an existing commit, announcing it afterwards rather than asking first. The reasoning was wrong in a specific way worth recording, because it sounds sensible: --force-with-lease refuses to destroy commits it has not seen, so the push felt safe, and safe was taken for permitted. It is not the same thing. A pushed branch is published: a reviewer may have fetched it, a comment may cite one of its commits, and the pull request lists them. Rewriting that is the maintainer's decision, like merging, which is already reserved to them for the same reason. Amending before the first push stays fine. After it, add a commit or ask. Co-Authored-By: Claude Opus 5 (1M context) --- CLAUDE.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index bc03aa0..7390e34 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -116,6 +116,13 @@ request that references the issue. Never push it to `main` directly. is done, and whether it lands, is the maintainer's call — not something to infer from green CI. - `main` is protected; a direct push is rejected, and that is intentional. +- **Never force-push a branch that has been pushed, without being told to.** + Amending, rebasing or squashing published commits is the maintainer's call, + the same as merging is. `--force-with-lease` only protects against + destroying somebody else's commits; it does not grant permission to rewrite + history a reviewer may already have fetched, a comment may already cite, or + a pull request already lists. Amend freely before the first push; after it, + add a commit, or ask. The repository is public and takes reports from other people, so the trail from a report to the change answering it has to stay visible and reviewable.