[Community] Towards a more scalable developer community

[yuanming-hu]

I understand most of us (myself included) simply enjoy coding itself, but as the community is growing bigger, something should be done organizationally for more development scalability :-)

Background: Taichi Course, Promotions and Reviewing Pressure

I'll be teaching a computer graphics course on building advanced physical engines online, using the Taichi programming language. Course website: http://games-cn.org/games201/. You'll probably find your name at the bottom of that page (acknowledgments).

The audience will be mainly Chinese college students. This will bring us hundreds of users. The slides will be in English so it will be a good learning material for physical simulation and Taichi, for people around the world. I choose to teach in Chinese just because it is easier to teach in one's native language.

More details on this will be covered in a different issue. This issue is about the developer community instead of the user community. Meanwhile, please feel free to write your own articles, tutorials, and examples to attract people :-)

Preparing for a series of lectures takes time. At the same time, code reviewing takes me and other reviewers a significant amount of time every day. During code reviews, I find that this process can be made much more efficient if we make some easy changes.

What needs to be changed

Considerations:

• The project can make its impact only if more people start using it;
• To support more users and make a bigger impact, we need a more efficient team of developers;
• Currently, the development efficiency is limited by a centralized reviewing system;
• We need changes to reduce the reviewers' pressure.

To this end, the following changes will be (gradually) implemented.

1. (Improve PR quality) PR authors should try their best to maximize the probability of direct approval

From a team-working point of view, the PR authors fixing their own issues in a few rounds of self-review is way more efficient than

1. Request a review
2. Reviewers point out the issue
3. The author fixes the issue
4. The author re-requests for a review

Related mechanisms to improve PR quality will be raised in a separate issue.

(Of course, if more than half of your previous PRs have been approved without major changes, then your PRs probably already considered as high-quality. If you think you are receiving too many reviews and your PRs takes days to get merged in, then please take action to improve your PR quality.)

2. (Reduce review pressure) Reviewers are not expected to provide real-time response

A review response within 24 hours is good enough. This will

1. Encourage the PR authors to polish their contribution to a good state;
2. Allow reviewers to do reviewing in a batched manner.

In this way, reviewers' time can be saved, and the team will work more efficiently.

3. We need more committers (with write permissions) to the project

The goal of permission control is to ensure code and community health.
Previously, only @yuanming-hu and @k-ye have write permissions to this repo. Both of us have full-time jobs to do, and currently, the reviewing/merging pressure is very high on us.

Who should have write permissions?

Write permission means the right to Squash and merge PRs.

Write permissions will be gradually given to people who

• Is a great team worker and can communicate effectively
• Demonstrates good software engineering practices
• Demonstrates a solid understanding of the codebase and design philosophy
• Contributed at least 5 non-trivial PRs that are approved smoothly (e.g., without major changes requested from the reviewers)

On April 24 the committer list is extended to

• @yuanming-hu
• @k-ye
• @archibate
• @xumingkuan
• @KLozes

Note that we emphasize quality over quantity. For example, contributing a high-quality PR (e.g. #627 #716) is more helpful than a few PRs that need more work from the author and reviewers.

Also, note that receiving write permission does not mean the developer has to spend much more time than before. Although we appreciate contributions, it is the developer's freedom to contribute to an open-source project, and no one should force it.

Developers with write permissions can merge PRs that have received approval from at least one reviewer.

A list of reviewers will be discussed & created in a separate issue.

Finally...

A huge thank you to everyone in the Taichi community. Without your great contributions, we couldn't get where we are today. Taichi has been an amazing project for us to learn and practice not only compilers, graphics, and computational physics techniques, but also (perhaps more importantly) strong team spirit. I believe, given time and our efforts, Taichi will be one of the standard tools for people in related fields.

---

Thanks to @k-ye for editing an early version of this post. Please feel free to share your thoughts :-)