Auto-assign people to issues and PRs

[plowin]

Background

In the CFF App Runtime Platform WG, @ameowlia struggles to keep up assigning issues and PRs to people and asked for some help automating this. I volunteered for a POC as noted as action item in our last WG meeting.

This is relevant for both issues and PRs and I took a look at both. From my POV, we need TOC-agreement for the PR-approach as we'd need a org-wide setting. I think, assigning issues seems to be more urgent and we could also try out a WG-specific solution for it and have a dedicated issue for it outside the central TOC/community project.

Proposal for Issues

I could not find a built-in option and checked two alternatives:

1. GitHub app: https://github.com/apps/auto-assign-issues
2. GitHub action: https://github.com/marketplace/actions/auto-assign-issue#working-with-issues

Option 1 did not work and seems not to be flexible for using GitHub teams but I had some success with Option 2, I am preferring 2b:

Option 2a (list of people):

This works just fine:

• Docu: https://github.com/marketplace/actions/auto-assign-issue#working-with-issues
• Workflow: https://github.com/org-plowin/code-review-poc/blob/b7afe35974dcbb34653a9ff8025b8d655319cf09/.github/workflows/auto-assign-all.yml#L12:

          - name: 'Auto-assign issue'
            uses: pozil/auto-assign-issue@v1
            with:
                assignees: b1tamara,plowin,stefanlay
                numOfAssignee: 1
                allowSelfAssign: true

• Issue got assigned: https://github.com/org-plowin/code-review-poc/issues/7
• Workflow run: https://github.com/org-plowin/code-review-poc/actions/runs/3712401031/jobs/6293885487
• Drawbacks:
  • requires a workflow per repo
  • adds many new locations to add WG members as individuals

Option 2b (GitHub "team"):

• Docu: https://github.com/marketplace/actions/auto-assign-issue#working-with-prs
• Github action config: https://github.com/org-plowin/code-review-poc/blob/a9c3dd614671b0721728668606457e57f10028c0/.github/workflows/auto-assign-all.yml#L12-L15:

          - name: 'Auto-assign issue'
            uses: pozil/auto-assign-issue@v1
            with:
                teams: team-plowin
                repo-token: ${{ secrets.TEST_TOKEN }}
                numOfAssignee: 1
                allowSelfAssign: true

• Issues get assigned to ppl from the team:
  • https://github.com/org-plowin/code-review-poc/issues/10
  • https://github.com/org-plowin/code-review-poc/issues/11
• Workflow run: https://github.com/org-plowin/code-review-poc/actions/runs/3712689614/jobs/6294496645
• Drawbacks:
  • requires a workflow per repo
  • adds many new locations to add WG teams
  • (AFAICT) no option to exclude technical users that might be in the team
  • requires a token per repo (org:read and repo:admin) to make the GH action work, could be added as org secret (?)

Proposal for PRs

For PRs, we we could use auto-assignment which is available for github orgs and teams. Tried it out for my test-org after adding two colleagues:

• 3 members in the team: https://github.com/orgs/org-plowin/teams/team-plowin/members
• A CODEOWNERS file adds this team to everything in this repo via wildcard: https://github.com/org-plowin/code-review-poc/blob/main/.github/CODEOWNERS
• The team has been configured according to this documentation: https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#configuring-auto-assignment
  • Tech users can be excluded which was not tried
• When opening a new PR, the CODEOWNER team is pre-selected by default for my repo. The two test-PRs got assigned and team-review was removed:
  • Example 1: https://github.com/org-plowin/code-review-poc/pull/1
  • Example 2: https://github.com/org-plowin/code-review-poc/pull/3
• With this approach, people are added as "Reviewers" and not "Assignees" but this should be fine from my POV
• Exemplary PR adding CODEOWNERS for one of the WG repos: https://github.com/cloudfoundry/pcap-release/pull/10
• Drawbacks
  • Has to be applied on org-level. Also without a CODEOWNERS file, ppl will be auto-assigned instead of the team after adding the team as reviewer: https://github.com/org-plowin/no-code-review-poc/pull/1. From my POV, this is not a big issue.
  • CODEOWNERS should be maintained for each repo

Additional Questions

In general, I am also not so sure how flexible we are with the GitHub teams. For example in App Runtime Platform WG, we got some areas with experts or even dedicated team-responsibility. We might need a more fine-granular concept of GitHub teams representing this. For us, this might be fine as we just got a new GitHub team that might be used. But for a general concept, this probably needs some broader discussions. Let's use this issue to start them!

[ameowlia]

Thank you for looking into this @plowin!

😅 I definitely don't think any option will be free or easy.

🤔 I think it would be great if PRs + Issues were handled by the same mechanism. Maybe like this action? (Warning: I did not test it).

❓ What do other WG's handle this stuff? cc: @cloudfoundry/wg-leads ?

[plowin]

Hi @ameowlia , thanks for the feedback and link. It makes sense having the same mechanism but with the current tooling on the web, it does not seem to be possible. The action looked promising and I tried it out in my setup. It seems to support configuring teams for both, issues and PRs.

Sadly, it does not have any round-robin functionality. When specifying numberOfAssignees to 1, it always takes the first entry from the list. Also checked in the code and there is nothing to get what we need. I raised an issue if this could enhance this workflow in general: https://github.com/wow-actions/auto-assign/issues/11

I'd also be curious how other working-groups handle this, waiting for further ideas.

[gcapizzi]

We use GitHub issues as backlog items, so they go through the classical Tracker-like flow: icebox -> selected -> in progress (that's when we assign) -> finished -> accepted -> done. A flow that auto-assigned issues wouldn't work for us.

On the other hand, it would be convenient for issues opened by people outside of the team. At the moment we just dump them in the icebox, which means it make take us a few days to even notice them.

[beyhan]

We use our FI WG meeting to assign people to PRs with the mentioned auto-assignment project settings of Github. For issues we don't have a strict approach. Basically, we try to react on them in a best effort approach and most of the time we don't have anyone assigned to them. During our FI WG we go over the issues which are still in our inbox and close or add a comment to them which transition the issues into our Discussion | Pending Review state. Additionally, we look into all issues in Discussion | Pending Review which have a Last Activity date newer than our last FI WG meeting. With this we guarantee that active issues will be updated latest during our FI WG meeting.

[ameowlia]

@beyhan - How do you get a list of all issues and PRs for your working group? We have projects, split up by area. But projects only allow you to link 25 repos, and our areas have more than that.

[ameowlia]

@Benjamintf1 - Curious to hear how you handle this issue Ben, since I know your area handles this on its own.

[beyhan]

@ameowlia There is a tool/Github action developed by @rkoster to sync all our repos into one project like here. We struggled also with the Github limit of 25 repos. Not having everything in one place makes it unmanageable. It should be generic so that your WG could also have its own sync.

[ryanmoran]

The Buildpacks area in the ARI WG has just one big pool of people and repos when in reality it only makes sense to assign certain users to certain issues. We'd love to have some automation like what is being proposed, but I think this would mean that we'd need to sub-divide our current area quite significantly (1 area becomes 15 areas). Do others have this type of sub-division within their area? Do we just need to bite the bullet and create lots of buildpack areas within ARI?

[ameowlia]

@ryanmoran - We have a similar issue with having broad areas and some approvers only have expertise in parts of the areas.

[beyhan]

@plowin Do you have a solution in the mean time? Can we close this?

[beyhan]

Closing because of inactivity. @plowin please reopen if it is still relevent.