We had originally said proposals were to live on cwiki [0], however, that hasn’t happened, maybe because we didn’t enforce it, maybe because it wasn’t read, but that was the plan. We were taking the ideas from Kafka, Groovy, and others. I’m still open to linking to Confluence for proposals and workshopping them on the mailing list as needed.
[0] https://cwiki.apache.org/confluence/display/KIE -- Jason Porter Software Engineer He/Him/His IBM From: Toni Rikkola <trikk...@redhat.com> Date: Friday, January 24, 2025 at 09:35 To: dev@kie.apache.org <dev@kie.apache.org> Subject: [EXTERNAL] Re: [DISCUSSION] Getting things done 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 > > > > >
