Re: rust-build-system from antioxidant

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 3937 bytes --]

On 2023-06-11, Maxim Cournoyer wrote:
> Maxime Devos <maximedevos@telenet.be> writes:
>> Op 02-06-2023 om 20:02 schreef Nicolas Graves:
>>> A few months ago, Maxime Devos worked on a new rust-build-system to
>>> handle a few issues we were experiencing with cargo (see discussions on
>>> antioxidant in guix-devel).
>>> A month ago, we discussed about the possibility of the integration
>>> in
>>> core guix, and the required steps. Maxime and I had a different
>>> approach. Maxime highlighted the possibility to make a smooth transition
>>> but once that would require many gradual changes and deprecation. My
>>> approach was that since we'll have to eventually migrate all packages to
>>> rust-build-system, and since we can freeze all former rust packages in
>>> an archive channel, I would be clearer to make the transition at once.
>>> [...]
>>
>> Actually, I started out with the non-gradual approach, but that was
>> overruled by Ludo', IIRC.
>
> Did you perhaps meant to say that it was disagreed with, or at worst
> "blocked by"?  There should not be a notion of 'overruling' in our
> contribution processes (unless the Guix co-maintainers have to step in
> as a last resort) if all participants strive to build consensus, as
> mentioned in info '(guix) Commit Access':
>
>    It is expected from all contributors, and even more so from committers,
>    to help build consensus and make decisions based on consensus.  To learn
>    what consensus decision making means and understand its finer details,
>    you are encouraged to read
>    <https://www.seedsforchange.org.uk/consensus>.
>
> I thought I knew what consensus meant myself, but the above link helped
> me to re-frame a few things in a way that is more conducive to building
> consensus.

A possible reframing that might be relevent here too that is maybe not
captured in the seedsforchange link referenced...

In a consensus decision (formal or informal), it is often really
valuable to not get caught up in "so-and-so is blocking X, Y, Z", but
rather more "this issue so-and-so raised is blocking X, Y, Z" or even
"this issue is blocking X, Y, Z". It is a perhaps subtle distinction,
but an important one, as I think it can refocus on a problem-solving
approach rather than finger-pointing-and-blaming approach.

That said, I definitely get the impression the Guix community practices
a very informal ad-hoc form of consensus, which ... while very flexible,
misses many of the strongest benefits of consensus (notably, clarity of
when a decision is actually reached and the next steps to move forward
with it).

A quick attempt at condensing a (more) formal consensus decision making
process boils down to:

* describe a situation, issue, proposal, etc.
* clarify understanding of the above (this step unfortunately
  may get skipped as people are very eagre to...)
* raise concerns
* address concerns (as a distinct step from raising concerns)
(iterate and repeat above steps as necessary)
* call for a decision (all concerns ideally resolved or mostly so.. ?)
* record decision (noting outstanding concerns if any)

I am not suggesting that a more formal process is even appropriate to
guix patch review...

Obviously, with the asyncronous nature of, say, a mailing list
discussion, these things do not necessarily happen in a structured
sequential way, though possibly being aware of the "ideal" formal
process, people can informally attempt to approximate it.

I do want to point out that informal processes are more prone to falling
into difficult patterns (e.g. defaulting to hierarchy or other power
dynamics), at least with the social aspects... I think this is a
collaborative project, so everything kind of has a social component!

We all fall down sometimes or lapse into old habits now and then, but
even if there is no formalized clarity of process, it is helpful to at
least reach towards the spirit of consensus building...


live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]