I feel like the proposal process has risen up as a definable topic in this discussion.
We have two hard topics for proposals coming: examples and documentation. Based on all I know right now, there will be no way we get a proposal passed where everyone agrees. I believe Alex is about to create a proposal for examples. There might be a countering proposal and voting. Since the actual proposal content changes based on the conversation. To keep everyone up to date with the correct up to date data, I would recommend having the proposal in a GitHub issue for example and then link it here on the starting email for the proposal on this ML. This way it can be updated. Then before a vote, copy & paste into a voting email thread. In that proposal Alex uses the structure he mentioned and from there we form a template for the community. With this setup we should be able to improve the proposal process as we go forward. Toni On Fri, Jan 24, 2025 at 4:49 PM Francisco Javier Tirado Sarti < ftira...@redhat.com> wrote: > In my humble opinion, The "done as better than perfect" should not be used > as an excuse to "do something that is very likely unneeded In a way that is > almost universally questioned" > Therefore, I would like to emphasize that the problem statement should be > exposed in the most possible objective way, not precluding any solution, > clearly stating the consequences of not doing it for the community, > specially users, and a fair estimation of the effort. > For example, in the recent discussion regarding "movement of examples to > tools repository", the problem statement does not fulfil any of those > criteria. If a problem statement does not fulfil those criteria, I hardly > see why rejection of it should be accompanied with an alternative proposal > (it looks like an inversion of roles, like in a court the accused has to > proof his innocence, when usually is the accuser the one that has to proof > the accused is culprit). > Appart from that, when disagreements arise, I think the fixing proposal > (for those cases where problem statement is acurrante and therefore we > really have to do something) should be chosen by voting between the > colliding proposals (not just vote the propopals separately). Im saying > that because, for the mentioned discussion, once the problem statement was > clarified and an apparently valid alternative proposal was proposed > (branch the examples repo and make main the default), the topic was > suddenly closed. > > On Fri, Jan 24, 2025 at 2:48 PM 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. 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 > > > > >
