Skip to content

Commit 0547147

Browse files
authored
Merge pull request #271 from nikomatsakis/compiler-team-steering-meetings
Compiler team steering meetings
2 parents 9407636 + 7ac2f12 commit 0547147

File tree

6 files changed

+274
-0
lines changed

6 files changed

+274
-0
lines changed

src/SUMMARY.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -7,6 +7,11 @@
77
- [Windows](./compiler/cross-compilation/windows.md)
88
- [Diagnostic Codes](./compiler/diagnostic-codes.md)
99
- [Profiling Queries](./compiler/profile-queries.md)
10+
- [Triage Meeting](./compiler/triage-meeting.md)
11+
- [Steering Meeting](./compiler/steering-meeting.md)
12+
- [Submitting a proposal](./compiler/steering-meeting/submit.md)
13+
- [How to run the planning meeting](./compiler/steering-meeting/how-to-run-planning.md)
14+
- [How to run a design meeting](./compiler/steering-meeting/how-to-run-design.md)
1015
- [Infrastructure](./infra/README.md)
1116
- [Other Installation Methods](./infra/other-installation-methods.md)
1217
- [Release Channel Layout](./infra/channel-layout.md)
@@ -27,6 +32,7 @@
2732
- [rust-lang/rust CI](./infra/docs/rustc-ci.md)
2833
- [Language](./lang/README.md)
2934
- [RFC Merge Procedure](./lang/rfc-merge-procedure.md)
35+
- [Triage Meeting Procedure](./lang/triage-meeting-procedure.md)
3036
- [Release](./release/README.md)
3137
- [Beta Backporting](./release/beta-backporting.md)
3238
- [Platform Support](./release/platform-support.md)

src/compiler/steering-meeting.md

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# Compiler-team Steering Meeting
2+
3+
## What is it?
4+
5+
The "steering meeting" is a weekly meeting dedicated to planning and
6+
high-level discussion. The meeting operates on a repeating schedule:
7+
8+
- Week 1: Planning
9+
- Week 2: Technical or non-technical discussion
10+
- Week 3: Technical or non-technical discussion
11+
- Week 4: Non-technical discussion
12+
13+
The first meeting of the 4-week cycle is used for **planning**. The
14+
primary purpose of this meeting is to **select the topics for the next
15+
three meetings**. The topics are selected from a set of topic
16+
proposals, which must be uploaded and available for perusal before the
17+
meeting starts. The planning meeting is also an opportunity to check
18+
on the "overall balance" of our priorities.
19+
20+
The remaining meetings are used for design or general discussion.
21+
Weeks 2 and 3 can be used for **technical** or **non-technical**
22+
discussion; it is also possible to use both weeks to discuss the same
23+
topic, if that topic is complex. **Week 4 is reserved for
24+
non-technical topics**, so as to ensure that we are keeping an eye on
25+
the overall health and functioning of the team.
26+
27+
## Announcing the schedule
28+
29+
After each planning meeting, the topics for the next three weeks are
30+
added to the [compiler-team meeting calendar][c] and a blog post is
31+
posted to the [Inside Rust blog][ir].
32+
33+
## When and where is it?
34+
35+
See the [compiler team meeting calendar][c] for the canonical date and
36+
time. The meetings take place in the #t-compiler stream on the
37+
[rust-lang Zulip][z].
38+
39+
[c]: https://rust-lang.github.io/compiler-team/#meeting-calendar
40+
[ir]: https://blog.rust-lang.org/inside-rust/
41+
42+
[rust-lang/rust#54818]: https://github.com/rust-lang/rust/issues/54818
43+
[compiler-team website]: https://rust-lang.github.io/compiler-team/about/triage-meeting/
Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,38 @@
1+
# How to run the design meeting
2+
3+
## Week of the meeting
4+
5+
* Announce the meeting in the triage meeting
6+
* Skim over the list of proposals and ping people who have open
7+
proposals to get their availability over the next few weeks
8+
* Make sure that a write-up is available and nag the meeting person otherwise
9+
10+
## Day of the meeting
11+
12+
* Create a `design meeting YYYY.MM.DD` topic
13+
* Ping `@t-compiler/meeting`, ideally 1h or so before the meeting actually starts,
14+
to remind people
15+
* Include a link to the design meeting write-up
16+
* At the time of the meeting, return to the topic
17+
* Ping `@t-compiler/meeting` to let people know the meeting is starting
18+
* Include a link to the design meeting write-up
19+
* We typically begin with a 5min announcement period
20+
21+
To guide the meeting, create a shared hackmd document everyone can
22+
view (or adapt an existing one, if there is a write-up). Use this to
23+
help structure the meeting, document consensus, and take live
24+
notes. Try to ensure that the meeting ends with sort of consensus
25+
statement, even if that consensus is just "here are the problems, here
26+
is a space of solutions and their pros/cons, but we don't have
27+
consensus on which solution to take".
28+
29+
## After the meeting
30+
31+
* Post the final contents of the summary hackmd as minutes to [the
32+
`minutes/design-meeting` directory in the compiler-team
33+
repository][ct]
34+
* (Optional) create a Inside Rust blog post pointing people at the
35+
minutes and maybe giving a few notes
36+
37+
[ct]: https://github.com/rust-lang/compiler-team/tree/master/content/minutes/design-meeting
38+
Lines changed: 59 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,59 @@
1+
# How to run the planning meeting
2+
3+
## Week of the meeting
4+
5+
* Announce the meeting in the triage meeting
6+
* Skim over the list of proposals and ping people who have open
7+
proposals to get their availability over the next few weeks
8+
9+
## Day of the meeting
10+
11+
* Create a `design meeting YYYY.MM.DD` topic
12+
* Ping `@t-compiler/meeting`, ideally 1h or so before the meeting actually starts,
13+
to remind people
14+
* At the time of the meeting, return to the topic
15+
* Ping `@t-compiler/meeting` to let people know the meeting is starting
16+
* We typically begin with a 5min announcement period
17+
* Visit the [compiler-team] repository to get a list of proposed meetings
18+
19+
To actually make the final selection, we recommend
20+
21+
* First, try to identify topics that are clear non-candidates
22+
* for example, sometimes more investigative work (e.g., data gathering) is needed
23+
* try to identify people to do those tasks
24+
* other issues may be out of date, or clear non-starters, and they can be closed
25+
* Next tackle technical design meetings, then non-technical
26+
* Typical ratio is 2 technical, 1 non-technical, but this is not set in stone
27+
* It's ok to have fewer than 3 meetings
28+
29+
[compiler-team]: XXX
30+
31+
## Announce the meetings
32+
33+
For each scheduled meeting, create a calendar event:
34+
35+
* invite key participants to the meeting
36+
* set the location to `#t-compiler, Zulip`
37+
* include a link to the design meeting issue in the event
38+
39+
In the relevant issues, add the `meeting-scheduled` label and add a
40+
message like:
41+
42+
```
43+
In today's [planning meeting], we decided to schedule this meeting for **DATE**.
44+
45+
[Calendar event]
46+
47+
[planning meeting]: XXX link to Zulip topic
48+
[Calendar event]: XXX link to calendar event
49+
```
50+
51+
You can get the link to the calendar event by clicking on the event in
52+
google calendar and selecting "publish".
53+
54+
## Publish a blog post
55+
56+
Add a blog post to the Inside Rust blog using the [template found on
57+
the compiler-team repository][blog-template].
58+
59+
[blog-template]: XXX
Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# Submitting a proposal
2+
3+
If you would like to submit a proposal to the steering meeting for
4+
group discusison, read on! This page has all the details.
5+
6+
## TL;DR
7+
8+
In short, all you have to do is
9+
10+
* [open an issue on the compiler-team repository][ct issues]
11+
* use the template for meeting proposals
12+
* you only need a few sentences to start, but by the time the meeting
13+
takes place we typically expect a more detailed writeup, e.g.
14+
using [this template](
15+
16+
You don't have to have a lot of details to start: just a few sentences
17+
is enough. But, especially for technical design discussions, we will
18+
typically expect that some form of more detailed overview be made
19+
available by the time the meeting takes place.
20+
21+
## Examples of good candidates for discussing at the steering meeting
22+
23+
Here are some examples of possible technical topics that would be
24+
suitable for the steering meeting:
25+
26+
- A working group has an idea to refactor the HIR to make some part of their
27+
job easier. They have sketched out a proposal and would like feedback.
28+
- Someone has encountered a problem that is really hard to solve with
29+
the existing data structures. They would like feedback on a good
30+
solution to their problem.
31+
- Someone has done major refactoring work on a PR and they would like
32+
to be able to explain the work they did and request review.
33+
34+
Steering meetings are also a good place to discuss other kinds of proposals:
35+
36+
- A proposal to move some part of the compiler into an out-of-tree crate.
37+
- A proposal to start a new working group.
38+
39+
Note that a steering meeting is **not** required to create a new
40+
working group or an out-of-tree crate, but it can be useful if the
41+
proposal is complex or controversial, and you would like a dedicated
42+
time to talk out the plans in more detail.
43+
44+
## Criteria for selection
45+
46+
When deciding the topics for upcoming meetings, we must balance a number of things:
47+
48+
- We don't want to spend time on design work unless there are known
49+
people who will implement it and support it; this includes not only
50+
the "main coder" but also a suitable reviewer.
51+
- We don't want to take on "too many" tasks at once, even if there *are* people to
52+
implement them.
53+
- We also don't want to have active projects that will be "stepping on
54+
each others' toes", changing the same set of code in deep ways.
55+
56+
## Meetings are not mandatory
57+
58+
It is perfectly acceptable to choose *not* to schedule a particular
59+
slot. This could happen if (e.g.) there are no proposals available or
60+
if nothing seems important enough to discuss at this moment. Note
61+
that, to keep the "time expectations" under control, we should
62+
generally stick to the same 4-week cycle and simply opt to skip
63+
meetings, rather than (e.g.) planning things at the last minute.
64+
65+
## Adding a proposal
66+
67+
Proposals can be added by opening an issue on the [compiler-team
68+
repository][ct issues]. There is an issue template for meeting
69+
proposals that gives directions. The basic idea is that you open an
70+
issue with a few sentences describing what you would like to talk
71+
about.
72+
73+
Some details that might be useful to include:
74+
75+
* how complex of a topic you think this is
76+
* people in the compiler team that you think should be present for the meeting
77+
78+
### Expectations for the meeting
79+
80+
By the time the meeting takes place, we generally would prefer to have
81+
a more detailed write-up or proposal. You can find a [template] for
82+
such a proposal here. This should be created in the form of a hackmd
83+
document -- usually we will then update this document with the minutes
84+
and consensus from the meeting. The final notes are then stored in the
85+
[minutes] directory of the compiler-team repository.
86+
87+
### Expectations for a non-technical proposal
88+
89+
**The requirements for non-technical proposals are somewhat looser.** A
90+
few sentences or paragraphs may well suffice, if it is sufficient to
91+
understand the aims of the discussion.
92+
93+
## Frequently asked questions
94+
95+
**What happens if there are not enough proposals?** As noted above,
96+
meetings are not mandatory. If there aren't enough proposals in some
97+
particular iteration, then we can just opt to not discuss anything.
98+
99+
[ct issues]: https://github.com/rust-lang/compiler-team/issues
100+
[template]: XXX
101+

src/compiler/triage-meeting.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Compiler-team Triage Meeting
2+
3+
## What is it?
4+
5+
The triage meeting is a weekly meeting where we go over the open
6+
issues, look at regressions, consider beta backports, and other such
7+
business. In the tail end of the meeting, we also do brief check-ins
8+
with active working groups to get an idea what they've been working
9+
on.
10+
11+
## When and where is it?
12+
13+
See the [compiler team meeting calendar][c] for the canonical date and
14+
time. The meetings take place in the #t-compiler stream on the
15+
[rust-lang Zulip][z].
16+
17+
[c]: https://rust-lang.github.io/compiler-team/#meeting-calendar
18+
[z]: https://rust-lang.github.io/compiler-team/about/chat-platform/
19+
20+
## Where can I lean more?
21+
22+
The meeting procedure is documented in [rust-lang/rust#54818].
23+
24+
The working group check-in schedule is available on the [compiler-team website].
25+
26+
[rust-lang/rust#54818]: https://github.com/rust-lang/rust/issues/54818
27+
[compiler-team website]: https://rust-lang.github.io/compiler-team/about/triage-meeting/

0 commit comments

Comments
 (0)