Thank you, everyone, for the discussion so far, and thank you, @Hzfengsy for driving the proposal. After reviewing the thread and watching all the relevant conversations. I would like to come out and share my support for the proposal.
I am making this statement [wearing Apache TVM hat](https://tvm.apache.org/docs/contribute/committer_guide.html?highlight=apache%20tvm%20hat#independent-project-management). I would like to summarize a few important perspectives from our community members here as guidelines for community members: ## How should we operate as a community? When considering proposals, there are many factors being considered by members. A lot of them have to do with the impact to code: - Impact to Code: cohesiveness to the overall vision, testing, clarity among modules, quality, stability, the overall complexity of the codebase, and presentation to the users. This is what we are getting used to in normal software development settings. There are even trade-off factors here. On the one hand, indeed, new modules bring different levels of impact on these perspectives depending on their scope. However, in many cases, new modules do not bring impact in a purely negative way. MLC(machine learning compilation) is a fast-evolving field. The ability to reinvent ourselves and keep up with innovation while keeping the main component stable is the key to survival in the ML landscape. PyTorch is exemplary in terms of development philosophy on bringing in related modules. In many ML frameworks such as PyTorch, allowing space for multiple relevant solutions(e.g. Dynamo, TorchScript, LazyTensor) to coexist and evolve is critical for success. It is also important to allow flexibility of growth rather than plan everything out in the beginning. When TorchFX first came out, there was no clear prediction of Dynamo being relevant. Even today, there is no detailed plan of replacing TorchScript with Dynamo. Nevertheless, the community members continue to use the relevant modules and have an evolving conversation. ML is fast evolving and we should never expect to lock down every aspect of a plan in the beginning. Instead, open doors for diverse community members to come and participate and contribute their perspectives. Such open philosophy is what the TVM community(or every successful ML OSS project) should aspire to be. This brings us to another **very important** factor, which is OK to ignore in software development settings but should always but put first in Apache projects: - Impact to the community: bringing in new community members and growing the community. A lot of that ties back into the "community over code principle". When evaluating modules, we should certainly consider how the proposal empowers new users/developers. Can the proposal welcome new developers? Can they solve different needs of the community? The TVM project exists because of the community. That means we need to empower each member with different needs, and sometimes that could mean that we would do something different than our normal development rationales to empower the community members – especially when many, or even the majority of community members, shared their voice and support. This does not mean our original rationale is wrong, but we are more open-minded and bring that community empowerment as the first principle. ## How can we empower each other Being in the same community means we share the same burdens(of maintenance, advocations) and joys together. Any process or system is not perfect, and the intention was never to assume people as adversarial. The first principle of the Apache community is community over code, which means we empower each other. Some in the discussion thread raised the question about what if a person operates in an outright stubborn manner – like declaring outright rejection of later S1/S2 proposals or code PRs without reviewing the additional context being brought up, and not having a constructive conversation with additional context. Such behavior would certainly be frowned upon in any OSS community, and this is not a behavior I would expect from any committer/reviewers. This also comes from the exclusive mindset and inclusive mindset we have in the community. Indeed it is an additional burden for us to help maintain, and development the code that is less relevant to our interest. One could outright dislike code that causes regressions irrelevant to our own customer use cases. It is harder to directly settle a lot of those conversations through a simple technical debate since many can have disagreements about what are important parts – to some graphs IR and executor are important, to many other TVM users, they might only care about FFI and TensorIR while building their own graph integration. When in confusion, always remember to come back to the community. Remember that we empower each other. These are codes that are developed by members who also volunteer their time reviewing our code, writing test cases, and contributing to common foundation components such as codegen, FFI. While the need perhaps is less urgent to ourselves, empowering them would help the community to grow stronger. I can give examples of when we do so. For example, the AOT proposal comes with quite a few complexities and burdens that not all of us fully agree to – a divergent ABI that could have been optimized through C Packed, an IR node that later caused regression in auto-scheduling. Extra code path that only supports a limited set of models and dynamism due to (reasonable) restrictions. To many of us, it is also not necessarily an executor that we need in our daily applications. One could have forced the AOT proposal to always take C Packed that is consistent with other server-level modules, or block the module because they contain overlapping features that are implemented differently nor support all models. We did not choose to do that; instead, we welcomed the modules because we knew that community members would need them and would benefit from them in a timely module establishment, even if some of the detailed plans still needed to be flushed out. We know that they will empower additional community members. A proposal for graph IR, or auto-scheduling layer is not that different in nature. While each module might need a different level of technical deliberation, community empowerment should always be an important factor. Time is also an important consideration – as we are facing competition, and time to market is important to ML. When reviewing proposals that have a lot of community support, we would always try to keep a constructive conversation going and facilitate the establishment. Being inclusive and empowering each other is an important factor in bringing a welcoming and productive community. This does mean we need to take burdens, and we also openly contribute to each different perspective of the community that supports each other. I and many other PMC members have personally done so in evaluating past proposals (like the above example) and would expect our colleagues to do the same. ## How shall we handle disagreements Being in a big community means we have a diverse view. When one says, "this code produces this bug", likely no one will disagree. But as we evaluate code and community factors, each of us could bring disagreements because we might have our own opinion on how things should be done considering the factors. Shall we always disallow new modules that have relevant features to coexist with existing ones? Should we outright reject the phased approach and always ask for a detailed plan before accepting a module? After considering the arguments, shall we empower community members so some of them can enjoy the new module, and help us to grow our developer community? First of all, it is important to acknowledge that each of our views is both valid in many cases. It is very important to understand each others' view, and re-evaluate the proposal under such a context. Perhaps we should consider more impact to test in this case; perhaps we should put more weight on community empowerment. After acknowledging and understanding the views, having a conversation around the cases, there can still be differences of opinion, how do we as a community proceed? Stalling is not the right option because that would implicitly ignore the voices of those who want to move forward, especially when the majority of the community wants to do so. We also need agility and support for many who value innovation while maintaining high-quality code. As a result, after acknowledging each others' views and having a constructive conversation, I recommend listening to the majority community's voices -- as it is a decision of the community, by the community, and for the community. When in doubt, we choose community over code. That is why I support this proposal. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1336463901 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1336463...@github.com>
