docs: adopt a contributor and governance model (+ print_debug_info)

[emfdavid]

Summary

insitubatch had no CONTRIBUTING, no issue or PR templates, no code of conduct and no governance document — .github/ held only workflows. With 0 open issues and every PR from #11–#22 authored by the maintainer, the repo reads from outside as a solo project that is not taking help, and a would-be contributor has no way to learn the scope limits before spending a weekend on a change that would be declined.

This adds the contributor-facing layer, plus the one small piece of code it depends on.

The guide (docs/contributing.md, canonical on the site; root CONTRIBUTING.md is a pointer, matching zarr-python's split) leads with the load-bearing scope limits and the reason for each, so a contributor can self-assess before writing rather than in review. Then dev setup, the one-framework-per-environment test caveat, code standards, failing-test-first for bugs, and what a performance claim has to carry.

GOVERNANCE.md adapts the Zarr Project's affiliated-project template (CC-BY-SA, attribution kept): merit-based core-developer group, lazy consensus with a vote as last resort, and a stated intent to seek Zarr Affiliated Project status — we already meet two of the three published criteria. It says plainly that one maintainer is a transitional state. One project-specific rule: changes to the load-bearing invariants are never made by lazy consensus.

CODE_OF_CONDUCT.md is Contributor Covenant 3.0 verbatim; SECURITY.md routes credential/transport issues upstream to obstore/zarr/icechunk and keeps the cache and transform-loading paths in scope.

Issue forms are shaped by what triage actually needs. The bug form asks for print_debug_info() output and the chunk geometry; there is a dedicated performance form asking for store geometry, loader config, hardware including vCPU count, and a control run, because a throughput report without those is not actionable. The feature form asks "does this touch a load-bearing invariant?" as a dropdown — the single highest-yield triage question here.

insitubatch.print_debug_info() is the only code change. It reports the storage stack, whichever framework adapter is installed, and the free-threading state as two facts — build flag and live GIL — since numcodecs re-enables the GIL on import and those diverge. Nothing is imported to report on it (distribution metadata only), because importing torch and JAX in one process crashes.

On AI-assisted contributions the line is drawn at accountability, not authorship of prose. This project is built with AI assistance including drafted PR descriptions, and a rule the maintainer breaks daily is not a rule. What is required: a human reviewed every change, can explain why each is correct, and verified the claims in the description.

Repo settings applied alongside this: Discussions enabled (the issue-chooser link depends on it) and a performance label created.

For reviewers

Three things worth a second look, in order:

1. The scope-limit section (docs/contributing.md) — it is now a public commitment, so it should say what you actually intend to enforce. It restates CLAUDE.md's invariants with reasoning; the two are paired, and CLAUDE.md carries a note explaining why its "Do not" list has three entries where the guide's has four (the frameworks rule is deliberately repeated in the guide's scannable list).
2. The Zarr affiliation intent in GOVERNANCE.md — framed as direction, not a claim of existing affiliation, but it is a public statement about an external body.
3. The AI policy wording — deliberately weaker than zarr's "I am a human, these are my changes", which this project would fail on its own PRs.

Confident in: the templates render and parse, and the docs build clean under --strict.

Author attestation

• I have reviewed every change in this PR, I can explain why each one is correct, and I have verified the claims made in this description.

Left unchecked deliberately. This description was drafted by Claude Code. The box asserts that a human reviewed every change and verified these claims — an assistant ticking it on the author's behalf is exactly the failure the policy this PR introduces exists to prevent. @emfdavid to review and tick.

Checklist

• Tests added or updated — tests/test_debug.py (4 tests: required keys, absent optionals degrade, the free-threading line states both halves, output is pasteable)
• ruff check / ruff format --check, mypy src bench examples and pytest -q green locally — 308 passed, 12 skipped
• Docstrings and API docs for the new public surface (docs/api.md gains a Debugging section)
• User-facing behavior documented in docs/*.md
• A bullet added under ## Unreleased in CHANGELOG.md (two: the helper, and the governance model)
• No load-bearing invariant is broken — print_debug_info() is off the hot path entirely and imports nothing
• Free-threaded (3.13t) run — n/a, nothing here touches ChunkPool, the scheduler, or cross-thread readiness
• Performance claim — n/a, no performance claim made

Not in this PR

The issue tracker still shows 0 open issues. Seeding four to six good-first-issues from DESIGN.md's Known limitations & defects is the highest-leverage remaining step — a contributor who reads the guide, agrees with it, and finds nothing to work on is one lost at the last step.

🤖 Generated with Claude Code