From b4dc3b9344ec45a126467afe92aa3c32210472bb Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Wed, 4 Mar 2015 20:52:08 -0800 Subject: [PATCH 1/3] RFC: Scaling Rust's Governance --- text/0000-rust-governance.md | 719 +++++++++++++++++++++++++++++++++++ 1 file changed, 719 insertions(+) create mode 100644 text/0000-rust-governance.md diff --git a/text/0000-rust-governance.md b/text/0000-rust-governance.md new file mode 100644 index 00000000000..fe1e988da37 --- /dev/null +++ b/text/0000-rust-governance.md @@ -0,0 +1,719 @@ +- Feature Name: not applicable +- Start Date: 2015-02-27 +- RFC PR: (leave this empty) +- Rust Issue: (leave this empty) + +# Summary + +This RFC proposes to expand, and make more explicit, Rust's governance +structure. It seeks to supplement today's core team with several +*subteams* that are more narrowly focused on specific areas of +interest. + +*Thanks to Nick Cameron, Manish Goregaokar, Yehuda Katz, Niko Matsakis and Dave + Herman for many suggestions and discussions along the way.* + +# Motivation + +Rust's governance has evolved over time, perhaps most dramatically +with the introduction of the RFC system -- which has itself been +tweaked many times. RFCs have been a major boon for improving design +quality and fostering deep, productive discussion. It's something we +all take pride in. + +That said, as Rust has matured, a few growing pains have emerged. + +We'll start with a brief review of today's governance and process, +then discuss what needs to be improved. + +## Background: today's governance structure + +Rust is governed by a +[core team](https://github.com/rust-lang/rust/wiki/Note-core-team), +which is ultimately responsible for all decision-making in the +project. Specifically, the core team: + +* Sets the overall direction and vision for the project; +* Sets the priorities and release schedule; +* Makes final decisions on RFCs. + +The core team currently has 8 members, including some people working +full-time on Rust, some volunteers, and some production users. + +Most technical decisions are decided through the +[RFC process](https://github.com/rust-lang/rfcs#what-the-process-is). +RFCs are submitted for essentially all changes to the language, +most changes to the standard library, and +[a few other topics](https://github.com/rust-lang/rfcs#when-you-need-to-follow-this-process). +RFCs are either closed immediately (if they are clearly not viable), +or else assigned a *shepherd* who is responsible for keeping the +discussion moving and ensuring all concerns are responded to. + +The final decision to accept or reject an RFC is made by the core +team. In many cases this decision follows after many rounds of +consensus-building among all stakeholders for the RFC. In the end, +though, most decisions are about weighting various tradeoffs, and the +job of the core team is to make the final decision about such +weightings in light of the overall direction of the language. + +## What needs improvement + +At a high level, we need to improve: + +* Process scalability. +* Stakeholder involvement. +* Clarity/transparency. +* Moderation processes. + +Below, each of these bullets is expanded into a more detailed analysis +of the problems. These are the problems this RFC is trying to +solve. The "Detailed Design" section then gives the actual proposal. + +### Scalability: RFC process + +In some ways, the RFC process is a victim of its own success: as the +volume and depth of RFCs has increased, it's harder for the entire +core team to stay educated and involved in every RFC. The +[shepherding process](https://github.com/rust-lang/rfcs#the-role-of-the-shepherd) +has helped make sure that RFCs don't fall through the cracks, but even +there it's been hard for the relatively small number of shepherds to +keep up (on top of the other work that they do). + +Part of the problem, of course, is due to the current push toward 1.0, +which has both increased RFC volume and takes up a great deal of +attention from the core team. But after 1.0 is released, the community +is likely to grow significantly, and feature requests will only +increase. + +Growing the core team over time has helped, but there's a practical +limit to the number of people who are jointly making decisions and +setting direction. + +A distinct problem in the other direction has also emerged recently: we've +slowly been requiring RFCs for increasingly minor changes. While it's important +that user-facing changes and commitments be vetted, the process has started to +feel heavyweight (especially for newcomers), so a recalibration may be in order. + +We need a way to scale up the RFC process that: + +* Ensures each RFC is thoroughly reviewed by several people with + interest and expertise in the area, but with different perspectives + and concerns. + +* Ensures each RFC continues moving through the pipeline at a + reasonable pace. + +* Ensures that accepted RFCs are well-aligned with the values, goals, + and direction of the project, and with other RFCs (past, present, + and future). + +* Ensures that simple, uncontentious changes can be made quickly, without undue + process burden. + +### Scalability: areas of focus + +In addition, there are increasingly areas of important work that are +only loosely connected with decisions in the core language or APIs: +tooling, documentation, infrastructure, for example. These areas all +need leadership, but it's not clear that they require the same degree +of global coordination that more "core" areas do. + +These areas are only going to increase in number and importance, so we +should remove obstacles holding them back. + +### Stakeholder involvement + +RFC shepherds are intended to reach out to "stakeholders" in an RFC, +to solicit their feedback. But that is different from the stakeholders +having a direct role in decision making. + +To the extent practical, we should include a diverse range of +perspectives in both design and decision-making, and especially +include people who are most directly affected by decisions: users. + +We have taken some steps in this direction by diversifying the core +team itself, but (1) members of the core team by definition need to +take a balanced, global view of things and (2) the core team should +not grow too large. So some other way of including more stakeholders +in decisions would be preferable. + +### Clarity and transparency + +Despite many steps toward increasing the clarity and openness of +Rust's processes, there is still room for improvement: + +* The priorities and values set by the core team are not always + clearly communicated today. This in turn can make the RFC process + seem opaque, since RFCs move along at different speeds (or are even + closed as postponed) according to these priorities. + + At a large scale, there should be more systematic communication + about high-level priorities. It should be clear whether a given RFC + topic would be considered in the near term, long term, or + never. Recent blog posts about the 1.0 release and stabilization + have made a big step in this direction. After 1.0, as part of the + regular release process, we'll want to find some regular cadence for + setting and communicating priorities. + + At a smaller scale, it is still the case that RFCs fall through the + cracks or have unclear statuses (see Scalability problems + above). Clearer, public tracking of the RFC pipeline would be a + significant improvement. + +* The decision-making process can still be opaque: it's not always + clear to an RFC author exactly when and how a decision on the RFC + will be made, and how best to work with the team for a favorable + decision. We strive to make core team meetings as *uninteresting* as + possible (that is, all interesting debate should happen in public + online communication), but there is still room for being more + explicit and public. + +### Community norms and the Code of Conduct + +Rust's design process and community norms are closely intertwined. The +RFC process is a joint exploration of design space and tradeoffs, and +requires consensus-building. The process -- and the Rust community -- +is at its best when all participants recognize that + +> ... people have differences of opinion and that every design or +> implementation choice carries a trade-off and numerous costs. There +> is seldom a right answer. + +This and other important values and norms are recorded in the +[project code of conduct (CoC)](http://www.rust-lang.org/conduct.html), +which also includes language about harassment and marginalized groups. + +Rust's community has long upheld a high standard of conduct, and has +earned a reputation for doing so. + +However, as the community grows, as people come and go, we must +continually work to maintain this standard. Usually, it suffices to +lead by example, or to gently explain the kind of mutual respect that +Rust's community practices. Sometimes, though, that's not enough, and +explicit moderation is needed. + +One problem that has emerged with the CoC is the lack of clarity about +the mechanics of moderation: + +* Who is responsible for moderation? +* What about conflicts of interest? Are decision-makers also moderators? +* How are moderation decisions reached? When are they unilateral? +* When does moderation begin, and how quickly should it occur? +* Does moderation take into account past history? +* What venues does moderation apply to? + +Answering these questions, and generally clarifying how the CoC is viewed and +enforced, is an important step toward scaling up the Rust community. + +# Detailed design + +The basic idea is to supplement the core team with several "subteams". Each +subteam is focused on a specific area, e.g., language design or libraries. Most +of the RFC review process will take place within the relevant subteam, scaling +up our ability to make decisions while involving a larger group of people in +that process. + +To ensure global coordination and a strong, coherent vision for the project as a +whole, **each subteam is led by a member of the core team**. + +## Subteams + +**The primary roles of each subteam are**: + +* Shepherding RFCs for the subteam area. As always, that means (1) ensuring that + stakeholders are aware of the RFC, (2) working to tease out various design + tradeoffs and alternatives, and (3) helping build consensus. + +* Accepting or rejecting RFCs in the subteam area. + +* Setting policy on what changes in the subteam area require RFCs, and reviewing + direct PRs for changes that do not require an RFC. + +* Delegating *reviewer rights* for the subteam area. The ability to `r+` is not + limited to team members, and in fact earning `r+` rights is a good stepping + stone toward team membership. Each team should set reviewing policy, manage + reviewing rights, and ensure that reviews take place in a timely manner. + (Thanks to Nick Cameron for this suggestion.) + +Subteams make it possible to involve a larger, more diverse group in the +decision-making process. In particular, **they should involve a mix of**: + +* Rust project leadership, in the form of at least one core team member (the + leader of the subteam). + +* Area experts: people who have a lot of interest and expertise in the subteam + area, but who may be far less engaged with other areas of the project. + +* Stakeholders: people who are strongly affected by decisions in the + subteam area, but who may not be experts in the design or + implementation of that area. *It is crucial that some people heavily + using Rust for applications/libraries have a seat at the table, to + make sure we are actually addressing real-world needs.* + +Members should have demonstrated a good sense for design and dealing with +tradeoffs, an ability to work within a framework of consensus, and of course +sufficient knowledge about or experience with the subteam area. Leaders should +in addition have demonstrated exceptional communication, design, and people +skills. They must be able to work with a diverse group of people and help lead +it toward consensus and execution. + +Each subteam is led by a member of the core team. **The leader is responsible for**: + +* Setting up the subteam: + + * Deciding on the initial membership of the subteam (in consultation with + the core team). + + * Working with subteam members to determine and publish subteam policies and + mechanics. + +* Communicating core team vision downward to the subteam. + +* Alerting the core team to subteam RFCs that need global, cross-cutting + attention, and to RFCs that have entered the "final comment period" (see below). + +* Ensuring that RFCs and PRs are progressing at a reasonable rate, re-assigning + shepherds/reviewers as needed. + +* Making final decisions in cases of contentious RFCs that are unable to reach + consensus otherwise (should be rare). + +The way that subteams communicate internally and externally is left to each +subteam to decide, but: + +* Technical discussion should take place as much as possible on public forums, + ideally on RFC/PR threads and tagged discuss posts. + +* Each subteam will have a dedicated discuss forum tag. + +* Subteams should have some kind of regular meeting or other way of making + decisions. + +* Subteams should regularly publish the status of RFCs, PRs, and other news + related to their area. + +## Core team + +**The core team serves as leadership for the Rust project as a whole**. In + particular, it: + +* **Sets the overall direction and vision for the project.** That means setting + the core values that are used when making decisions about technical + tradeoffs. It means steering the project toward specific use cases where Rust + can have a major impact. It means leading the discussion, and writing RFCs + for, *major* initiatives in the project. + +* **Sets the priorities and release schedule.** Design bandwidth is limited, and + it's dangerous to try to grow the language too quickly; the core team makes + some difficult decisions about which areas to prioritize for new design, based + on the core values and target use cases. + +* **Focuses on broad, cross-cutting concerns.** The core team is specifically + designed to take a *global* view of the project, to make sure the pieces are + fitting together in a coherent way. + +* **Spins up or shuts down subteams.** Over time, we may want to expand the set + of subteams, and it may make sense to have temporary "strike teams" that focus + on a particular, limited task. + +* **Decides whether/when to ungate a feature.** While the subteams make + decisions on RFCs, the core team is responsible for pulling the trigger that + moves a feature from nightly to stable. This provides an extra check that + features have adequately addressed cross-cutting concerns, that the + implementation quality is high enough, and that language/library commitments + are reasonable. + +The core team should include both the subteam leaders, and, over time, a diverse +set of other stakeholders that are both actively involved in the Rust community, +and can speak to the needs of major Rust constituencies, to ensure that the +project is addressing real-world needs. + +## Decision-making + +### Consensus + +Rust has long used a form of [consensus decision-making][consensus]. In a +nutshell the premise is that a successful outcome is not where one side of a +debate has "won", but rather where concerns from *all* sides have been addressed +in some way. **This emphatically does not entail design by committee, nor +compromised design**. Rather, it's a recognition that + +> ... every design or implementation choice carries a trade-off and numerous +> costs. There is seldom a right answer. + +Breakthrough designs sometimes end up changing the playing field by eliminating +tradeoffs altogether, but more often difficult decisions have to be made. **The +key is to have a clear vision and set of values and priorities**, which is the +core team's responsibility to set and communicate, and the subteam's +responsibility to act upon. + +Whenever possible, we seek to reach consensus through discussion and design +revision. Concretely, the steps are: + +* Initial RFC proposed, with initial analysis of tradeoffs. +* Comments reveal additional drawbacks, problems, or tradeoffs. +* RFC revised to address comments, often by improving the design. +* Repeat above until "major objections" are fully addressed, or it's clear that + there is a fundamental choice to be made. + +Consensus is reached when most people are left with only "minor" objections, +i.e., while they might choose the tradeoffs slightly differently they do not +feel a strong need to *actively block* the RFC from progressing. + +One important question is: consensus among which people, exactly? Of course, the +broader the consensus, the better. But at the very least, **consensus within the +members of the subteam should be the norm for most decisions.** If the core team +has done its job of communicating the values and priorities, it should be +possible to fit the debate about the RFC into that framework and reach a fairly +clear outcome. + +[consensus]: http://en.wikipedia.org/wiki/Consensus_decision-making + +### Lack of consensus + +In some cases, though, consensus cannot be reached. These cases tend to split +into two very different camps: + +* "Trivial" reasons, e.g., there is not widespread agreement about naming, but + there is consensus about the substance. + +* "Deep" reasons, e.g., the design fundamentally improves one set of concerns at + the expense of another, and people on both sides feel strongly about it. + +In either case, an alternative form of decision-making is needed. + +* For the "trivial" case, usually either the RFC shepherd or subteam leader will + make an executive decision. + +* For the "deep" case, the subteam leader is empowered to make a final decision, + but should consult with the rest of the core team before doing so. + +### How and when RFC decisions are made, and the "final comment period" + +Each RFC has a shepherd drawn from the relevant subteam. The shepherd is +responsible for driving the consensus process -- working with both the RFC +author and the broader community to dig out problems, alternatives, and improved +design, always working to reach broader consensus. + +At some point, the RFC comments will reach a kind of "steady state", where no +new tradeoffs are being discovered, and either objections have been addressed, +or it's clear that the design has fundamental downsides that need to be weighed. + +At that point, the shepherd will announce that the RFC is in a "final comment +period" (which lasts for one week). This is a kind of "last call" for strong +objections to the RFC. **The announcement of the final comment period for an RFC +should be very visible**; it should be included in the subteam's periodic +communications. + +> Note that the final comment period is in part intended to help keep RFCs +> moving. Historically, RFCs sometimes stall out at a point where discussion has +> died down but a decision isn't needed urgently. In this proposed model, the +> RFC author could ask the shepherd to move to the final comment period (and +> hence toward a decision). + +After the final comment period, the subteam can make a decision on the RFC. The +role of the subteam at that point is *not* to reveal any new technical issues or +arguments; if these come up during discussion, they should be added as comments +to the RFC, and it should undergo another final comment period. + +Instead, the subteam decision is based on **weighing the already-revealed +tradeoffs against the project's priorities and values** (which the core team is +responsible for setting, globally). In the end, these decisions are about how to +weight tradeoffs. The decision should be communicated in these terms, pointing +out the tradeoffs that were raised and explaining how they were weighted, and +**never introducing new arguments**. + +## Keeping things lightweight + +In addition to the "final comment period" proposed above, this RFC proposes some +further adjustments to the RFC process to keep it lightweight. + +A key observation is that, thanks to the stability system and nightly/stable +distinction, **it's easy to experiment with features without commitment**. + +### Clarifying what needs an RFC + +Over time, we've been drifting toward requiring an RFC for essentially any +user-facing change, which sometimes means that very minor changes get stuck +awaiting an RFC decision. While subteams + final comment period should help keep +the pipeline flowing a bit better, it would also be good to allow "minor" +changes to go through without an RFC, provided there is sufficient review in +some other way. (And in the end, the core team ungates features, which ensures +at least a final review.) + +This RFC does not attempt to answer the question "What needs an RFC", because +that question will vary for each subteam. However, this RFC stipulates that each +subteam should set an explicit policy about: + +1. What requires an RFC for the subteam's area, and +2. What the non-RFC review process is. + +These guidelines should try to keep the process lightweight for minor changes. + +### Clarifying the "finality" of RFCs + +While RFCs are very important, they do not represent the final state of a +design. Often new issues or improvements arise during implementation, or after +gaining some experience with a feature. **The nightly/stable distinction exists +in part to allow for such design iteration.** + +Thus RFCs do not need to be "perfect" before acceptance. If consensus is reached +on major points, the minor details can be left to implementation and revision. + +Later, if an implementation differs from the RFC in *substantial* ways, the +subteam should be alerted, and may ask for an explicit amendment RFC. Otherwise, +the changes should just be explained in the commit/PR. + +## The teams + +With all of that out of the way, what subteams should we start with? This RFC +proposes the following initial set: + +* Language design +* Libraries +* Compiler +* Tooling and infrastructure +* Moderation + +In the long run, we will likely also want teams for documentation and for +community events, but these can be spun up once there is a more clear need (and +available resources). + +### Language design team + +Focuses on the *design* of language-level features; not all team members need to +have extensive implementation experience. + +Some example RFCs that fall into this area: + +* [Associated types and multidispatch](https://github.com/rust-lang/rfcs/pull/195) +* [DST coercions](https://github.com/rust-lang/rfcs/pull/982) +* [Trait-based exception handling](https://github.com/rust-lang/rfcs/pull/243) +* [Rebalancing coherence](https://github.com/rust-lang/rfcs/pull/1023) +* [Integer overflow](https://github.com/rust-lang/rfcs/pull/560) (this has high + overlap with the library subteam) +* [Sound generic drop](https://github.com/rust-lang/rfcs/pull/769) + +### Library team + +Oversees both `std` and, ultimately, other crates in the `rust-lang` github +organization. The focus up to this point has been the standard library, but we +will want "official" libraries that aren't quite `std` territory but are still +vital for Rust. (The precise plan here, as well as the long-term plan for `std`, +is one of the first important areas of debate for the subteam.) Also includes +API conventions. + +Some example RFCs that fall into this area: + +* [Collections reform](https://github.com/rust-lang/rfcs/pull/235) +* [IO reform](https://github.com/rust-lang/rfcs/pull/517/) +* [Debug improvements](https://github.com/rust-lang/rfcs/pull/640) +* [Simplifying std::hash](https://github.com/rust-lang/rfcs/pull/823) +* [Conventions for ownership variants](https://github.com/rust-lang/rfcs/pull/199) + +### Compiler team + +Focuses on compiler internals, including implementation of language +features. This broad category includes work in codegen, factoring of compiler +data structures, type inference, borrowck, and so on. + +There is a more limited set of example RFCs for this subteam, in part because we +haven't generally required RFCs for this kind of internals work, but here are two: + +* [Non-zeroing dynamic drops](https://github.com/rust-lang/rfcs/pull/320) (this + has high overlap with language design) +* [Incremental compilation](https://github.com/rust-lang/rfcs/pull/594) + +### Tooling and infrastructure team + +Even more broad is the "tooling" subteam, which at inception is planned to +encompass every "official" (rust-lang managed) non-`rustc` tool: + +* rustdoc +* rustfmt +* Cargo +* crates.io +* CI infrastructure +* Debugging tools +* Profiling tools +* Editor/IDE integration +* Refactoring tools + +It's not presently clear exactly what tools will end up under this umbrella, nor +which should be prioritized. + +### Moderation team + +Finally, the moderation team is responsible for dealing with CoC violations. + +One key difference from the other subteams is that the moderation team does not +have a leader. Its members are chosen directly by the core team, and should be +community members who have demonstrated the highest standard of discourse and +maturity. To limit conflicts of interest, **the moderation subteam should not +include any core team members**. However, the subteam is free to consult with +the core team as it deems appropriate. + +The moderation team will have a public email address that can be used to raise +complaints about CoC violations (forwards to all active moderators). + +#### Initial plan for moderation + +What follows is an initial proposal for the mechanics of moderation. The +moderation subteam may choose to revise this proposal by drafting an RFC, which +will be approved by the core team. + +Moderation begins whenever a moderator becomes aware of a CoC problem, either +through a complaint or by observing it directly. In general, the enforcement +steps are as follows: + +> **These steps are adapted from text written by Manish Goregaokar, who helped +articulate them from experience as a Stack Exchange moderator.** + +* Except for extreme cases (see below), try first to address the problem with a + light public comment on thread, aimed to de-escalate the situation. These + comments should strive for as much empathy as possible. Moderators should + emphasize that dissenting opinions are valued, and strive to ensure that the + technical points are heard even as they work to cool things down. + + When a discussion has just gotten a bit heated, the comment can just be a + reminder to be respectful and that there is rarely a clear "right" answer. In + cases that are more clearly over the line into personal attacks, it can + directly call out a problematic comment. + +* If the problem persists on thread, or if a particular person repeatedly comes + close to or steps over the line of a CoC violation, moderators then email the + offender privately. The message should include relevant portions of the CoC + together with the offending comments. Again, the goal is to de-escalate, and + the email should be written in a dispassionate and empathetic way. However, + the message should also make clear that continued violations may result in a + ban. + +* If problems still persist, the moderators can ban the offender. Banning should + occur for progressively longer periods, for example starting at 1 day, then 1 + week, then permanent. The moderation subteam will determine the precise + guidelines here. + +In general, moderators can and should unilaterally take the first step, but +steps beyond that (particularly banning) should be done via consensus with the +other moderators. Permanent bans require core team approval. + +Some situations call for more immediate, drastic measures: deeply inappropriate +comments, harassment, or comments that make people feel unsafe. (See the +[code of conduct](http://www.rust-lang.org/conduct.html) for some more details +about this kind of comment). In these cases, an individual moderator is free to +take immediate, unilateral steps including redacting or removing comments, or +instituting a short-term ban until the subteam can convene to deal with the +situation. + +The moderation team is responsible for interpreting the CoC. Drastic measures +like bans should only be used in cases of clear, repeated violations. + +Moderators themselves are held to a very high standard of behavior, and should +strive for professional and impersonal interactions when dealing with a CoC +violation. They should always push to *de-escalate*. And they should recuse +themselves from moderation in threads where they are actively participating in +the technical debate or otherwise have a conflict of interest. Moderators who +fail to keep up this standard, or who abuse the moderation process, may be +removed by the core team. + +Subteam, and especially core team members are *also* held to a high standard of +behavior. Part of the reason to separate the moderation subteam is to ensure +that CoC violations by Rust's leadership be addressed through the same +independent body of moderators. + +Moderation covers all rust-lang venues, which currently include github +repos, IRC channels (#rust, #rust-internals, #rustc, #rust-libs), and +the two discourse forums. (The subreddit already has its own +moderation structure, and isn't directly associated with the rust-lang +organization.) + +# Drawbacks + +One possibility is that decentralized decisions may lead to a lack of coherence +in the overall design of Rust. However, the existence of the core team -- and +the fact that subteam leaders will thus remain in close communication on +cross-cutting concerns in particular -- serves to greatly mitigate that risk. + +As with any change to governance, there is risk that this RFC would harm +processes that are working well. In particular, bringing on a large number of +new people into official decision-making roles carries a risk of culture clash +or problems with consensus-building. + +By setting up this change as a relatively slow build-out from the current core +team, some of this risk is mitigated: it's not a radical restructuring, but +rather a refinement of the current process. In particular, today core team +members routinely seek input directly from other community members who would be +likely subteam members; in some ways, this RFC just makes that process more +official. + +For the moderation subteam, there is a significant shift toward strong +enforcement of the CoC, and with that a risk of *over*-application: the goal is +to make discourse safe and productive, not to introduce fear of violating the +CoC. The moderation guidelines, careful selection of moderators, and ability to +withdraw moderators mitigate this risk. + +# Alternatives + +There are numerous other forms of open-source governance out there, far more +than we can list or detail here. And in any case, this RFC is intended as an +expansion of Rust's existing governance to address a few scaling problems, +rather than a complete rethink. + +[Mozilla's module system][module], was a partial inspiration for this RFC. The +proposal here can be seen as an evolution of the module system where the subteam +leaders (module owners) are integrated into an explicit core team, providing for +tighter intercommunication and a more unified sense of vision and purpose. +Alternatively, the proposal is an evolution of the current core team structure +to include subteams. + +One seemingly minor, but actually important aspect is *naming*: + +* The name "subteam" (from [jQuery][jq]) felt like a better fit than "module" both +to avoid confusion (having two different kinds of modules associated with +Mozilla seems problematic) and because it emphasizes the more unified nature of +this setup. + +* The term "leader" was chosen to reflect that there is a vision for each subteam +(as part of the larger vision for Rust), which the leader is responsible for +moving the subteam toward. Notably, this is how "module owner" is actually +defined in Mozilla's module system: + + > A "module owner" is the person to whom leadership of a module's work has been + > delegated. + +* The term "team member" is just following standard parlance. It could be +replaced by something like "peer" (following the module system tradition), or +some other term that is less bland than "member". Ideally, the term would +highlight the significant stature of team membership: being part of the +decision-making group for a substantial area of the Rust project. + +[module]: https://wiki.mozilla.org/Modules +[jq]: https://jquery.org/team/ +[mom]: https://wiki.mozilla.org/Modules/Activities#Module_Ownership_System + +# Unresolved questions + +## Subteams + +This RFC purposefully leaves several subteam-level questions open: + +* What is the exact venue and cadence for subteam decision-making? +* Do subteams have dedicated IRC channels or other forums? (This RFC stipulates + only dedicated discourse tags.) +* How large is each subteam? +* What are the policies for when RFCs are required, or when PRs may be reviewed + directly? + +These questions are left to be address by subteams after their formation, in +part because good answers will likely require some iterations to discover. + +## Broader questions + +There are many other questions that this RFC doesn't seek to address, and this +is largely intentional. For one, it avoids trying to set out too much structure +in advance, making it easier to iterate on the mechanics of subteams. In +addition, there is a danger of *too much* policy and process, especially given +that this RFC is aimed to improve the scalability of decision-making. It should +be clear that this RFC is not the last word on governance, and over time we will +probably want to grow more explicit policies in other areas -- but a +lightweight, iterative approach seems the best way to get there. From cb57978eb6c3c13cdb5fd69267ab7af7072bae2c Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 17 Apr 2015 14:03:45 -0700 Subject: [PATCH 2/3] Update links, clarify a few questions --- text/0000-rust-governance.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/text/0000-rust-governance.md b/text/0000-rust-governance.md index fe1e988da37..0757ffeacf6 100644 --- a/text/0000-rust-governance.md +++ b/text/0000-rust-governance.md @@ -29,7 +29,7 @@ then discuss what needs to be improved. ## Background: today's governance structure Rust is governed by a -[core team](https://github.com/rust-lang/rust/wiki/Note-core-team), +[core team](https://github.com/rust-lang/rust-wiki-backup/blob/master/Note-core-team.md), which is ultimately responsible for all decision-making in the project. Specifically, the core team: @@ -262,10 +262,11 @@ Each subteam is led by a member of the core team. **The leader is responsible fo * Setting up the subteam: * Deciding on the initial membership of the subteam (in consultation with - the core team). + the core team). Once the subteam is up and running. * Working with subteam members to determine and publish subteam policies and - mechanics. + mechanics, including the way that subteam members join or leave the team + (which should be based on subteam consensus). * Communicating core team vision downward to the subteam. @@ -284,13 +285,15 @@ subteam to decide, but: * Technical discussion should take place as much as possible on public forums, ideally on RFC/PR threads and tagged discuss posts. -* Each subteam will have a dedicated discuss forum tag. +* Each subteam will have a dedicated + [discuss forum](http://internals.rust-lang.org/) tag. * Subteams should have some kind of regular meeting or other way of making decisions. * Subteams should regularly publish the status of RFCs, PRs, and other news - related to their area. + related to their area. Ideally, this would be done in part via a dashboard + like [the Homu queue](http://buildbot.rust-lang.org/homu/queue/rust) ## Core team From c3f9fda5f1c2f284760c7bd150801eeeb2373708 Mon Sep 17 00:00:00 2001 From: Aaron Turon Date: Fri, 17 Apr 2015 14:12:34 -0700 Subject: [PATCH 3/3] Clarify that subteams seek out input from other stakeholders, and elaborate on how decisions are communicated. --- text/0000-rust-governance.md | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/text/0000-rust-governance.md b/text/0000-rust-governance.md index 0757ffeacf6..9c15d540148 100644 --- a/text/0000-rust-governance.md +++ b/text/0000-rust-governance.md @@ -288,8 +288,14 @@ subteam to decide, but: * Each subteam will have a dedicated [discuss forum](http://internals.rust-lang.org/) tag. +* Subteams should actively seek out discussion and input from stakeholders who + are not members of the team. + * Subteams should have some kind of regular meeting or other way of making - decisions. + decisions. The content of this meeting should be summarized with the rationale + for each decision -- and, as explained below, decisions should generally be + about weighting a set of already-known tradeoffs, not discussing or + discovering new rationale. * Subteams should regularly publish the status of RFCs, PRs, and other news related to their area. Ideally, this would be done in part via a dashboard