thanks for the replies here, everyone. @comaniac
>-1 is totally fine and I don't think this Process RFC forbids this. On the >other hand, if an RFC is suspensive for a while but we still cannot make every >-1 voter happy, it doesn't make sense to me to reject the RFC (we don't >actually "reject" it, but prevent it from merging forever is basically the >same as reject). I guess my point here though is: we have this problem for PRs too. We trust committers and PMC members not to blockade PRs so long as everyone is collaborating. For ordinary RFCs, we have the same situation. We achieve lazy consensus through discussion. In cases where there is a disagreement that cannot be resolved, and the argument has run its course, I agree it may become necessary to relax the requirement of lazy consensus in the name of progress. I am not aware of such a case in the project right now. To be explicit: in the case of the [Relax RFC](https://github.com/apache/tvm-rfcs/pull/89), the authors have not answered some key questions that contribute to "discussions about how the proposal fits into the project." My understanding is that those answers are coming so the argument is not deadlocked. @sunggg > Are you suggesting the consensus is the right way to go for this optional > module? If so, I'm wondering how you define the consensus. IMHO, reaching > unanimous might be practically impossible for the large community like this Sorry--to clarify my original post, I am suggesting we adopt the same voting mechanism as we do for PRs and ordinary RFCs. > it does not seem to fit for S0: by definition, S0 is to satisfy clear needs > from some users in the community, not the entire users. I'm afraid if too > high bar for optional module may discourage contributors. It seems like 3 PMC approvers is a higher bar for newcomers than merely getting a +1 from a committer. > This quote below sounds more about the standard process of how we digest a > giant commit, which could be orthogonal to voting rules. This was meant to serve as an example of the effect of adopting a resolution such as replacing the implementation of a large component or adopting a submodule could wind up impacting the project in ways that materially determine its future. It is common for projects to fork when two different factions cannot reach consensus on a change of this magnitude. In such cases, I could see the need to relax the consensus requirement in order to decide which way the original project will go. By contrast, an S0 proposal clearly limits its blast radius and should not impact a project to the degree of forking. I don't see a clear reason why we cannot use the same voting mechanism we do for PRs and RFCs here. -- Reply to this email directly or view it on GitHub: https://github.com/apache/tvm-rfcs/pull/95#issuecomment-1285017979 You are receiving this because you are subscribed to this thread. Message ID: <apache/tvm-rfcs/pull/95/c1285017...@github.com>
