如何成为 Contributor
Contributor 新人指南
订阅公共邮件列表
请订阅{dev,commits}@doris.apache.org 邮件列表，通过发送邮件到{dev,commits}-subscribe@doris.apache.org 完成订阅。 commits 邮件非常重要，因为所有的 GitHub Issue，PR 提交都会发往这个邮件列表。
Code Review 指南
始终保持一个较高的标准来进行 review，这样才能更好地保证整个产品的质量。
对于用户接口类的、整体架构方面的修改，需要在社区进行充分地讨论，可以在邮件组发起，也可以在 issue 上发起。 用户接口的改变包括支持新的 SQL 函数，支持新的 HTTP 接口，支持新的功能等。这样能够保证产品的一致性。
测试覆盖。新增的逻辑需要有对应的测试来覆盖。对于已有老代码，不好增加的可以酌情考虑。
文档。新增加的功能必须要有文档来说明，否则这样的代码不允许合入。必须要有英文文档，最好有中文文档。
代码的可读性。如果 review 的同学对于代码逻辑不是很清晰，那么可以要求 contributor 去解释这段逻辑，并且需要在代码里写充分的注释来解释逻辑。
尽量在评论的结尾给出明确的结论。是同意，还是要 change request。如果是小问题，可以只留评论。
如果你已经看过了代码，觉得没有问题，但是觉得需要其他同学来确认下，可以留下 +1 Comment。
互相尊重，互相学习。在评论的时候保持礼貌的口吻，提建议尽量给出建议的理由。
Pull Request 指南
一个 PR 合入需要三种角色的参与。Contributor：PR 的提交者；Reviewer：对 PR 进行代码级评论的人；Moderator：PR 合入的协调者。 Moderator 主要负责给 PR 设定相关标签，推动相关 reviewer 进行评论，推动作者对 PR 进行修改，合入 PR 等工作。 在一个具体的 PR 中，一个人可能充当不同的角色，比如一个 Contributor 自己提交的 PR，既是 Contributor，又是这个 PR 的 Moderator。
Contributor 可以把一个 PR 分配给自己作为整个 PR 的 moderator，负责后续 PR 的推动工作。分配给自己之后，其他的 Contributor 就知道这个 PR 有相关人负责了。
鼓励 Contributor 作为自己 PR 的 Moderator。
Reviewer 需要进行代码级的 review，可以参考 Code Review Guideline。
Reviewer 一旦评论了某个 PR 之后，需要持续跟进这个 PR 的后续改动，不鼓励评论了之后就不再管 Contributor 的后续回复了。
一个 PR 至少要获得一个非作者外的 Committer +1 才能进行被合入。
PR 获得第一个 +1 后，至少要等一个工作日后才能进行合入。主要目的是等待社区其他同学来进行 review。
对于接口类、整体架构方面的修改，至少要获得 3 个 +1 才能进行合入。
需要回归测试全部通过才能被合入。
Moderator 需要在确定所有的评论都被回复之后才能进行代码合入。
代码合入选择“squash and merge”方式进行合入。
对于一个修改不同的 reviewer 有争议时，可以尝试讨论解决。如果讨论没有办法解决，可以在 dev@doris.apache.org 中发邮件投票解决，采取少数服从多数的原则。
新增外部依赖
在引入外部依赖项时要格外谨慎。当需要引入新库时，我们需要考虑以下因素。
新增的外部库提供了什么功能？现有的库能否提供此功能（可能需要一些努力）？
外部库是否由活跃的贡献者社区维护？
新增库的许可条款是什么。
你是否将库添加到基础模块？这将影响 Doris 代码库的其他部分。以 Java 为例，如果新库引入了大量传递依赖项，那么我们可能会遇到类冲突的意外问题， 这些问题很难通过测试发现，因为这取决于运行时加载库的顺序。
