* Re: [RFD] COCONUT-SVSM project governance
2023-05-08 10:15 [RFD] COCONUT-SVSM project governance Jörg Rödel
@ 2023-05-08 16:28 ` Dionna Amalie Glaze
2023-05-24 10:39 ` Jörg Rödel
2023-05-11 19:26 ` Claudio Carvalho
1 sibling, 1 reply; 5+ messages in thread
From: Dionna Amalie Glaze @ 2023-05-08 16:28 UTC (permalink / raw)
To: Jörg Rödel; +Cc: amd-sev-snp, linux-coco
I'm in favor of governance models that strongly value transparency,
good-faith disagreement, and a set of community guidelines that both
has enforcement power and accountability of all parties involved.
On Mon, May 8, 2023 at 3:15 AM Jörg Rödel <jroedel@suse.de> wrote:
>
> Hi,
>
> As discussed before[1] I'd like to start a discussion about the future
> governance of COCONUT-SVSM. Bottom line is that the project should move
> from a single-maintainer, SUSE-driven project to a multi-maintainer
> model driven by the community.
>
> [1] https://lore.kernel.org/linux-coco/ZFJTDtMK0QqXK5+E@suse.de/
>
> Some of the things to discuss:
>
> * How many maintainers? (3 or more?)
>
3 is a minimum I think, with at least 2 entities represented.
Technical software repo governance I think should follow the OSSF
Scorecard [1], e.g., you need at least 2 people to approve a change
(author + human reviewer), enforced by a repository security setting.
> * How to select them (by contributions and trust in the
> community? elections? If elections, who can vote?)
>
I think that an RFC process as means of democracy around policy
changes, maintainer list changes, and substantial/breaking features á
la the Rust-lang project is a good one to emulate.
Particularly contentious RFCs should generally be treated with a great
deal of caution, so following a good-faith revision process shouldn't
be too onerous.
If an RFC drags on to the point of "calling the question" [2], I think
you'd have to hold a series of community town halls in APAC-, EMEA-,
and Americas-friendly timezones to send a contentious RFC to a vote. I
don't like online election systems without some kind of
group-membership restricting casting multiple votes.
To avoid situations of "why wasn't I consulted?" [4] you need both a
minimum length response period (e.g., 3-6 weeks), and mechanisms to
shorten that time in the event that there is no hesitation for
adopting the change given at all, and that you have a majority of
active contributors (has engaged with the project in the past 180
days) weighing in. I don't imagine the shortening condition getting
hit often except for extreme circumstances.
Certainly to make this work, you need to have to have existing
maintainers stick to the selection criteria for requiring a change go
through the RFC process when the contributor hadn't elected to do so.
> * Regular changes to the maintainer group?
>
I think again an RFC process to amend the maintainer group is
sensible, so long as following community guidelines are treated as a
sort of constitution to remove members in protest due to unneighborly
behavior.
> * How the group makes decisions on merging contributions and
> the general direction of the project.
>
This is where the notion of a working group comes into play, such as
language or core library evolution working groups of the C++ standards
committee.
It's up to maintainers to decide if it's time to split
responsibilities into different working groups in order to avoid
expensive meetings that attendees have little interest in
participating in.
> And certainly more questions which I have not yet thought of. So I'd
> like to invite everyone to share their thoughts and opinions in this
> thread so that we can develop a way to an open project governance :)
>
We don't want to repeat the unaccountability mistakes of the Rust
project that led to the moderation team quitting en masse.
I think eventually the project ought to be donated to the Linux
Foundation for impartial-ish ownership, but when it would be a wise
decision to do so is something I think lawyers will need to figure
out, since there are so many rules about corporation collaboration
outside the context of a third-party foundation.
I think the sigstore.dev project does a good job of running regular
community meetings and publishing meeting notes to allow for regular
collaboration across institutions.
I don't think we need to set that up until there's a good reason to
take a discussion off the mailing list for higher bandwidth
communication, since who needs more low value meetings?
[1] https://github.com/ossf/scorecard
[2] Robert's Rules of Order
[3] https://www.redhat.com/en/blog/understanding-open-source-governance-models
[4] https://www.youtube.com/watch?v=m0rakUuPXFM
> Regards,
>
> --
> Jörg Rödel
> jroedel@suse.de
>
> SUSE Software Solutions Germany GmbH
> Frankenstraße 146
> 90461 Nürnberg
> Germany
>
> (HRB 36809, AG Nürnberg)
> Geschäftsführer: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
>
--
-Dionna Glaze, PhD (she/her)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [RFD] COCONUT-SVSM project governance
2023-05-08 10:15 [RFD] COCONUT-SVSM project governance Jörg Rödel
2023-05-08 16:28 ` Dionna Amalie Glaze
@ 2023-05-11 19:26 ` Claudio Carvalho
2023-05-24 10:49 ` Jörg Rödel
1 sibling, 1 reply; 5+ messages in thread
From: Claudio Carvalho @ 2023-05-11 19:26 UTC (permalink / raw)
To: Jörg Rödel, amd-sev-snp; +Cc: linux-coco
On Mon, 2023-05-08 at 12:15 +0200, Jörg Rödel wrote:
> Hi,
>
Hi Everybody,
> As discussed before[1] I'd like to start a discussion about the future
> governance of COCONUT-SVSM. Bottom line is that the project should move
> from a single-maintainer, SUSE-driven project to a multi-maintainer
> model driven by the community.
>
> [1] https://lore.kernel.org/linux-coco/ZFJTDtMK0QqXK5+E@suse.de/
>
> Some of the things to discuss:
>
> * How many maintainers? (3 or more?)
>
> * How to select them (by contributions and trust in the
> community? elections? If elections, who can vote?)
>
At least 3 maintainers looks good, but I think we will have a better answer once
we know the number of maintainer candidates and their experience/interest.
An option could be to have maintainer(s) per area. I have worked on the
vtpm/attestation for the AMDESE/linux-svsm and I could help to maintain it (and
other parts) in the coconut-svsm.
> * Regular changes to the maintainer group?
>
> * How the group makes decisions on merging contributions and
> the general direction of the project.
>
> And certainly more questions which I have not yet thought of.
We may also want to discuss about release plan/model; e.g. the dynamics of new
releases, how often they will happen and if there is any priority that we need
to consider in the short term.
Thanks,
Claudio
> So I'd
> like to invite everyone to share their thoughts and opinions in this
> thread so that we can develop a way to an open project governance :)
>
> Regards,
>
^ permalink raw reply [flat|nested] 5+ messages in thread