Post

Avatar
I really, truly, wish Rust leadership would just stop trying to create more designs for radical changes in the language. And instead work on finishing things that were half started.
Avatar
I've thought repeatedly about trying to publicly and clearly track RFC's that are approved-but-not-implemented but then been overwhelmed by the amount of work it is to start that lol
Avatar
After being thoroughly nerd-sniped 😅 here's what the Rust RFC tracking issues look like over their history. Caveats: there exist multiple tracking issues for some RFCs due to subtasks being split out, and there are 9 tracking issues with RFC labels but no obvious associated RFC that I've omitted.
Avatar
And to cap off the snipe, a barebones website to host and render the Rust RFC tracking issues graph:
Rust RFC Observerrust.rfc.observer
Avatar
Avatar
I can totally set up go.rfc.observer. Where do Go proposals live and what is their evolution process?
Avatar
github.com/golang/propo... They are issues with tracking labels in github.com/golang/go/is... (and I think there's a GitHub project too. Roughly they go "created (label Proposal)" -> "active (comment saying so and added to minutes)" -> accepted (label Proposal-Accepted) -> implemented (closed).
GitHub - golang/proposal: Go Project Design Documentsgithub.com Go Project Design Documents. Contribute to golang/proposal development by creating an account on GitHub.
Avatar
Okay, first pass is up: go.rfc.observer "Implemented" is any issue closed while labeled Proposal-Accepted, other closures are "Closed". Did the Go Proposal workflow change in late 2015? There's very little label data prior to then. Also, y'all have a lot of proposals! Data fetch takes a minute.
Avatar
Avatar
Good to know, thanks. I can't parse meeting minutes etc yet, gonna need persistence to cache the results so rendering is not horribly slow. As long as the current graph is close enough to the Go ecosystem's expectation, it will do for now.