[Process RFC] Empowering New Scoped Module to the Project

[tqchen]

Thanks, everyone, for the discussions so far on this thread. Here are a few things that can help future discussions:

• I would encourage us to avoid making implications, “e.g. we have to do X; otherwise, it is not achieving goal Y and then bad consequences.” Instead, coming back to goals and being open-minded could go a long way.
• We all strive to build a welcoming, inclusive community. Through the discussions, let us be empathetic, welcoming, friendly, and patient. Let us focus on solving issues(of achieving both G0 and G1), and avoid blaming people or groups.

Finally, I would encourage us all to think about the community over the code principle and encourage everyone to put the community into the picture. Process serves the community this conversation is important for us to be viable as a community and as a project. thanks everyone’s inputs so far and thanks @Hzfengsy for driving the conversation.

[Hzfengsy]

How does the proposal fit into TVM and planning

Thanks, everyone for the discussion so far. One G0-related action is to discuss how an S0-module proposal fits into the project and overall planning. We agree that such discussions about fit and planning are important.

In the meantime, many OSS project modules also do not pin down all the detailed plans from the very beginning. Instead, they usually start with some clear positive signs in some area, then gradually expand to more as the project evolves. For example, TorchFX started with the ability to build quick rewrites(quantizer) and then moved on to support Dynamo compilation later.

As a result, would love to see what we think about the following text (also included F0 as a comparison). NOTE: It’s not a formal vote, but only to see feedback from the community

• F0: There should be discussions about how the proposal fits into the project. We expect the discussion to bring pin down to all future S1 and S2 aspects.

• F1: There should be discussions about how the proposal fits into the project to bring clarity. We also acknowledge that not all S1, S2 level decisions can be made at the beginning. Additionally, an S0-module should show a clear positive fit to some(but not all) aspects of the project and clear cohesion to some of the existing modules. As the development evolves, more discussions will happen in future RFCs with additional evidence to help us make informed decisions.

[spectrometerHBH]

To me, the most important metric of the quality of a code is whether it is useful and solves problems faced by some part of the community.

If it indeed solves problems and provides new features people want, then I will regard it as good code, even if they use _ and __ as variable names (forgive me if this sounds a bit extreme to you). You can always iterate over the code from 1 to 2 to 3 and so on, but the most important step comes from 0 to 1, which I value the most.

When I crafted and merged the initial version of TVMScript ([RFC] Hybrid Script Support for TIR, https://github.com/apache/tvm/pull/6227) into TVM, the code I wrote is hard to say to be in satisfactory industrial quality (at least from my perspective) when I was only a 3-year undergrad and has little experience of research and engineering, and it has been substantially refactored since then by many other community members.

I would say TVMScript is still an optional module now because users can choose to use TVMScript if they are interested in it, or they can simply just ignore it without modifying any line of their codes. And I believe this can be a typical workflow for other optional modules, which is principally reflected by this RFC.

Actually I am a bit surprised by this RFC because I thought it was a de-facto existing develop work flow in TVM. AutoTVM, Ansor, MetaSchedule, TVMScript are all optional modules IMO. Even for the compilation module which lies in the core of TVM, users can choose to use te or TensorIR which provide two indepedent APIs to describe computation and schedules.

Maintenance is a typical engineering problem faced by many projects, many of which are 10x larger than TVM. I would say as long as it’s an engineering problem, it can be solved with strong and broad community users and developers, given the fact that there are many much larger and longstanding projects like Linux that are still under active maintenance.

The key to such success is that we do have a persistently existing community along with the evolution of new technology, the emergence of new problems and new challenges, and the proposal of new and even unmature solutions. It is in some sense much more difficult than maintenance efforts because machines and codes are under control while people are not.

[tqchen]

I would like to follow up on this since I was not straight on this, and I apologize for not calling it out directly. There was a post that singled out a particular group in the discussion. They are not helpful to our discussion at all, and we should stop bringing up conversations that single out a group. The related posts are flagged for deletion. As a community, we follow a common code of conduct and aim to have civil discussions.

There are many productive comments on this thread, and let us continue to have civil and constructive discussions.

[Hzfengsy]

Overall Process Compatibility

I would also like to report back here after doing some research on process compatibility. Since that was another concern being raised in this thread.

ASF allows projects to update their process according to the community needs, which was also the motivation behind the original process RFC

All code patches to S0-modules follow the same reviewing process, and it is reasonable as most comments on code changes can be quite grounded with clear technical reasoning (this code has bugs that can be fixed in this way).

S0-module establishment is closer to the establishment of a submodule. Such creations are usually not typical code changes since they are subjective and can not state grounded reasons “(opens a security exposure, negatively affects performance, etc. )”

For similar reasons, other Apache projects also define their process of creation of a new submodule that follows some kind of majority. For example, Apache Hadoop process and Apache Hive Bylaws specify that any submodule(subproject) creation follows 2 / 3 majority. Note that these previous cases can apply to both S0/S1 modules indifferently.

[Hzfengsy]

Thanks for the feedback from the community. As the majority of the community members agree on F1, I’d like to update the proposal according to the community’s opinion. The following statements are added:

@Hzfengsy

There should be discussions about how the proposal fits into the project to bring clarity. We also acknowledge that not all S1, S2 level decisions can be made at the beginning. Additionally, an S0-module should show a clear positive fit to some(but not all) aspects of the project and clear cohesion to some of the existing modules. As the development evolves, more discussions will happen in future RFCs with additional evidence that help us to make informed decisions.

[Hzfengsy]

Thanks everyone for the great input in this thread. We all agree about the importance of G0 and G1. We have different thoughts on how to get to the Gs. Knowing that some of them can be subjective, a lot of our discussions come back to the level of open-mindedness when considering contributions wrt to their scope. I would also encourage all of us to come back and think about the community in such cases.

Thanks to everyone’s constructive inputs that help to improve the proposal, in some cases when we have different opinions, we choose the phrasing that most of us agree to.

Now, the RFC is post on the tvm-rfcs. Discussion in this thread and comments on the RFC repo are all welcomed.