Update merged RFCs after implementation has been completed

[MajorBreakfast]

When reading merged RFCs I often wonder whether the proposal has been fully implemented yet and if and how the implementation differs from what was outlined in the RFC.

It’d be great if RFCs where updated with a quick summary about how the implementation went after the implementation has been completed. I propose to add this as a final step to the existing flow for changes to the language via RFC.

Does this make sense? I’m looking forward to your comments!

[Ixrec]

My understanding was that all accepted RFCs link to a tracking issue, the tracking issue should have a regularly updated status summary at the top, and the tracking issue will only get closed after the feature is fully implemented and stabilized. Is that good enough? Do we just need to change the RFC template to make it more obvious to look at the tracking issue for this information? (I feel like I’ve seen many tracking issues where the status was very out of date, but that’s a slightly different discussion)

[MajorBreakfast]

@Ixrec I know that there is a tracking issue. I also like its placement in the RFC template. Here are the reasons why I want RFCs to be updated with a “status” and “implementation differences summary”:

• Currently there is no indication whether the implementation has been completed. ATM you have to click on the tracking issue to see the implementation status. When casually browsing through the RFCs on http://rust-lang.github.io/rfcs/ this extra step is a bit annoying
• Sometimes the actual implementation differs. In that case the RFC contains outdated information. A summary about the implementation differences would make the reader aware of that.

[MajorBreakfast]

To be precise: It’d suffice if the updated RFC says the “implementation has no differences to the RFC” or “has minor/major differences” and refer to the tracking issue for details. Or, in case there was a follow-up RFC, it should refer to that other RFC.

[mpol]

Would using a badge - eg. - to at least see the tracking issue status at a glance be useful here?

[MajorBreakfast]

@mpol Good idea!

Of course such a badge doesn’t indicate whether the implementation went smoothly once the tracking issue is closed. But the badge is a clear indicator that the implementation is still in progress while the issue is open.

[Centril]

My initial reaction was that this would take too much time away from other things; but the “implementation has no differences to the RFC” seems doable, .

[Tom-Phinney]

Currently there is no indication whether the implementation has been completed. ATM you have to click on the tracking issue to see the implementation status. When casually browsing through the RFCs on http://rust-lang.github.io/rfcs/ this extra step is a bit annoying

This lack of readily-apparent RFC completion status has bothered me a lot. There are currently 390 RFCs listed on the RFC summary page cited above. Are these all open RFCs? If not, could an icon be appended to each entry in the left-hand summary column that indicates whether the RFC 1) has been closed or 2) is still being worked? That would assist potential contributors when they look for some ongoing area of work where they might be able to help.

[steveklabnik]

I’m of two minds about all of this. I can certainly see that it’s useful, but at the same time, RFCs are not a spec; they’re a tool for consensus. Doing this right basically means coming up with a spec. Which should ultimately be the reference, not RFCs.

[Tom-Phinney]

Do you have an alternative suggestion that would provide people who have some time to devote to Rust’s evolution with a succinct list of the current areas where such contributions could conceivably be of value?

[steveklabnik]

We have those places already, this is about expanding that information to another place. If I had to do something, I’d vote for the badge showing that the issue is open or closed; that’s the most important bit and accomplishing it is the least effort.

[tmccombs]

Doing this right basically means coming up with a spec. Which should ultimately be the reference, not RFCs.

How about instead of updating the RFC part of closing the tracking issue is adding documentation to the reference (If that isn’t already the case), and maybe adding a link to the applicable section of the reference to the RFC.

[scottmcm]

How about instead of updating the RFC part of closing the tracking issue is adding documentation to the reference (If that isn’t already the case)

“Updating documentation” is already part of the stabilization process, yes: https://forge.rust-lang.org/stabilization-guide.html

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.