[GitHub] [tvm-rfcs] leandron commented on pull request #102: [Process RFC] Clarify Community Strategy Decision Process

["leandron (via GitHub)" <gi...@apache.org>]

leandron commented on PR #102:
URL: https://github.com/apache/tvm-rfcs/pull/102#issuecomment-1667516671

    > The RFC is about how we operate as a community, and it's not necessarily related to "gigantic puzzle of features". To clarify, according to my read, this RFC is particularly designed to be extremely conservative that a decision making should get super majority (2/3) of the votes to pass. It means the will of a single person or identity is insufficient to push forward anything unless they convince most of the community members.
   >
   > As a community of diverse needs, of course, we have different opinions on how we could drive our technical needs, which is a process issue of any community operation. If a super majority of the community firmly believe in one approach of how, I would agree and support it no matter what I personally believe in. The RFC is just about that the community needs a way to drive technical resolution.
   
   I wasn't aware of these motivations, I think they should be stated in the RFC text.
   
   > I share the same sentiment with you that I wish some of my softwares never got updated, for example, LLVM breaks upon almost every release, and Cython just breaks recently which is a huge headache (and meanwhile, they constantly bring in coolest new features!). Stability is indeed an important issue to me, and therefore, if a “stable architecture” already copes with new challenges out of box, I would personally prefer not to upgrade, just to save my own time.
   
   We are getting confused with the difference between a stable architecture (components that interact with each other), with API, which is the specific function calls and classes design to make something work. What I'm arguing is that we should prioritise evolving our existing components e.g. IRs, rather than come up with something new every couple years.
   
   Cython and LLVM are great software with mature communities, being used in many production cases and - I'd argue - very stable.
   
   This is probably one of the reason their contribution guides are clear w.r.t changes, for example Cython mention the development larger features in branches before they get into the main codebase ([source](https://github.com/cython/cython/wiki/HackerGuide#feature-branches)) and LLVM has this note in their development guide: **"we need to strike a balance between being inclusive of new ideas and people and the cost of ongoing maintenance that new code requires. As such, we have a general support policy for introducing major new components into the LLVM world, depending on the degree of detail and responsibility required. Core projects need a higher degree of scrutiny than peripheral projects, and the latter may have additional differences."**
   
   So, if said projects keeping control of their architectures break sometimes, imagine for project that are less careful with that, how would that be?
   
   > Meanwhile, as a PMC member, I would take **PMC responsibility** to a) hear the voice of super majority, and b) make concrete progress to keep the software updated to the latest challenge, which further becomes neither my personal will, nor stability concern wishing for zero change or zero break, but grave concern accordingly on a) community stagnation; b) being out of touch from major usecases.
   
   I this this paragraph misinterpret the role of the PMC, which is not to "hear the voice of super majority". It says, instead, among other things: "to further the long-term development and health of the community as a whole, and to ensure that balanced and wide scale peer review and collaboration takes place." ([source](https://www.apache.org/foundation/how-it-works/#pmc)). 
   
   I think it is not welcoming and correct to say that there is this "super majority" that crushes everyone else's opinion. At least this is not the way I think it should be.
   
   > > I understand the fact a subset of the community wants to bring changes faster into the TVM stack for the benefit of "a field in fast development" or to attract more contributors, etc.
   > 
   > I apologize in advance if I misread as a non-native speaker, but correct me if I was wrong, as a PMC member just like you, I was slightly surprised about your wording on this particular scenario. Given the context that this is an extremely conservative proposal that requires super majority to push forward any technical decision, I would love to have you re-examine the following assumption:
   > 
   > * A super majority is described as "a subset of the community". Do you want to clarify if it's you believe super majority is representative in your reasoning?
   
   A "subset" is exactly what it is.
   
   > * The motivation of having new features, as you described, is to "attract more contributors" instead of merely coping with latest needs in the field. Do you want to clarify if you believe there is any need to cope with latest needs?
   
   Sorry, I'm not aware of statistics in this area. I'm just representing a view I took from previous numerous discussions around this topic, that I referred in my previous post.
   
   > To summarize, @leandron, do you agree with me that we value community over code? I'm really grateful to have such a helpful and collaborative super majority of the community, and we concrete deliver for them all the time, making our solution as fast, robust and easy-to-use, solving community problems at large scale.
   
   This text is already off-topic by a lot, so I suggest rather than posting passive-aggressive questions such as whether long term contributors of this project agree with "community over code", we focus on clarifying the RFC text, so that the community understands what is it that we're changing once this goes to vote.


-- 
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: commits-unsubscribe@tvm.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org