2018-10-26

We had our first T-compiler steering meeting today! What follows is a summary of the major points raised during the discussion. If you’d like to read the detailed minutes, please see the Zulip chat log. I’ll insert links here and there into that log where appropriate, if you want to see the original comment.

To start, before the meeting we did a survey asking folks what they thought worked well and what needed improvement in and around with the compiler team. I summarized those results in a Google doc, which shows the things people wrote and how often (in the case of duplicates). We then voted on what to talk about (that’s what the columns with the x are).

In the end, we opted to discuss the most popular topic, which sort of subsumed a number of entries:

• “how to plan what to do and expose our plans”
  • hard to answer “what to do next” or “how can I help” (8)
  • public roadmap (4)
  • hard to do high-level design + planning and not just triage (3)
  • no central place to get “big picture” of what’s going on (3)

(Originally, we thought we’d cover many more things, but that did not turn out to be true. =)

To start, there were a number of comments on the survey (and in the meeting) to support the idea that Working Groups are an effective way to organize, particularly for newcomers, but it works best if we focus the WG on a concrete topic (e.g., NLL). WG leaders ought to be actively triaging and looking for places to help people get involved, and so they can be good ones to answer the question of “what to do next”.

We can also use WG as an organizational tool to expose the “big picture” of what’s going on. In addition to WGs, though, it would be good to just list out the specialities of compiler team contributors, as well. WGs can also be an organizational axis for labels with the WG focusing creating a steady supply of E-mentor issues.

However, this places a big burden on WG leaders. One thing we noted is that having more than one leader is good and that this itself can be a mentoring opportunity.

In terms of getting people involved, the findwork site was raised, as well as the difficulty of keeping it up to date (perhaps WGs can help?).

We pointed out that when we do our planning at the next Rust All Hands, we can try to figure out WGs then.

We discussed some how the diagnostics efforts could be increased.

We discussed the rustc-dev-guide as well as the NLL contributor YouTube videos and ways to improve them. One solid thought was that we might want to create a rustc-dev-guide WG (which has its own zulip topic here). We talked in particular about how both experienced folks and newcomers can contribute there.