Document compiler backport nomination/review/decision procedure and process

[jieyouxu]

Tip

Part of a meta-effort to document our team policies and processes, cf. #all-hands-2025 > team processes and policies session.

As part of the async compiler backport experiment, I noticed we didn't really have any concrete docs on how compiler handles backport nominations and decisions (esp. the async process that we're experimenting with now, but also the sync process).

How to determine when a decision point was reached for async backport nominations was discussed in Do backport nominations async? zulip thread. Quoting @davidtwco for the async backport process:

I think we could say "if N team members vote one way and there's no disagreement, then go with that vote" and hopefully if there's enough engagement then that is 90% of cases (once we pick an N), otherwise we can raise these at the weekly meeting but hopefully with a shorter time spent on them because they've been pre-read/voted by some.

Ideally we ping the group of people interested in backports so that they see it

I think "async backport will never take longer than waiting for the next meeting" is a reasonable upper bound

In this PR, I took the liberty to pick:

1. For async backport polls: N >= 3 "strong" approve/reject votes with no votes in opposite direction.**
2. For sync triage meeting backport polls: N >= 2 "strong" approve/reject votes, where N includes at least one compiler lead.

I also took the liberty to document a fallback backport decision procedure for compiler leads

In time sensitive cases, compiler leads may choose to accepted/reject backport nominations if there are insufficient engagement on either async/sync avenues.

r? @davidtwco (and @wesleywiser)
cc @apiraino (compiler-ops 😁)
cc @cuviper (since you raised the "it's hard (for release team) to determine when to know compiler has reached a backport decision" point with me :D)
cc @rust-lang/release

Rendered

[jieyouxu]

Discussion:

1. Is N = 3 a good minimum threshold for async backport polls?
2. Does the N = 3 need to include >= 1 compiler lead?

[jieyouxu]

Discussion:

• Is N = 2 a good minimum threshold for sync backport polls?

[apiraino]

So, a few thoughts.

I appreciate your effort to explain the topic exhaustively but this feels ... quite a lot of text for what the backport workflow actually is. I would like to review it to see if we can cut some foliage.

Second point: I think it's a bit premature at this time to set in stone, with this level of detail, the number of votes to approve backports. Let's not make it look like it's a binary thing (approved or not). During triage meetings only people attending the meeting vote so it's random how many votes we can have.

So, yes, let's make some assumptions (n=3 or n=2) but let's be flexible. I'd say we let people evaluate (async) the backport but the beta-accepted is applied at the triage meeting. I first want to see if this new way of backport voting gets more interest.

I will post on Zulip that we are starting to run this experiment and ask T-compiler members to help with the voting.

[jieyouxu]

I appreciate your effort to explain the topic exhaustively but this feels ... quite a lot of text for what the backport workflow actually is. I would like to review it to see if we can cut some foliage.

Yes, if there's any way to cut how verbose it is (or idk add some TL;DR), please do leave suggestions!

Second point: I think it's a bit premature at this time to set in stone, with this level of detail, the number of votes to approve backports. Let's not make it look like it's a binary thing (approved or not). During triage meetings only people attending the meeting vote so it's random how many votes we can have.

So, yes, let's make some assumptions (n=3 or n=2) but let's be flexible. I'd say we let people evaluate (async) the backport but the beta-accepted is applied at the triage meeting. I first want to see if this new way of backport voting gets more interest.

Yeah we can leave off the concrete numbers. I only Picked Something™ because they were obvious gaps.

Re. the specific approvals, it was mostly because release found it hard to determine if sth was actually approved or not (for the async workflow). But this isn't a problem if we double-check during sync triage meetings anyway, and specifically adjust the backport-accepted labels!