docs(community): add contributor onboarding and issue templates

[Timur Tukaev (tym83)]

Summary

Nothing in the project told a newcomer what to do first. The material exists, but
it is split in two places and neither is addressed to a first-time contributor:
the website Developer Guide
explains platform internals and per-package make targets, while
docs/agents/contributing.md
holds the actual commit, sign-off, regeneration and pull-request conventions
behind a title that reads as if it were not meant for humans.

What

contributors/README.md — a standalone walkthrough assembled from both
sources, in the order a contributor needs it: pick a task, work out which
environment the change requires, set up the fork, regenerate what is generated,
verify, commit, rebase, open the PR, and what to expect afterwards.

Three things it says that were not written down anywhere:

• Environment cost is tiered. Charts, values, ApplicationDefinitions,
  dashboards and docs need nothing but Go and Docker. Only end-to-end work needs
  the three-QEMU-VM setup at 8 vCPU and 24 GiB each. Contributors were previously
  left to discover the 72 GiB requirement themselves, or assume it applied to
  everything.
• Build jobs failing on a fork PR are the project's problem, not the
  contributor's. Forks cannot authenticate to the image registry, so any build
  job that pushes an image fails regardless of the change. Two currently approved
  external PRs are red for exactly this reason.
• A bot comment is not a review. Every recent first-time PR was met first by
  CodeRabbit or Gemini, and several got no human response at all. The document
  states that a human answer is due within two business days and that chasing it
  is legitimate.

.github/ISSUE_TEMPLATE/governance.md and community.md — the README
routes governance, process and community matters to this repo, but the repo
offered only a blank issue. Both templates are short: what the issue is, where it
shows up, what should happen. The governance template asks for both the written
rule and the actual behaviour when the two disagree.

config.yml — two new contact links, for the onboarding guide and the
community meeting.

Why

Deliberately not a rewrite of the existing documentation. The downstream trigger
map and the gh api graphql recipe for unresolved review threads stay in
docs/agents/contributing.md and are linked, not copied — one copy, one owner.
What is duplicated here is only the material a newcomer cannot proceed without.

[gemini-code-assist]

Caution

The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 5eb6e061-0f67-4f16-8296-f8e8475bf336

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[IvanHunters]

Reviewed against the actual tree (Makefile, workflows, docs/agents/contributing.md), not just the diff. Almost all of the CI/generation claims check out verbatim: the make targets, per-package show/generate, the -rd/cozyrds ApplicationDefinition layout, the area/uncategorized labeler fallback, the 3×(8 vCPU / 24 GiB) e2e VMs with the IPv4-forwarding check, both contributing.md anchors, the Assisted-By: trailer, and the fork/registry mechanism. Two things to fix before this onboards anyone:

Blocking, an undocumented commitment. "A human response is due within two business days" is not written down anywhere in the repo. ## Review Expectations (contributing.md:264) sets no response-time SLA, and the only business-day commitments are security-side with different numbers (SECURITY.md:52 3 days, docs/security/incident-response.md:34 7 days, CONTRIBUTOR_LADDER.md:154 5 days for offboarding). As written this promises a maintainer SLA the project never agreed to. Either soften it ("expect a human reply; pinging if it has been a while is legitimate") or add the rule to GOVERNANCE first and link it.

Fix, CI mechanism named wrong. "CI runs make generate across every package and then git diff --exit-code": there is no git diff --exit-code in CI. Drift is caught by codegen-drift.yml:57 (root make generate + git status --porcelain) plus the per-package run-make-generate pre-commit hook. The net effect is right, the mechanism is not, worth wording accurately since newcomers will trust it.

Non-blocking:

• contributors/README.md links ../community_meeting.md, which is added in docs(community): publish the meeting archive and how the meeting runs #47, not here. Merge docs(community): publish the meeting archive and how the meeting runs #47 first or the link is dead.
• The rebase recipe in step 7 (git cherry-pick <your-commit-hash>) only moves a single commit; a branch with several commits would silently lose the rest. git rebase upstream/main is safer to recommend.