Re: Silence does not imply consensus.

[Siddhesh Poyarekar <siddhesh dot poyarekar at gmail dot com>]

On 7 March 2013 21:12, Carlos O'Donell <carlos@redhat.com> wrote:
> I've recently fallen into this trap myself, and I
> thank Roland for pulling me out of it. I can't just
> check things in because nobody complains. That's not
> consensus. It's easy to fall into this trap,
> particularly when you're busy and need to get that
> patch in before you reach your deadline.

I did not see anything inherently wrong with the discussion on the
default stack size patch, which is the example I think you're talking
about here.  I had posted the patch quite a long time ago (first draft
was 2 months ago), pinged and discussed it multiple times and after
those iterations, got an ack and checked it in.  Roland noticed it and
raised his objection, at which point the patch was reverted.  *All* of
that, including having to revert the patch was IMO a perfectly healthy
exchange.  I'd rather check in the patch after an approval and then
have someone point out a flaw/protest and revert it, than wait/ping
endlessly waiting to check it in.  In some cases, it actually halts
progress when it shouldn't.

> Consensus needs to be worked on, and involves reaching
> out to people in the community and getting them to
> comment on your change.
>
> Is it hard work? Yes.

It is not like once a patch is checked in, it cannot be reverted or
that reverting it is a big hindrance.  I'm all for discussions, but I
don't like the idea of waiting for someone to break silence on a
project that is silent by default.

> This community does not adhere to implicit approval.

I do agree that checking in without *any* approval or if someone
objects to the patch in its current form, is wrong.  At least one
other maintainer ought to approve it and if someone has a problem with
a change, it should be their responsibility to bring it up and stay
with it and not the patch author's responsibility to ping everyone in
sight to gather consensus.  There's plenty of time to object - right
up to the point that a release is frozen.

> Reach out and gather consensus, and then make
> the change, your code will be better, the quality
> of the project will be better, and you'll grow
> as a developer.

I guess the crux of what I'm trying to say is that while I agree that
gathering consensus is necessary, please let us not make it into a
needlessly bureaucratic process.

Siddhesh
-- 
http://siddhesh.in