Re: bug#61894: [PATCH RFC] Team approval for patches

[Maxim Cournoyer]

Hi Ludovic,

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

> Hello Maxim and all!
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>>> With the proposed policy, members of a team would also have to review
>>> and approve each other’s work.  Formal approval means getting an
>>> explicit “LGTM” (or similar) from at least one other team member.
>>
>> In other words, to give teams the power to gate the changes touching
>> their scope.  That's reasonable, if we have functional teams.  I'd argue
>> we aren't there yet.
>
> I kinda agree; bootstrapping issue then?

Bootstrapping, yes, but also tooling, and people not yet catching up.
As I've pointed before, we've had the doc mentioning a command which
doesn't work to notify teams since at least October of last year [0] and
it seems few people even noticed (I think you only did recently :-)),
which tells me it's not a very well-trodden path yet!

[0]  https://issues.guix.gnu.org/58813

> I hope the maintainer team can help make teams “more functional”,
> whatever that teams.  It’s really what maintainership is about in Guix;
> it’s not about writing code.

I'm happy to help with the effort, but I don't think it's particularly
relevant to Guix co-maintainers more than anyone else interested in
advancing/contributing to Guix, and I find it great that it's this way
(not out of laziness, but because the talent pool of the whole Guix
community is much larger that that of us 4 co-maintainers).  Per what we
co-maintainers signed up for in [1], the co-maintainers three primary
duties are:

    Enforcing GNU and Guix policies, such as the project’s commitment to
    be released under a copyleft free software license (GPLv3+) and to
    follow the Free System Distribution Guideline (FSDG).

    Enforcing our code of conduct: maintainers are the contact point for
    anyone who wants to report abuse.

    Making decisions, about code or anything, when consensus cannot be
    reached. We’ve probably never encountered such a situation before,
    though!

[1]  https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/

>> And also:
>>> I think it avoids the unavoidable misunderstandings that can arise in
>>> a growing group and help pacify day-to-day collaboration.
>>
>> Again, "pacify" irks me a bit in this sentence, given I consider
>> collaboration has and continues to be cordial in our community, unless
>> I've been living under a rock.
>
> “Pacify” in the sense that, by being explicit, we avoid
> misunderstandings that could turn into unpleasant experiences.
>
> Like you I’m glad collaboration is nice and friendly; yet, over the past
> few months I’ve experienced misunderstandings that seemingly broke the
> consensus-based process that has always prevailed.

I'm sorry that you feel that way.  I don't think consensus was willfully
broken, and perhaps by studying some actual examples of these
occurrences we can better understand what went wrong and how the new
suggested policy would have helped or could be modified to help avoid
such problems in the future.  It's also worth noting that this
consensus-based process has always been implicit; for example, it is not
defined/mentioned anywhere in our documentation.  Perhaps it should?

> In a way, that’s probably bound to happen as the group grows, and I
> think that’s why we must be explicit about what the process is and about
> whether one is expressing consent or dissent.
>
> With so many things happening in Guix (yay!), it’s also easy to overlook
> a change and realize when it’s too late.  By having a rule that at least
> one other person on the team must approve (consent to) a change, we
> reduce that risk.
>
> Being on a team, then, is a way to express interest on a topic and to be
> “in the loop”.

That's already what teams can do!  I'd argue giving them the extra
powers that would be conferred to teams in this is not needed/desirable.
Some committer not a regular member of X team may still be confident
enough to push a patch sitting on the tracker, and I think they should
be able to.

> It is not about asserting power or building a hierarchy;
> it’s about formalizing existing relations and processes.

OK; I think in practice it would amount to that though (building a
hierarchy which has some form power).

> I hope this clarifies my position!

Yes, it does.  Thanks for taking the time to field some of the
questions!

-- 
Thanks,
Maxim