I want to propose an inaugural “compiler steering committee meeting”. This meeting would be held every 6 weeks, right after each release.
Unlike the existing triage meeting, the purpose of this meeting is to be “proactive” – basically to take a look at the priorities for the upcoming release, take stock of where we are with respect to our larger goals, and make sure we are on track. It would also potentially be a place to bring up other longer-term topics.
Like the existing triage meeting, it would be an open meeting, with anyone welcome to attend. However, I would like to strongly encourage compiler team members to attend if at all possible. Also like the existing triage meeting, it would take place on Zulip.
The next release is Oct 25, a Thursday. I propose we hold the first such meeting on Friday, Oct 26 from 10am-11am EST (same time as the existing compiler meeting).
I take it the term “Steering Committee” is just meant to convey intent about the goals of the meeting itself, and is not meant to imply that there is a different subset of the compiler team labelled the “Steering Comittee” ?
Maybe just call this a “Steering Meeting”?
(I’m trying to come up with some sort of cutesy alternative name… perhaps inspired by games like RoboRally or Mechs vs Minions where you don’t “Steer” so much as “Lay Down a Program and Watch It Fall to Pieces”)
Honestly, the difference between quarterly and every 6 weeks is almost immaterial: one is twice as frequent as the other, but both frequencies are infrequent enough that they shouldn't be disruptive for most
I think not, at least not initially. I would like to draw up a tentative agenda in advance though — that might help you to decide. Guess we'd have to get on that =)
Probably I should just change that to yes, but maybe a "not quite yet"? In general, I would like to see us start to become more purposeful and deliberate in our planning and action. We've often done this in times of great need, e.g. with the Rust 2018 standup meetings and things, but it's hard to sustain.
I would like to see us moving towards a place where we have "big goals" that we are moving towards, and that we have regular check-ins that discuss our progress towards those goals. If we're not making progress, then we can ask whether they are the right goals, etc.
I think this makes sense to do within an individual team but also at higher-levels (e.g., "intra-team"). But the nature of the discussion will change as we move up — it might make sense to do that after we get a handle on what a team meeting looks like? Not sure.
I am creating a calendar event for this meeting. If you would like your e-mail added, send me a private message. (Maybe we need a Rust Teams Calendar or something…)
First off, what I don’t think we should shoot for is deep technical discussion. I don’t think a synchronous chat meeting is the best forum for that. I suspect that would work best either on internals or (better) at the Rust All Hands that is (likely?) taking place this February.
Here are two other ideas.
Idea #1. Do a “State of the Team” retrospective, where we survey and discuss what works and doesn’t work with our current setup. I wrote up a gist with a possible plan (credit to @ag_dubs for the basic structure). Note that time allotted exceeds 1 hour – seems like the first meeting might want 90 minutes.
Idea #2. Do a survey that mixes “retrospective” with “where to go from here” – basically asking something like:
Github Username
Role (member, contributor, general public)
Things you think work well with compiler team
Things you think compiler team should fix
Things you think compiler team should prioritize over the next year (pick all that apply)
Raw compilation speed (time to run cargo build non-incrementally)
Incremental updates and RLS integration
Feature work (chalk, const generics, polonius)
Other
We could then discuss the results of these and try to lay plans.
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)
Today in the compiler team triage meeting, we decided to make the “Steering Meeting” every three weeks, at least to start. So a “twice per release” checkin.
That puts the next meeting on Friday, November 16 at 10am Boston time. If you would like to be added to the calendar invite, please let me know.
The next question: what should we talk about?
I was thinking it would be good to discuss compiler priorities for the next year a bit. I think it’s pretty clear that compilation time + fast, snappy RLS is going to be a priority, but I’d like to drill down a bit into some of the promising leads we have for that and what we can do to evaluate them – I’m particularly interested in how we can estimate the impact and choose relative priorities.
(I don’t expect us to reach final decisions here; but I see a need for us to start formulating thoughts in anticipation of the upcoming Roadmap discussion, and I would also like to start nailing down our agenda for the upcoming Rust All Hands in February – that is a great opportunity for us to finalize various architectural decisions in these areas, and I’d like to ensure we have all the data we need to make an informed decision.)
Thoughts?
One concern is whether we should maybe focus a bit harder – e.g., maybe it’s a good idea to discuss RLS specifically, or “overall compilation time” specifically?
I still hope we can talk about our priorities and planning for the next year. I'd like to do a few things:
Gather up all the major initiatives that are being contemplated, and ensure that they are represented in some way on my compiler planning diagram
For each one, identify:
Major steps or refactorings that ought to be represented themselves
Experiments we can do to get an estimate for how effective something will be (especially relevant to performance tasks)
Figure out places where it would be helpful to discuss in detail at the All Hands
It might also make sense to go through the All Hands Planning Document and try to prioritize and break things up. It'd be good to know which people ought to be a part of which discussion. As I recall from last time, it is pretty hard to solve the dependencies, so having some kind of input there is important.
Let me clarify what I am talking about. What I mean is, it'd be good to have meetings broken into "must attend", "may attend" to some extent, so that we can figure out which things can overlap etc.
But I'd also like to be able to answer the question "if we are only going to have time to cover 2 or 3 topics, which ones?"
In addition: what can we do now so that when we are trying to make plans, we have the data we need? I for example would really like to know more about the potential impact of various optimizations etc, as well perhaps as data on what scenarios we think are useful to which people.
Thinking more about what these online Zulip meetings are like, maybe we ought to focus for now on brainstorming. I imagine maybe:
are there improvements and ideas beyond the ones listed? can we get a complete list?
are there specific scenarios we want to optimize for? e.g., for mozilla or other major customers? how can we get something representative of e.g. dropbox, fuschia, and other major users?
what experiments can we do to to measure the effectiveness of each idea on each scenario?
