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