社区治理
说明维护角色、问题分流、内容证据、决策方式和版本发布规则。
子比主题开发文档采用公开仓库协作。社区治理的目标不是增加流程，而是让问题、结论和发布结果都能被追踪，并避免未经核对的源码推断直接进入正式文档。
维护角色
| 角色 | 主要职责 |
|---|---|
| 维护者 | 管理仓库设置、分类、发布、权限、安全报告和最终合并 |
| 文档贡献者 | 核对源码、补充 MDX、修正文案、维护链接和示例 |
| 工具贡献者 | 维护 MCP、Codex 插件、构建脚本、自动化和测试 |
| 社区成员 | 提交可复现问题、讨论方案、分享案例、申请友情链接和参与代码审查 |
当前默认维护者由 .github/CODEOWNERS 指定。新增维护者时，应同时更新 CODEOWNERS、本文和仓库权限，避免文档中的职责与 GitHub 实际权限不一致。
信息如何流转
- 可以复现的错误进入 Issue，并附页面、版本、路径、步骤和实际结果。
- 尚未形成明确修改任务的方案进入 Discussions，结论确定后再转为 Issue。
- 文档、组件、MCP 或工作流修改通过 Pull Request 合并，并关联对应 Issue。
- 安全问题通过 GitHub Security Advisories 私下报告，不进入公开讨论。
- QQ 群用于即时交流；能复用的结论需要回写到 Issue、Discussion 或文档。
文档页底部反馈由 GitHub App Bot 创建带页面上下文的 Issue。友情链接申请由 Issue Form 收集信息，Action 只负责格式校验和创建待审核 PR，最终收录仍由维护者确认。
内容证据
正式文档按以下优先级核对：
- 当前可复现的主题、子主题或插件运行行为。
- 当前版本实际加载的源码、模板、Hook、Ajax action 和配置结构。
- 官方公开文档、更新记录和可验证示例。
- 社区案例和历史经验。
如果证据冲突，应在页面中注明适用版本和不确定范围，不把推测写成稳定接口。主题源码和用户项目不得直接提交到公开仓库；只能提交经过授权、脱敏且确有必要的最小片段。
合并与发布
- 小型文案、链接和明确错误可由维护者直接审查合并。
- 新分类、公共组件、MCP 工具和工作流修改必须通过类型、格式、构建、导航、社区配置和协议检查。
- 影响路由、静态资源地址或多语言入口的修改，需要验证 GitHub Pages 项目子路径。
zibll-docs-mcp使用mcp-v<版本>标签发布，标签必须与包版本一致。- Pages 在
main更新后自动构建；删除页面时，构建脚本会先清空旧导出，避免残留路由继续可访问。
决策原则
维护者优先选择能被当前源码和构建结果验证的方案。涉及兼容性、社区规则或长期维护成本的变更，应先在 Discussion 记录背景、替代方案和取舍；存在争议时，以可复现证据、文档准确性、安全边界和维护成本为判断依据。
相关入口
Was this document helpful?