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