On Tue, May 26, 2020 at 11:22 PM Bartłomiej Płotka <[email protected]> wrote:
> > >> >> Overall, I feel that our team is not a children's playground, we are team >> of professionals. This means that we trust each other, so no one in >> Prometheus will decide something totally against someone else's strong >> opposite vote. >> > > > If we don't want to go totally against someone's strong opposing vote, > then I think we could just leave the governance as it is. I thought the > point was to make it possible to go against someone's strong opposing vote, > just as long as it's considered. And if they are still against something, > they can still call for a vote, but now that burden would be on the > minority blocker party. > > I think I was misunderstood. It's opposite:* It is exactly to make it > possible to go against someone's strong opposite vote.* But it does not > mean that if anyone disagrees we immediately ignore one person's opinion. > It's more *about stronger motivation to find consensus *between everyone > as there is an open, legal path for the project to move forward despite one > person being strongly opposed. > Yep, agreed. > Let's think about this in the opposite way: If we *trust* each other, why > having a rough consensus would be a problem? We will definitely try to > address our concerns and items asked by the opposed party, right? *It's > the same with open source*. Our license (Apache 2) allows almost > anything. Free distribution, modification, forking etc. This ensures that > there is always an open path if there will be a major blocker or conflict > etc. It does not mean that forks are often. > > Kind Regards, > Bartek > > > On Tue, 26 May 2020 at 22:08, Julius Volz <[email protected]> wrote: > >> On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < >> [email protected]> wrote: >> >>> On 26 May 22:55, Julius Volz wrote: >>> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka <[email protected] >>> > >>> > wrote: >>> > >>> > > Hi >>> > > >>> > > I support 100% of what Julius said: >>> > > >>> > > *> In general, +10 for a change in this direction, since currently, >>> the >>> > > balance is too much in favor of inaction - it's really easy to veto >>> > > something, but really hard to unblock it because team-wide votes are >>> > > high-overhead.* >>> > > *> I would also want to understand a bit more specifically how this >>> would >>> > > work in practice though. * >>> > > >>> > > +1 on moving to a rough consensus as I think it's stepping into a >>> good >>> > > direction. >>> > > >>> > > Overall, I feel that our team is not a children's playground, we are >>> team >>> > > of professionals. This means that we trust each other, so no one in >>> > > Prometheus will decide something totally against someone else's >>> strong >>> > > opposite vote. >>> > > >>> > >>> > If we don't want to go totally against someone's strong opposing vote, >>> then >>> > I think we could just leave the governance as it is. I thought the >>> point >>> > was to make it possible to go against someone's strong opposing vote, >>> just >>> > as long as it's considered. And if they are still against something, >>> they >>> > can still call for a vote, but now that burden would be on the minority >>> > blocker party. >>> >>> >>> Yes that is what I think too. Note that rough consensus means that >>> sometimes the minority wins too. >>> >> >> Even if there's already an outspoken (relative) majority against that >> minority? How would that be rough consensus then? >> >> >>> > >>> > >>> > > On a separate note, while I believe in maintaining high project >>> quality >>> > > for everything we ship, I think we should be way more open into the >>> > > experimenting bit more in Prometheus. Having some experimental >>> features >>> > > under a flag is something that gives quicker feedback if the API, >>> feature, >>> > > or given logic makes sense for a wider user base. For majority of >>> cases we >>> > > always reject those because "it's support burden", "this does not >>> help much >>> > > for Prometheus only Cortex/Thanos/XYZ", "this overlap with older, >>> less >>> > > efficient API", "we don't like those extra dependencies (e.g gRPC)", >>> > > "people will not use it". This might be off-topic here, but I feel >>> like >>> > > this is another thing which could improve the velocity of Prometheus >>> and >>> > > usability of the project itself (: >>> > > >>> > > Kind Regards, >>> > > Bartek >>> > > >>> > > On Mon, 25 May 2020 at 20:53, Julien Pivotto < >>> [email protected]> >>> > > wrote: >>> > > >>> > >> On 25 May 19:41, Richard Hartmann wrote: >>> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz < >>> [email protected]> >>> > >> wrote: >>> > >> > >>> > >> > > I would also want to understand a bit more specifically how this >>> > >> would work in practice though. E.g. when there are three people >>> arguing one >>> > >> way on an issue, and one person against, and all views have been >>> considered >>> > >> and arguments are turning in circles, can the majority (with >>> respect to >>> > >> that discussion) just go ahead and decide / merge things? I guess >>> in the >>> > >> worst case, when someone feels unheard, they can still call for a >>> team-wide >>> > >> vote, but the cost of calling for that vote would then be carried >>> by the >>> > >> minority, not the majority? So things would be more biased towards >>> action. >>> > >> > >>> > >> > That's one possible mode of operation, yes. >>> > >> > >>> > >> > Hopefully, there would be fewer lockups by shifting from >>> default-deny >>> > >> > to default-majority-ish. >>> > >> > >>> > >> > If it does not work out to our shared satisfaction, we can always >>> > >> > refine the governance further, e.g. introduce a Chair system >>> though, >>> > >> > again, I would like to avoid that. >>> > >> > >>> > >> > >>> > >> > Best, >>> > >> > Richard >>> > >> >>> > >> I would vote :+1: on changing to rough consensus. >>> > >> >>> > >> -- >>> > >> Julien Pivotto >>> > >> @roidelapluie >>> > >> >>> > >> -- >>> > >> You received this message because you are subscribed to the Google >>> Groups >>> > >> "Prometheus Developers" group. >>> > >> To unsubscribe from this group and stop receiving emails from it, >>> send an >>> > >> email to [email protected]. >>> > >> To view this discussion on the web visit >>> > >> >>> https://groups.google.com/d/msgid/prometheus-developers/20200525195320.GA983523%40oxygen >>> > >> . >>> > >> >>> > > >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> Groups "Prometheus Developers" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> > To view this discussion on the web visit >>> https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxDKMgf%2BEmyWG3%3D1KMW_Z99-Ky8kmFo12VgmejKRS%2Bk4w%40mail.gmail.com >>> . >>> >>> -- >>> Julien Pivotto >>> @roidelapluie >>> >> -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoyRpSrY1WFFreyt7hjTkGHf4OVBZ5894f7F7dPCRzGH4Q%40mail.gmail.com.
