This is the “meeting thread” for the lang-team meta working group.
I’ll post videos / minutes / summaries in here.
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.)
9 Likes
(edit: I typed this while Niko was typing his summary, so I’m sorry if there’s some duplication here)
I watched the " Lang Team Meta WG 2019.05.02" video today. Really like what you’re all working towards 
I had a few off the cuff remarks:
-
On the topic of Lack of feedback from nightly features, another option would be a lang team newsletter/survey system, asking very specific questions (some open, some closed-form) to regular Rust users who sign up.
As someone who has a vested interest in seeing Rust succeed, I wouldn’t mind receiving a survey every so often, to provide feedback on a specific feature.
If there is an unstable feature that I anticipate to be using a lot in the future, knowing how much focus the Rust team has on stability and backward compatibility, I have a high incentive to voice questions/concerns before it’s stabilised, but I just don’t know when/how that is about to happen, so a newsletter/survey being actively sent to me would definitely go on my “todo” list to quickly fill out at the end of the week.
-
Another interesting point that Jonathan brought up about the Typescript team announcing “beta” releases and asking for feedback using a blog post right before they do a release of a big new feature.
In Rust we do the same, but only announce it on the internal forums (I believe?). We’re underutilising the Rust beta channel by not broadening these announcements. Either via a regular blog post, or newsletter groups.
If we do plan on exposing those beta releases more broadly, I think it should also be more formal, and not by linking to the release notes on GitHub, but making an actual post explaining the features that are going to be stabilised. In a sense, you’re writing the blog post for the final release in advance, with some added context asking for feedback before stabilisation.
-
On the topic on being more structured, having a clear schedule, and having the goals written out for everyone to see. In my experience, for this to succeed, you need someone that has the dedication and time to invest in this.
I realise that’s the whole point of this WG, to invest time in solving these problems (and it was awesome to see so many people actively participating in the meeting). The problem with that is that I’ve seen too many times that a group of people who are interested in A (for example working on Rust itself), realise that in order for A to go more smoothly they need B (for example, a more rigorous process, schedules, documentation, etc), to dive into solving B with a lot of passion, coming up with a solution, but then slowly shifting back to focussing more on A (because it’s why they set out to solve B in the first place), whereas B will still require active involvement to make sure it keeps working.
That active involvement/maintenance can be relatively minimal, such as “reminding people” or “asking them to spend some time on their part of B to get it up-to-date again”, “updating documentation”, etc. But it still requires time to do that, and because it feels rather trivial (and to some, boring) it often ends up at the bottom of your TODO list, whereas I think it’s a vital part of making a process or the collaboration between a group of people work smoothly over longer periods of time.
In other words, I think the whole discussion on solving B is moot (or at least short lived), if you don’t find someone who has the time to invest in making B work over a longer period of time, and who enjoys doing that kind of work.
Also, looking forward to a lot of the RFC process changes being proposed, in particular making the RFCs more holistic in nature 
Yeah, I think this is a really strong point. I was thinking after today's meeting (video, summary coming soon) that to "really do things right" is a lot of work and I probably need to curtail my expectations to get more realistic.
Still, I would like to think that we'll be able to setup a system that allows for some of the "updating documentation, communication, etc" work to be integrated more deeply, and to get folks involved who enjoy doing that sort of thing. Perhaps that's naive of me.
(In other words, I don't think it's realistic to find "one person", but I would like to think that multiple people who enjoy doing this sort of work can become first class members of the team.)
Have you considered treating syntax sugar changes differently from semantic changes?
It’s obviously easier to bikeshed about how the syntax looks like, but also because it should be easier to experiment with, and even implement, syntax sugar without any changes to Rust itself by compiling alternative syntax to the standard one.
2 Likes
I absolutely agree. I guess I'm just slightly more pessimistic on finding such a group of people, specifically those who aren't also tied up with a lot of other Rust/$dayjob related work, and thus will have limited amount of time.
I haven't watched the recording of the latest meeting yet, but the previous meeting attendees were mostly people who (as I mentioned) are very passionate about other areas of Rust, and want to dedicate some time on this topic, to make that other area run more smoothly. The challenge is to get more people involved who truly have (and continue to will) time to invest, and like doing so on this topic.
Granted, it's still early days, so I'm optimistic that the more discussions there are, and the more crystallized the ideas become, the more people might be inclined to jump in and help out, but it would probably be a good idea to set some kind of target "number of outside people" who are starting to help out in X weeks, and if we don't reach that target, do some reflection on what we should change to reach our goal.
It looks like we never posted the minutes from our last meeting on 2019.05.09! This is because we never got time to write up a nice summary. But if you’d like to see the raw minutes and video, you can find them here.
1 Like
There is something delightfully meta about never getting time to write up a summary of a meeting about how to communicate better.
12 Likes
Wait till you see the minutes from this meeting – I think we were up to 3 levels of meta.
1 Like
I cannot view the video. It says “Video unavailable. This video is a duplicate of another YouTube video”
Yeah it looks like I messed things up. The correct link for 2019.05.09 is this video here. I had previously uploaded that (erroneously) as a general lang team meeting.
1 Like
2019.05.30
We started digging into what a “staging process” might look like (see notes at the end as well). @Manishearth raised concerns about trying to do “technical” solutions without also looking at some of the “social” problems, though I think there was ultimately consensus that the two are intertwined in subtle ways (i.e., establishing better processes can enable us to address the social problems as well).
3 Likes
2019.06.06
Summary
We focused on what the output from the “exploration” stage of a working group might look like. We sketched out some examples for the case of error handling. We settled on a rough outline looking roughly like this:
- Problems in and around the space
- describe the problems we are aiming to solve, as precisely as we can
- give representative examples that can be referenced in the solutions
- aim for completeness, even if not everybody agrees it is a problem
- describe the problems we are aiming to solve, as precisely as we can
- Positives and strengths to consider
- things that are working well which might be “imperiled” by some of the solutions
- or just general things that we want to preserve and why
- Solutions
- describe possible solutions
- what problems do they try to address
- relationships between the solutions
- do they build on one another?
- describe possible solutions
- Unknowns and constraints
- list out concerns, things to be resolved
- Roadmap recommendation? Narrative?
- experiments? in particular, can we use procedural macros, nightly builds, or other mechanisms to enable experimentation and try to answer specific questions and ideas.
- this part was the least clear – how much do we ex
We looked a bit at the TC39 homepage and the way that it clearly identifies proposals by stage and had some back-and-forth about how to compare that with our existing set of github pulls.
Homework and next meeting
Before our next meeting, we should:
- Research the TC39 process, for those unfamiliar with it, or other relevant processes.
- Niko would like to try and apply this exploration to
impl Traitor some other example, but this may not happen.
Although this wasn’t discussed in the meeting, next meeting I hope to spend a bit of time digging into other processes to learn more about how they work. In particular probably starting with Chef, to build on some “local expertise”. --nikomatsakis
1 Like
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.