tqchen commented on PR #95:
URL: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1339499093

   @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.   
   
   
   
   
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to