[RFC] Machine-enforceable issue claiming workflow (/accept, /assign)

Problem Statement

Issue ownership today is informal: contributors express interest in comments, and maintainers assign by hand. That works when volume is low and responses are fast, but ownership is easy to lose track of as the project grows — especially around good first issues and other community-facing work.

A small, machine-enforceable claiming protocol would make ownership explicit for both contributors and maintainers, without turning this into a project-management system.

Proposed Solution

Add one GitHub Actions workflow that reacts to issue comments with three commands:

Command	Who	Effect
/accept	maintainers (write / maintain / admin)	mark the issue ready for public claiming (accepted)
/assign	any contributor	claim the issue if it is open, claimable, and currently unassigned
/unassign	current assignee or a maintainer	release the issue

Claimable means the issue is open and any of:

• labeled accepted, or
• already labeled good first issue, or
• already labeled help wanted

Hard rules:

• first valid /assign wins; never overwrite an existing assignee
• the bot never revokes a manual maintainer assignment
• closed issues ignore all commands
• unknown commands are no-ops
• repeated /assign from the same person is idempotent

Why this shape

The goal is only:

1. maintainers decide acceptance
2. contributors decide whether to claim
3. the bot enforces ownership

Out of scope for a first iteration: prow-style command suites, workgroup taxonomies, title-format checks, PR admission gates, and any change to existing issue templates or CI.

Alternatives Considered

• Keep the current comment-based process: lowest cost, but ownership stays implicit.
• A full community lifecycle bot: more powerful, but heavier than this repo needs right now.
• This proposal: the smallest set of rules that makes claim state visible in GitHub.

Labels

Two new labels only: accepted, in-progress. Existing labels are unchanged. Type labels from issue forms continue to work as they do today.

Implementation shape (if this direction is wanted)

• one workflow file, e.g. .github/workflows/issue-claim.yml
• actions/github-script only (no new Python stack, no third-party bot)
• permissions: issues: write, contents: read
• estimated size: ~150–200 lines

Questions for maintainers

1. Should good first issue / help wanted be claimable without /accept?
2. Who may run /accept — write / maintain / admin only?
3. Any concern about slash commands versus free-form comments?
4. Is a tracking issue + small PR welcome, or is the current manual process preferred for now?

Happy to follow up with a focused PR if the direction looks right.