PR Assignment & Alert Process

[breehall]

As our team continues to soar and crank out amazing work, what process do you think the team needs for assigning and maintaining the queue of open pull requests? This is a two part question.

1. How do you think we should assign pull requests?
   I don't think we have a concrete method of assigning PRs. Cee mentioned in our weekly sync that they assign the PRs to eui-team and allow them to be picked up. I think that this method in combination with an alert (like the one mentioned below) would be fine, but what do you all think?

2. How do you think we should maintain the open request queue?
   In our weekly sync we discussed setting up a bot to alert us of old or stale PRs.
   Github allows us to do this with scheduled reminders. There are different options like ignoring specific terms or tags and reminding authors after reviews. We could integrate this into the #eui-github-notifications Slack channel.
   You can check out the scheduled reminder creation page here.

[cee-chen]

++ to setting up a slack alert for open PRs! Adding a scheduled list/reminder this for Monday morning right before our grooming session makes a ton of sense, but I also think adding an ad-hoc reminder that nags whenever an unapproved or unmerged PR assigned to someone has gone 24+ hours without any activity (either a comment, or a push, or whatever) would be useful.

Cee mentioned in our weekly sync that they assign the PRs to eui-team and allow them to be picked up. I think that this method in combination with an alert (like the one mentioned below) would be fine, but what do you all think?

TBH, I've been a little medium on the @elastic/eui-team assignments 😅 They're primarily applicable for more speculative or investigatory PRs where I'm seeing feedback or confirmation from the entire team vs. one specific person, but for smaller PRs or quick fixes I think round-robin-ing is a bit more useful and tends to get looked at faster 🤷

[JasonStoltz]

They're primarily applicable for more speculative or investigatory PRs where I'm seeing feedback or confirmation from the entire team vs. one specific person

Agreed. I think assigning the whole team should indicate that you're expecting 👀 on it from the entire team.

I think round-robin-ing is a bit more useful and tends to get looked at faster

I think we should be assigning PRs to individuals. Round-robining is great, or if you have a PR you want to review from a specific person, we can do that also.

We can also set up Github to automatically do round-robin when we do team assignments: https://docs.github.com/en/organizations/organizing-members-into-teams/managing-code-review-settings-for-your-team#routing-algorithms

[1Copenut]

I like normalizing the idea if the eui-team is tagged on a PR, the whole team's feedback is being requested. It's good to have these conversations; in the past I've seen whole teams requested and no one acted. I think the idea was someone else less busy or more knowledgable would review it. This clear explanation is a positive affirmation everyone's feedback is requested and expected.

If there's an algorithm that can suggest reviewers, I say sure let's give it a try. Sometimes I catch myself changing the suggested reviewer because I feel I've asked the suggested person for a lot of reviews lately or someone else has been working with me or the files being changed, more recently.

[breehall]

Thank you for all of your input! What I've gathered is:

• PR Reminders
  • Yes to adding Slack reminders for PRs. Let's configure this for Monday mornings right before grooming
  • Add an additional reminder for stale (24 hours+ ) PRs that unapproved / unmerged and are assigned to someone
• PR Assignments:
  • Assign eui-team when soliciting feedback or confirmation from the entire team
  • Assign PRs that don't require the whole team to one individual. Let's try to work with the Github round-robin algorithm