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. I would see it as rather a message to the community that we no longer accept blocking decisions for so long as we used to. If anyone has strong objections on a certain topic, they *have *to suggest alternatives or actionable items that have to be addressed first. This is what I would see as a practical form of such consensus which also hopefully avoids "*concern tends to be ignored rather than addressed*" problem that Brian's mentioned. 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/CAMssQwZ3apTKpmUGuTJRs0ipDF7TQcypPOiXh_uX9%2B%3D2zVrFqg%40mail.gmail.com.
