# 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](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](https://rust-lang.zulipchat.com/#narrow/stream/238009-t-compiler.2Fmeetings/topic/.5Bweekly.5D.202023-01-19/near/322309288), 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](https://github.com/rust-lang/team/blob/master/teams/compiler.toml) 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

- [x] 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?
- [x] 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
- [x] 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?
- [x] Remove list of assigned PRs (list too long)
- [x] Add a checkbox to enable/disable "max assigned PRs". grey out the input if disabled (default: 10)
- [x] direct `r? user` overrides everything (f.e. assumes prev. discussion)
- [x] 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](https://rust-lang.zulipchat.com/#narrow/pm-with/261224-triage-rust-lang-bot) and use the following commands:
- File a PTO for me:
> @**triagebot** PTO add from <time:2023-01-20T10:36:00+01:00> to <time:2023-01-24T10:37:00+01:00>
- Remove PTO for me:
> @**triagebot** PTO del
- Check my PTO:
> @**triagebot** PTO list