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 < ftira...@redhat.com> 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 <trikk...@redhat.com> 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 < > > gabriele.card...@gmail.com> 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 < > > trikk...@redhat.com > > > > > > > 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 <trikk...@redhat.com> > > > 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 < > > > > > ftira...@redhat.com> 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 < > > > > >> gabriele.card...@gmail.com> 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 < > > > > >> trikk...@redhat.com > > > > >> > > > > > > >> > 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 > > > > >> > > > > > > >> > > > > > >> > > > > > > > > > > > > > > >
