社区
关于 Druid 的大部分讨论都在 Slack、GitHub 和 Apache 开发邮件列表上进行，但这并不是与 Druid 社区互动的唯一方式。我们还有聊天、聚会等更多交流渠道。
如果您正在寻求帮助、讨论 Druid 开发或只是想了解最新动态，请查看以下资源：
- Slack： 许多用户和提交者都在 Apache Druid Slack 上。使用此链接加入并邀请他人：https://druid.org.cn/community/join-slack。如果您需要帮助，这里是提问的最佳场所！
- GitHub： 在 apache/druid 给我们加星，并利用它关注 Druid 开发、提出问题或提交 Pull Request。如果您对开发感兴趣，请参阅下方的贡献部分，了解有关我们开发流程的详情。
- 开发邮件列表： dev@druid.apache.org 用于讨论项目开发。要加入，请发送邮件至
dev-subscribe@druid.apache.org。 - Twitter： 在 Twitter 上关注我们 @druidio。
还可以查看
- 用户邮件列表： druid-user@googlegroups.com 用于一般性讨论、问题咨询和公告发布。
- LinkedIn： 在 LinkedIn 小组中与其他 Apache Druid 专业人士建立联系。
- Meetups（线下聚会）： 在 meetup.com 上的 Apache Druid 查看世界各地定期聚会的链接。
- StackOverflow： 虽然用户邮件列表是提问的主要资源，但如果您更喜欢使用 StackOverflow，请务必为您的问题打上
druid或apache-druid标签。 - Linen： 查看 Linen 上的 Apache Druid 社区，获取 Apache Druid Slack 讨论串的数字归档。虽然 Slack 将消息历史记录限制在最近 90 天内，但您可以在 Linen 上继续访问更早的讨论串。
- Struct： 查看 Struct 上的 Apache Druid，获取由 Apache Druid Slack 讨论串生成的 AI 知识库。与 Linen 类似，Struct 对 Slack 讨论串进行归档，以便您能够访问超出 Slack 90 天保留期限的消息。
寻求帮助
获取有关 Druid 各类帮助的最佳地点是 Slack。使用此链接加入并邀请他人：https://druid.org.cn/community/join-slack。
您也可以在 GitHub 上报告问题或建议新功能。
第三方公司也为 Druid 提供商业支持和服务，包括：
贡献
Druid 是一个社区主导的项目，我们很高兴收到任何形式的贡献，从小的修复到重大的新功能。
可以做什么
如果您有想解决的问题，请务必去做！修复您遇到的错误，或添加您需要的功能，这些都非常有帮助。
如果您正在寻找一些入门项目，我们维护了一份适合新开发者的议题列表。
除了编写 Druid 代码之外，还有很多方式可以提供帮助。Pull Request 的代码审查（即使您不是提交者）、功能建议、报告错误、文档和可用性反馈都极其重要。另一个重要的帮助方式是提供客户端库，它们涵盖多种编程语言。如果您开发了新的客户端库，我们很乐意将其包含在列表中。
让您的更改被接受
对 Druid 的修补通过 GitHub Pull Requests 完成。
Pull Request 需要获得一位资深提交者在代码和文档层面的批准（+1）。重大的架构变更、API 变更和/或以下内容的变更除外：
- HTTP 请求和响应（例如新的 HTTP 端点）
- 扩展接口
- 服务器配置（例如更改配置属性的行为）
- 输出的指标
- 以及 Druid 提交者认为属于重大的其他变更
这些变更需要额外的设计和兼容性审查。此类 Pull Request 需要获得三位不同提交者的设计批准（其中一人可以是 Pull Request 的作者）。对于这些变更，事先在 Druid 开发邮件列表 dev@druid.apache.org 或 GitHub Issue 上讨论会有所帮助。
总体而言，发送 Pull Request 时请遵循贡献指南。这将有助于审查尽可能快地进行。
测试
所有 Pull Request 都会通过 GitHub Actions 在 AMD64 和 ARM64 架构上进行自动测试。
提交者
提交者共同负责 Druid 的技术管理。这包括确定项目方向、贡献代码以及审查他人贡献的代码。
您无需成为提交者即可做出贡献——我们欢迎任何人提交 Pull Request。
成为提交者
如果您想成为一名提交者，那太好了！请联系现有的提交者之一了解流程。简而言之，我们寻找的是对持续向 Druid 做出贡献有兴趣的人。
通用提交者指南
如果您是一位正式的 Druid 提交者，那么恭喜您！您是这个杰出团队的一员。以下是一些指导原则，以帮助确保 Druid 项目持续成长和改进：
- 如果符合其余标准，您可以合并自己的 Pull Request。常见的情况是收到其他提交者“在 Travis 通过后的 +1”。
- Pull Request 在“代码/文本”审查层面，应至少获得一位非作者提交者的 +1 批准。
- 仅获得一位提交者 +1 的 Pull Request 在提交 PR 后至少 3 个工作日内不得合并。
- 仅获得一个 +1 的 Pull Request 只能由提供审查的提交者（或与其协调）进行合并。这是因为审查者可能认为该 PR 复杂或具有风险，需要第二双眼睛来查看。如果是这种情况，第一位审查者应在 PR 批准消息中明确指出。
- 如果 Pull Request 获得了两位或以上非作者提交者的 +1，则可以立即由任何提交者合并。但仍需保证自 PR 提交以来经过了足够的时间，以便给其他人留出表达评论意愿的合理机会。换句话说：不要合并周五晚上提交的 Pull Request，直到至少经过 1-2 个常规工作日。请在这里使用良好的判断力。
- 重大的架构变更和不向后兼容的变更，或具有长期维护后果的变更（参见上文“让您的更改被接受”部分中的示例），应在“设计”审查层面至少获得三位提交者的 +1。其中一个批准可以来自 PR 作者。第一位指出 PR 需要设计审查的提交者应为该 Pull Request 添加
Design Review标签。 - Travis-CI 应该通过，或者对于 Pull Request 而言有非常充分的理由说明为何它无法通过。
- 您有合理的理由相信所有评论都已得到处理。
- 期望您成为自己 Pull Request 的拥护者（Champion）。
- 根据代码变更的大小及其涉及的代码部分，作为 Pull Request 的拥护者可能是一项重大任务。它可能需要与其他开发者沟通、协调分歧、组织社区反馈，和/或跟进在 Pull Request 中发表评论的人，以确保评论得到处理。
- 有时代码是作为正在进行的工作（WIP）或讨论点提出的。在这种情况下，请在 Pull Request 上使用
WIP或Discuss标签。 - 如果您所拥护的 Pull Request 合并时间超过预期，请务必在开发者同步会议上提出该问题。
- 限制您同时拥护的 Pull Request 数量。
- 优先审查那些阻塞下一个版本的 Pull Request（查看 Pull Request 上的里程碑标记）。
- 协助作为来自新提交者的 Pull Request 的拥护者。
- 如果您认为某个 Pull Request 对下一个版本是必需的，请在 Pull Request 的 Milestone（里程碑）中进行标记。
- 除非您愿意跟进编辑工作，否则不要在 Pull Request 上发表评论。
- 优先合并较旧的 Pull Request。（作为它们的拥护者或活跃评论者）
- 最重要的是……PMC 希望确保开发者获得积极而高效的体验！如果您发现事情不如预期，请提出该问题。
记住，我们都希望看到这个项目蓬勃发展！
治理
PMC（项目管理委员会）负责 Druid 项目的行政方面。PMC 的职责包括：
- 批准发布
- 提名新提交者
- 维护项目的共享资源，包括 GitHub 帐户、邮件列表、网站、社交媒体渠道等。
- 维护项目指南