[Development] Proposal: Allow contributors to +1 sanity review.

Oswald Buddenhagen oswald.buddenhagen at digia.com
Thu Aug 15 11:05:17 CEST 2013


On Wed, Aug 14, 2013 at 11:41:29AM -0700, Alan Alpert wrote:
> On Wed, Aug 14, 2013 at 5:06 AM, Oswald Buddenhagen <oswald.buddenhagen at digia.com> wrote:
> > any kind of security/safety mechanism causes some friction, so by
> > definition your idea of improvement would mean abolishing any kind of
> > restrictions. the reality is that it is about trade-offs. having a
> > contributor wait a few hours because the reviewer did a stupid mistake
> > is a *perfectly* acceptable trade-off to uninformed contributors
> > mindlessly overriding the bot just because they can.
> 
> We seem to have different value judgement on what trade-offs are
> worthwhile. Because we already have the important rule of requiring an
> approver's approval,

> and we trust the approvers to consider the sanity bot (yes, you are
> trusting me to do that already ;) ).
> 
only because i have to due to bandwith reasons. you have repeatedly
demonstrated that you don't deserve that trust.

> The cost of uninformed contributors mindlessly overriding the bot
> because they can is the same as uninformed contributors giving +1s on
> arbitrary reviews just because they can - and this hasn't bothered me
> that much so far.
> 
no, it's not the same. a +1 sanity is a *pass*. an (even temporarily)
inattentive approver will not even notice that there is a problem when
some uninformed contributor overrides the bot.

> The alternative can cost more than a few hours.
>
the thing is that it doesn't cost anything. the whole development
process can be massively pipelined due to how git works.

> It can lead to a poorly documented aspect of the process sapping the
> enthusiasm of contributors due to delays and confusion*,
> 
seriously, somebody who needs instant gratification doesn't make a good
contributor anyway; i've had to deal with enough of them already.
some minor confusion and frustration is part of every learning process.
you can minimize it by being a good mentor, but optimizing our processes
for newcomers at the cost of the quality of the majority of the work is
not acceptable. a newcomer simply has to deal with it.

> I have since updated the relevant wiki page to answer his question,
>
which wiki is that?



More information about the Development mailing list