Jason, Thank you. Wiki does the same and seems to be the common practice for proposals.
Brian, Thank you for the feedback, it is much needed and clears many things. I do not think we have any one who is not a contributor in the community right now. Looks like the -1 is not as strong as was brought up. So I can not see how a deadlock could happen, voting will work. Toni On Fri, Jan 24, 2025 at 6:43 PM Brian Proffitt <b...@apache.org> wrote: > On Fri, Jan 24, 2025 at 1: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" . > > > > Comment-only contributors need to eventually contribute. There is no nice > way to put this. Personality-driven collaboration is harmful and not, > ultimately, collaborative. > > > > > > 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? > > > > -1s only vetoes _releases_ in ASF practices. Otherwise, it's just one > dissenting vote. What deadlock? And if you're about to tell me that you > have community members who will just sit back and wait until a release to > _then_ veto something with a -1, then I would submit that such community > members are not usually acting in the best interests of the project, but > rather their own personal aggrandizement. -1 votes are serious and should > be done with careful deliberation and factual backup. > > BKP > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > Brian Proffitt > VP, Marketing & Publicity > VP, Conferences >
