作者：兴趣使然的小 tison
其实我觉得这个多少不算版本计划，但是也没想好该提议个啥分类比较合适…
欢迎来到新一期的 This Week on TiDB 栏目！TiDB 是一个开源的 MySQL 协议兼容的分布式数据库，支持 HTAP 即混合事务和分析处理。这个栏目是 TiDB 开发进展和社区新闻的非官方周刊窗口，如果你想将自己看到或者正在做的工作也通过这个窗口发布，欢迎私信联系我或者在 weekly 仓库中提出。如果你有意了解或加入 TiDB 社区，TiDB 社区也非常欢迎贡献者。
User Generate Content
结合 TiDB 和 TiKV 社区的流程和治理模型再造经验，我撰写了这篇文章，以通过介绍两个社区所面临的问题和采取的应对手段，希望能为如雨后春笋般增长的新兴开源社区提供开源社区的治理模型方面的经验。这里面最重要的一条就是，开源社区的治理模型应当因地制宜。
TiDB 社区的先行者 @winkyao 在周末的 ApacheCon Asia 2021 上讨论了 PingCAP 是如何探索和学习，并将 TiDB 建设成今天的样子。视频讨论了 TiDB 社区的独特之处，以及 Apache 基金会和 Linux 基金会也在遵循的不变的原则。
如何参与改善 TiDB 代码质量？我是说…一分钟成为 TiDB 贡献者。
@feitian124 在博客上总结了自己加入 TiDB 社区的经历和体会。原博文提到参与的契机是看到了我在 bilibili 上发布的视频，有兴趣成为 TiDB 贡献者的同学也可以点开看看。
原博文有一句话让我有所共鸣，在国内开源社区环境整体比较急躁的情况下，肯定了踏实地参与软件开发，在社区中凭借自己的贡献赢得权威的做法。
…写了上面这些是想告诉后来的新人们， 不要觉得太难而不敢参与， 也不要因为太容易而不愿意参与。 高楼大厦也是一块一块砖头砌起来的，正确的心态很重要。 我们新人这些细小的改进，也可以汇集成 tidb 宏伟蓝图中重要的一部分。
Development
Track issue of merge BR into TiDB
pingcap/br 仓库已经合并到了 pingcap/tidb 仓库里，目前 @3pointer 和 @zhouqiang-cl 等开发者正在关注合并后的回归测试稳定性等问题处理上。
合并以后构建流程和代码的重构，以及多余的仓库文件清理不可避免。可以关注一下合并以后对 tidb 开发的影响，发现以后提出 issue 报告或者直接 PR 修复。
Tracking issue for restructure tests
测试架构迁移预计分成三个阶段。
-
第一阶段是确定迁移基调，迁移依赖较少的实用函数模块，目前已经完成的七七八八了。
-
第二阶段是攻坚核心代码模块，包括 ddl / executor / expression / planner 等等，目前已经逐步开展起来了。
-
第三阶段是收尾和清理脚手架，这个到第二阶段越过临界线之后会开始推进。
一方面，这个项目通过测试这种目标明确的工作帮助贡献者跨过参与贡献的门槛，成为给社区提交过代码的一份子。
另一方面，对于积极的贡献者来说，这其实是一个广阔天地的窗口。这个项目从代码层面上涉及了 TiDB 数据库核心的方方面面，只要你愿意花时间研究迁移的测试代码以及背后的生产代码的逻辑，找到可做的工作，深入的参与社区不是一件难事。
欢迎参与！
makefile: make CI fail if a single unit test runs longer than 3s
测试方面另一个值得一提的工作是 @tiancaiamao 在 CI 里为每个测试添加了不超过 3 秒的运行时间要求，实现上是跑完测试以后筛选出超时的测试并 fail 掉 CI 作业。
如果近期测试因为莫名的原因挂掉，可以看下是不是这个改动导致的。TiDB 社区非常关注研发体验，目前跑完一次测试的时间大约是十分钟上下，根据个人的环境情况可能会有出入。比起以前参与过的某些社区动辄数个小时的 CI 时间，已经算得上是飞快了。
Substitute rocksdb write stall
@Connor1996 主导的为 TiKV 实现 RocksDB 上层的 Write Stall 控制的项目已经结束。关注 TiKV 存储技术的同学可以从上面卡片关注到这个项目的设计和实现。
understanding-tidb: add introduction for statistics
最后一个和 TiDB 的开发相关的进展，是 TiDB Development Guide 的 Understanding TiDB 章节的编写。上面几个 PR 分别由 TiDB 的开发者 @mjonss @winoros @morgo 创建，如果你对了解 TiDB 的内核原理感兴趣，可以参与到这些文章的 review 当中来，或者提出现有文章的问题，或者将自己的理解形成 PR 提升整个 Dev Guide 的质量。
Forum
来自小米的贡献者 @mianhk 介绍了自己在 TiDB Operator 项目上的工作和小米在 TiDB 实践上与部署和云上运维的经验。
虽然我觉得编号大可不必，不过作为贡献者在社区亮相不失为一件好事。可以让社区的其他同学快速地知道你在做什么，如何帮助你快速的融入和在有意愿和时间的情况下深入参与。
@andylokandy 针对 Understanding TiKV 章节做了目录的调整，调整之后的结构非常清晰，相关的章节也开始有其他社区同学例如 @skyzh 和 @iosmanthus 开始参与编写。
主导 HugeGraph 和 TiKV 融合项目的 @Jerry098 在论坛上针对近期的进展做了同步。
项目拆分成五个子任务，
- support metrics for tikv backend
- support basic function of TikvStore
- support basic functions for TikvStdSessions
- adapt to core tests
- improve insert and query performance
TiKV 作为一个可以承担海量数据存储的 KV 数据库，正在找到自己越来越多的场景。如果你苦恼于 Redis 单机扛不住大数据量，Redis Cluster 运维复杂且数据一致性难以保证，其他 KV 数据库缺乏熟悉的事务支持，而 etcd 又是单个 Raft Group 同样面临扛不住大数据量的问题，那么 TiKV 就可能是你的解决方案。
HugeGraph 和 TiKV 的融合项目，正是将 TiKV 作为图数据库 HugeGraph 的数据存储引擎来使用，来改善存储后端的容量问题，数据一致性问题，和性能问题。是的，TiKV 在保证强一致性的同时，还有超越 HBase 或 Cassandra 等大数据技术的性能。
如果你在寻找一个好的 KV 数据库，那么你应该将 TiKV 加入候选名单。如果你对图数据库的概念感兴趣，不妨看一看 HugeGraph 的使用场景，并期待它与 TiKV 结合所产生的化学反应，或者参与其中。如果你已经选定了 TiKV 作为 KV 数据库，那么参与这个融合项目将有助于从接口到原理了解 TiKV 在实际生产场景的用途。
欢迎关注及参与！
TiDB Committer @ichn-hu 发起了 SQL 执行期间计算下推到 unistore 的实现层面的代码优化。
unistore 是由 @ngaut 发起，@coocood 等开发者参与开发的一个 Go 语言实现的存储引擎。目前作为 TiDB 在单机模式下运行时 TiKV 角色的替代者，广泛使用在开发阶段的概念验证和测试代码当中，其代码已经合并到 TiDB 代码仓库中。
Replace the execution framework on unistore with TiDB’s builtin execution framework
@ichn-hu 提到，目前 unistore 和 TiDB 的执行框架已经对接完毕，但是在结构化和向量化执行上仍有欠缺。他计划通过上面的 issue 来记录重构这部分代码的工作，并期待有更多的参与者共同开发。