diff mbox series

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

Message ID 5760a46dfc1b97312d1d5512ebf1bd21da6707f5.1696903067.git.maxim.cournoyer@gmail.com
State New
Headers show
Series [bug#66430] doc: Mention the responsibilities that blocking comes with. | expand

Commit Message

Maxim Cournoyer Oct. 10, 2023, 2:01 a.m. UTC
* doc/contributing.texi (Commit Access): Mention that blocking comes with
extra responsibilities.

Change-Id: I27cafcb351f68057b7882198e72e9bf66ccc1262
---
 doc/contributing.texi | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)


base-commit: 7937c8827b8d23347a3159b4696335bd19fc17aa

Comments

Simon Tournier Oct. 11, 2023, 9:30 a.m. UTC | #1
Hi Maxim,

On Mon, 09 Oct 2023 at 22:01, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> -@url{https://www.seedsforchange.org.uk/consensus}.
> +@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 would propose:

 + one sentence for summarizing what “consensus” means, roughly.
 + one sentence for clarifying the “block” situation.
 + the link for more details.

Well, concretely, something along this wording:

--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 participant wishing to block a proposal bears a special
responsibility for finding alternatives and proposing ideas/code 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---


Cheers,
simon
Ludovic Courtès Oct. 11, 2023, 9:10 p.m. UTC | #2
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?)

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

Thanks,
Ludo’.

PS: We really need a process for changes to our collective rules.
Maxim Cournoyer Oct. 12, 2023, 5:08 p.m. UTC | #3
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.
Simon Tournier Oct. 12, 2023, 7:17 p.m. UTC | #4
Hi,

On Wed, 11 Oct 2023 at 23:10, Ludovic Courtès <ludo@gnu.org> 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.
>
> 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?

Using the wording I am proposing [1], the case would be solved by
“significant concerns”, “can live with”, “actively” and “special
responsibility for finding alternatives”.

Well, this wording [1] tries to capture Maxim’s answer [2], I guess.

Somehow, it is an attempt to 1. summarize what consensus means,
and 2. clarify that blocking also implies actively being part of the
resolution.

Maybe, what is missing is explicitly mention the status quo case.  In my
mind it is covered by “finding alternatives” but maybe it would be
better to explicit mention it.  What do you think about this,

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

?

Cheers,
simon


1: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.
Simon Tournier <zimon.toutoune@gmail.com>
Wed, 11 Oct 2023 11:30:10 +0200
id:867cntld5p.fsf@gmail.com
https://issues.guix.gnu.org//66430
https://issues.guix.gnu.org/msgid/867cntld5p.fsf@gmail.com
https://yhetil.org/guix/867cntld5p.fsf@gmail.com

2: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.
Maxim Cournoyer <maxim.cournoyer@gmail.com>
Thu, 12 Oct 2023 13:08:53 -0400
id:87pm1j7opm.fsf@gmail.com
https://issues.guix.gnu.org//66430
https://issues.guix.gnu.org/msgid/87pm1j7opm.fsf@gmail.com
https://yhetil.org/guix/87pm1j7opm.fsf@gmail.com
Simon Tournier Oct. 12, 2023, 8:18 p.m. UTC | #5
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
Maxim Cournoyer Oct. 13, 2023, 4:02 a.m. UTC | #6
Hi Simon and Ludovic,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> 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:
>
> 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>.

I like it, but I admit I wasn't sure what "detailing the status quo"
meant until I read your examples below.  Perhaps it could be reworded to
"explain the rationale for the status quo" ?

Thanks,

Maxim
Maxim Cournoyer Oct. 13, 2023, 4:02 a.m. UTC | #7
Hi Simon and Ludovic,

Simon Tournier <zimon.toutoune@gmail.com> writes:

> 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:
>
> 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>.

I like it, but I admit I wasn't sure what "detailing the status quo"
meant until I read your examples below.  Perhaps it could be reworded to
"explain the rationale for the status quo" ?

Thanks,

Maxim
Simon Tournier Oct. 13, 2023, 6:51 a.m. UTC | #8
Hi,

On Fri, 13 Oct 2023 at 06:02, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:

> > 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>.
>
> I like it, but I admit I wasn't sure what "detailing the status quo"
> meant until I read your examples below.  Perhaps it could be reworded to
> "explain the rationale for the status quo" ?

Yes, that's better. :-)

Cheers,
simon
Ludovic Courtès Nov. 5, 2023, 5:19 p.m. UTC | #9
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 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’.
Maxim Cournoyer Nov. 7, 2023, 6:05 p.m. UTC | #10
Hi Ludovic,

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

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

>> 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.
diff mbox series

Patch

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 864190b119..082a288704 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2030,7 +2030,11 @@  Commit Access
 consensus and make decisions based on consensus.  To learn what
 consensus decision making means and understand its finer details, you
 are encouraged to read
-@url{https://www.seedsforchange.org.uk/consensus}.
+@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.
 
 The following sections explain how to get commit access, how to be ready
 to push commits, and the policies and community expectations for commits