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

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

[Maxim Cournoyer]

* 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(-)

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

base-commit: 7937c8827b8d23347a3159b4696335bd19fc17aa
-- 
2.41.0

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

[Maxim Cournoyer]

Hello!

This is a heads-up regarding a modification to or contributing
guidelines I am considering to make:

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> * 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(-)
>
> 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

I'll leave it open for 2 weeks to let some time for people to voice any
opinions.  If you have something to say about it, now is a good time!

-- 
Thanks,
Maxim

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

[Simon Tournier]

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

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

[Ludovic Courtès]

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.

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

[Maxim Cournoyer]

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

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

[Ludovic Courtès]

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

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

[Maxim Cournoyer]

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.

-- 
Thanks,
Maxim

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

[Simon Tournier]

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

[bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.)

[Simon Tournier]

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

[bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.)

[Maxim Cournoyer]

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 

[bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.)

[Simon Tournier]

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

[bug#66430] Wording v2 (was Re: [bug#66430] [PATCH] doc: Mention the responsibilities that blocking comes with.)

[Maxim Cournoyer]

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 

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

[Maxim Cournoyer]

* doc/contributing.texi (Commit Access): Mention that blocking comes with
extra responsibilities.

Reviewed-by: Simon Tournier <zimon.toutoune@gmail.com>
---

Changes in v2:
 - Reword per suggestions

 doc/contributing.texi | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 864190b119..a18ee00845 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2030,7 +2030,17 @@ 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}.  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 explain the rationale
+for 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>.
 
 The following sections explain how to get commit access, how to be ready
 to push commits, and the policies and community expectations for commits

base-commit: 4ec6fd7817ec4073547fd71309374a293d7c436c
-- 
2.41.0

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

[Simon Tournier]

Hi Maxim,

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

> +                                                                       A
> +participant wishing to block a proposal bears a special responsibility

The term “participant” could appear unclear when reading the complete
section «Commit Access».  Instead, I propose:

    contributor, without or with commit access,

IMHO, it makes clearer what are the expectations on both sides:
reviewer and submitter.

Aside this comment, it is LGTM.  But it is better to wait more
comments. :-)

Cheers,
simon

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

[Maxim Cournoyer]

Hello,

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

> Hi Maxim,
>
> On Fri, 13 Oct 2023 at 10:38, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>
>> +                                                                       A
>> +participant wishing to block a proposal bears a special responsibility
>
> The term “participant” could appear unclear when reading the complete
> section «Commit Access».  Instead, I propose:
>
>     contributor, without or with commit access,
>
> IMHO, it makes clearer what are the expectations on both sides:
> reviewer and submitter.
>
> Aside this comment, it is LGTM.  But it is better to wait more
> comments. :-)

I've reworded it like so:

--8<---------------cut here---------------start------------->8---
modified   doc/contributing.texi
@@ -2036,11 +2036,12 @@ Commit Access
 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 explain the rationale
-for 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>.
+contributor (which may or may not have commit access), wishing to block
+a proposal bears a special responsibility for finding alternatives,
+proposing ideas/code or explain the rationale for 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>.
 
 The following sections explain how to get commit access, how to be ready
 to push commits, and the policies and community expectations for commits
--8<---------------cut here---------------end--------------->8---

I'll push a v3 shortly and let it sit there to let enough time for
others to chime in if they wish

-- 
Thanks,
Maxim

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

[Maxim Cournoyer]

* doc/contributing.texi (Commit Access): Mention that blocking comes with
extra responsibilities.

Reviewed-by: Simon Tournier <zimon.toutoune@gmail.com>
---

Changes in v3:
 - s/participant/contributor (which may or may not have commit access)/

Changes in v2:
 - Reword per suggestions

 doc/contributing.texi | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/doc/contributing.texi b/doc/contributing.texi
index 864190b119..f68ff5bb23 100644
--- a/doc/contributing.texi
+++ b/doc/contributing.texi
@@ -2030,7 +2030,18 @@ 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}.  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 (which may or may not have commit access) wishing to block a
+proposal bears a special responsibility for finding alternatives,
+proposing ideas/code or explain the rationale for 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>.
 
 The following sections explain how to get commit access, how to be ready
 to push commits, and the policies and community expectations for commits

base-commit: 4ec6fd7817ec4073547fd71309374a293d7c436c
-- 
2.41.0

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

[Simon Tournier]

Hi,

On sam., 14 oct. 2023 at 09:06, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> * doc/contributing.texi (Commit Access): Mention that blocking comes with
> extra responsibilities.

[...]

>  doc/contributing.texi | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)

[...]

> +@url{https://www.seedsforchange.org.uk/consensus}.  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 (which may or may not have commit access) wishing to block a
> +proposal bears a special responsibility for finding alternatives,
> +proposing ideas/code or explain the rationale for 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 will push this change soon if there is no more comment.

Cheers,
simon

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

[Maxim Cournoyer]

Hi Simon,

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

> Hi,
>
> On sam., 14 oct. 2023 at 09:06, Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
>> * doc/contributing.texi (Commit Access): Mention that blocking comes with
>> extra responsibilities.
>
> [...]
>
>>  doc/contributing.texi | 13 ++++++++++++-
>>  1 file changed, 12 insertions(+), 1 deletion(-)
>
> [...]
>
>> +@url{https://www.seedsforchange.org.uk/consensus}.  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 (which may or may not have commit access) wishing to block a
>> +proposal bears a special responsibility for finding alternatives,
>> +proposing ideas/code or explain the rationale for 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 will push this change soon if there is no more comment.

We haven't gotten much comments, but I think it's been out there long
enough that if someone had a problem with it, they would have spoken, so
no objections from myself.

-- 
Thanks,
Maxim

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

[André Batista]

Hello,

sáb 14 out 2023 às 09:06:53 (1697285213), maxim.cournoyer@gmail.com enviou:
> * doc/contributing.texi (Commit Access): Mention that blocking comes with
> extra responsibilities.
> 
> Reviewed-by: Simon Tournier <zimon.toutoune@gmail.com>
> ---
> 
> Changes in v3:
>  - s/participant/contributor (which may or may not have commit access)/
> 
> Changes in v2:
>  - Reword per suggestions
> 
>  doc/contributing.texi | 13 ++++++++++++-
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/contributing.texi b/doc/contributing.texi
> index 864190b119..f68ff5bb23 100644
> --- a/doc/contributing.texi
> +++ b/doc/contributing.texi
> @@ -2030,7 +2030,18 @@ 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}.  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 (which may or may not have commit access) wishing to block a
> +proposal bears a special responsibility for finding alternatives,
> +proposing ideas/code or explain the rationale for 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 believe this is commit b88bff628. I did not follow this thread, but
I've noticed now that it has two issues:

First it repeated the phrase: "To learn what consensus... read
<https://www.seedsforchange.org.uk/consensus>" before and as the last
sentence on the patch.

Second it uses '<...>' instead of '@url{...}' on the second occurence,
which was probably the one intended to be kept.

Cheers,

André

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

[Simon Tournier]

Hi,

On ven., 02 févr. 2024 at 18:55, André Batista <nandre@riseup.net> wrote:

> I believe this is commit b88bff628. I did not follow this thread, but
> I've noticed now that it has two issues:

Thanks.  Fixed with 9389070b9cdec8f250714df1fec82aae8bd7f67d.

Closing.

Cheers,
simon