Add kubevirt/kubevirt approvers to this repository's OWNERS

[iholder101]

What this PR does / why we need it:
This repository lacks approvers, and most of the existing approvers aren't very active anymore.

As Kubevirt becomes more popular and active, and more design proposals are being introduced, we need more people to share the burden of reviewing and approving such proposals. This is especially important since #251 had landed.

Release note:

NONE

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign vladikr for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[iholder101]

CCing all of the current approvers
/cc @aburdenthehand @AlonaKaplan @cwilkers @davidvossel @fabiand @rmohr @vladikr
/cc @fossedihelm @acardace

[acardace]

/lgtm

This really makes sense to move at a faster pace with design proposals.

[fabiand]

/hold

What is the justification of kubevirt/kubevirt approvers to gain approval rights in this repository?
Why not a different set of people? :)

Instead of increasing 1 core approver group with individuals, why can we not focus on the decentralized approach in order to increase our bandwidth: See #288

cc @lyarwood

tl;dr Before simply adding more approvers, let us please fix the process to make this process more scaleable.

[iholder101]

/hold

What is the justification of kubevirt/kubevirt approvers to gain approval rights in this repository? Why not a different set of people? :)

Instead of increasing 1 core approver group with individuals, why can we not focus on the decentralized approach in order to increase our bandwidth: See #288

cc @lyarwood

tl;dr Before simply adding more approvers, let us please fix the process to make this process more scaleable.

Hey @fabiand!
I definitely support #288. As the PR suggests, proposals (or VEPs) would be introduced to https://github.com/kubevirt/enhancements. I thought that in the meantime, until this effort takes effect, more Kubevirt approvers could contribute in reviewing "legacy" design proposals.

After we move to kubevirt/enhancements, I guess it would still makes sense that k/k approvers will have approval right in this repo, which I assume will mostly revolve around community guidelines.

[fabiand]

Let's focus on #288 and move it forward.

Merging this pr is just making us loose our focus.

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[iholder101]

/remove-lifecycle stale

@fabiand, see #319.

As said above, I do support #288 and try to promote it, but I don't think it should be a blocker for this PR.
Would you consider unholding this and to get this in until your PR is merged?

[dhiller]

+1 to what @iholder101 said.

As discussed in the community meeting, this repository lacks active approvers - this can be seen by the number of open pull requests without any activity from reviewer/approver side.

[kubevirt-bot]

PR needs rebase.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[iholder101]

Let's focus on #288 and move it forward.

Merging this pr is just making us loose our focus.

@fabiand IMHO we should either split #288 into two (as suggested here) to move it forward, or get this in, or think of a different solution.

While we're not being able to converge into a solution, the problem gets bigger over time.

I think there's a pretty large consensus to get this PR in. I identify at least @dhiller @acardace @aburdenthehand @fossedihelm @alicefr @RamLavi @orelmisan @orenc1 @lyarwood as supporters for this approach, and we've already raised it in the community meeting and there was no pushback.

WDYT?

[dankenigsberg]

I don't believe there is consensus for mass addition of approvers, please refer to the lively discussion on https://groups.google.com/g/kubevirt-dev/c/uqN9cPRZAF8

What we need is few strong and active reviewers, such as the newly-nominated @jean-edouard . We need a plan to ensure that the existing approvers are active, and we need commitment to review and participate.

/hold

[kubevirt-bot]

Pull requests that are marked with lgtm should receive a review
from an approver within 1 week.

After that period the bot marks them with the label needs-approver-review.

/label needs-approver-review

[kubevirt-bot]

@iholder101: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-community-make-generate	a39e9cb	link	true	/test pull-community-make-generate

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.