Add RFC on governance, establishing the Leadership Council by jntrnr · Pull Requ...
source link: https://github.com/rust-lang/rfcs/pull/3392
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Add RFC on governance, establishing the Leadership Council #3392
Conversation
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:
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
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
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
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
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
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
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
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
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.
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK