Ideas to reduce the PR backlog

[jodh-intel]

Background

Review rota

The Kata community has a very small team of volunteer reviewers who give up some of their time to review the PR and issue backlogs.

Why are reviewers important?

The reviewers are the gatekeepers of the Kata project. They help to ensure the correctness, consistency, legibility, maintainability and general overall quality of the contents of the Kata repositories.

Do we really need reviewers?

Yes, they are absolutely 100% completely entirely totally categorically omg essential! Kata would not be what it is today without them. See above!

What do you need to be a reviewer?

Anyone can be a reviewer, whether you are on the rota or not. See and then feel free to start comments on PRs!:

• https://github.com/kata-containers/kata-containers/pulls
• https://github.com/kata-containers/tests/pulls

Problem

We have too many open PRs.

• Lots of PRs is a "good thing" as it's a sign of a healthy community.
• However, every PR opened results in more work for the very small team of volunteer reviewers.

Hence, more specifically the problem can be defined as:

• PRs are taking too long to land.
• We don't have enough volunteers on the review rota.
• We need more "knowledge transfer" from those with specialist knowledge to help others be able to review PRs in more detail.

Remember

Every open PR is:

• An improvement or new feature you cannot use yet.
• A bugfix you cannot benefit from yet.

In other words PRs are only directly useful to the community of users once they have been merged. But they cannot be merged until they have been reviewed and approved.

Solutions

Can you help?

If you have spare time, please help us by reviewing any open PRs. It's great that we have so many PRs being raised, but every PR raised means more work for the review team.

Reminders:

• You do not need to be an expert to help review any PR - all comments are potentially useful so please feel free to ask away!
• We need to keep every PR moving by "nudging" it with comments, suggestions and approvals.

Review documentation

We have lots of helpful documentation for reviewers:

• https://github.com/kata-containers/community/blob/main/PR-Review-Guide.md
• https://github.com/kata-containers/community/blob/main/Documentation-Review-Process.md
• https://github.com/kata-containers/community/blob/main/Rota-Process.md

The following documents are also potentially useful for reviewers to read:

• https://github.com/kata-containers/kata-containers/blob/main/docs/Documentation-Requirements.md
• https://github.com/kata-containers/kata-containers/blob/main/docs/code-pr-advice.md
• https://github.com/kata-containers/kata-containers/blob/main/docs/Unit-Test-Advice.md

Proposals

"Raise 1, review 2"

If you raise a PR, please consider reviewing atleast two other PRs.

Present at the AC meeting

If you have specialist knowledge that could be shared with the community, please consider presenting at the Architecture Committee meeting. This will help others to help you as others will be able to help review PRs "in your area".

AC meeting plan

As discussed in the AC meeting on 2022-03-01, we're going to try expanding the scope of our CODEOWNERS files to focus reviews towards the teams that can best review particular PRs.

Plan

• Update the CODEOWNERS files.
• Review one month after they have landed to see if they are helping or not.

[jodh-intel]

RFC PRs raised - please comment! 😄

• codeowners: Expand scope kata-containers#3805
• codeowners: Expand scope tests#4534

[wainersm]

Hi @jodh-intel , thanks for raising those issues and proposing solutions.

I came from email based communities (e.g. QEMU) where it is a common practice to have a MAINTAINERS file to keep the inventory of maintainers and reviewers. And there are tools to copy patch series emails to the maintainers and reviewers too. I am still a heavy user of emails, and I have filters to organize my inbox; so github notifications where I was mentioned will land to my inbox and get my attention. I (unfortunately) don't have the habit of scanning github pull requests. So I'm saying all this to emphasize that I like the idea of the codeowners files being up-to-date as much as possible; that will help me to create filters and/or habits of reviewing PRs for the areas I am interested and is more knowledgeable.

[wainersm]

Hi @jodh-intel , thanks for raising those issues and proposing solutions.

I came from email based communities (e.g. QEMU) where it is a common practice to have a MAINTAINERS file to keep the inventory of maintainers and reviewers. And there are tools to copy patch series emails to the maintainers and reviewers too. I am still a heavy user of emails, and I have filters to organize my inbox; so github notifications where I was mentioned will land to my inbox and get my attention. I (unfortunately) don't have the habit of scanning github pull requests. So I'm saying all this to emphasize that I like the idea of the codeowners files being up-to-date as much as possible; that will help me to create filters and/or habits of reviewing PRs for the areas I am interested and is more knowledgeable.

Just to make it more clear: very often I loose the opportunity to review important PRs because I was not mentioned nor not marked as reviewer, then the github notifications goes to /dev/null... :(

[jodh-intel]

Thanks @wainersm. If you and others could tal at the proposed changes for the codeowners file, that would be great:

• codeowners: Expand scope kata-containers#3805
• codeowners: Expand scope tests#4534