Migrating highfive to triagebot

This is a proposal on how to migrate highfive to triagebot.

Triagebot will be updated with the following:

• Add support to detect r? foo to perform the same behavior as @rustbot assign foo. This is essentially https://github.com/rust-lang/triagebot/pull/433 and https://github.com/rust-lang/triagebot/pull/946.

  • This will only be enabled if the [highfive] table is in triagebot.toml. This requirement makes it possible to transition away from highfive without having the two bots fighting each other (see transition below).

  • This will use the groups and owners configuration from triagebot.toml (see below).

  • Triagebot's behavior may be altered slightly to be more similar to highfive (though probably not much). Some behaviors may be different. For example:

    • Highfive restricts the commenter to be the author, the current assignee, or a repo collaborator. I think this restriction isn't particularly necessary (as triagebot's @rustbot assign is currently unrestricted). If we have problems with abuse, that can be handled individually, or we can add restrictions later if needed.

• Triagebot will trigger on new PRs to auto-assign using the same behavior has highfive.

• Add configuration to triagebot.toml to configure auto-assignment on new PRs:

  ​​​​# Ad-hoc groups can be configured here.
  ​​​​# Although it is preferred to use real GitHub groups, very often the
  ​​​​# review rotation is not the same.
  ​​​​[highfive.groups]
  ​​​​libs = ["@joshtriplett", "@Mark-Simulacrum", "@kenntytm", "@m-ou-se", "@thomcc"]
  
  ​​​​# This specifies users, groups, or teams to assign for different paths.
  ​​​​# Triagebot will use pick one person to assign.
  ​​​​# Paths are gitignore-style matches.
  ​​​​[highfive.owners]
  ​​​​# Examples of assigning individuals.
  ​​​​"Cargo.lock" = ["@Mark-Simulacrum"]
  ​​​​"/library/std/src/sys/windows" = ["@ChrisDenton"]
  ​​​​# Example of assigning to a group.
  ​​​​"/library/std" = ["libs"]
  ​​​​# Supports gitignore patterns.
  ​​​​"*.js" = ["@foo"]
  ​​​​# Can use real GitHub teams.
  ​​​​"/src/tools/cargo" = ["@rust-lang/cargo"]
  
  ​​​​# Additional features in the highfive table.
  ​​​​[highfive]
  ​​​​# Automatically adds these labels on new PRs.
  ​​​​new-pr-labels = ["S-waiting-on-review"]
  ​​​​# If `true`, then triagebot will write a comment if the PR is opened against a different branch than the default.
  ​​​​expected-branch = true
  ​​​​# A URL to include in the welcome message.
  ​​​​contributing = "https://rustc-dev-guide.rust-lang.org/"
  

Migration

To migrate a repo, the process is roughly:

1. Post a PR to add triagebot.toml configuration.
2. Post a PR to remove the configuration from highfive.
3. Very shortly after the triagebot.toml file is merged, merge the highfive change (or just remove the highfive webhook from the repo) to avoid conflicting behavior.

Alternatives considered

These are some alternatives that were considered, but not chosen.

• Use CODEOWNERS. This is a built-in GitHub system with rather sophisticated capabilities. It uses gitignore-style syntax to choose who to "request review" from based on which files were modified.

  When a team is requested, GitHub can be configured to select a subset of the team. You can select the number of people to request. You can also choose to never select certain members. It has different algorithms: Round-robin or Load-balance. Both are rather sophisticated.

  I don't think we should use CODEOWNERS for the following reasons:

  • It only does the "request review" feature, it does not set the assignment. I think it is important to very clearly mark who is responsible for the PR via the "assignment" field. The "request review" feature is tucked away in a small part of the UI, and isn't as clear to me.
  • It requires the users to have write access to the repo.
  • It is only triggered on new PR, you can't reroll (AFAIK).
  • If multiple people match, they are all requested, which makes it a little harder to make it clear exactly who is responsible for the PR.

  See https://github.com/rust-lang/highfive/issues/72

• Configure review groups via the teams repo.

  This is certainly a viable option. I could see a few different ways of approaching this, such as creating "real" teams, or just having a configuration in each team config that lists who is in rotation.

  This seems a bit overkill, and would require spreading the configuration between triagebot.toml and the teams repo. I think that would make it harder to configure.

  The downside is that this adds ad-hoc groups which can be confusing.

• It was suggested to not allow defining individuals at all (and only allow teams), but I think that is over-restrictive.