kubevirt/community approver inactivity

[Daniel Hiller]

Hey all,

I've noticed that (while Andrew is out) there's nearly no activity when it comes to kubevirt/community PRs - current state is that there's 26 PRs open, of which a couple are LGTMed.

Maybe this is related to holiday period, but still it would be great if we could create higher throughput on PRs. There's two PRs [1][2] where we are trying to add more approvers - maybe the existing approvers (which I've added in cc) could take a look and see whether they have objections.

Or otherwise there might be reasons for existing approvers to be hesitant which others don't know about?

Further thought - when looking at the approvers list, might it make sense to consolidate with KubeVirt project maintainers? I see some of those missing there.

Thanks!

[1] https://github.com/kubevirt/community/pull/319

[2] https://github.com/kubevirt/community/pull/297

--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com   

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

[Edward Haas]

On Mon, Sep 2, 2024 at 2:50 PM Daniel Hiller <dhi...@redhat.com> wrote:

Hey all,

I've noticed that (while Andrew is out) there's nearly no activity when it comes to kubevirt/community PRs - current state is that there's 26 PRs open, of which a couple are LGTMed.

Maybe this is related to holiday period, but still it would be great if we could create higher throughput on PRs. There's two PRs [1][2] where we are trying to add more approvers - maybe the existing approvers (which I've added in cc) could take a look and see whether they have objections.

Or otherwise there might be reasons for existing approvers to be hesitant which others don't know about?

Further thought - when looking at the approvers list, might it make sense to consolidate with KubeVirt project maintainers? I see some of those missing there.

AFAIK the kubevirt/kubevirt project has identified that the past approach of having root approvers is not scaling well.

As such, SIG and now subproject specific approvers have been nominated while root approver nomination has been freezed (some even renounce it in favor of a specific SIG one).

The ref nomination example proposals are making root approvers take more responsibility and owning another aspect of the overall project.

While I think the individuals are a great fit, it is progressing in a different direction.

I think we need to decide on the roles and then assign approvers to the relevant portions.

E.g. approvers of design proposals could be nominated from a role of architects or per their specific expertise in the relevant subject.

What is required for the role and who should be nominated is a big subject by itself.

I am not really sure what is the correct solution, but I would prefer this is thoroughly discussed to assure we are not overloading responsibility

and accountability as we have experienced in kubevirt/kubevirt.

Thanks!

[1] https://github.com/kubevirt/community/pull/319

[2] https://github.com/kubevirt/community/pull/297

--

Kind regards,

Daniel Hiller

He / Him / His

Senior Software Engineer, KubeVirt CI, OpenShift Virtualization

Red Hat

dhi...@redhat.com   

Red Hat GmbH, Registered seat: Werner-von-Siemens-Ring 12, D-85630 Grasbrunn, Germany  
Commercial register: Amtsgericht München/Munich, HRB 153243,
Managing Directors: Ryan Barnhart, Charles Cachera, Michael O'Neill, Amy Ross 

--
You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAK%2BeyL4_wySO26%3DFw23uK_nvumaGOTn%3Dxf%3DzP2JDuZCnV6V%3DnQ%40mail.gmail.com.

[Itamar Holder]

I've expressed my opinion regarding this in multiple places already, so I'll summarize briefly here as well.

I support our structuring around SIGs and Fabian's proposal for introducing VEPs which will replace our current design proposals and would be owned by a certain SIG.

However, since we already decided to go for the SIG structuring, I don't think it makes sense to restructure k/community in parallel to that. I think we should direct our energy towards the future (SIG structuring), and shouldn't invest a lot of time restructuring k/community which might look very different after we move on with SIGs (for example, k/enhancement will probably be the new place for VEPs, the new design proposals).

My PR was intended to serve as an intermediary solution until we formalize and agree upon the new VEP's policy and procedure.

As I see it, we have the following options until we formalize the new SIGs/VEP process:

1. Stay with a small number of approvers for k/community.

2. (Arbitrarily?) choose a portion of kubevirt approvers to become k/community approvers, like suggested in https://github.com/kubevirt/community/pull/319.

3. Increase the pool of approvers with kK approvers, which de-facto are anyway the people that review k/community PRs.

I think that since k/k approvers are the ones who review these anyhow, we should let them technically approve proposals until the new process is formalized to save our energy and use it to push the SIG/VEP structuring forward.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CALmkdFQJV7edULY_kn3kB7Uo9Wn2Ns-02NpTh%3DDWOcyPv8g-OQ%40mail.gmail.com.

[Edward Haas]

On Tue, Sep 3, 2024 at 11:37 AM Itamar Holder <iho...@redhat.com> wrote:

I've expressed my opinion regarding this in multiple places already, so I'll summarize briefly here as well.

I support our structuring around SIGs and Fabian's proposal for introducing VEPs which will replace our current design proposals and would be owned by a certain SIG.

However, since we already decided to go for the SIG structuring, I don't think it makes sense to restructure k/community in parallel to that. I think we should direct our energy towards the future (SIG structuring), and shouldn't invest a lot of time restructuring k/community which might look very different after we move on with SIGs (for example, k/enhancement will probably be the new place for VEPs, the new design proposals).

My PR was intended to serve as an intermediary solution until we formalize and agree upon the new VEP's policy and procedure.

The PR suggests to increase the elevated responsibility and ownership root maintainers have on k/kubevirt repo to the community repo.

Considering the challenges we face in k/kubevirt in this regard, I would not recommend expanding that to this repo as well.

I also do not this can be considered a temporary solution. Once it is done, it is unclear if it can be reverted.

As I see it, we have the following options until we formalize the new SIGs/VEP process:

1. Stay with a small number of approvers for k/community.

2. (Arbitrarily?) choose a portion of kubevirt approvers to become k/community approvers, like suggested in https://github.com/kubevirt/community/pull/319.

3. Increase the pool of approvers with kK approvers, which de-facto are anyway the people that review k/community PRs.

IMO option  1 with a request for some of the approvers there to increase their focus and activity in the repo is a practical intermediate solution.

Promoting approvers from kubevirt/kubevirt to also cover the community repo requires role definition and clarity of the responsibility, something which takes time.

I think that since k/k approvers are the ones who review these anyhow, we should let them technically approve proposals until the new process is formalized to save our energy and use it to push the SIG/VEP structuring forward.

The repo is covering several subjects, the one which is probably of special focus here is the design proposals.

IMO approving a design in a large project like Kubevirt is not necessarily 1:1 related to being an approver of k/kubevirt (or any other important repo).

The existing list includes co-founders and early contributors to the project, there is currently no other criteria for adding new members there.

I suggest this is first discussed offline by the existing members in that list and when a consensus is reached, they will communicate it and open it for

discussion.

[Lee Yarwood]

On Tue, 3 Sept 2024 at 12:14, Edward Haas <edw...@redhat.com> wrote:

On Tue, Sep 3, 2024 at 11:37 AM Itamar Holder <iho...@redhat.com> wrote:

I've expressed my opinion regarding this in multiple places already, so I'll summarize briefly here as well.

I support our structuring around SIGs and Fabian's proposal for introducing VEPs which will replace our current design proposals and would be owned by a certain SIG.

However, since we already decided to go for the SIG structuring, I don't think it makes sense to restructure k/community in parallel to that. I think we should direct our energy towards the future (SIG structuring), and shouldn't invest a lot of time restructuring k/community which might look very different after we move on with SIGs (for example, k/enhancement will probably be the new place for VEPs, the new design proposals).

My PR was intended to serve as an intermediary solution until we formalize and agree upon the new VEP's policy and procedure.

The PR suggests to increase the elevated responsibility and ownership root maintainers have on k/kubevirt repo to the community repo.

Considering the challenges we face in k/kubevirt in this regard, I would not recommend expanding that to this repo as well.

I also do not this can be considered a temporary solution. Once it is done, it is unclear if it can be reverted.

As I see it, we have the following options until we formalize the new SIGs/VEP process:

1. Stay with a small number of approvers for k/community.

2. (Arbitrarily?) choose a portion of kubevirt approvers to become k/community approvers, like suggested in https://github.com/kubevirt/community/pull/319.

3. Increase the pool of approvers with kK approvers, which de-facto are anyway the people that review k/community PRs.

IMO option  1 with a request for some of the approvers there to increase their focus and activity in the repo is a practical intermediate solution.

Promoting approvers from kubevirt/kubevirt to also cover the community repo requires role definition and clarity of the responsibility, something which takes time.

In reality that isn't a practical suggestion when many approvers on that list are not currently active within the KubeVirt org or this repo. FWIW I'm not attributing blame to anyone here, the folks on that list are a huge part of the reason that KubeVirt is a success today.

I think that since k/k approvers are the ones who review these anyhow, we should let them technically approve proposals until the new process is formalized to save our energy and use it to push the SIG/VEP structuring forward.

I agree with Itamar here even if that's just mapping the k/k OWNERS file into the design-proposal sub-directory for now to get that part moving.

 

The repo is covering several subjects, the one which is probably of special focus here is the design proposals.

IMO approving a design in a large project like Kubevirt is not necessarily 1:1 related to being an approver of k/kubevirt (or any other important repo).

The existing list includes co-founders and early contributors to the project, there is currently no other criteria for adding new members there.

Ultimately I think SIGs can help solve that by giving ownership of a design to a singular SIG that then coordinates with any other related SIGs or WGs, AFAIK this is how larger KEPs are handled in k8s.

That said, that is part of some utopic VEP based future that we are nowhere near at the moment without actively engaged approvers in this repo.

 

I suggest this is first discussed offline by the existing members in that list and when a consensus is reached, they will communicate it and open it for

discussion.

Again I don't think that's practical with many no longer active within the community. We obviously have to get approval from some folks on that list but that shouldn't be reliant on some offline downstream discussion and if anything should be held upstream in the open during the community call.

Cheers,

Lee

 

[Dan Kenigsberg]

A healthy community requires active maintainers. If a current k/c maintainers are not joining a public discussion, and do not respond to offline communication, it is critical to add new owners who commit to be active. I don't think it should be en-mass. We can start by adding one or two wise and community-recognized people - if they commit to take this step forward.

Regards,

Dan.

[Fabian Deutsch]

+1

And this is also true for k/k  - maintainership requires active participation. If this is not possible or wanted, then every maintainer should consider to change their role, and drop the maintainer hat.

 

I don't think it should be en-mass. We can start by adding one or two wise and community-recognized people - if they commit to take this step forward.

Regards,

Dan.

--

You received this message because you are subscribed to the Google Groups "kubevirt-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubevirt-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CAHOEP54fW5dxQ9n6dOTqRsx_sOFrR4%3D434EUV932SsWVCsapPw%40mail.gmail.com.

[Andrew Burden]

Thanks for bringing this up, Daniel. Since this was raised we have had some additions to the reviewer/approver list, but there is still more to do :)

It has now been 6 months of inactivity from some of our reviewer/approver pool and we will remove them from the list, so it will get smaller again. If you're reading this, please consider self-nominating!

Note: As a reviewer or the community repo you are not expected to review design proposals (although you can), but rather PRs that impact the community repo about processes, governance etc, such as the PRs that Daniel mentioned that added SIG chairs and subprojects.

We talked about some ideas on how to improve our general pool of reviewers in last week's community meeting. Part of which is to remind people that anyone can review a PR, and it is the best step towards growing to becoming an acknowledged reviewer. It can perhaps be daunting to get started but there are no 'bad' reviews, and you can always ask for guidance in the kubevirt-dev slack channel. I'll be looking to set up a pool of reviewer mentors to help facilitate this - anyone with reviewing experience in the project, please make yourselves known if you would like to help out.

Really, everyone who is active in the project should be considering/working towards becoming, or is already, a reviewer. The great enemy to a timely review is time. Good reviews take considerable time, which can only be alleviated by a greater pool of reviewers to share the load. It is everyone's concern.

Re: design proposals

At present the expectation is that design proposals need lgtms from approvers in the repos that the design proposal will touch. Once they have those, they can be merged. Looking through the list of open design proposals, the blocker is not so much that we don't have approvers in the repo to merge them [1], or even that the proposals aren't being reviewed, but rather they're not being given the required tick of approval through the lgtm label to move them forward. This could be for a variety of reason, such as failure to achieve consensus on the proposal, but maybe it's not widely understood that this doesn't fall on the community repo reviewers?

To echo others, now that we have SIGs in place, those can take the place of 'repo' and we should instead require reviews/lgtm from the affected SIGs. This is harder/not possible to auto-assign SIG-specific reviewers and may require SIGs to periodically triage open design proposals and ensure they are not blocked, or for folks to consult something like the SIG list table and tag a SIG chair to assign someone who can move it forward. Formalising sig-reviewers would be a useful next step, in my opinion.

It would be nice to see #288 get over the line, especially as it evolves the lifecycle. We expect more design proposals, and we also expect more from them, than we did in the past, and I agree with the chorus that we've outgrown their location in the community repo.

Thanks for reading,

Andrew

[1] I recognise that this is different to what Daniel raised in his initial post, which was an issue of community repo approvers not reviewing and approving those PRs.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubevirt-dev/CA%2BPVUaTKO__XpEn6kWQEJr1yatN0P9G%3DT6k64%3DP5DhEk8sH_vA%40mail.gmail.com.