[Community] H2 community management: a process for issues, PRs, comms & continuous engagement

From discussion with @thedjpetersen.

## Context

This half we're investing in **growing and sustaining the Astryx community**. Adoption is rising and contributions are coming in — but our *operating process* for handling that inflow hasn't caught up. We have solid ingredients (issue templates, a rich label taxonomy, `CODEOWNERS`, the `review-signal` router, the Night-Watch-PM triage role, and a genuinely good release-comms pipeline), but no defined, measurable process tying them together. We triage without response-time targets, PR review latency is inconsistent and unmeasured, comms are broadcast-only, and we have no rhythm for staying continuously engaged with contributors.

This issue is the **umbrella** for that work. The goal isn't to ship a feature — it's to **define, instrument, and adopt a repeatable process** across four pillars.

## Start by listening

Before we design process top-down, we should **ask the community what they actually want** — a short survey and/or an open GitHub Discussion aimed at contributors and consumers. This is itself the two-way engagement the comms pillar is missing, and it de-risks every decision below (SLA expectations, which channels people would actually use, what recognition they value, where community content should live). Findings feed all four pillars. **Recommended first move.**

## Where we stand today (process audit)

**What we already have:**
- Issue templates (`bug.yml`, `rfc.yml`) and a rich label taxonomy (`area:*`, `type:*`, `needs:code-review`, `needs:design-review`, `needs-scoping`, `community`, `good first issue`, `help wanted`).
- `CODEOWNERS` / `DESIGNOWNERS` / `ENGOWNERS` + the `review-signal` workflow, which auto-applies review-routing labels from changed paths.
- The **Night-Watch-PM** role (wiki) runs hourly triage: checks issue implementability, labels unlabeled issues/PRs, consolidates duplicates, closes resolved issues, and flags issues stale at 30+ days.
- **Solid release comms:** versioned GitHub Releases with notes (steady cadence — v0.1.5→v0.1.9 in ~2 weeks), a public auto-formatted CHANGELOG with contributor credit, public npm publishing with provenance, and a docsite blog.

**What we're missing (the gaps this half should close), roughly in priority order:**

1. **No SLA / response-time targets, anywhere.** Triage exists, but there is no "first response within N days" bar for issues or PRs. Nothing defines what "responsive" means.
2. **No SLA / latency tracker or dashboard.** We can't *measure* triage-time or review-turnaround, so we can't tell if we're improving. The backlog is real: **~194 open issues, ~163 open PRs, ~24 PRs open >14 days, ~67 issues open >30 days.**
3. **No stale automation / `needs-info` loop.** Staleness is a manual eyeball at 30 days — no auto-nudge / auto-label / auto-close, and no follow-up when an author never replies to a triage ask.
4. **Comms are broadcast-only.** Release comms are strong but one-directional and release-triggered — they announce *what shipped*. There's no **between-release, two-way** cadence: no calls-for-contribution, no roadmap sharing, no acknowledgement of community work beyond the changelog credit line, and no channel where contributors can actually *reply* (e.g. GitHub Discussions).
5. **No continuous-engagement mechanisms.** Engagement spikes at launches then goes quiet — no office hours, contributor spotlight, recognition path, or first-time-contributor greeting.

**Low-priority housekeeping** (worth doing, but not where the leverage is): a `PULL_REQUEST_TEMPLATE.md` (most PRs already flow through the AI-assisted path + CI + `review-signal`, so a static checklist adds little), and an `ISSUE_TEMPLATE/config.yml` (mainly useful *once* we decide on a Discussions channel, to route questions there via `contact_links`).

## The four pillars

### 1. Issue management
- **Gap:** no response-time SLA, no way to measure triage latency, no `needs-info` follow-up loop.
- **Define:** first-response and triage-time targets; extend Night-Watch-PM (or add automation) to enforce and *track* them; a `needs-info` → auto-nudge → auto-close lifecycle.

### 2. PR management
- **Gap:** review latency is unmeasured (~24 PRs open >14 days); no documented stale-PR handling.
- **Define:** review SLA + reviewer ownership rotation on top of `review-signal`; a humane stale-PR path that doesn't discourage contributors.

### 3. Comms
- **Gap:** strong at release time, but broadcast-only — no between-release, two-way cadence.
- **Define:** a two-way channel (GitHub Discussions?), a between-release cadence for calls-for-contribution / roadmap / acknowledgements, and channel ownership. (Let the listening survey inform *which* channels people would use.)

### 4. Continuous engagement
- **Gap:** engagement spikes at launches then goes quiet; no recognition or recurring touchpoints; no feedback loop from contributor findings back into core.
- **Define:** recurring touchpoints (office hours, contributor spotlights, roadmap sharing), a recognition path, first-time-contributor greeting, and a first-class channel to route community findings into core (the community template catalog already surfaced 4+ real core bugs — see below).

## Workstream: surfacing community-managed content

The original scope of this issue — **where and how community-managed components, templates, and patterns should live** — is one concrete workstream under continuous engagement. The prior-art analysis lives in the comments below (@ernestt on registry economics + the vetted-core vs. community boundary) and remains the reference for that decision.

**The open question there:** on-docsite Community section vs. separate registry vs. showcase vs. hybrid — with the licensing stance and the vetted/community trust boundary decided up front. See comments for full framing. (This is exactly the kind of question the listening survey should ask directly.)

## What "good" looks like this half

- A written, adopted process for each pillar (a living doc, not a one-off).
- **Instrumented, measurable targets** — a tracker/dashboard for triage-time and review-turnaround, so "responsive" is a number we can see.
- A clear vetted-core vs. community boundary that contributors and consumers understand.
- Contributors were **asked** what they wanted, and report they feel heard and know what to expect.

## Open questions

- What do contributors and consumers actually want? (Run the listening survey / Discussion first.)
- Which pillar is most urgent to formalize first? (The unmeasured backlog argues for issue + PR SLAs.)
- Minimum viable process vs. what can wait?
- Which tools/channels do we standardize on (Discussions? a metrics dashboard? stale-bot?)?
- Who owns each pillar?

---

_Filed to kick off and align on direction. Refined from the original content-surfacing scope to cover the full community-management process for this half._