镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Steering committee needs more selection details #1

Description

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

Activity

  1. royaljust commented on Jul 27, 2021

    @royaljust
    Collaborator

    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.

  2. jberkus commented on Jul 27, 2021

    @jberkus
    Author

    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.

  3. royaljust commented on Aug 4, 2021

    @royaljust
    Collaborator

    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.

  4. royaljust commented on Aug 10, 2021

    @royaljust
    Collaborator

    Closing this issue and continuing the conversation in Issue #7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions