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