GNU bug report logs - #66430
[PATCH] doc: Mention the responsibilities that blocking comes with.

Previous Next

Full log

View this message in rfc822 format

From: Ludovic Courtès <ludo <at> gnu.org>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 66430 <at> debbugs.gnu.org
Subject: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.
Date: Sun, 05 Nov 2023 18:19:19 +0100

Hello!

Maxim Cournoyer <maxim.cournoyer <at> gmail.com> skribis:

[...]

>>> +@url{https://www.seedsforchange.org.uk/consensus}.  The project uses the
>>> +@samp{Requiring people who block to help find solutions} block variant,
>>> +which means a participant wishing to block a proposal bears a
>>> +special responsibility for finding alternatives and proposing ideas/code
>>> +to resolve the deadlock.
>>
>> I’m unsure about this.  A situation I have in mind is this: a volunteer
>> writes a review describing issues with a proposed change that have no
>> obvious solution, or rejecting the change altogether (for instance
>> because it’s deemed outside the scope of the project or tool).
>>
>> How would one interpret the reviewer’s responsibility in this case?
>
> It's a good question.  Hopefully there'd be more than 2 persons
> participating in the conversation, in which case there may be some
> consensus emerging that the proposed change should be rejected.  If
> there's no consensus at all and nobody is willing to iterate on the
> idea, then the issue should also be abandoned.

I think maintainers/committers have a responsibility that passersby do
not and cannot have: they must keep long-term maintenance in mind and
they define the project’s scope.  A newcomer or occasional contributor
may not share that vision from the get-go.

> I submitted this change hoping to encourage active participation toward
> consensus, and to "raise the bar" for using a block, which should seldom
> be used according to the consensus guide.  It'd be easy to otherwise
> abuse it, at the detriment of the group.

Yes, and I agree this is a worthy goal.  My only concern would be if it
gives an incentive for maintainers/committers to never say “no”.  Saying
“no” is an important part of this business.  :-)

Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.