|
| 1 | +# Steering meeting |
| 2 | + |
| 3 | +The "steering meeting" is a weekly meeting dedicated to planning and |
| 4 | +high-level discussion. The meeting operates on a repeating schedule: |
| 5 | + |
| 6 | +- Week 1: Planning |
| 7 | +- Week 2: Technical or non-technical discussion |
| 8 | +- Week 3: Technical or non-technical discussion |
| 9 | +- Week 4: Non-technical discussion |
| 10 | + |
| 11 | +The first meeting of the 4-week cycle is used for **planning**. The |
| 12 | +primary purpose of this meeting is to **select the topics for the next |
| 13 | +three meetings**. The topics are selected from a set of topic |
| 14 | +proposals, which must be uploaded and available for perusal before the |
| 15 | +meeting starts. The planning meeting is also an opportunity to check |
| 16 | +on the "overall balance" of our priorities. |
| 17 | + |
| 18 | +The remaining meetings are used for design or general discussion. |
| 19 | +Weeks 2 and 3 can be used for **technical** or **non-technical** |
| 20 | +discussion; it is also possible to use both weeks to discuss the same |
| 21 | +topic, if that topic is complex. **Week 4 is reserved for |
| 22 | +non-technical topics**, so as to ensure that we are keeping an eye on |
| 23 | +the overall health and functioning of the team. |
| 24 | + |
| 25 | +## Announcing the schedule |
| 26 | + |
| 27 | +After each planning meeting, the topics for the next three weeks will |
| 28 | +be posted on the README.md of the main repository and also sent to a |
| 29 | +dedicated internals thread. |
| 30 | + |
| 31 | +## Examples of good candidates for discussing at the steering meeting |
| 32 | + |
| 33 | +Here are some examples of possible technical topics that would be |
| 34 | +suitable for the steering meeting: |
| 35 | + |
| 36 | +- A working group has an idea to refactor the HIR to make some part of their |
| 37 | + job easier. They have sketched out a proposal and would like feedback. |
| 38 | +- Someone has encountered a problem that is really hard to solve with |
| 39 | + the existing data structures. They would like feedback on a good |
| 40 | + solution to their problem. |
| 41 | +- Someone has done major refactoring work on a PR and they would like |
| 42 | + to be able to explain the work they did and request review. |
| 43 | + |
| 44 | +Steering meetings are also a good place to discuss other kinds of proposals: |
| 45 | + |
| 46 | +- A proposal to move some part of the compiler into an out-of-tree crate. |
| 47 | +- A proposal to start a new working group. |
| 48 | + |
| 49 | +Note that a steering meeting is **not** required to create a new |
| 50 | +working group or an out-of-tree crate, but it can be useful if the |
| 51 | +proposal is complex or controversial, and you would like a dedicated |
| 52 | +time to talk out the plans in more detail. |
| 53 | + |
| 54 | +## Criteria for selection |
| 55 | + |
| 56 | +When deciding the topics for upcoming meetings, we must balance a number of things: |
| 57 | + |
| 58 | +- We don't want to spend time on design work unless there are known |
| 59 | + people who will implement it and support it; this includes not only |
| 60 | + the "main coder" but also a suitable reviewer. |
| 61 | +- We don't want to take on "too many" tasks at once, even if there *are* people to |
| 62 | + implement them. |
| 63 | +- We also don't want to have active projects that will be "stepping on |
| 64 | + each others' toes", changing the same set of code in deep ways. |
| 65 | + |
| 66 | +## Meetings are not mandatory |
| 67 | + |
| 68 | +It is perfectly acceptable to choose *not* to schedule a particular |
| 69 | +slot. This could happen if (e.g.) there are no proposals available or |
| 70 | +if nothing seems important enough to discuss at this moment. Note |
| 71 | +that, to keep the "time expectations" under control, we should |
| 72 | +generally stick to the same 4-week cycle and simply opt to skip |
| 73 | +meetings, rather than (e.g.) planning things at the last minute. |
| 74 | + |
| 75 | +## Adding a proposal |
| 76 | + |
| 77 | +Proposals can be added by opening a PR and adding a new file into the |
| 78 | +[proposals] directory. The file should use the [proposal |
| 79 | +template][template], but renamed to a suggestive title. **This format |
| 80 | +is meant to be lightweight:** Proposals are generally not expected to |
| 81 | +be a lot of work to produce. |
| 82 | + |
| 83 | +[proposals]: /proposals |
| 84 | +[template]: /proposals/_template.md |
| 85 | + |
| 86 | +### Expectations for a technical proposal |
| 87 | + |
| 88 | +Technical proposals in particular should include enough detail that |
| 89 | +those experienced with the compiler can generally understand the |
| 90 | +plan. We should be able to figure out roughly how much work this idea |
| 91 | +would be to implement and which people would be most important to have |
| 92 | +in the discussion. |
| 93 | + |
| 94 | +For example, it would not be enough to say "experiment with a new |
| 95 | +hybrid bitfield format for spans" by itself. It is also not enough to |
| 96 | +just describe the format. It *would* be enough to describe the format |
| 97 | +and try to list out key parts of the compiler that would have to be |
| 98 | +changed, and what complications might arise. |
| 99 | + |
| 100 | +For larger designs, it's a good idea to come with an initial proposal |
| 101 | +early on that sketches out the shape. You can then come back with more |
| 102 | +detailed proposals as the work proceeds. |
| 103 | + |
| 104 | +### Expectations for a non-technical proposal |
| 105 | + |
| 106 | +**The requirements for non-technical proposals are somewhat looser.** A |
| 107 | +few sentences or paragraphs may well suffice, if it is sufficient to |
| 108 | +understand the aims of the discussion. |
| 109 | + |
| 110 | +## Frequently asked questions |
| 111 | + |
| 112 | +**What happens if there are not enough proposals?** As noted above, |
| 113 | +meetings are not mandatory. If there aren't enough proposals in some |
| 114 | +particular iteration, then we can just opt to not discuss anything. |
| 115 | + |
| 116 | + |
0 commit comments