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 > > > >> > > > > > >> > > > > >> > > > > > > > > > >
