On Tue, 28 Jan 2025 at 13:10, Mark Proctor <mdproc...@gmail.com> wrote:
> > > On Fri, 24 Jan 2025 at 13:48, Alex Porcelli <a...@porcelli.me> wrote: > >> 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. > > +1 This is my underlying philosophy. We must find ways to keep moving > forward. A decision is often better than months of no decision. It's not > always easy, but sometimes it's better to accept a hit so we keep > the momentum going. > I'll caveat that, of course, this must be nuanced and doesn't make an excuse for bad decisions or things that add technical debt that outweighs the merits of the change. > > > 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 <trikk...@redhat.com> 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 < >> > elguard...@gmail.com> 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 <trikk...@redhat.com> >> 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 <trikk...@redhat.com> >> > > 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 < >> > > > > elguard...@gmail.com> 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 < >> > > > toshiyakobaya...@gmail.com> >> > > > >> 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 < >> trikk...@redhat.com> >> > > > >> 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: dev-unsubscr...@kie.apache.org >> For additional commands, e-mail: dev-h...@kie.apache.org >> >>
