You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add the standard community-health files the repository currently lacks — structured issue templates, a security disclosure policy (SECURITY.md), a code of conduct — and curate an initial set of labeled good-first-issues so new contributors have an obvious entry path.
Why this matters
GitHub surfaces community-health completeness directly (the Community Standards checklist), and contributors and corporate adopters both check it. For a security library specifically, a visible vulnerability-disclosure channel is table stakes: today CONTRIBUTING.md mentions GitHub Security Advisories in passing, but there is no SECURITY.md, which is where every scanner and every researcher looks first.
Proposed scope
.github/ISSUE_TEMPLATE/: bug_report.yml (version, Python version, minimal repro, expected/actual), feature_request.yml (problem, proposed solution, alternatives), and config.yml routing security reports away from public issues to the advisory channel.
SECURITY.md: supported versions table, private reporting via GitHub Security Advisories, expected response window, scope notes consistent with the documented threat model (and the planned threat-model doc, docs: add capability-token threat model and misuse cases #122).
CODE_OF_CONDUCT.md: Contributor Covenant 2.1 with a working contact method.
PR template with a checklist mirroring AGENTS.md review gates (make ci passes, CHANGELOG updated, docs match implementation).
Curate 3–5 existing issues as good first issue with a one-line "where to start" comment each.
Implementation notes
Forms (.yml) over markdown templates — structured fields produce better bug reports for an API library.
SECURITY.md content should align with docs/security.md and the disclaimers in the README (not production-hardened for real authentication) so the disclosure scope is honest.
All template text must follow the repo's domain vocabulary (capability, principal, grant, Frame — per AGENTS.md).
Acceptance criteria
GitHub's Community Standards checklist shows all items green.
New-issue flow offers bug/feature forms and routes security reports to private advisories.
SECURITY.md states supported versions, reporting channel, and response expectations.
PR template reflects the actual review checklist.
At least three issues labeled and annotated as good first issues.
Out of scope
Governance documents (maintainer ladder, RFC process) — premature at current scale.
Discussion forums / chat channels.
References
GitHub community standards documentation; Contributor Covenant 2.1.
Summary
Add the standard community-health files the repository currently lacks — structured issue templates, a security disclosure policy (SECURITY.md), a code of conduct — and curate an initial set of labeled good-first-issues so new contributors have an obvious entry path.
Why this matters
GitHub surfaces community-health completeness directly (the Community Standards checklist), and contributors and corporate adopters both check it. For a security library specifically, a visible vulnerability-disclosure channel is table stakes: today CONTRIBUTING.md mentions GitHub Security Advisories in passing, but there is no SECURITY.md, which is where every scanner and every researcher looks first.
Proposed scope
.github/ISSUE_TEMPLATE/:bug_report.yml(version, Python version, minimal repro, expected/actual),feature_request.yml(problem, proposed solution, alternatives), andconfig.ymlrouting security reports away from public issues to the advisory channel.SECURITY.md: supported versions table, private reporting via GitHub Security Advisories, expected response window, scope notes consistent with the documented threat model (and the planned threat-model doc, docs: add capability-token threat model and misuse cases #122).CODE_OF_CONDUCT.md: Contributor Covenant 2.1 with a working contact method.make cipasses, CHANGELOG updated, docs match implementation).good first issuewith a one-line "where to start" comment each.Implementation notes
.yml) over markdown templates — structured fields produce better bug reports for an API library.docs/security.mdand the disclaimers in the README (not production-hardened for real authentication) so the disclosure scope is honest.Acceptance criteria
Out of scope
References
CONTRIBUTING.md,AGENTS.mdreview checklist,docs/security.md, docs: add capability-token threat model and misuse cases #122 (threat model doc).Priority: P1 · Effort: S · Impact: Medium