[RFD] COCONUT-SVSM project governance

[RFD] COCONUT-SVSM project governance

[Jörg Rödel]

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?)

	* How to select them (by contributions and trust in the
	  community? elections? If elections, who can vote?)

	* 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. 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,

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

Re: [RFD] COCONUT-SVSM project governance

[Dionna Amalie Glaze]

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)

Re: [RFD] COCONUT-SVSM project governance

[Claudio Carvalho]

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,
> 

Re: [RFD] COCONUT-SVSM project governance

[Jörg Rödel]

Hi Dionna,

On Mon, May 08, 2023 at 09:28:40AM -0700, Dionna Amalie Glaze wrote:
> 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.

Thanks for your input, I completly agree with that baseline. One thing
to keep in mind is that any processes and rules we potentially put in
place are aligned with the size of the community. Really large
communities like for Rust or K8s certainly need different governance
than ours.

> 3 is a minimum I think, with at least 2 entities represented.

Right, we need to make sure different entities are represented.

> 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

Thanks, that is a lot of good input. I think in general we need to find
a balance between the needed bureaucracy to ensure fairness and
inclusiveness on one side, and being able to stay productive and make
decissions as needed on the other. That balance might shift with the
size of the community, of course.

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

Re: [RFD] COCONUT-SVSM project governance

[Jörg Rödel]

On Thu, May 11, 2023 at 03:26:30PM -0400, Claudio Carvalho wrote:
> 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.

Yeah, I also think that 3 is a good starting point. Having more probably
does not make sense before the community reaches a certain size or we
get to a sub-maintainer model.

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

That definitly makes sense. There will likely also be effort to make
certain parts of the code more generic, so that the different parts are
easier to maintain.


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

That are all interesting points. In my opinion it is too early to think
about doing a release. But we can discuss possible release models so
that we are ready when it actually happens.

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