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