🚨 PROCESS CHANGE: Merging some working groups and committees to better reflect current contributor engagement #1549
Comments
|
This might be seen as a next logical step in simplifying the project governance after #1399 |
|
+1 in general to streamlining things. Some thoughts on the main proposals:
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.
Would this have any impact on Functions as a top-level / core Knative project?
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. |
|
+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 |
|
@knative/steering-committee Let's keep the upcoming TOC elections on hold. Merging SC+TOCI 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).
I am not sure about how the TOC and productivity WG are related. Can you please elaborate on this? |
|
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: ***@***.***>
|
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.
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.
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:
|
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.
The text was updated successfully, but these errors were encountered: