Updates for developer collaboration process

#1

On March 26th, 2021, @Xuanwo, a TiKV reviewer, encountered a bad case on developer collaboration on tipb repo. His early PR got closed because a later PR for the same purpose merged first because it got extra attention from committers. We put great attention on this case and draft work items to improve the contributor experience.

Here are the work items.

  1. Improve developer collaboration process among the community.
  2. Squash stale pull requests.

For the first item, we bring back rfcs process and make it a significant role to sync up community force. That means, we don’t conflict effort each other by being aware of rfcs under active developing.

For TiDB projects, you can take a look at the design document directory and its README file describes when and how to make a design. You might take the dynamic privileges feature as a good example.

For TiKV projects, you can take a look at the rfcs repository and also its README file describes when and how to make an rfc. We interchangeably use rfc and design doc. You might take the GC worker feature as a good example.

For the second item, @hi-rustin proposed a tichi bot plugin, lifecycle, and hopefully we deal with stale pull requests with it as well as engaging committers later.

1 Like
#2

DISCLAIMER: I edited the original content of the topic as an admin for better expression, which is with the permission granted by the author @gingerkidney.

Thanks for starting the discussion @gingerkidney! I’d like to attach a bit more information about the “developer collaboration process” part.

Among working projects kicked off recently, we make a consensus with several teams to follow the proposed collaboration process, including

  • Supporting Temporary Table
  • Supporting Common Table Expression
  • Partition Table General Access
  • Substitute TiKV Write Stall
  • Dealing with TiKV OOM

The first three projects are mainly developed under TiDB projects groups and the last two projects are mainly developed under TiKV projects groups while some overlap exists.

To be clear about “developer collaboration process”, we setup two checkpoints about a new feature implementation or a significant code refactor.

  1. A tracking issue tracks all progress and opens to questions.
  2. A design document about what to do the why doing that.

as well as suggesting a Pre-RFC discussion on this forum.

Let me show you how these projects meet the checkpoints.

Supporting Temporary Table

Supporting Common Table Expression

Partition Table General Access

It is to final comment period before we make the consensus, and thus we do not trace back to its design document. But both user document and dev document for partition table is required I think. @qw4990

Substitute TiKV Write Stall

Dealing with TiKV OOM

This is a long term effort and below is one of its subtask’s design and tracking issue.

#3

The question of how to balance the relationship between commercial companies and the open-source community is a long-standing one. I am very pleased to see that PingCAP is making positive improvements in this area. I hope PingCAP can explore a suitable path for TiDB / TiKV.

2 Likes
#4

this month i participated in the Temporary table project, the members in this team is very very nice. every time i have questions, team members would answer carefully, and told me about the whole function’s ins and outs, and help me figure out the bad taste of code. it helps me improves a lot.
suggestions: expose more docs or source code analysis 2 community

#5

You might be interested in our ongoing TiDB Development Guide. I’m working on it and welcome you to join on either share your ideas by comments or issue, or create a pull request push you ideal content.