Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)
I appreciate you guys bringing this back up, and I appreciate the goal here of establishing a project policy to ensure we're welcoming to new projects as the MLC landscape changes. I still have some reservations about this proposal in its current form, but I would support it if a small number of changes were made. Here is what I think it needs: 1. **Approval mechanism**. I disagree with @Hzfengsy's statement that "establishing a scoped module is not a typical code change." Because the typical S0 module would reside inside `apache/tvm` on `main`, a subproject at the moment is essentially several PRs that add code to the codebase. This is a typical code change, so I don't see a reason to adopt Lazy Majority consensus here. I appreciate that Hive uses Lazy Majority, but Hive has [52 PMCs and 104 committers](https://projects.apache.org/committee.html?hive), and also has a process by which committers and PMCs automatically gain [emeritus status](https://cwiki.apache.org/confluence/display/Hive//Bylaws#Bylaws-Committers) after 6 months of inactivity. TVM has a much smaller PMC. I would support this proposal if Lazy Consensus was the voting mechanism. One of my practical concerns here is that we lose recourse for preventing overload of the CI. And while I do want us to be welcoming of new projects, I could see the following situation arising that would place committers in an awkward position: 1. A new S0 module is proposed and a majority of PMC members approve. The S0 module is accepted. 2. PRs for the new module begin to merge. 3. At some point, the integration test suite is added, but this involves regression tests that add 1 hour to the CI. The proposer either doesn't have time to rewrite the tests, or it's not practical to do so. Meanwhile a committer more familiar with the CI flags this, but the proposer cites acceptance of the RFC as grounds that the project has chosen to merge the new S0 module and its tests. CI is a bit tricky since it's complex enough that not everyone understands it, but it's a shared community resource that underpins the whole project. I think that choosing community over code means that we don't overextend the project so that we can ensure that such shared resources are available to everyone to work towards the project's goals. While I agree the community has been generally involved with keeping the CI green, only 4 of 20 PMCs have made or been involved with [changes](https://github.com/apache/tvm/commits/main/Jenkinsfile) to `Jenkinsfile` in the past year (and of those, only 2 made changes other than updating a CI image). Changing Jenkinsfile is the primary way we do things like resharding tests to reduce apparent CI runtime. I'm not sure Lazy majority is the right tool to evaluate this aspect of the decision, considering that adding S0 modules may involve significant changes to the CI. To conjure another situation at the other end of the spectrum: Someone new to the project proposes that we add an S0 module, but although they get a few supporters, they don't manage to get majority PMC support. Perhaps they don't know many PMCs, or the PMC doesn't know much about the relevant subject area. Is the proposal rejected? Majority seems like it could also be a high bar here, and if we intentionally adopt a different voting mechanism to accept new projects, the rules seem more confusing for newcomers. It doesn't make sense to me to have two different voting mechanisms involved with adding code (one for PRs, and one for RFCs that propose a bunch of PRs to add isolated code). There are many situations today in which committers and PMCs can block changes to the project, and we rely on a sense of community to avoid such deadlock. I continue to think that fostering consensus in the community is the best way to choose community over code. Should we come to a point where the community needs to choose between two paths forward, such as when making an S1 -> S2 change, and consensus cannot be reached, then that is a case where I think Lazy Majority may be a reasonable path to making forward progress. 2. **S1 and S2 module lifecycle**. This RFC talks a lot about S0 proposals, and it is great that we are creating a welcoming stance towards new contributions. However, I would like to see the proposal rounded out with discussion of how an S0 module should become S1 and how an S1 module can deprecate others (i.e. S1 -> S2). I agree that some of this is covered in the RFC today, but because the RFC doesn't include complete discussions around the S1 and S2 phases, I think it's hard to understand the S1 and S2 concepts. Here's a specific example: > There can be follow-up steps (S1), such as making a dialect broadly accessible in existing compilation flows. This sentence, inside "Background," discusses the existence of S1 steps, giving one example. However, the way it's worded makes it sound like others may
Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)
Thank you @areusch . First of all, I think @Hzfengsy has already addressed many points you bought up in the past, including: - Putting the CI/testing as part of the important factors to consider - Clarifying the definition of S0 - Clarifyng n how deprecation of S0 happens I would like to acknowledge that you have made your point clearly in your last point. Most of those points are disagreement on how to do things. In light of such disagreement, it is important to acknowledge each others’ view, reevaluate, and come back to also put the community's voices into consideration. Let me first try to address some of the cases you bought up: My read is that the decision is around “module-establishment” but not blank approval of all code that comes. All the subsequent code changes are still subject to the normal review process. CI is indeed one important area of the codebase. It is also equally important in other areas, such as community member contributing code, document, importer, different modules. No area is certain superior to another one. We are working together to empower each other. One thing to keep in mind though is that CI/testing is only good if we have community members who come and use them. It is a great thing to have comprehensive tests, and we work collectively to resolve issues in testing, CI, system design, documentation and other places. Remember we are fostering a culture that empowers each other. Let us see how the two scenarios you mentioned will play out in the empowering culture (which I believe we all strive to do): Imagine at some point, the integration test suite is added, but this involves regression tests that add 1 hour to the CI. That particular code is receiving the normal review process, and will be blocked, which requires the contributing team to be mindful (either move integration, or come and help work CI to be able to support such cases): - When some regression happens after the code gets merged, open-minded team members can always come and revert the tests, and work together to improve them. - If it gets down to fixing Jenkinsfile, people volunteer to help, just like in other areas. I have personally helped maintain Jenkinsfile for the first few years and would be more than happy to help improve Jenkinsfile for a module that gets supported by the majority of community members. My belief is other members will also do so. - Bottom-line, despite some hiccups, we bring a module that welcomes more community members, while still keeping other modules to support other community members. Remember that problems do arise in the community and we work collectively to address them. We also have tools in our hands and multiple decision points(including reverting) to iteratively improve. If we simply block the gate, we simply will not have those troubles, nor will we empower or even have those community members around who would otherwise not be part of the community. It is great to us collaboratively working together iteratively – which means indeed a few disruptions, but we also welcome more people to work together to bring in improvements. We all pay our credits to the community in one way or another. While not everyone might help in CI, and reverting some of their PR might cause a bit of burden on others, they help reviewing code in other modules, fixing regression tests, writing docs, and bringing in architectures that reduces burdens. In the case of someone proposing a new S0 module and not getting majority support. That would entail that there is at least one -1 from the PMC members. Which also means that it would get rejected at any other possible mechanisms. Not knowing PMC won’t be a problem at all because many of us are eager to review, and empower good proposals from community members. I also do not think relevant subject areas would be a problem since we have some of the best experts in ML compilation. Again you will find how much of an empowerment mindset we have in here. Establishing a module indeed has a lot of factors to consider, there are more negative considerations from the PMC, likely they have already considered the code and community factors. In such cases, I would still expect us to see constructive conversation and reasoning. **OSS development is not a single bundled thing**. - We establish module - We add PR changes - We revert patches that brings regression, CI issue or other cases Each step has **their own contexts**, set of stakeholders. They can come from different people. Some volunteers can take over others. While it is important to set marks through RFC, roadmap, signaling, and strategy. It is also important to be able to facilitate and empower each other through each of those steps. The same thing applies to process RFCs. We bring in the process RFC to address things one step at a time. While clarifying S1, S2 is indeed important, which can be a topic of future discussions. Same w
Re: [apache/tvm-rfcs] [Process RFC] Empowering New Scoped Module to the Project (PR #95)
I want to come back and encourage that we take fine-grained steps. As @Hzfengsy mentioned, many community members, including himself, had to overcome a large language barrier to be able to come out and help facilitate this process. Having a dragging conversation simply due to bundling reduces the ability for volunteers to participate, which goes against core one principle of ASF – which is empowering everyone. We should reduce such burden by having well scoped proposals, knowing that with a growing community, the conversation always continues. One observation is that there can be a disagreement on how much bundling we have in making decisions. I would like to come back and acknowledge what you stated, @areusch have clearly made points– requiring all approvals, requiring S1 and S2 discussions, and bundling stability discussion to be addressed is a valid position on how we do things to establish this process. It is also clear that many others had a different position, that emphasizes on empowering the majority of the community, more fine-grained decision making so we don’t have to bundle all these conversations together and continue to empower each other. They are different valid opinions on how we shall operate. After acknowledging each other’s views, take these into context, and have a constructive conversation, I recommend listening to the majority community's voices and empowering the community. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1338702897 You are receiving this because you are subscribed to this thread. Message ID:
