Lang Team Meta Working Group

language design
3

(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 :tada: 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.

    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.

  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.

    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.

  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.

    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 :+1: