At the meeting the subject of "how do we get people to implement things?" came up. Remember that This Week In Rust has a "Call for Participation" every single week. It's often for crates.io crates, but there's no reason that rust language work can't also be posted there for more people to become aware of.
It's not just implementers, but also T-compiler reviewers
(people with r+ who understand the code more generally)
compiler implementers become compiler reviewers and the cycle continues :)
That is one great point.
Another is that we're at 5,000+ issues and 210 PRs, so I suspect there's a lot of work to be done just getting things to a place where it can be reviewed at all. And if reviewers are doing work writing instead of reviewing it slows down the overall pipeline.
So, without letting code quality drop, it's probably wise to try and get more people working on the compiler so that we have a situation of "too much written and waiting on review" instead of "too much not even written yet".
I'd definitely prefer to be waiting on review than waiting on implementation
because even if someone gives up waiting for a review, their code is still available for someone else to pick up later down the line
and I think we're fairly good at reviewing at the moment, especially small to medium PRs
I'm torn between two impulses, and I haven't figured out what I think yet.
On the one hand, I find our current "unbounded queues" setup kind of stressful and overwhelming. It's hard to track what's going on. I think things kind of get lost in limbo. Sometimes a lot of work goes on into an RFC, but there is nobody to implement, and the design just sits, and I think that leads to downstream problems. I'd prefer -- especially for larger projects! -- that we tried not to take on something we don't intend to finish. I'd prefer if we had some notion of who is going to do implementation and review before we take on big things.
On the other hand, I see that the current setup is in some ways natural for an open-source organization. There are smaller changes that I think would just never happen if we drove things in an overly top-down way. And you have things like the
unwrap() work that @anp is tackling now, where the initial design was done last year, and yeah it sat around, but now @anp is doing it, and we're all very glad that this is getting done. If we'd been too much of a stickler around provisioning before-hand, maybe it'd be done already, but maybe we wouldn't even have an RFC.
So I don't quite know what to think yet.
I wonder if we could get some help, via This Week In Rust or similar, to get a comprehensive list of "accepted but not implemented RFCs", as well as of "implemented but not stabilized RFCs".
Maybe just create labels and assign them to the tracking issues?