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

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi,

Ludovic Courtès <ludo@gnu.org> writes:

> Hi!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> * doc/contributing.texi (Commit Access): Mention that blocking comes with
>> extra responsibilities.
>>
>> Change-Id: I27cafcb351f68057b7882198e72e9bf66ccc1262
>
> (Oh, what does this line mean?)

That's the commit-msg hook I've sent in bug#66027; in a nutshell it'd
add traceability between what's been reviewed in Debbugs to what's in
our Git (allowing to take actions on fully merged series, say, close the
issue in Debbugs).

>> +@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 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.

-- 
Thanks,
Maxim