Hi Toni, In that case, I agree with Alex that, if the fix is absolutely needed, a -1 should be accompanied with an alternative proposal (I do not agree on the "equal merits" part, it is assuming that the original proposal has "more merits", which for me has not logical justification), so maybe it just a matter of voting which proposal is more liked by the whole community (in other words, the rule of democracy ;)), rather than ruling out the alternative "on principle" (as it has been done so far)
On Fri, Jan 24, 2025 at 7:20 PM Toni Rikkola <trikk...@redhat.com> wrote: > Well I did say I might start a fight in the mailing list to a > colleague this morning. Also this was my 4th draft of the email. This was a > hard topic to start, but made with absolutely everyone's best interest in > mind. > > The community will have several types of contributors. Some comment, others > implement, some do both. Others are hard to please, some too easy. So we > need to find a way that works for every personality. A process of doing > things where YOU ( since you reading this are the problem ) can say "ok, > check mate, go forward with it" . > > Now to work towards a solution. > Once a proposal has been made for something we absolutely need. This > proposal is prepared by the contributor. The contributor has included > everything they can implement based on given feedback. However it still > gets a -1. > How do we get out of the deadlock? > > Toni > > On Fri, Jan 24, 2025 at 5:32 PM Francisco Javier Tirado Sarti < > ftira...@redhat.com> wrote: > > > Hi Brian > > I agree with you > > However, please allow me one comment, you wrote > > "Reading this thread, and some others that were referenced here, I am > > getting the sense that a lot of concerns are being raised without counter > > proposals/solutions being made" > > This is simply not true and can be verified. > > In the example discussion that originates this thread, there was a > counter > > proposal made by Dominik. This counter proposal, since was not aligned > with > > the original onel (move another piece of software to tools repo) were > > simply ignored. > > Also, it can be verified (going through the archive list) that other > > proposals to add functionality (not to move existing things between > repos) > > for example, adding status to ProcessIntance in Data Index were plainly > > rejected without an alternative. > > > > > > On Fri, Jan 24, 2025 at 5:37 PM Brian Proffitt <br...@proffitt.org> > wrote: > > > > > Okay, let me interject some thoughts here from the mentor point of > view, > > > since things are getting overheated. > > > > > > Open source community building is about collaboration on the broadest > > point > > > of view, and consensus at the day-to-day execution/tactical level. > > > > > > "Consensus," even in Apache terms, is a tricky thing. A lot of people > > tend > > > to think that it is when everyone agrees on something, which can be > true, > > > and it is delightful when it happens. However, human nature, (and the > > > gradual rising of the temperature of this thread would seem to support > > > this), tends to manifest in non-agreement. I can say, for example, the > > sky > > > is blue, and someone will argue that no, today it is grey and cloudy, > or > > > not really, the blue wavelength is what's scattered the most across the > > > gases in the atmosphere due to the Rayleigh Effect. Are those arguments > > > wrong? No. Do they help support the point I might be trying to make? > > > Probably not. > > > > > > Consensus is great when everyone agrees, but that does not happen > often, > > so > > > stop trying to make everyone agree with you. To put it bluntly, an open > > > source software project is not here to be a discussion/chat room > > > indefinitely. Something needs to actually get built. > > > > > > Reading this thread, and some others that were referenced here, I am > > > getting the sense that a lot of concerns are being raised without > counter > > > proposals/solutions being made. "I don't like this, because..." is all > > well > > > and good, but what's the alternative solution offered? Is there one? > Can > > it > > > be expressed as a working PR/issue? At that point, self-reflection > needs > > to > > > be in order: is the issue I am raising something that I am willing to > > fix? > > > Because if it is not, then how important, really, is that issue, then? > It > > > is very very easy to criticize the direction of a project, or complain > > and > > > then not offer to be part of the solution. > > > > > > That said, here is a solution, which follows community and ASF best > > > practices: > > > > > > * Discuss issues, see if you can get consensus. *Listen to each other*, > > > present alternative solutions as much as possible, and acknowledge that > > > sometimes your idea might not be the best one. > > > * If consensus can't be reached, hold a +1/0/-1 vote. Unless it's a > > > release-related issue, the majority vote will decide if that issue will > > > move forward or not. > > > * If you find yourself in the minority, and find yourself frustrated > that > > > things are not going your way, work to move the project ahead _with_ > the > > > community, and keep figuring out alternative solutions to the things > that > > > you see are problematic. > > > > > > Peace, > > > BKP > > > > > > > > > Brian Proffitt > > > VP, Marketing & Publicity > > > VP, Conference > > > > > > On Fri, Jan 24, 2025 at 11:15 AM Tiago Bento <tiagobe...@apache.org> > > > wrote: > > > > > > > It is exhausting and discouraging to have you participate in all > > > > discussions with subjective criticism and condescendence accompanied > > > > by little to no action. Even this "debate" you think you're having > now > > > > is not helping the community move forward and get things done. > > > > > > > > On Fri, Jan 24, 2025 at 12:55 PM Gabriele Cardosi > > > > <gabriele.card...@gmail.com> wrote: > > > > > > > > > > Tiago, it also amazes me how unnecessary aggressive, and out of the > > > > point, > > > > > your own reply is. > > > > > > > > > > I simply stated something pretty obvious, i.e why some kind of > > > discussion > > > > > may arise: the very same thing could be viewed as something to be > > done > > > > now > > > > > for someone, and a technical debt for someone else. > > > > > Since there is no proposal discussed in this thread, there is not > > even > > > > the > > > > > chance that I'm referring to anything here as "technical debt". > > > > > > > > > > And, it is exactly about giving room to everyone to share their own > > > > ideas. > > > > > > > > > > > > > > > > > > > > Il giorno ven 24 gen 2025 alle ore 16:46 Tiago Bento < > > > > tiagobe...@apache.org> > > > > > ha scritto: > > > > > > > > > > > Francisco and Gabriele, it really does amaze me how anything > > contrary > > > > > > to your views is "likely unnecessary", "almost universally > > > questioned" > > > > > > and/or "tech debt". Come on, guys. Give some room for other > people > > to > > > > > > have their ideas and move things forward in their own way. You > > don't > > > > > > need to have an opinion about everything. > > > > > > > > > > > > On Fri, Jan 24, 2025 at 12:00 PM Gabriele Cardosi > > > > > > <gabriele.card...@gmail.com> wrote: > > > > > > > > > > > > > > Hi all, > > > > > > > I think Enrique clearly defined the problems and issues related > > to > > > > > > > different kind of votes: [1] > > > > > > > > > > > > > > 1. > > > > > > > > > > > > > > Procedural Issues > > > > > > > 2. > > > > > > > > > > > > > > Code modifications > > > > > > > 3. Package releases > > > > > > > > > > > > > > The very same document states > > > > > > > > > > > > > > The community should spell out in its guidelines the tacit > > > > implications > > > > > > of > > > > > > > > voting. However, *in no case* may someone's vote be > considered > > > > invalid > > > > > > if > > > > > > > > it does not appear to meet the implied commitment: a vote is > a > > > > formal > > > > > > > > expression of opinion, *not* of commitment. > > > > > > > > > > > > > > > > > > > > > > It is implied by their very nature that Proposal would raise a > > lot > > > of > > > > > > > discussions, IMO. Those discussions could also stray away from > > the > > > > > > original > > > > > > > message, because the original proposer overlooked some indirect > > > > > > consequence. > > > > > > > When that happens, there is the clash of two different > > approaches, > > > > the > > > > > > > "done is better than perfect", on one side, and the "let's > avoid > > > > > > increasing > > > > > > > tech debt just to have a PR merged in" (please, bear with me - > > just > > > > for > > > > > > the > > > > > > > sake of discussion). > > > > > > > It is more than anything a mindset confrontation, and a fair > > > > discussion > > > > > > > should lead to the "best possible" (of course, not perfect) > > > solution > > > > that > > > > > > > considers both POV. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] https://www.apache.org/foundation/voting.html > > > > > > > > > > > > > > Il giorno ven 24 gen 2025 alle ore 14:50 Alex Porcelli < > > > > a...@porcelli.me > > > > > > > > > > > > > > ha scritto: > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: dev-unsubscr...@kie.apache.org > > > > For additional commands, e-mail: dev-h...@kie.apache.org > > > > > > > > > > > > > >
