Design meeting: Discuss improvements to stabilization procedures

[traviscross]

Summary

@jieyouxu:

Hi all, T-compiler had some internal discussions about our current feature stabilization procedures, especially if a feature stabilization is a cross-team consideration.

For instance, we may want to improve or add a Stabilization Checklist (for example: documentation, test coverage, FCP/sign-off by relevant teams, FIXME searches, outstanding issue searches, sufficiency checks / double-checks by relevant "owners").

A concrete concern that spawned the above idea is that stabilization PRs are very hard to review -- to the reviewer, it can just seem like "flipping some gates" and "mechanically changing and reblessing a few tests".

Example feature stabilizations where our project-level cross-team stabilization procedure doesn't seem as good/coherent as it can be:

• Stabilization of #[coverage] attribute: Stabilize #[coverage] attribute rust#130766
• Stabilization of #[derive(CoercePointers)]: Stabilize derive(CoercePointee) rust#133820

To be very clear: this is not intended to point blame at any specific individual nor team, but moreso that cross-team stabilizations don't really have a project-level coherent procedure, that helps to make sure that what we stabilize are what we-as-a-project are happy with. We would benefit from having a more refined stabilization procedure that's less confusing for everyone :3

About this issue

This issue corresponds to a lang-team design meeting proposal. It corresponds to a possible topic of discussion that may be scheduled for deeper discussion during one of our design meetings.