brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrea Turli <>
Subject Re: Faster PR reviews
Date Mon, 08 May 2017 10:17:34 GMT
Richard, all,

thanks for the great discussion.

Thanks for moving this forward. I think those that have participated in
> this thread are generally in agreement over changing our PR reviewing
> standards, although I'm slightly concerned that relatively few people have
> contributed to the thread.

It's probably too late here but I think we can also assume those kind of
conversations (or maybe all?) assumes Lazy Consensus [1] where of course a
a negative vote constitutes a veto, which cannot be overridden.

> I'd like to move the PR reviewing question on to a vote, based on a short,
> clear statement about the new standards. I will start a vote shortly (with
> the aim that only requiring reviewing a short email and providing a yes/no
> response will get more responses).
> On the YOML question, fewer people have participated in that part of the
> thread. Several voices are of the opinion that a PR would not be acceptable
> in this form (even under the new reviewing standards), *were it submitted
> by anyone other than Alex*, but an exception is perhaps appropriate in this
> case. I have reservations about this in principle, but agree that it may be
> appropriate. However I want to ensure cases like this *remain* exceptional
> and not be normalised. I would therefore want that to be a subject of a
> vote too. To avoid confusion the votes should not overlap IMO. Any comments
> on this paragraph?

I don't have strong feelings against a vote vs 2 votes vs no vote, but I
think Lazy Consensus principle [1] can help here as well: it reduces the
number of required formal votes and also mitigates the concern around the
number of active participants to the discussion, IMHO.

As an interesting side point, I've also found one post on these topics
(there are probably millions of this nature!): it's from a linux kernel
maintainer and the suggestions seem very sensible to me [2]
I hope I'm not digressing too much!

My two cents,


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message