通信
在哪里提问、提交错误报告、提议功能，以及如何联系团队。
如果您只是想与我们交流，请使用 Discord。 对于需要持久记录的内容（如 bug、功能请求、设计讨论、RFC），请使用 GitHub。
Discord：联系团队的最佳途径
实时聊天。这是维护者日常交流的地方；获得人工回复的最快途径。
频道：
#general：默认房间#help：“我没法让 X 正常工作”类讨论帖；最快的解决问题方式#dev：进行中的开发讨论#releases：公告、发行说明、重大变更预警
Discord 是临时性的：如果对话引出了某个 bug 或功能创意，请随后将其记录为 GitHub issue，以便记录得以留存。Discord 用于交流；GitHub 用于留存记录。
当 Discord 产生项目必须记录的内容时，使用 GitHub 进行交接。当讨论串产生可复现的 bug、具体的功能范围、架构或治理决策、维护者承诺、负责人分配、里程碑决策、阻塞项、临时解决方案、验证证据、发布影响说明或过期豁免原因时，创建或更新 issue、discussion、PR 评论或维护者文档。交接内容只需包含决策、证据、负责人（如有），以及足够的上下文，使另一位维护者无需重读聊天记录即可继续工作。
GitHub 问题
用于跟踪错误、功能请求以及任何需要记录的事项。
- 错误报告：使用错误报告模板（
.github/ISSUE_TEMPLATE/bug_report.yml）。请附上zeroclaw --version、操作系统信息，以及zeroclaw doctor的输出。 - 功能请求：使用功能模板（
.github/ISSUE_TEMPLATE/feature_request.yml）。重点说明用户价值和约束条件；实现细节应放在 RFC 或 PR 讨论中。 - RFCs：参见 RFC 流程。
在提交之前请先搜索。重复的问题会被合并；搜索框是你的好帮手。
GitHub 讨论
对于面向社区的讨论帖，如果它们比 Discord 需要更强的持久性，但又尚未成为已跟踪的工作项，可以使用此功能。Discussions 非常适合用于问答、创意、项目展示、投票、维护者公告，以及那些在 Discord 中容易被刷屏淹没的“还有其他人遇到这个问题吗？“之类的讨论帖。
将讨论（Discussions）视为非紧急的社区交流。仅当有专人负责或记录了审查节奏时，它们才属于维护者处理范围。维护者日常工作和默认节奏请参阅 审查者操作手册：讨论管理。
Discussions 是 GitHub 交接系统的一部分，而非 issues、RFC、PR 评论或维护者文档的替代品。一旦某个 Discussion 产生了具体的 bug、功能范围、负责人、阻塞项、验证证据、策略决策或文档需求，就应将其转入受跟踪的处理流程中。
在选择平面时使用此分割：
| Surface | 用于 | 移动时机 |
|---|---|---|
| Discord | 快速帮助、实时协调以及早期的“这是个问题吗?“讨论 | 项目需要一份持久记录、决策、负责人、验证说明、阻碍因素或发布影响说明 |
| 讨论 | 可搜索的问答、想法、展示分享、演示、投票、公告、广泛反馈，以及尚未准备好正式跟踪的探索性架构问题 | 该讨论串可产生具体的缺陷、功能范围、架构提案、策略决策、文档缺口、负责人、阻塞项或验证证据 |
| 问题 | 缺陷、功能请求、支持/配置报告、贡献者任务、路线图跟踪以及其他需要分类或跟踪的工作 | 该议题将转化为 RFC、PR、追踪项、重复项、支持重定向或关闭决定 |
| RFC 问题 | 需要正式评审的架构、治理、生命周期、兼容性或流程决策 | 该 RFC 被接受、拒绝、取代，或拆分为多个实现问题 |
| PR 评论 | 审查活动变更的反馈和实现细节 | 细节会转化为持久的策略、可复用的文档、后续的 issue 或发布说明 |
讨论分类应当让预期结果一目了然。Q&A 用于可解答的问题，Ideas 用于需要社区共同打磨的提案，Show and tell 用于人们想要分享的项目相关演示、集成或下游分支，Polls 用于社区投票，Announcements 用于维护者更新，General 则用于宽泛的可检索对话、早期架构探索，或尚未纳入工作追踪的下游/分支/企业协作。如果下游协作变得足够频繁，需要专门的管理通道，维护者后续可以添加一个专属分类。
当讨论转移时，请闭环跟进。添加简短的总结，并链接到现在负责该结果的 issue、RFC、PR 或文档。如果该分类支持采纳答案，且能准确反映结果，请将总结或跟踪工作的链接标记为答案。
github.com/zeroclaw-labs/zeroclaw/discussions
维护者联系方式
以下所有人员均为核心团队成员，即 FND-003 §5 中定义的 Tier 3 角色。成员资格来自邀请及公开公告，详见 §5.1；本表为上述决策的已发布摘要，而非确立成员资格的记录。请注意，本表可能与 core-contributors GitHub 团队及协作者列表存在差异——后两者为访问控制机制而非成员资格记录：其中包含自动化账号，且访问权限可能为直接授予、继承或待处理状态。有关各记录所回答问题的说明，请参阅 §5.3。
Focus 列描述的是每位成员的工作重点，而非其所持有的权限级别：Core Team 采用扁平化结构。日常决策通过惰性共识机制运行，而 CODEOWNERS 变更、发布、RFC 结果、治理编辑以及 Core Team 成员新增，均需经过 Core Team 的明确投票，与角色无关。“项目负责人“是 Core Team 内部的协调与上报角色，而非凌驾于其上的层级。
| 处理 | 角色 | 焦点 |
|---|---|---|
| @JordanTheJet | 核心团队，项目负责人 | Web、插件和技能、桌面应用、测试和仓库工具、Cargo 和许可证管理 |
| @Audacity88 | 核心团队 | 运行时、代理、工具、网关、内存、配置、提供商、构建和发布工具 |
| @Nillth | 核心团队 | Git 代码托管渠道（GitHub、Gitea、Forgejo） |
| @tidux | 核心团队 | 提供商、API、基础设施、硬件、固件、频道（Matrix、ACP）、身份验证以及旧版 src/ 目录树、国际化、文档 |
| @IftekharUddin | 核心团队 | Web 图形界面、维护者流程文档、标签和 issue 模板 |
| @vyahhi | 核心团队 | 仓库自动化和 ZeroClaw-Bot |
| @Stalesamy | 核心团队 | 市场营销和社区，以及偶尔的 PR |
| @perlowja | 核心团队 | 市场营销和社区，以及偶尔的 PR |
并非列出的所有人都会审查代码。请根据 Focus 列和 CODEOWNERS 来分配代码审查，而非根据层级。
关注领域遵循 .github/CODEOWNERS，后者是权威的路由记录。此表是便于人工阅读的摘要；如果两者不一致，以 CODEOWNERS 为准。
谨慎使用 @ 提及，只有当问题确实需要维护者关注时才抄送他们。默认情况下让团队进行分类处理。
安全问题
请勿为安全漏洞提交公开问题。
通过 GitHub 的私密漏洞报告（Security Advisories）私下报告。
包含：
- 受影响的版本
- 复现（请提供最小示例）
- 影响评估
我们的目标是在 48 小时内确认、在 1 周内评估，并在 2 周内针对严重问题发布修复。我们感谢您进行协调披露。
有关完整策略，请参阅仓库根目录下的 SECURITY.md。
发布说明
订阅 GitHub 版本更新源，以便在新版本发布时收到通知：
https://github.com/zeroclaw-labs/zeroclaw/releases.atom
或在 GitHub 上关注该仓库（Watch → Custom → Releases）。
发行说明会同步发布到 Discord 的 #releases 频道以及社区 Twitter 账号。
商业支持
未提供。ZeroClaw 由社区维护。如果您需要大规模部署并希望获得 SLA 支持，可以直接赞助维护者，或通过核心团队资助专门的支援方案。请通过 hello@zeroclaw.dev 联系我们。
反馈
开放式反馈，例如“我尝试做 X，但感觉不对“、UX 观察、方向性想法，当需要快速实时交流时，最适合作为 Discord #general 或 #dev 中的话题发布。当反馈需要保持可搜索性以便社区异步参与时，请使用 GitHub Discussions 的 General 或 Ideas。如果讨论逐渐形成具体内容，请将其转移到 issue、RFC、PR 评论或文档中。
贡献者认可
每个有 PR 被合并的人都会出现在仓库的贡献者列表中。对于重大贡献、功能、RFC 以及重要的错误修复，你的用户名会出现在发布说明中。