search

knative / community

Knative governance and community material.
https://knative.dev/community
Other
244 stars 234 forks source link

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

Open cardil opened 3 months ago

cardil commented 3 months ago

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:

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 commented 3 months ago

This might be seen as a next logical step in simplifying the project governance after https://github.com/knative/community/issues/1399

psschwei commented 3 months ago

+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 commented 3 months ago

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

dprotaso commented 3 months ago

+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 commented 3 months ago

@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 commented 2 months ago

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 https://github.com/knative/community/issues/1549#issuecomment-2035471598, 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 commented 2 months ago

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

cardil commented 2 months ago

I'm happy to see @dsimansk opened a dedicated issue for merging Client and Func WGs: https://github.com/knative/community/issues/1554, as this makes this proposal already partially successful! Thanks, David!

aliok commented 1 month ago

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

Benefits:

nainaz commented 1 month ago

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 commented 1 month ago

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 commented 1 month ago

+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:

aliok commented 1 month ago

Related: https://github.com/knative/community/pull/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 commented 4 weeks ago

@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 commented 4 weeks ago

I'll send a PR proposing the new governance structure

aliok commented 4 weeks ago

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

geekygirldawn commented 3 weeks ago

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 commented 3 weeks ago

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

Qs:

(what other comments have I missed?)

aliok commented 3 weeks ago

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

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 commented 3 weeks ago

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 commented 3 weeks ago

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.