新架构、新角色：TiDB Community Upgrade！

做者：Jian Zhang

通过几年的发展，TiDB 社区已经逐渐成熟，可是随着社区的发展壮大，咱们逐渐感觉到了如今社区架构上的一些不足。通过一系列的思考和总结，咱们决定升级和调整目前社区组织架构，引入更多的社区角色和社区组织，以便更好的激发社区活力，维护积极健康的社区环境。

老社区架构

下图是以前官网上的社区架构图：

图 1 老社区架构

老社区架构主要面向 TiDB 开发者社区（Developer Group），主要角色有 Maintainer、Committer、Contributor 等，其中：

• Committer：由 Maintainer 或 PMC 推荐，是对 TiDB 有突出贡献的 Contributor。须要独立完成至少一个 feature 或修复重大 bug。

• Maintainer：项目的规划和设计者，拥有合并主干分支的权限，从 Committer 中产生。他们必须对子项目的健康表现出良好的判断力和责任感。维护者必须直接或经过委派这些职责来设置技术方向并为子项目作出或批准设计决策。

能够看到老社区架构屏蔽了日益壮大的、对产品打磨升级相当重要的 TiDB 用户群体，而且老架构中对于开发者社区角色的职责、角色之间关系的表述都比较简单，因此咱们在新社区架构中作了一些加法，将 TiDB 用户社区归入进来的同时，对 TiDB 开发者社区的每一个角色定义、权责又作了明确的界定，同时也增长了一些新角色、新组织，下面让咱们来详细地看一看。

新社区架构

变化 1：将 TiDB 用户社区归入总体社区架构

随着 TiDB 产品的成熟，TiDB 用户群体愈发壮大，用户在使用过程当中遇到的问题反馈及实践经验，对于 TiDB 产品的完善及应用推广有着不可忽视的重要做用。所以咱们这次正式将 TiDB 用户社区（TiDB User Group，简称 TUG）归入新的社区架构中来，但愿用户与开发者有更好的交流互动，一块儿推进 TiDB 社区的健康发展。

图 2 新社区架构之 User Group

TiDB User Group（TUG）是由 TiDB 用户发起的独立、非盈利的第三方组织，用户实行自我管理，旨在增强 TiDB 用户之间的交流和学习。TUG 的形式包括但不限于线上问答和技术文章分享、线下技术沙龙、走进名企、官方互动活动等等。TUG 成员能够经过线上、线下的活动，学习前沿技术知识，发表技术看法，共同建设 TiDB 项目。更多信息能够登录 TUG 问答论坛 asktug.com 查看。

变化 2：Active Contributor 和 Reviewer

图 3 新社区架构之 Active Contributor、Reviewer

上图反映了此次社区架构升级的第 2 个变化：在开发者社区中，新增了 Reviewer 和 Active Contributor 的角色。

Active Contributor 是一年贡献超过 8 个 PR 的 Contributor。Reviewer 从 Active Contributor 中诞生，具备 Review PR 的义务，而且对 TiDB 或者 TiKV 某个子模块的 PR 的点赞（LGTM）有效。关于这些角色，咱们将在后文介绍 Special Interest Group 时更详细地介绍。

变化 3：Special Interest Group

让咱们把开发者社区架构图放大再看看：

图 4 新社区架构之 Special Interest Group

上图展现了以垂直的视角来细看开发者社区的总体架构，反映了此次社区架构升级的第 3 个变化：引入了 “专项兴趣小组”（Special Interest Group，简称 SIG）。

专项兴趣小组主要负责 TiDB/TiKV 某个模块的开发和维护工做，对该模块代码的质量负责。咱们将邀请知足条件的 Active Contributor 加入专项兴趣小组，开发者们将在专项兴趣小组中得到来自 Tech Lead 们的持续指导，一边锻炼技术能力，一边优化和完善该模块。社区开发者们可经过专项兴趣小组逐渐从初始的 Active Contributor 成长为受到社区承认的 Reviewer、Committer 和 Maintainer。通常而言每一个专项兴趣小组都会周期性的组织会议，讨论最近进展和遇到的问题，全部的会议讨论都公开在社区上，方便感兴趣的同窗一块儿参与和讨论。

具体可参考目前咱们正在运营的表达式专项兴趣小组：Expression Special Interest Group。

另外这张图也反映了社区角色和专项兴趣小组的关系，咱们来仔细看看 SIG 中的社区角色：

1. Active Contributor

   • 即一年贡献超过 8 个 PR 的 Contributor。
   • 若是要加入某个 SIG，某个 Contributor 须要在 1 年内为该 SIG 所负责的模块贡献超过 8 个以上的 PR，这样便可得到邀请，加入该 SIG 进行针对性的学习和贡献。

2. Reviewer

   • 隶属于某个 SIG，具备 Review PR 的义务。
   • Reviewer 从 Active Contributor 中诞生，当 Active Contributor 对该模块拥有比较深度的贡献，而且获得 2 个或 2 个以上 Committer 的提名时，将被邀请成为该模块的 Reviewer。
   • Reviewer 对该模块代码的点赞（LGTM）有效（注：TiDB 要求每一个 PR 至少拥有 2 个 LGTM 后才可以合并到开发分支）。

3. Tech Lead

   • 即 SIG 的组织者，负责 SIG 的平常运营，包括组织会议，解答疑问等。
   • Tech Lead 须要为 SIG 的管理和成长负责，责任重大。目前暂时由 PingCAP 内部同事担任，未来可由社区开发者一块儿担任，和 PingCAP 同事一块儿为 SIG 的进步而努力。

再来看看另外两个角色：

1. Committer

   • 资深的社区开发者，从 Reviewer 中诞生。
   • 当 Reviewer 对该模块拥有很是深度的贡献，或者在保持当前模块 Reviewer 角色的同时，也在别的模块深度贡献成为了 Reviewer，这时他就在深度或者广度上具有了成为 Committer 的条件，只要再获得 2 个或 2 个以上 Maintainer 的提名时，便可成为 Committer。

2. Maintainer

   • 重度参与 TiDB 社区的开发者，从 Committer 中诞生，对代码 repo 拥有写权限。

以上社区角色的详细的定义和权责内容能够在 这里 查看。

变化 4：Working Group

图 5 新社区架构之 Working Group

第 4 个变化是开发者社区架构中引入了 “工做小组”（Working Group，简称 WG）。工做小组是由为了完成某个特定目标而汇集在一块儿的社区开发者与 PingCAP 同事一块儿成立。为了完成目标，有些工做小组可能跨越多个 SIG，有些小组可能只会专一在某个具体的 SIG 中作某个具体的事情。

工做小组具备生命周期，一旦目标完成，工做小组便可解散。工做小组运营和管理的惟一目标是确保该小组成立时设置的目标在适当的时间内完成。通常而言，工做小组也会有周期性的会议，用于总结目前项目进展，肯定下一步实施方案等。

可参考目前咱们正在运营的表达式工做小组：Vectorized Expression Working Group。

总结和将来的工做

总的来讲，此次社区架构升级主要有以下改进：

1. 引入了 TiDB 用户社区（TiDB User Group）。

2. 引入了 Active Contributor、Reviewer 的社区角色。

3. 引入了 Special Interest Group（SIG）。

4. 引入了 Working Group（WG）。

在社区运营方面，咱们将来还将继续：

1. 完善社区成员晋级的指导机制，让社区同窗从 Contributor 成长到 Committer 或 Maintainer 有路可循。

2. 让社区上的事情更加成体系，作事不乱。

3. 让社区同窗更有归属感，增强和其余社区成员的沟通。

在将来，咱们将陆续开放更多的专项兴趣小组和工做小组。在专项兴趣小组中，还将持续发放更多数据库相关的资料，帮助成员在专项兴趣小组中逐渐深度参与 TiDB 的开发工做。但愿你们都可以多多参与进来，一块儿将 TiDB 打形成开源分布式关系型数据库的事实标准！