owned this note   changed 2 years ago  
Published Linked with GitHub

Handling time off for pull requests reviewers

Problems

  1. today @rustbot assigns a review by reading the .toml files in https://github.com/rust-lang/team
  2. we don't have anything (ex. a shared calendar) where ppl can opt in to file their time off from reviewing PRs.
  3. sometimes pull requests are autoassigned but not reviewed because (among other reasons) ppl are on "off duty". Example this comment, we know by word of mouth that someone in not available for reviews

Backoffice for people to file their time off

Contributors can set their own review capacity, @rustbot will read these preferences when autoassigning a review. Settings will be saved in the triagebot DB. @rustbot will exclude people not actively on duty and distribute the workload more evenly (according to contributors' capacity).

  • This could deprecate the editing of .toml files on GitHub only to set oneself temporarily off-duty. Editing the TOML files will be only to add and remove people from a team
  • Access to this backoffice is behind a GitHub auth token (i.e. only accessible if you're logged into GitHub)
  • The backoffice will request the team TOML file everytime from Github and will match the list of users from its DB.
  • This backoffice will show only users that are listed in the members section of the teams TOML files. If a person is removed from a team or is moved to the alumni section, the record won't show up anymore in this backoffice.

How will it work in practice?

Let's see some cases:

When requesting to a team (es. r? compiler) the autoassignment will skip people on not actively on duty.

When requesting a specific person whose queue is full, the review will be assigned anyway.

If a person is added to a team (through the usual .TOML file procedure), they will be asked to fill up these settings. It is not mandatory, though.

Questions / Comments

  • Do we want everyone able to query someone else's PTO? Add a flag to allow the reviewer to publish or not their preferences.
  • how can the team have idea of who has set these prefs? an admin? maybe team leads? Does Github oauth2 tokens differentiate between team leads and members?
  • Should this backoffice stay inside the triagebot or be hosted as an external application? There will be authentication involved, maybe better to host it somewhere else
  • What happens to assigned PRs when the assignee is on PTO? Currently PRs wait for the reviewer to be back. Or if a PR sits there indefinitely, it might be reassigned to someone else
  • Add a flag to set oneself "off duty" (equals to being on PTO permanently, until the flag is reversed)
  • What happens is a new team member does not fill-up their preferences? Will the PR be assigned based on some defaults? Ask the new team member to fill up their prefs?
  • Remove list of assigned PRs (list too long)
  • Add a checkbox to enable/disable "max assigned PRs". grey out the input if disabled (default: 10)
  • direct r? user overrides everything (f.e. assumes prev. discussion)
  • Time off start and end in the same column
  • "Days before ping": this is subjective. Remove this field? Coordinate with triage? PRs against critical things should move faster. Cleanups, tier 3 platforms don't need to move equally fast. Ensure pings happen when a PR is really "forgotten". Need to think about it.

Nice to have: Zulip integration!

Privmsg the triagebot on Zulip and use the following commands:

  • File a PTO for me:

@triagebot PTO add from time:2023-01-20T10:00:36:00+01 to time:2023-01-24T10:00:37:00+01

  • Remove PTO for me:

@triagebot PTO del

  • Check my PTO:

@triagebot PTO list

Select a repo