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]

discuss forum should be linked to http://internals.rust-lang.org/, I guess.

[nagisa]

Would be nice to have something in spirit to the homu queue.

[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]

I think an explicit recommendation for subteams to involve people outside of the subteam in discussions/decisions whenever possible would be nice to have here. (It's probably going to happen in practice anyway)

The subteams should be viewed as place where the discussion focuses, not an authority figure that swoops in and hands out decisions.

[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!

[Gankro]

Once the subteam is up and running.

? Missing a word or extra punctuation or something?

[Gankro]

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]

Can we mandate that any meetings should be minuted? And that as much communication as possible should be public - i.e., using publicly archived mailing lists or discuss vs private email and using a public irc channel rather than private messaging.

[wycats]

That seems totally reasonable. It should be added to the doc.

[reem]

A public IRC channel for each subteam with logging sounds ideal.

[Manishearth]

This sounds good, but for the moderation subteam we might want to allow them to discuss things in private, though general communication should be public as much as possible. With the mod subteam there's going to be a lot of discussion of people, and this should be kept private so that the team members can be open about it and so that there's no chance of a user feeling publicly humiliated. Bans and all are a way to let the user cool off and reevaluate their reasons for being here and their behavior -- public discussion behind a ban can lead to a permanent-ish record which we may not want.

[tshepang]

@Manishearth 👍

[aturon]

Note the bullet in the RFC:

Technical discussion should take place as much as possible on public forums, ideally on RFC/PR threads and tagged discuss posts.

I'll supplement this by introducing public, logged IRC channels as well. There are several existing channels that can be repurposed for this role.

Also, I personally don't think that literal transcripts of meetings are always so valuable -- they are often inaccurate, and take one person out of the conversation, and can be very hard to decipher. I think it would be much better to instead coherently summarize what was said and done in any meetings -- the traditional notion of "minutes".

In my experience meetings are actually a poor place to make decisions -- it's easy to be swayed by the "heat of the moment" and a sense that an opinion needs to be registered immediately. It works much better to log objections directly onto RFC threads, and then follow up as those objections are addressed.

In the core team, for example, we almost never make decisions on RFCs in a meeting; at most, we call attention to RFCs that need decisions soon. Instead, we keep track of RFCs nearing decision point (a bit like the "final comment period"), and make sure that people who have objections have raised them publicly on thread. I would suggest a similar process for subteams.

As an aside, I think private conversation has its place. It allows for greater bandwidth (due to shared context), greater candor, and makes it easier to hash out ideas in an earlier phase, and so on. I do not think it's possible or desirable to legislate away its existence.

Rather, there needs to be a culture of public communication:

• As soon as an opinion or idea becomes relatively formed -- ready for public consumption -- go public with it. Whenever practical, start in public.
• All decisions are made based on previously-discussed public rationale.
• Use of processes like RFCs to move things forward in a very public, visible way.

All of this is already in the RFC.

[nrc]

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

[aturon]

@nrc

I think there is some happy place between summaries and literal transcripts that is more ideal than both. I often find detailed minutes extremely useful. Specifically it is good to know who is involved in a discussion and how (so you know who to contact if you want to be part of the conversation), how much confidence there was in the arguments, how close the decision was, what the motivations are, the reasoning that people use. Summaries rarely capture the level of detail necessary for someone not at the meeting to really understand how a decision is made.

This puts much more weight on meetings/final point of making a decision than I think it merits.

We've been pushing for the last several months for strong, active participation on RFC threads prior to any decision. The decision-making process at this point is usually just a check: "Has everyone's objections been raised on the thread and responded to"? And the more controversial a topic, the more we strive to debate it vigorously on the RFC thread.

When RFC decisions were previously made in the minuted weekly meeting, there were many problematic cases that resulted in a lot of frustration in the community, despite those minutes.

I think that the situation has improved greatly over the last several months, mostly due to the increased discipline in the core team spending time engaging directly on RFC threads, laying out arguments, tradeoffs, and worries. These activities all support the goals you mentioned above, but they do so before the point of a final decision, and I think that is key.

Whatever venue a decision is made within, I think what people want is a chance to engage with the rationale, and thereby to influence the decision-makers, prior to the final decision. That's not really about meetings or minutes; it's about team members participating actively in all phases of the RFC process.

I do agree there is a place for private conversation, but it should be much rarer then it currently is. It has its place to do very early brainstorming and later very detailed work, but we would benefit from more of the middle section of idea development being public by default.

I think everyone agrees that conversation should be public by default, and the RFC explicitly mentions this (as did my bullets above).

FWIW, I don't share the impression that much of significance is being discussed privately at the moment. I tried to express this above with the strong move toward participation on RFC threads, which I think has been very successful. It also applies to topics beyond RFC decisions, where anything actionable that comes out of a core team meeting has a next step of getting feedback from the broader community, be it via a discourse thread, a new RFC, or something else.

But in any case, as I've said elsewhere, we can certainly minute the core team meetings (in the traditional sense) going forward.

In particular, the idea of forming an idea in private and then communicating it publicly seems the wrong approach. The idea should be formed in public (where by public I don't mean the whole world or every Rust user, it might mean just one subteam's peers) and there should be no need to communicate things because the conversation itself is public.

This may just be a difference in working style. I appreciate being able to bounce a passing thought off a collaborator without starting an entire thread or group IRC discussion about it. If it turns into something interesting, then I get feedback from a larger group until I'm ready to write an actual RFC about it.

[nrc]

I think we are more or less in agreement, with perhaps some difference of opinion about where to draw the line in the details.

I hope that having the subteams will make things easier. Rather than bouncing ideas off a specific person, we have a small group of people to ask if they're interested in the 'idea bouncing stage', and that group of people at least can know which ideas are bouncing around.

[nrc]

At the least it seems that each subteam should have a way to broadcast changes which are major enough to make them nervous, but not major enough to need an RFC - an 'intent to implement' email or something.

[nrc]

I've previously suggested that this team should in some way 'choose itself' rather than be appointed by the core team. That probably still requires one or two appointments, but the rest can be bootstrapped.

[nrc]

For clarity, are non-core-team Mozilla employees/contractors/interns/former interns also excluded or fair game for the moderation subteam?

[wycats]

I'm personally pretty uneasy with the idea of making Mozilla special from the perspective of governance rules, especially since I expect that, in the long term, more and more companies and individuals will come to be represented on the core team and in subteams.

That said, if the intent of some part of the process is to ensure fair dealing (and the perception of fair dealing), we should be cognizant that companies with significant representation on the core team will be a poor fit.

[nrc]

There has been a lot of confusion in the past between the set of core team members and the set of people affiliated with Mozilla in some way. I agree that this will become less significant with time, but here and now I think it is worth clarifying.

[Manishearth]

I think mentioning that the mod subteam should not include core team members is enough for the scope of this RfC; subteam can internally decide how to pick users beyond that. I would suggest that they avoid current employees though (at least for now), since at the moment there is a strong core-team/Mozilla relation and conflict of interest is possible.

[nrc]

It seems like unnecessary oversight to require core-team approval here. It seems to me that this breaks the separation of concerns between the two groups (to give a political equivalent, government does not need to approve life sentences - the judiciary are considered independent in that respect).

Put another way, since every permanent ban must be approved by the core-team, it means that all bans are political rather than judicial.

[tshepang]

👍 the sentence should be removed. I did wonder what the motivation behind it is.

[aturon]

The motivation, as with the feature-gate removal, is to provide an extra level of checking before making the final step. Like gate removal, it should basically always be approved; if it's not, something has gone very wrong.

I don't believe we should strive for a complete "separation of concerns" between any of the teams; the goal here is greater scalability, and having teams with different (but overlapping) focuses can get us a long way, in my opinion.

I certainly hope that bans aren't common enough to cause scalability issues, and I think getting some additional opinions from the core team before kicking someone permanently out of the community is a reasonable protection against moderation going overboard.

In terms of governmental analogies -- which I'm wary of for many reasons -- many governments set up an elaborate, explicit interconnectedness between various branches. In the US, for example, there's the presidential veto of legislation, but likewise the legislation's requirement to "confirm" the president's choices of e.g. cabinet members. Etc. etc.

[nrc]

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

[aturon]

@nrc

(text re-ordered a bit)

If part of the reason for having a moderation team is to avoid conflict of interest, it seems you can't have this check - it's clearly a conflict of interest. I realise in purely practical terms this is not a big deal, but appearance is very important, and this creates a bad appearance. In particular, this means that the core team are essentially exempt from being banned and, a cynical person could argue, from the CoC itself.

We should trust out moderation team by default, if they turn out to be terrible then I believe we have the ability and community will to fix things at that point rather than trying to plan in advance.

I don't believe that conflicts of interest or trust are such binary things. This RFC gives a huge amount of trust to subteams, allowing them to accept, reject, and implement RFCs independently, and even to set the policy about what requires an RFC in their area. Likewise, the majority of the moderation subteam's activities are done without oversight, including temporary bans.

Similarly, prohibiting core team members from sitting on the moderation team substantially decreases the potential for conflicts of interest -- the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

In short, I object to the idea that having any amount of oversight indicates a default of mistrust, or that any potential for conflicts of interest indicates that moderation is a sham. It is all a spectrum, and I believe that this RFC moves control to a substantial degree away from the core team, keeping around only final gatekeeping checks at the final stage. It is for catching mistakes in the process that potentially have significant consequences.

A ban is not a death penalty - it can always be fixed afterwards so there is plenty of opportunity for the core team to work with the moderation team if a mistake is made and to fix the mistake. It seems overly cautious to have this check - the expense of the paranoia about the moderation team going overboard (which seems unlikely) is the perception of corruption.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

As I said above, the worry about conflicts of interest that I've encountered has wholly been about the other side -- that if the core team enforced the CoC, it could be seen as doing so to silence technical dissent.

[Manishearth]

• the most important of which, historically, is not the claim that the core team is breaking the CoC but rather that any attempts to enforce it are actually about squelching dissent on technical topics.

FWIW this is the situation I was considering when I noted that we should avoid Mozilla employees (/core team members) in the original CoC enforcement proposal. I did not think we would need to plan for a CT member violating the CoC, nor would we have to plan for the community being wary of the same. I still don't think we need to. I'm more wary of a perception of the core team squelching dissent, as you said.

A ban might be reversible, but the fallout from making a ban, and then reversing it, could be extreme. Much better to avoid the mistake in the first place.

Huge +1 here. Bans can easily antagonize the recipient (that's why we try to resolve it without a ban first), make people feel patronized, and in general sour a situation further.

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

So it might be okay to be looser on the core team approval thing for a certain degree of severity.

Though the time thing becomes a non-issue if, after the first or second infraction by someone, the mod team and perhaps a core team member discuss it out internally and decide what to do the next time an infraction of the same type comes from that person, if ever. If there doesn't seem to be any disagreement, if the person violates the CoC again, a mod can just unilaterally-ish hand out a ban the next time. (In cases where the pre-discussion isn't unanimous, it might be best to discuss it out)

[aturon]

@Manishearth

However, note that in most cases with bans time is of the essence. Given that the core team is concentrated on one hemisphere, waiting for CT approval on something might take a day -- bear in mind that it probably already took half a day for the mod team to discuss this out. This is a lot of time to wait if there's a fight brewing or something. I'm not so concerned about a perception of corruption due to this as I am concerned of the time lost in the process.

I think you say this in the rest of your comment, but just to be clear: it's worth remembering that this is only about permanent bans. The moderation team is free to issue short-term bans on its own (and in truly urgent cases, an individual moderator could do so unilaterally). That should take care of any latency issue, and give plenty of time for discussion with both teams before deciding if/when to issue a permanent ban.

[Manishearth]

Oh, I didn't realize that.

This works.

And I think this should address @nrc's concerns too, since permabans should be very rare anyway.

[nrc]

I did realise it was only permanent bans. I agree they ought to be rare and that is one reason I'm more keen to sort things out ahead of time, whereas for other things I think 'see how it goes' is a better approach. I worry that in the past the core team and core team + extras have been very hesitant around bans, when in retrospect they should have been handed out earlier. This extra check seems like it will encourage such hesitancy in the future too - more steps to go through and more people to debate means more chance of indecision. Hopefully, it will be rare enough to not matter....

[nrc]

Does the moderation team also have the power to remove one of its own members? (presumably by consensus of the others)

[Manishearth]

This probably can be decided by the mod team itself once formed.

I would say yes.

[nrc]

Worth pointing out that we expect core-team members to be subteam members (not just the leader) and this is also a mitigating factor.

[nrc]

"large number" is scary here - I hope the absorption of new people into decision making roles is slow and gradual. It might be worth being explicit in this RFC about the sort of numbers we expect in each subteam initially and (roughly, obvs) how quickly we expect the subteams to grow (for that matter the core team too, there are hints in this RFC that you would like the core team to grow, but aiui there has previously been pressure that it should not grow, or at least not quickly).

[Manishearth]

+1. Ever since the initial draft I wasn't quite able to get a clear image of what a subteam should look like, though I didn't ask because it didn't occur to me consciously.

I've been assuming 5-10 per subteam, though it could be less. (timezones can be an issue with a small subteam though)

[aturon]

It will likely vary by area, but yes, I think 5-10 is a good range. The moderation team probably wants to be a bit smaller.

And yes, of course this will be a gradual process.

[nrc]

I was thinking numbers-wise the modules should be like the core team: 4-6 is a good number, 8 is the point where we start to think about scaling again. Obvs, this is pretty much the same as 5-10, so this is agreement stated slightly differently :-)

[nrc]

My particular preference for owner rather than leader is because I think that the leader should be first among equals, rather than a BDFL of an area. Just as we (nearly always) look towards the core-team as a whole for our current leadership, so it should with subteams.

[nrc]

In my ideal world 'peer' means being a peer for the project as a whole and the core-team are also peers with a particular responsibility towards strategic/global issues, rather than 'peer' being part of a sub-group.

[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

[ubsan]

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!