diff --git a/text/3392-leadership-council.md b/text/3392-leadership-council.md new file mode 100644 index 00000000000..ad826034d43 --- /dev/null +++ b/text/3392-leadership-council.md @@ -0,0 +1,665 @@ +- Feature Name: leadership-council +- Start Date: 2022-08-01 +- RFC PR: [rust-lang/rfcs#3392](https://github.com/rust-lang/rfcs/pull/3392) +- Rust Issue: N/A + +# Summary + +This RFC establishes a Leadership Council as the successor of the core team[^core] and the new governance structure through which Rust Project members collectively confer the authority[^authority] to ensure successful operation of the Project. The Leadership Council delegates much of this authority to teams (which includes subteams, working groups, etc.[^teams]) who autonomously make decisions concerning their purviews. However, the Council retains some decision-making authority, outlined and delimited by this RFC. + +The Council will be composed of representatives delegated to the Council from each [top-level team][top-level-teams]. + +The Council is charged with the success of the Rust Project as a whole. The Council will identify work that needs to be done but does not yet have a clear owner, create new teams to accomplish this work, hold existing teams accountable for the work in their purview, and coordinate and adjust the organizational structure of Project teams. + +# Outline + +- [Reference materials](#reference-materials) +- [Motivation](#motivation) +- [Duties, expectations, and constraints on the Council](#duties-expectations-and-constraints-on-the-council) +- [Structure of the Council](#structure-of-the-council) + - [Top-level teams](#top-level-teams) + - [Initial list of top-level teams](#initial-list-of-top-level-teams) + - [The "launching pad" top-level team](#the-launching-pad-top-level-team) + - [Removing top-level teams](#removing-top-level-teams) + - [Alternates and forgoing representation](#alternates-and-forgoing-representation) + - [Term limits](#term-limits) + - [Limits on representatives from a single company/entity](#limits-on-representatives-from-a-single-companyentity) + - [Candidate criteria](#candidate-criteria) + - [Relationship to the core team](#relationship-to-the-core-team) + - [Relationship to the Rust Foundation](#relationship-to-the-rust-foundation) +- [The Council's decision-making process](#the-councils-decision-making-process) + - [Operational vs policy decisions](#operational-vs-policy-decisions) + - [Repetition and exceptions](#repetition-and-exceptions) + - [The consent decision-making process](#the-consent-decision-making-process) + - [Approval criteria](#approval-criteria) + - [Modifying and tuning the decision-making process](#modifying-and-tuning-the-decision-making-process) + - [Agenda and backlog](#agenda-and-backlog) + - [Deadlock resolution](#deadlock-resolution) + - [Feedback and evaluation](#feedback-and-evaluation) +- [Transparency and oversight for decision making](#transparency-and-oversight-for-decision-making) + - [Decisions that the Council may make internally](#decisions-that-the-council-may-make-internally) + - [Decisions that the Council must necessarily make privately](#decisions-that-the-council-must-necessarily-make-privately) + - [Decisions that the Council must make via public proposal](#decisions-that-the-council-must-make-via-public-proposal) + - [Conflicts of interest](#conflicts-of-interest) + - [Determining and changing team purviews](#determining-and-changing-team-purviews) +- [Mechanisms for oversight and accountability](#mechanisms-for-oversight-and-accountability) + - [Ensuring the Council is accountable](#ensuring-the-council-is-accountable) + - [Ensuring Council representatives are accountable](#ensuring-council-representatives-are-accountable) + - [Ensuring teams are accountable](#ensuring-teams-are-accountable) +- [Moderation, disagreements, and conflicts](#moderation-disagreements-and-conflicts) + - [Disagreements among teams](#disagreements-among-teams) + - [Conflicts involving teams or Project members](#conflicts-involving-teams-or-project-members) + - [Contingent moderators](#contingent-moderators) + - [Moderation team policies and procedures](#moderation-team-policies-and-procedures) + - [Audits](#audits) + - [Last-resort accountability](#last-resort-accountability) + - [Moderation actions involving Project members](#moderation-actions-involving-project-members) + - [Conflicts involving Council representatives](#conflicts-involving-council-representatives) + - [Conflicts involving moderation team members](#conflicts-involving-moderation-team-members) +- [Ratification of this RFC](#ratification-of-this-rfc) +- [Footnotes](#footnotes) + +# Reference materials + +To reduce the size of this RFC, non-binding reference materials appear in separate documents: + +- [Full motivation](3392-leadership-council/motivation.md) + - [Further research into the needs of Project-wide governance (Inside Rust blog post)](https://blog.rust-lang.org/inside-rust/2022/05/19/governance-update.html) +- [Non-goals of this RFC](3392-leadership-council/non-goals.md) +- [Rationale and alternatives](3392-leadership-council/alternatives.md) +- [Recommendations for initial work of the Council](3392-leadership-council/initial-work-of-the-council.md) + +# Motivation + +The Rust project consists of hundreds of globally distributed people, organized into teams with various purviews. However, a great deal of work falls outside the purview of any established team, and still needs to get done. + +Historically, the core team both identified and prioritized 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 + +At a high-level, the Council is *only* in charge of the following duties: + +- Identifying, prioritizing, and tracking work that goes undone due to lack of clear ownership (and not due to the owners' explicit de-prioritization, placement in a backlog, etc.). +- Delegating this work, potentially establishing new (and possibly *temporary*) teams to own this work. +- Making decisions on *urgent* matters that do not have a clear owner. + - This should only be done in exceptional circumstances where the decision cannot be delegated either to existing teams or to newly created ones. +- Coordinating Project-wide changes to teams, structures, or processes. +- Ensuring top-level teams are accountable to their purviews, to other teams, and to the Project. +- Ensuring where possible that teams have the people and resources they need to accomplish their work. +- Establishing the official position, opinion, or will of the Rust Project as a whole. + - This helps reduce the need for Project-wide coordination, especially when a long public polling and consensus-building process is not practical - for example, when communicating with third parties who require some understanding of what the Rust Project as a whole "wants". + +In addition to these duties, the Council has additional expectations and constraints, to help determine if the Council is functioning properly: + +- *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. +- *Ensure the Project runs smoothly in the long term*: The Council should ensure that non-urgent Project management work is prioritized and completed with enough regularity that the Project does not accumulate organizational debt. +- *Be Accountable*: As the Council wields broad power, the Council and Council representatives must be accountable for their actions. They should listen to others' feedback, and actively reflect on whether they continue to meet the duties and expectations of the position they hold. +- *Be representational*: Council representatives should not only represent the breadth of Project concerns but also the diversity of the Rust community in as many aspects as possible (demographics, technical background, etc). +- *Share burden*: All Council representatives must share burden of Council duties. +- *Respect others' purviews*: The Council must respect the purviews delegated to teams. The Council should consult with and work together with teams on solutions to issues, and should almost never make decisions that go against the wishes of any given team. +- *Act in good faith*: Council representatives should make decisions in the best interest of the Rust Project *as a whole* even if those decisions come into conflict with their individual teams, their employers, or other outside interests. +- *Be transparent*: While not all decisions (or all aspects of a decision) can be made public, the Council should be as open and transparent about their decision-making as possible. The Council should also ensure the organizational structure of the Project is clear and transparent. +- *Respect privacy*: The Council must never compromise personal or confidential information for the sake of transparency, including adjacent information that could unintentionally disclose privileged information. +- *Foster a healthy working environment*: The Council representatives should all feel satisfied with the amount and nature of their contribution. They should not feel that their presence on the Council is merely out of obligation but rather because they are actively participating in a meaningful way. +- *Evolve*: The Council is expected to evolve over time to meet the evolving needs of teams, the Project, and the community. + +Council representatives, moderation team members, and other Project members serve as examples for those around them and the broader community. All of these roles represent positions of responsibility and leadership; their actions carry weight and can exert great force within the community, and should be wielded with due care. People choosing to serve in these roles should thus recognize that those around them will hold them to a correspondingly high standard. + +# Structure of the Council + +The Council consists of a set of team representatives, each representing one [top-level team][top-level-teams] and its subteams. + +Each top-level team designates exactly one representative, by a process of their choice. + +Any member of the top-level team or a member of any of their subteams is eligible to be the representative. Teams should provide members of their subteams with an opportunity for input and feedback on potential candidates. + +Each representative represents at most one top-level team, even if they're also a member of other teams. The primary responsibility of representing any Rust team falls to the representative of the top-level team they fall under.[^under-multiple-teams] + +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][launching-pad] as a temporary home. This ensures that all teams have representation on the Council. + +## Top-level teams +[top-level-teams]: #top-level-teams + +The Council establishes top-level teams via public policy decisions. In general, top-level teams should meet the following criteria: +- Have a purview that is foundational to the Rust Project +- Be the ultimate decision-makers on all aspects of that purview +- Have a purview that not is a subset of another team's purview (that is, it must not be a subteam or similar governance structure) +- Have an open-ended purview that's expected to continue indefinitely +- Be a currently active part of the Rust Project + +There must be between 4 and 9 top-level teams (inclusive), preferably between 5 and 8. This number balances the desire for a diverse and relatively shallow structure while still being practical for productive conversation and consent.[^number-of-representatives] + +When the Council creates a new top-level team, that team then designates a Council representative.[^bootstrapping-new-teams] When creating a new top-level team, the Council must provide justification for why it should not be a subteam or other governance structure. + +### Initial list of top-level teams + +The initial list of top-level teams is formed from all teams listed on [the rust-lang.org website's top-level governance section](https://www.rust-lang.org/governance) (besides core and alumni) at the time of initial publication of this RFC, plus the ["launching pad" team][launching-pad]: +- Compiler +- Crates.io +- Dev tools +- Infrastructure +- Language +- Launching Pad +- Library +- Moderation +- Release + +This list is not an optimal set of top-level teams. This RFC recommends that the first order of business of the Council be to go through existing governance structures and ensure that all structures have representation either directly or indirectly through one or more top-level teams as well as ensure that all top-level teams sufficiently meet the criteria for being considered a top-level team. This will involve modifying the set of top-level teams. + +### The "launching pad" top-level team +[launching-pad]: #the-launching-pad-top-level-team + +This RFC establishes the "launching pad" team to *temporarily* accept subteams that otherwise do not have a top-level team to slot underneath of. This ensures that all teams have representation on the Council, while more permanent parent teams are found or established. + +The "launching pad" team is an umbrella team: it has no direct members, only subteam representatives. + +The Council should work to find or create a more appropriate parent for each subteam of the "launching pad", and subsequently move those subteams to their new parent team. + +In some cases, an appropriate parent team may exist but not yet be ready to accept subteams; the launching pad can serve as an interim home in such cases. + +The launching pad also serves as a default home for subteams of a team that's removed or reorganized away, if that removal or reorganization does not explicitly place those subteams somewhere else in the organization. + +The Council must review subteam membership in the "launching pad" every 6 months to ensure that proper progress is being made on finding all subteams new parent teams. As with other top-level teams, the "launching pad" team can be retired (and have its representation within the Council removed) if the Council finds it to be no longer necessary. The process for retiring the "launching pad" team is the same as with other top-level teams. Alternatively, the Council is free to give the "launching pad" team its own purview, but doing so is out of scope for this RFC. + +### Removing top-level teams + +Any decision to remove a team's top-level designation (or otherwise affect eligibility for the Council) requires the consent of all Council representatives, with the exception of the representative of the top-level team being removed. Despite this caveat, the representative of the team under consideration must be invited to Council deliberations concerning the team's removal, and the Council should only remove a team over their objections in extreme cases. + +The Council cannot remove the moderation team. The Council cannot change the moderation team's purview without the agreement of the moderation team. + +## Alternates and forgoing representation + +A representative may end their term early if necessary, such as due to changes in their availability or circumstances. The respective top-level team must then begin selecting a new representative. The role of representative is a volunteer position. No one is obligated to fill that role, and no team is permitted to make serving as a representative a necessary obligation of membership in a team. However, a representative is obligated to fulfill the duties of the position of representative, or resign that position. + +A top-level team may decide to temporarily relinquish their representation, such as if the team is temporarily understaffed and they have no willing representative. However, if the team does not designate a Council representative, they forgo their right to actively participate in decision-making at a Project-wide level. All Council procedures including decision-making should not be blocked due to this omission. The Council is still obligated to consider new information and objections from all Project members. However, the Council is not obligated to block decisions to specially consider or collate a non-represented team's feedback. + +Sending a representative to the Council is considered a duty of a top-level team, and not being able to regularly do so means the team is not fulfilling its duties. However, a Council representative does not relinquish their role in cases of short absence due to temporary illness, vacation, etc. + +A top-level team can designate an alternate representative to serve in the event their primary representative is unavailable. This alternate assumes the full role of Council representative until the return of the primary representative. Alternate representatives do not regularly attend meetings when the primary representative is present (to avoid doubling the number of attendees). + +If a team's representative *and* any alternates fail to participate in any Council proceedings for 3 consecutive weeks, the team's representative ceases to count towards the decision-making quorum requirements of the Council until the team can provide a representative able to participate. The Council must notify the team of this before it takes effect. If a team wishes to ensure the Council does not make decisions without their input or without an ability for objections to be made on their behalf, they should ensure they have an alternate representative available. + +A top-level team may change their representative before the end of their term, if necessary. However, as maintaining continuity incurs overhead, teams should avoid changing their representatives more than necessary. Teams have the primary responsibility for briefing their representative and alternates on team-specific issues or positions they wish to handle on an ongoing basis. The Council and team share the responsibilities of maintaining continuity for ongoing issues within the Council, and of providing context to alternates and other new representatives. + +For private matters, the Council should exercise discretion on informing alternates, to avoid spreading private information unnecessarily; the Council can brief alternates if they need to step in. + +## Term limits + +Council representatives' terms are one year in length. Each representative has a soft limit of three consecutive full terms for any given representative delegation (the delegation from a particular top-level team). A representative may exceed this soft limit if and only if the Council receives explicit confirmation from the respective team that they are unable to produce a different team member as a representative (for example, due to lack of a willing alternative candidate, or due to team members having blocking objections to any other candidate). + +Beyond this, there is no hard limit on the number of terms a representative can serve for other top-level teams or non-consecutive terms for a single top-level team. Teams should strive for a balance between continuity of experience and rotating representatives to provide multiple people with such experience.[^representative-selection] + +Half of the representative appointments shall happen at the end of March while half shall happen at the end of September. This avoids changing all Council representatives at the same time. For the initial Council, and anytime the set of top-level teams is changed, the Council and top-level teams should work together to keep term end-dates roughly evenly divided between March and September. However, each term should last for a minimum of 6 months (temporary imbalance is acceptable to avoid excessively short terms). + +If the Council and top-level teams cannot agree on appropriate term end-date changes, representatives are randomly assigned to one or the other end date (at least 6 months out) to maintain balance. + +## Limits on representatives from a single company/entity + +Council representatives must not disproportionately come from any one company, legal entity, or closely related set of legal entities, to avoid impropriety or the appearance of impropriety. If the Council has 5 or fewer representatives, no more than 1 representative may have any given affiliation; if the Council has 6 or more representatives, no more than 2 representatives may have any given affiliation. + +Closely related legal entities include branches/divisions/subsidiaries of the same entity, entities connected through substantial ownership interests, or similar. The Council may make a judgment call in unusual cases, taking care to avoid conflicts of interest in that decision. + +A Council representative is affiliated with a company or other legal entity if they derive a substantive fraction of their income from that entity (such as from an employer, client, or major sponsor). Representatives must promptly disclose changes in their affiliations. + +If this constraint does not hold, whether by a representative changing affiliation, top-level teams appointing new representatives, or the Council size changing, restore the constraint as follows: +- Representatives with the same affiliation may first attempt to resolve the issue amongst themselves, such that a representative voluntarily steps down and their team appoints someone else. + - This must be a decision by the representative, not their affiliated entity; it is considered improper for the affiliated entity to influence this decision. + - Representatives have equal standing in such a discussion; factors such as seniority in the Project or the Council must not be used to pressure people. +- If the representatives with that affiliation cannot agree, one such representative is removed at random. (If the constraint still does not hold, the remaining representatives may again attempt to resolve the issue amongst themselves before repeating this.) This is likely to produce suboptimal results; a voluntary solution will typically be preferable. +- While a team should immediately begin the process of selecting a successor, the team's existing representative may continue to serve up to 3 months of their remaining term. +- The existing representative should coordinate the transition with the incoming representative but it is the team's choice which one is an actual representative during the up to 3 month window. There is only ever one representative from the top-level team. + +## Candidate criteria + +The following are criteria for deciding ideal candidates. These are similar to but not the same as the criteria for an effective team lead or co-lead. While a team lead *might* also make a good Council representative, serving as a team lead and serving as a Council representative both require a substantial time investment, which likely motivates dividing those roles among different people. The criteria are not hard requirements but can be used for determining who is best positioned to be a team's representative. In short, the representative should have: +- sufficient time and energy to dedicate to the needs of the Council. +- an interest in helping with the topics of Project operations and Project governance. +- broad awareness of the needs of the Project outside of their teams or areas of active contribution. +- a keen sense of the needs of their team. +- the temperament and ability to represent and center the needs of others above any personal agenda. +- ability and willingness to represent all viewpoints from their team, not just a subset, and not just those they agree with. + +While some teams may not currently have an abundance of candidates who fit this criteria, the Council should actively foster such skills within the larger Project, as these are helpful not only for Council membership but across the entire Project. + +## Relationship to the core team + +The Leadership Council serves as the successor to the core team in all capacities. This RFC was developed with the participation and experience of the core team members, and the Council should continue seeking such input and institutional memory when possible, especially while ramping up. + +External entities or processes may have references to "the Rust core team" in various capacities. The Council doesn't use the term "core team", but the Council will serve in that capacity for the purposes of any such external references. + +The core team currently has access to credentials for various Project accounts, in addition to the infrastructure team. As the Council is not expected to need these credentials, they will not be transferred from the core team into Council ownership, instead residing solely with the infrastructure team[^infra-creds]. The infrastructure team's responsibilities include ensuring teams have the tools and access needed to do their work effectively, while balancing against security and maintainability of our infrastructure. The Council can help coordinate which teams should have access through policy. + +## Relationship to the Rust Foundation + +The Council is responsible for establishing the process for selecting Project directors. The Project directors are the mechanism by which the Rust Project's interests are reflected on the Rust Foundation board. + +The Council delegates a purview to the Project directors to represent the Project's interests on the Foundation Board and to make certain decisions on Foundation-related matters. The exact boundaries of that purview are out of scope for this RFC. + +# The Council's decision-making process +[decision-making]: #the-council-s-decision-making-process + +The Leadership Council make decisions of two different types: operational decisions and policy decisions. Certain considerations may be placed on a given decision depending on its classification. However, by default, the Council will use a consent decision-making process for all decisions regardless of classification. + +## Operational vs policy decisions + +Operational decisions are made on a daily basis by the Council to carry out their aims, including regular actions taking place outside of meetings (based on established policy). Policy decisions provide general reusable patterns or frameworks, meant to frame, guide, and support operations. In particular, policy decisions can provide partial automation for operational decisions or other aspects of operations. The council defaults to the consent decision making process for all decisions unless otherwise specified in this RFC or other policy. + +This RFC does not attempt to precisely define which decisions are operations versus policy; rather, they fall somewhere along a continuum. The purpose of this distinction is not to direct or constrain the council's decision-making procedures. Instead, this distinction provides guidance to the Council, and clarifies how the Council intends to record, review, and refine its decisions over time. For the purposes of any requirements or guidance associated with the operational/policy classification, anything not labeled as either operational or policy in this or future policy defaults to policy. + +## Repetition and exceptions +[repetition-and-exceptions]: #repetition-and-exceptions + +Policy decisions often systematically address what might otherwise require repeated operational decisions. The Council should strive to recognize when repeated operational decisions indicate the need for a policy decision, or a policy change. In particular, the Council should avoid allowing repeated operational decisions to constitute de facto policy. + +Exceptions to existing policy cannot be made via an operational decision unless such exceptions are explicitly allowed in said policy. Avoiding ad-hoc exceptions helps avoid ["normalization of deviance"](https://en.wikipedia.org/wiki/Normalization_of_deviance). + +## The consent decision-making process + +The Council will initially be created with a single process for determining agreement to a proposal. It is however expected that the Council will add additional processes to its toolbox soon after creation. + +Consent means that no representative's requirements (and thus those of the top-level team and subteams they represent) can be disregarded. The Council hears all relevant input and sets a good foundation for working together equitably with all voices weighted equally. + +The Council uses consent decision-making where instead of being asked "do you agree?", representatives are asked "do you object?". This eliminates "pocket vetoes" where people have fully reviewed a proposal but decide against approving it without giving clear feedback as to the reason. Concerns, feedback, preferences, and other less critical forms of feedback do not prevent making a decision, but should still be considered for incorporation earlier in drafting and discussion. Objections, representing an unmet requirement or need, *must* be considered and resolved to proceed with a decision. + +### Approval criteria + +The consent decision-making process has the following approval criteria: +- Posting the proposal in one of the Leadership Council's designated communication spaces (a meeting or a specific channel). +- Having confirmation that at least N-2 Council representatives (where N is the total number of Council representatives) have fully reviewed the final proposal and give their consent. +- Having no outstanding explicit objections from any Council representative. +- Providing a minimum 10 days for feedback. + +The approval criteria provides a quorum mechanism, as well as sufficient time for representatives to have seen the proposal. Allowing for two non-signoffs is an acknowledgement of the volunteer nature of the Project, based on experience balancing the speed of decisions with the amount of confirmation needed for consent and non-objection; this assumes that those representatives have had time to object if they wished to do so. (This is modeled after the process used today for approval of RFCs.) + +The decision-making process can end at any time if the representative proposing it decides to retract their proposal. Another representative can always adopt a proposal to keep it alive. + +If conflicts of interest result in the Council being unable to meet the N-2 quorum for a decision, the Council cannot make that decision unless it follows the process documented in [the "Conflicts of interest" section for how a decision may proceed with conflicts documented][conflicts-of-interest]. In such a case, the Council should consider appropriate processes and policies to avoid future recurrences of a similar conflict. + +## Modifying and tuning the decision-making process + +Using the public policy process, the Council can establish different decision-making processes for classes of decisions. + +For example, the Council will almost certainly also want a mechanism for quick decision-making on a subset of operational decisions, without having to wait for all representatives to affirmatively respond. This RFC doesn't define such a mechanism, but recommends that the Council develop one as one of its first actions. + +When deciding on which decision-making process to adopt for a particular class of decision, the Council balances the need for quick decisions with the importance of confidence in full alignment. Consent decision-making processes fall on the following spectrum: + +- Consensus decision making (prioritizes confidence in full alignment at the expense of quick decision making): team members must review and prefer the proposal over all others, any team members may raise a blocking objection +- Consent decision making (default for the Council, balances quick decisions and confidence in alignment): team members must review and may raise a blocking objection +- One second and no objections (prioritizes quick decision making at the expense of confidence in alignment): one team member must review and support, any team member may raise a blocking objection + +Any policy that defines decision-making processes must at a minimum address where the proposal may be posted, quorum requirements, number of reviews required, and minimum time delay for feedback. A lack of objections is part of the approval criteria for all decision-making processes. + +If conflicts of interest prevent more than a third of the Council from participating in a decision, the Council cannot make that decision unless it follows the process documented in [the "Conflicts of interest" section for how a decision may proceed with conflicts documented][conflicts-of-interest]. (This is true regardless of any other quorum requirements for the decision-making process in use.) In such a case, the Council should consider appropriate processes and policies to avoid future recurrences of a similar conflict. + +The Council may also delegate subsets of its own decision-making purviews via a public policy decision, to teams, other governance structures, or roles created and filled by the Council, such as operational lead, meeting facilitator, or scribe/secretary. + +Note that the Council may delegate the drafting of a proposal without necessarily delegating the decision to approve that proposal. This may be necessary in cases of Project-wide policy that intersects the purviews of many teams, or falls outside the purview of any team. This may also help when bootstrapping a new team incrementally. + +## Agenda and backlog + +The Council's agenda and backlog are the primary interface through which the Council tracks and gives progress updates on issues raised by Project members throughout the Project. + +To aid in the fairness and effectiveness of the agenda and backlog, the Council must: + +- Use a tool that allows Project members to submit requests to the Council and to receive updates on those requests. +- Use a transparent and inclusive process for deciding on the priorities and goals for the upcoming period. This must involve regular check-ins and feedback from all representatives. +- Strive to maintain a balance between long-term strategic goals and short-term needs in the backlog and on the agenda. +- Be flexible and adaptable and be willing to adjust the backlog and agenda as needed in response to changing circumstances or priorities. +- Regularly review and update the backlog to ensure that it accurately reflects the current priorities and goals of the Council. +- Follow a clear and consistent process for moving items from the backlog to the agenda, such as delegating responsibility to roles (e.g. meeting facilitator and scribe), and consenting to the agenda at the start of meetings. Any agenda items rejected during the consent process must have their objections documented in the published meeting minutes of the Council. + +## Deadlock resolution + +In some situations the Council might need to make an decision urgently and not feel it can construct a proposal in that time that everyone will consent to. In such cases, if everyone agrees that a timely decision they disagree with would be a better outcome than no timely decision at all, the Council may use an alternative decision-making method to attempt to resolve the deadlock. The alternative process is informal, and the council members must still re-affirm their consent to the outcome through the existing decision making process. Council members may still raise objections at any time. + +For example, the Council can consent to a vote, then once the vote is complete all of the council members would consent to whatever decision the vote arrived to. The Council should strive to document the perceived advantages and disadvantages for choosing a particular alternative decision-making model. + +There is, by design, no mandatory mechanism for deadlock resolution. If the representatives do not all consent to making a decision even if they don't prefer the outcome of that decision, or if any representative feels it is still possible to produce a proposal that will garner the Council's consent, they may always maintain their objections. + +If a representative withdraws an objection, or consents to a decision they do not fully agree with (whether as a result of an alternative decision-making process or otherwise), the Council should schedule an evaluation or consider shortening the time until an already scheduled evaluation, and should establish a means of measuring/evaluating the concerns voiced. The results of this review are intended to determine whether the Council should consider changing its prior decision. + +## Feedback and evaluation + +All policy decisions should have an evaluation date as part of the policy. Initial evaluation periods should be shorter in duration than subsequent evaluation periods. The length of evaluation periods should be adjusted based on the needs of the situation. Policies that seem to be working well and require few changes should be extended so less time is spent on unnecessary reviews. Policies that have been recently adjusted or called into question should have shortened evaluation periods to ensure they're iterating towards stability more quickly. The Council should establish standardized periods for classes of policy to use as defaults when determining periods for new policy. For instance, roles could have an evaluation date of 3 months initially then 1 year thereafter, while general policy could default to 6 months initially and 2 years thereafter. + +- New policy decisions can always modify or replace existing policies. +- Policy decisions must be published in a central location, with version history. +- Modifications to the active policy docs should include or link to relevant context for the policy decision, rather than expecting people to find that context later. + +# Transparency and oversight for decision making + +Decisions made by the Leadership Council will necessarily require varying levels of transparency and oversight based on the kind of decision being made. This section gives guidance on how the Council will seek oversight for its decisions, and what qualifies decisions to be made in private or in public. + +This RFC places certain decisions into each category. All decisions not specifically enumerated must use the public policy process. The Council may evolve the categorization through the [public policy process](decisions-that-the-Council-must-make-via-public-proposal). + +Decisions made by the Council fall into one of three categories, based on the level of oversight possible and necessary: + +- Decisions that the Council may make internally +- Decisions that the Council must necessarily make privately +- Decisions that the Council must make via public proposal + +## Decisions that the Council may make internally + +Some types of operational decisions can be made internally by the Council, with the provision that the Council has a mechanism for community feedback on the decision after it has been made. + +Adding a new decision to the list of decisions the Council can make internally requires a public policy decision. Any decisions that impact the structure, decision-makers, or oversight of the Council itself should not be added to this list. + +The Council should also strive to avoid establishing de facto unwritten policy via repeated internal decisions in an effort to avoid public proposal. See ["Repetition and exceptions"][repetition-and-exceptions] for more details. + +This list exhaustively enumerates the set of decisions that the Council may make internally: + +- Deciding to start a process that itself will play out in public (e.g. "let's start developing and posting the survey", "let's draft an RFC for this future public decision"). +- Expressing and communicating an official position statement of the Rust Project. +- Expressing and communicating the position of the Rust Project directly to another entity, such as the Rust Foundation. +- Communicating via Rust Project communication resources (via the blog or all@). +- Making most operational decisions about the Council's own internal processes, including how the Council coordinates, the platforms it uses to communicate, where and when it meets, templates used for making and recording decisions (subject to requirements elsewhere in this RFC). +- Appointing officers or temporary roles within the Council, for purposes such as leading/facilitating meetings, recording and publishing minutes, obtaining and collating feedback from various parties, etc.[^council-roles] Note that any such roles (titles, duties, and current holders) must be publicly disclosed and documented. +- Inviting specific attendees other than Council representatives to specific Council meetings or discussions, or holding a meeting open to the broader community. (In particular, the Council is encouraged to invite stakeholders of a particular decision to meetings or discussions where said decision is to be discussed.) +- Making decisions requested by one or more teams that would be within the normal purviews of those teams to make without a public proposal. (Note that teams can ask for Council input without requesting a Council decision.) +- Making one-off judgment calls in areas where the purviews of teams overlap or are ambiguous (though *changing* the purviews of those teams must be a public policy decision). +- Any decision that this RFC or future Council policy specifies as an operational decision. + +See the [accountability section][accountability] for details on the feedback mechanism for Council decisions. + +## Decisions that the Council must necessarily make privately + +Some decisions necessarily 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). + +This additional constraint should be considered an exceptional case. This does not permit making [decisions that would require a public proposal per the next section][decisions-that-the-Council-must-make-via-public-proposal]. However, this does permit decisions that the Council makes internally to be kept private, without full information provided for public oversight. + +The Council may also decline to make a decision privately, such as if the Council considers the matter outside their purview (and chooses to defer to another team) or believes the matter should be handled publicly. However, even in such a case, the Council still cannot publicly reveal information shared with it in confidence (since otherwise the Council would not be trusted to receive such information). Obvious exceptions exist for imminent threats to safety. + +Private decisions must not establish policy. The Council should also strive to avoid establishing de facto unwritten policy via repeated private decisions in an effort to avoid public proposal. See ["Repetition and exceptions"][repetition-and-exceptions] for more details. + +This list exhaustively enumerates the set of decisions that the Council may make either partly or entirely in private: + +- Determining relationships with new industry / Open Source initiatives, that require confidentiality before launching. +- Discussing the personal aspects of a dispute between teams that involves some interpersonal dynamics/conflicts. +- Participating in contract negotiations on behalf of the Project with third parties (e.g. accepting resources provided to the Project). +- Decisions touching on Project-relevant controversial aspects of politics, personal safety, or other topics in which people may not be safe speaking freely in public. +- Discussing whether and why a team or individual needs help and support, which may touch on personal matters. +- Any decision that this RFC or future Council policy specifies as a private decision. + +The Council may pull in members of other teams for private discussions leading to either a private or public decision, unless doing so would more broadly expose private information disclosed to the Council without permission. When possible, the Council should attempt to pull in people or teams affected by a decision. This also provides additional oversight. + +Some matters may not be fit for full public disclosure while still being fine to share in smaller, more trusted circles (such as with all Project members, with team leads, or with involved/affected parties). The Council should strive to share information with the largest appropriate audiences for that information. + +The Council may decide to withhold new decisions or aspects of decisions when it's unclear whether the information is sensitive. However, as time progresses and it becomes clearer who the appropriate audience is or that the appropriate audience has expanded, the council should revisit its information-sharing decisions. + +The Council should always loop in the moderation team for matters involving interpersonal conflict/dispute, both because such matters are the purview of the moderation team, and to again provide additional oversight. + +The council should evaluate which portions of a decision or its related discussions necessarily need to be private, and should consider whether it can feasibly make non-sensitive portions public, rather than keeping an entire matter private just because one portion of it needs to be. This may include the existence of the discussion, or the general topic, if those details are not themselves sensitive. + +Private matters may potentially be able to become public, or partially public, at a later date if they're no longer sensitive. However, some matters may potentially *never* be able to become public, which means they will never become subject to broader review and oversight. Thus, the Council must exercise caution and prudence before making a private decision. + +The Council should make every effort to not make private decisions. The Council should have appropriate additional processes in place to encourage representatives to collectively review such decisions and consider their necessity. + +## Decisions that the Council must make via public proposal +[decisions-that-the-Council-must-make-via-public-proposal]: #decisions-that-the-Council-must-make-via-public-proposal + +Decisions in this category require the Council to publicly seek feedback from the broader Rust Project *in advance* of the decision being made. Such decisions are proposed and decided via the appropriate public decision process, currently the RFC process (though the Council may adopt a different public proposal process in the future). The public decision process must require the consent of representatives (either affirmatively or via non-objection), must allow for blocking objections by Council representatives, must provide reasonable time for public evaluation and discussion, and must provide a clear path for public feedback to the Council. + +Following the existing RFC process, public proposals must have a minimum time-delay for feedback before the decision takes effect. Any representative may request that the feedback period for a particular decision is extended to at most 20 days total. The Council may make an internal operational decision to extend the feedback period beyond 20 days. The time-delay for feedback starts only when the necessary threshold for approval is otherwise met, including there not being any raised objections. If objections are raised and resolved during the time-delay, the waiting period starts again. + +The Leadership Council is expected to evolve over time to meet the evolving needs of the teams, the Rust Project, and the community. Such evolutionary changes may be small or large in scope and require corresponding amounts of oversight. Changes that materially impact the shape of the Council would need to be part of a public decision process. + +As an exception to the above, modifications or removals of a single top-level team (other than the moderation team) may occur with the unanimous agreement of the Council absent the representative delegated by that top-level team. + +The Council is permitted to have private *discussions* even on something that ultimately ends up as a public proposal or a publicly disclosed internal decision. The Council may wish to do this if the discussions are sensitive to allow decision participants to speak more frankly and freely. Additionally, in some cases, private information that can't be disclosed may impact an otherwise public decision/proposal; the Council should strive to be as transparent and non-misleading as possible and avoid having opaque decisions where all rationale is private. + +Note that all decisions fall into this category unless explicitly designated (via this RFC or future public proposals) to fall into another category, so this list (unlike those in the other two categories) is intentionally vague/broad: it is intended to give guidance on what likely should belong in this category without necessarily being prescriptive. + +- Any decision that has the effect of modifying the list of decision-makers on the Leadership Council or the decision-making process of the Leadership Council. For instance: + - Changing this list (or this RFC in general). + - Modifying the publication and approval process used for the Council's public proposals. Such a proposal must use the existing established process, not the proposed process. + - Adding, modifying, or removing policies affecting eligibility for Council representatives. + - Adding, modifying, or removing one or more top-level teams. This includes: + - modifying the purview of a top-level team to such an extent that it meaningfully becomes a different team. + - reorganizing the Project such that top-level teams move underneath other teams. + - Adding other types of Council representatives other than those delegated by top-level teams. + - Adding, modifying, or removing policies regarding Council quorums or the locations in which binding decisions can be made. +- Any policy decision, as opposed to a one-off operational decision. (See the [decision-making section][decision-making] for details on policy decisions versus operational decisions.) This includes any decision that binds the decisions of other parts of the Project (e.g. other teams or individuals), effectively serving as an exception to the normal purviews of all teams. Some examples of policy decisions: + - Modifying or extending existing policies, including those previously made via RFC. + - A legal/licensing policy affecting Rust Project software or other work of the Rust Project. + - A change to the Code of Conduct. + - A policy affecting eligibility for membership in the Rust Project or any team thereof. + - A change to how the moderation team moderates Council representatives or the Leadership Council as a whole. Such decisions must be made jointly with the moderation team. + - An agreement with another project or organization that makes any ongoing commitments on behalf of the Rust Project. (One-off commitments involving teams that have agreed to those commitments are fine.) + - Creating or substantially modifying legal structures (e.g. additional Foundations, changing relationship with the Rust Foundation, partnering with other legal entities). + - Making policy decisions requested by one or more teams that would be within the normal purviews of those teams. (Note that teams can ask for Council input without requesting a Council decision.) + - Deciding that a class of future decisions always belongs within the Council, rather than being delegated to any other team. +- Any decision that this RFC or future Council policy specifies as a public policy decision. + +## Conflicts of interest +[conflicts-of-interest]: #conflicts-of-interest + +A Council representative must not take part in or influence a decision in which they have a conflict of interest. + +Potential sources of conflicts of interest include, but are not limited to: +- Personal: a decision about themselves +- Financial: a decision with any substantive financial impact on the representative +- Employment or equivalent: a decision involves another person at the same company, or would benefit/harm that company disproportionately more than others +- Professional or other affiliation: a decision involves an organization the representative is associated with, such as an industry/professional/standards/governmental organization +- Familial/Friendship: a decision about a person the representative cannot be expected to be impartial about, including a conflict of interest of another type through that person (such as a family member's business) + +Council representatives must promptly disclose conflicts of interest and recuse themselves from affected decisions. Council representatives must also proactively disclose likely sources of potential conflict annually to other representatives and to the moderation team. + +Note that conflicts of interest can arise even if a proposal does not name a specific entity. Council representatives cannot, for instance, use their position to tailor requirements in a proposal to disproportionately benefit their employer. + +A proposal favored widely across the Rust community does not automatically represent a conflict of interest for a representative merely because that representative's employer or equivalent also favors the general area of that proposal, as long as the proposal does not favor any particular entities. For example, a proposal to improve the security of a particular Rust component is not a conflict of interest for representatives just because their employers generally care about Rust security; however, a proposal to engage specific developers or security experts, or one's compensation being predicated on such a proposal, might still raise a conflict. + +The Council may not waive a conflict of interest if one applies, even if the Council considers it minor. However, the Council may evaluate *whether* a conflict exists at all. Council representatives must raise potential conflicts so that the Council can make such a determination. + +The Council may request specific information from a recused representative, and the recused representative may provide that information upon request. + +Where possible and practical, the Council should separate decisions to reduce the scope of a conflict of interest. For instance, the Council could separate a decision to arrange access to a class of hardware (without setting specific requirements or selecting vendors) from the decision of which exact hardware to purchase and where to purchase it, if doing so made a conflict of interest only apply to the latter decision. + +A representative simultaneously considering the interests of the Rust Project and the interests of any Project team is not necessarily a conflict of interest. In particular, representatives are *expected* to regularly take part in decisions involving their teams, as delegates from those teams. + +In the unlikely event that a proposed decision produces a conflict of interest with enough representatives that the remainder cannot meet a previously established quorum requirement, and the decision must still be made, then either top-level teams must provide alternate representatives for the purposes of the specific decision, or (for public decisions only) the Council may elect to proceed with the decision while publicly documenting all conflicts of interest. (Note that proceeding with a public decision, even with conflicts documented, does not actually eliminate the conflicts or prevent them from influencing the decision; it only allows the public to judge whether the conflicts might have influenced the decision. Eliminating the conflicts entirely is always preferable.) In such a case, the Council should consider appropriate processes and policies to avoid future recurrences of a similar conflict. + +## Determining and changing team purviews + +The Council can move an area or activity between the purviews of top-level teams either already existing or newly created (other than the moderation team). Though the purview of a given top-level team may be further sub-divided by that team, the Council only moves or adjusts top-level purviews. If a sub-divided purview is moved, the Council will work with the involved teams to coordinate the appropriate next steps. This mechanism should be used when the Council believes the existing team's purview is too broad, such that it is not feasible to expect the team to fulfill the full purview under the current structure. However, this should not happen when a team only *currently* lacks resources to perform part of its duties. + +The Council also must approve expansions of a top-level team's purview, and must be notified of reductions in a top-level team's purview. This most often happens when a team self-determines that they wish to expand or reduce their purview. This could also happen as part of top-level teams agreeing to adjust purviews between themselves. Council awareness of changes to a purview is necessary, in part, to ensure that the purview can be re-assigned elsewhere or intentionally left unassigned by the Council. + +However, teams (individually or jointly) may further delegate their purviews to subteams without approval from the Council. Top-level teams remain accountable for the full purviews assigned to them, even if they delegate (in other words, teams are responsible for ensuring the delegation is successful). + +The Council should favor working with teams on alternative strategies prior to shifting purviews between teams, as this is a relatively heavyweight step. It's also worth noting that one of the use cases for this mechanism is shifting a purview previously delegated to a team that functionally no longer exists (for instance, because no one on the team has time), potentially on a relatively temporary basis until people arrive with the time and ability to re-create that team. This section of the RFC intentionally does not put constraints on the Council for exactly how (or whether) this consultation should happen. + +# Mechanisms for oversight and accountability +[accountability]: #mechanisms-for-oversight-and-accountability + +The following are various mechanisms that the Council uses to keep itself and others accountable. + +## Ensuring the Council is accountable + +The Council must publicly ensure that the wider Project and community's expectations of the Council are consistently being met. This should be done both by adjusting the policies, procedures, and outcomes of the Council as well as education of the Project and community when their expectations are not aligned with the reality. + +To achieve this, in addition to rotating representatives and adopting a "public by default" orientation, the Council must regularly (at least on a quarterly basis) provide some sort of widely available public communication on their activities as well as an evaluation of how well the Council is functioning using the list of duties, expectations, and constraints as the criteria for this evaluation. + +Each year, the Council must solicit feedback on whether the Council is serving its purpose effectively from all willing and able Project members and openly discuss this feedback in a forum that allows and encourages active participation from all Project members. To do so, the Council and other Project members consult the high-level duties, expectations, and constraints listed in this RFC and any subsequent revisions thereof to determine if the Council is meeting its duties and obligations. + +In addition, it is every representative's *individual* responsibility to watch for, call out, and refuse to go along with failures to follow this RFC, other Council policies and procedures, or any other aspects of Council accountability. Representatives should strive to actively avoid ["diffusion of responsibility"](https://en.wikipedia.org/wiki/Diffusion_of_responsibility), the phenomenon in which a group of people collectively fail to do something because each individual member (consciously or subconsciously) believes that someone else will do so. The Council may also wish to designate a specific role with the responsibility of handling and monitoring procedural matters, and in particular raising procedural points of order, though others can and should still do so as well. + +If any part of the above process comes to the conclusion that the Council is *not* meeting its obligations, then a plan for how the Council will change to better be able to meet their obligations must be presented as soon as possible. This may require an RFC changing charter or similar, a rotation of representatives, or other substantive changes. Any plan should have concrete measures for how the Council and/or Rust governance as a whole will evolve in light of the previous year's experience. + +## Ensuring Council representatives are accountable + +Council representatives should participate in regular feedback with each other and with their respective top-level team (the nature of which is outside the scope of this RFC) to reflect on how well they are fulfilling their duties as representatives. The goal of the feedback session is to help representatives better understand how they can better serve the Project. This feedback must be shared with all representatives, all members of the representative's top-level team, and with the moderation team. This feedback should ask for both what representatives have done well and what they could have done better. + +Separately, representatives should also be open to private feedback from their teams and fellow representatives at any time, and should regularly engage in self-reflection about their role and efficacy on the Council. + +Artifacts from these feedback processes must never be made public to ensure a safe and open process. The Council should also reflect on and adjust the feedback process if the results do not lead to positive change. + +If other members of the Council feel that a Council representative is not collaborating well with the rest of the Council, they should talk to that representative, and if necessary to that representative's team. Council representatives should bring in moderation/mediation resources as needed to facilitate those conversations. Moderation can help resolve the issue, and/or determine if the issue is actionable and motivates some level of escalation. + +While it is out of scope for this RFC to specify how individual teams ensure their representatives are held accountable, we encourage teams to use the above mechanisms as inspiration for their own policies and procedures. + +## Ensuring teams are accountable + +Teams regularly coordinate and cooperate with each other, and have conversations about their needs; under normal circumstances the Council must respect the autonomy of individual teams. + +However, the Council serves as a means for teams to jointly hold each other accountable, to one another and to the Project as a whole. The Council can: + +- Ask a team to reconsider a decision that failed to take the considerations of other teams or the Project as a whole into consideration. +- Encourage teams to establish processes that more regularly take other teams into consideration. +- Ensure a shared understanding of teams' purviews. +- Ensure teams are willing and able to fulfill those purviews. +- Establish new teams that split a team's purview up into more manageable chunks. + +The accountability process must not be punitive, and the process must be done with the active collaboration of the teams in question. + +In extreme circumstances where teams are willfully choosing to not act in good faith with regards to the wider Project, the Council has the authority to change a team's purview, move some subset of a team's purview to another team, or remove a team entirely. This is done through the Council's regular decision making process. (This does not apply to the moderation team; see the next section for accountability between the Council and moderation team.) + +# Moderation, disagreements, and conflicts + +This section describes the roles of the Leadership Council and the moderation team in helping resolve disagreements and conflicts, as well as the interactions between those teams. + +Disagreements and conflicts fall on a spectrum of interpersonal interaction. Disagreements are more factual and/or technical misalignments, while conflicts are more social or relational roadblocks to collaboration. Many interactions might display aspects of both disagreement and conflict. The Council can help with aspects of disagreement, while aspects of conflict are the purview of the moderation team. + +This RFC does not specify moderation policy in general, only the portion of it necessary to specify interactions with the Council and the checks and balances between the Council and the moderation team. General moderation policy is out of scope for this RFC. + +Much of the work of the Rust Project involves collaboration with other people, all of whom care deeply about their work. It's normal for people to disagree, and to feel strongly about that disagreement. Disagreement can also be a powerful tool for surfacing and addressing issues, and ideally, people who disagree can collaboratively and (mostly) amicably explore those disagreements without escalating into interpersonal conflicts. + +Situations where disagreements and conflicts arise may be complex. Disagreements can escalate into conflicts, and conflicts can de-escalate into disagreements. If the distinction between a disagreement and a conflict is not clear in the situation, or if participants disagree, assume the situation is a conflict. + +In the event of a conflict, involved parties should reach out to the moderation team to help resolve the conflict as soon as possible. Time is a critical resource in attempting to resolve a conflict before it gets worse or causes more harm. + +## Disagreements among teams + +Where possible, teams should attempt to resolve disagreements on their own, with assistance from the Council as needed. The Council can make judgment calls to settle disagreements, but teams need to maintain good working relationships with each other to avoid persistent disagreements or escalations into conflicts. + +Potential resolution paths for disagreements between teams could include selecting a previously discussed option, devising a new option, deciding whose purview the decision falls in, or deciding that the decision is outside the purviews of both teams and leaving it to the Council to find a new home for that work. + +## Conflicts involving teams or Project members + +Conflicts involving teams or Project members should be brought to the moderation team as soon as possible. The Council can help mitigate the impact of those conflicts on pending/urgent decisions, but the moderation team is responsible for helping with conflicts and interpersonal issues, across teams or otherwise. + +Individuals or teams may also voluntarily engage in other processes to address conflicts or interpersonal issues, such as non-binding external mediation. Individuals or teams should keep the moderation team in the loop when doing so, and should seek guidance from the moderation team regarding appropriate resources or approaches for doing so. Individuals or teams must not use resources that would produce a conflict of interest. + +## Contingent moderators + +The moderation team must at all times maintain a publicly documented list of "contingent moderators", who must be approved by both the moderation team and the Council via internal consent decision. The moderation team and contingent moderation team should both consist of at least three members each. The contingent moderators must be: +- Not part of the current moderation team *or* the Leadership Council. +- Widely trusted by Rust Project members as jointly determined by the Council and moderation team; this will often mean they're already part of the Project in some capacity. +- Qualified to do moderation work and [audits] as jointly determined by the Council and moderation team. More detailed criteria and guidelines will be established by moderation policy, which is out of scope for this RFC. +- Willing to serve as contingent moderators: willing to do audits, and willing to do interim moderation work if the moderation team dissolves or becomes unavailable, until they can appoint new full moderators. (The contingent moderators are not expected to be willing to do moderation work long-term.) +- Willing to stay familiar with moderation policy and procedure to the standards expected of a moderation team member (including any associated training). Contingent moderators should receive the same opportunities for training as the moderation team where possible. + +The need for contingent moderators arises in a high-tension situation, and the Project and Council must be prepared to trust them to step into that situation. Choosing people known and trusted by the rest of the Project helps lower tensions in that situation. + +Moderation is a high-burnout activity, and individual moderators or the moderation team may find itself wishing to step away from that work. Note that one or more individual moderators may always choose to step down, in which case the moderation team should identify and bring in new moderators to fill any gaps or shortfalls; if the moderation team asks a contingent moderator to become a full moderator, the team should then appoint a new contingent moderator. An individual moderator who stepped down *may* be selected as a contingent moderator. If the moderation team as a whole becomes simultaneously unavailable (as determined jointly by the Council and contingent moderators via internal consent decision), or chooses to step down simultaneously, the contingent moderators become the interim moderation team and must promptly appoint new contingent moderators and start seeking new full moderators. + +As the contingent moderator role does not have any regular required activities outside of exceptional situations, those appointed to that role must have regular check-ins with the moderation team, to reconfirm that they're still willing to serve in that role, and to avoid a circumstance in which the contingent moderators are abruptly needed and turn out to be unavailable. + +## Moderation team policies and procedures + +The moderation team has a duty to have robust policies and procedures in place. The Council provides oversight and assistance to ensure that the moderation team has those policies and procedures and that they are sufficiently robust. + +The Council may provide feedback to the moderation team and the moderation team is required to consider all feedback received. If the Council feels the moderation team has not followed moderation policies and procedures, the Council may [require an audit][audits] by the contingent moderators. However, the Council may not overrule a moderation decision or policy. + +## Audits +[audits]: #audits + +If any Council member believes a moderation decision (or series of decisions) has not followed the moderation team's policies and procedures, they should promptly inform the moderation team. The Council and moderation team should then engage with each other, discuss and understand these concerns, and work to address them. + +One of the mechanisms this RFC provides for checking the moderation team's actions in a privacy-preserving manner is an audit mechanism. In any case where any Council member believes moderation team actions have not followed documented policies or procedures, the Council member may decide to initiate the audit process. (In particular, they might do this in response to a report from a community member involved in a moderation situation.) This happens *in addition* to the above engagement and conversation; it is not a replacement for direct communication between the Council and the moderation team. + +In an audit, the contingent moderation team works with the moderation team to establish whether the moderation team followed documented policies and procedures. 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. However, this mechanism is not intended to second-guess the actions themselves; the audit mechanism focuses on establishing whether the moderation team is acting according to its established policy and procedures, as well as highlighting unintended negative consequences of the policies and procedures themselves. + +The contingent moderators also reach out to the Council to find out any additional context they might need. + +Moderation processes and audits both take time, and must be performed with diligence. However, the Council, contingent moderators, and moderation team should all aim to communicate their concerns and expectations to each other in a reasonably timely fashion and maintain open lines of communication. + +Contingent moderators must not take part in decisions or audits for which they have a conflict of interest. Contingent moderators must not have access to private information provided to moderation before the contingent moderator was publicly listed as part of the contingent moderation team; this gives people speaking with the moderation team the opportunity to evaluate potential concerns or conflicts of interest. + +The discussions with the Council and the contingent moderation team may discover that the moderation team had to make an exception in policy for a particular case, as there was an unexpected condition in policies or that there was contextual information that couldn't be incorporated in policy. This is an expected scenario that merits additional scrutiny by the contingent moderation team on the rationale for making an exception and the process for deciding the necessity to make an exception, but is not inherently a violation of moderation team responsibilities. + +As the audit process and the Council/moderation discussions proceed, the moderation team may decide to alter moderation policies and/or change the outcome of specific moderation decisions or proposed decisions. This is solely a decision for the moderation team to make. + +The contingent moderation team must report the results of the audit to the moderation team and the Council for their review. This must not include any details that may reveal private information, either directly or indirectly. Together with the discussions with the moderation team, this should aim to address the concerns of the Council. + +## Last-resort accountability + +The Leadership Council and moderation team each have substantial power within the Rust Project. This RFC provides many tools by which they can work out conflicts. This section outlines the last-resort mechanisms by which those teams can hold each other accountable. This section is written in the hopes that it will never be needed, and that teams will make every possible effort to resolve conflicts without reaching this point. + +If the Council believes there is a systemic problem with the moderation team (whether based on an audit report from the contingent moderation team or otherwise), and the Council and moderation team cannot voluntarily come to agreement on how to address the situation, then as a **last resort**, the Council (by unanimous decision) may simultaneously dissolve itself and the moderation team. The top-level teams must then appoint new representatives to the Council, and the contingent moderation team becomes the new interim moderation team. + +Conversely, if the moderation team believes the Council has a systemic problem, and the Council and moderation team cannot voluntarily come to agreement on how to address the situation, then as a **last resort**, the moderation team (by unanimous decision) may simultaneously dissolve itself and the Council. This process can only be enacted if there are at least three moderation team members. The top-level teams must then appoint new representatives to the Council, and the contingent moderation team becomes the new interim moderation team. + +The moderation team's representative is recused from the decision to dissolve the Council and moderation team to avoid conflicts of interest, though that representative must still step down as well. + +The removed representatives and moderators may not serve on either the Council or the moderation team for at least one year. + +By default, the new Council and interim moderation team will take responsibility for clearly communicating the transition. + +This mechanism is an absolute last resort. It will almost certainly produce suboptimal outcomes, to say the least. If situations escalate to this outcome, many things have gone *horribly* wrong, and those cleaning up the aftermath should endeavor to prevent it from ever happening again. The indication (by either the moderation team or the Council) that the situation *might* escalate to this point should be considered a strong signal to come to the table and find a way to do "Something Else which is Not That" to avoid the situation. + +## Moderation actions involving Project members +[moderation-actions-involving-Project-members]: #moderation-actions-involving-Project-members + +The moderation team, in the course of doing moderation work, necessarily requires the ability to take action not just against members of the Rust community but also against members of the Rust Project. Those actions may span the ladder of escalation all the way from a conversation to removal from the Project. This puts the moderation team in a position of power and trust. This RFC seeks to provide appropriate accountability and cross-checks for the moderation team, as well as for the Council. + +If the moderation team plans to enact externally visible sanctions against any member of the Rust Project (anything that would create a conspicuous absence, such as removal from a role, or exclusion from participation in a Project space for more than a week), then any party may request that an [audit][audits] take place by reaching out to either the Council or contingent moderators, and that audit will be automatically granted. + +For the first year after the ratification of this RFC, audits are automatically performed even without a request, to ensure the process is functional. After that time, the Council and moderation team will jointly review and decide whether to renew this provision. + +When the moderation team sends a warning to a Project member, or sends a notification of moderation action regarding a Project member, that message will mention the option of requesting an audit. + +Conflicts regarding Project members should be brought to the moderation team as soon as possible. + +## Conflicts involving Council representatives + +Conflicts involving Council representatives, or alternates, follow the same process as conflicts involving Project members. The moderation team has the same ability to moderate representatives or alternates as any other member of the Project, including the required [audit][audits] by the contingent moderators for any externally visible sanction. This remains subject to the same accountability mechanisms as for other decisions of the moderation team. + +In addition to the range of moderation actions already available, the moderation team may take the following additional actions for representatives or alternates as a near-last resort, as a lesser step on the ladder of escalation than removing a member from the Project entirely. These actions are not generally specific to the Council, and apply to other Rust teams as well. + +- The moderation team may decide to remove a representative from the Council. The top-level team represented by that representative should delegate a new representative to serve the remainder of the term, starting immediately. +- The moderation team may decide to prevent a Project member from becoming a Council representative. +- The moderation team and Council (excluding the affected parties) may jointly decide (as a private operational consent decision) to apply other sanctions limiting the representative's involvement in the Council. (In this scenario, representatives are not excluded if they have a conflict of interest, as the entire Council will have to cooperate to make the sanctions effective. If the conflicts of interest thus prevent applying these partial sanctions, the moderation team always has the option of full sanctions such as removal.) + +All of these also trigger a required audit. The Council must also be notified of any moderation actions involving representatives or alternates, or actions directly preventing people from becoming representatives. + +## Conflicts involving moderation team members + +Conflicts involving a member of the moderation team will be handled by the remaining members of the moderation team (minus any with a conflict of interest), *together with* the contingent moderation team to provide additional oversight. Any member of the moderation or contingent moderation team should confer with the Council if there is a more systemic issue within the moderation team. The contingent moderators must audit this decision and must provide an audit report to the Council and moderation team. + +# 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 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. + +# Footnotes + +[^core]: Unlike in some other Open Source projects, the Rust Project's "core team" does not refer to a group that decides the technical direction of the Project. As explained in more detail elsewhere in the RFC, the Rust Project distributes decision-making to many different teams who have responsibility for their specific purview. For example, the compiler team is in charge of the Rust compiler, the language team is in charge of language evolution, etc. This is part of why this RFC discontinues use of the term "core team". + +[^authority]: The term 'authority' here refers to the powers and responsibilities the Council has to ensure the success of the Rust Project. This RFC lays out the limits of these powers, so that the Council will delegate the authority it has to teams responsible for the concerns of the Project. These concerns may include - but are not limited to - product vision, day-to-day procedures, engineering decisions, mentoring, and marketing. + +[^teams]: Throughout this document, "teams" includes subteams, working groups, project groups, initiatives, and all other forms of official collaboration structures within the Project. "Subteams" includes all forms of collaboration structures that report up through a team. + +[^under-multiple-teams]: Subteams or individuals that fall under multiple top-level teams should not get disproportionate representation by having multiple representatives speaking for them on the Council. Whenever a "diamond" structure like this exists anywhere in the organization, the teams involved in that structure should strive to avoid ambiguity or diffusion of responsibility, and ensure people and teams know what paths they should use to raise issues and provide feedback. + +[^bootstrapping-new-teams]: The Council consists only of the representatives provided to it by top-level teams, and cannot appoint new ad hoc members to itself. However, if the Council identifies a gap in the project, it can create a new top-level team. In particular, the Council can bootstrap the creation of a team to address a problem for which the Project doesn't currently have coordinated/organized expertise and for which the Council doesn't know the right solution structure to charter a team solving it. In that case, the Council could bring together a team whose purview is to explore the solution-space for that problem, determine the right solution, and to return to the Council with a proposal and charter. That team would then provide a representative to the Council, who can work with the Council on aspects of that problem and solution. + +[^number-of-representatives]: This also effectively constrains the number of Council representatives to the same range. Note that this constraint is independently important. + +[^representative-selection]: Being a Council representative is ultimately a position of service to the respective team and to the Project as a whole. While the authors of this RFC hope that the position is fulfilling and engaging to whomever fills it, we also hope that it is not viewed as a position of status to vie for. + +[^council-roles]: The Council is not required to assign such roles exclusively to Council representatives; the Council may appoint any willing Project member. Such roles do not constitute membership in the Council for purposes such as decision-making. + +[^infra-creds]: In practice the infrastructure team as a whole will not have access to all credentials and internally strives to meet the principle of least privilege. diff --git a/text/3392-leadership-council/Leadership-Council-RFCja.md b/text/3392-leadership-council/Leadership-Council-RFCja.md new file mode 100644 index 00000000000..4814be931bd --- /dev/null +++ b/text/3392-leadership-council/Leadership-Council-RFCja.md @@ -0,0 +1,127 @@ +リーダーシップ・カウンシル：PR説明とRFC要約 + +このRFCは@jntrnr (コア)、@joshtriplett (言語チームリード)、@khionu(モデレーション)、 @Mark-Simulacrum(コアプロジェクトディレクター、リリースリード)、@rylev(コアプロジェクトディレクター), @technetos (モデレーション)、@yaahc(コラボレーションプロジェクトディレクター)により共同で著作されました。 + +「リーダーシップチャット」のすべてのメンバーおよび初期のレビュー・フィードバックに関して Rust プロジェクトの多くの皆様に感謝します。 + +このRFCはリーダーシップ・カウンシルをコアチームの後継者として制定するものです。カウンシルはその権限の多くを諸チームに付与しています。 + +> **注意**:この要約はRFCの概要を提供していますが、正式なものではありません。 + +# 手続きに関する情報 + +## 議論 + +このPRの議論に関しては、[専用のZulipストリーム](https://rust-lang.zulipchat.com/#narrow/stream/369838-rfc-leadership-council-feedback)を使用してください。 + +## 翻訳 + +このRFCの正式版は英語版です。しかしながら、Rustのガバナンス体制とポリシーを幅広く理解してもらうために、提案されるガバナンス体制とポリシーをその他の言語に翻訳する過程を開始しました。特に、[Rust アンケートデータ](https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html)に基づき、英語以外でのコミュニケーションができれば助かるという応答があった上位言語について、できあがり次第、以下の言語で翻訳版（正式版ではない）を掲載します。 + +- 中国語（簡体字） +- 中国語（繁体字） +- 日本語 +- 韓国語 +- ロシア語 + +できあがり次第翻訳版へのリンクを追加します。しかし、英語以外の言語で書かれたコメントに対応できるとは限らないことをご理解ください。この先、翻訳に関する決定はカウンシルに任されており、このグループに決定権はありません。これら翻訳版にフィードバックがあれば、翻訳に関して将来何かを決定する際に参考するための情報になるため、お知らせください。 + +## 補助的ファイル + +このRFCには補助的なテキストファイルが含まれます。[こちら](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council/)のサブディレクトリをご参照ください。 + +--- + +＃RFC要約 + +## モチベーション + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#motivation) + +Rustの体制では決定のほとんどが適切なチームに委任されます。しかしながら、既存チームの範囲外にある仕事が多くあります。 + +歴史的には、コアチームがチーム範囲外にある重要な仕事を認知し、また自分たちでその仕事をこなそうとしてきました。しかしながら、この両方の活動を同じチームで行おうとすることは、スケールせず、バーンアウトという結果になってしまいました。 + +このRFCで設立されるリーダーシップ・カウンシルでは、チームの範囲外にある仕事を認識し優先化することに焦点を当てます。カウンシルは基本的に、その仕事を自分たちでするのではなく、委任します。またカウンシルは、コーディネートする組織として、またチーム間でアカウンタビリティ、例えばチーム間協力、ロードマップ、プロジェクトの長期的成功などの説明責任のパートナーとして機能します。 + +このRFCはカウンシル全体と各メンバー、調整チーム、プロジェクトチーム、プロジェクトメンバーの間で、監視とアカウンタビリティの仕組みを確立します。 + +## カウンシルの責任、期待、制限 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#duties-expectations-and-constraints-on-the-council) + +明確なオーナーシップが欠けているために、遂行されない仕事を認識し、優先度付け、追跡します。その仕事を諸チーム（新規・一時的なチームであることもある）に委任します。明確なオーナーのいない*緊急*事項は、カウンシルが決定する場合もあります。 + +またプロジェクト全体の変更をチームや体制、プロセスに振り分けて、トップレベルのチームが説明可能（アカウンタブル）であるように確認し、Rust プロジェクトの公的な地位を確立します。 + +## カウンシルの体制 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#structure-of-the-council) + +カウンシルは一連のチーム[代表者](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#candidate-criteria)からなっており、各チームは、トップレベルのチーム一つと、その下に複数のサブチームをもち、それらを代表しています。 + +各[トップレベルチーム](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#top-level-teams)は、チームが選択する過程により、代表者を指名します。トップレベルチームのメンバーや、そのサブチームのメンバーは誰でも代表者になる資格があります。 + +Rustプロジェクトの全チームは、最終的に少なくとも一つのトップレベルのチームの下に置かれていなければなりません。親チームが現在ないチームに関しては、このRFCが[「ローンチパッド」チーム](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-launching-pad-top-level-team)を一時的なホームとして設置します。これによって全チームがカウンシル上で代表者がいるようになります。 + +代表者には[期間の限度](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#term-limits)があります。[1エンティティからの代表者の数には限度](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#limits-on-representatives-from-a-single-companyentity)があります。チームは[不在の場合は代替を提供](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#alternates-and-forgoing-representation)しなければなりません。 + +## カウンシルの決定過程 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-councils-decision-making-process) + +カウンシルは[オペレーションの決定、ポリシーの決定](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#operational-vs-policy-decisions)の両方を行います。デフォルトで、カウンシルは、全ての意思決定に関し、代表者が明示的な承認ではなく異議を求められる[公の同意に基づく意思決定過程](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-consent-decision-making-process)を使用します。最小限の[意思決定承認基準](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#approval-criteria)は定足数が必要であり、代表者が提案を確認するための時間を必要とします。 + +公のポリシープロセスを使用することで、カウンシルは[決定事項の階級によって異なる意思決定プロセス](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#modifying-and-tuning-the-decision-making-process)を確立することができます。カウンシルの[アジェンダとバックログ](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#agenda-and-backlog) +はプロジェクトメンバーによって提起された問題のための第一のインターフェースです。全ポリシーの決断には[評価期間](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#feedback-and-evaluation)がなければなりません。 + +## 意思決定の透明性と監視 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#transparency-and-oversight-for-decision-making) + +リーダーシップ・カウンシルで行われる様々な意思決定には色々なレベルの透明性と監視が必要になります。 + +オペレーション上の決定の中には[カウンシルが内部で]行うことが可能なものもあり(https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-may-make-internally)、後ほどその決定に関してフィードバックを求めることになります。決定の中には[プライベートで行われなければならない]ものがあり(https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-necessarily-make-privately)、その理由は個人やその他エンティティの私的な詳細に関わるものであり、その詳細を公にすることが個人やエンティティ（例: 安全性）またはプロジェクト に（例:信用を損なう）にネガティブな影響を与える可能性があるからです。[その他の全決定は公に行われなければならず](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-make-via-public-proposal)決定に関するフィードバックを前もって受けることができるようにします。 + +カウンシルの代表者は[利益相反]がある決定に参加したり影響を与えること(https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-of-interest)をしてはなりません。カウンシルはトップレベルチームの範囲の拡大を承認しなければならず、またトップレベルチームの範囲を調整することができます(モデレーションチーム以外に)](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#determining-and-changing-team-purviews)。 + +## 監視とアカウンタビリティの仕組み + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#mechanisms-for-oversight-and-accountability) + +カウンシルは、[プロジェクト全体とコミュティのカウンシルに対する期待が一貫して満たされるよう、公に確実にしなければ](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-the-council-is-accountable)なりません。 + +カウンシルの代表者はお互いに、またトップレベルのチームと[定期的にフィードバックに参加し](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-council-representatives-are-accountable)代表者としての責任をどの程度良く満たしているかについて見返す必要があります。 + +カウンシルはまた[チームがお互いに、またプロジェクトに対して説明責任を持つ](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-teams-are-accountable)ための道具として役割を果たします。 + +## モデレーション、意見の相違と対立 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-disagreements-and-conflicts) + +可能であれば、チームは自分たちで[必要ならばカウンシルの助けを借りて](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#disagreements-among-teams)意見の相違の解消を試みるべきです。チームやプロジェクトメンバーに関わる対立はできるだけ早く[モデレーションチームに相談](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-teams-or-project-members)すべきです。 + +モデレーションチームは["臨時モデレーター"](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#contingent-moderators)の公開リストを管理していなければなりません。臨時モデレーターは[監査プロセス](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#audits)でモデレーションチームがドキュメント化されたポリシーと手続きに沿っているか確認するためにモデレーションチームと協力して働くことができます。カウンシルメンバーは監査を開始することができますが、カウンシルがプライベートのモデレーション情報を見ることは決してありません。 + +絶対的な最終手段として、カウンシルまたはモデレーションチームが[両チームを同時に解消することを選択](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#last-resort-accountability)することもあります。チームはそれから新たな代表者を選択し、臨時モデレーターは一時的モデレーターになり、後継者を選択します。 + +[プロジェクトメンバーを含むモデレーションケース](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-actions-involving-project-members)の場合、当事者には監査人が必要になることがあります。[カウンシル代表者](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-council-representatives)を含むモデレーションケースや[モデレーション チームメンバー](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-moderation-team-members)の場合は付加的な監視やアカウンタビリティの方法があります。 + +## このRFCの批准 + +[[フルテキスト]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ratification-of-this-rfc) + +2021年11月以来、コアチームの全メンバー、モデレーションチームの全メンバー、Rust Foundation理事会のプロジェクト代表者全員、「トップレベル」全チームのリードが事実上のプロジェクトリーダーシップとして行動しています: + +- コンパイラー +- Crates.io +- 開発ツール +- インフラストラクチャ +- 言語 +- ライブラリ +- モデレーション（既に上記に含まれる） +- リリース + +このRFCは標準的なRFCプロセスを使用し、事実上のリーダーシップグループの全メンバーを承認チームとして、批准されます。このグループはプロジェクトの他のメンバーに代わって異議を申し立てるべきです。特に、チームリードはそのチームやサブチームからフィードバックを請うべきです。 + +[レンダリング済み](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md) \ No newline at end of file diff --git a/text/3392-leadership-council/Leadership-Council-RFCko.md b/text/3392-leadership-council/Leadership-Council-RFCko.md new file mode 100644 index 00000000000..7932e7d78a3 --- /dev/null +++ b/text/3392-leadership-council/Leadership-Council-RFCko.md @@ -0,0 +1,125 @@ +리더십 심의회: PR 설명 및 RFC 개요 + +이 RFC는 @jntrnr(중심), @joshtriplett(언어팀 리드), @khionu(중재), @Mark-Simulacrum(중심 프로젝트 디렉터, 공개 리드), @rylev(중심 프로젝트 디렉터), @technetos(중재) 및 @yaahc(협업 프로젝트 디렉터)가 공동으로 작성했습니다. + +'리더십 대화'의 모든 일원과 모든 Rust Project의 이해당사자 여러분, 일차 통과 검토와 피드백을 주셔서 정말 감사드립니다. + +이 RFC는 중심 팀의 후임인 리더십 심의회를 설립합니다. 이 심의회는 팀에게 여러 권한을 위임합니다. + +> **참고**: 이 개요는 RFC에 대한 개요를 제공하지만 강제성을 띄지는 않습니다. + +# 절차적 정보 + +## 논의 + +이 PR에 대한 논의를 위해 [전용 Zulip 스트림]을 활용하세요(https://rust-lang.zulipchat.com/#narrow/stream/369838-rfc-leadership-council-feedback). + +## 번역 + +강제성을 띈 RFC 버전은 영문으로 되어 있습니다. Rust의 거버넌스 구조와 정책을 널리 이해시키기 위해, 당사는 제시된 거버넌스 구조와 정책을 다른 언어로 번역하는 과정을 시작했습니다. 특히, 당사는 설문 응답자가 영어로 된 소통이 도움이 된다고 나타낸 상위 언어에 대한 [Rust 설문 데이터](https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html)에 따라 사용할 수 있는 즉시 다음 언어로 된 (강제성이 없는) 번역본을 게시할 것입니다. + +- 중국어(간체) +- 중국어(번체) +- 일본어 +- 한국어 +- 러시아어 + +당사는 이러한 언어로 된 번역본을 사용할 수 있게 되는 즉시 링크를 연결할 것입니다. 그렇다고 해서 비영어권 언어로 된 댓글을 다룰 준비를 마친 것은 아니오니 이에 유의하십시오. 향후 번역에 대한 일체의 결정은 이 그룹이 아니라 심의회가 내릴 것입니다. 이러한 번역에 대한 피드백이 있는 경우, 저희에게 알려주시면 번역에 대해 향후 결정을 내릴 때 유용하게 사용하겠습니다. + +## 보충 파일 + +이 RFC에는 보충 텍스트 파일을 포함되어 있습니다. [이곳](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council/)에서 하위 디렉터리에 유의하세요. + +----- + +# RFC 개요 + +## 동기 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#motivation) + +Rust는 대부분의 결정을 적합한 팀에게 위임하는 구조입니다. 하지만 업무의 많은 부분이 확립한 팀의 범위에 속하지 않습니다. + +과거에 중심팀에서 팀의 범위를 벗어나는 중요한 업무를 식별한 후 팀 내부에서 이를 수행하려는 시도를 한 일화가 있습니다. 하지만 같은 팀 안에서 두 가지 활동을 수행하는 것은 규모를 확장할 수 없었으며 결국 번아웃에 이르게 되었습니다. + +이 RFC에 따라 설립된 리더십 심의회는 팀의 범위를 벗어나는 업무를 식별하고 이를 우선순위에 올리는 것에 집중하빈다. 심의회는 이러한 업무를 직접 수행하지 않고 먼저 위임할 것입니다. 심의회는 또한 팀 간의 조율, 로드맵 및 프로젝트의 장기적인 성공을 돕는 등, 팀 사이를 조정하고 조직하고 책임지는 역할을 합니다. + +이 RFC는 또한 심의회 자체와 각 심의회 위원, 중재팀, 프로젝트팀 및 프로젝트 일원 사이의 감독 및 책임성 메커니즘을 확립합니다. + +## 심의회의 임무, 기대 사항 및 제한 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#duties-expectations-and-constraints-on-the-council) + +심의회는 명확한 주인의식의 부재로 인해 완수되지 않는 작업을 식별하여 우선순위로 정하고 추적합니다. 심의회는 이러한 (새롭거나 임시적일 수 있는) 작업을 팀에게 위임합니다. 일부 상황에서는 명확한 책임자가 없는 *급박한* 사안에 대해 결정을 내릴 수 있습니다. + +심의회는 또한 프로젝트 전반에 걸친 변화를 팀, 구조 또는 과정과 조율을 돕고 고위 팀으로 하여금 책임을 지게 하며 Rush Project의 공식 입장을 확립합니다. + +## 심의회 구조 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#structure-of-the-council) + +심의회는 고위 팀과 그 하위 팀을 각각 대표하는 여러 팀 [대표](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#candidate-criteria)로 구성되어 있습니다. + +각 [고위 팀](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#top-level-teams)은 선임 과정을 거쳐 대표를 한 명 위임합니다. 고위 팀이나 그 하위 그룹의 일원이라면 누구나 자격을 충족합니다. + +Rust Project의 모든 팀은 궁극적으로 최소 한 개의 고위 팀에 속합니다. 현재 상위 팀이 없는 팀에 대하여, 이 RFC는 임시 소속으로서 ['런칭 패드'팀](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-launching-pad-top-level-team)을 확립합니다. 심의회에서 모든 팀을 대표할 수 있도록 하기 위함입니다. + +대표들은 [제한 조건](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#term-limits)을 적용받습니다. [엔터티의 대표 수 제한](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#limits-on-representatives-from-a-single-companyentity)도 있습니다. 팀은 [부재 시에 대비해 대안을 마련해 제공](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#alternates-and-forgoing-representation)해야 합니다. + +## 심의회의 의사 결정 과정 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-councils-decision-making-process) + +심의회는 [운영 및 정책 결정](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#operational-vs-policy-decisions) 모두를 내립니다. 심의회는 기본적으로 모든 결정에 있어 대표자로 하여금 명시적인 승인이 아닌 반대 의사를 묻는 방식인 [동개 동의 의사 결정 과정](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-consent-decision-making-process)을 활용합니다. 최소 [의사 결정 승인 요건](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#approval-criteria)으로서 정족수가 필요하며, 대표자로 하여금 제안 사항을 고려할 충분한 시간을 허용합니다. + +심의회는 공개 정책 과정을 활용해 [여러 분류의 결정에 대해 다양한 의사 결정 과정](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#modifying-and-tuning-the-decision-making-process)을 확립할 수 있습니다. 심의회의 [안건 및 백로그](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#agenda-and-backlog)는 프로젝트 일원이 문제를 제시하는 기본적인 인터페이스입니다. 모든 정책 결정에는 [평가 날짜](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#feedback-and-evaluation)가 포함되어야 합니다. + +## 의사 결정의 책임성 및 감독 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#transparency-and-oversight-for-decision-making) + +리더십 심의회가 다루는 여러 유형의 결정에는 여러 수준의 투명성 및 감독이 필요합니다. + +일부 유형의 운영 관련 결정은 [심의회가 내부적으로](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-may-make-internally) 결정할 수 있으며, 그러한 결정에 대한 추후 피드백을 허용합니다. 개인과 다른 당사자에 대해 공개되지 않은 정보가 있으며 이러한 정보가 공개될 경우 해당 개인 또는 당사자(안전 등) 및 프로젝트(신뢰도 하락) 모두에게 부정적인 영향이 우려되는 경우, 일부 결정은 [비공개로 다루어야 합니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-necessarily-make-privately). [다른 모든 결정은 공개적으로 다루고](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-make-via-public-proposal) 사전에 해당 결정에 대한 피드백을 허용해야 합니다. + +심의회 대표자는 본인이 [이해상충](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-of-interest)이 있는 결정에 참여하거나 영향력을 행사해서는 안 됩니다. 심의회는 [고위 팀의 권한 확장을 승인해야 며, (중재 팀이 아닌) 해당 고위 팀의 권한을 조정할 수 있습니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#determining-and-changing-team-purviews). + +## 감독과 책임성 메커니즘 + +즘[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#mechanisms-for-oversight-and-accountability) + +심의회는 [프로젝트의 이해당사자와 커뮤니티가 심의회에게 기대하는 바를 지속적으로 충족하고 있음을 공개적으로 다루어야 합니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-the-council-is-accountable). + +심의회 대표자는 대표자로서 맡은 책임을 얼마나 잘 이행하고 있는지 반영하기 위해 서로, 그리고 관련 고위 팀과 [정기적인 피드백에 참여해야 합니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-council-representatives-are-accountable). + +심의회는 또한 팀들이 [팀과 프로젝트와 관련하여 서로 신뢰를 유지할 수 있도록](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-teams-are-accountable) 돕는 역할을 합니다. + +## 중재, 반대 의견 및 충돌 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-disagreements-and-conflicts) + +가능한 경우, 팀은 [필요에 따라 심의회의 지원을 받으며](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#disagreements-among-teams) 반대 의견을 직접 해결하려는 노력을 기울여야 합니다. 팀이나 프로젝트 일원이 포함된 충돌은 최대한 빨리 [중재팀에 보고해야 합니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-teams-or-project-members). + +중재팀은 ['조건부 중재자'(https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#contingent-moderators)의 공개 내역을 유지해야 합니다. 조건부 중재자는 중재팀이 문서화된 정책과 절차를 따르고 있는지 확인하기 위해 [감사 과정](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#audits)에서 중재팀과 협업할 수 있습니다. 심의회 위원은 감사를 시작할 수 있으나 심의회는 비공개 중재 정보를 절대 볼 수 없습니다. + +절대적인 최후의 수단으로서 심의회 또는 중재팀이 [두 팀을 동시에 해산하기로 결정할 수 있습니다](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#last-resort-accountability). 그 다음 팀에서는 새로운 대표자를 선임하고 조건부 중재자가 임시 중재팀이 되어 후임을 선정합니다. + +[프로젝트 일원이 연관된 중재 건](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-actions-involving-project-members)에서는 어떤 당사자이든 감사를 요청할 수 있습니다. [심의회 대표자](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-council-representatives) 또는 [중재팀 일원](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-moderation-team-members)이 연관된 중재 건에는 추가적인 감독 및 책임성 조치가 있습니다. + +## 이 RFC의 비준 + +[[전문]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ratification-of-this-rfc) + +2021년 11월 이래로 모든 중심팀 일원, 모든 중재팀 일원, Rust Foundation 위원회의 모든 프로젝트 대표자 및 모든 '고위' 팀 선임은 사실상 프로젝트 리더십의 역할을 해왔습니다. +- 컴파일러 +- Creates.io +- 개발 도구 +- 인프라 +- 언어 +- 라이브러리 +- 중재(이미 상기 포함) +- 공개 + +이 RFC는 표준 RFC 과정을 통해 비준을 받을 것이며 이를 승인하는 팀은 이러한 사실상의 리더십 그룹에 속한 모든 일원이 됩니다. 이 그룹은 프로젝트의 다른 일원을 대신하여 반대 의견을 표의할 수 있으며, 특히 팀 리더는 자신의 팀과 하위 팀의 피드백을 요청해야 합니다. + +[렌더링됨](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md) diff --git a/text/3392-leadership-council/Leadership-Council-RFCru-RU.md b/text/3392-leadership-council/Leadership-Council-RFCru-RU.md new file mode 100644 index 00000000000..8b090274ee0 --- /dev/null +++ b/text/3392-leadership-council/Leadership-Council-RFCru-RU.md @@ -0,0 +1,125 @@ +**Руководящий совет – описание для PR и обзор RFC** + +Соавторами данного RFC являются @jntrnr (Основная команда), @joshtriplett (Руководитель языковой команды), @khionu (Модерация), @Mark-Simulacrum (Директор основного проекта, Руководитель релизной команды), @rylev (Директор основного проекта), @technetos (Модерация) и @yaahc (Директор совместных проектов). + +Благодарим всех участников "чата руководства" и Проект Rust в целом за многочисленные предварительные рецензии и обратную связь. + +В данном RFC устанавливается роль Руководящего совета в качестве преемника основной команды. Совет делегирует основную часть своих полномочий другим командам. + +> **Примечание**: В настоящем обзоре предоставляется краткое описание RFC, но оно не имеет официальной силы. + +# Процедурная информация + +## Обсуждения + +Для обсуждения данного PR просим воспользоваться [специальным Zulip-стримом](https://rust-lang.zulipchat.com/#narrow/stream/369838-rfc-leadership-council-feedback). + +## Переводы + +Официальной версией данного RFC является версия на английском языке. Тем не менее, в целях широкого распространения информации об управленческой структуре и политиках Rust мы начали процесс перевода описания предлагаемой управленческой структуры и политик на другие языки. В частности, на основании [данных опроса Rust](https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html) относительно наиболее популярных языков, указанных респондентами опроса в качестве предпочтительного в будущем средства коммуникации в дополнение к английскому, мы предложим (не имеющие официальной силы) переводы на следующие языки, как только они будут готовы: + +- китайский (упрощенный) +- китайский (традиционный) +- японский +- корейский +- русский + +Мы разместим здесь ссылки на эти переводы, как только они будут готовы. Обращаем ваше внимание на то, что это не обязательно означает, что мы будем готовы реагировать на комментарии на других языках, кроме английского. Любые потенциальные решения относительно перевода будут зависеть не от этой группы, а от Совета. Если вы захотите оставить отзыв о переводах, пожалуйста, поделитесь им с нами, чтобы мы могли учесть его при принятии дальнейших решений, связанных с переводами. + +## Дополнительные файлы + +Настоящий RFC включает в себя дополнительные текстовые файлы. См. подкаталог [здесь](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council/). + +----- + +# Обзор RFC + +## Мотивация + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#motivation) + +Структура Rust позволяет делегировать большинство решений соответствующим командам. Тем не менее, существует большой объем работ, который не входит в компетенцию ни одной из созданных команд. + +Исторически сложилось, что основная команда и определяла важные работы, которые не входили в компетенцию отдельных команд, и пыталась выполнять эти работы своими силами. Однако совмещение этих двух задач в рамках одной команды не привело к масштабированию, но повлекло за собой выгорание. + +Руководящий совет, создаваемый настоящим RFC, занимается выявлением и приоритизацией работ за пределами компетенции отдельных команд. Совет преимущественно не выполняет эту работу своими силами, а делегирует ее другим. Совет также может выступать в качестве координирующего, организующего и отчетного органа, работающего с командами, направляющего совместные усилия нескольких команд, координирующего планы действий и содействующего общему успеху Проекта. + +В рамках данного RFC также устанавливаются механизмы надзора и подотчетности между Советом в целом, отдельными членами Совета, командой модерации, командами Проекта и членами Проекта. + +## Обязанности, ожидания и ограничения, применимые к Совету + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#duties-expectations-and-constraints-on-the-council) + +Совет выявляет и определяет приоритеты, а также отслеживает выполнение работы, которая остается не сделанной в силу отсутствия четких сфер ответственности. Он делегирует эту работу командам (причем они могут быть новыми или временными). В некоторых случаях он вправе разрешать *срочные* вопросы, не имеющие четкой сферы ответственности. + +Совет также координирует общепроектные изменения в командах, структурах или процессах, обеспечивает подотчетность команд верхнего уровня и устанавливает официальные позиции Проекта Rust. + +## Структура Совета + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#structure-of-the-council) + +В состав Совета входят [представители команд](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#candidate-criteria), каждый из которых представляет одну из команд верхнего уровня и ее под-команд. + +Каждая [команда верхнего уровня](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#top-level-teams) назначает своего представителя, пользуясь любой процедурой по своему выбору. Представителем может стать любой из членов команды верхнего уровня или любой из ее под-команд. + +Все команды в рамках Проекта Rust должны в конечном итоге быть подотчетны как минимум одной из команд верхнего уровня. Для команд, у которых в настоящее время нет вышестоящей команды, настоящий RFC создает [команду "запуска"](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-launching-pad-top-level-team) в качестве временной аффилиации. Таким образом, все команды получают представительство в Совете. + +Срок службы представителей [ограничен](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#term-limits). Существуют [ограничения на число представителей одной структуры](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#limits-on-representatives-from-a-single-companyentity). Команды должны [назначать заместителей на случай отсутствия представителя](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#alternates-and-forgoing-representation). + +## Процедура принятия решений в Совете + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-councils-decision-making-process) + +Совет принимает как [оперативные, так и относящиеся к политике решения](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#operational-vs-policy-decisions). По умолчанию Совет использует [процедуру принятия решений, основанную на общественном согласии](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-consent-decision-making-process) для принятия всех решений, относительно которых представителям предлагается высказать свои возражения, а не прямое одобрение. Минимальные [критерии принятия решений](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#approval-criteria) включают в себя наличие кворума и обеспечение представителям достаточного времени для ознакомления с предложением. + +Используя публичную процедуру формирования политики, Совет может устанавливать [различные процедуры принятия решений для определенных категорий решений](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#modifying-and-tuning-the-decision-making-process). [Повестка и архив](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#agenda-and-backlog) Совета являются его основным интерфейсом для вопросов, поднимаемых участниками Проекта. Всем решениям относительно политики должны присваиваться [даты оценки](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#feedback-and-evaluation). + +## Прозрачность и надзор за принятием решений + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#transparency-and-oversight-for-decision-making) + +Различные виды решений, принимаемых Руководящим советом, нуждаются в различных уровнях прозрачности и надзора. + +Некоторые виды операционных решений могут приниматься [внутри Совета](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-may-make-internally) с сохранением возможности получения в будущем обратной связи. Некоторые решения [должны приниматься в частном порядке](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-necessarily-make-privately), поскольку они связаны с конфиденциальными данными физических или иных лиц, обнародование которых имело бы негативные последствия для данных физических или иных лиц. [Все остальные решения должны приниматься публично](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-make-via-public-proposal), при условии предварительного получения обратной связи. + +Представитель Совета не вправе принимать участие в принятии решения или оказывать влияние на принятие решения при наличии [конфликта интересов](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-of-interest). Совет обязан утверждать [расширение сфер компетенции команды верхнего уровня и может корректировать сферы компетенции команд верхнего уровня (кроме команды модерации)](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#determining-and-changing-team-purviews). + +## Механизмы надзора и отчетности + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#mechanisms-for-oversight-and-accountability) + +Совет обязан [публично обеспечивать постоянное соответствие более общим требованиям Проекта и сообщества, применимым к деятельности Совета](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-the-council-is-accountable). + +Представители Совета [должны регулярно предоставлять обратную связь](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-council-representatives-are-accountable) друг другу и своим соответствующим командам верхнего уровня относительно исполнения своих обязанностей в качестве представителей. + +Совет также выступает средством [взаимного привлечения команд к ответственности по отношению друг к другу и к Проекту](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-teams-are-accountable). + +## Модерация, разногласия и конфликты + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-disagreements-and-conflicts) + +По возможности команды должны пытаться разрешать разногласия собственными силами, [при необходимости прибегая к помощи Совета](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#disagreements-among-teams). Конфликты с участием команд или участников Проекта [доводятся до сведения команды модерации](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-teams-or-project-members) в кратчайшие сроки. + +Команда модерации ведет публичный список ["контингента модераторов"](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#contingent-moderators). Контингент модераторов может работать совместно с командой модерации в рамках [процесса аудита](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#audits), чтобы определить, следовала ли команда модерации задокументированным политикам и процедурам. Члены Совета вправе инициировать аудиторские проверки, но конфиденциальные данные по модерации никогда не доводятся до сведения Совета. + +В качестве самого крайнего средства либо Совет, либо команда модерации [может принять решение об одновременном роспуске обеих команд](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#last-resort-accountability). После этого команды выбирают новых представителей, и контингент модераторов становится временной командой модерации и выбирают кандидатов себе на смену. + +[В случаях модерации с участием членов Проекта](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-actions-involving-project-members) любая сторона может запросить аудит. В случаях модерации с участием [представителей Совета](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-council-representatives) или [членов команды модераторов](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-moderation-team-members) предусмотрены дополнительные меры надзора и ответственности. + +## Ратификация данного RFC + +[[полный текст]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ratification-of-this-rfc) + +С ноября 2021 г. в качестве фактических лидеров Проекта выступает следующая группа: все члены основной команды, все члены команды модерации, все представители Проекта, входящие в состав правления Rust Foundation, а также руководители всех команд "верхнего уровня": + +- компилятор +- Crates.io +- инструменты разработки +- инфраструктура +- язык +- библиотека +- модерация (уже включена выше) - релиз + +Данный RFC подлежит ратификации с использованием стандартной процедуры RFC, причем утверждающая группа состоит из всех членов данной фактической руководящей группы. Эта группа также должна выдвигать возражения от имени других участников Проекта; в частности, руководители команд должны запрашивать обратную связь от своих команд и под-команд. + +[Визуализация](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md) diff --git a/text/3392-leadership-council/Leadership-Council-RFCzh-Hans.md b/text/3392-leadership-council/Leadership-Council-RFCzh-Hans.md new file mode 100644 index 00000000000..f7914bb0c59 --- /dev/null +++ b/text/3392-leadership-council/Leadership-Council-RFCzh-Hans.md @@ -0,0 +1,125 @@ +领导理事会。PR说明和RFC摘要 + +本RFC由@jntrnr（核心团队成员）、@joshtriplett（语言团队负责人）、@khionu（调解团队成员）、@Mark-Simulacrum（基金会核心项目主管，发布团队负责人）、@rylev（基金会核心项目主管）、@technetos（调解团队成员）和@yaahc（基金会合作项目主管）共同撰写。 + +非常感谢 "领导力交流"的所有成员和更大范围的Rust项目的所有成员的初步审查和反馈。 + +本RFC建立了一个取代核心团队的领导理事会。理事会将大部分权力下放给各团队。 + +**注意**。此摘要对RFC进行了概述，但它是非权威性的。 + +# 程序性信息 + +## 讨论 + +有关本PR的讨论，请使用[本专用Zulip流](https://rust-lang.zulipchat.com/#narrow/stream/369838-rfc-leadership-council-feedback)。 + +## 翻译 + +本RFC的权威版本是英文版。然而，为了帮助人们广泛理解Rust的管理结构和政策，我们已经开始将所提议的管理结构和政策翻译成其他语言。具体来说，根据[Rust调查数据](https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html)中认为非英语交流会有帮助的被调查对象使用最多的语种，我们将在完成以下语种的（非权威性）译版后发布这些译版： + +- 中文（简体） +- 中文（繁体） +- 日语 +- 韩语 +- 俄语 + +完成这些翻译后，我们将在这里发布相关链接。请注意，这并不一定意味着我们会处理非英语评论。未来的任何翻译计划将由理事会决定，而非此小组。如果您对这些翻译有建议或意见，请反馈给我们。我们将在未来翻译计划方面参考您的反馈。 + +## 补充文件 + +本RFC包括补充文本文件。请[在此](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council/)查看子目录。 + +----- + +# RFC 摘要 + +## 出发点 + +[全文](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#motivation) + +Rust的管理结构将大多数决定权交给了适当的团队。然而，有大量的工作是不属于任何既定团队的职权的。 + +历史上，核心团队既负责发现不属于其他团队职权范围内的那些重要工作，又负责努力自行完成这些工作。然而，将两部分都放置于此团队之内既没有很好的扩展性，又导致了团队成员的倦怠退出。 + +本RFC建立的领导理事会将着重确定团队职权之外的工作及其优先次序。理事会会对这些工作进行委托而非亲自完成它们。理事会还能够以跨团队工作、规划和项目的长期成功等为目标，成为团队之间的协调、组织和问责机构。 + +本RFC还建立了理事会全体、理事会成员个人、调解团队、项目团队和项目成员之间的监督和问责机制。 + +## 职责、期望和对理事会的限制 + +[全文](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#duties-expectations-and-constraints-on-the-council) + +理事会将确定、优先处理和跟踪因为归属不明而未完成的工作，并将这些工作委托给某团队（新团队或临时团队）。在某些时候，理事会可以在没有明确责任方的情况下决定*紧急*的事项。 + +理事会还会协调因项目而导致的团队、结构或流程的变化，确保顶层团队负起责任，并展示Rust项目的官方态度。 + +## 理事会的结构 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#structure-of-the-council) + +理事会由一组团队[代表](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#candidate-criteria)组成，他们各自代表某个顶层团队及其子团队。 + +每个[顶层团队](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#top-level-teams)通过其各自的选择程序指定一名代表。顶层团队或其子团队的任何成员都有资格。 + +Rust项目中的所有团队最终必须隶属于至少一个顶层团队。对于目前没有母队的团队，本RFC建立了[孵化器团队](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-launching-pad-top-level-team)作为其临时母队，来确保所有团队都有理事会代表。 + +代表有[任期](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#term-limits)。[每个团队的代表人数也有限制](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#limits-on-representatives-from-a-single-companyentity)。各团队应[在代表缺席时派出候补代表](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#alternates-and-forgoing-representation)。 + +## 理事会的决策过程 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-councils-decision-making-process) + +理事会[既做事务性决策也做政策决策](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#operational-vs-policy-decisions)。默认情况下，理事会在做出所有决策时都采用[众人认同的决策程序](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-consent-decision-making-process)，询问各代表的反对票而无需各代表明确投出赞同票。最低[决策批准标准](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#approval-criteria)要求，必须达到规定人数，且必须达到规定的时间以便代表们能够了解提案。 + +利用公共政策程序，理事会可以[为不同类别的计划制定决策程序](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#modifying-and-tuning-the-decision-making-process)。理事会的[议程和未完成项目](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#agenda-and-backlog)是其处理项目成员所提出的问题的主要渠道。所有的政策决定都应该有[评估日期](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#feedback-and-evaluation)。 + +## 决策的透明度与监督 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#transparency-and-oversight-for-decision-making) + +领导理事会的不同类型的决策需要不同程度的透明度和监督。 + +某些事务性决策可以[由理事会内部作出](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-may-make-internally)，并允许事后对决定决策反馈。有些决策[必须私下作出](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-necessarily-make-privately)，因为它们涉及到个人或其他实体的隐私细节。公开这些细节会对这些个人或实体产生负面影响（如安全）和对项目产生负面影响（降低信任度）。[所有其他决策必须公开](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-make-via-public-proposal)并允许对决策进行事前反馈。 + +理事会代表不得参与或影响与其本人有[利益冲突](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-of-interest)的决定。理事会必须批准[顶层团队对职权的扩大，并可以调整（除调解团队外）顶层团队的职权](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#determining-and-changing-team-purviews)。 + +## 监督和问责机制 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#mechanisms-for-oversight-and-accountability) + +理事会必须[公开确保始终达到更广泛项目和社区对理事会的期望](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-the-council-is-accountable)。 + +理事会代表应在各个代表之间以及与各自所属顶层团队之间[进行定期反馈](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-council-representatives-are-accountable)，来回顾他们身为代表的职责履行情况。 + +理事会也是一种[团队共同对彼此和项目负责](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-teams-are-accountable)的方式。 + +## 调解、分歧和冲突 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-disagreements-and-conflicts) + +团队应尽可能尝试独自解决分歧，[必要时由理事会协助](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#disagreements-among-teams)。涉及团队或项目成员的冲突[应尽快提交给调解团队](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-teams-or-project-members)。 + +调解团队必须保留一份[“临时调解人”](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#contingent-moderators)的公开名单。临时调解人可以在[审核过程](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#audits)中与调解团队合作，以确定调解团队是否遵循了文件规定的政策和程序。理事会成员可以发起审核，但理事会不会看到私人调解信息。 + +作为绝对的最后手段，理事会和调解团队均[可以选择同时解散两个团队](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#last-resort-accountability)。此时，团队选择新的代表，而临时调解人成为临时调解团队并选择继任者。 + +在[涉及项目成员的调解案件](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-actions-involving-project-members)中，任何一方都可以要求进行审核。涉及[理事会代表](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-council-representatives)或[调解团队成员](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-moderation-team-members)的调解案件有额外的监督和问责措施。 + +## 本RFC的批准 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ratification-of-this-rfc) + +自2021年11月以来，以下小组构成了项目事实上的领导层：核心团队的所有成员、调解团队的所有成员、Rust基金会董事会的所有项目代表以及所有“顶层”团队的负责人： +- 编译器 +- Crates.io +- 开发工具 +- 基础设施 +- 语言 +- 库 +- 调解（已在前文包含）。 +- 发布 + +本RFC将使用标准的RFC流程进行审批。审批的团队是实际领导小组的所有成员。此小组也应代表项目内其他成员将反对意见提出；特别是团队负责人应从各自的团队和子团队中对反馈意见进行搜集。 + +[呈现版](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md) \ No newline at end of file diff --git a/text/3392-leadership-council/Leadership-Council-RFCzh-Hant.md b/text/3392-leadership-council/Leadership-Council-RFCzh-Hant.md new file mode 100644 index 00000000000..bcccbb10228 --- /dev/null +++ b/text/3392-leadership-council/Leadership-Council-RFCzh-Hant.md @@ -0,0 +1,124 @@ +領導理事會。PR說明和RFC摘要 + +本 RFC 由 @jntrnr（核心成員）、@joshtriplett（語言團隊負責人）、@khionu（審核團隊）、@Mark-Simulacrum（核心專案主管，發佈負責人）、@rylev（核心專案主管）、@technetos（審核團隊）和 @yaahc（合作專案主管）共同撰寫。 + +非常感謝 「領導層交流」的所有成員和更大範圍的Rust專案的初步審查和回饋。 + +本 RFC 建立了一個繼承核心團隊的領導委員會。理事會將大部分權力下放給各團隊。 + +> **注意**。 此摘要對 RFC 進行了概述，但它不具有權威性。 + +# 程序性資訊 + +## 討論 + +關於對此 PR 的討論，請使用 [此 Zulip 回饋討論串]（https://rust-lang.zulipchat.com/#narrow/stream/369838-rfc-leadership-council-feedback)。 + +## 翻譯 + +本 RFC 的官方版本是英文版。然而，為了幫助人們廣泛理解 Rust 的管理架構和政策，我們已經開始將所計劃的管理架構和政策翻譯成其他語言。具體來說，根據 [Rust 調查數據]（https://blog.rust-lang.org/2022/02/15/Rust-Survey-2021.html）中認為非英語交流會有説明的被調查物件使用最多的語種，我們將完成並立即發佈以下語種的譯版（非官方性）： + +- 中文（簡體） +- 中文（繁體） +- 日語 +- 韓語 +- 俄語 + +完成這些翻譯後，我們將在這裡發佈相關連結。請注意，這並不一定意味著我們會處理非英語評論。未來的任何翻譯計劃將由理事會決定，而非此小組。如果您對這些翻譯有建議或意見，歡迎您給我們任何回饋。 我們將在未來翻譯計劃方面參考您的回饋。 + +## 補充文檔 + +本 RFC 包括補充文本檔。請 [在此] 查看子目錄 （https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council/）。 + +----- + +# RFC 摘要 + +## 動機 + +[[全文]] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#motivation) + +Rust的管理架構是將多數決策給予適切的團隊處理。然而，過量的工作不屬於任何既定團隊的職權。 + +歷史上來說，核心團隊曾發現過不屬於團隊職權範圍的重要工作，但他們依然試圖親自完成它們。然而，將這兩種活動交給同一個團隊並無法使團隊擴展，反而會導致工作過度造成精疲力盡。 + +本 RFC 建立的領導理事會將著重確定團隊職權之外的工作及其優先次序。理事會將對這些工作進行委託而非親自完成它們。理事會還能以跨團隊工作、規劃和項目的長期成功等為目標，成為團隊之間的協調、組織和問責機構。 + +本 RFC 還建立了理事會全體、理事會成員個人、審核團隊、專案團隊和專案成員之間的監督和問責機制。 + +## 職責、期望和對理事會的限制 + +[[全文]] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#duties-expectations-and-constraints-on-the-council) + +理事會將確定、優先處理和追蹤因歸屬不明而未完成的工作，並將這些工作委託給某團隊（新團隊或臨時團隊 ）。在某些時候，理事會可以在沒有明確責任方的情況下決定**緊急**的事項。 + +理事會還會協調因專案而導致的團隊、結構或流程的變化，確保高層負責，並設立 Rust 專案的官方職位。 + +## 理事會的結構 + +[[全文]](https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#structure-of-the-council) + +理事會由一組團隊 [理事會代表]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#candidate-criteria）組成， 他們分別代表一個一級團隊及其子團隊。 + +每個 [一級團隊]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#top-level-teams）通過其各自的選擇程序指定一名代表。一級團隊或其子團隊的任何成員都有資格爭取。 + +Rust專案中的所有團隊最終必須隸屬於至少一個一級團隊。對於目前沒有母隊的團隊，本RFC建立了[「啟動台 」團隊]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-launching-pad-top-level-team）作為其臨時母隊，以確保所有團隊都有理事會代表。 + +理事會代表有[任期限制]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#term-limits）。[一個團隊的理事會代表人數也有限制] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#limits-on-representatives-from-a-single-companyentity)。各團隊應[在理事會代表缺席時派出候補代表] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#alternates-and-forgoing-representation)。 + +## 理事會的決策過程 + +[[全文]]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-councils-decision-making-process） + +理事會同時做出[業務和決策]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#operational-vs-policy-decisions)。預設情況下，理事會對所有決定都採用[共識決策流程]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#the-consent-decision-making-process)，各理事會代表將被要求提供反對意見而非明確同意。最低[決策批准標準]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#approval-criteria）要求，必須達到規定人數，且理事會代表們必須在規定的時間內瞭解提案。 + +透過公共政策流程，理事會可以[為不同類別的計劃制定決策流程] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#modifying-and-tuning-the-decision-making-process)。理事會的 [議程和未完成專案]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#agenda-and-backlog）是其處理專案成員所提出的問題的主要平台。所有政策決定都應該有[評估日期]（ https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#feedback-and-evaluation)。 + +## 決策的透明度與監督 + +[[全文]]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#transparency-and-oversight-for-decision-making） + +領導理事會的不同類型決策需要不同程度的透明度和監督。 + +有些營運決策可以[由理事會內部作出]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-may-make-internally），並允許事後對其決策給出回饋。有些決策[必須私下作出] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-necessarily-make-privately)， 因為它們涉及到個人或其他實體的隱私細節。 公開這些細節會對這些個人或實體（如安全）和專案（降低信任度）產生負面影響。 [所有其他決策必須公開] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#decisions-that-the-council-must-make-via-public-proposal) 並允許對決策進行事前回饋。 + +理事會代表不得參與或影響與其本人有[利益衝突] （ https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-of-interest） 的決定。 理事會必須批准[擴大一級團隊的職權，並可以調整一級團隊（除審核團隊外）的職權] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#determining-and-changing-team-purviews)。 + +## 監督和問責機制 + +[[全文]]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#mechanisms-for-oversight-and-accountability） + +理事會必須[公開地確保始終達到更廣泛專案和社群對理事會的期望] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-the-council-is-accountable)。 + +理事會代表應在各個代表之間以及與各自一級團隊之間的[進行定期回饋]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-council-representatives-are-accountable），以反思他們身為代表的職責履行情況。 + +理事會也是一種[團隊共同對彼此和專案負責]（ https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ensuring-teams-are-accountable）的方式。 + +## 審核、分歧和衝突 + +[[全文]] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-disagreements-and-conflicts) + +團隊應儘可能嘗試獨自解決分歧，[必要時由理事會協助] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#disagreements-among-teams)。涉及團隊或專案成員的衝突[應儘快提交給審核團隊] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-teams-or-project-members)。 + +審核團隊必須保留一份[「審核人代表團」] 的公開名單（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#contingent-moderators）。審核人代表團可以在[審核過程]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#audits）中與審核團隊合作，以確保審核團隊遵循文件規定之政策及流程。理事會成員可以發起審核但無法看到私人審核資訊。 + +作為絕對的最後手段，理事會或審核團隊[可以選擇同時解散兩個團隊] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#last-resort-accountability)。然後，所有團隊將選擇新的理事會代表，而審核人代表團將成為臨時審核團隊並選擇繼任者。 + +在[涉及專案成員的審核案件]（ https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#moderation-actions-involving-project-members）中，任何一方都可以要求進行審核 。 涉及[理事會代表]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-council-representatives）或[審核團隊成員]（ https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#conflicts-involving-moderation-team-members）的審核案件有額外的監督和問責措施。 + +## 本RFC的批准 + +[[全文]] (https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md#ratification-of-this-rfc) + +自2021年11月以來，以下團隊為實際項目領導層：核心團隊的所有成員、審核團隊的所有成員、Rust基金會董事會的所有專案代表以及所有「一級」團隊的負責人： +- 編譯器 +- Crates.io +- 開發工具 +- 基礎架構 +- 語言 +- 函式庫 +- 審核（已包含在上面） +- 發佈 + +此 RFC 將以標準 RFC 程序審批，由前述實質上的領導層成員來批准。這些成員還應代表專案中其他成員提出異議，更具體來說，團隊負責人應徵求他的團隊和子團隊的回饋。 +[[好讀版]]（https://github.com/rust-lang/rfc-leadership-council/blob/main/text/3392-leadership-council.md） \ No newline at end of file diff --git a/text/3392-leadership-council/alternatives.md b/text/3392-leadership-council/alternatives.md new file mode 100644 index 00000000000..21a654a9cf2 --- /dev/null +++ b/text/3392-leadership-council/alternatives.md @@ -0,0 +1,93 @@ +# Rationale and alternatives + +The design space for governance is quite large. This section only attempts to address the largest and most consequential alternatives to the design decisions presented in this RFC. This section presents each such alternative along with justifications for why they were not selected. + +## Broader governance changes in this RFC + +We considered doing *more* in this RFC to set up initial governance structures and improve existing governance structures. In particular, we considered changes to the existing set of top-level teams. + +However, we felt strongly that anything that *could* be deferred to the Council should be, and that this RFC should focus on defining and delimiting the Council itself and its interactions with the rest of the Project. We felt it would go beyond the mandate of the transitional leadership structure to do much more than just architecting long-term leadership. + +We also felt that further incremental evolutions would become much easier with the structures proposed by this RFC in place. + +We recognize that changes to the set of top-level teams will prove especially difficult. However, we felt that the interim leadership group (including top-level team leads) would have that problem in common with the Council. Furthermore, we found that many members and leads of top-level teams were if anything *enthusiastic* about potential systematic improvements in this area, rather than resistant to them, even when such changes involved their own teams. + +Apart from that, developing and building consensus on this RFC already represented a massive time investment by many people, and making it larger would make it take even longer. + +## Alternative Council structures and non-representative Council members + +As an alternative to Council representatives exclusively being the representatives of top-level teams, we extensively considered other structures, whether in addition or in place of that. For instance, the Council could appoint additional members, or appoint successors, or some or all Council representatives could be elected by the Project. Such approaches could potentially make it easier to represent aspects or constituencies of the Project not *yet* represented by existing top-level teams, before even the nascent structures of those teams started to take shape. + +Specific variants we decided not to pursue: + +### Non-representative Council structures + +Alternative structures in which Council members are not representatives of top-level teams would have various drawbacks: +- Any structure that does not guarantee each team a representative would provide less comprehensive and balanced representation for existing teams. +- A structure not based on team-appointed representatives would make it harder to change representatives quickly and easily in a pinch, such as in response to changes in personal circumstances, or changes in a representative's affiliations that cause a violation of the limits placed on shared affiliations. +- Some variants of this (such as Council-appointed additional members or Council-appointed successors) would steer the Council towards a more self-perpetuating nature that we wanted to avoid. + +Ultimately, we addressed part of this issue by instead allowing the Council to easily create provisional teams (so as to introduce additional *representatives* on the Council), and then made room for the Council to further evolve its structure in the future by consent. + +### Elections + +Any structure involving elections would raise additional problems: +- Accurately determining the electorate: who precisely qualifies as being "part of the Rust Project"? + - Many people have intuitive ideas about this, and such intuitions don't currently cause problems because we don't tie much of substance to that status. However, such intuitive definitions cause serious issues if membership in the Project determines eligibility to vote. +- The usual problems of popularity contests: not all folks doing organizational/coordinative work are especially visible/glamorous/popular, and those doing visible/glamorous/popular work may serve the Project better doing that work rather than reallocating their time towards organizational/coordinative work. +- Elections motivate some form of campaigning. +- A robust election system would introduce more process complexity, both directly for the voting process, indirectly by making it harder to rotate/replace candidates in a pinch or supply alternates/backups. +- Elections would introduce more difficult challenges when needing to change representatives quickly and easily in a pinch, such as in response to changes in personal circumstances, or changes in affiliation that run into the limits upon shared affiliations. The voters will have chosen candidates, and it's harder to go back to the electorate for new candidates, so there would have to be (for example) careful rules for selecting backup candidates based on the next lower number of votes. +- Elections, no matter what voting system they use, inherently ignore the consent of many constituents. +- Simpler election structures would not guarantee teams a representative, and would thus provide less comprehensive and balanced representation for existing teams. Providing more comprehensive/proportional representation of teams would add even more complexity to the election system. + - In particular, if the people in the project fall into teams in a vaguely Pareto-style structure (a small number of teams contain a large number of people), a simple election structure may result in many teams having *no* representation. + +We felt that we could better improve people's routes to be heard and taken into account by ensuring all governance structures and all Project members are connected through parent teams, and thus that every member of the Project has at least one representative on the Council. + +## Referendums + +We considered introducing a full-fledged referendum system, by which proposals could be introduced, supported, and voted on by the Project as a whole. This would sidestep issues of ensuring proposals get considered and added to the Council's agenda, and would make it easier to make substantial changes not aligned with the existing Council (for better or for worse); it would also serve as an addition check and balance on the Council. + +However: +- This would have all the problems mentioned above about determining constituency in the Project. +- This would also be a *complex* new structure introduced entirely in this RFC (rather than later by the Council). + - This mechanism and its eligibility and corner cases would need to be *very* precisely specified, as it would often be invoked in situations with high tension and a need for a timely and authoritative decision. +- Voting mechanisms, no matter what voting system they use, inherently ignore the consent of many constituents. + - Voting mechanisms trend towards picking winners and losers, rather than consensus-seeking and finding ways to meet *everyone's* needs. +- If such a mechanism were trivial to initiate, it could become a dysfunctional pseudo-"communication" mechanism in its own right, substituting for healthier communication and more consent-driven actions. It would, effectively, escalate problems into public dirty laundry, making it *harder* to resolve smaller problems. In addition, reporting on such events can generate unwarranted news like "Rust considers X" even if X has no meaningful support. +- If such a mechanism were not trivial to initiate, the type of grassroots organizing required to successfully raise and pass such a referendum would produce better effects by working through teams, when the Project is well-aligned. +- Conversely, if the Project has substantial issues aligning with its leadership, making *individual* decisions doesn't solve the underlying problem with Project health. + +We chose to instead provide extensive checks on the Council itself, and mechanisms to ensure feedback and alignment between the Council and the Project, as well as a last-resort mechanism, rather than providing an ongoing mechanism to make or override *individual* Project-wide decisions. + +## Alternative checks and balances between the Leadership Council and the Project + +We considered many structures for additional checks and balances between the Leadership Council and the Project: +- We considered "vote of no confidence" mechanisms, but these would have many of the same problems as referendums, including determining the electorate, being either too difficult or too easy to initiate, and tending towards escalation rather than resolution. +- We considered arrangements in which members of teams could directly raise objections to Council RFCs. However, this added complexity for something that the consent decision-making mechanism *should* make redundant. +- We considered more formal feedback systems that could provide checks on *individual* Council decisions. However, any such mechanisms would also make it difficult to make timely decisions, and the blocking mechanisms would cause problems if they were either too easy or too difficult to initiate. + +## Alternative checks and balances between the Leadership Council and the moderation team + +We went through substantial tuning on the checks and balances between the Leadership Council and the moderation team: +- We considered making audits not automatically granted, and instead having the Council decide whether to grant an audit request. However, this would raise fairness questions for how the Council decides when to grant an audit based on limited information, as well as motivating procedural delays to give time for such an evaluation. We also felt that automatic audits (at least initially) would provide an opportunity to thoroughly test and evaluate the audit process. +- We also considered structures using separate auditors rather than using the "contingent moderators" as auditors, but this raised *severe* trust issues with sharing private moderation information with those auditors. + +## Launching pad alternatives + +We considered other alternate structures apart from the "launching pad", for handling existing teams that aren't attached to the rest of the team structure. For instance, we considered attaching such teams directly to the Council; however, this would have required special-case handling for representation that would start to look a lot like the launching pad, but with more coordination work attached to the Council. + +We also considered options in which we *didn't* connect those teams, and permitted "disconnected" working groups and similar. This would require less transition, but would leave many Project members unrepresented and disenfranchised. + +We felt that we could best improve people's routes to be heard and taken into account by ensuring all governance structures and all Project members are connected through parent teams. + +We considered giving additional purviews to the launching pad, such as contributing to team organization and structure, best practices, or processes. However, the launching pad is already the one exception in which this RFC creates a new team, and we already have concerns about successfully staffing that team; we don't want to add further complexity beyond that in this RFC. The Council has the option of changing the launching pad's purview in the future. + +We considered the name "landing pad" (a place for unattached teams to land) instead of "launching pad", but we felt that "launching pad" better conveyed the idea of incubating teams and helping them thrive rather than just serving as a holding area. + +## Double-linking + +We considered adopting a "double-linking" structure between the Council and top-level teams, in which teams have two representatives on the Council, one more responsible for connecting team-to-Council and the other more responsible for connecting Council-to-team. Such redundancy could provide a firmer connection between the Council and teams, making it *much* less likely that concerns from teams would fail to propagate to the Council and vice versa. However: +- Such a structure would require either an unmanageable number of Council members or far fewer than our current number of top-level teams (and we did not want to change the number of top-level teams in this RFC, or limit the number of top-level teams that strongly). +- This would require substantial changes to the structures of top-level teams themselves to permit such linking, and such structural changes would go beyond the remit of this RFC. +- Some models of double-linking would have one of the representatives determined by the team and the other by the Council; such a model would add complexity to the membership of the Council, such that members were not exclusively the representatives of top-level teams, which would have many of the downsides of such variations mentioned above, notably giving the Council a more self-perpetuating nature. diff --git a/text/3392-leadership-council/initial-work-of-the-council.md b/text/3392-leadership-council/initial-work-of-the-council.md new file mode 100644 index 00000000000..85643991c2d --- /dev/null +++ b/text/3392-leadership-council/initial-work-of-the-council.md @@ -0,0 +1,61 @@ +# Recommendations for initial work of the Council + +In the course of developing this RFC, and thinking extensively about the structure and operation of the Council, the interim leadership team also identified many other tasks that fell outside the scope of this RFC, and explicitly decided to defer those tasks to the new Council. This section documents those tasks, as a suggested starting point for bootstrapping the work of the Council. None of these are binding suggestions, and the Council can freely set and prioritize its own agenda; this section serves as a public, transparent handoff of knowledge and proposals to the Leadership Council. + +Some of these tasks represent meta-level decisions about the processes of the Council, and we chose not to make those decisions in this RFC to avoid enshrining a particular structure rather than deferring to those who will be working regularly with that structure. The remaining tasks represent a partial todo list of long-standing tasks that fall within the Council's purview, insofar as they have fallen through the gaps between team purviews. Some of these tasks should be delegated by the Council rather than worked on directly by the Council. The inclusion of a task in this list doesn't change what type of decision-making process is required for it; some of these may be Council-internal operational decisions or private operational decisions, while others will require a public policy process. + +These are in no particular order, other than that meta-level decisions about processes for making decisions will need to happen before decisions relying on those processes. + +## Meta-level decisions about processes and policies + +- Determining where, when, and how frequently the Council meets. +- Establishing processes for where the Council makes decisions, both synchronously (in meetings) and asynchronously. +- Writing and agreeing on templates for decisions, that help guide the Council to remember and follow process steps. +- Establishing specific processes around Council transparency, including records of decisions, minutes of meetings, the locations where these get published, and similar. +- Establishing a process for appointing the "Project directors" to the Rust Foundation board in a timely fashion. The Council will need to make such appointments soon after formation, and will also need to help ensure continuity across the transition. +- Establishing processes and conventions for the Council's regular review of its policy decisions. In particular, establishing expectations for the frequency of such reviews, with mechanisms to adjust those downwards when representatives express concern, or upwards after previous successful reviews. +- Selecting tools and establishing processes for tracking the Council's backlog/todo list, making as much of that list as possible public for transparency, and having a well-defined mechanism for Project members or teams to ask the Council to address something (either publicly or privately). +- Defining and documenting processes for external requests to the Council from outside the Project, ensuring they get routed appropriately, and taking steps where possible to ensure they can be directly routed to appropriate teams (potentially including new teams) in the future. +- Bootstrapping the new "Launching Pad" team and ensuring it has enough structure to operate. +- Organizing teams within Rust, and ensuring all teams and other governance structures are "attached" to appropriate places in the structure. (This includes working with teams to find appropriate homes, and ensuring such changes are ultimately reflected in the team metadata repository.) +- Establishing and agreeing on processes for faster decision-making for simple one-off operational matters, such as responding to emails reaching out to the Project. +- Ensuring the policy decision process (RFC process) is well-documented and linked from the Council documentation, so people know how Council public proposals happen. +- Develop handoff procedures for handling transitions to new Council representatives, or to alternates. + +## Other tasks/gaps potentially within the Council's purview + +- Checking in with teams and individuals across the Project, seeing what's going well and what needs help, and adding to the Council's todo list. + - Checking for priority items that need *urgent* help from the Council. + - Checking in with members of the former core team to identify items from their past todo lists and other open issues they're aware of, to add to the Council's todo list, and subsequently to either work on or delegate or otherwise disposition. + - Checking in with the moderation team, to ensure they have sufficient support and resources to ensure growth and sustainability. Collaborating with the moderation team as they develop and codify their policies and procedures to better handle a broader range of situations across the Project. + - Helping to develop plans to support understaffed or otherwise unsustainable teams. +- Work with the infra team to develop a transition plan for privileges traditionally maintained by core (such as root privileges / logged-use break-glass credentials). Coordinate appropriate policies with infra. +- Working with the Launching Pad team to help transition teams out of it into appropriate places in the organization. +- Ensuring that top-level teams have well-documented purviews, starting to identify gaps between those purviews, and working with teams to determine when those gaps should fall to specific existing teams or become the purview of new teams. +- Establishing policies to enable delegation of communication/PR tasks that have traditionally fallen to top-level leadership, and then making appropriate delegations of such work, potentially including the creation of teams. +- Working with teams to establish coordination channels for team roadmaps, and developing processes to support cohesion across those roadmaps. +- Making concrete plans to improve Rust Project diversity, including working with individual teams on how to better support diversity initiatives, as well as addressing gaps for which no individual team currently has responsibility. +- Working with teams on processes for receiving feedback from subteams, particularly on proposed Council representatives. Particular attention should be paid to: + - Ensure feedback is processed early, often, fairly, and consistently such that subteam members feel heard and Council members are given opportunity to address feedback and improve. + - Help detect and address bias in Council representative selection, including status-quo bias towards existing Rust leaders or people similar to them. +- Documenting and improving processes for interaction with the Rust Foundation, and considering organizational improvements to provide further ongoing support for those interactions (such as how and where Project directors fit into the organizational structure and how they interface with the Council regularly). + - In particular, establishing the purview of the Project directors along with policies and procedures for ensuring proper representation of Project interests on the Foundation board. +- Establishing proper procedures, and potentially teams, for handling issues which may have legal implications on the Project or Project participants. +- Ensuring that people and teams within the Rust Project have access to appropriate training and resources for the positions they find themselves in, beyond the skills required for their direct purview. Foster a culture of team membership that values such skills and help teams find resources or training to bolster such skills. Such skills and training include, among many others: + - General leadership and coordination skills, within a team and across a community + - Transparent and legible reasoning skills, recognizing and documenting underlying values, crux-finding, and collaborative disagreement + - Conflict resolution and de-escalation + - Project management and planning + - Communications between individuals, teams, and projects + - Public communications +- Help teams evaluate and consider replicating useful aspects of the Council's structure and processes within other teams across the Project (particularly top-level teams), such as: + - Appropriate structures to help subteams collaborate and coordinate amongst themselves and with top-level teams + - Structures for decision-making, including policies allowing for some types of decisions to be made more quickly, where appropriate + - Transparency, privacy, and documentation of decisions + - Policies for handling conflicts of interest among team members + - Policies on the number of team members sharing a common affiliation +- Ensure Project and Project member health by understanding and working against common work patterns where select "heroes" assume an outsized and unreasonable share of the maintenance burden by: + - taking on large amounts of essential work that they do not really *want* to do because no one else volunteers + - taking on so much work (either voluntarily or out of seeming necessity) that they are prone to burnout + - taking on work no one else has the ability to do and for which the member's absence would lead to potential crises in the Project +- Evaluating improvements to the RFC decision process, such as tracking and supporting multiple potential outcomes and changes in people's preferences without restarting decisions, and providing lighter-weight mechanisms for reversible decisions. diff --git a/text/3392-leadership-council/motivation.md b/text/3392-leadership-council/motivation.md new file mode 100644 index 00000000000..4c4a05da5bc --- /dev/null +++ b/text/3392-leadership-council/motivation.md @@ -0,0 +1,31 @@ +# Motivation + +The Rust Project is composed of hundreds of globally distributed individuals each of whom have very different motivations for working on Rust. Rust's open culture allows for these individuals to collaborate in a productive manner where complex technical and organizational decisions are made through consensus building and stakeholder feedback. + +Rust's model for project management and decision-making delegates most decisions to the appropriate team. Teams are ultimately accountable for their purview. While teams' decision-making processes do not strictly need to be consensus based, stakeholder feedback is repeatedly solicited to ensure a plethora of opinions on each matter are considered and factored in. + +However, at times this leads to issues. These issues can be summarized by the following questions which do not have clear answers in Rust's current governance model: +- What happens when it is unclear which teams' purviews a certain decision falls under? +- Who is in charge of important but non-urgent work that is not clearly owned by an existing team? +- Who is accountable when that work does not happen and organizational debt accrues? +- How are teams in the Project held accountable to each other and to the wider Project? + +Examples of the type of work in question include the following. Please note that this list is far from exhaustive and is merely meant to give an impression of the type of work in question: +- Helping identify gaps where existing teams are struggling to accomplish work or grow to meet challenges. +- Establishing large structural changes such as the Rust Foundation or new top-level teams. +- Project self-reflection. What aspects of Project operations are less than ideal? What do we do to change course? +- Project-wide community management. While individual teams can ensure that their teams are welcoming places, how do we ensure that the Project as a whole is? +- Policy work, for policies that have ramifications across the Project or even legal ramifications. +- Ensuring teams coordinate their work so that the Rust Project produces results greater than the sum of the output of the individual teams. + +While the current system does at times lead to positive outcomes in the above scenarios, it often does not. Some examples of failure mode categories include: +- No one is accountable for a decision and so the decision goes unmade, leaving it undefined. This requires solutions to repeatedly be developed either "off the cuff" or from first principles. This requires enormous amounts of energy and often leads to work not being done well or at all. In some cases it can even lead to burning out Project participants. +- Much Project work that is non-urgent often does not get done. This can lead to processes and procedures that are done not because they are the best way to handle a situation but simply because they are the easiest. This can lead to outcomes that are unfair or even actively harmful to individuals. In general, working this way leads to a culture of "putting out fires" instead of actively fostering improvements. +- The solutions to many of the issues facing the Rust Project require coordinated action across many different teams. Finding solutions for these issues requires investment at the organizational level, and it is often very difficult for individuals to coordinate and implement such structural investment. +- Still, such Project work is often taken up by motivated individuals who then lack structural support for accomplishing goals leading to frustration and at times conflict and burnout. + +Historically, the core team delegated authority to "top-level" teams who have further delegated authority to subteams or other governance structures. However, since the work outlined above is often Project-wide and outside the purview of individual teams, delegation was sometimes difficult. As a result, the core team assumed the following two responsibilities: +- Identifying, prioritizing, and advertising that certain important work needs to get done and does not fall under the purview of an existing team +- Attempting to do that work + +Through experience by the core team, it has become clear that both the identification of problems *and* the actual work itself is far too much for a single team. This has led to less than ideal results and in some cases, burnout. While a small amount of work requires urgent and immediate action, the vast majority of work would benefit from being tracked and handled by dedicated governance structures. diff --git a/text/3392-leadership-council/non-goals.md b/text/3392-leadership-council/non-goals.md new file mode 100644 index 00000000000..22b8a05ce3e --- /dev/null +++ b/text/3392-leadership-council/non-goals.md @@ -0,0 +1,22 @@ +# Non-goals of this RFC + +The following are non-goals of this RFC. These may be met in future RFCs but are explicitly not part of this RFC. + +Non-goal #1: *Laying out the complete policies and procedures of the Council*. While the RFC lays out and bounds the structure of the Council, the Council's full policies and procedures will be created by the Council itself. It is also expected that the Council will change and adapt to meet the needs of the Rust Project as it evolves. + +Non-goal #2: *Addressing all governance and potential governance concerns*. One of the Council's responsibilities will be to identify and reflect on the issues present in governance, but we see the formation of the Council as part of a continuous process of improving Rust's leadership and how it meets the needs of the Project. + +Non-goal #3: *Forming additional teams*. The focus of this RFC is to form the Council and does not include the creation of additional teams, subteams, or groups of any kind. + +We recognize the importance of having additional teams, but see this as outside of the scope of this RFC. Instead, it will be the responsibility of the Council to investigate and understand such needs and then create additional teams to ultimately handle these issues. + +This has one exception, other than the Council itself: the "launching pad" top-level team, which provides a temporary grouping of teams not yet attached to any existing top-level team either directly or indirectly. + +Non-goal #4: *Altering the charters or purviews of existing teams*. While this RFC does discuss membership in the Council, it does not extend beyond this to update the charter or purview of any existing team. Existing teams continue to follow their existing charters and purviews. + +This has two exceptions: + +- the core team: As part of this RFC, all of the capabilities and responsibilities of the core team move to the Council and are then clarified, modified, and constrained by the rest of this RFC. +- the moderation team: As this RFC covers topics like conflict resolution and Council oversight, it does define additional capabilities for the moderation team, as well as additional checks and balances providing bidirectional oversight between the moderation team and the Council. + +Non-goal #5: *Establishing completely immutable properties of the Council*. Any aspect established in this RFC can be modified in the future, via the public policy decision-making process, with oversight provided by that process. This RFC lays out policies for making such changes, and the processes of changing such policies must follow the existing policies.