RFC: Scaling Rust's Governance

[aturon]

This RFC proposes to expand, and make more explicit, Rust's governance
structure. It seeks to supplement today's core team with several
subteams that are more narrowly focused on specific areas of
interest.

Thanks to Nick Cameron, Manish Goregaokar, Yehuda Katz, Niko Matsakis
and Dave Herman for many suggestions and discussions along the way.

Rendered

[steveklabnik]

👍

[lambda]

Broken link, should reference the wiki backup instead.

[nagisa]

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

[Manishearth]

Note: Probably should have public minutes as much as possible.

[Manishearth]

@nagisa

Is it team leader’s resposibility to select subteam members or perhaps one has to nominate oneself somehow (if so, how)?

The team will select new members. This can either be unilaterally by the team owner, or by a discussion amongst the other members, if any. Should be the latter in general, though I think the RfC leaves the decision of how subteams can be expanded to the individual subteams so a subteam might decide on a more involved process.

Of course, you can nominate yourself by asking the team leader 😛

[aturon]

@nagisa @lambda I've taken your suggestions, thanks! And @nagisa, I added a bit of text about how the subteam membership evolves. Basically the policy is left to each subteam to decide (since the needs will differ by area), but after the team is up and running changes to its makeup should involve some kind of team consensus.

[aturon]

@Manishearth: I've pushed a commit to address both of the points you raised. Thanks!

[Gankra]

Once the subteam is up and running.

? Missing a word or extra punctuation or something?

[Gankra]

Overall this seems like a major improvement to the current process, 👍.

All of my thoughts/concerns are basically things that can/should be hashed out adhoc by the individual teams, I think.

[reem]

👍 from me too, this seems really nice.

[nrc]

For a project to be truly open, the process on deciding on these priorities must be public as well as the outcomes. Blog posts etc. have a place in keeping casual users informed, but to truly involve the community, we need to do much better at sharing how the core team arrive at decisions and trade-offs.

I.e., we need to find ways for the community to be part of the process (even if that is just as observers), not just recipients of the outcomes.

[wycats]

Do you feel the RFC process is deficient in some way with regard to this?

[nrc]

The process of setting priorities and strategic level direction has not been part of the RFC process, its been decided by the core team and only the results of the process have been stated publicly (not even the results sometimes). So it seems to be a process which is (somewhat) orthogonal to the RFC process and one where the level of openness has been sub-optimal.

[glaebhoerl]

👍

[aturon]

Niko's recent post about post-1.0 priorities is a good example of the kind of communication I have in mind here. The initial priorities laid out came out of consultation with a large number of people in the community, and the post itself is an explicit "request for comments". I'll make some additional replies about core team communication elsewhere on thread.

[nrc]

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

[aturon]

@nrc

Is there sill a role for the current weekly meeting or should its responsibilities be entirely covered by the subteams?

I think that if we make the move to subteams, the current meeting structure should be completely rethought. And yes, in particular the weekly meeting should be replaced by subteam meetings. I'm personally still interested in an additional, "town hall" style meeting, perhaps once per cycle.

Can we have minutes for the core team meeting? And a general move towards more open communication between the core team? I would very much like to see some movement in that direction in this RFC.

Sure, we can put out minutes of whatever meetings we wind up with (it's a little unclear how things will be structured if we move to subteams).

[Manishearth]

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

[aturon]

@Manishearth

I think at the very least a summary of the discussions, and why each decision was made, would be nice.

I'm not sure what this is a reply to, but these summaries and explanations of rationales are already made when merging or closing RFCs -- it's something we've been working really hard to do with every RFC. They could certainly be consolidated into meeting minutes, but as I said above we try to avoid making decisions in meetings anyway. But maybe I'm misunderstanding what you mean?

[Manishearth]

Nah, it was a general comment on the entire minutes discussion. Never mind it :)

[aturon]

After the discussion on this thread, the core team decided to start publishing minutes for its meetings, regardless of the outcome of this RFC.

The first set of minutes is up here. As you can see, rather than a transcript (which tends to have a mixed amount of detail, be difficult to follow, and require someone to focus on real-time transcription rather than the conversation), we've summarized the contents of the meeting post hoc.

[Manishearth]

\o/ nice 😄

[nrc]

Awesome, happy to see the core team meeting minutes

[quantheory]

A minor nitpick: I would say "unnecessary" or "needless" rather than "undue". The phrase "undue process burden" sounds like a reference to the concept of "due process", which is well-known legal jargon in most English-speaking countries, but I think that's just a distracting coincidence.

[quantheory]

I still need time to re-read/re-think this and the comments, but a few immediate thoughts:

1. The CoC is a big deal. Like most other mature human beings, I prefer to avoid trolling and drama on the internet. In professional matters, I pay attention to explicit statements about non-discrimination, partly out of principle, and partly because, like most people, I'm in some of those marginalized categories. I prefer to know that the community has my back, so that I don't have to always watch my own. So even though it isn't the first (or second...) thing I look for in an open source project, just having a decent CoC made a good impression when I was first looking into Rust.

   (I also like the aside in the CoC that mentions that cursing is allowed, but not at others. I'm not going to promote obscene language for its own sake, however much I indulge in it myself. But it's important both to clarify what the priorities in the CoC are, and to deal with cultural differences in what's considered a curse word. In my experience, the distinction between "cursing about a situation" and "deliberately insulting other people" is almost never ambiguous to an attentive moderator, but people do try to defend themselves by blurring the line here.)

2. I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes). Non-x86 architectures and accelerators (most obviously GPUs) are a weakness for Rust right now. I sure as heck don't want to deal with such things, but I think that there are plenty of people with such interests. The community really needs a body of people who specialize in codegen (e.g. know intimately how LLVM actually works) and/or follow trends in hardware capabilities (to take a simple example, widening of registers for improved SIMD), and I really don't see such things fitting into the subteams for language design, the reference compiler, or libraries, even though these considerations do in fact impact all of the above.

3. I think that the subteam hierarchy is, in general, inevitable. I have had this worrisome image in my head, which can be summarized as: How busy would it be if there was just one forum, where anyone who ever had a problem with C would know to raise an issue and actually expect to be heard by the standards committee? Of course, there are members of other language standards committees that you can contact without too much trouble, but older languages tend to be either more closed (so less expectation that anyone will listen to you as a user) or more populous (so there are more developers and committee members to field the many suggestions and requests) or usually both. I think that the best you can really do is to try for scaling that's O(log(n)) in the number of users by growing a deeper/broader hierarchy as the need arises.

4. I don't actually think that over-enforcement of the CoC is likely to be an issue, unless some very excessive people are brought on as moderators. The most common problems I've seen for open-source projects are under-enforcement (especially when moderators are chosen due to their popularity in the community or popularity among the core team, which are traits that should actually disqualify individuals from being moderators) or simple corruption (someone invested in certain subprojects banning political opponents).

[Manishearth]

I very strongly feel that there should be at least one subteam dealing with performance and portability (across hardware, not OSes).

I don't think we'll need a decision-making subteam here -- any decisions can be handled by the core or the compiler subteam, and there are people who do occasionally make PRs about this.

[quantheory]

@Manishearth I simply disagree. I regard this as a separate and essential specialty. The core team is by design not intended to deal with specialties, and my understanding is that the reference compiler team will have a lot of competing concerns. (Besides which, language design and libraries are both as relevant as the compiler.)

To be frank, I suspect that we will get by without such a subteam for a while, because it's not completely critical, and because we may not have enough people who are invested in Rust and prefer to specialize in hardware yet. (We have occasional RFCs, but fewer than I would expect for a systems language.) I think that in the medium/long run maintaining competitive performance will be difficult, though, without a body of specialists who look specifically at throughput and the ability to express various optimizations in Rust.

[Manishearth]

The thing is, the subteams are not for working on an issue, they are for prioritization and decision making. There's not much decision making to be done here, mostly just work. There may be occasional prioritization necessary and this sort of stuff can be handled by the core team (similar to all the other fields which rarely need a decision).

A group of specialists can be formed; I just don't see how it fits into the subteam system.

[quantheory]

@Manishearth OK, I agree now.

[bill-myers]

Have you considered having a single person in charge, possibly elected by the core team?

The issue with having a team in charge is that decisions may happen (or not happen) without any single person feeling truly responsible for them, which may result in bad decisions or inaction where action would be necessary.

As an example, you could have a situation where something is criticized and everyone on the core team could legitimately respond with "well, I'm not totally sure about that, but we decided to do it this way last meeting" and do nothing, while a single leader would have to either back up his decision or realize he made a mistake and move to correct it.

[Manishearth]

For subteams or the core team? Subteams have a leader, except for the mod subteam.

The core team has a bettry interpersonal dynamic than that I think -- If such things are happening there's a problem with the team.

Also fwiw most decisions will be made by the relevant subteam, which will be headed by a core team member (?), so for an individual decision there is a "responsible" party. ish.

[Manishearth]

Seems like we've reached a fixed point on this?

I guess we should move to the "final comment period" for this RfC then 😛

[nikomatsakis]

@Manishearth I agree:

https://internals.rust-lang.org/t/final-comment-period-for-rfc-1068-scaling-rusts-governance/1977

[strega-nil]

Final comment: 👍

This is a real step forward, and I'm glad we're taking it.

[Manishearth]

Time to merge? :D

[alexcrichton]

After giving this RFC a go through a trial run of the "final comment period", it looks like it's come out quite well! At this point there appears to be broad consensus that this is a great step forward for Rust's governance, both improving its transparency, scalability, and openness. As such, I'm now going to merge this RFC. Thanks again for everyone's discussion on this topic, it has been quite valuable!

The core team has been discussing the initial set of subteams and membership, and more details are soon to follow. This will also include an initial sketch for how the subteams may operate with guidelines about communication, status reports, etc. Stay tuned!