Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Process RFC] Clarify Community Strategy Decision Process #102

Merged
merged 7 commits into from
Aug 25, 2023
Merged

[Process RFC] Clarify Community Strategy Decision Process #102

Changes from all commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
3340d95
[Process RFC] Clarify Community Strategy Decision Process
tqchen Aug 3, 2023
078aa9d
Update 0102-clarify-strategy-decision-process.md
tqchen Aug 3, 2023
c48f207
Update rfcs/0102-clarify-strategy-decision-process.md
tqchen Aug 3, 2023
a748eba
Include description of lazy 2/3 majority
tqchen Aug 3, 2023
a1d26e8
Update 0102-clarify-strategy-decision-process.md
tqchen Aug 4, 2023
21d140e
Update 0102-clarify-strategy-decision-process.md
tqchen Aug 4, 2023
d60925d
Finish
tqchen Aug 10, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
39 changes: 39 additions & 0 deletions rfcs/0102-clarify-strategy-decision-process.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,39 @@
Authors: @tqchen

- Feature Name: [Process RFC] Clarify Community Strategy Decision Process
leandron marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- Start Date: 2023-08-03
- RFC PR: [apache/tvm-rfcs#0102](https://github.com/apache/tvm-rfcs/pull/0102)
- GitHub Issue: [apache/tvm#0000](https://github.com/apache/tvm/issues/0000)

## Summary

Machine Learning Compilation (MLC) is an emerging field in fast development.
With the tremendous help from the whole community, it’s exciting to see that TVM delivers significant needs from and to
developers and thus has become widely popular in both academia and industry.

As the community pushes for different goals that help each other, naturally, there
are strategy decision points about overall directions and new modules adoptions.
These decisions are not fine-grained code-level changes but are important for a
community to be viable in the long term.
The process of bringing those changes is less clarified to the community, and hurdles can be high.
We have made attempts in the past to bring more verbose processes, but this has proven to be less successful.
One observation is that it is hard for broader volunteer developers and community members to follow complicated processes.
leandron marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Additionally, different members can have different interpretations of how to do things,
leading to stagnation and lack of participation from volunteer members.

We are in a different world now in the case of ML/AI ecosystem, and it is critical for
the community to be able to make collective decisions together and empower the community.
Following the practices of existing ASF projects (e.g. hadoop), we propose to use a simple process for strategic decisions.

## Proposal: Strategy Decision Process

We propose the following clarification of the strategy decision process:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

It takes lazy 2/3 majority (at least 3 votes and twice as many +1 votes as -1 votes)
of binding decisions to make the following strategic decisions in the TVM community:

- Adoption of a guidance-level community strategy to enable new directions or overall project evolution.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@tqchen tqchen Aug 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

- Establishment of a new module in the project.
leandron marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@tqchen tqchen Aug 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@tqchen tqchen Aug 8, 2023 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

If such a vote fails to gain approval, the existing code base will continue. This also covers the creation of new sub-projects within the project.

All these decisions are made after community conversations that get captured as part of the summary.
tqchen marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.