Reminder of our Code Review Guidelines

[junrushao]

@tqchen

So specifically for the list of PRs, I would instead ask the following constructive questions and enable flexibility for our community and contributors. For example, I would ask does the PRs get review from the people who are familiar with related area of expertise? Are there any possible outstanding changes that needs to be made, or do they help the overall codebase in general? Is the merger open to followup when additional comments are raised.

Strongly agree with this. I would love to advocate once more that as a community, we promote open-mindedness and collective understanding so that no one is a bottleneck.

I took a brief look at the PRs you called out, many of which are from voluntary contributors:

• [Runtime] Add missing Type2Str for TVMByteArray by wrongtest-intellif · Pull Request #14051 · apache/tvm · GitHub by @wrongtest: fixes a bug in C++ templates
• [AutoScheduler][AutoTVM] Enable xgboost >= 1.7.x new changes by cbalint13 · Pull Request #14036 · apache/tvm · GitHub by @cbalint13: fixes compatibility with latest xgb
• [FIX][TOPI] Clip with IntImm/FloatImm by MasterJH5574 · Pull Request #14027 · apache/tvm · GitHub by @MasterJH5574: fixes an operator clip to support PrimExpr
• [TIR] [Bugfix] Pass the correct block_sref_reuse to Replace by quic-sanirudh · Pull Request #14023 · apache/tvm · GitHub by @sanirudh: fixes a bug in TIR scheduling (layout transformation)
• https://github.com/apache/tvm/pull/14020 by @zxybazh: fixes a bug in TIR lowering for shape functions (in memory verification)

I would love to provide my view as follows:

• All of the PRs are contributed by voluntary contributors to enhance our codebase and fix existing issues;
• All of the PRs got reviewed and approved by people who are familiar with the relevant area, who are willing to follow up if additional comments are raised;
• All of the PRs follow our existing design and do not bring in any contradiction from the mergers’ point of view.

I would love to further remind us about the trust building in our code guideline:

@tqchen

Building Trust

First and foremost, we are building a community that based on trust, which takes time and effort to both build and maintain. We expect our community members to work together in a constructive way and work together with common sense. Although we all have different sets of backgrounds, interests and goals we must work together to find solutions that work for the larger community. Trust-based collaboration is also a key tenant of the Apache way and an important factor to consider in growing the community, and promoting members to official roles.

Be Respectful

• To everyone who are making comments: making constructive comment will help new contributors to land their PRs timely and help us welcome new members to the community.
• To authors: reviewers should spend significant time reading the code, and a careful review could be as time intensive as writing the code from scratch. Respectfully address review comments and reciprocate the review by helping review others changes in the future.

Most importantly focus on having a constructive conversation, and try to assume best intentions when interacting as a reviewer. If there is something in the process not working, consider getting some face time with the other contributors and discussing how to improve the process or communication.

As a community, the codebase is not owned by one company or two, and the code change does not have to be approved by specific companies. Instead, we trust and welcome voluntary contributions, and given that the mergers are experts of relevant fields, I would personally prefer trusting them to callig them out.

I know building a community is hard and different from running a team in a company, and let’s work together to make this happen