Hi Brian and our mentors, https://www.apache.org/foundation/voting.html says:
* Procedural : if there are more favourable votes than unfavourable ones, the issue is considered to have passed * Code modifications : a negative vote constitutes a veto * Package releases : Releases may not be vetoed. In https://lists.apache.org/thread/okldcghkrlzypyts6wt6s6b4wv6z217k , Brian wrote: > -1s only vetoes _releases_ in ASF practices. Otherwise, it's just one dissenting vote. The contradiction about the "-1" veto criteria is confusing us. Could you kindly clarify? Thanks! Toshiya On Thu, Jan 30, 2025 at 10:19 PM Toni Rikkola <[email protected]> wrote: > I have to agree with the conflict. The base rules are that -1 blocks code > change and -1 can not block a release. -1 has to be backed with a technical > justification. > Then it comes down to fighting about the definition of technical > justification. For example placing code to location X or Y, both have the > same justification for a -1. > > Kafka has overwritten the rules. The maturity model page states every > Apache project has to use the Apache voting rules. Are they not Apache? :) > Apache Community Development - A Maturity Model for Apache Projects > < > https://community.apache.org/apache-way/apache-project-maturity-model.html > > > > I feel that the proposal for proposal->voting wiki page could find > consensus so I will open that next week. > This will not only be for the current community. It will be useful for any > new comers. > > FYI: > I have been suggested ( off list ) it might make sense to just escalate > this to find a resolution. > Several other sources also stated it is just us who are participating in > this :) > > Toni > > On Thu, Jan 30, 2025 at 2:29 PM Francisco Javier Tirado Sarti < > [email protected]> wrote: > > > Hi Toni, > > Regardless of what we consider a procedural issue (I agree with you that > > removing Springboot is not a procedural issue), I think there is a clear > > contradiction between what the document said and what the mentor told. > > -1 in code review is clearly a veto Also note that -1 for code review > > should only be used when there is a real issue with the change. So, as > > clearly stated, you should use -1 only for veto changes that cause an > > issue. > > For example, in my opinion. > > Good usage of -1 in code modifications, "this does not to be removed > > because can be fixed this way" or "this changes cause a performance issue > > and the real problem is that close is not getting invoked" or "we have a > > lot of users that rely on this functionality, so removing it will cause a > > lot of noise in the community" (in this later case, evidence of > > usage/interest should be attached or at least commitment to > maintain/evolve > > that functionality) > > Bad usage of -1 in code modifications, "the word oracle appears in a > > comment" or "I have a bad feeling about this" or "there is a lot of > users" > > (but those users are never identified) > > > > > > On Thu, Jan 30, 2025 at 12:25 PM Toni Rikkola <[email protected]> > wrote: > > > > > Code modification has lower priority in voting than removing > Optaplanner, > > > since removing Optaplanner affects external API, brand, web sites, the > > Git > > > repository structure and removing a big part of the community ( the > users > > > ). > > > > > > Code modification is every PR that has been created. So with -1 I can > > block > > > every PR that is not delivering a feature I want? > > > > > > Things to keep in mind. Our *mentor from Apache* already stated -1 only > > > blocks releases. > > > Re: [DISCUSSION] Getting things done-Apache Mail Archives > > > <https://lists.apache.org/thread/1vrtdv4jy3db8wj86bgd3w6ofd0w5zb8> > > > > > > Our own "rule of books" aka wiki points to KAFKA rules about this. > > > Our wiki: Communication within Apache - Apache KIE - Apache Software > > > Foundation > > > < > > > > > > https://cwiki.apache.org/confluence/display/KIE/Communication+within+Apache > > > > > > > Kafka Bylaws: Bylaws - Apache Kafka - Apache Software Foundation > > > < > > > https://cwiki.apache.org/confluence/display/KAFKA/Bylaws#Bylaws-Approvals > > > > > > > > > > Apache is pretty clear about how to solve practices that cause harm to > > open > > > source projects by denial. Not having documentation is something I > think > > we > > > all can agree is causing harm to us. > > > AW: [DISCUSS] PMC Structure and Leadership for KIE-Apache Mail Archives > > > <https://lists.apache.org/thread/joy9ofdg287x27tzhf0rwgjgkks09t6j> > > > Right now I only see one proposal coming that can actually deliver > > anything > > > for documentation. There is nobody else to work on it. The community > > > absolutely needs it. > > > > > > I am also seeing the method I am writing here as the only solution to > > this. > > > I do appreciate the comments and additions by everyone and my mind on > > what > > > should be done has changed by them. I urge anyone to step up and give > any > > > input. Let's keep discussing for some time, but at one point I will > start > > > writing our own wiki page for this and hopefully we can agree on > things. > > I > > > will make a proposal so everyone can comment and help. Then I will > make a > > > vote. > > > > > > If we do not come to an agreement on our own, meaning there is a single > > -1 > > > in the vote I will make (since that is a hard no based on some of the > > > community members ATM). Then there is no other option than escalate to > > > Apache and they will restructure everything in the way THEY want, not > us, > > > to make everything flow. I really hope things do not come to that since > > it > > > will be our hardest failure as a community. We should build ourselves > up. > > > > > > Now I am offering, not claiming ownership of the proposal. If anyone > else > > > wants to work on that I am happy to help or just watch and comment. > > > > > > Toni > > > > > > On Thu, Jan 30, 2025 at 11:28 AM Gabriele Cardosi < > > > [email protected]> wrote: > > > > > > > HI Tony, > > > > following the Apache document [1] about voting, there are three types > > of > > > > votes, each of which have different implications. > > > > So, I have the impression that, without the proper context, > discussing > > > just > > > > "-1" makes things harder to understand. > > > > > > > > From my POV, "Optaplanner" removal is mostly a general strategic > > > discussion > > > > topic, and I would put it under "procedural issues" > > > > > > > > If, on the other side, there is a proposal with an actual > > implementation > > > of > > > > some modification (i.e. some PR, code modification, etc) then it will > > > fall > > > > under "code modifications" > > > > > > > > Please correct me if my interpretation is wrong, especially with > regard > > > to > > > > "procedural issues" meaning. > > > > > > > > Cheers :) > > > > > > > > [1] https://www.apache.org/foundation/voting.html > > > > > > > > > > > > > > > > Il giorno gio 30 gen 2025 alle ore 09:31 Toni Rikkola < > > > [email protected] > > > > > > > > > ha scritto: > > > > > > > > > I will add another concerning case about the -1 vote. We do need to > > get > > > > the > > > > > functionality validated, but if it blocks a proposal, then we have > to > > > > > understand what it means. > > > > > > > > > > SpringBoot was a good example and as Francisco said maybe there is > > one > > > > > person who wants to keep it and work on it. That is fine. > > > > > > > > > > However the -1, as the link provides states, there just needs to > > have a > > > > > justification brought up with no requirement for action. > > > > > > > > > > One big problem for us will be the Optaplanner codes. At the moment > > > there > > > > > is nobody working on that. It is a big part of KIE, with its own > > > website, > > > > > documentation and branding. > > > > > Small bug in it. For sure we will find someone to fix it. What > about > > a > > > > > security issue that takes a week to fix? > > > > > We have a vote to ask if Optaplanner can be removed. It gets a -1, > a > > > huge > > > > > part of the brand and the Optaplanner user community is left > standing > > > > > on nothing. A valid reason. > > > > > We have a vote to ask if we can make a release. There is a security > > > issue > > > > > in our codes, it gets a -1. We can not release it because of a > > security > > > > > issue. A valid reason. > > > > > The community has painted itself in a corner. > > > > > > > > > > That is why we need to figure this out. We can leave things out > like > > > the > > > > > documentation and things keep rolling, but what if we need to get > > > > something > > > > > out. > > > > > I say for these bits there needs to be a proof of contribution to > the > > > > area > > > > > that is affected on to justify the -1. > > > > > > > > > > Toni > > > > > > > > > > On Wed, Jan 29, 2025 at 5:01 PM Toni Rikkola <[email protected]> > > > > wrote: > > > > > > > > > > > Good comments from everyone. > > > > > > One thing I forgot to mention is. I am not looking for getting > > things > > > > > done > > > > > > as fast as possible by any means. I am hoping we find a forward > > > driving > > > > > > process to reach a decision that is backed up by the community as > > > > > > efficiently as possible. > > > > > > > > > > > > Few replies to each one of you. > > > > > > > > > > > > Enrique > > > > > > > > > > > >> In some cases like code changes. -1 is a veto. We cannot > redefine > > > the > > > > > >> process. (That is what I understand from there) > > > > > > > > > > > > > > > > > > This is a problematic one. Our mentor mentioned in the "getting > > > things > > > > > > done" that this only applies to releases. > > > > > > The problem is opposite to making a proposal and delegating. It > > > blocks > > > > > > work without any intention to contribute to a solution. > > > > > > It sounds like we need to check this from people higher to us in > > the > > > > > > Apache foundation. > > > > > > > > > > > > Gabriele > > > > > > > > > > > >> And that's the root of the friction that we currently have, > since > > > > > probably > > > > > >> not everyone has the same knowledge, understanding, or even time > > to > > > > > think > > > > > >> in a long term perspective. > > > > > > > > > > > > > > > > > > Also time and time is money. If a task does not profit the > company > > > you > > > > > > work for and it takes over a week. Getting justification to work > on > > > > that > > > > > > during company time is difficult. Same thing was happening in the > > > past. > > > > > It > > > > > > was not about the lack of skill to fix things, but the lack of > > > > > time=money. > > > > > > Work is limited by time, skill, money and motivation. > > > > > > > > > > > > Francisco > > > > > > > > > > > >> For example, in the documentation > > > > > >> discussion, to find a compromise it is as easy as not storing > the > > > docs > > > > > in > > > > > >> tools repo and store them in a dedicated one. The resource > problem > > > you > > > > > >> describe is absurd from a logical point of view, if the proposal > > > > exists, > > > > > >> it > > > > > >> is because there are resources to write the docs, which is the > > bulk > > > of > > > > > the > > > > > >> work. > > > > > > > > > > > > > > > > > > It is fine to ask for changes on the proposal. This is why it can > > be > > > > > > edited. Problem is the contributor can have limitations and that > is > > > why > > > > > the > > > > > > change is not approved. If the one proposing is doing the work on > > his > > > > own > > > > > > time, it can be motivation. If that person is getting paid, it > > comes > > > > down > > > > > > to if the company they are funded by wants to pay for it as it > is. > > > For > > > > > this > > > > > > reason I really hope we find a way to work for a common goal with > > > > > > compromises. As a community we can not force anyone, everything > we > > > get > > > > > is a > > > > > > donation from some source. > > > > > > > > > > > > Toni > > > > > > > > > > > > On Wed, Jan 29, 2025 at 4:13 PM Francisco Javier Tirado Sarti < > > > > > > [email protected]> wrote: > > > > > > > > > > > >> Hi Toni , > > > > > >> > > > > > >> Just one annotation. > > > > > >> > > > > > >> "If you absolutely disagree, make a countering proposal. But > know > > > that > > > > > you > > > > > >> have to find the resources for implementing it, better to try > and > > > > > >> compromise with the original." > > > > > >> > > > > > >> As mentioned by Enrique, it depends on the problem statement. > Also > > > you > > > > > >> might agree with the what to do, but not with the how. > > > > > >> So, I would differentiate between > > > > > >> - "I agree that we need to do something, but I would do it in a > > > > > different > > > > > >> way" In that case, the one that needs to find a compromise is > the > > > > > proposal > > > > > >> author (not the other way around). For example, in the > > documentation > > > > > >> discussion, to find a compromise it is as easy as not storing > the > > > docs > > > > > in > > > > > >> tools repo and store them in a dedicated one. The resource > problem > > > you > > > > > >> describe is absurd from a logical point of view, if the proposal > > > > exists, > > > > > >> it > > > > > >> is because there are resources to write the docs, which is the > > bulk > > > of > > > > > the > > > > > >> work. > > > > > >> - "I think we do not need to do anything" In that case, it is > > > > impossible > > > > > >> to > > > > > >> find a compromise and probably we should vote as soon as > possible. > > > And > > > > > the > > > > > >> vote should be: does the problem statement really describe a > > > problem > > > > we > > > > > >> need to fix?. Enrique mentioned the Sprinboot thing as an > > > > illustrative > > > > > >> example. I agree, but, who knows, maybe there is a majority that > > > wants > > > > > to > > > > > >> remove SpringBoot support, then, why not? Which kind of majority > > do > > > we > > > > > >> need > > > > > >> in those cases? In my opinion, a proposal for removing a > > > functionality > > > > > (I > > > > > >> remark the word functionality) needs unanimity. If there is > just > > > one > > > > > >> committer that wants to keep it, lets keep it. (Probably that > > > comitter > > > > > >> will > > > > > >> take charge of supporting that functionality himself) There > might > > be > > > > > other > > > > > >> cases that heavily affect everyone's development work, for > example > > > the > > > > > >> mono > > > > > >> repo thing, that might require unanimity also. I'm not so sure > > > > unanimity > > > > > >> should be required for stuff such as "Task refactoring", "Status > > on > > > > data > > > > > >> index", "Adding more queries to data-index", "Do some > prototyping > > on > > > > > >> drools" (some of them, pretty curiously, were quickly rejected > and > > > > then > > > > > >> nobody mention that the person blocking them was jeopardizing > the > > > > > >> community > > > > > >> progress). Things that basically add new functionality which > some > > > > > comitter > > > > > >> is willing to work with and is not going to affect others > > > productivity > > > > > or > > > > > >> the long term viability of the project. > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> On Wed, Jan 29, 2025 at 12:58 PM Gabriele Cardosi < > > > > > >> [email protected]> wrote: > > > > > >> > > > > > >> > Hi Tony, > > > > > >> > thanks for starting this, anyway there is a bit that maybe > needs > > > > > >> > clarification, and interestingly Enrique raised the same > points > > > > while > > > > > I > > > > > >> was > > > > > >> > writing this one. > > > > > >> > I reply almost exactly what he wrote, but in a different way. > > > > > >> > First, I'm also referring to Apache Voting Process here -> > > > > > >> > https://www.apache.org/foundation/voting.html > > > > > >> > that clearly defines three kinds of votes: > > > > > >> > > > > > > >> > - procedural > > > > > >> > - code modifications > > > > > >> > - package > > > > > >> > > > > > > >> > And since decisions are made on top of votes that are > expressed > > > > inside > > > > > >> mail > > > > > >> > threads, we need to clarify exactly how each kind of thread > > > > > (Discussion > > > > > >> vs > > > > > >> > Proposal) maps to the kind of vote. > > > > > >> > Then, it should be clear that code modifications are just the > > last > > > > > part, > > > > > >> > i.e. the implementation of a general idea/approach, that > should > > be > > > > > first > > > > > >> > and foremost discussed previously. > > > > > >> > I invite anyone to read in first person what the > > > > > >> > https://www.apache.org/foundation/voting.html document > states, > > to > > > > > have > > > > > >> a > > > > > >> > first-hand opinion of how the Apache Foundation means to be a > > > > > >> "democratic" > > > > > >> > approach to open-source. > > > > > >> > And this sentence seems interesting in that regard -> > > > > > >> > > > > > > >> > The community should spell out in its guidelines the tacit > > > > > implications > > > > > >> of > > > > > >> > > voting. However, *in no case* may someone's vote be > considered > > > > > >> invalid if > > > > > >> > > it does not appear to meet the implied commitment: a vote > is a > > > > > formal > > > > > >> > > expression of opinion, *not* of commitment. > > > > > >> > > > > > > > >> > > > > > > >> > WIth that in mind, I think that, as a general rule, any > > *proposal* > > > > > (i.e. > > > > > >> > actual code modification) that has a global impact should > > follow, > > > > i.e > > > > > >> > should be preceded by, a thorough *discussion*. > > > > > >> > And, as the document seems to imply (IIUC) if the overall idea > > is > > > > > >> rejected, > > > > > >> > then there is no obligation to commit to any other > alternative. > > > > > >> > And the clear reason for that, IMO, is that we should avoid > the > > > risk > > > > > >> that > > > > > >> > the code will be modified on a "per-availability" basis. > > > > > >> > > > > > > >> > Behind the scenes of those threads, it seems that someone > > believes > > > > > that > > > > > >> > making a lot of things, fast, means producing a lot of results > > in > > > > the > > > > > >> long > > > > > >> > term. > > > > > >> > Alas, while this could be true for a RnD setup, driven mostly > by > > > > > >> innovation > > > > > >> > and alternative approaches, for enterprise-level code this is > > not > > > > so. > > > > > >> > What really matters, in day-by-day usage, is the > time-to-release > > > of > > > > > new > > > > > >> > features or bug fixes: this real productivity. > > > > > >> > Any change that slows down it, directly or indirectly, it is a > > > > > problem, > > > > > >> not > > > > > >> > a solution. > > > > > >> > Funny enough, most of us are, and have been, extremely busy to > > fix > > > > or > > > > > >> > workaround problems that have been created by some previous, > > > > > >> unfortunate, > > > > > >> > choices, which have always been justified by some "immediate > > need" > > > > > >> that, at > > > > > >> > the end of the day, some time were not even really needed. > > > > > >> > Instead of providing real value, a lot of our work is burned > by > > > > trying > > > > > >> to > > > > > >> > cope with the previous mistakes, which, for some reason, seems > > to > > > be > > > > > >> > undebatable as sculpted in the stone. > > > > > >> > And that's the root of the friction that we currently have, > > since > > > > > >> probably > > > > > >> > not everyone has the same knowledge, understanding, or even > time > > > to > > > > > >> think > > > > > >> > in a long term perspective. > > > > > >> > > > > > > >> > Cheers :) > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > > > > > > >> > Il giorno mer 29 gen 2025 alle ore 12:10 Toni Rikkola < > > > > > >> [email protected] > > > > > >> > > > > > > > >> > ha scritto: > > > > > >> > > > > > > >> > > Hello, > > > > > >> > > > > > > > >> > > We are still maturing as a community and the process on how > to > > > > > decide > > > > > >> > > important things for the entire community needs to be > cleared > > > up. > > > > > >> After > > > > > >> > my > > > > > >> > > previous email about getting things done several good ideas > > came > > > > up, > > > > > >> it > > > > > >> > > raised some good comments and questions both off and on > list. > > To > > > > > clear > > > > > >> > > things up we need to be sure that we are on the same page to > > > bring > > > > > >> trust > > > > > >> > > into the community and remove doubt. > > > > > >> > > > > > > > >> > > There is also some overloading on the terms. While you can > for > > > > > example > > > > > >> > > propose in any context. A proposal for the community, that > can > > > be > > > > > >> acted > > > > > >> > on, > > > > > >> > > is an email thread with the [PROPOSAL] in the title. > > > > > >> > > > > > > > >> > > I took the process from other Apache communities. This is > > > > influenced > > > > > >> by > > > > > >> > how > > > > > >> > > I see things and I am not the boss here. We can customise it > > to > > > > our > > > > > >> > needs. > > > > > >> > > If I got something wrong I hope our mentor can correct us. > > > > > >> > > > > > > > >> > > *Each item is driven by an email thread in this list.* > > > > > >> > > > > > > > >> > > *[DISCUSSION]* > > > > > >> > > > > > > > >> > > Free speech, no commitment, any idea is welcomed. > > > > > >> > > Important to know is that no decisions can be made. > > > > > >> > > > > > > > >> > > *[PROPOSAL]* > > > > > >> > > > > > > > >> > > Mutable. Who starts the proposal leads it. Make a wiki page > > for > > > > the > > > > > >> > > proposal and link it in the start. People commenting can > > request > > > > > >> changes, > > > > > >> > > if approved the proposal wiki is edited to maintain the > > latest. > > > > > >> > > The person who started the proposal thread has to know how > to > > > get > > > > > >> > resources > > > > > >> > > and what the limits of those resources are. For example > > > deadlines, > > > > > >> > > motivation, skill or time issues. Same as any task in any > > > company. > > > > > >> > Proposal > > > > > >> > > creators should not agree on anything they can not deliver. > > > > > >> > > > > > > > >> > > Porcelli made a pretty good template to use when making a > > > > proposal. > > > > > >> > > - Problem Statement: Clearly define the issue being > addressed. > > > > > >> > > - Action Plan: Outline the steps to address the issue. > > > > > >> > > - Commitment: Specify who will take ownership of the action > > plan > > > > > and a > > > > > >> > > rough timeline for execution. > > > > > >> > > > > > > > >> > > If you absolutely disagree, make a countering proposal. But > > know > > > > > that > > > > > >> you > > > > > >> > > have to find the resources for implementing it, better to > try > > > and > > > > > >> > > compromise with the original. > > > > > >> > > You can offer help. > > > > > >> > > No final decisions can be made, but +-1 can be used to > signal > > > > voting > > > > > >> > > intentions. +-1 at this stage is not binding, you can vote > > > > > >> differently. > > > > > >> > > > > > > > >> > > *[VOTE]* > > > > > >> > > > > > > > >> > > Immutable. If there was a proposal, take a timed snapshot of > > it > > > > and > > > > > >> add > > > > > >> > it > > > > > >> > > into the thread. > > > > > >> > > Voting is done here, decisions are made here. If votes pass > > the > > > > > thread > > > > > >> > is a > > > > > >> > > signed contract that everyone agrees. -1 votes do not cancel > > the > > > > > vote > > > > > >> > > unless it is a vote for a release. When PR is done if it > does > > > not > > > > > >> follow > > > > > >> > > this contract it can be challenged. Vote does not have to > > have a > > > > > >> proposal > > > > > >> > > in advance, but it can help to get the best result. No > changes > > > can > > > > > be > > > > > >> > done > > > > > >> > > during a vote. You should not need to scroll down 10 emails > to > > > see > > > > > >> what > > > > > >> > was > > > > > >> > > agreed on. > > > > > >> > > > > > > > >> > > *Things that can happen.* > > > > > >> > > > > > > > >> > > Example is the upcoming documentation proposal/vote, > > discussion > > > > was > > > > > >> > already > > > > > >> > > done. Vote does not pass. A countering proposal would pass > > > votes, > > > > > but > > > > > >> > there > > > > > >> > > is nobody to work on it. We end up with no documentation. > The > > > > > >> community > > > > > >> > did > > > > > >> > > not agree on creating them with the resources at hand. > > > > > >> > > > > > > > >> > > A discussion item like the monorepo keeps coming back in > > > > > discussions. > > > > > >> > These > > > > > >> > > cycles reduce productivity. We make a vote if we want one or > > > not. > > > > No > > > > > >> > reason > > > > > >> > > to bring it up unless you feel like a revote changes the > > result. > > > > > >> > > > > > > > >> > > Jason mentioned that in the past this location was suggested > > as > > > > the > > > > > >> wiki > > > > > >> > > location. > > > > > >> > > https://cwiki.apache.org/confluence/display/KIE > > > > > >> > > > > > > > >> > > Hoping to move us forward. > > > > > >> > > Toni > > > > > >> > > > > > > > >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
