贡献者沟通
本文档解释了如何在 Model Context Protocol (MCP) 项目中进行沟通和协作。
沟通渠道
简而言之:
- Discord:用于实时或临时讨论。
- GitHub Discussions:用于结构化的、长篇讨论。
- GitHub Issues:用于可操作的任务、错误报告和功能请求。
- 对于安全问题:遵循 SECURITY.md 中的流程。
所有沟通都受我们的行为准则约束。我们期望所有参与者在所有渠道中保持尊重、专业和包容的互动。
Discord
用于实时贡献者讨论和协作。该服务器围绕 MCP 贡献者设计,不打算作为一般 MCP 支持的场所。
Discord 服务器将同时具有公共和私人频道。
公共频道(默认)
- 目的:开放社区参与、协作开发和透明的项目协调。
- 主要用例:
- 公共 SDK 和工具开发:所有开发,从构思到发布规划,都在公共频道中进行(例如,
#typescript-sdk-dev、#inspector-dev)。 - 工作和兴趣组讨论
- 社区入门和贡献指导。
- 社区反馈和协作头脑风暴。
- 公共办公时间和维护者可用性。
- 公共 SDK 和工具开发:所有开发,从构思到发布规划,都在公共频道中进行(例如,
- 避免:
- MCP 用户支持:参与者应该阅读官方文档,并针对问题或支持开启新的 GitHub Discussions。
- 服务或产品营销:在此 Discord 上的互动应该是供应商中立的,不用于品牌建设或销售。除非作为示例或响应最初专注于规范的对话的一部分,否则不鼓励提及品牌或产品。
私人频道(例外)
- 目的:机密协调和不能公开讨论的敏感事项。访问将仅限于指定的维护者。
- 私人使用的严格标准:
- 安全事件(CVE、协议漏洞)。
- 人员事项(与维护者相关的讨论、行为准则政策)。
- 选定的频道将配置为只读。例如,这对于维护者决策制定很有用。
- 需要立即或以其他方式专注响应与有限受众的协调。
- 透明度:
- 所有影响社区的技术和治理决策****必须在 GitHub Discussions 和/或 Issues 中记录,并将标记为
notes。 - 与个人贡献者相关的某些事项可以在适当情况下保持私密(例如,个人情况、纪律处分或其他敏感个人事项)。
- 私人频道应用作临时的"事件室",不用于例行开发。
- 所有影响社区的技术和治理决策****必须在 GitHub Discussions 和/或 Issues 中记录,并将标记为
在 Discord 上的任何重要讨论如果导致潜在决策或提案,都必须移动到 GitHub Discussion 或 GitHub Issue 以创建持久的、可搜索的记录。然后,提案将被提升为完整的 PR,并根据需要包含相关工作项(GitHub Issues)。
GitHub Discussions
用于关于项目方向、功能、改进和社区主题的结构化、长篇讨论和辩论。
何时使用:
- 项目路线图规划和里程碑讨论
- 公告和发布沟通
- 社区投票和共识建立流程
- 具有上下文和理由的功能请求
- 如果特定存储库未启用 GitHub Discussions,请随时改为开启 GitHub Issue。
GitHub Issues
用于错误报告、功能跟踪和可操作的开发任务。
何时使用:
- 具有可重现步骤的错误报告
- 具有特定范围的文档改进
- CI/CD 问题和基础设施问题
- 发布任务和里程碑跟踪
注意:SEP 提案作为拉取请求提交到 seps/ 目录,而不是作为 GitHub Issues。有关详细信息,请参阅 SEP 指南。
安全问题
不要公开发布安全问题。 相反,应该:
- 使用私人安全报告流程。对于协议级别的安全问题,请遵循 modelcontextprotocol GitHub 存储库中 SECURITY.md 中的流程。
- 直接联系负责人和/或核心维护者。
- 遵循负责任的披露指南。
决策记录
所有 MCP 决策都在公共频道中记录和捕获。
- 技术决策:GitHub Issues 和 SEPs。
- 规范变更:在 Model Context Protocol 网站上。
- 流程变更:社区文档。
- 治理决策和更新:GitHub Issues 和 SEPs。
在记录决策时,我们将保留尽可能多的上下文:
- 决策者
- 背景上下文和动机
- 考虑的选项
- 所选方法的理由
- 实施步骤