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. > 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.
