These reports will likely grow over time, but one of the main things they are doing – starting now – is announcing that RFCs or unstable features are going into a final comment period, prior to a final decision being made. This period lasts for one week (i.e., until the next status report). Several RFCs have moved that way already. We’ll also leave comments on the RFCs themselves, for those tracking the repo.
These reports each include a generated dashboard that tracks the RFC and feature implementation pipeline. The information in the dashboard is somewhat incomplete right now: it includes all of the open RFC PRs, but not all of the issues. We’ll be working through triaging the backlog of RFCs and issues in the coming weeks.
We’re using T labels for teams: T-libs, T-lang, T-compiler, T-tools.
We’re using P-high to identify high priority issues in rust-lang/rust (which are usually bugs), and for issues in rust-lang/rfcs (feature requests).
We’re using B-rfc-approved in rust-lang/rust to track RFCs that have been approved.
In the past, the tracking issue generated from an RFC would be closed once the feature was implemented. We’re now planning to keep these issues open until the feature is stabilized. That will give us a single place to track the progress of a feature once its RFC has been accepted – and the tracking issue is where people will leave comments for the final comment period.
Should the “*-team status reports” be parceled together in one mega-thread per-week? If the core team announcements are any indication, they are generally very low traffic. Also most discussion is generally better directed towards a different location (e.g. the PR/RFC of interest).
Great idea. I think it’ll still be easier if we break each report out as a separate markdown file (just in terms of actually creating/maintaining the reports), but we can make a joint post each week with the links.