Automate code review assignment

[pbochynski]

Description

Code review assignment should be automated to:

• reduce time to merge
• reduce number of github notifications
• reduce communication noise related to review assignment on slack
• enable effective reviews for external contributors

It can be done by enabling auto-assignment in the team settings.

To make it effective we need first to refactor our CODEOWNER files to use teams. The idea is to not use internal team names (can be confusing for externals or newjoiners) but area teams. Developer can join multiple teams so we can be still flexible. We can simplify CODEOWNERS file and keep it stable (no need to change CODEOWNERS when someone join/leaves the team).

Plan

• ask entire kyma team for opinion, get their approval, adjust the plan based on their feedback
• create area teams like: eventing, reconciler, provisioner, keb, monitoring, service-mesh, documentation etc.
• assign individual codeowners to area teams
• modify CODEOWNERS to use area teams instead of individuals (Replace individual code owners with teams kyma#12837)
• configure teams notifications (how to)
• configure auto-assignment with round-robin or load balancer(how to)
• update contribution guide: describe new process, make use of draft pull request to not spam reviewers with not ready PRs
• create dashboard (or any other tool) that can monitor review process effectiveness (measure time to review, time to merge)

Reasons

If your Pull Request (PR) involves many code owners it is hard to get them working on it. You need to actively search for the proper team member on slack as the notifications are going to all code owners and none of them feel responsible for the review (they get tons of such notifications). As a result, the review process generates also notification hell on slack. The process is inefficient and almost impossible to go through for external contributors (they do not know who to ping on slack).

[majakurcius]

I like the idea, sounds like a great improvement. Thanks for researching that!
From what I understand, it will still be possible to manually assign a specific team member as a reviewer (e.g. when someone is on sick-leave), right?

[Ressetkk]

I have to add some cents to that topic.
As a team that is responsible of Prow environment we actively monitor possible improvements in regards of development workflow. One of the improvements was automatic merge which has been used for several months now. What Prow can also do is to manage the entire flow of PR - from opening one, through review and ending in auto merge after some steps are required. This flow seems to be just the right thing for this issue.

With wide variety of Plug-Ins Prow can:

• Assign labels based on the changes in the pull request (eg. area/ sig/),
• Assign person to do a review using comment flow (/assign /unassign) and should be able to automatically load the review between directory reviewers using blunderbuss plugin,
• Define potential user groups in OWNERS_ALIASES file,
• Check if requested reviewers/approves approved the Pull Request (approve plugin),
• Automatically check if the PR can be merged (Tide),
• Handle external contributors by blocking pipeline execution (ok-to-test plugin)
• Allows to completely revoke the write access to the repositories in the organisation which will harden the security and mitigate the chance to 'accidentally` change the repository context.

In addition Prow is also expendable with API for handling the external plugins which might further extend the workflow related operations.
So far the only problem with this approach is that Technical Writers are the owners of every Markdown file in our organisation and approve plugin cannot assume the ownership of the file based on filters applied in the OWNERS file. I've created an issue that tackles this problem and I've proposed two solutions described in kyma-project/test-infra#4520. Please @pbochynski @majakurcius and other Technical Writers take a look at that. In addition I'm working on a PoC Prow plug-in that will label every Pull Request if the markdown files are changed. This potentially will allow to introduce the Prow's approval flow.

For more information regarding the Prow flow refer to the following docs:
https://github.com/kubernetes/test-infra/blob/master/prow/plugins/approve/approvers/README.md
https://github.com/kubernetes/test-infra/blob/master/prow/plugins/README.md
https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md

The example PRs handled by Prow can be seen in any repo in Kubernetes organisation.

[NHingerl]

Maybe both suggestions can be combined? So, use area teams to support automatic assignment, and use the Prow functionalities to manage the entire workflow. Not sure if that works from a technical perspective though.

[Ressetkk]

Maybe both suggestions can be combined? So, use area teams to support automatic assignment, and use the Prow functionalities to manage the entire workflow. Not sure if that works from a technical perspective though.

Unfortunately GitHub assumes all codeowners also have write access to the repository, as stated in official GitHub docs.

The people you choose as code owners must have write permissions for the repository. When the code owner is a team, that team must be visible and it must have write permissions, even if all the individual members of the team already have write permissions directly, through organization membership, or through another team membership.

If we were to revoke the write access from members then GitHub's functionality won't work.

Additionally Prow does not allow to define GitHub groups as reveiwer/approver in the OWNERS file because GitHub does not provide audit logs for changes in the teams. Hence why there is OWNERS_ALIASES, where you can simply define aliases for groups of people. It's convenient and simple.

[pbochynski]

@Ressetkk I am not attached to the GitHub solution if we can achieve the same result with OWNERS and ONWERS_ALIASES we can try it. If only *.md pattern is blocking us from applying it, I would consider removing that line for a while. Anyway, I think it would be better to have TW review optional for files outside /docs/ folder.

[Ressetkk]

@pbochynski I have prepared the workaround regarding this problem - Prow plug-in that will keep blocking label until a person from tectonical writers approve changes, and in the future Prow will just allow for granual approvals. However teams responsible for the code will have to update or create the OWNERS file inside their directories before we enable Prow approval flow.

[pbochynski]

We agreed with @Ressetkk to apply prow plugins in some repositories and verify the code review flows there (e.g. test-infra or community repo).

[Ressetkk]

After a week of extensive testing I'm here to write some conclusions:

• Prow assigns 2 people, based on their availability set in GH, to newly opened PR. This works highly as noted in the k8s LGTM flow. However reviews are only informational, and review requests should be tracked individually. As stated in the docs:

Any collaborator on the repo may use the /lgtm command, whether or not they are selected as a reviewer or approver by this plugin.

Of course it's an intended thing, as teams may have different review flow for PRs that touch their area/. Additionally the PR author, or any other person can /cc @person manually to request their review. Everyone can set their push notifications that are sent every time bot requests a review from them. Approved label, and by that Approval of the PR, can ONLY be done by the person who is listed as an approver in the specific OWNERS file.

Prow also helps defining which person to /assign @person in the comment. The Reviewer is responsible to assign the person or mention them in comments.

* Drafts are still being assigned to reviewers. The issue regarding this problem is tracked in kyma-project/test-infra#4798 This is no longer an issue. Prow now does not request any reviews from Draft PRs.

• To link PR with an Issue, PR creator must use GitHub keywords listed in GitHub Docs. Other ways of linking will not be possible.

• Labels are not changeable. Each person should use /commands to set allowed labels. The label and lifecycle are generally the ones that allow managing various labels.

• Projects and Milestones assignment is not yet tested. Prow provides two plugin called project and milestone. The project/milestone assignment would work by using commands /project name or /milestone name, but from my understanding another GitHub groups for project/milestone maintainers will have to be created. Applying milestone can be automated using milestoneapplier plugin.

• The complete list of Prow commands that are available is listed in https://status.build.kyma-project.io/command-help

[Disper]

Two points from my side

1. Is there any way of listing all PRs where members of a specific team were requested for a review? It could be helpful in making sure that no PR was accidentally omitted. It would be especially important at the beginning because afaik we're completely not used to Github notifications.
2. I'm thinking whether we should be using Busy status (docs) before someone goes to holiday or Never assign certain team members option ( 10th point in the docs ) in case someone forgets or won't be able to set it up.

[Ressetkk]

@Disper

Two points from my side

1. Is there any way of listing all PRs where members of a specific team were requested for a review? It could be helpful in making sure that no PR was accidentally omitted. It would be especially important at the beginning because afaik we're completely not used to Github notifications.

Not that I'm aware of, but once the OWNERS files will be filled up and have area/ labels set up it should be possible to triage all PRs based on the assigned area/ labels.

2. I'm thinking whether we should be using Busy status (docs) before someone goes to holiday or Never assign certain team members option ( 10th point in the docs ) in case someone forgets or won't be able to set it up.

Prow will most likely ignore the second option, as the new flow will not be using GitHub rules. AFAIK blunderbuss filters reviewers based on Busy status set in profile.

[Ressetkk]

I have made some tests with issue/PR assignments to Projects and Milestones. We've created test GitHub Team called project-maintainers and updated the Prow configurations, as required by plugins:

Projects:
Once write access is indeed removed it's not possible to assign Issue or PR to the Project or Milestone. The only way to add Issues to the project will be through Project board itself 😭
The plugin that Prow provides does not seem to work with new Boards. If that's the major issue then the problem might not be easily worked around 😞

Milestones:
it is possible to assign existing PR or issue with a milestone even without write access. Prow's plugin milestone allows milestone assignments using /milestone command by group of people specified in the defined GitHub Team. The configuration can be either global, or different per repository. That means for specific repos there can be different GitHub Team that is responsible for assigning milestones. This is probably intended thing, because you don't want everyone to edit the milestones going towards specific release, or topic. With that option it's possible to restrict the milestone application to strict group of people, not the entire development team.

It's also possible to automatically assign PR to the milestone. Prow also provides such functionality - based on the plugin configuration, The milestoneapplier plugin automatically applies the configured milestone for the base branch after a PR is merged. If a PR targets a non-default branch, it also adds the milestone when the PR is opened. That means if the PR is merged to the main branch it will be added to the specified milestone. Working example of the configuration can be found here

The tests were done on Issue kyma-project/test-infra#4832.

[Disper]

Would it be possible to add new issues to new projects automatically without Prow plugin but with some external script that are calling New GitHub projects API directly with some technical account that has the write permissions?

[janmedrek]

If I understand correctly - the only way to add milestones/projects to the issue would be to go through the board for projects and with the use of commands in GH comments for milestones?

Looking at the test issue - it kills the transparency for me. We want to have status updates in the issues, those will be mixed with commands for milestone updates (and we have lots of those).

Regarding projects: GH-default fields (such as assignee or labels) are immutable in the project as well.

Isn't that a little bit - overkill?

[Ressetkk]

@janmedrek status update comments can include commands, as well as Issue/PR body. That is really a change of a habit IMO.
One of the solution would be to add Triage role for the set of people that should manage the issues and PRs. This can be done with creating GitHub group with this permission. That ofc allows people with triage right to edit milestones, assignees, labels and request reviews. Most of the stuff can be done with Prow and comment flow.

Problem is when person has excessive permissions for the repository and unfortunately GitHub doesn't want to improve on that so easily. For example one of the most requested issue was to restrict pushing tags to the repository. No progress since 2019. With bigger orgs such things may generate more problems than solved issues.

[klaudiagrz]

Hi @Ressetkk ! 👋

Thank you for your presentation on SIG Quality! 🙂

I just want to confirm that in the new approach nothing will really change from the TWs perspective, is that right? We will operate on this documentation-review-missing label that will prevent PRs from being merged in case there is any change in the documentation. Then the parties interested will have to ping us for review, right?

In case you'd like to change that in the future, I have two remarks:

• Please note that the number of TWs in our project will drop drastically to 4 people in the nearest future so if 2 people will be auto-assigned and needed for review, that already makes half of the team, which makes quite a big pressure on us. We would prefer that only one TW's approval is required.
• TWs are assigned to specific teams so they "specialise" in the team's domain. For example, I always review docu PRs related to service management and KEB. We would like to keep it that way but I'm not sure how it could be handled from the technical point of view.

cc: @kyma-project/technical-writers

[Ressetkk]

@klaudiagrz

I just want to confirm that in the new approach nothing will really change from the TWs perspective, is that right? We will operate on this documentation-review-missing label that will prevent PRs from being merged in case there is any change in the documentation. Then the parties interested will have to ping us for review, right?

Prow will only add label to the PRs that have changes in the Markdown files. It will not request any reviews from TWs and will not require reviews from 2 people from this group. Only one approving review from technical-writers group in OWNERS_ALIASES is required to dismiss blocking label. It will be up to a PR creator or code reviewer to mention @kyma-project/technical-writers in their PR so you get a notification. Unfortunately /cc does not work with GitHub Teams.

Of course there is still room for improvements and if you have any suggestions please raise an issue on the test-infra with /area tooling.

TWs are assigned to specific teams so they "specialise" in the team's domain. For example, I always review docu PRs related to service management and KEB. We would like to keep it that way but I'm not sure how it could be handled from the technical point of view.

The workaround that is working on the test-infra will not change the flow you review the documentation. Manual ping still will be needed for documentation review. Either in GitHub or by other means.

[strekm]

@Ressetkk what concerns me is that we can always have ppl in github team who shouldn't be codeowners. i assume that everyone in a github team is already codeowner, right?

[Ressetkk]

@Ressetkk what concerns me is that we can always have ppl in github team who shouldn't be codeowners. i assume that everyone in a github team is already codeowner, right?

@strekm code owners are defined in the approvers section of respective OWNERS file. They can be only members of the organisation or outside collaborator, if allowed. By default external contributor cannot be an owner. Every member of the organization can do a review, but it will be up to the approver to approve the PR and allow it to merge.
GitHub CODEOWNERS cannot work unless you give the people WRITE access to the repo. It is stated in the GitHub docs.

[janmedrek]

@Ressetkk

status update comments can include commands, as well as Issue/PR body. That is really a change of a habit IMO.

Totally agree with that, I am not convinced of the commands though. We are automating one action (assigning a reviewer) while forcing multiple other actions (such as adding labels or milestones) to be done via commands - this is inconvenient in comparison to just choosing a label from the list, it will generate a lot of noise since reviewer needs to be assigned once and issue metadata is something that changes quite often (looking at the stalebot for example).

[koala7659]

I generally like the idea of specifying teams and groups of people as codeowners of some functionality in Kyma or control-plane. But the idea of automatic review assignment for PRs is problematic to me and I believe it will negatively impact the quality of the code. Here are my thoughts:

• Current process works well for in our team. We choose the reviewers for our PRs on our daily meetings based on people's expertise, experience with the code and current workload. We sometimes switch reviewers if we think it is more effective.
• If any external team requests code review from us, we take the review request from slack. There is a dedicated person "tarcz" who takes care that no review request is left unanswered, and ensures that the reviewer is found.
• We have team members with different level of expertise, some of them that are still learning the code base. I don't think they should got be assigned as reviewers for ANY PR before they got some experience.
• Most likely after getting assigned as a reviewer to unknown piece of the code somebody will immediately start looking for a more experienced developer switch review with him.
• In the last point about effectiveness there is a hidden assumption that good code review is a quick one. I'm afraid it will make a pressure on developers to close reviews as soon as possible without much care for the quality of the code.

To summarise my opinion I strongly believe that the team should agree on the matter who should review individual PR - not random algorithm.

[Ressetkk]

@janmedrek

Totally agree with that, I am not convinced of the commands though. We are automating one action (assigning a reviewer) while forcing multiple other actions (such as adding labels or milestones) to be done via commands - this is inconvenient in comparison to just choosing a label from the list, it will generate a lot of noise since reviewer needs to be assigned once and issue metadata is something that changes quite often (looking at the stalebot for example).

That's why I suggested that there should be a specific set of people (POs) that have Triage GitHub role. Proper GitHub Team can be created, and not only have the Triage role, it can be configured to be used with milestone plugin, giving people from this team access to the /milestone command. This one gives the required permissions to manipulate labels, assignees, project and milestones right from the Issue page. The person outside this role will only be able to operate on issues using allowed commands. Commands will not mate that much noise as it looks like. If GitHub notifications are set-up properly you will get pinged only if you were assigned, mentioned, requested your review or there has been an activity in the Issue.
Adding issue to the project can be done from the page by anyone having right permissions to the project.

Choosing a label using specific set of commands restricts your usage of some protected labels. Tide uses labels to determine the status if PR can be merged or not. Right now you can modify labels to your liking by using any of the labels, also the ones you are not supposed to use, like approved, lgtm, or any other do-not-merge/ label.

[Ressetkk]

I generally like the idea of specifying teams and groups of people as codeowners of some functionality in Kyma or control-plane. But the idea of automatic review assignment for PRs is problematic to me and I believe it will negatively impact the quality of the code. Here are my thoughts:

• Current process works well for in Framefrog team. We choose the reviewers for our PRs on our daily meetings based on people's expertise, experience with the code and current workload. We sometimes switch reviewers if we think it is more effective.
• If any external team requests code review from us, we take the review request from slack. There is a dedicated person "tarcz" who takes care that no review request is left unanswered, and ensures that the reviewer is found.
• We have team members with different level of expertise, some of them that are still learning the code base. I don't think they should got be assigned as reviewers for ANY PR before they got some experience.
• Most likely after getting assigned as a reviewer to unknown piece of the code somebody will immediately start looking for a more experienced developer switch review with him.
• In the last point about effectiveness there is a hidden assumption that good code review is a quick one. It will make a pressure on developers to close reviews as soon as possible without much care for the quality of the code.

To summarise my opinion I strongly believe that the team should agree on the matter who should review individual PR - not random algorithm.

With Granular OWNERS you can define for example a SUBSET of people from framefrog that should review or approve the PR if it touches the file. Let's take an example: you have created a package for component your team is responsible for. This was the combined effort of 3 people in your group. You can define OWNERS file in this directory with reviewers field set to you, and two of your colleagues, and approvers with you and for example PO, and labels: area/component/package. If someone touches the files in this directory, a reviewer from this OWNERS file will be requested to do a review, for ex. you and one of your team members. If the PR is lgtm'd, someone from approvers will have to /approve the PR to let it merge, for ex. if you review this PR you will automatically approve it. If someone else from your team will review it, that is not in the approvers list, you will have to /approve the PR. Only if the required set of approvers /approve the PR (one per each touched directory) the PR will be approved to merge.

OWNERS file can include specific GitHub usernames or aliases from OWNERS_ALIASES file.

This will not change your usual way of reviewing the PRs. If the OWNERS file are properly configured, then correct people will be assigned to do a review. If not, one can always /cc @person to request a review manually. This ensures someone got a GitHub notification :)

[dbadura]

My short comment about this.
The problem is: how to ping the proper team or assing
I think, instead of assigning particular person, you should be able to assign the team responsible for area, e.g serverless.
The team can check if there is a PR assigned to the team and not assigned to the particular person every day and assign particular person

The problem I see with automatic assignment is that it can assign people who doesn't contribute to kyma any longer.
Generally It would be nice to create per directory CODEOWNERS file instead of having the big one.

[Ressetkk]

@dbadura

My short comment about this. The problem is: how to ping the proper team or assing I think, instead of assigning particular person, you should be able to assign the team responsible for area, e.g serverless. The team can check if there is a PR assigned to the team and not assigned to the particular person every day and assign particular person

Based on the OWNERS file inside the specific directory. You define a set of approvers and reviewers inside the directory and for review only this set of reviewers will be assigned for review.

The problem I see with automatic assignment is that it can assign people who doesn't contribute to kyma any longer. Generally It would be nice to create per directory CODEOWNERS file instead of having the big one.

With Prow integration you will be able to define multiple OWNERS files for each directory, see http://github.com/kyma-project/test-infra for reference.
People who are still in the OWNERS file, but do not belong to the organisation, or are not external collaborators will not be assigned for a review. Additionally each person who doesn't want to be assigned to a review can set their status to Busy in the GitHub profile.

[pPrecel]

@dbadura

good point. I think we can extend this proposition to create new labels (for example review-required/wookiee) and then every day we can filter all PRs in our two organizations by this label, for example as a part of the daily planning.

Here is an example link to filter all PRs in the kyma-project and the kyma-incubator orgs with the size/M label:
https://github.com/search?q=org%3Akyma-project+org%3Akyma-incubator+is%3Aopen+is%3Apr+label%3Asize%2FM&type=issues

[Ressetkk]

@dbadura

good point. I think we can extend this proposition to create new labels (for example review-required/wookiee) and then every day we can filter all PRs in our two organizations by this label, for example as a part of the daily planning.

Here is an example link to filter all PRs in the kyma-project and the kyma-incubator orgs with the size/M label: https://github.com/search?q=org%3Akyma-project+org%3Akyma-incubator+is%3Aopen+is%3Apr+label%3Asize%2FM&type=issues

@pPrecel Maybe instead of creating labels for review-required/ we should go with the approach that is widely used and is actually proposed in the 1st post - create special interest groups (SIGs) regarding specific part of the topic, so the people affiliated with the topic will be able to filter interesting info. GitHub search queries are pretty powerful.

With properly created OWNERS files automatic review assignment should be pretty straightforward. I have also suggested similar approach in my previous messages. Please take a look at them.

With Granular OWNERS you can define for example a SUBSET of people from framefrog that should review or approve the PR if it touches the file. Let's take an example: you have created a package for component your team is responsible for. This was the combined effort of 3 people in your group. You can define OWNERS file in this directory with reviewers field set to you, and two of your colleagues, and approvers with you and for example PO, and labels: area/component/package. If someone touches the files in this directory, a reviewer from this OWNERS file will be requested to do a review, for ex. you and one of your team members. If the PR is lgtm'd, someone from approvers will have to /approve the PR to let it merge, for ex. if you review this PR you will automatically approve it. If someone else from your team will review it, that is not in the approvers list, you will have to /approve the PR. Only if the required set of approvers /approve the PR (one per each touched directory) the PR will be approved to merge.

OWNERS file can include specific GitHub usernames or aliases from OWNERS_ALIASES file.

This will not change your usual way of reviewing the PRs. If the OWNERS file are properly configured, then correct people will be assigned to do a review. If not, one can always /cc @person to request a review manually. This ensures someone got a GitHub notification :)

[koala7659]

@Ressetkk Asigning PR review for the team with just a GH label could be the easiest approach without defining specific owner for every file. With labels we can be quite flexible and dispatch review request to developers who have time to take care about this task. IMHO that could make our life much easier.

[Ressetkk]

@koala7659

@Ressetkk Asigning PR review for the team with just a GH label could be the easiest approach without defining specific owner for every file. With labels we can be quite flexible and dispatch review request to developers who have time to take care about this task. IMHO that could make our life much easier.

If specific teams want to adjust their review flow differently I see no problem if said teams just ignore automatic assignment and dispatch review in their own flow. As I mentioned before, everyone from the organisation can do a review, and add /lgtm label. It is up to approver defined in OWNERS file to /approve a PR. OWNERS files are still valid and need to be created. Other teams, like tooling, would like to utilise automatic assignment and make review as part our daily workflow. GitHub notifications with review requests will be a nice QoL improvement for teams who want that functionality.

We want to provide secure repository management and reliable infrastructure with good set of automations that improve workflow in the organisation.

[Disper]

Allows to completely revoke the write access to the repositories in the organisation which will harden the security and mitigate the chance to 'accidentally` change the repository context.

We're using List layout of Github Projects beta and today we've noticed that our new team mate wasn't able to edit few of the fields. It was fixed when I've added him to developers team, probably because of the write permissions that team has on all repositories.

I just wanted to point out that some fields that are easily edited via GitHub Projects boards won't be editable anymore in such convenient way when we revoke the write accesses.

[Disper]

One more scenario to consider. We often tend to create issues, which contents are later edited by someone else by adding e.g. some details.

Will that be possible without having write accesses on the repository? I understand that we can add new comments, but sometimes it makes sense to just edit the original description of your team mate so it will be easier to see all essential information in one place.

[Ressetkk]

@Disper no, only people with Write access can modify others messages. It's actually a security measurement since anyone can modify anyone's message completely changing the original message.

[dbadura]

@Ressetkk
As far as I know, the history of modification is available.
Would I be able to modify my comments?

[Ressetkk]

@dbadura Yes.

[ghost]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[dekiel]

Because prow approval flow was reverted neighbors team decided to use github native auto code review assignment. This feature can is enabled on a team level. This doesn't require change on a repo or organisation level. With our monorepo setup it allow each team to decide if they would like to use it. Github documentation with instruction about feature enabling. https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#configuring-auto-assignment.

Because of enabled standard branch protection on our repositories a team review request is not removed from the list. However auto assignment notification settings allow send notification to the individual members only. This makes web or mail notification less noise.
Check following option.

Only notify requested team members

If you are using github scheduled reminders you can make it ignore team review request assignments too.

One requirement which some might see as a drawback is that you need to use a GitHub team as an owner in CODEOWNERS file.

[tobiscr]

Thanks a lot for the provided details and the suggestion to use Github auto-assignments for reviews. We enabled the feature for our existing reconciler repository and are looking forward to gain more experiences about its impact on our current "merge performance". It looks quite promising that we can shorten the time between opening and merging a PR.

[ghost]

This issue has been automatically marked as stale due to the lack of recent activity. It will soon be closed if no further activity occurs. Thank you for your contributions.

[ghost]

This issue has been automatically closed due to the lack of recent activity. /lifecycle rotten

[pbochynski]

As a tendency is now to move from big monorepo into teams repositories problem can be addressed on team level using github features.