[Proposal] Introducing Area Maintainers for ovn-kubernetes

[Surya Seetharaman]

Hi everyone,

I'd like to propose a new governance role for our project: Area Maintainers.

The problem

As ovn-kubernetes grows, our small group of maintainers is becoming a bottleneck for reviews and merges. Contributors with deep expertise in specific areas (e.g. KubeVirt, Egress IP) are already doing much of the review work, but they lack the authority to merge PRs in their area without waiting for a committer.

Also, since the repo is growing and we are adding more and more features, its impossible to expect folks to know 70-80% of the repo to become full fledged maintainers of the repo - this could take many years for any engineer. It's only fair that the repo maintainers come up with a good contributor ladder that ensures folks who are putting in efforts into specific aspects of our project receive the recognition and merge rights for those areas. This is a pattern already in use in majority of the big open source projects like Kubernetes.

NOTE: This has been discussed several times in our upstream meetings before. I have discussed this internally with current repo maintainers and only after procuring majority of votes in favor of this, am I raising this proposal to the community.

The proposal

Area Maintainers are trusted contributors who own a specific area of the codebase. They can:

• Review and approve PRs within their area
• Merge PRs that exclusively touch files in their area (via a /area-maintainer-approved command)
• Drive design proposals (OKEPs), documentation, and CI health for their area
• Represent their area in upstream meetings

Area Maintainers are not full Maintainers — they cannot merge PRs that touch files outside their designated area. Those still require a committer from ovn-kubernetes-committers.

How it works

Full details are in the PR: https://github.com/ovn-kubernetes/ovn-kubernetes/pull/6490

• File ownership is defined in CODEOWNERS. GitHub automatically assigns reviewers from the area's pool using round-robin.
• The Area Maintainer: header in each CODEOWNERS section designates who has merge authority (distinct from reviewers who only get review assignments).
• A GitHub Actions merge bot verifies scope (all files must be within the area), CI status (all checks must pass), and prevents self-merges before merging.
• Appointment and removal of Area Maintainers requires a simple majority vote from the Repo Maintainers, consistent with our existing governance model.

First area: KubeVirt

As a pilot, we're starting with the KubeVirt / Live Migration area:

• Area Maintainer: @maiqueb
• Reviewers: @qinqon, @ormergi
• Scope: KubeVirt production code, related e2e tests (kubevirt, multihoming, network segmentation, localnet), unit tests, and utilities

Next steps

• Review and discuss this proposal — feedback is welcome on the PR or this thread
• Once approved, this becomes the template for adding more areas (Egress IP, Services, UDN, etc.)
• Area Maintainer appointments will follow the governance process (proposed by a Maintainer, approved by majority vote)
• It would be nice if we as a community could also work on ensuring our code is modular and not sprawled all over the place like is with the default network controller and features added back in the old days. This makes it difficult to make this model a success. So, moving forward like with our newer features, let's make sure our code is added in a way that makes things modular for ownership

Final thoughts for closing - This doesn't mean folks need to get constrained to areas. If someone demonstrates the passion and puts in the work to span cross areas and eventually enough of those is enough to vote that person into being a repo maintainer. So this isn't closing doors for anyone to become a full repo maintainer, its actually opening doors to have an intermediate step for area maintainership as a way towards repo maintainer if folks are interested.

Looking forward to your thoughts.
Thanks, 

Surya

[Surya Seetharaman]

There was a suggestion on the PR to use SIG-* as the terminology instead of "Area" like Kubernetes and other projects like Kubevirt have which makes sense to me

So the concept stays the same, but we are going to go with "SIG-Virtualization" and in future it could be "SIG-DPU"/"SIG-Policies" etc for other SIGs.

Cheers,

Surya

[Nadia Pinaeva]

Hey all!
+1 on the proposal, thanks for the write up Surya!
On the SIG- rename I think it may be slightly confusing for 2 reasons:
- naming conflict with k8s SIGs: this can make it hard to understand
which group we are talking about and in which context, e.g. if we have
SIG-network-policy in ovn-k I will 100% confuse it with the u/s group
:)
- I think k8s SIGs are more than an area ownership that is being
proposed: u/s SIGs have their own chairs, meetings, enhancement
proposals, repositores and processes. In our case, I think the scpoe
is smaller (at least for now) and is mostly about code ownership with
a strong engagement from the other community members and maintainers.

Thanks,
Nadia Pinaeva

> --
> You received this message because you are subscribed to the Google Groups "ovn-kubernetes" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to ovn-kubernete...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/ovn-kubernetes/cc29fc3e-4fb1-435c-a903-14d80f191f3cn%40googlegroups.com.

[Surya Seetharaman]

Hello all!

On Wed, Jun 3, 2026 at 1:15 PM Nadia Pinaeva <n.m.p...@gmail.com> wrote:

Hey all!
+1 on the proposal, thanks for the write up Surya!
On the SIG- rename I think it may be slightly confusing for 2 reasons:
- naming conflict with k8s SIGs: this can make it hard to understand
which group we are talking about and in which context, e.g. if we have
SIG-network-policy in ovn-k I will 100% confuse it with the u/s group
:)

haha that's also a good point, I don't have a strong opinion on "area maintainer" v/s SIG-* 

@Or Mergi since it was your suggestion initially, not sure if you wanna chime in here 

[Or Mergi]

Hi, 

Thanks again for kicking off this work and bringing this topic to discussion.

This is indeed a good point.

How about adding a prefix to the SIG name to eliminate ambiguity? Would that work? ('ovn' / 'k8s-ovn', sig-k8s-ovn-network-policy)

Last thing I want is to slow this down, this is merely a suggestion based on practices I've seen work in the mentioned projects.

--

Or Mergi

[Surya Seetharaman]

To keep things simple for now, let's call the concept "Area" and "Area Maintainers". Changing this to SIGs if we succeed in this and adding more areas in future should be a relatively easy task!

Cheers,

Surya

[Patryk Diak]

Thanks Surya,

+1 on the proposal from me! 

[Tim Rozet]

+1

Just to be explicit here "Drive design proposals (OKEPs)" - I think it does not override the agreement where we still need participating members from each org to approve OKEPs. In other words, if only one org has a representative as an Area Maintainer in a certain Area, we still require OKEP approval from all orgs.