[Process RFC] Clarify Community Strategy Decision Process

[tqchen]

• rendered

[csullivan]

I'm in favor of this change.

[Johnson9009]

+1

[junrushao]

+1. I'm in favor of this. A healthy community needs progress and keep updated to the latest trend, and a super majority vote is for now the best way we could think of to balance the need for stability while being against stagnation

[comaniac]

+1

[leandron]

The topic of decision making in the TVM community is a long standing topic, present in the ongoing RFC #95, #91 and #89 as well as numerous posts in the forum, in which many member of the community expresses their concerns with the proposals.

As with the previous proposals, this one needs to be improved on a few points for actual clarification, so that everybody understands what is being voted and the particular consequences it will have for their use-cases. We shouldn't rush into it IMHO.

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.

On the flip side, many see value in having a stable architecture with a set of components we can evolve long term in a coherent way, that would require us to be mindful when bringing new alternatives to solutions we already have on the stack. It might become too costly for some to keep up with gigantic puzzle of features that are just too complicated to make work.

All that is to say that fundamentally changing the decision making to make the barrier lower for key elements like "new direction or overall project evolution" is a new direction to the project in itself.

I'm not in favour of this RFC as is, but eventually it is for us collectively to decide and think what's the impact for our individual use cases.

[junrushao]

I was a bit confused, and would love to clarify my points first, and ask @leandron to clarify some of your points :-)

It might become too costly for some to keep up with gigantic puzzle of features that are just too complicated to make work.

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.

On the flip side, many see value in having a stable architecture with a set of components we can evolve long term in a coherent way, that would require us to be mindful when bringing new alternatives to solutions we already have on the stack

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.

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 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?
• 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?

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.

[Hzfengsy]

+1

[leandron]

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) 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 think 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).

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.

[tqchen]

It is clear from current conversations and past conversations that there are different opinions on how we should operate as a community.

These include what we should prioritize (e.g., “prioritize evolving our existing components, e.g., IR”), how we evolve core components, and how to “ensure long-term development and health of the community as a whole.”

It is also clear there are different interpretations of the same text; for example, our opinions about what approach qualifies as “ensure long-term development” or “evolving existing core components.” are different.

This proposal comes with the observation that there is no single, dogmatic way or interpretation to approach all situations. There are many ways a project can be successful. There should be holistic consideration from a technical perspective, the current state of the AI/ML ecosystem, and the demand from the community. This RFC do not suggest a specific path, or interpretation of the how.

Unfortunately, some of the hows, or interpretation of hows, are exclusive to each other when it comes down to the operational process. By stagnating, we are implicitly taking a path that is favored by some, but dismiss the opinions of others, sometimes the majority of the community.

It shall be the decision of the community collectively to choose the how(and path) to take after conversations. That means when we have disagreements on hows(and/or their interpretations), each one of us should do our best to convey our idea of how (technical strategies with concrete technical reasonings, approach of supporting emerging needs, approach about existing use-cases, and their tradeoffs) to the community. The community collectively chooses.

We would anticipate everyone to put the factors (such as long-term development, evolving our existing components, community growth, the need of stability on some modules) into consideration. Of course everyone would have their own interpretation of how these goals boils down to a concrete decision.

In short, this is a question of process for the community to collectively make decisions on how, long term technical strategies, and their interpretation to some extent, and that is what this RFC is about.

[junrushao]

As a diverse community, there are clearly different opinions on rules and guidelines of community operation, and it's not unusually that people agree to disagree. As PMC members, it's our responsibility to take actions to navigate the way the community operates, hearing voices from the community, keeping our technical decisions up-to-date to the latest challenges in industry, and that is exactly why we need this process RFC - Clarify the rules and guidelines of community operation.

I think 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).

Textual interpretation, just as @tqchen said, is usually subject to personal opinions. This is why we need a process RFC to clarify how decision making process could potentially incorporate community needs. This is how I interpret "community as a whole".

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 see what you mean. Thanks for clarifying your position as a PMC member.

[yongwww]

+1! I really like this proposal! The ability to move fast is crucial in adapting to the ever-evolving AI infra. I like the concept of lazy majority of binding decisions, it could facilitate the decision-making process and make sense to me.

[csullivan]

Hi @leandron! Would you kindly consider posting the text changes you would like to see in order for you to lift your changes requested? This may help keep discussions concise as well as help others in the community understand your desires most directly.

If convenient to you, it could help discussion for these to be submitted as code changes suggestions in the github review. Reading from the document changes you propose would be helpful to avoid inflation of discussion on irrelevant topics that can frequently happen in committee and discussion threads.

Thanks for considering

[leandron]

Hi @leandron! Would you kindly consider posting the text changes you would like to see in order for you to lift your changes requested? This may help keep discussions concise as well as help others in the community understand your desires most directly.

If convenient to you, it could help discussion for these to be submitted as code changes suggestions in the github review. Reading from the document changes you propose would be helpful to avoid inflation of discussion on irrelevant topics that can frequently happen in committee and discussion threads.

Thanks for considering

Thanks @csullivan - here it is.

[leandron]

Suggested change

	- Establishment of a new module in the project.
	- Establishment of a new module in a new development branch or an optional module.

[tqchen]

Thank you for the suggestion. There are two possible ways we can go with here here.

• W0: a more restricted form, aka only new development branch or an optional modules.
• W1: While the original intention of strategic decisions that relates to any new module, period, including the core ones.

I understand that you would like to go with W0, while others would like to have W1. Given both W0 and W1 are related to how we operate, and they are exclusive to each other, after reviewing your inputs and others, I plan to keep the text as it is for now. I would mention your opinion, however, in the overall summary. You are also more than welcome to followup with these points in the community.

[Johnson9009]

I perfer W1, because it is very hard for downstream to maintain several branches to keep track with the community's important Work, especially for the commercial company that have customer release pressure.

[leandron]

Suggested change

	We propose the following clarification of the strategy decision process:
	We propose the following strategy decision process:

[leandron]

Suggested change

	- Adoption of a guidance-level community strategy to enable new directions or overall project evolution.
	- Adoption of a guidance-level community strategy to enable new directions or overall project evolution in the form of the deprecation of existing components or the introduction of breaking changes

[tqchen]

I am not sure I get it. strategy do not necessarily entail deprecation or breaking changes :) and i guess different people have different interpretation of breaking changes

[leandron]

I suggest this point to be removed, given in this aspect TVM is different from Hadoop (where this line was taken from), which releases many separate components e.g. HDFS, HBase etc.

In our case, "adopting a new codebase" would mean replacing the whole repository. In case I misunderstood, can you please make this point more specific to what is meant by "alternative codebase" in TVM?

Suggested change

- Adoption of a new codebase: When the codebase for an existing, released product is to be replaced with an alternative codebase.

[tqchen]

Thank you for your inputs, particular terminology have nothing to do with any of the components, but just the codebase of that the project product develops on. As verbatim it is very is clear, an alternative codebase of the product.

[leandron]

Suggested change

	- Feature Name: [Process RFC] Clarify Community Strategy Decision Process
	- Feature Name: [Process RFC] Establish a Community Strategy Decision Process

[tqchen]

Thank you for your input

ASF requires consensus on code-level contributions, but the case of long term strategy decisions are left unspecified for per project.

But I appreciate that some may have a different view, and that is a process issue(e.g. how the community operate), and is being decided procedurally by each ASF community, which we are doing right now.

[leandron]

Suggested change

	We have made attempts in the past to bring a more verbose processes, but this has proven to be less successful.
	We have made attempts in the past to bring a more verbose processes such as (please describe), but this has proven to be less successful due to (please expand)

[leandron]

Suggested change

	All these decisions are made after community conversations that get captured as part of the summary.
	All these decisions are made after community conversations that get captured as part of the summary, in the form of one or more RFCs.

[tqchen]

Thank you for your input. There are two possible ways to view how we want to approach things:

• W0: There needs to be extra RFCs as being requested in the text.
• W1: The discussion already cover the information needed, and the decision process provide an resolution in a simple and clear fashion that is understood by community members, in that case no RFC is necessary.

I understand that the request is W0. Given both W0 and W1 are related to how we operate, and they are exclusive to each other, after reviewing your inputs and others, I plan to keep the text in the form W1 for now and see whether community prefer the other one

[Johnson9009]

Everybody like RFC, so do I, because we can know the details of the design, everybody hate RFC when his changes is very obvious or clear, so do I. Instead of a beautiful RFC and slow implement, I perfer a workable code.

[leandron]

Suggested change

	One observation is that it is hard for broader volunteer developers and community members to follow complicated processes.
	One observation is that it is hard for broader volunteer developers and community members to follow complicated processes such as (please expand).

[Johnson9009]

e.g. I can't spend too much time to read a long long discussion article, if a commercial company will do a decision like this way, it will loss all customers.

[YuchenJin]

I fully support this RFC to require a 2/3 majority to make strategic decisions in TVM.

I'm in favor of the RFC text as it is now. It's clear and concise, while precise and effective.

[sunggg]

+1 given the fast moving nature of this space, I'm in favor of this change and I believe this will allow us adapt fast. Current RFC text seems clear to me.

[hsaputra]

+1 for this proposal

This will allow the project and community to move fast given the nature of the space that the project is in.
Very clear description on what the expectation from the community and the project.

NOTE: I saw a comment about having "value in having a stable architecture with a set of components", this is can be achieve via Git management and releases. We should NOT block progress for OSS projects as if they are internal enterprise based projects that need permissions on some VPs or business leaders to make decisions.

Reminder that PMC IS the leadership of any ASF Top Level Projects. So member of PMC needs to be able to balance and switch hats as they are contributing to the success of the project.

[hsaputra]

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.

I do Not think "we" are confused. Coming up with something new every couple of years actually should be happening for open source projects. API stability is another dimensions of evolution and progression that we could manage via versioning and release management.

I would not recommend to compare Apache TVM, or ASF, with other OSS projects and ecosystem. They are different and we will never try to operate and follow other communities on how to operate.

[psrivas2]

+1
I support this proposal. We need to be agile to be competitive in this fast moving space of AI / ML ecosystem, while at the same time ensure we are building robust, stable software architecture. 2/3rd majority strikes the right balance between those two options.

[tqchen]

Thank you everyone for your inputs so far. We have had many related conversations over the past year and get collective inputs on different views to approach this process. Based on the inputs so far over the past year, I opened a vote to bring forward the version that most in the discussion thread prefers so we can bring clarity to this process.

apache/tvm#15521

Thank you

[mbaret]

+1
I think this is a substantially improved proposal compared with the similar RFC from last year, being more concise and using a 2/3rds majority which feels appropriate.

[sequoiar]

+1

the majority of community voted to accept simpler version of the process

[tqchen]

Link to the voting result thread

apache/tvm#15618

https://lists.apache.org/thread/bd0ph9j98r6sjm3wtp9174zgqqfhskt6