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