Maintainer starter-issue hygiene

Use this lightweight checklist to keep starter work real and usable for first-time contributors.

Curate issues with conversion in mind

For each issue you mark good first issue:

• Keep scope narrow (one workflow, one command family, or a small doc/test area).
• Add objective acceptance criteria (what must be true to close it).
• Link to exact files/commands contributors should start from.
• Confirm it can be validated with existing repo checks.

If any item is missing, use help wanted until scope is tightened.

Labeling rules of thumb

• Use good first issue only when context burden is low.
• Use help wanted for valuable tasks that still need project context.
• Add domain labels (for example: documentation, tests) to improve filtering.
• Remove needs-triage once scope/labels are confirmed.

Keep issue quality lightweight

When creating or grooming starter work, avoid process bloat:

• No placeholder/fake tasks.
• No broad epics for first-timers.
• No extra templates/checklists beyond what this repo already uses.

Fallback when issue queue is thin

If there are few open starter issues, direct contributors to:

• docs/starter-work-inventory.md for safe contribution categories.
• .github/ISSUE_TEMPLATE/feature_request.yml for scoped proposals.

This maintains a truthful contribution path without pretending there is a large maintained backlog.