On 26 May 21:16, Bartłomiej Płotka wrote:
> Hi
> 
> 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 (:

I agree with that statement. I think that we could and should not have
taboos; we should be able to rethink some decisions and not be afraid to
accept more new features.

Maybe we should also be less concerned about pointing our users in the
"correct" direction and let them do more with their data.

> 
> 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/CAMssQwZ3apTKpmUGuTJRs0ipDF7TQcypPOiXh_uX9%2B%3D2zVrFqg%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/20200526202441.GB1213027%40oxygen.

Reply via email to