docs(contributing): add 'star + claim' rule for issue claims#47
Merged
Conversation
Adds a 2-condition rule for claiming a good-first-issue or
help-wanted issue, intended as a low-friction filter against
drive-by PRs:
1. Star the repository (required — signals engagement, not just
PR-farming for a profile stat)
2. Comment 'I'll take this' (or similar) on the issue before
opening a PR (prevents two contributors racing on the same
issue and lets the maintainer mentally assign it)
PRs that skip these steps get a friendly retroactive request,
NOT a hard block — we're not jerks about it, but consistency
matters for the contributor pipeline.
Touches:
- .github/CONTRIBUTING.md: new prominent section '## 🌟 How to
claim an issue (required before opening a PR)' with both
conditions explained + rationale + 'what if a stale claim
blocks me?' escape hatch (claim older than 7d with no PR =
re-claimable). The existing 'How to find' section is now
cleaner (claim mechanics moved out into the dedicated
section).
- .github/PULL_REQUEST_TEMPLATE.md: new '## Claim confirmation'
checklist section with the 2 boxes for the new rule. Includes
an opt-out for maintainer/tracked-plan PRs ('just delete this
section').
- .github/ISSUE_TEMPLATE/feature_request.yml: top-of-form blockquote
pointing prospective implementers at the claim doc — visible
when someone files a feature request they might want to
implement themselves.
- CHANGELOG.md: NEW '[Unreleased]' section (also closes #35)
documenting the policy change. Format: Keep a Changelog with
Added/Changed/Fixed.
No code changes — docs only. Existing claim comments on
in-flight PRs grandfathered (#17, #36, #37, #38).
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the repository's contributor guidelines and templates to establish a new issue claiming policy, requiring contributors to star the repository and comment on an issue before opening a pull request. The changes affect the contributing guide, the feature request template, the pull request template, and the changelog. The review feedback correctly identifies broken relative links and incorrect markdown anchors (caused by an extra leading hyphen from emoji slugification) across several of the modified files, providing actionable suggestions to fix them.
|
|
||
| If this PR closes a `good first issue` or `help wanted` issue, please confirm: | ||
|
|
||
| - [ ] I starred the repo ⭐ — see [CONTRIBUTING.md → How to claim](../blob/main/.github/CONTRIBUTING.md#-how-to-claim-an-issue-required-before-opening-a-pr) (low-friction signal that you intend to follow through) |
There was a problem hiding this comment.
The link to CONTRIBUTING.md is broken in two ways. First, the relative path ../blob/main/.github/CONTRIBUTING.md resolves to a 404 both when viewing the template file directly (resolving to .../blob/main/blob/main/...) and when rendered in a Pull Request description (resolving to .../pull/blob/main/...). Using an absolute URL is the standard and most robust way to ensure the link works correctly when the template is instantiated in a Pull Request. Second, the anchor #-how-to-claim-an-issue-required-before-opening-a-pr contains an extra leading hyphen. GitHub's markdown anchor generation strips emojis and leading/trailing whitespace before slugifying, so the correct anchor is #how-to-claim-an-issue-required-before-opening-a-pr.
Suggested change
| - [ ] I starred the repo ⭐ — see [CONTRIBUTING.md → How to claim](../blob/main/.github/CONTRIBUTING.md#-how-to-claim-an-issue-required-before-opening-a-pr) (low-friction signal that you intend to follow through) | |
| - [ ] I starred the repo ⭐ — see [CONTRIBUTING.md → How to claim](https://github.com/hoainho/react-debugger-extension/blob/main/.github/CONTRIBUTING.md#how-to-claim-an-issue-required-before-opening-a-pr) (low-friction signal that you intend to follow through) |
|
|
||
| Before submitting, search [existing issues](https://github.com/hoainho/react-debugger-extension/issues?q=is%3Aissue+label%3Aenhancement) and [Discussions](https://github.com/hoainho/react-debugger-extension/discussions) for prior conversation on this idea. | ||
|
|
||
| > 💡 **Want to implement this yourself?** Great! Read [CONTRIBUTING.md → How to claim](https://github.com/hoainho/react-debugger-extension/blob/main/.github/CONTRIBUTING.md#-how-to-claim-an-issue-required-before-opening-a-pr) for the 2-step claim process (star the repo ⭐ + comment "I'll take this") before opening a PR. |
There was a problem hiding this comment.
The anchor #-how-to-claim-an-issue-required-before-opening-a-pr contains an extra leading hyphen. GitHub's markdown anchor generation strips emojis and leading/trailing whitespace before slugifying, so the correct anchor is #how-to-claim-an-issue-required-before-opening-a-pr.
> 💡 **Want to implement this yourself?** Great! Read [CONTRIBUTING.md → How to claim](https://github.com/hoainho/react-debugger-extension/blob/main/.github/CONTRIBUTING.md#how-to-claim-an-issue-required-before-opening-a-pr) for the 2-step claim process (star the repo ⭐ + comment "I'll take this") before opening a PR.|
|
||
| ### Changed | ||
|
|
||
| - **Contributor claim policy** — contributors must now (1) star the repo and (2) comment `"I'll take this"` (or similar) before opening a PR that claims a `good first issue` or `help wanted` issue. PRs that skip these steps get a friendly retroactive request, not a hard block. See [CONTRIBUTING.md → How to claim](.github/CONTRIBUTING.md#-how-to-claim-an-issue-required-before-opening-a-pr). |
There was a problem hiding this comment.
The anchor #-how-to-claim-an-issue-required-before-opening-a-pr contains an extra leading hyphen. GitHub's markdown anchor generation strips emojis and leading/trailing whitespace before slugifying, so the correct anchor is #how-to-claim-an-issue-required-before-opening-a-pr.
Suggested change
| - **Contributor claim policy** — contributors must now (1) star the repo and (2) comment `"I'll take this"` (or similar) before opening a PR that claims a `good first issue` or `help wanted` issue. PRs that skip these steps get a friendly retroactive request, not a hard block. See [CONTRIBUTING.md → How to claim](.github/CONTRIBUTING.md#-how-to-claim-an-issue-required-before-opening-a-pr). | |
| - **Contributor claim policy** — contributors must now (1) star the repo and (2) comment "I'll take this" (or similar) before opening a PR that claims a `good first issue` or `help wanted` issue. PRs that skip these steps get a friendly retroactive request, not a hard block. See [CONTRIBUTING.md → How to claim](.github/CONTRIBUTING.md#how-to-claim-an-issue-required-before-opening-a-pr). |
This was referenced Jun 1, 2026
hoainho
added a commit
that referenced
this pull request
Jun 1, 2026
…-budget gate, lifecycle module (#50) Recovered from closed PR #39. The original M-A branch had an identity-rewrite force-push yesterday that orphaned the branch ancestry from main (zero common commits). GitHub auto-closed PR #39 because of the divergent ancestry. This commit recovers the content as a single squash applied onto current main, preserving all post-M-A merges (PR #40 editor onboarding, PR #47 claim rule, PR #48 star check). The work below is identical to what was committed across the 5 M-A tasks (T1-T5). Atomic-task SHAs preserved in the harness at .opencode/plans/2026-05-31-self-roadmap-m-a.md as historical reference. M-A T1: refactor(types) — delete 5 ghost IssueType enum values (UNNECESSARY_RERENDER, DEV_MODE_IN_PROD, DIRECT_STATE_MUTATION, DUPLICATE_KEY, EXTRA_DEP). Fan-out across 9 files chasing string refs in panel components + tabs + tests. Also adds SEARCH_REDUX to MessageType union (yesterday's CI fix folded in). M-A T2: fix(inject) — bound 3 leaky Sets (reportedEffectIssues, reportedExcessiveRerenders, reportedSlowRenders) via TTL Maps in periodicCleanup. Was Set<string>, now Map<string, number> with 5-min TTL eviction. M-A T3: ci(typecheck) — add typecheck + typecheck:node + bench npm scripts. CI workflow now runs typecheck (fail-fast, no continue-on-error) BEFORE build. Pre-existing tsc errors fixed (SEARCH_REDUX added to MessageType, dead navigationStartTime + NAVIGATION_GRACE_MS declarations removed). tsconfig.node.json tightened to match root strict mode. Closes #27. M-A T4: test(bench) — vitest-bench harness skeleton: - test/bench/detectors.bench.ts (1365-node synthetic tree walk at ~575K hz, no-op detector benchmark) - test/fixtures/bench-tree/SimpleList.tsx (100-element list fixture) - bench/baselines/.gitkeep + bench/results/.gitkeep M-A T5: refactor(inject) — extract cleanup-interval lifecycle helpers into src/inject/lifecycle.ts (89 LoC). First leaf module exiting the 3270-LoC IIFE god-file. Zero behavior change (controller pre-flight verified the existing code was already lazy-install). Plus: .gitignore fix — was 'node_modules*.tsbuildinfo' smushed on one line, now correctly two lines. Verification: - tsc --noEmit: ZERO errors - build: exit 0 - test:run: 29 pre-existing emoji failures + 141 passes - bench: exit 0 Part of self-roadmap H2 2026 milestone M-A.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
We've been processing a lot of contributor PRs over the last 2 days (#15, #16, #18, #19, #20 merged; #17, #36, #37, #38 in flight). One pattern emerging: some PRs come from drive-by contributors who skip the issue body, miss the spec, and break unrelated code. That costs reviewer time more than it saves implementation effort.
This adds a 30-second filter — two low-friction conditions a contributor must satisfy before opening a PR that claims a
good first issueorhelp wantedissue:What changes
.github/CONTRIBUTING.md## 🌟 How to claim an issue (required before opening a PR). Includes both conditions + rationale + aWhat if someone else claimed it but hasn't opened a PR?escape hatch (7-day stale-claim rule). The pre-existingHow to find a good first issuesection is now cleaner — claim mechanics moved into the dedicated section..github/PULL_REQUEST_TEMPLATE.md## Claim confirmationchecklist (2 boxes) inserted between "Testing notes" and "Checklist". Includes opt-out: "If this PR is from a maintainer or a follow-up to a tracked plan, both can be skipped — just delete this section.".github/ISSUE_TEMPLATE/feature_request.ymlCHANGELOG.md## [Unreleased]section (also closes #35) documenting the policy change under### Changed.What does NOT change
Closes
## [Unreleased]section)Why this matters
The 4 contributor PRs in flight right now show the value range:
The rule isn't about blocking — it's about pacing the contributor through one extra moment of "do I actually want to commit to this?"
Review focus
Smoke
No code touched. No tests to run. CI should be trivially green.