Right now the Rust Compiler Team is a somewhat ad-hoc group.
We have a team lead (Niko).
We have some semi-formal structures in place:
- weekly triage meeting
- weekly steering/design meeting
- new members are nominated by an existing team member and then all the current team members get a chance to weigh on the nomination.
and of course we have the various working-groups and the experts map.
I am not sure the current structure is scalable going forward.
The biggest question: How do we achieve all of:
- decisiveness,
- openness (representation) and
- not impose big time constraints (e.g. requiring attendance at too many meetings).
Right now I think we are optimizing for (2) and (3) but failing at (1).
I don't know how to fix that, but I'm hoping that adding some additional structure, or even just identifying the structure that is already implicitly present, would help.
My belief: there is some amount of informal knowledge about which members of the team have expertise in which areas (which we do try to codify in the working-group structure and in the experts map), and when it comes time to make decisions, whomever is present decides on-the-fly on a case-by-case basis whether all the necessary parties are present and have the information necessary for a decision to be made.
Thus, some decisions are left unmade for a long time, as we wait for:
- implementation experiments
- data collection
- people to happen to show up at the right time.
Furthermore: There are tasks that happen (or should happen) on a regular basis, such as:
- doing triage on the P-high issues,
- writing up the meeting summaries,
- trying to farm out/mentor our huge backlog of unassigned P-medium bugs.
Sometimes the burden of the above falls on the compiler lead. But that need not be the case; this burden could be shared amnongst a larger portion of the team, e.g. via rotation across team members
It would also make sense to actually define (as in name) the specific roles that are taking care of such duties at the meetings. e.g. The person charged with summarizing the meeting is usually called a "secretary"; that should be formal role on its own, with an associated set of team members who know how to do it well. (The reason to have a set of people available is that you want to make sure that at least one will be able to author the summary in a timely manner during or after the meeting.)
Some additional questions that I would like a "compiler team constitution" to answer:
- How is leadership determined?
- Maybe we elect a lead. Or elect a co-lead and give Niko co-lead for life status.
- What about other roles? Election? Or co-leads have authority to approve e.g. secretaries.
- What process should we use to resolve intra-team disputes? (How public can/should such a process be?)
- Should we have a specific subteam tasked with technical steering, so that those discussions can be more focused?
- How are working groups determined?
Some/all of these may actually be covered by discussions already had by WG-meta; see https://rust-lang.github.io/compiler-team/working-groups/meta/
(But just because it was discussed by WG-meta doesn't mean the rest of the compiler team signed on.)