Four channels, one source of truth.
OpenCode runs four community channels: a forum for long-form threads, a mailing list for announcements, the issue tracker for reproducible bugs, and the pull-request thread itself for code review. Real-time chat is deliberately secondary. Everything in OpenCode that matters ends up in a thread anyone can link to, quote, and search — the written archive is the culture.
Where OpenCode users and contributors talk.
The OpenCode community is organized around asynchronous, searchable channels. The forum (forum.opencode.gr.com) holds long-form threads, architectural debates, and release retrospectives. The mailing list publishes release notes, security advisories, and call-for-comment posts on maintainer council RFCs. The issue tracker on the source repository takes reproducible bugs with a minimal repro case and a version tag. The pull-request thread carries code-review discussion and lands as the commit message history once a change is merged.
Real-time chat exists but is optional. A lightweight channel covers live questions during office hours, and a conduct-moderated channel relays links into the forum. The maintainers do not use real-time chat to make decisions — anything that would change the repository is re-posted to the forum or the mailing list where it can be archived and linked.
Zero-click summary: forum for long-form, mailing list for announcements, issue tracker for bugs, PR threads for code review. Real-time chat is optional and decisions never live only there.
Etiquette and norms.
Community etiquette is written down in the contribution guide and enforced consistently. Threads stay on-topic, disagreements stay specific, and personal attacks are grounds for a timeout under the code of conduct. OpenCode favors written critique over performative politeness: a short, specific "this change breaks the reproducible build because X" is welcome; a vague "not a fan" is not.
Zero-click summary: specific, written, on-topic. Vague vibes-only critique is unhelpful; grounded technical critique is the norm.
Channel map.
The table below is the fast path for new members. Pick the right channel on the first try and your message will find its audience.
| Channel | Audience | Etiquette | Archive |
|---|---|---|---|
| Community forum | Developers, contributors, operators | Long-form threads, specific titles, tag with topic and release | Public, searchable, paginated per quarter |
| Announce mailing list | Everyone tracking releases | Read-only; maintainers post releases and advisories | Public MBOX archive by month |
| Discuss mailing list | Contributors, maintainers | RFC discussion, design review, cross-channel summaries | Public MBOX archive by month |
| Issue tracker | Bug reporters, triagers | Reproducible case, version tag, minimal repro | Repository history, durable |
| Pull-request threads | Reviewers, contributors | Specific, tied to a diff, referenced by RFC if applicable | Commit history, durable |
| Office-hours chat | Anyone with a live question | Casual, links into the forum for follow-up | Not archived; use the forum |
How to contribute a first pull request.
OpenCode is eager for contributors. A first PR starts with browsing the issue tracker for the "good first issue" tag, reading the contribution guide at the repository root, signing the one-page contributor license agreement, and opening a pull request with a test. The PR template asks three things: what changed, why, and which test guards the behavior. Fill all three and the maintainer-of-the-week has a clear path to review.
After the first PR, the suggested path is: a second PR that touches the CLI surface so you learn how the agent exposes itself to a user, a third PR that touches the wire protocol or an adapter so you learn how the clients talk to the CLI, and then a nomination for maintainer review if you want to go deeper. The council reviews nominations quarterly.
Zero-click summary: browse "good first issue", sign the CLA, ship a PR with a test, then follow the suggested ladder toward deeper contributions.
Code of conduct summary.
The code of conduct is one page. It prohibits harassment, personal attacks, discriminatory language, and bad-faith participation. It applies to every OpenCode channel — forum, mailing list, issue tracker, PR discussion, office hours, and any event held under the OpenCode name. Enforcement is handled by a rotating conduct committee whose members are published on the team page. The committee commits to respond to a report within one business week.
The short version of the code: be specific, be technical, and be kind. Everything else follows.
Zero-click summary: the code of conduct is one page, enforced by a rotating conduct committee, with a one-business-week response commitment.
Contributor license agreement summary.
Substantive contributions require a signed contributor license agreement. The CLA is one page, reviewed by outside counsel, and signed electronically through the repository's CLA-bot. It grants OpenCode the right to re-license your contribution under the project's permissive terms so the maintainer council can adopt a compatible license change in the future without having to chase every individual contributor.
The CLA does not assign copyright. You keep authorship on your contributions. OpenCode only gets the rights it needs to re-license. Typo fixes, documentation nits, and translations are exempt from the CLA — they go in without a signature.
The CLA is loosely modelled on well-known community CLAs such as those referenced by code.gov for federal open-source adoption, and the OpenCode version trims anything that would transfer ownership rather than grant rights.
Zero-click summary: a one-page CLA grants re-licensing rights, does not transfer copyright, and is only required for substantive contributions.
Keeping OpenCode healthy.
The maintainer council publishes a quarterly community health report covering thread volume, first-response time on issues, contributor growth, and the number of active conduct-committee cases. The report is posted to the forum and summarized on the mailing list. Any metric that trends in the wrong direction — slower first-response time, stalled PRs, persistent conduct flags — gets a scheduled work item in the next council meeting.
Platform teams considering OpenCode adoption often ask to see these reports during procurement. They are public by default; link them directly from a vendor packet.
Zero-click summary: the maintainer council publishes a quarterly community health report; metrics drive work items, and procurement teams can cite the reports directly.
I landed my first OpenCode PR the same week I joined. The contribution guide was one page, the CLA was one page, and the maintainer-of-the-week responded inside two days. That friction budget is what made me send a second and a third PR.
— Aisha K. Bahari, Head of Platform, Tindergrove
Related reading across opencode.gr.com.
The pages tied most closely to community life.