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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 >> > > >> > >> >
