Hi Ludovic,
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (30 lines)
> Hello!
>
> Maxim Cournoyer <maxim.cournoyer@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 think the distinction between occasional contributors and committers
should not matter too much in the context of establishing a consensus:
instead of a plain "no", people with more experience in the best place
to share to newcomers why they think things are better left the way they
are (explain the rationale for the status quo). A consensus should
hopefully emerge from that, or a refined way forward that everyone
agrees improve on the status quo. Similar to the aim of the recently
added review guidelines, this would favor active engagement or at least
dialogue rather than plain, veto-like refusal.
It's more work, sure, but that's the trade-off implied by using a
consensus-based decision process, I think.
And if, by some kind of luck (?), a large amount of newcomers were to
come and start discussing and agreeing to rewrite the guix-daemon in
VBA, appearing to form consensus, the idea/code could be gated by a
decision from the co-maintainers group. This is a last resort "veto"
right that should be seldom used, just like an individual contributor's
block.
Toggle quote (9 lines)
>> 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. :-)
I agree it's an important role of reviewers and committers to be able to
offer a critique of a suggested change, saying why they think it's not
an improvement. I don't see this new guideline as an obstacle to it,
although it will ensure the rational for turning an idea down, if
needed, has been well discussed and understood.
--
Thanks,
Maxim
