Since I'm coming pretty late to the #Rust2018 party, most of the things I wanted to say have already been said!

Ashley's kick-off post was kind of a meta-#Rust2018 for me, calling for us to experiment with new ways to get community feedback in Rust. I personally really enjoyed all of the energy in #Rust2018, and hope that we continue to experiment on this front.

I really loved Julia's post, both for enumerating so many ways that Rust has become easier to use since last year, but also for showing that marketing Rust to people who have never written low-level code before need not conflict with marketing Rust to people who want a better C++ (and other audiences too!).

I liked both Steve's post and Nick's post for showing that we're already on track to have a great 2018, as long as we stay focused on shipping and polishing what we already have in flight. We can have a "boring year" that is anything but boring.

I also enjoyed withoutboats' post, both for capturing many of my personal technical goals, but also for crisply capturing what has so excited me about Rust since I started using it for the first time in 2013:

I want to see the barrier to entry for “systems programming” to fall dramatically. Rust is not just a language that forces you to follow best practices (“eat your vegetables”), it is an automated assistant that helps you to organize and manage the complexity of the project that you’re working on. When a programmer with experience in higher level languages begins to use Rust, the space of programs that they now have the technology to write expands dramatically. I want to see the kinds of programs that emerge when systems programming knowledge is widespread and easy to acquire, when anyone with an interest can take the skills they already have and use it to start tinkering in domains that once might have seemed inaccessible to them, such as operating systems, network protocols, cryptography, or compilers.

(emphasis mine)

I'll leave the exhaustive summarizing to folks who are better at it than me, but suffice it to say that there are many more posts that resonated with me strongly.

What follows is my own contribution to #Rust2018.

Exploring New Contribution and Feedback Models

Since last summer, we saw two initiatives that pushed us out of our historical contribution-style comfort zone: the "impl period" and this #Rust2018 call for blog posts.

Both initiatives brought in a ton of new people into areas of the process that they weren't already very involved in. The impl period brought in interested contributors who didn't previously have a good way in, and puts many new people on a path to project leadership. #Rust2018 gave many people who felt daunted by the volume and speed of the Rust RFC process an opportunity to weigh in on the direction of their project.

I would like to continue to explore these ideas througout Rust.

The RFC process has historically provided a clear way for ideas to be proposed, vetted, refined, and eventually approved for implementation. It offers a process that applies to team members and outside contributors alike, ensuring that even members of the Rust core team flesh out proposals and subject them to the same level of scrutiny as any other member of the community.

At the same time, the RFC process, by virtue of its sheer volume and speed, is not very accessible to production users of Rust (like me). Production users have a lot of day-to-day experience with large applications written in Rust, but not much time to participate in today's RFC process. In many cases, especially for significant proposals, something closer to the #Rust2018 process would work better for production users of Rust than a long-running, fast-moving conversation.

That doesn't mean I think we can do away with conversations about language proposals, and indeed the #Rust2018 blog posts spawned many very interesting conversations, not all of which were easy to find in this first, limited experiment.

That said, I would like to see us explore ways to use what we have learned from the impl period and #Rust2018 to get broader feedback and contribution, while being careful to avoid losing the benefits and stability of the existing system.