Tiago, I'm starting to see a pattern here Agree with Alex/Tiago => good for the community Do not agree with Alex/Tiago => bad for the community About "actions", I kindly refer to the number of contributions of every committer in several repos (not only tools) compared with the number of words written here. It's an objective thing, divide your lines of code by your lines of written text. I hope we agree the higher the ratio the better for community
On Fri, Jan 24, 2025 at 5:39 PM Tiago Bento <[email protected]> wrote: > It is exhausting and discouraging to have you participate in all > discussions with subjective criticism and condescendence accompanied > by little to no action. Even this "debate" you think you're having now > is not helping the community move forward and get things done. > > On Fri, Jan 24, 2025 at 12:55 PM Gabriele Cardosi > <[email protected]> wrote: > > > > Tiago, it also amazes me how unnecessary aggressive, and out of the > point, > > your own reply is. > > > > I simply stated something pretty obvious, i.e why some kind of discussion > > may arise: the very same thing could be viewed as something to be done > now > > for someone, and a technical debt for someone else. > > Since there is no proposal discussed in this thread, there is not even > the > > chance that I'm referring to anything here as "technical debt". > > > > And, it is exactly about giving room to everyone to share their own > ideas. > > > > > > > > Il giorno ven 24 gen 2025 alle ore 16:46 Tiago Bento < > [email protected]> > > ha scritto: > > > > > Francisco and Gabriele, it really does amaze me how anything contrary > > > to your views is "likely unnecessary", "almost universally questioned" > > > and/or "tech debt". Come on, guys. Give some room for other people to > > > have their ideas and move things forward in their own way. You don't > > > need to have an opinion about everything. > > > > > > On Fri, Jan 24, 2025 at 12:00 PM Gabriele Cardosi > > > <[email protected]> wrote: > > > > > > > > Hi all, > > > > I think Enrique clearly defined the problems and issues related to > > > > different kind of votes: [1] > > > > > > > > 1. > > > > > > > > Procedural Issues > > > > 2. > > > > > > > > Code modifications > > > > 3. Package releases > > > > > > > > The very same document states > > > > > > > > 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. > > > > > > > > > > > > > It is implied by their very nature that Proposal would raise a lot of > > > > discussions, IMO. Those discussions could also stray away from the > > > original > > > > message, because the original proposer overlooked some indirect > > > consequence. > > > > When that happens, there is the clash of two different approaches, > the > > > > "done is better than perfect", on one side, and the "let's avoid > > > increasing > > > > tech debt just to have a PR merged in" (please, bear with me - just > for > > > the > > > > sake of discussion). > > > > It is more than anything a mindset confrontation, and a fair > discussion > > > > should lead to the "best possible" (of course, not perfect) solution > that > > > > considers both POV. > > > > > > > > > > > > > > > > > > > > [1] https://www.apache.org/foundation/voting.html > > > > > > > > Il giorno ven 24 gen 2025 alle ore 14:50 Alex Porcelli < > [email protected] > > > > > > > > ha scritto: > > > > > > > > > Thank you for starting this critical discussion, Toni! > > > > > > > > > > You've raised some crucial points, and we're overlooking a > fundamental > > > > > principle: while discussions are valuable, opinions are only truly > > > > > constructive when paired with a commitment to action. > > > > > > > > > > Proposals play an essential role in balancing collaboration and > > > > > productivity. Sharing proposals before implementing changes helps > > > > > mitigate frustration, particularly when efforts like a PR are later > > > > > rejected. Proposals are intended to streamline discussions and > guide > > > > > us toward actionable solutions. > > > > > > > > > > That said, we've sometimes lost focus during proposal reviews. > > > > > Discussions often stray into abstract or tangential topics, > becoming > > > > > debates lacking actionable outcomes. This undermines the purpose of > > > > > proposals and stalls progress. > > > > > > > > > > The "done is better than perfect" principle should guide us. Those > who > > > > > take action—the doers—should not be held back by unstructured > > > > > opinions. Instead, opinions should come with a commitment to > address > > > > > the specific problem within the proposal's scope. Without that > > > > > commitment, such opinions should not carry weight in the > > > > > decision-making. > > > > > > > > > > To improve our workflows and ensure productive discussions, I > suggest > > > > > that proposals follow a basic structure: > > > > > > > > > > - 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. > > > > > > > > > > Engagement on proposals should focus on clarifying questions and > > > > > constructive feedback. If disagreements arise, they should be > > > > > accompanied by an alternative actionable plan with similar detail > and > > > > > commitment, including a timeline. Discussions that do not meet > these > > > > > criteria risk becoming noise and should be deprioritized. > > > > > > > > > > By adhering to this approach, we can foster a culture of > > > > > accountability and ensure that our discussions lead to meaningful > > > > > progress. > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Jan 24, 2025 at 7:44 AM Toni Rikkola <[email protected]> > > > wrote: > > > > > > > > > > > > The reason why I am separating ML and PR is that if there is no > PR > > > there > > > > > is > > > > > > no work done. Of course you might have a topic branch. Any talk > on ML > > > > > > without PR is just talk. Since there is no guarantee on delivery > due > > > to > > > > > the > > > > > > "hit by a bus" factor. Any work left over after a contributor is > > > lost can > > > > > > go stale fast unless someone else picks it up. Also ML list > > > definition > > > > > can > > > > > > differ from PR. > > > > > > > > > > > > I admit this is a very cold take on everything. That is why I was > > > saying > > > > > it > > > > > > is the bare minimum. > > > > > > > > > > > > Toshiya's work reported on the mailing list is a great example of > > > how to > > > > > do > > > > > > things. > > > > > > Propose -> Vote/PR -> Merge > > > > > > > > > > > > Then again the commits mailing list is busy. All the work there, > but > > > not > > > > > on > > > > > > this list, is going in due to trust among the community. > > > > > > > > > > > > Then we have the examples and documentation issues. Everybody > has an > > > > > > opinion. That is normal and discussion is needed. But... > > > > > > How to get things done? > > > > > > Who is the contributor doing the work? We can not order anyone > to do > > > it. > > > > > > Someone has to volunteer and then that contributor can make a > > > proposal > > > > > > based on the time that is available for it, with the skills they > > > have. > > > > > The > > > > > > contributor has to lead the change and know the limits that they > can > > > set > > > > > > and then everyone else has to be aware of the list of items I > > > brought up. > > > > > > > > > > > > Toni > > > > > > > > > > > > On Fri, Jan 24, 2025 at 11:52 AM Enrique Gonzalez Martinez < > > > > > > [email protected]> wrote: > > > > > > > > > > > > > Yeap. You are right. The problem with this sort of vague > guideline > > > is > > > > > that > > > > > > > what it means is a proper analysis of harm. That is an > arbitrary > > > > > > > definition. > > > > > > > Just an example about ruleflow thing in drools i might consider > > > that > > > > > > > removing it is a bad option but my understanding of drools is > > > limited > > > > > so my > > > > > > > opinion might not have the same weight as an expert realm. > Here the > > > > > > > structure is flat and everybody can jump into it. So at some > point > > > > > somebody > > > > > > > might feel an arbitrary call by somebody else. Which is > difficult > > > to > > > > > > > handle. > > > > > > > > > > > > > > El vie, 24 ene 2025, 10:35, Toni Rikkola <[email protected]> > > > > > escribió: > > > > > > > > > > > > > > > On -1 being veto. Based on the veto definition, the -1 voter > > > would > > > > > have > > > > > > > to > > > > > > > > prove that the proposal does more harm than not having it. > > > > > > > > > > > > > > > > To prevent vetoes from being used capriciously, the voter > must > > > > > provide > > > > > > > with > > > > > > > > > the veto a technical justification showing why the change > is > > > bad > > > > > > > (opens a > > > > > > > > > security exposure, negatively affects performance, etc. ). > A > > > veto > > > > > > > > without a > > > > > > > > > justification is invalid and has no weight. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Toni > > > > > > > > > > > > > > > > On Fri, Jan 24, 2025 at 11:24 AM Toni Rikkola < > > > [email protected]> > > > > > > > wrote: > > > > > > > > > > > > > > > > > I just wanted to make sure nobody sees my email as a set of > > > rules. > > > > > They > > > > > > > > > are just notifications and a heads up for how Open Source > > > > > communities > > > > > > > > work > > > > > > > > > based on my experience. > > > > > > > > > > > > > > > > > > This discussion is also a good place to argue in advance. > Since > > > > > when > > > > > > > the > > > > > > > > > list becomes a reality it can cause contributor rage quits, > > > forks > > > > > and > > > > > > > so > > > > > > > > on. > > > > > > > > > > > > > > > > > > The fact is, PR driven development will lead to > backstabbing > > > and > > > > > > > > > conflicts. These will happen and are part of the politics, > but > > > this > > > > > > > will > > > > > > > > > help to prevent it: > > > > > > > > > > > > > > > > > > We require a more broad view of the project and start > building > > > some > > > > > > > basic > > > > > > > > >> consensus > > > > > > > > > > > > > > > > > > > > > > > > > > > Toni > > > > > > > > > > > > > > > > > > On Fri, Jan 24, 2025 at 10:48 AM Enrique Gonzalez Martinez > < > > > > > > > > > [email protected]> wrote: > > > > > > > > > > > > > > > > > >> Toshiya > > > > > > > > >> > > > > > > > > >> Code modification a -1 is a veto. > > > > > > > > >> Regarding getting things done is about a deeper problem > than > > > > > setting > > > > > > > > more > > > > > > > > >> rules or procedures. This is rooted in the lack of project > > > path > > > > > and > > > > > > > > silos > > > > > > > > >> in some areas. That is the reason we all find resistance > in > > > > > certain > > > > > > > > areas. > > > > > > > > >> We require a more broad view of the project and start > building > > > > > some > > > > > > > > basic > > > > > > > > >> consensus. > > > > > > > > >> > > > > > > > > >> El vie, 24 ene 2025, 9:36, Toshiya Kobayashi < > > > > > > > > [email protected]> > > > > > > > > >> escribió: > > > > > > > > >> > > > > > > > > >> > Thank you for raising this post, Toni. > > > > > > > > >> > > > > > > > > > >> > I had a short talk with Toni, and add one more point > > > regarding > > > > > > > > >> > "Discussion". > > > > > > > > >> > > > > > > > > > >> > For a large work, we typically raise a discussion > thread and > > > > > take a > > > > > > > > >> vote. > > > > > > > > >> > > > > > > > > > >> > We may have been spending too much time on the > discussion > > > phase. > > > > > > > > >> Sometimes > > > > > > > > >> > we cannot settle conflicts of opinion. Sometimes we > don't > > > get > > > > > enough > > > > > > > > >> > feedback. But we can have a deadline for the vote, and > then > > > go > > > > > for > > > > > > > the > > > > > > > > >> > vote. It will accelerate the actual work eventually. > > > > > > > > >> > > > > > > > > > >> > We don't need to be afraid of "-1" which is not veto > (See > > > > > > > "procedural > > > > > > > > >> > issues" in > https://www.apache.org/foundation/voting.html) > > > and > > > > > we > > > > > > > can > > > > > > > > go > > > > > > > > >> > forward. > > > > > > > > >> > > > > > > > > > >> > Regards, > > > > > > > > >> > Toshiya > > > > > > > > >> > > > > > > > > > >> > On Fri, Jan 24, 2025 at 4:10 PM Toni Rikkola < > > > > > [email protected]> > > > > > > > > >> wrote: > > > > > > > > >> > > > > > > > > > >> > > Hello, > > > > > > > > >> > > > > > > > > > > >> > > I thought I should open a discussion about this. I > > > mentioned > > > > > in > > > > > > > last > > > > > > > > >> > week's > > > > > > > > >> > > meeting that we spend a lot of time planning and not > that > > > much > > > > > > > > >> executing. > > > > > > > > >> > > The highlight of this is we have a 1.5 hour weekly > meeting > > > > > where > > > > > > > > >> nothing > > > > > > > > >> > > can be decided since decisions are done on this > mailing > > > list. > > > > > > > > >> > > > > > > > > > > >> > > In a community like this. If you take away everything, > > > but the > > > > > > > bare > > > > > > > > >> > > minimum. There really only exist the things that have > a > > > PR and > > > > > > > what > > > > > > > > is > > > > > > > > >> > > merged in. > > > > > > > > >> > > > > > > > > > > >> > > Why is a plan not included in the bare minimum? A > plan is > > > a > > > > > wish. > > > > > > > > For > > > > > > > > >> a > > > > > > > > >> > > wish to become a reality it needs a contributor ( > single > > > or a > > > > > > > team ) > > > > > > > > >> and > > > > > > > > >> > > work hours to get done ( no getting hit by a bus, > people > > > > > changing > > > > > > > > >> jobs, > > > > > > > > >> > > company shifting interests or closing down a > contributing > > > > > team ). > > > > > > > > Only > > > > > > > > >> > when > > > > > > > > >> > > the plan has a PR, everything green and working, does > it > > > > > exist for > > > > > > > > the > > > > > > > > >> > > community. ( Merge is just a matter of a mouse click. > ) > > > > > > > > >> > > > > > > > > > > >> > > Few types resulting in a PR: > > > > > > > > >> > > > > > > > > > > >> > > 1. You can propose something. Ask for feedback. > Make a > > > good > > > > > > > plan. > > > > > > > > >> Get > > > > > > > > >> > > everyone to agree. Make a PR. > > > > > > > > >> > > 2. You can propose something... Make a PR and the > PR is > > > > > nothing > > > > > > > > >> that > > > > > > > > >> > was > > > > > > > > >> > > agreed upon. > > > > > > > > >> > > 3. You can propose something. Nobody wants it. > Make a > > > PR > > > > > > > > >> > > 4. You can just make a PR with no warning. > > > > > > > > >> > > > > > > > > > > >> > > What type is best? Depends. > > > > > > > > >> > > It is possible to have several plans competing. First > one > > > > > having a > > > > > > > > PR > > > > > > > > >> > > usually wins. > > > > > > > > >> > > > > > > > > > > >> > > I am bringing these bullet points up just to give a > heads > > > up. > > > > > > > > >> > > > > > > > > > > >> > > - For a good while everything was led top down at > Red > > > Hat. > > > > > In > > > > > > > an > > > > > > > > >> > > environment like that it is easy to make long term > > > plans. > > > > > In > > > > > > > the > > > > > > > > >> > current > > > > > > > > >> > > setup, anything that goes past 3 months is a > dream. Any > > > > > plan > > > > > > > is a > > > > > > > > >> wish > > > > > > > > >> > > until PR, any PR is a proposal until it is merged. > > > > > > > > >> > > - PR contains what the contributor decides it > > > contains. It > > > > > is > > > > > > > of > > > > > > > > >> > course > > > > > > > > >> > > beneficial to signal the change early, implement > what > > > is > > > > > agreed > > > > > > > > on, > > > > > > > > >> > > propose, vote and so on. However if something > needs to > > > get > > > > > > > done, > > > > > > > > >> there > > > > > > > > >> > > is > > > > > > > > >> > > only one person that is willing to do it. Then it > is > > > up to > > > > > the > > > > > > > > >> > > community to > > > > > > > > >> > > take what is offered or live without. > > > > > > > > >> > > - A contributor is the lead for the work and > planning > > > > > leading > > > > > > > to > > > > > > > > a > > > > > > > > >> PR. > > > > > > > > >> > > - Contributor can be a group of people > > > > > > > > >> > > - PR contains what the contributor decides it > > > contains. > > > > > > > > >> > > - Plan is formed by the contributor > > > > > > > > >> > > - Contributor can take in suggestions > > > > > > > > >> > > - Plan is executed by the contributor > > > > > > > > >> > > - PR is delivered by the contributor > > > > > > > > >> > > - The contributor can not alone decide if the > PR is > > > > > merged. > > > > > > > > >> This is > > > > > > > > >> > > up to the community and therefore we get > > > "separation of > > > > > > > > powers" > > > > > > > > >> > > - If you disagree on something. > > > > > > > > >> > > - You can offer opinions, these can be ignored. > > > > > > > > >> > > - You can offer help ( better way, still might > also > > > be > > > > > > > > ignored ) > > > > > > > > >> > > - You can make a completely alternative > > > implementation > > > > > > > > >> > > - You can also slow down the process of getting > > > things > > > > > done > > > > > > > by > > > > > > > > >> > > stalling it in many ways. Try not to be that > person > > > > > > > > >> > > - Too much planning will drive contributors away > > > > > > > > >> > > - Too much critique will drive contributors away ( > > > maybe > > > > > it can > > > > > > > > be > > > > > > > > >> > fixed > > > > > > > > >> > > later ) > > > > > > > > >> > > - The best plan loses to the solution that has been > > > > > implemented > > > > > > > > >> > > - Getting everyone to agree on something is > impossible > > > > > > > > >> > > - Getting everything perfect on the level where > even > > > one > > > > > of us > > > > > > > is > > > > > > > > >> > happy > > > > > > > > >> > > is impossible > > > > > > > > >> > > - Each one of us is QA, PM, HR, contributor, a > customer > > > > > and a > > > > > > > > >> > king/queen > > > > > > > > >> > > of their own work. > > > > > > > > >> > > - There is no higher level that can > > > > > > > > >> > > - Settle arguments > > > > > > > > >> > > - Decide when a plan is complete > > > > > > > > >> > > - Decide who does what > > > > > > > > >> > > - Order anyone to do anything > > > > > > > > >> > > - Order anyone not to do something > > > > > > > > >> > > - We need to be comfortable with conflicts > > > > > > > > >> > > - Do not trust work planned by a contributor will > be > > > > > delivered > > > > > > > > >> > > - Do not trust PR contains what was planned > > > > > > > > >> > > - A working community is based on trust. ( There > is a > > > > > balance > > > > > > > of > > > > > > > > >> trust > > > > > > > > >> > > and not having it.) Not every PR has to be agreed > by > > > > > everyone > > > > > > > > >> > > - Code wins > > > > > > > > >> > > - Getting things done wins > > > > > > > > >> > > > > > > > > > > >> > > Now these are not rules I am proposing. This is how it > > > works > > > > > with > > > > > > > > the > > > > > > > > >> > > current setup. It might feel like a wild west, > because it > > > is. > > > > > It > > > > > > > is > > > > > > > > >> > however > > > > > > > > >> > > how Open Source projects work when they are actually > open. > > > > > This is > > > > > > > > >> more > > > > > > > > >> > or > > > > > > > > >> > > less how the early days of KIE were ( different > branding > > > back > > > > > then > > > > > > > > ), > > > > > > > > >> > > before everyone in the community was working for the > same > > > > > company. > > > > > > > > >> > > > > > > > > > > >> > > I am bringing this up since I see a few items stuck on > > > > > planning > > > > > > > and > > > > > > > > we > > > > > > > > >> > > needed them ages ago. We have contributors that can > act, > > > but > > > > > > > getting > > > > > > > > >> the > > > > > > > > >> > > plan perfect is in the way. The contributors can just > say > > > > > this is > > > > > > > > >> enough, > > > > > > > > >> > > implement and this will drive the change forward. For > > > those > > > > > > > opposing > > > > > > > > >> > this. > > > > > > > > >> > > The options you have are listed above. > > > > > > > > >> > > > > > > > > > > >> > > Toni Rikkola > > > > > > > > >> > > Community member sponsored by Red Hat during days > > > > > > > > >> > > Community member sponsored by Kalsarikännit during > nights > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [email protected] > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
