Hi Paolo, Perhaps the wording in the voting process [1] page is not accurate. In my understanding, the "Binding votes" part is appled for all the three vote types. It writes:
> Who can vote is, to some extent, a community-specific thing. > > PMC members have formally binding votes, but in general communities encourage > all their members to vote, even if their votes are only advisory. [1] https://www.apache.org/foundation/voting.html This is also true for "Votes on code modifications." So, "a negative vote constitutes a veto" means "a negative _binding_ vote constitutes a veto." Back to the divergent discussion on features, I second what Dave says. In my experience, the proposer can first initialize a discussion, receive comments, and try to resolve concerns, whether or not it's from a PPMC member. When all the concerns are well considered, the proposal can start a vote of the proposal, with a section mentioning all the discussed topics. For reference, Flink documents their discarded proposal at [2] ("Discarded"). You can read their discussion to see the lifecycle of a rejected proposal in that community. [2] https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals Best, tison. Paolo Bizzarri <pibi...@gmail.com> 于2025年3月12日周三 15:39写道： > > On Wed, Mar 12, 2025 at 1:02 AM Dave Fisher <w...@apache.org> wrote: > > Hi Dave, first thank you for your reply. > > > > > > I’m not part of your community, so it is possible I’m misreading this, > > but I see some issues from a casual glance. IMO, the two proposals need to > > be discussed further and consensus reached before moving forward. Calling > > for a vote without discussion, like the second proposal, is not how things > > are done in ASF projects. > > > > It looks like some community problems have been identified, discussed a > > lot with no consensus, then complex proposals were created by a couple of > > committers, these proposals were not discussed and instead pushed to a > > vote. I am not surprised that a number of community members responded with > > a -1. > > > > I think that rather than have an abstract battle on how to vote the > > proposers should do some work by adding to this examples repository. If it > > accomplishes what the proposers think it will then having it will help > > convince the rest of the community, and then the rest of the work can > > continue. > > > > > I agree not having an abstract battle, but at the same time I would like to > have a clarification on which is the Apache rules for votes like this. > Looking at the Apache document on voting, it seem clear to me that -1 is a > veto on code changes. > > Alex Porcelli said that this is not the case, but I can't find an Apache > docs saying this. Brian Profitt, one of our mentors, suggested to ask the > IPMC mailing list and here I am asking. > > I can discuss on the specific case, but I would prefer to have first a > solid foundation on what are the agreed default Apache rules on these > topics and where they are documented. > > Regards > > P. > > > > > Best, > > Dave > > > > > > > > Kind Regards, > > > Justin > > > > > >> On 12 Mar 2025, at 7:48 AM, Paolo Bizzarri <pibi...@gmail.com> wrote: > > >> > > >> Hello, > > >> > > >> this is Paolo Bizzarri. I am part of the Apache Kie project. > > >> > > >> I am looking for clarifications about the official policy of Apache > > >> foundation about code changes and vetoes. > > >> > > >> As per this document in the Apache web site, a -1 to a proposal for a > > code > > >> change is a veto - i.e. it "kills the proposals" > > >> > > >> > > https://www.apache.org/foundation/voting.html#:~:text=Votes%20On%20Code%20Modification,approve%20of%20this%20change.%27 > > >> > > >> However we got two proposals that are getting pushed through even in > > >> presence of -1 > > >> > > >> https://lists.apache.org/thread/drojdtvz6xx1zo35ggjm75xdngnfcl21 > > >> > > >> and > > >> > > >> https://lists.apache.org/thread/c09l9xq0d8jz7th6k23gf5svoky06955 > > >> > > >> I got an answer from Alex Porcelly stating that "-1 are not vetos on > > >> proposals" which seems wrong to me. These are code changes and so the > > rules > > >> for vetoes should apply. > > >> > > >> Otherwise I could make a proposal like "put all passwords in plain text > > in > > >> the code" and then pretend that the PR cannot be vetoed because the > > >> corresponding proposal has already been approved, so there is consensus. > > >> > > >> https://lists.apache.org/thread/r37j54k3fyg5h18d4xdlb43ff9wcq96b > > >> > > >> Can you clarify and provide an answer that I can forward to the kie > > mailing > > >> list? > > >> > > >> I understand that some projects have defined less restricting veto > > >> policies, but I understand also that this is a matter of internal rules > > - > > >> i.e. a way for the community of a project to decide how to work. My > > >> understanding is that in the absence of such a decision, the Apache > > default > > >> rules apply. > > >> > > >> Regards > > >> > > >> Paolo Bizzarri > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
