On 26 May 22:31, Brian Brazil wrote: > On Tue, 26 May 2020 at 22:08, Julius Volz <julius.v...@gmail.com> wrote: > > > On Tue, May 26, 2020 at 10:57 PM Julien Pivotto < > > roidelapl...@prometheus.io> wrote: > > > >> On 26 May 22:55, Julius Volz wrote: > >> > On Tue, May 26, 2020 at 10:17 PM Bartłomiej Płotka <bwplo...@gmail.com> > >> > 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? > > > > The doc Richi linked covers it in some depth. Rough concensus can cover > both a minority "winning" over a majority, and a majority being in favour > not being sufficient for rough concensus. It's all about if objections are > sufficiently considered. > The doc is more aspirational/philosophical rather than a formal policy, so > I think it doesn't work as a governance in those terms as it's kinda vague.
I have to say that it will be fun to address 'the PromQL evaluation model doesn't allow looking into the future.' kind of arguments. Unless it falls under the "unappealing" kind of concerns and can be dismissed by a real "rough" consensus call: Conversely, the working group might convince the objector that the concerns can be addressed, or that the choice is simply unappealing (i.e., something the objector can "live with") and not a show-stopper. > > Brian > > > > > > > >> > > >> > > >> > > 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 < > >> roidelapl...@prometheus.io> > >> > > wrote: > >> > > > >> > >> On 25 May 19:41, Richard Hartmann wrote: > >> > >> > On Mon, May 25, 2020 at 7:08 PM Julius Volz <julius.v...@gmail.com > >> > > >> > >> 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 prometheus-developers+unsubscr...@googlegroups.com. > >> > >> 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 prometheus-developers+unsubscr...@googlegroups.com. > >> > 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 prometheus-developers+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxEVQAerZx40j1vdz%2Bm5RO21qbxDKj7D3wvC38EDKYCdA%40mail.gmail.com > > <https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YoxEVQAerZx40j1vdz%2Bm5RO21qbxDKj7D3wvC38EDKYCdA%40mail.gmail.com?utm_medium=email&utm_source=footer> > > . > > > > > -- > Brian Brazil > www.robustperception.io > > -- > 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 prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLqyupF1B_jd2_RrGv%3DDncWMPEMP3q3MmJJ%3D4cdHH-%3DxaQ%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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200526214245.GA1327139%40oxygen.
