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