Popular posts

Also, to expand a bit on this question, how do you interact with people who have a good intuition when it comes to language ideas, but would not translate these ideas into a formal RFC form due to fear of general lack of spec writing skills? There are plenty of people out there who are better at thinking or coding than technical writing.

One thing we're trying out this year is the "impl Period"; that is, there's a moratorium on new RFCs at the end of the year. This, combined with our yearly roadmap, helps us focus on shipping, rather than solely paying attention to new proposals.

We often try to prioritize RFCs based on user feedback; that is, if the lack of something is causing a lot of pain, we put it very high up. More theoretical stuff is only really considered in the context of "how does this solve real problems people have with Rust today".

Regarding intuition, people will often work with others to write up RFCs, and the whole point of the review process is to improve the spec before acceptance.

Thanks!

I love this question; it really hits on one of the biggest challenges in my day-to-day life.

So first off, OSS if done right is fundamentally chaotic. People are coming and going, have their own goals and angles, and somehow the project needs to turn all of that energy into a coherent direction. It's not easy! And you can't do it perfectly.

That said, what we've found this year in the Rust community is that the best thing we can do as a community is:

• Set out various rhythms. We have things on a yearly cadence, a quarterly cadence, a six week cadence. Having these "seasons" to the work that happens helps you stay focused and not feel like you're dealing with an endless slog.

• Be very clear about goals for a given part of the cadence. For example, each year we have a roadmap that's decided on with broad input and driven by a bunch of data (like the survey). Throughout the year, the various Rust teams keep coming back to this roadmap, prioritizing things relative to it and making sure we're making steady progress.

So the principle is that, on the one hand, you want to allow for that magical OSS serendipity, where someone amazing unexpectedly shows up and hands you something that might not have been on the roadmap, but is super valuable. But on the other hand, you want to have some sense for overall direction and priorities, so that you can make sure the most vital improvements are actually landing.

The Rust community is very much still on a learning curve here. I think this year has shown a lot of success around these processes, but also plenty of failures, and I'm hoping for 2018 to reboot a bunch of aspects of how we operate to try to hit this balance better.

how do you interact with people who have a good intuition when it comes to language ideas, but would not translate these ideas into a formal RFC form due to fear of general lack of spec writing skills?

Another incisive question!

In general, the Rust community strongly believes that there are many different kinds of valuable contribution, and strives to enable people to bring their unique skills to bear.

This is an area where I'm super proud of what we've done with Rust. There are folks who have written extremely important language design RFCs who don't know the first thing about the compiler. Some of them are now members of the formal language design team!

As to your question about formal spec-writing, we offer a lot of venues for people to pitch "pre-RFC" ideas -- whether on our discussion forum or IRC. Generally we try to pair up folks with complementary skills but a common goal, and deliver things that way. It can be hard to manage, but it works!

Thanks again! The way you phrase it, managing a large-scale public open source project sure sounds like a good balance of challenging and exciting!