meta: notify #t-rustdoc Zulip stream on backport nominations

[fmease]

In July '23, it was decided to handle rustdoc-specific backport nominations in t-rustdoc meetings going forward (Zulip announcement). However, t-rustdoc meetings are far too infrequent for them to address nominations on time (contrary to the weekly t-compiler meetings).

Hence GuillaumeGomez and I came to the conclusion that {beta,stable}-nominated rustdoc PRs should be dealt with on a case by case basis, e.g. on Zulip.

This PR attempts to partially automate this process. Sadly, triagebot is not quite as flexible has I've hoped. Blocked on triagebot improvements (see the FIXMEs in this PR). (Fixed in rust-lang/triagebot#1791).

r? GuillaumeGomez

[GuillaumeGomez]

Approving the PR just to show my support as I think this is a very nice add! Please ping me once the other blockers have been solved.

[Urgau]

Maybe instead of hijacking the beta-nominated Nominated for backporting to the compiler in the beta channel. label rustdoc could use it's own label beta-rustdoc-nominated ?
This would have the advantage of being clearer about how should be responsible for the backport but also may avoid many unnecessary ping as many PRs have both T-compiler and T-rustdoc labels.

EDIT: Same for I-nominated which should have a rustdoc variant I-rustdoc-nominated (like I-types-nominated The issue / PR has been nominated for discussion during a types team meeting. for the Types team)

[fmease]

Hmm, I'm not super convinced that we need to introduce rustdoc-{beta,stable}-{nominated,accepted} (whatever the naming). I think it would needlessly complicate the backporting process as T-release members would have to remember to not only look for {beta,stable}-accepted but also for rustdoc-{beta,stable}-accepted. It's not the end of the world but I'd say it can be avoided.

There are only 7 T-{rustdoc,compiler}beta-accepted PRs out of 77 T-rustdocbeta-accepted PRs which amounts to 9.1%, meaning not that frequent (obviously not accounting for rejected nominations here). We could also update triagebot to support exclude_labels = ["T-compiler"] for notify-zulip hooks if we wanted to rule this out anyway.

Although the idea of creating I-rustdoc-nominated is pretty good on its own. While we could teach rustdoc reviewers to add I-rustdoc-nominated to {beta,stable}-nominated PRs, personally speaking I much prefer automation if possible.

[Urgau]

I'm not proposing to introduce beta-rustdoc-accepted just the nominated variants {stable,beta}-rustdoc-nominated as {beta,stable}-accepted is already IMO agnostic.

[Mark-Simulacrum]

T-release looks for both nominated and accepted labels, any changes here are somewhat painful (especially since backports are currently manual, and expressing the necessary combined query in GitHub would be... difficult).

You can read more about the process here - https://forge.rust-lang.org/release/backporting.html

So even just the nominated labels changing would be enough to lead to additional pain for the release team.

[fmease]

I've created a triagebot patch here: rust-lang/triagebot#1791. If it gets accepted it will unblock this PR. Merged.

[rustbot]

triagebot.toml has been modified, there may have been changes to the review queue.

cc @davidtwco, @wesleywiser

[GuillaumeGomez]

Thanks for working on this (again)! 😄

[fmease]

PR has been approved.
@bors r=GuillaumeGomez rollup

[bors]

📌 Commit 8f3d7fe has been approved by GuillaumeGomez

It is now in the queue for this repository.