Steering committee needs more selection details

[jberkus]

Howdy! I'm coming over from the CNCF where we're working on something similar, which you can see in our Project Template.

Currently the Charter document names a Steering Committee, but doesn't say anything about how that committee is selected. It would be useful to give some examples/options of how a committee could be selected.

Alternately, we decided that the actual MVG was the "maintainer council" model, where the people who have approver rights are identical to the people who have governance authority, which is the de facto way that most small independant projects run. Anyway, check out our repo for some ideas. Also happy to sync up directly at some point.

[royaljust]

Howdy! I'm coming over from the CNCF where we're working on something similar, which you can see in our Project Template.

Howdy @jberkus - glad to see other work in this area!

Currently the Charter document names a Steering Committee, but doesn't say anything about how that committee is selected. It would be useful to give some examples/options of how a committee could be selected.

The initial state would be negotiated by the folks interested in the collaboration. And then Section 2.2 of the Charter has additions or subtraction by 3/4 vote of the Steering Committee.

Alternately, we decided that the actual MVG was the "maintainer council" model, where the people who have approver rights are identical to the people who have governance authority, which is the de facto way that most small independant projects run.

Agree! For each project, the project governance document states that the maintainers govern -- appeals can be made to the steering committee of the organization.

It strikes me that we might have a naming problem. In MVG the intent is that the Steering Committee can oversee a number of (likely) overlapping projects. I think the analog in CNCF would be the Governing Board. MVG also tries to capture the de facto standard that most individual projects are governed by the maintainers. Keeping this structure in mind, any other thoughts on SC structure?

Feel free to reach out to me at my handle @github.com - would love to chat about this or any other feedback or thoughts more generally on project/organization governance.

[jberkus]

Ah, I don't think it's clear at all the division between individual project and meta-project. I certainly wasn't to me when I started poking around. Perhaps a guide?

In general what's missing from these governance docs is any information about how people are selected/promoted and removed, which is key to governance anywhere. I do really like your "How we work" sections though, if licensing is compatible I might copy those for some of our docs.

[royaljust]

Thanks @jberkus.

I don't think it's clear at all the division between individual project and meta-project. I certainly wasn't to me when I started poking around. Perhaps a guide?

Take a look at the excellent feedback and ideas around that guide in Issue #7. I'm partial to the tree feature from @spier, but would love any thoughts you might have on the two proposals or any other thoughts you have.

In general what's missing from these governance docs is any information about how people are selected/promoted and removed, which is key to governance anywhere.

They are selected and removed by the existing members of either the maintainers or the steering committee. Do you mean the docs are silent regarding criteria for selection or removal? If so, that is currently on purpose at both levels so that the docs remain flexible, but I'd be very interested in thoughts on whether there is one standard way to do it at either the steering committee or maintainer level. I do want to avoid a garden of forking paths leading to different forms. A bit more on why we've gone with that design choice thus far:

At the steering committee level there are many different reasons that people or organizations come together to collaborate and who is on the steering committee might differ depending on the context of the collaboration and relationships between the people and institutions involved. The default of adding or removing with 3/4 approval might lead to discussion between the initial group to make sure that each group of people or institutions are adequately represented so that the steering committee has no hostile takeover by some subset of interested parties (e.g. employees of the same corporation).

At the maintainer level, allowing the maintainers to set criteria in the contributing document and then approve new maintainers I think is pretty standard. Though I'm not aware of harmonized criteria for becoming a maintainer that's widely accepted. Being a lawyer and not an engineer I very much accept that I might have a huge blindspot here and perhaps there is a great contributing ladder that has wide adoption we could plug in -- would love to find such a thing.

[royaljust]

Closing this issue and continuing the conversation in Issue #7