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 >
