I must have missed an e-mail in my inbox, because recently I started seeing people publish Rust 2020 blogposts so I thought, why not. I haven't been incredibly involved in the development of Rust in the last few months, (navigating the delicate balance of being self employed, working on free software and not burning out) but I feel like that might change again. And also, I still have feelings about software.
This post was also largely inspired by my friend XAMPPRocky's post, as well as attending NixCon a few weeks ago, and generally interacting with the NixOS RFC process.
What even is an RFC?
An RFC, or "request for comments" is a mechanism by which a group of
people can get feedback from a wider community on proposed
changes. The idea is that a written proposal outlines a change's
scope, implementation details, rationale and impact on the ecosystem,
then people make comments on the proposal. Usually by the time that
everybody has stopped shouting at each other, the RFC is ready to be
merged, meaning it is accepted and its vision can be implemented.
This can either be implementing a feature, or removing unstable
flags from it.
Unfortunately I'm not being too flippant here: the procedure of how an RFC goes from "proposed" to "accepted" is very vague and can depend on a lot of factors. Needless to say, this can also be the source of a lot of conflict in a community.
Rust has had an RFC process for a few years now, and most, if not all decisions to the language and ecosystem have gone through it, and the community feedback it entailed. Some go largely overlooked, like this one that I co-authored at the Rust All Hands 2018 in Berlin (it's fine, I understand), others get hundreds of comments. This often results in no meaningful conversations, in large parts because it's hard to have a discussion with 1000 people, and in other part because GitHub is a terrible platform to do anything on (sequel hook).
RFC chaos
I remember this issue first coming up in the module refactoring debates and the three (?) RFCs that were in total created before everybody felt happy enough about it. These were the first large RFCs I witnessed while being kinda part of the community. Many of the people who were involved in them talked about how stressful it had been and I think they might also be the first time that the RFC process, the way that the Rust project implemented it, started showing limitations of scale.
The fact that an RFC is proposed, with no real structure or framework on how to continue afterwards means that either feedback is chaotic and iterations on the design can seem arbitrary, or on the other hand some RFCs remain open for years, in limbo, where nothing really happens on them. Both aren't great outcomes, only add to stress levels of the people who were involved in writing them, and generally just slows down our decision making process.
As XAMPPRocky wrote in her blog post:
When 1.0 launched there was ~30 members of The Rust Programming Language, now in 2019 we have ~200 members. This is nearly 7x the amount of members, yet we've changed very little to be able to adapt to this growth.
While she was talking about how many people get paid for Rust, I feel this is also applicable to the way that we make decisions. Many people wrote about the RFC process for their Rust 2019 posts in rather vague terms, including myself. Well, I'm mentioning it again, because I feel like we should try something concrete.
Shepherds and an RFC committee
The NixOS project has two concepts in their RFC process which I think are valuable and that the Rust project would benefit from: RFC Shepherds and the RFC steering committee.
The RFC steering committee is a group of between 5-6 people, assigned for a year to oversee any new RFC, make sure that shepherds get assigned to it, and also keep tabs on progress that is being made. Are shepherds regularly (in whatever interval they deem appropriate) meeting to discuss the RFC, is feedback being taken into account by the authors, and how is the discussion generally going?
They do not need to actually understand where the discussion is heading, but make sure that a discussion is happening. This would solve the problem of RFCs remaining open for years, without getting any further feedback and un-cluttering the PRs page of open RFCs. RFCs that were forgotten about by their authors or that the community has largely moved on from can be closed/ rejected. It can also give closure to people who have written RFCs that was never rejected, but not accepted either (again, I'm cool, don't worry).
RFC shepherds are then assigned to an RFC (3-5 people) to actually oversee the discussion and consolidate feedback into changes that can be made on the RFC. They are also responsible for regular (again, up to them how regular) meetings discussing the wider implications, as well as small details of an RFC, usually on a video call, taking notes for people who can't attend to read up on afterwards.
An important note here: shepherds don't have to be part of a team that would otherwise oversee the development of a feature (like lang or compiler) and instead can be any community member who feels like nominating themselves or who is nominated by someone else. The idea is that everybody should be involved in overseeing incoming RFCs.
Governance WG and a new process
Generally, I think we all know that the RFC process needs to change. It has a bunch of problems that have lead to people physically and mentally burning out while contributing to Rust. And, as XAMPPRocky mentioned in her post, sustainability is important for Rust to remain a healthy project, 5, 10 or 15 years down the line.
I haven't followed a lot of progress from the governance workinggroup, but reading their charter and some of the proposed RFC stages might address some of the issues in the process. I feel that introducing a new RFC governance body (a set of people who rotate) as well as the concept of RFC shepherds would be beneficial to the Rust project as a whole, and anyone who's involved in any RFC related discussions in the future.
There's some tooling issues to address as well, but I feel those are second to the social ones.
Distributing Rust code
Wow, yea this was supposed to be a post about Rust 2020 and my personal roadmap. While I would love to be involved co-authoring an RFC on changing the RFC process in the ways that I propose in this post, there's some personal projects I want to get going as well.
At the beginning of the year I told myself that my SQL migration crate
barrel would see a 1.0 release by the end of the year. This is
looking less and less likely, but I want to at least get close to
it. And then, next year, there will be a 1.0. There's a bunch of
improvements to the crate itself, as well as compatibility with other
crates (such as diesel and other migration toolkits), I want to make.
There's clap 3.0 things that are happening although maybe those will
all be done by the end of the year. Who knows?
But mostly, I want to address a pain point in application packaging. Over the last year I've been tricked into maintaining a Linux distribution, NixOS. And while I'm not that involved in the development of it, there's some things that often come up with packaging Rust applications that could and should be better.
Mostly this is about applications, written in Rust, that want to distribute artifacts other than their binaries as well. Be that generated man pages, default configuration, or static files for a website. Currently this process is entirely up to the packager of an application and relies heavily on the application in question having good documentation. This is also a problem for all Linux distributions, not just NixOS.
Enter cargo-dist, a tool that can be used by a project to easily
declare exportable artifacts and provides a way to tell an external
packaging tool (such as nix, or dpkg) where to copy files to make
a complete, working application. It steals borrows some
concepts from autotools, using a PREFIX and several paths that
artifacts can be copied into. This way a Rust application can easily
be made into a package by calling cargo dist, which internally does
a release build, and exports required artifacts to the appropriate
places.
All of this is pretty WIP and local on my laptop right now. But I would love to finish it soon, and see projects in 2020 adopt this as a standard to distribute files for Rust packaging.