Note: There will be a lot of activity needed to get this committee bootstrapped and shepherded through the process. I'm volunteering to serve as interim-chair until we can get a proper chairperson chosen.

Ex-officio, full voting membership:
Each SIG Chair

Some SIGs (e.g. Hyperscale) have two co-chairs: are both eligible here?

Non-binding Votes on CentOS Stream or RHEL and their Infrastructures: Any technical decisions or proposals that directly impact CentOS Stream, RHEL or their infrastructures are considered non-binding. The Committee serves in an advisory role signaling interest from the CentOS project
Majority voting for all other decisions: Technical decisions not directly related to CentOS Stream or RHEL follow a majority voting process, meaning a proposal with the support of a majority of those present-and-voting for a vote prevails. Each full voting member of the Committee, including the chairperson, has one vote.

Who/what decides whether a given vote is "on CentOS Stream or RHEL and their Infrastructures" or not? I think I understand the spirit behind the dichotomy here, but I'm concerned that in practice the vast majority of things such a committee would want to discuss and weigh in on would fall in this bucket. If the committee role is purely advisory, this risks being perceived as just another layer of indirection with little actual ability to effect change. I would recommend expanding this to spell out the reasoning behind the dichotomy (and ideally provide a framework to resolve it).

Ex-officio, full voting membership:
Each SIG Chair

Some SIGs (e.g. Hyperscale) have two co-chairs: are both eligible here?

Updated the description to allow a designee, but this is one-vote-per-SIG.

Non-binding Votes on CentOS Stream or RHEL and their Infrastructures: Any technical decisions or proposals that directly impact CentOS Stream, RHEL or their infrastructures are considered non-binding. The Committee serves in an advisory role signaling interest from the CentOS project
Majority voting for all other decisions: Technical decisions not directly related to CentOS Stream or RHEL follow a majority voting process, meaning a proposal with the support of a majority of those present-and-voting for a vote prevails. Each full voting member of the Committee, including the chairperson, has one vote.

Who/what decides whether a given vote is "on CentOS Stream or RHEL and their Infrastructures" or not? I think I understand the spirit behind the dichotomy here, but I'm concerned that in practice the vast majority of things such a committee would want to discuss and weigh in on would fall in this bucket. If the committee role is purely advisory, this risks being perceived as just another layer of indirection with little actual ability to effect change. I would recommend expanding this to spell out the reasoning behind the dichotomy (and ideally provide a framework to resolve it).

Added a note about the purpose of including the Stream Team Lead, and included the phrase "impact only CentOS Stream, RHEL, or their infrastructures" . The committee should absolutely spend much of its time taking advisory stances like this. The intent is to make it clear that decisions do not directly alter business priorities or resource allocation for Red Hat, but are a valuable piece of input to priority and resource allocation discussions from a body that is in direct contact with industry trends.

Binding votes do apply directly to priority and resource allocation discussions to be had within the CentOS project.

The CentOS Technical Steering Committee coordinates and agrees upon technical solutions that impact the CentOS ecosystem.

I believe "ecosystem" should be "project"

Added a note about the purpose of including the Stream Team Lead, and included the phrase "impact only CentOS Stream, RHEL, or their infrastructures" .

What is the risk of decisions that put one more SIGs or CentOS Stream at risk having to leave the project due to fundamentally unworkable, but majority approved, technical decisions? Maybe a different way to ask this question is can a decision be appealed?

Also, I think majority should be defined as majority of the membership casting a +1 or -1 vote (+0 doesn't count) and ensure it is not just a function of the actual attendees in a given meeting.

Who do we expect to implement whatever this group decides?

Do we expect SIGs representatives to optionally offer some work capacity? Like some SIGs just having opinions, and other SIGs taking on some of the implementation?

Would this also be an official venue for SIGs to discuss requests for the CentOS Stream team within Red Hat? Maybe a more focused alternative to opening Distribution BZs/Jira tickets?

Or are you prposing the CentOS Stream team lead to be representing the RHEL engineering as a whole in these discussions?

Would this example fit?

Let's say there's a SIG that needs messages generated by our compose testing. So they'd ask about it in this group. Maybe some other SIGs would have similar need, so they'd discuss it and figure out what they want so it works for everyone. They'd figure out who should do the work — let's say the Infra SIG which is already in the loop.

This is different than posting a request to the Infra SIG, because this would get considered accross the board first, and the Infra SIG would already be in the loop. When all figured out, a clearly formulated request to the Infra SIG would get submitted for tracking and prioritisation.

Added a note about the purpose of including the Stream Team Lead, and included the phrase "impact only CentOS Stream, RHEL, or their infrastructures" .

What is the risk of decisions that put one more SIGs or CentOS Stream at risk having to leave the project due to fundamentally unworkable, but majority approved, technical decisions? Maybe a different way to ask this question is can a decision be appealed?

Also, I think majority should be defined as majority of the membership casting a +1 or -1 vote (+0 doesn't count) and ensure it is not just a function of the actual attendees in a given meeting.

+1

I'd be also strongly in favour of async voting. This proposed group seems span quite a wide set of time zones.

1) As a person with Fedora background I would avoid using Steering Committee term here, because it sets expectation for the committee to be similar to FESCo, while it can not be.

FESCo essentially manages Fedora Linux distribution. The proposed group explicitly won't manage the CentOS Stream. I would rather come up with a name which highlights the difference.

2) It doesn't look like the proposed committee can just claim the responsibility described. Its power and and ability to be part of the decision making process essentially based on CPE and CentOS Stream Red Hat teams committing to hand over that role and that power to the Committee.

The committee then can work like a useful tool for those teams, if included in their planning and resource allocation processes.

Do we have a commitment from those teams to use it in this way?

3)

Ratifying a policy designating SIG Chairs (or their delegates) as the stewards of certain sensitive data and build processes (i.e. SIG Secureboot certificates and builds)

Generating a living document describing the project’s technical direction based on the needs of the community, the reality of project infrastructure constraints, and upcoming activities in CentOS Stream

For these two items I think we need to discuss the expectations here. I believe that while Committee can advise/vote/decide on policies and changes it hardly can do things. You can not assign action item to a committee, there should be someone who actually does the job and brings it to a vote.

So if the assumption here is that by creating a committee we will somehow get those policies written, I think we should reconsider. Because work needs to be done by a working group/SIG/a dedicated volunteer/whatever. It can not be assigned to SIG leads just because they are SIG leads.

Updated the voting language to be less prescriptive about presence, the intent behind this style of majority vote is that abstentions don't count toward no.

@bookwar wrote:

1) As a person with Fedora background I would avoid using Steering Committee term here, because it sets expectation for the committee to be similar to FESCo, while it can not be.

FESCo essentially manages Fedora Linux distribution. The proposed group explicitly won't manage the CentOS Stream. I would rather come up with a name which highlights the difference.

Suggestions welcome.

2) It doesn't look like the proposed committee can just claim the responsibility described. Its power and and ability to be part of the decision making process essentially based on CPE and CentOS Stream Red Hat teams committing to hand over that role and that power to the Committee.

The committee then can work like a useful tool for those teams, if included in their planning and resource allocation processes.

Do we have a commitment from those teams to use it in this way?

Right now there is no formal way for the project to evaluate, coordinate, and size requests of teams providing resources. In theory the project could find other sources of support as well, I expect this group to set technical direction for the project which should be a key indicator for teams that support the project.

3)

Ratifying a policy designating SIG Chairs (or their delegates) as the stewards of certain sensitive data and build processes (i.e. SIG Secureboot certificates and builds)

Generating a living document describing the project’s technical direction based on the needs of the community, the reality of project infrastructure constraints, and upcoming activities in CentOS Stream

For these two items I think we need to discuss the expectations here. I believe that while Committee can advise/vote/decide on policies and changes it hardly can do things. You can not assign action item to a committee, there should be someone who actually does the job and brings it to a vote.

So if the assumption here is that by creating a committee we will somehow get those policies written, I think we should reconsider. Because work needs to be done by a working group/SIG/a dedicated volunteer/whatever. It can not be assigned to SIG leads just because they are SIG leads.

I don't understand this framing, these 2 items are key things that need to be done and is the point of creating this committee in the first place. (1) is about documenting and realizing governance for Secureboot keys (we need to show Microsoft how we, as a project, plan to handle this) and (2) should follow naturally from being a policy body, we have to keep records somewhere.

Is https://git.centos.org/centos/board/issue/90 the sort of thing you'd want to see discussed in this SIG?

Is https://git.centos.org/centos/board/issue/90 the sort of thing you'd want to see discussed in this SIG?

Yes! this would be appropriate for discussion in this group.

We should consider this withdrawn pending further discussion.