@mbaret I want to apologize about my wording. Indeed constructive conversation is important -- that is why we are having this conversation for about several months now. I would like to point out the importance of unbundling -- i removed my wording on dragging.
I do would like to point out the language barrier factor, the needs to empower our community members, and so. There is no intention to indicate that that those who speaks against the RFC as "anti-community", I want to apologize if the text was interpreted in that way. Instead, we summarizes the case there is a disagreement on hows, and disagreement on how usually are addressed through procedural approaches. > Firstly, there aren't many community members even present commenting here We have observed at least community contributors from more than eight organizations supporting the proposal in this RFC and the original [thread](https://discuss.tvm.apache.org/t/process-rfc-empowering-new-scoped-module-to-the-project/13617/29). It is very rare to see vocal support of such proposals I agree with you on multiple personas. And i would like to remind us that every one of us are wearing multiple hats. I personally contribute to features, maintain the modules, fixing tests. It is unfair to simply categorize a S0 proposer as "feature developers". Many of them are maintainers of the modules, fixing bugs more often. Additionally, S0 as being defined only have to do with its "scope of impact". There is nothing to do with the reach-ness to the users, or whether people needs them. Imagine a case when a module is being needed by more than eight organizations -- many of them are industry players, but not all other members. Will we count that module as "need to be hidden from the majority of users"? Of course not, we should present these modules to the user. A module that have limited scope of impact, while benefit a lot users is a great thing. The factor of inclusion should consider, testing, maintenance, documentations and others as being listed in the proposal. > However, the S1 and S2 mechanisms would be of enormous value to maintainers There is no question that these are important and we should do them as well in other conversations. > Could we therefore please stop pretending this RFC 'empowers the majority of > the community' and say what we mean: it empowers the PMC - the composition of > which currently doesn't closely reflect the active contributors in the > community. We all contribute in different means, some of them are code, some of them project management, directions. Apache principle means that we encourage volunteer contributions where our contribution past or recent are equally valued. I would value that our PMC members places the best interest in mind in having such conversations. Additionally, empowering and bringing people along means we will have more active contributors in the community overall. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1339499093 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1339499...@github.com>
