Where to ask questions, file bugs, propose features, and reach the team.
If you just want to talk to us, Discord is the answer. For anything that needs a durable record (bugs, feature requests, design discussion, RFCs), GitHub.
Real-time chat. This is where the maintainers live day-to-day; the fastest path to a human response.
Channels:
#generalβ the default room#helpβ "I can't get X working" threads; the fastest way to unblock#devβ in-flight development discussion#releasesβ announcements, release notes, breaking-change pre-warnings
Invite link in the repo README.
Discord is ephemeral β if the conversation leads to a bug or a feature idea, capture it as a GitHub issue afterwards so the record persists. Discord is for conversation; GitHub is for memory.
Use a GitHub handoff when Discord produces something the project must remember. Create or update an issue, discussion, PR comment, or maintainer doc when the thread produces a reproducible bug, concrete feature scope, architecture or governance decision, maintainer commitment, owner assignment, milestone decision, blocker, workaround, validation evidence, release-impact note, or stale-exemption reason. The handoff only needs the decision, evidence, owner when one exists, and enough context for another maintainer to continue without rereading chat.
For bugs, feature requests, and anything that needs to be tracked.
- Bug reports β use the bug template (
.github/ISSUE_TEMPLATE/bug_report.yml). Includezeroclaw --version, OS, and the output ofzeroclaw doctor. - Feature requests β use the feature template (
.github/ISSUE_TEMPLATE/feature_request.yml). Focus on user value and constraints; implementation details are for RFCs or PR discussion. - RFCs β see RFC process.
Search before filing. Duplicates get consolidated; the search box is your friend.
For community-facing threads that need more permanence than Discord but are not yet tracked work. Discussions work well for Q&A, ideas, show-and-tell, project or integration demos, polls, announcements, and "does anyone else see this?" threads where Discord would scroll away.
Treat Discussions as non-urgent community conversation. They are maintained intake only when a steward or review cadence is documented.
Discussions are part of the GitHub handoff system, not a replacement for issues, RFCs, PR comments, or maintainer docs. Move a Discussion into the tracked surface once it produces a concrete bug, feature scope, owner, blocker, validation evidence, policy decision, or docs requirement.
github.com/zeroclaw-labs/zeroclaw/discussions
Core maintainers and their focus areas:
| Handle | Role | Focus |
|---|---|---|
| @JordanTheJet | Project lead | Hardware, edge deployments |
| @theonlyhennygod | Original creator | Channels, gateway |
| @WareWolf-MoonWall | Maintainer | Governance, docs, reviewer playbook |
| @singlerider | Maintainer | Runtime, providers, infra |
@-mention sparingly β CC maintainers only when the issue genuinely needs their attention. Default to letting the team triage.
Do not file public issues for security vulnerabilities.
Email: security@zeroclaw.dev
Include:
- Affected versions
- Reproduction (minimal, please)
- Impact assessment
We aim to acknowledge within 48 hours and publish a patch + advisory within 14 days for critical issues. Coordinated disclosure is appreciated.
See SECURITY.md in the repo root for the full policy.
Subscribe to the GitHub release feed to be notified when new versions ship:
https://github.com/zeroclaw-labs/zeroclaw/releases.atom
Or watch the repo on GitHub (Watch β Custom β Releases).
Release notes are cross-posted to Discord #releases and the community Twitter.
None offered. ZeroClaw is maintained by the community. If you're deploying at scale and want SLAs, sponsor a maintainer directly or fund a dedicated support arrangement through the core team. Reach out via hello@zeroclaw.dev.
Open-ended feedback β "I tried to do X and it felt wrong", UX observations, direction thoughts β lands best as a thread in Discord #general or #dev. The team is more likely to see and discuss it there. If the thread turns into something concrete, move it to a GitHub Discussion or issue.
Everyone who's had a PR merged appears in the contributors list on the repo. For substantial contributions β features, RFCs, significant bug fixes β your handle shows up in the release notes.
- How to contribute
- RFC process
- Philosophy β what the project is trying to be, so you know what's in scope