guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the res


From: Simon Tournier
Subject: [bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.)
Date: Thu, 12 Oct 2023 22:18:24 +0200

Hi,

Re-reading the complete section (and other sections around), I am
proposing a tiny variation of the wording I sent earlier.

On Thu, 12 Oct 2023 at 21:17, Simon Tournier <zimon.toutoune@gmail.com> wrote:

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

Instead of Maxim’s wording above, I am proposing:

--8<---------------cut here---------------start------------->8---
It is expected from all contributors, and even more so from committers,
to help build consensus and make decisions based on consensus.  By using
consensus, we are committed to finding solutions that everyone can live
with.  It implies that no decision is made against significant concerns
and these concerns are actively resolved with proposals that work for
everyone.  A contributor, without or with commit access, wishing to
block a proposal bears a special responsibility for finding
alternatives, proposing ideas/code or detailing the status quo to
resolve the deadlock.  To learn what consensus decision making means and
understand its finer details, you are encouraged to read
<https://www.seedsforchange.org.uk/consensus>.
--8<---------------cut here---------------end--------------->8---

>>                         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?

Case 1: a volunteer writes a review describing issues with a proposed
change that have no obvious solution

Question: How would one interpret the reviewer’s responsibility?

Answer: Be engaging,

 + propose an alternative: idea or code
 + explain the status quo

Since there is no obvious solution, the reviewer’s responsibility –
propose an alternative or explain the status quo – helps in iterating.

Question: How would one interpret the participant’s responsibility?

Answer: Be engaging:

 + explain why they cannot live with the proposed change
 + propose an alternative: idea or code

At last resort, since there is no obvious solution, and if there is no
consensus – someone cannot live with and has significant concerns – then
it is up to maintainers to resolve by « Making decisions, about code or
anything, when consensus cannot be reached. We’ve probably never
encountered such a situation before, though! »


Case 2: a volunteer writes a review rejecting the change altogether (for
instance because it’s deemed outside the scope of the project or tool)

Question: How would one interpret the reviewer’s responsibility?

Answer: Be engaging:

  + explain the status quo

Please note that it is a group effort.  Therefore, if other people do
not participate in the discussion and there is no consensus, it means
this case falls under « Informal hierarchy ».  That’s another question
and orthogonal with reviewer’s responsibility, IMHO.

WDYT?

Cheers,
simon





reply via email to

[Prev in Thread] Current Thread [Next in Thread]