Add RFC on governance, establishing the Leadership Council

[sophiajt]

This RFC was jointly authored by @jntrnr (Core), @joshtriplett (Lang Team Lead), @khionu (Moderation), @Mark-Simulacrum (Core Project Director, Release Lead), @rylev (Core Project Director), @technetos (Moderation), and @yaahc (Collaboration Project Director).

Many thanks to all of the members of "leadership chat" and the wider Rust Project for their many first-pass reviews and feedback.

This RFC establishes a Leadership Council as the successor of the core team. The Council delegates much of its authority to teams.

Note: This summary provides an overview of the RFC, but it is not authoritative.

Procedural information

Discussions

For discussion on this PR, please use this dedicated Zulip stream.

Translations

The authoritative version of this RFC is in English. However, to support widespread understanding of Rust's governance structure and policies, we've started the process of translating the proposed governance structure and policies into additional languages. Specifically, based on Rust Survey data on the top languages for which survey respondents indicated non-English communication would be helpful, we will post (non-authoritative) translations into the following languages as soon as they're available:

• Chinese (Simplified)
• Chinese (Traditional)
• Japanese
• Korean (In Progress, see this comment below)
• Russian

We'll link those translations from here when they're available. Please note that this does not necessarily mean we'll be prepared to handle comments in non-English languages. Any potential future translation decisions will be up to the Council, not this group. If you have feedback on these translations, please let us know, as input for future decisions about translations.

Supplemental files

This RFC includes supplemental text files. Please note the subdirectory here.

---

RFC Summary

Motivation

[full text]

Rust's structure delegates most decisions to the appropriate team. However, a great deal of work falls outside the purview of any established team.

Historically, the core team both identified important work that fell outside of team purviews, and also attempted to do that work itself. However, putting both of those activities in the same team has not scaled and has led to burnout.

The Leadership Council established by this RFC focuses on identifying and prioritizing work outside of team purviews. The Council primarily delegates that work, rather than doing that work itself. The Council can also serve as a coordination, organization, and accountability body between teams, such as for cross-team efforts, roadmaps, and the long-term success of the Project.

This RFC also establishes mechanisms for oversight and accountability between the Council as a whole, individual Council members, the moderation team, the Project teams, and Project members.

Duties, expectations, and constraints on the Council

[full text]

The Council indentifies, prioritizes, and tracks work that goes undone due to lack of clear ownership. It delegates this work to teams (which may be new or temporary). In some circumstances it can decide urgent matters without a clear owner.

The Council also coordinates Project-wide changes to teams, structures, or processes, ensures top-level teams are accountable, and establishes official positions of the Rust Project.

Structure of the Council

[full text]

The Council consists of a set of team representatives, each representing one top-level team and its subteams.

Each top-level team designates a representative, by a process of their choice. Any member of the top-level team or any of its subteams is eligible.

All teams in the Rust Project must ultimately fall under at least one top-level team. For teams that do not currently have a parent team, this RFC establishes the "launching pad" team as a temporary home. This ensures that all teams have representation on the Council.

Representatives have limited terms. There are limits on the number of representatives from an entity. Teams should provide alternates in case of absence.

The Council's decision-making process

[full text]

The Council makes both operational and policy decisions. By default, the Council uses a public consent decision-making process for all decisions, where representatives are asked for their objections rather than explicit approval. The minimum decision approval criteria requires a quorum, and requires time for representatives to have seen the proposal.

Using the public policy process, the Council can establish different decision-making processes for classes of decisions. The Council's agenda and backlog are its primary interface for issues raised by Project members. All policy decisions should have evaluation dates.

Transparency and oversight for decision making

[full text]

Different kinds of decisions made by the Leadership Council require varying levels of transparency and oversight.

Some types of operational decisions can be made internally by the Council, allowing for feedback on the decision afterwards. Some decisions must be made privately because they involve private details of individuals or other entities, and making these details public would have a negative impact both on those individuals or entities (e.g. safety) and on the Project (eroding trust). All other decisions must be made publicly allowing for feedback on the decision beforehand.

A Council representative must not take part in or influence a decision in which they have a conflict of interest. The Council must approve expansions of a top-level team's purview, and can adjust the purviews of top-level teams (other than the moderation team).

Mechanisms for oversight and accountability

[full text]

The Council must publicly ensure that the wider Project and community's expectations of the Council are consistently being met.

Council representatives should participate in regular feedback with each other and with their respective top-level team to reflect on how well they are fulfilling their duties as representatives.

The Council also serves as a means for teams to jointly hold each other accountable, to one another and to the Project.

Moderation, disagreements, and conflicts

[full text]

Where possible, teams should attempt to resolve disagreements on their own, with assistance from the Council as needed. Conflicts involving teams or Project members should be brought to the moderation team as soon as possible.

The moderation team must maintain a public list of "contingent moderators". Contingent moderators can work with the moderation team in an audit process to establish whether the moderation team followed documented policies and procedures. Council members may initiate audits, but the Council never sees private moderation information.

As an absolute last resort, either the Council or the moderation team may choose to simultaneously dissolve both teams. Teams then select new representatives, and the contigent moderators become the interim moderation team and select successors.

In moderation cases involving Project members, any party may request an audit. Moderation cases involving Council representatives or moderation team members have additional oversight and accountability measures.

Ratification of this RFC

[full text]

Since November of 2021 the following group has been acting as de-facto Project leadership: all members of the core team, all members of the moderation team, all Project representatives on the Rust Foundation board, and the leads of all the "top-level" teams:

• Compiler
• Crates.io
• Dev tools
• Infrastructure
• Language
• Library
• Moderation (already included above)
• Release

This RFC will be ratified using the standard RFC process, with the approving team being all the members of this de facto leadership group. This group should also raise objections on behalf of other members of the Project; in particular, team leads should solicit feedback from their teams and subteams.

Rendered

[joshtriplett]

Starting the process of gathering consensus or objections:

@rfcbot merge

[rfcbot]

Team member @joshtriplett has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Manishearth
• @Mark-Simulacrum
• @Turbo87
• @badboy
• @cuviper
• @jntrnr
• @joshtriplett
• @jtgeibel
• @khionu
• @m-ou-se
• @nikomatsakis
• @pietroalbini
• @pnkfelix
• @rylev
• @technetos
• @tmandry
• @wesleywiser
• @yaahc

Concerns:

• require-all-checkmarks resolved by Add RFC on governance, establishing the Leadership Council #3392 (comment)

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[Diggsey]

The RFC goes to great lengths to balance power between the moderation team and the council. The "audit" process seems designed to ensure that the moderation team follows their policies and procedures. But what about challenges to the moderation policy itself?

Hypothetical example: the moderation team decides to change their policy to something contentious. They later implement that policy resulting in the removal of a project member and thus an audit. Under this scenario it would appear that the "contingent moderation team" would feel obligated to agree with the decision, since the policy was implemented correctly, even if neither the council nor the contingent moderation team agreed with the policy change.

However, the Council may not overrule a moderation decision or policy.

While the Council should not be able to overrule a specific decision, I do think it would make sense for the Council to have veto power over changes to the moderation policy prior to the new policy being enacted.

[joshtriplett]

@Diggsey

In this scenario, we would expect the contingent moderators' audit to come back with a report saying "while the moderation team followed policy, the policy itself is the problem and is producing bad outcomes". The Council and moderation team, and for that matter the moderation team and contingent moderators, can talk through the policy and evaluate whether changes need to be made.

I don't think we want to give the Council veto power over moderation policy (other than changes to the policies around interaction between the Council and the moderation team). However, I would expect the moderation team to keep the Council informed of changes to moderation policy, and either party can start discussions about those changes. The Council and the moderation team are both obligated to engage with feedback in good faith.

We currently have text saying

This mechanism necessarily involves the contingent moderation team using their own judgment to evaluate moderation policy, specific evidence or communications, and corresponding moderation actions or proposed actions.

This does empower the contingent moderation team to evaluate policy, not just actions. However, we may need to clarify subsequent text to state explicitly that the contingent moderation team evaluates both the policy and its specific application.

[araruna]

While the Council should not be able to overrule a specific decision, I do think it would make sense for the Council to have veto power over changes to the moderation policy prior to the new policy being enacted.

I agree with this, but I think it only makes sense if the vetoes, when they happen, are subject to the scrutiny of a higher order body (like the entirety of the governance members) with the final decision over the sustainability of the veto.

[Diggsey]

I don't think we want to give the Council veto power over moderation policy

Is there a particular rationale for this?

In the governance of nations it is typical to have one body in charge of putting forward proposals and a separate body with veto power, but no ability to make proposals on its own. It seems like this model would work well here.

The moderation policy is a public document that will affect the willingness of people to contribute to the whole Rust project.

The Council itself has many controls in place to prevent it becoming a bad actor (elected members, term limits, subject to moderation team actions, affiliation limits, etc.) while the moderation team's only form of oversight is the contingent moderation team... Who are likely to have many of the same biases given the relationship between those teams (eg. a bias towards policy changes that make it easier to make moderation decisions).

The Council's only real recourse is the nuclear option - but that doesn't work if the moderation team make incremental changes to the policy where each change in its own right is insufficient to warrant a nuclear response. The Council can object as much as they want but the moderation team has no reason to even come to the table. WIth veto power over policy changes, there is much more balance, while the Council is still unable to interfere in the day-to-day moderation activities of the team.

[joshtriplett]

@Diggsey

First and foremost, because the Council itself is subject to the moderation policy. We're trying to create a system of checks and balances between the moderation team and the Council, and giving the Council veto power over the moderation policy that applies to itself would limit future moderation teams' ability to serve as a check on the Council. For instance, a Council member engaging in repeatedly borderline behavior could also veto policy that addresses that behavior specifically.

Second, because ultimately moderation policy is the set of guidelines by which the moderation team does its job, written down for the sake of consistency and documentation. The checks and balances on moderation policy are the same as those on moderation actions: audits, conversations about those audits, and the last-resort mechanism if those conversations don't succeed. In practice, having an external veto over a team's policy does not prevent a team from having that policy, it just prevents them from writing down that policy. We still need a robust audit mechanism that looks at the actual actions and policy together and determines if they're reasonable.

(Also, we might want to take this to Zulip for a higher-bandwidth interactive conversation, since long threads on GitHub are harder to follow.)

[onur-ozkan]

The Council primarily delegates that work, rather than doing that work itself. The Council can also serve as a coordination, organization, and accountability body between teams, such as for cross-team efforts, roadmaps, and the long-term success of the Project.

This separation sounds great. For such responsibilities it's better to not involve directly in the work/implementation. A spectator at tribune can have wider point of view than a footballer on the field 😄

I hope this will also reduce the pressure on core team.

[yaahc]

@rfcbot concern require-all-checkmarks

For this RFC we want to get all checkboxes, not n-2. This is not an objection, it is purely meant to prevent the FCP from starting until all checkboxes have been filled.

[nrc]

I've given quite a lot of feedback on this RFC as it was being developed and I don't have much to add, I think it's as good as it could get under the circumstances and without changing the minds of the authors on some fairly fundamental points.

I want to thank the authors for their hard work, I know this took ages and isn't the most fun job.

However, I want to note for posterity that I think the process of developing this RFC has been Very Bad.

• The 'leadership chat' was a necessary way to break the deadlock around the core team's collapse and was a good thing. But the fact that it persisted as a governance mechanism and took total responsibility for the governance reform was not. It has not open, transparent, or accountable and this doesn't fill me with optimism for the reforms proposed by it.
• Developing this RFC almost entirely in private is contrary to the principals of the Rust project and those espoused in the RFC itself. Doing stuff in private where it is necessary is fine (e.g., where work has privacy concerns, or legal or financial work), but governance work is not in that category. Doing governance work in private is just because it is easier, and that is not a good reason.
• It took way too long. Frankly, I suspect that some folk who had authority over this work were not giving it the attention it deserved (which has been an anti-pattern in Rust's governance in the past) or were being deliberately obstructive. But of course we have no idea because both the leadership chat and the RFC development process were completely opaque and nobody involved is individually accountable.
• "For discussion on this PR, please use this dedicated Zulip stream." IMO, the most important RFC in years is not the place to make ad hoc changes to the RFC process with no public discussion. Everyone knows GitHub PRs are sub-optimal for RFC discussion. But Zulip threads are worse - they are harder to read after the fact, harder to search, require an additional sign-up to participate in, have the friction of another venue, and do not conveniently record objections and discussion next to the RFC. I hope that all discussion there will be recorded here.
• Some authors seem to me to have a significant conflict of interest due to direct involvement with the mods/core conflict last year and should have recused themselves from this work.

I do think we should merge this RFC as soon as possible, so we can move on and start making some positive changes to Rust's governance (having a leadership/governance structure at least makes positive change possible).

[nrc]

• Delegate work: The Council should not take on work beyond what this RFC explicitly assigns to it; it must delegate to existing or new teams distinct from the Council. Such teams may include Council representatives, but such membership is not part of the duties of a Council representative.

Given that this emphasis on delegation is one of the key features of this RFC, I think it is important to reflect on delegation of work vs delegation of authority. The Rust project has historically been good at delegating work but not authority (which I'm personally guilty of contributing to in the past) but I think that unless the council is able to effectively delegate authority, then it will face many of the same problems as the core team in the past.

As an example of what this means, the council must trust the groups it delegates to to make final decisions without direct council involvement (some oversight is fine and probably necessary to maintain that trust). For example, if the council delegates responsibility for reorganising the top-level teams (as recommended in the RFC) then a good way of that working is to delegate a group to have responsibility (i.e., to tick the boxes to accept an RFC) and that group further delegates responsibility (mostly internally) for the various stages of creating a proposal. A bad way of that working would be for the council to delegate the work of creating a proposed re-org, and then keeping authority to approve that proposal to itself.

[dlight]

I think it's as good as it could get under the circumstances and without changing the minds of the authors on some fairly fundamental points.

@nrc perhaps I'm asking too much, but could you elaborate on those fundamental points?

I'm asking because this RFC already has 8/18 boxes ticked with seemingly little to no public discussion between decision makers [*]. As you mentioned this proposal was already discussed in private, but for the sake of transparency perhaps this RFC is the place to summarize this discussion.

[*] Which is not to say that there is no public discussion: discussion is largely happening on this /r/rust thread (oddly I can't find a thread on users.rust-lang.org nor internals.rust-lang.org), and in particular I think this comment makes great points, but it is unclear whether the community feedback can make substantive changes on the text of the RFC. As you said, the current text might be as good as it gets.

[yaahc]

For context on the boxes checked. 7 6 of the 8 people who have checked their boxes are the authors who've been working on this RFC together since August. The rest of the approvers should currently be gathering feedback, reactions, concerns, and objections from the members their team and subteams to bring back into this discussion on their behalf.

[rylev]

Thanks for your feedback @nrc! We certainly want to make sure the process is as open and collaborative as possible. We talked about this feedback amongst ourselves and have some thoughts to share.

Why was the leadership chat allowed to continue to exist?

The follow up question to this point is: what should the 'leadership chat' be replaced with? This RFC is exactly the attempt to answer that question. So, total agreement with your point, but it seems like we're just not in agreement on the timeline (more on that below).

Why was this RFC drafted in private?

This process has had deep involvement from many folks outside of the working group (including yourself) on early drafts. We decided to send out early drafts to targeted individuals over 6 months ago. Getting targeted feedback ensured that the amount of feedback was manageable.

Additionally, we encouraged anyone who wanted to read a draft and participate in discussion to reach out (starting with this blog post in October). While we received a few such requests to share an early draft and get early feedback, most of the responses were signs of appreciation that we were taking this work on so that they did not have to. We were not surprised by the lack of interest with being intimately involved in this process as the work is incredibly emotionally draining.

Finally, we then sent a draft to all project participants (those on the all@ email address) in early January to review and give feedback. This process produced more feedback which we incorporated into the draft.

The involvement of those outside of the 7 of us on the working group has changed this RFC in fundamental ways.

However, this work is complex, requires immense amount of context to follow, and is often very subtle. The amount of work required to keep those not directly involved on top of each change of the draft would have easily drowned the working group in additional responsibility. This would have very likely led to burn out and the process ending before we reached any sort of conclusion. If any of the choices made in the RFC are unclear, we are more than happy to include context on the tradeoffs considered. There is already quite of bit of this present in the alternatives document.

We owe the community the chance to review this document and suggest changes, and we are obligated to continue to evolve the RFC through the lens of that feedback. That is exactly what we are doing now. Having to follow the same process while getting our own thoughts in order would simply not have been possible.

Why did this take so long?

First of all, no one has been deliberately obstructive. This process has personally given me a ton of hope that we as a project can continue to work through difficult problems with good faith discussion and positive attitudes. It wasn't always easy, but I firmly believe everyone involved has had the Project's best interests in mind.

Second, the drafting process started in earnest in early August 2022 not November 2021. Before that we conducted a large set of in-depth one-on-one interviews with project leaders to understand their perspectives. I wish we would have started the drafting process earlier, but coordination at this scale is very hard (hence why we're establishing the Council to specifically handle such coordination). In essence, this RFC proposes a process to make sure things like this are addressed in a more open, transparent, and timely manner.

Third, if this could have gone more quickly, we certainly would have tried. This was a process involving hundreds of hours of work by each working group member. We tried our best to balance "getting the draft right" with "getting a draft done". Our original goal was shipping in late December, but we ultimately waited in order to incorporate feedback we received from Project members.

It's important to reiterate that this process is not over, and this document is not policy until ratification. Even then, we also explicitly state in the RFC that there is an expectation that the Council evolves over time. Just because the working group is confident in its draft, does not mean that feedback has not, cannot, and will not continue to be integrated during the review period.

Zulip Feedback

If the Zulip discussions are not working for folks, we're more than happy to switch to GitHub issues to try to collect feedback in a more structured manner.

Also, folks are more than welcome to post here, like you did. We just wanted to avoid mixed streams of comments causing the discussion becoming impossible to follow.

[Manishearth]

(I'm not an author of this RFC, but I have been observing their progress and given feedback a couple times whilst it was circulated amongst leadership)

I'd like to add that I don't think drafting in private is fundamentally a lack of openness, and can often be more effective at achieving the goal of openness. RFCs are live discussion documents, it does not matter all too much who was consulted for creating the doc as long as the following two things are true:

• The motivation behind decisions in the RFC is either evident in the RFC or can be provided upon request¹
• Nothing in the RFC is considered set in stone and the RFC can change based on the consensus reached during the RFC process. The RFC is a starting point though people are free to try and make the starting point as solid as they can.

My perception is that both are true here (especially from Ryan's comment above).

After all, when an individual writes an RFC, they have often drafted it "in private" in their minds before posting it.

As @rylev mentioned this RFC is a very high-context one, and a risk with drafting it in public is that it's way harder for people to know what kind of feedback is necessary at what stage; someone might read it, not understand that some areas are still pending some work, and engage with the perceived flaws. This situation is a disservice to everyone: the people who are pouring time into this have to spend time communicating, and this individual has just spent time tilting at a windmill. This ends up looking more open but really not being so because only the people with all the context can contribute constructively. This is a bit of a common failure mode in the Rust community and a lot of the bigger RFCs these days tend to be polished up before they hit the repo.

I think it's good to give more structure to the open community input process by starting with a solid, coherent document and soliciting feedback from there, especially if targeted feedback is sought during the original drafting (which it was, pretty extensively).

I do think it is possible to do the targeted-feedback-drafting thing purely in the open too (being very clear at each stage as to what engagement should look like), but I don't actually think it gets you much and I think that would have taken way, way longer.

It took way too long.

Also just to provide an alternate perspective on this; I feel like Rust has been working on its governance for ages, and has multiple iterations of a governance WG as well as governance efforts within core that never made it to the stage of an actual RFC. Personally, I didn't expect it to be much faster than this, and really expected it to take longer to even get to the RFC stage.

Footnotes

1. It's nigh impossible to condense the meat of every discussion leading up to an RFC into an RFC itself, so it seems fine to not try to include everything and do it on-demand, though fundamentals should absolutely be contextualized in the original RFC. ↩

[pnkfelix]

I have two main pieces of feedback regarding this RFC, which I have already shared privately with some of its authors, but I'll now post publicly.

1. Broad issue: building upon what others have already said about the known difficulty within the project of finding human beings to do the requested work: the RFC has laid out a number of constraints (e.g. limits w.r.t. affiliation, plus one representative per top-level team) that complicate the problem, but another big issue is something the RFC has left unaddressed: There is no stated upper-bounds, or even a rough target, on how much of a time commitment is expected for a representative serving on the leadership council. How can we ask people to sign up for this without giving any clue as to what they're signing up for ? Will there be limits on the amount of raw text that every representative is expected to consume as part of their role? (Insert witty reference to Blaise Pascal here.)
   • One might make a guess as to what the time commitment will be is going to be based how much effort was put into this RFC and the resulting size of the RFC text; but that guess does not bode well. (One can well argue that this would be a bad basis for a guess, given the amount of emphasis the RFC text has put on both delegation and structured process, which should hopefully lighten the load for the representatives themselves.)
2. Narrow cornercase: I am not 100% clear on when the criteria when the co-affiliation limit drops from at most two to at most one. In particular: if one or more reps from top-level teams are not attending meetings and are otherwise not engaged, such that only five reps are effectively present, does that cause the limit to drop to one? (If so, I can imagine a chain reaction where you think you have six or more members, but the number actively present in the conversation is actually five, and then you end up actually having to disqualify two of them.)

However, I do not feel strongly enough about either of these issues to believe they warrant registering a formal concern with this RFC. I would like them to be addressed in the future in some manner, but that can be part of the work undertaken by the leadership council over the course of its operations and/or establishment of policy.

@rfcbot reviewed

[sophiajt]

Next Steps

Greetings all. First off, a big 'thank you!' to everyone who took the time to review, give thoughtful feedback, and iterate on this document with us. We appreciate your attention to detail but most of all the care you showed the project.

Now that all checkboxes have been checked by the stakeholders, the next step will be to prepare for FCP. We (the Governance WG) have two things we would like to do before it begins: prepare a role description of what a Council member would be like to help teams choose their representative and make sure we've addressed any last comments or concerns.

Once FCP begins, top-level teams will be able to officially select their initial representation on the Council. The Governance WG would be happy to assist this process any way we can, including joining your team's meeting to talk through the Council and answer any questions you have.

The FCP time period will continue until all top-level teams have chosen their representation. Please do not feel rushed during this time, as it's important to follow your team's process for selecting representation. After the initial Council has been selected, we will land this RFC and the Council will step in and begin functioning. Those of us on the Rust Core team will step down at the same time and hand over leadership responsibilities to the Council.

As I mentioned earlier, we're happy to answer any questions you might have.

[joshtriplett]

A further note on representative selection: as there's a limit of two representatives with any given affiliation, teams should coordinate with each other as they start to determine likely representatives, to give potential representatives with the same affiliation sufficient time to coordinate with each other and work with their teams to find alternate candidates.

[rylev]

Thank you to everyone who has given feedback here, in Zulip, and in 1 on 1 discussions! Before we enter FCP, I'd like to take one final opportunity to talk to the feedback we've received and how the governance RFC working group hopes these issues will be addressed in the future.

While we have taken the opportunity to adjust the RFC due to feedback, we did not perceive any feedback as blocking objections or as requests to change the fundamental direction of the RFC. This is not to say that there are not plenty of open questions and legitimate concerns, but these questions and concerns will best be answered by having a solid base for governance with a strong mandate for evolution and adaptation. It remains our belief that this RFC provides that foundation.

Moderation Oversight

The moderation team and Council share a special relationship in that they each have the power to dissolve the other (and themselves) if their working relationship breaks down. While this is far from an ideal, it does provide a "break glass" mechanism that should ensure we don't hit undefined behavior in the face of a complete breakdown in trust between the teams.

As time goes forward, the RFC mandates that the moderation team must have robust policies and procedures and that the council is charged with ensuring that the moderation team delivers on this obligation. We hope to see many future RFCs that refine this process and ensure additional layers of oversight over moderation policy.

Addressing this large topic in this RFC would balloon the complexity of the RFC and introduce substantial delays. In the spirit of not letting perfect be the enemy of good enough for now, we look to future work to ensure that the moderation team operates by well documented and robust policies and procedures.

Transparency

Introducing transparency into how a team operates takes a lot of work. There was much discussion of whether the governance RFC working group and the interim "leadership chat" were transparent enough during their existence.

The working group cooperated extensively with project leaders, the wider Rust project, and members of the Rust community. They were consistently updated on the progress, and a large number of stakeholders were actively involved. Additionally, we invited feedback throughout the process and acknowledged that our limited openness was a deliberate choice and explained our reasoning. However, it is indisputable that the working group could have implemented additional measures to improve transparency.

This RFC goes through great lengths to ensure that the Council has the right set of expectations to ensure transparency when appropriate, and we believe that going forward the accountability mechanisms will ensure that the Council lives up to this obligation.

Enough Participation

It has been a common concern that it will be difficult to find enough people to fill the positions necessary to make this Council work. We believe this concern is legitimate. However, we also believe that potential lack of participation is not truly a potential issue with this proposal but a reality that the Rust project will always have to wrestle with. No matter how we chose to govern the Rust project, finding people to participate in that governance will always be an issue.

This RFC acknowledges this fact and encourages the Council to immediately begin trying to foster more participation from folks with skills needed to effectively govern. This problem will only go away if we actively work to find solutions to making it better.

A related concern is finding people who are in a position to be trusted with the work and authority being entrusted in them. This is a similar concern that requires active work to help solve. Again, we do not see this as an issue with this proposal but a fundamental problem within the Rust project that must be solved no matter what governance structure we assume.

The Project's Obligations to the Wider Community

The council's first and primary obligation is the health of the Rust project and our ability to maintain the language and related artifacts. Core to this obligation is the well-being of the project members. This RFC prioritizes the needs of the project and project members so that they have the capacity to help support the wider community.

What's more, the project is not independent from the community. It is made up entirely of community members. And it should go without saying that the without the Rust community the Rust project would have no purpose.

However, at the end of the day, this RFC is about how the project can best govern itself. It does not touch on deeper topics of the goals, mission, and raison d'etre of the Rust project which we believe would best be served by a future RFC.

[khionu]

This is the current role description for Council Representatives. This isn't a set-in-stone description; it's expected that the Council will evolve this over time as the concrete details settle into place. The Council will also find a long-term place to keep this and other living documents.

Role Description: Council Representative

• Aims
  • Represent the needs and interests of the team and subteams you represent within the Council.
  • Represent the needs of the Rust Project at large within the team and subteams you represent.
  • Ensure effective communication, collaboration, and coordination among teams.
  • Work towards the long-term success of the Rust Project.
• Time Budget
  • TBD (based on core team members' experience)
    • JT estimate: < 5hr/week on average
    • rylev comment: This is likely to be higher during initial setup of the council
• Tasks / Activities / Responsibilities
  • Participate in Council meetings, discussions, and decision-making processes.
  • For the initial term especially: design and establish many initial Council processes and policies.
  • Provide updates on Council activities and decisions to the team and subteams.
  • Solicit feedback on Council proposals, decisions, and relevant matters from the team and subteams, and communicate feedback and objections to the Council.
  • Collaborate with other Council Representatives to identify, prioritize, and delegate work beyond established team purviews.
  • Assist in coordinating cross-team efforts, roadmaps, and long-term Project success.
  • Establish and maintain the Rust Project's official mission, vision, aims, positions, and opinions.
  • Coordinate Project-wide changes to teams, structures, or processes.
  • Make decisions on urgent matters when necessary.
• Qualities of a Council member (required skills)
  • Desire to lean into conflict and its transformation into a healthy part of collaboration.
    • Ability to collaboratively introspect one's own values and those of others, to seek out understanding and consensus.
  • Strong understanding of the Rust Project, its teams, processes, and ecosystem.
  • Ability to prioritize others' needs, representing all viewpoints from their team.
  • Ability to collaborate, communicate, delegate, and work effectively within diverse teams.
  • Interest in contributing to Project operations and governance, with sufficient time and energy to dedicate to Council needs.
  • Familiar with the needs of their team and subteams.
  • Time management and task prioritization abilities.
  • Commitment to evolving with the changing needs of the project.
  • For the initial term especially: ability to work in a low-structure environment and help construct necessary structure incrementally.
• Minimum/maximum terms
  • 1 year term
  • Soft limit of 3 consecutive years - rotation encouraged

Notes about representative selection

Many of the same qualities that make a good Council representative also make a good team lead. However, we strongly recommend against individuals taking on both the role of team lead and Council representative simultaneously. In the past, our experience has shown that it is extremely difficult to balance the demands of both roles effectively. For teams with shared leadership responsibilities (e.g. co-leads), assigning one co-lead as the representative may be fine if the other co-lead(s) are prepared to take on more of the team leadership responsibilities. However, for teams with a single lead, we recommend either establishing multiple clearly delineated team leadership roles or selecting a different Council representative.

Remember that Council representatives can be subteam members, if a subteam member has the requisite scope and skillset. (Note, though, that any subteam member who has the requisite scope and skills to represent the top-level team on the Council should almost certainly be invited to join the top-level team.)

Representative selection should ideally be done by consensus, not by vote or similar. Further experimentation with process will be needed, but one possible suggested process is:

• Select a facilitator by consent:
  • Any team member can suggest a facilitator or volunteer themselves.
  • The facilitator must not be a candidate for the Council representative, and must be someone everyone trusts to set aside their preferences during the selection process.
• Request nominations from the team and subteams:
  • Facilitator asks for nominations, including self-nominations.
  • Nominations should be accompanied by supporting reasoning.
  • Anyone can share concerns about nominees privately with the facilitator or other trusted team members, but objections happen later in the process.
• Discuss the nominated candidates:
  • Team members have the opportunity to discuss nominations.
  • Nominations can be withdrawn or added during this time.
• Facilitator proposes a candidate:
  • Based on gathered data, the facilitator suggests a candidate they believe is likely to receive the group's consent.
• Seek objections to the facilitator's proposal:
  • Team members can provide objections, which may be submitted privately or anonymously if desired.
• Finalize representative selection:
  • Discuss and attempt to resolve any objections, if possible.
  • If the proposed candidate has no remaining objections, select them as the Council representative.
  • If objections persist and the current proposal reaches an impasse, the facilitator should make a new proposal based on the discussion and feedback received.
  • Continue the process of seeking consensus and addressing objections until a satisfactory candidate is selected.
    • Note that this process seeks to produce a candidate everyone is satisfied with and has no objections to. Avoid lengthy debates over preferences that do not pertain to objections or unmet requirements.

[nrc]

Time Budget

TBD (based on core team members' experience)
JT estimate: < 5hr/week on average

This seems extremely low based on my core team experience. Including time spent gathering sentiment/news/etc, as well as thinking time, meetings, and time actually doing stuff, I would expect 16-20 hours to be realistic if the council is going to be proactive (and assuming some amount of time spent in WGs which the council is delegating to). And more time initially (as noted).

Tasks / Activities / Responsibilities

My reading of the RFC was that many of these tasks should be delegated to new groups?

Note, though, that any subteam member who has the requisite scope and skills to represent the top-level team on the Council should almost certainly be invited to join the top-level team

This is making some assumptions about how teams/sub-teams are run and organised that I don't think are true for all teams.

[sophiajt]

@nrc - Yes, agreed. If you add up the time that includes both your time working in the Council meeting with the time spent inside of your team's meetings or in team chat gathering information, you'll get a higher number. For my estimate, I was trying to estimate specifically the bandwidth of doing the Council meeting and responding to conversations the Council is having about the area that you may be the specific point-person on.

For folks looking to have an estimate of all activities, which may overlap with team activities, I would encourage the higher estimate as what Nick points out. We also anticipate that the earlier period of the Council to require more time while things are getting setup.

[sophiajt]

FCP begins

Greetings all. With this, we've now met the requirements for FCP. All teams are now ready to select their representatives, comments have been addressed, and we have posted the role description for a Council representative.

Now that FCP has begun, teams can officially select their representative. The FCP period will continue until all representatives have been chosen. If you have any question during this process, please feel free to reach out to anyone on the Governance WG team. Some of the other details of the FCP period are covered in our previous post, so please check that out as well.

@rfcbot fcp merge

[yaahc]

@rfcbot resolved require-all-checkmarks

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period, with a disposition to merge, as per the review above, is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed.

This will be merged soon.

[sanbox-irl]

FCP begins

The FCP period will continue until all representatives have been chosen.

Where can we see the progress on this front?

[Manishearth]

The individual team channels on Zulip/etc are where most of the selection has been running. There is no one place showing all of the progress. For example, for devtools (the team I lead), Eric Huss was nominated and selected, and you can see that process here.

At the moment, two teams still need to select candidates: Launching Pad and Lang. I don't think Lang is running selections in the public Zulip channel, but I could be wrong, since I'm not really familiar with how the lang team does stuff.

[digama0]

A Zulip thread on lang team selection was opened here.

[sanbox-irl]

Looks like as of this morning, Lang Team https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/selecting.20a.20lang.20team.20rep/near/362737733 and Launching Pad https://rust-lang.zulipchat.com/#narrow/stream/384197-t-launching-pad/topic/Council.20Representative.20-.20Open.20for.20Nominations/near/362409210 have made selections. I'm only reading over the channels later, so I'm not sure if those are totally decided yet/what that process it, but looks good to me

[Mark-Simulacrum]

The council had its initial meeting a few hours ago, and we're now ready to merge the RFC. Some of the structures for council operation are being spun up as we speak (e.g., Zulip #council stream), expect to see more soon.