🚨 PROCESS CHANGE: Merging some working groups and committees to better reflect current contributor engagement

[cardil]

Background

Currently (March 2024), the project consists of the following working groups: Serving, Client, User Experience, Eventing, Functions, Operations, Productivity, Security, and two committees, the Steering Committee, and the Technical Oversight Committee.

This governance schema is inherited from the days where the commitment of full-time maintainers and their parent companies was far larger (as for an example, see the Knative 2019 Annual Report).

Considering the current commitment of full-time maintainers and their parent companies, one might say this governance is too laborious. At least, some WGs have a hard time getting a quorum. This fact makes it hard to contribute, as decisions and reviews take longer than they could. Even if a WG can do its work, despite having only one or two members, it could easily make decisions that could later be opposed when released to the wider community.

Proposal

The general suggestion is to limit the number of project governing bodies to ensure a quorum, and their decisions can be treated as final. How to get there, is an open question.

Below, I'm listing a couple of ideas, which at least some of them do not exclude the others.

Split TOC into Steering and Productivity

By merging TOC and Steering committees, we can have more flexible project governance, which could focus primarily on project direction and the health of the other working groups.

The technical aspects of TOC should be moved to a WG, probably something very close to the current Productivity WG, making it both more effective and more attractive.

Join up Client and Functions as CLI

The client suffers from a lack of contributors, which, I think, is a direct result of having a plugin architecture. There are a couple of plugins, of which the Func is the largest and has the most involvement. I think it makes sense to merge the Client and Functions WGs, since they both end up focusing on the same thing - CLI for Knative - and they have plenty of common topics. This also gives other plugins a place to thrive and a place to discuss.

Fold low engagement groups (Security or Operations) into one body

Some groups, like Security or Operations, despite being both relevant and important for the project, get minimal involvement nowadays. Both of these groups, in addition to long-term development, have tasks that come up from time to time. Therefore, I believe that including them in a single technical body should not cause congestion. Instead, it will allow for a quorum, faster response in the project, and greater awareness of contributors.

For security embargoed tasks, a separate subgroup could operate as needed.

Expected benefits

Once all or some of the proposed changes are made, the project will become a more pleasant place to work because we will reduce response time (by a larger quorum on WGs), and the decisions of the working groups will be largely final. We will also make it easier for new contributors to get started, as project management will become clearer.

I can imagine the following structure:

• Project Steering Committee
• Technical and Productivity Leadership WG
• Serving WG
• Eventing WG
• Command Line Interface WG
• User Experience WG

NOTE: WGs reports to the Steering Commitee.

Expected Costs

The costs are not huge, but there are some. Mostly the changes needed in the community docs and website. We should also change the Google Drive folder structure, adjust the meetings in Google Calendar and Zoom, and change the Slack channels.

It is worth adding that we should make the changes in such a way as to preserve the historical structure for ease of finding the old stuff.

Timeframe for implementation/rollout.

If planned properly, a rollout could take no more than a few days.

Are you willing to drive the process, or is this a request for help?

Yes. However, the involvement of WG leaders would be highly desirable.

[cardil]

This might be seen as a next logical step in simplifying the project governance after #1399

[psschwei]

+1 in general to streamlining things. Some thoughts on the main proposals:

technical aspects of TOC should be moved to a WG

This would mean the TOC is no longer elected / rotated... I think that's an aspect that we should try to preserve. I'd probably be more inclined to just merge Steering and TOC into a single governance body.

Join up Client and Functions as CLI

Would this have any impact on Functions as a top-level / core Knative project?

Fold low engagement groups into one body

If a group doesn't have enough engagement to warrant being a working group, we could also just fold the working group (with major technical decisions owned by the TOC). It could always be reactivated if interest picked back up.

[geekygirldawn]

+1 to merging the TOC and Steering into a single elected governance body.

[dprotaso]

+1 to merging the TOC and Steering into a single elected governance body.

+1

I'm less inclined for TOC to take on the responsibility of working groups that have low engagement. If we can't find maintainers then my recommendation we deprecate and sunset said component/tool

[aliok]

@knative/steering-committee

Let's keep the upcoming TOC elections on hold.

Merging SC+TOC

I am supportive of this idea in general.

IMO, we have too many "manager"s for the current number of contributors in Knative.

I was investigating a SC+TOC merge idea in parallel and I got some feedback from some TOC and SC members that this is a good idea.

Merging SC and TOC would make the decision making process more efficient and would make the community more agile.

Currently we have 5 SC members and 5 TOC members. If we were to keep the same number of members, we would be still too many managers.

IMO, if we can have 7 members in total, that would be a good number (6 members + 1 end user chair).

The technical aspects of TOC should be moved to a WG, probably something very close to the current Productivity WG, making it both more effective and more attractive.

I am not sure about how the TOC and productivity WG are related. Can you please elaborate on this?

[nainaz]

I am in favour of one committee instead of 2. One concern that I have is that TOC needs a different skill set than Steering. I like the idea of moving more technical aspect of the current TOC to the working group and other duties might be preserved in one committee. I also want to explore 5 members ( 4 +1 end user) Thank you, -N

…

On Wed, 3 Apr 2024 at 15:59, Ali Ok ***@***.***> wrote: @knative/steering-committee <https://github.com/orgs/knative/teams/steering-committee> Let's keep the upcoming TOC elections on hold. Merging SC+TOC I am supportive of this idea in general. IMO, we have too many "manager"s for the current number of contributors in Knative. I was investigating a SC+TOC merge idea in parallel and I got some feedback from some TOC and SC members that this is a good idea. Merging SC and TOC would make the decision making process more efficient and would make the community more agile. Currently we have 5 SC members and 5 TOC members. If we were to keep the same number of members, we would be still too many managers. IMO, if we can have 7 members in total, that would be a good number (6 members + 1 end user chair). The technical aspects of TOC should be moved to a WG, probably something very close to the current Productivity WG, making it both more effective and more attractive. I am not sure about how the TOC and productivity WG are related. Can you please elaborate on this? — Reply to this email directly, view it on GitHub <#1549 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AISZCFAG247Q2PME3QCXKILY3RNRZAVCNFSM6AAAAABFONBNP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMZVGQ3TCNJZHA> . You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[cardil]

@psschwei: If a group doesn't have enough engagement to warrant being a working group, we could also just fold the working group (with major technical decisions owned by the TOC).

This is, exactly, what I'm proposing.

If a group is disbanded, but the topic is still relevant and the project can't go without it (like infra, testing, security etc.), somebody would need to make decisions in the end. That's why I proposed to have Technical Leadership WG.

@dprotaso: I'm less inclined for TOC to take on the responsibility of working groups that have low engagement. If we can't find maintainers then my recommendation we deprecate and sunset said component/tool

Sunsetting can only happen to extensions of the project (as in the recent RabbitMQ case). It can't happen to integral parts like infra, testing, security, etc.

For those, someone still needs to make decisions. I argue that it's better to have a single body making decisions (or at least fewer of them) than to have dedicated but almost empty WGs.

@aliok: I am not sure about how the TOC and productivity WG are related. Can you please elaborate on this?

The issues the Productivity WG is trying to manage are cross-project, technical, and could have a big impact on all subprojects. That's why very often the things we discuss in the Productivity WG, but in the small community, we feel we should propose somewhere "higher". That higher body is currently the TOC. Let me give you some examples of such things: Vendorless Knative, Rename knative-sandbox github org, Hackless Go-native tools for Knative, Run tests on GKE spot instances, etc. These are just some of the tasks. In fact, most of the bigger ones in the Productivity WG have a big enough impact on the project that they should be accepted by the wider technical community.

Let me also bring up and comment on the current TOC charter:

• Technical Project Oversight, Direction & Delivery

  • Set the overall technical direction and roadmap of the project.

    @cardil: This should be the Project Steering

  • Resolve technical issues, technical disagreements and escalations within the project.

    @cardil: This is a WG responsibility, as decisions should not be made "higher", but should ultimately be agreed upon by the community, or at worst, voted on. If agreement can't be reached, despite attempts and votes, this should be escalated to Project Steering.

  • Set the priorities of individual releases to ensure coherency and proper sequencing.

    @cardil: Coherency and proper sequencing is just a WG responsibility, priorities should go to Steering

  • Approve declaring a new long-term supported (LTS) Knative release.

    @cardil: A Project Steering, clearly. WG could advise.

  • Approve the creation and dissolution of working groups and approve leadership changes of working groups.

    @cardil: A clear Project Steering

  • Create proposals based on TOC discussions and bring them to the relevant working groups for discussion.

    @cardil: I doubt this should be a thing. Anyone can propose anything to other WGs, not just TOC, right?

  • Approve the creation/deletion of GitHub repositories, along with other high-level administrative issues around GitHub and our other tools.

    @cardil: A Steering decision. If additional manual work is needed, it should be delegated to a WG.

  • Advise the Steering Committe on conformance rules and tests that define brand use decisions.

    @cardil: Of couse a Steering responsibility.

• Happy Healthy Community

  • Establish and maintain the overall technical governance guidelines for the project.

    @cardil: A WG can do that.

  • Decide which sub-projects are part of the Knative project, including accepting new sub-projects and pruning existing sub-projects to maintain community focus

    @cardil: Clearly a Steering responsibility

  • Ensure the team adheres to our code of conduct and respects our values.

    @cardil: Also, a clear Steering responsibility

  • Foster an environment for a healthy and happy community of developers and contributors.

    @cardil: Again, a Steering responsibility

[cardil]

I'm happy to see @dsimansk opened a dedicated issue for merging Client and Func WGs: #1554, as this makes this proposal already partially successful! Thanks, David!

[aliok]

@knative/steering-committee @knative/technical-oversight-committee

I want to reach out to TAG Contributor Strategy again (Josh Berkus + Dawn Foster) for our changes in governance. However, what is the path now?

Can we continue this discussion please?

I propose this:

• We have a single elected body
• We have 7 seats in total (6 elected + 1 end user)
• We might reduce/increase the number later on

Benefits:

• 1 less meeting
• More competition for getting elected (less hard time finding nominees for an election)
• Easier decision making, thanks to 1 body

[nainaz]

I want to see the reduction to governing body.
We might need different skillsets, if we are merging,
Or we redistribute the charter between one governing body and rest to WG.
other than that , I am onboard.

[psschwei]

There was also some discussion in Slack around:

A third option that occurred to me just now would be to reduce the number 
of positions (e.g. to 4 or 3) intentionally if we don't have people who would 
want to continue. 

I haven't thought about it enough to have a strong preference, just posting it as another option that had been discussed.

[dsimansk]

+1 to @aliok's proposal. I'm in favor of merging TOC and SC to single governing body.

In addition, one optimization comes to mind. We can try to do more WG update presentations per governing meeting. Also, not every meeting have to host a WG update. That can help balance SC and TOC scopes.

E.g. running with agenda like:

• 15 min WG update + discussion
• 15 min WG update + discussion
• 30 min for the rest of topics

[aliok]

Related: #1572
We now need a member for the TOC, but I propose that we wait until we know what to do before filling that seat.

[evankanderson]

@knative/steering-committee @knative/technical-oversight-committee

I want to reach out to TAG Contributor Strategy again (Josh Berkus + Dawn Foster) for our changes in governance. However, what is the path now?

Can we continue this discussion please?

I propose this:

• We have a single elected body
• We have 7 seats in total (6 elected + 1 end user)
• We might reduce/increase the number later on

Benefits:

• 1 less meeting
• More competition for getting elected (less hard time finding nominees for an election)
• Easier decision making, thanks to 1 body

We discussed the concern about skill balancing (technical vs community contributors) in the combined committee. I suggest we change:

4 elected members (2 each year, serving 2 year terms)
2 selected members from the community (1 selected each year by the newly-constituted committee each year after the election to balance the composition, serving 2 year terms until their replacement is selected)
1 end-user seat, selected annually by the committee after the election, serving until their replacement is selected

[evankanderson]

I'll send a PR proposing the new governance structure

[aliok]

@jberkus @geekygirldawn

Can you review Evan's comment above please? We discussed this in today's SC meeting and we want to go with that proposal.

The motivation for having appointed members are:

• A completely elected SC might be composed of people who don't have the full skill set to steer the project
• Appointed seats will be the people who have the missing skills of the elected SC (can be technical skills, community building skills, etc.)

[geekygirldawn]

I'm ok with this proposal. When I was on the TODO Group board, we did something similar, and it seemed to work pretty well to help us fill skill gaps in the board. It also helped to ensure that we had a more diverse board.

[davidhadas]

Qs and a comment that were raised today in TOC - as input for SC.

Qs:

• How do the new governance ensure balancing between contributors associated with specific vendors - how do we ensure that multiple views are heard on technical decisions?
• Why is it preferred to have selected technical members in the new governance team over elected ones? What is the criteria upon which we expect such members to be chosen by the other 4 SC members? And how do we ensure balancing between technical agenda of different vendors?

Comment:

• If we identify the need for different skillsets to make quality decisions that are now done as part of SC work and TOC work, is it better to merge the two and keep weekly meetings with 7 diversified members (where it is less likely all will be in the details) over keeping tasks separated and reducing the number of members in each committee (e.g. electing 3, from different vendors) as well as the meeting schedule to align with the slower pace of contributions (once in 2 weeks? once a month?).

(what other comments have I missed?)

[aliok]

@davidhadas

How do the new governance ensure balancing between contributors associated with specific vendors - how do we ensure that multiple views are heard on technical decisions?

There can be a mechanism to prevent that. Let's check out what Evan will write and we can make suggestions in his PR.

Why is it preferred to have selected technical members in the new governance team over elected ones?

We wanted to have a single governance body in Knative, as discussed before. We can go as is, with a merged SC+TOC of 10 members. However, again as discussed before, we wanted to reduce the number of members a bit.
Then we had this concern of skill set balance and thought about appointing governing body members with skills that the governing body lacks.

There can be more arguments, but:

• It is hard to do elections for many seats with the current state of the community.
  • In the most recent elections, we had to reduce criteria to vote, to get more people eligible.
  • Similarly, it is hard to find candidates. There were only 2 candidates to fill 2 seats in the recent SC election.
• If we go with election only, the governing body might not have this skill balance.
  • Think about the scenario that we again have elections for 2 seats and there are only 2 candidates, whose skill sets are not helping with what the rest of the Knative governing body members lack.

What is the criteria upon which we expect such members to be chosen by the other 4 SC members?

We haven't defined the details, but the key part is that the governing body will select people who would help with the lack of skill set. E.g., if the elected people lack the technical skills, they will select people with technical skills. Or if they lack community skills, they will select people with community skills.

And how do we ensure balancing between technical agenda of different vendors?

Same as the first question above.

If we identify the need for different skillsets to make quality decisions that are now done as part of SC work and TOC work, is it better to merge the two and keep weekly meetings with 7 diversified members (where it is less likely all will be in the details) over keeping tasks separated and reducing the number of members in each committee (e.g. electing 3, from different vendors) as well as the meeting schedule to align with the slower pace of contributions (once in 2 weeks? once a month?).

Sorry I couldn't understand the suggestion here. Can you elaborate please?

[psschwei]

I'm in favor of reducing the number of folks in governance. But what I'm still not clear on is the benefit of combing Steering and TOC rather than just reducing the membership of each (down to say 4 and 3 respectively). Especially if we're anticipating that there will still be "steering" tasks and "toc" tasks, each of which require a different skillset.

[davidhadas]

Regarding the desire to merge SoC and ToC:

Sorry I couldn't understand the suggestion here. Can you elaborate please?

@aliok
The point I was making is very similar to the comment from @psschwei.
Reducing the overall number of technical members to 3-4 (while ensuring diversity among vendors) and reducing the cadence of meetings to bi-weekly and if needed even monthly makes sense as the project technical activity drops. Similar reduction may or may not be needed in SoC.

At the same time, joining the SoC and ToC to one governance body seems to only introduce new issues and does not seem to solve any.
It may make sense for the ToC and SoC to have joint meetings at times, (however it seems that this is rare).
It may make sense to have some members elected to both ToC and SoC (we should not prevent this)

Overall it seems that creating a single governance body in Knative is counter productive - during the ToC meeting we were trying to figure out why is this something that SoC wish to do (beyond the need to reduce the number of governance members and overall project governance overhead - which everyone seem to agree is needed at this point). What is the upside of merging?

---

Regarding selecting members instead of electing members of governance:

...we had this concern of skill set balance and thought about appointing governing body members with skills that the governing body lacks.

A solution is to perform both technical and non-technical elections (i.e. designate governance sits to technical members) - this does not mandate selecting members of Governance instead of electing them.

There can be more arguments, but:

• It is hard to do elections for many seats with the current state of the community.
  In the most recent elections, we had to reduce criteria to vote, to get more people eligible.
  Similarly, it is hard to find candidates. There were only 2 candidates to fill 2 seats in the recent SC election.

Understood - a solution can be reducing the number of governance members, reducing cadence of meetings to reduce the overhead on members and allowing the same members to be elected to both SoC and ToC if they wish to extend their influence and contribute to both.

If we go with election only, the governing body might not have this skill balance.

The right way to address this problem is to have sits in governance pre-designated for people with different skill-sets and have them elected accordingly.

Think about the scenario that we again have elections for 2 seats and there are only 2 candidates, whose skill sets are not helping with what the rest of the Knative governing body members lack.

If we cant find members that wish to be elected for governance, the same members will (probably) also not want to be selected for governance.

If we can find 3 technical members (given vendor diversity rules) that wish to be members of the technical governance and are suitable based on our rules - great. If we cant, we will need to change the rules to adapt. This apparently is not related to the question of should those members be elected or selected.

We can have a general rule that if a governance sit is not taken following an election, the existing governance members can ask a community member of their choice to fill in the spot until the next election time - this means interim selection but still opt for election whenever feasible.