# Lang Team Meta Working Group **URL:** \ **Category:** language design\ **Created:** [May 2, 2019, 9:18pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989 "2019-05-02T21:18:44Z")\ **Posts on this page:** 15\ **Page:** 1
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 2, 2019, 9:18pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/1 "2019-05-02T21:18:44Z")
This is the “meeting thread” for the lang-team meta working group. I’ll post videos / minutes / summaries in here. ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 3, 2019, 9:41am UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/2 "2019-05-03T09:41:25Z")
# [2019.05.02](https://github.com/rust-lang/lang-team/blob/master/working-groups/meta/minutes/2019.05.02.md) - [Video](https://youtu.be/IiAieCpAA1g) - [Paper document with live notes](https://paper.dropbox.com/doc/T-LangWG-Meta-2019.05.02--Aca1auzeySClzoCkHEHhY8HfAg-CLZabEcgkroWWNEEcnneL) ## 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](https://www.seedsforchange.org.uk/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.) ---
**Author:** ![JeanMertz](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jeanmertz/32/4536_2.png) [@JeanMertz](https://internals.rust-lang.org/u/JeanMertz)\ **Post date:** [May 3, 2019, 9:56am UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/3 "2019-05-03T09:56:16Z")
(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](https://www.youtube.com/watch?v=IiAieCpAA1g)" video today. Really like what you’re all working towards 🎉 I had a few off the cuff remarks: 1. 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. 2. 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. 3. 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. Also, looking forward to a lot of the RFC process changes being proposed, in particular making the RFCs more holistic in nature 👍 ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 9, 2019, 5:02pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/4 "2019-05-09T17:02:15Z")
> [@JeanMertz](#): > > 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. 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.) ---
**Author:** ![kornel](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kornel/32/2711_2.png) [@kornel](https://internals.rust-lang.org/u/kornel)\ **Post date:** [May 9, 2019, 5:46pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/5 "2019-05-09T17:46:14Z")
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](https://internals.rust-lang.org/t/pre-rfc-first-class-support-for-compile-to-rust-languages/7610). ---
**Author:** ![JeanMertz](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jeanmertz/32/4536_2.png) [@JeanMertz](https://internals.rust-lang.org/u/JeanMertz)\ **Post date:** [May 9, 2019, 7:06pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/6 "2019-05-09T19:06:26Z")
> [@nikomatsakis](#): > > (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.) 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. ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 30, 2019, 2:56pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/7 "2019-05-30T14:56:00Z")
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](https://github.com/rust-lang/lang-team/blob/master/working-groups/meta/minutes/2019.05.09.md). ---
**Author:** ![Eh2406](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/eh2406/32/4839_2.png) [@Eh2406](https://internals.rust-lang.org/u/Eh2406)\ **Post date:** [May 30, 2019, 3:45pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/8 "2019-05-30T15:45:27Z")
There is something delightfully meta about never getting time to write up a summary of a meeting about how to communicate better. ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 30, 2019, 4:18pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/9 "2019-05-30T16:18:51Z")
Wait till you see the minutes from this meeting – I think we were up to 3 levels of meta. ---
**Author:** ![Pauan](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/pauan/32/3006_2.png) [@Pauan](https://internals.rust-lang.org/u/Pauan)\ **Post date:** [May 30, 2019, 5:06pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/10 "2019-05-30T17:06:17Z")
I cannot view the video. It says “Video unavailable. This video is a duplicate of another YouTube video” ---
**Author:** ![newpavlov](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/newpavlov/32/3290_2.png) [@newpavlov](https://internals.rust-lang.org/u/newpavlov)\ **Post date:** [May 30, 2019, 5:12pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/11 "2019-05-30T17:12:02Z")
I think correct link is this [one](https://www.youtube.com/watch?v=aOdT6U_gTaw). (or this [one](https://www.youtube.com/watch?v=5iiWsbOeYbI), I am not sure) ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 30, 2019, 5:16pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/12 "2019-05-30T17:16:02Z")
> [@Pauan](#): > > 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](https://www.youtube.com/watch?v=5iiWsbOeYbI). I had previously uploaded that (erroneously) as a general lang team meeting. ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [May 31, 2019, 8:23pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/13 "2019-05-31T20:23:19Z")
# 2019.05.30 - [Video](https://youtu.be/EWMxvNiBZTA) - [Minutes](https://github.com/rust-lang/lang-team/blob/master/working-groups/meta/minutes/2019.05.30.md) 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). ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [June 6, 2019, 9:02pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/14 "2019-06-06T21:02:18Z")
# [2019.06.06](https://github.com/rust-lang/lang-team/blob/master/working-groups/meta/minutes/2019.06.06.md) - [Video](https://youtu.be/UYrq3eINGUM) - [Dropbox paper](https://paper.dropbox.com/doc/Meta-WG-2019.06.06--Aeh5qqFUFXz4Usd_a899bZKGAg-VO3EBc6lEdNunBh6hxGfn) # Summary We focused on what the output from the “exploration” stage of a working group might look like. We [sketched out some examples](https://paper.dropbox.com/doc/Meta-WG-2019.06.06--Aeh5qqFUFXz4Usd_a899bZKGAg-VO3EBc6lEdNunBh6hxGfn#:uid=330091089397131641914243&h2=Error-handling) 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 - 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? - 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](https://github.com/tc39/proposals) 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](https://github.com/rust-lang/rfcs/pulls/). # Homework and next meeting Before our next meeting, we should: - Research the [TC39 process](https://github.com/tc39/proposals), for those unfamiliar with it, or other relevant processes. - Niko would like to try and apply this exploration to `impl Trait` or 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 ---
**Author:** ![nikomatsakis](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/nikomatsakis/32/5410_2.png) [@nikomatsakis](https://internals.rust-lang.org/u/nikomatsakis)\ **Post date:** [September 4, 2019, 9:15pm UTC](https://internals.rust-lang.org/t/lang-team-meta-working-group/9989/15 "2019-09-04T21:15:06Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.