[CLOSED] How should the TOC be formed?

[jawache]

There are a couple of models we can propose (ultimately this is decided by the steering committee but I would imagine they would take the recommendation of this community).

This is my proposal, please discuss, disagree, propose alternatives!

TOC Membership (Who's voice has input)

• See https://github.com/Green-Software-Foundation/toc/blob/main/toc-responsibilities.md#toc-members
• Comprised of every project lead (for graduated projects) and every working group chair.
• All TOC members are welcome to join meetings, engage in discussions, raise agenda items, make proposals, add their voices essentially to the topics that the TOC discusses.

TOC Leadership (Who get's to make decisions)

• TOC has a leadership team made up of all the elected positions in the Foundation, which currently is just the working group chairs.
• Input is welcome from all TOC members but when it comes to consensus/voting only the votes of the TOC leadership counts.
• Project leads are unelected, they hold their positions indefinitely, working group chairs are elected and therefore given a mandate by the GSF member to make decisions on their behalf.
• Basically I think only elected leaders should make decisions in this group, it has a lot of powers that impact everyone, the peiple who wield those powers should be elected.
• To that point, I also propose for any voting purposes in this group, we do make it an individual vote. Currently our voting is by "member organization" but for TOC leadership I believe it should be 1 vote per person. Each person was elected, it shouldn't matter if two people are from the same company. Our one vote one company rule is to stop people from buying votes, but you can't buy votes here.

TOC Chair/Vice Chair (Who leads the group)

• https://github.com/Green-Software-Foundation/toc/blob/main/toc-responsibilities.md#toc-chair
• Generally (even in WGs) I think we should either have 3 co-chairs or 1 chair and 1 vice-chair, to make decision making clear - two equal co-chairs means decisions can be split..
• Other similar groups in other Foundations either have 3 co-chairs or chair + vice chair to make sure this doesn't happen.
• Strictly our charter only actually allows chair and a vice-chair, when we implemented co-chairs we did it without changing the charter (I think this is one of the changes this group should formalize in our charter).
• For this group considering it's smaller size I think 1 chair and one vice makes sense.
• The chair/vice-chair also is responsible for sitting in the steering committee meetings and representing the TOC (they don't hold voting rights in any SC meeting)
• These positions should be voted on by the TOC leadership

UPDATE

There were no objections to the formation rules and they have been approved by the SC

[tmcclell]

When would this take effect? Are elections coming up for the new session?

[jawache]

WG Elections? We've not scheduled any yet. Ideally we'd want this group incorporated and the process a little settled before we go for another round of elections, would also like to clear up our charter on election rules and co-chair Vs Vice-chair rules. Little bit chicken and the egg!

[jawache]

I think the right process is I'm going to bring this to the steering committee next meeting (next week), we'll discuss the scope of the group and the formation rules. I'll create a proper PR for my proposal above and ask for peoples feedback, I think it'll be easier to argue wording etc.. through a PR.

Then the next time this group meets we need to start the election process for the chairs.

Possibly the meeting after that we'll be up and running.

So really we're looking at start of march before this group starts functioning smoothly.

[jawache]

See this PR for official addition of of the rules of formation: #3

[vaughanknight]

I think only elected leaders should make decisions in this group

100% agree. Members are electing who can represent them best, and I feel that makes sense. If it was project leads, you could end up with an active company creating many projects (which is awesome!) but then they would skew the voting with a single voice.

[Sealjay]

@jawache what projects will we be considering graduated in that lifecycle?

[jawache]

Good question, I think one of the first things this group should do is to decide this :)

I would suggest every project that has had an actual release meets graduated requirements and should be grandfathered in.
So:
CA SDK
Principles & Patterns

But thinking about it maybe we should open this up to all project leads, currently I don't think Carbon CI, SCI Data, SCI Ontology meets the criteria of "graduated" but I think the leads for those projects are an important voice in this group. What do you think @Sealjay? Open to all incubated and graduated?

[Sealjay]

I agree with you - SDK is a good candidate, as patterns and principles.
This seems broadly similar to other foundations, albeit I like the CNCF sandbox stage:
Green-Software-Foundation/opensource-wg#55