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