Feature request: Auto-create a tracking issue for accepted MCPs

[fmease]

Uplifted from https://github.com/rust-lang/triagebot/pull/2066/files#r2133761555.
This proposal is blocked on PR #2066.

I propose that triagebot should automatically create a T-compiler tracking issue over at rust-lang/rust for accepted (compiler) MCPs once their waiting period has passed (right before or after automatically closing the MCP, cc #2066).

Motivation: It would make it less likely for accepted MCPs to fall into oblivion which is a confirmed issue that's been discussed in the past (like maybe a year ago). For example, I don't even know if we have an accurate and up to date list of accepted but still unimplemented MCPs (I remember that there were motions to compile such a lists some time ago).

---

How should the generated tracking issue look like, roughly? Here's a quick mockup:

• Title: Tracking issue for MCP <NUMBER>: <TITLE>
  • NUMBER: The issue number in the rust-lang/compiler-team repo.
  • TITLE: The title of the MCP.
• Labels: C-tracking-issue + T-compiler + B-MCP-approved + S-tracking-unimplemented
• Assignee: (Maybe) the author of the MCP.

Description:

This is a tracking issue for [MCP {number}](https://github.com/rust-lang/compiler-team/issues/{number}).

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps

- [ ] Implement the MCP
- [ ] Adjust documentation

### Unresolved questions

*None so far.*

### Implementation history

*Empty so far.*

[fmease]

In case there's already an accompanying implementation PR over at r-l/r, such a tracking issue would be overkill. Therefore, I also propose the introduction of yet another label (that can also be added by unauthenticated users via triagebot's labeling system) to suppress the creation of such tracking issues.

Bikeshed name: suppress-auto-tracking

[fmease]

Right now, the template is quite bare bones and that is probably okay: The important thing is the existence of a tracking issue itself I would say.

CONS of triagebot-created tracking issues:

• MCP authors who don't have at least GH triage write rights can't modify the description of the tracking issue.
  • However, the compiler MCP template has a section titled Mentors or Reviewers which — if filled out — likely contains people with such permissions meaning triagebot could auto-ping all listed mentors and reviewers in the newly created tracking issue who can then keep modifying the issue description on behalf of the unauthenticated user according to the "update comments" they post in the GH issue
  • We might be able to leverage @bot note for this, idk? I don't know that feature at all.

[fmease]

Does this itself need an MCP 🤔😆

[Urgau]

The "Unresolved questions" section might be a bit problematic, there are MCP which have some unresolved questions bc they are experimentation, I (as a compiler member) feels like we would want to copy those, but I (triagebot member) has no idea how we would do that.

• MCP authors that don't have at least GH triage rights can't modify the description of the tracking issue.
  • We might be able to leverage @bot note for this, idk? I don't know that feature at all.

Notes creates an additional (and special) section on the issue. It's not design to edit an existing section. It's more like concerns. (example here on the clippy repo)

[Kobzol]

In case there's already an accompanying implementation PR over at r-l/r, such a tracking issue would be overkill. Therefore, I also propose the introduction of yet another label (that can also be added by unauthenticated users via triagebot's labeling system) to suppress the creation of such tracking issues.

Bikeshed name: suppress-auto-tracking

I would create a tracking issue even if there is an implementation PR, these are separate things.

[apiraino]

Do MCPs always lead to an implementation? Is this something we can assume it will happen? My understanding (which could well be partially incorrect) of the MCP process is that it is something coming a contributor (inside or outside the Rust project), T-compiler says yay/nay and then the contributor (with a mentor) can start working on that. But it not a promise to deliver anything.

I am unsure about the added value here but at the same time I don't feel a strong no 🤷‍♂

[fmease]

Do MCPs always lead to an implementation? Is this something we can assume it will happen?

I don't know the exact numbers, but I would gauge that maybe ≥95% of MCPs require a r-l/r PR to impl the MCP. I means see for yourself: https://github.com/rust-lang/compiler-team/issues?q=is%3Aissue+label%3Amajor-change. Probably <5% of MCPs represent … process changes or things not representable as changes to r-l/r?

But it not a promise to deliver anything.

I don't know about that. From the original MCP RFC:

The intent here is that if you have a plan to make some "major change" to the compiler, you will start with this process

So it's expected that the MCP author has a "plan to make [… changes] to the compiler". I guess it depends on which definition of the word "plan" you want to use but typically a plan (without any further qualifying adjectives) comes with the connotation (esp. if it's written down / declared in written form) that it will eventually be realized (unless something exceptional happens) (welp, I guess there are many failed plans in reality, so it might not actually have that connotation).

---

Also, in those <5% of cases where the author wants to create a "tentative MCP", they could always just @rustbot label +suppress-auto-tracking as proposed by me here (#2067 (comment)).

[rustbot]

Error: Parsing assign command in comment failed: ...'
' | error: specify user to assign to at >| '

But it '...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[rustbot]

Error: Parsing assign command in comment failed: ...'
' | error: specify user to assign to at >| '

But it '...

Please file an issue on GitHub at triagebot if there's a problem with this bot, or reach out on #t-infra on Zulip.

[Urgau]

But it not a promise to deliver anything.

Even if there is no promise to deliver anything, that doesn't preclude a tracking issue following the MCP. A tracking issue doesn't promise anything either, it's just tracking something.

Do MCPs always lead to an implementation?

No, but as you always say it, there is more than code, sometimes the action is to adjust some documentation, sometimes it's to reach consensus on a topic (and therefor write it down somewhere), ... and if there is no do do, closing the tracking issue would signal that.

[fmease]

rust-lang/compiler-team#892