Description
For context, a pre-MCP discussion happened over here: rust-lang/triagebot#2067.
Proposal
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 (either right before or right after automatically closing the MCP).
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 (#t-compiler > Unimplemented MCPs? @ 💬; from 2024). 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).
Additionally, I tentatively propose the introduction of a label called suppress-auto-tracking (bikesheddable name) to suppress the creation of such a tracking issue which the author can apply at their discretion if they consider a tracking issue to be overkill for their specific MCP for whatever reason (e.g., in case they already have an accompanying implementation PR over at r-l/r and it's clear that that single PR is sufficient to fully realize the MCP). Of course, users with insufficient privileges ought to be allowed to add it via triagebot's labeling commands.
One small issue of triagebot-created issues is the fact that MCP authors who don't have at least GitHub write rights can't modify its description (e.g., to post updates). However, triagebot could simply auto-ping the MCP seconder (who has to have these permissions) in the newly created tracking issue (and optionally all people listed in the MCP section titled Mentors or Reviewers). They can then keep modifying the issue description on behalf of the insufficiently privileged user according to the "update comments" they post in the GH issue.
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.*Mentors or Reviewers
Process
The main points of the Major Change Process are as follows:
- File an issue describing the proposal.
- A compiler team member or contributor who is knowledgeable in the area can second by writing
@rustbot second.- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
-C flag, then full team check-off is required. - Compiler team members can initiate a check-off via
@rfcbot fcp mergeon either the MCP or the PR.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a
- Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.
You can read more about Major Change Proposals on forge.