TiDB 开源社区指南（上）

做者：申砾

本系列文章旨在帮助社区开发者了解 TiDB 项目的全貌，更好的参与 TiDB 项目开发。大体会分两个角度进行描述：

• 从社区参与者的角度描述如何更好的参与 TiDB 项目开发；
• 从 PingCAP 内部团队的角度展现 TiDB 的开发流程，包括版本规划、开发流程、Roadmap 制定等。

但愿经过一内一外两条线的描述，读者能在技术以外对 TiDB 有更全面的了解。本篇将聚焦在社区参与者的角度进行描述，也就是“外线”。

了解 TiDB

参与一个开源项目第一步老是了解它，特别是对 TiDB 这样一个大型的项目，了解的难度比较高，这里列出一些相关资料，帮助 newcomers 从架构设计到工程实现细节都能有所了解：

• Overview
• How we build TiDB
• TiDB 源码阅读系列文章
• Deep Dive TiKV (Work-In-Process)

固然，最高效地熟悉 TiDB 的方式仍是使用它，在某些场景下遇到了问题或者是想要新的 feature，去跟踪代码，找到相关的代码逻辑，在这个过程当中很容易对相关模块有了解，很多 Contributor 就是这样完成了第一次贡献。 

咱们还有一系列的 Infra Meetup，大约两周一次，若是方便到现场的同窗能够听到这些高质量的 Talk。除了北京以外，其余的城市（上海、广州、成都、杭州）也开始组织 Meetup，方便更多的同窗到现场来面基。

发现能够参与的事情

对 TiDB 有基本的了解以后，就能够选一个入手点。在 TiDB repo 中咱们给一些简单的 issue 标记了 for-new-contributors 标签，这些 issue 都是咱们评估过容易上手的事情，能够以此为切入点。另外咱们也会按期举行一些活动，把框架搭好，教程写好，新 Contributor 按照固定的模式便可完成某一特性开发。

固然除了那些标记为 for-new-contributors 的 issue 以外，也能够考虑其余的 issue，标记为 help-wanted 标签的 issue 能够优先考虑。除此以外的 issue 可能会比较难解决，须要对 TiDB 有较深刻的了解或者是对完成时间有较高的要求，不适合第一次参与的同窗。

固然除了现有的 issue 以外，也欢迎将本身发现的问题或者是想要的特性提为新的 issue，而后自投自抢 :) 。 

当你已经对 TiDB 有了深刻的了解，那么能够尝试从 Roadmap 上找到感兴趣的事项，和咱们讨论一下如何参与。

讨论方案

找到一个感兴趣的点以后，能够在 issue 中进行讨论，若是是一个小的 bug-fix 或者是小的功能点，能够简单讨论以后开工。即便再简单的问题，也建议先进行讨论，以避免出现解决方案有问题或者是对问题的理解出了误差，作了无用功。

可是若是要作的事情比较大，能够先写一个详细的设计文档，提交到 docs/design 目录下面，这个目录下有设计模板以及一些已有的设计方案供你参考。一篇好的设计方案要写清楚如下几点：

• 背景知识
• 解决什么问题
• 方案详细设计
• 对方案的解释说明，证实正确性和可行性
• 和现有系统的兼容性
• 方案的具体实现 

用一句话来总结就是写清楚“你作了什么，为何要作这个，怎么作的，为何要这样作”。若是对本身的方案不太肯定，能够先写一个 Google Doc，share 给咱们简单评估一下，再提交 PR。

提交 PR

按照方案完成代码编写后，就能够提交 PR。固然若是开发还没有完成，在某些状况下也能够先提交 PR，好比但愿先让社区看一下大体的解决方案，这个时候请将 PR 标记为 WIP。

对于 PR 咱们有一些要求：

1. 须要能经过 make dev 的测试，跑过基本的单元测试；
2. 必须有测试，除非只是改动文档或者是依赖包，其余状况须要有充足的理由说明没有测试的缘由；
3. 代码以及注释的质量须要足够高，这里 有一些关于编码风格和 commit message 的 guide；
4. 请尽量详细的填写 PR 的描述，并打上合适的 label。

对于 PR 的描述，咱们提供了一个模板，但愿你们可以认真填写，一个好的描述可以加速 PR 的 review 过程。经过这个模板可以向 reviewers 以及社区讲明白：

• 这个PR 解决什么问题：相关的问题描述或者是 issue 连接；
• 如何解决：具体的解决方法，reviewers 会根据这里的描述去看代码变更，因此请将这一段写的尽量详细且有帮助；
• 测试的状况；
• 其余相关信息（若是须要）：benchmark 结果、兼容性问题、是否须要更新文档。

最后再说几句测试，正确性是数据库安身立命之本，怎么强调测试都不为过。PR 中的测试不但须要充足，覆盖到所作的变更，还须要足够清晰，经过代码或者注释来表达测试的目的，帮助 reviewer 以及从此可能变更/破坏相关逻辑的人可以容易的理解这段测试。一段完善且清晰的测试也有利于让 reviewer 相信这个 Patch 是正确的。

PR review

PR review 的过程就是 reviewer 不断地提出 comment，PR 做者持续解决 comment 的过程。

每一个 PR 在合并以前都须要至少获得两个 Committer/Maintainer 的 LGTM，一些重要的 PR 须要获得三个，好比对于 DDL 模块的修改，默认都须要获得三个 LGTM。

Tips：

• 提了PR 以后，能够 at 一下相关的同窗来 review；
• Address comment 以后能够 at 一下以前提过 comment 的同窗，标准作法是 comment 一下 “PTAL @xxx”，这样咱们内部的 Slack 中能够获得通知，相关的同窗会受到提醒，让整个流程更紧凑高效。

与项目维护者之间的交流

目前标准的交流渠道是 GitHub issue，请你们优先使用这个渠道，咱们有专门的同窗来维护这个渠道，其余渠道不能保证获得研发同窗的及时回复。这也是开源项目的标准作法。

不管是遇到 bug、讨论具体某一功能如何作、提一些建议、产品使用中的疑惑，均可以来提 issue。在开发过程当中遇到了问题，也能够在相关的 issue 中进行讨论，包括方案的设计、具体实现过程当中遇到的问题等等。

最后请你们注意一点，除了 pingcap/docs-cn 这个 repo 以外，请你们使用英文。

更进一步

当你完成上面这些步骤的以后，恭喜你已经跨过第一个门槛，正式进入了 TiDB 开源社区，开始参与 TiDB 项目开发，成为 TiDB Contributor。

若是想更进一步，深刻了解 TiDB 的内部机制，掌握一个分布式数据库的核心模块，并能作出改进，那么能够了解更多的模块，提更多的 PR，进一步向 Committer 发展（这里 解释了什么是 Committer）。目前 TiDB 社区的 Committer 还很是少，咱们但愿从此能出现更多的 Committer 甚至是 Maintainer。

从 Contributor 到 Committer 的门槛比较高，好比今年的新晋 Committer 杜川同窗，在成为 Committer 的道路上给 tidb/tikv 项目提交了大约 80 个 PR，而且对一些模块有很是深刻的了解。固然，成为 Committer 以后，会有必定的权利，好比对一些 PR 点 LGTM 的权利，参加 PingCAP 内部的技术事项、开发规划讨论的权利，参加按期举办的 TechDay/DevCon 的权利。目前社区中还有几位贡献者正走在从 Contributor 到 Committer 的道路上。