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

## Background

Currently (March 2024), the project consists of the following working groups: [Serving](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/working-groups/WORKING-GROUPS.md#serving), [Client](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/working-groups/client/CHARTER.md), [User Experience](https://docs.google.com/document/d/1b_CliwhqjwcHHLh_UU-DwsRMDxE50cGc6vuJh0OW57E/edit?usp=sharing), [Eventing](https://github.com/knative/eventing/blob/main/docs/mission.md), [Functions](https://github.com/lance/community/blob/add-func-wg/working-groups/functions/CHARTER.md), [Operations](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/working-groups/operations/CHARTER.md), [Productivity](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/working-groups/productivity/CHARTER.md), [Security](https://docs.google.com/document/d/194bECSbxPIONzhgGj1g9tccUsP8I-M7WIvbBqcT-tXY/edit), and two committees, the [Steering Committee](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/STEERING-COMMITTEE.md), and the [Technical Oversight Committee](https://github.com/knative/community/blob/1177cc1b0ea1c6142b53db88bc6a3a0f9f043ee3/TECH-OVERSIGHT-COMMITTEE.md).

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](https://drive.google.com/drive/u/0/folders/0AM-QGZJ-HUA8Uk9PVA)).

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.

Start by reading the proposal alongside the linked WORKING-GROUPS.md, committee documents, and working-group charters. Confirm the governance structure with the relevant WG leaders before changing community docs, website material, Google Drive folders, meetings, or Slack channels. Done means an agreed structure is documented while preserving historical information.

Written by the indexing model from the issue text.