2019.05.02
Summary
The goal for today was to enumerate the problems we aim to solve, as well as the good points we aim to preserve. The biggest theme that we discussed was the need to improve communication, in a number of dimensions.
Communicating the state of things or our process
A lot of this communication goes from the lang team “outwards” – whether that be to other members of the lang team, or to the community at large.
For example, we felt that it is often very hard to find out the current state of a design and the reasons for the design. This is true for lang-team members as well as people in the public at large. Some examples:
- impl Trait – a number of distinct rfcs that layer on one another, no clear home for the design as a whole. Everything lumped under one feature gate, but some parts are very unstable and buggy, and others “almost work”, and it’s basically impossible to know which is which.
- const fn – this has gotten somewhat better, in that we’ve split up const fn into a number of feature gates and layers.
Particularly for large designs, there is also a need to clearly document and track use cases. For example, with const fn, it’d be great to have examples of the various uses we expect, which would also inform our prioritization.
Capturing motivations, not just design
In general, we ought to document not only the design we wound up with, but the motivations behind that design, and the alternatives that were considered. This is particularly important when we try to extend designs later on.
It would also be useful to look at the past decisions that have been made in Rust and try to “reverse engineer” the underlying values. Some of us have been in the project a long time, but for newcomers to the project, they may not be aware of past precedent around particular points.
Communicating expectations
If you just follow a link to an RFC and don’t know about the Rust project, it’s not very clear how you are supposed to participate. Who can make comments? What sorts of comments? This can intimidate people from participating, but it also results in people repeating the same argument over and over, or making proposals that don’t really fit the moment.
When it comes to process, it would be helpful to make clear what stage a proposal is in and also the expectations at that stage. In particular, early on, we want to be very open to new ideas and exploration, but as we advance through the design, the bar for disruptive changes gets higher and higher.
We often have a lack of clarity about scheduling and other constraints. This has been very prominent with async-await, because it is of such sharp interest to so many people, but it has occurred in other cases. When there is a need to meet a schedule, we need to get better at ensuring everyone agrees to the schedule and clearly enumerating the set of work that needs to be done to meet it.
However, we shouldn’t try to schedule everything. It’s generally better to let things progress at their natural pace, and setting hard deadlines adds pressure that can lead to mistakes or stress. But if we feel that there is little time pressure, that is also something we should state explicitly.
Strictly speaking, final decisions only require consensus from the lang team. However, we do take objections from the discussion thread seriously. Sometimes this leads to confusion about who the ultimate decision makers are. As we grow to working groups, we will also start to get questions like: whose opinion matters more, a team member who has not been actively involved, or a non-team-member who has? Ideally, we should design a system that has enough cross-communication to head off these conflicts before they happen, but it probably behooves us to try and document our rules as well.
Gathering feedback
In general, we would like to be more deliberate in the ways that we gather mass amounts of feedback. As noted above, we are often unable to communicate precisely the kinds of feedback that is appropriate at each stage. Similarly, we need to be able to communicate when we have eliminated options from discussion – and not relitigate those questions.
This topic of feedback extends beyond the design phase. It would be very useful to be able to steer user feedback towards feature we are considering for stabilization or to answer specific questions. Right now, there are a whole mess of features, but it might be nice for us to be able to say “here are the 5 features where we could most use feedback”.
Running more smoothly
We would like to be able to better control our focus and attention – we’d like to be driving things more from the roadmap and our defined goals. We often wind up today in a kind of reactive mode. Some of that is inevitable, since questions arise that must be settled – but some of it is self-inflicted. For example, under today’s process, anyone can open an RFC on anything at any time – it might be nice to limit the introduction of new ideas to specific points in time, and make it more of a two-way conversation. Still, we have to ensure we leave room for serendipity and fresh ideas.
We need to do a better job of coordinating across teams. It often happens that features will have aspects that properly belong to different teams. Having working groups dedicated to particular features should help here, because we can involve people from many teams in that group.
One part of that coordination is capacity tracking. That is, we don’t want to do a bunch of design when we have no plans to implement or document. We don’t generally want to take on tasks we can’t finish. We should be engaging with the compiler team and other teams earlier on, so that implementation and design can proceed in conjunction.
Challenges of moderation and managing disagreements
One of the challenges we see is that our systems are based on consensus and generally assume all people are operating in good faith and with common understanding. This is not always the case. We expect that as we get better at communicating what has already been decided and what is currently under discussion, we’ll be able to establish stronger norms that keep conversations more focused on those topics. Moreover, we’ll be able to more aggressively “moderate out” comments that are going afield (as off topic).
We discussed how, in our system, we have only one formal form of “objection” that a team member can raise – they can block progress entirely. But other consensus systems have more “degrees” of objection. For example, the Consensus Handbook defines a number of other states:
- Block: There are fundamental problems with the proposal. If it is accepted I will struggle to stay part of the group.
- Stand aside: I cannot support this proposal, and I won’t be part of implementing it, but I am not going to block the rest of the group.
- Reservations: I have problems with the proposal I would like to document, but I will go along with it.
Strong points of the existing system
We want to avoid creating a lot of “bureaucratic overhead” for everything. For smaller designs, the existing RFC process can be quite a good fit. Therefore we want to ensure we don’t add too many layers that it becomes an impediment to making small improvements.
RFCs have also been a great entry vector into the project: it’s how boats and Josh came to the lang team, for example. We’d like to preserve (and strengthen!) that quality.
Some early thoughts on improving the process
We would like to see an emphasis on tests much earlier on, even before implementation begins. Tests can serve as a lightweight form of both documentation and tests, and are a great way to communicate the design to everyone.
We would like documenting language features to be the lang team’s job. Too often, we’ve considered that “somebody else’s problem”. But we should be keeping the Rust reference up to date, as well as publishing “explainers” for end users.
We talked about how RFCs could get progressively “locked” over time – e.g., indicating which parts have been decided, and which are still in flux with some kind of annotations. We also talked about how the output of the working group should be the full exploration – including motivations and dead-ends – and not just the end result.
To help ensure capacity, we would like to find the people we need early on. That is, we won’t go deep into the design of something (at least for larger things) until we have lined up implementation, review, documentation.
Balancing meta discussion with progress
One question that arose was how much we need to balance organizational debt against progress. On the one hand, we don’t want to stop everything to pursue “meta” pursuits. On the other hand, we are at a point where we don’t have a lot of essential additions. It seems plausible that we can do one or two things, and do them carefully, using them to help drive and develop the process.
What’s next?
This was just our first meeting. In the next meeting, the plan is to try and settle on some concrete objectives of what things to try and specify first.
(We also decided we might try to find a different time for our permanent meeting, fyi, so I’ll post a doodle soon.)