core (roadmap)
The focus of this year is on project health, specifically as it relates to Rust's governance structure.
The core team will drive these efforts in coordination with all Rust teams and working groups. As the Rust teams have grown over the years, there is increasingly less cross-chatter that naturally happens due to shared membership of teams, and this RFC aims to improve our written documentation to provide for a smoother onboarding process for new team members, as well as improving the ability of current team members to evaluate who to consult on new ideas or projects.
The Rust project governance has grown into a large and diverse structure, with most teams not having well defined expectations about scope and membership. As the project has grown, we have also struggled with a unified place for new and existing contributors to learn about active efforts and join in. Our efforts to establish charters and unified vocabulary will help contributors new and old to navigate our organizational structure. Our expectation is that this work will also help each team better understand what their aims are and will help the core team better serve the team's needs.
The Rust teams, in concert with the core team, will work to establish a charter for each of the Rust teams over the course of the year, with an aim for defining, particularly, the purpose and membership requirements. Our goal is that going into 2022, all active groups within the Rust project will have well-defined charters and membership. This includes all pre-existing groups in Rust governance, including domain working groups, project groups, and working groups.
We have a number of active efforts in the Rust project which are not currently called teams. By the end of the year, we expect that regardless of the naming, every active group in Rust’s governance will be chartered. The core team will additionally propose an RFC clarifying the naming and setting policy guidelines for team formation towards the end of the year, once we have worked through a number of charters and can set these expectations better.
This RFC does not aim to provide a fine-grained framework for precisely what form these charters will take. Furthermore, it is our expectation that these charters will be “living” documents, parts of which will be updated as the group changes roles or membership, and the precise expectations of charters are likely to evolve over time.
However, at minimum, they should provide answers to these questions:
The core team, upon merging of this RFC, will prepare a new repository for governance RFC work. This repository will have empty charters for the existing known groups, and changes will be approved by the core team. It is expected that teams forming new groups after the merge of this RFC will prepare charters and merge them into that repository before kicking off the group's tasks.
The reason a separate repository is chosen is because the underlying format and document style is likely to be quite different; we also intend to track changes via in-place updates to charters rather than the RFC style of filing a new RFC which documents the new state. The structure of the repository is likely to also have more nesting/folders than the rfcs repository.
This RFC proposes using the DARCI framework for this section, as a way to both provide structure, and help satisfy the goal that readers can quickly decide whether the group is responsible for decisions or implementation work on a particular topic, or if they need to be consulted (but not able to solely approve), or if they are merely asking to be informed.
This section should also reference charters for subgroups. For example, the compiler and dev-tools teams have a large number of subgroups which should be documented here.
Groups should aim to limit these sections to start out, especially in the area of being accountable/responsible: one of the goals of charter work is to ensure that our governance structure matches reality, so it is better to not be responsible for things that you do not think you can do well. Charters are living documents, and growing scope over time is reasonable: starting out with a core set that you know the team can be successful with is a good idea. Documenting what is left temporarily out of scope is a good idea.
Each of these sections should define topics which fall into them. It is possible that for some sections there will be multiple lists of topics, with different subsets of the group (e.g. leaders vs. the whole group) defined as responsible for that subsection.
For some groups, it may be useful to select a subset of consensus builders or deciders, but for most teams it is expected that this will simply be the team as a whole. This can also be on a per-topic basis; for example, a team can record that bikeshed questions are for the team leads to ultimately decide. It is also possible that some questions are escalated to some other team. For example, project groups would often record the parent team as the decision makers, but the project group is still accountable for completing the work to prepare for that decision, and has some amount of "small" decision making.
This is the set of topics that the team is accountable for completing or executing work in. The most common case of being accountable but not responsible is when a subgroup has been delegated the responsibility for executing.
The goal for this section is that this is the group that will be asked and consulted with if the task(s) are not being done in a timely manner. They should also be actively tracking work in any area they are accountable for, so that they can communicate to groups which need to be informed if the task is not done; ideally in time for more resources to be invested or for others to know that the dependency they may need won't be ready.
This is the set of topics on which the group are the ones engaged in work. This is how, for example, people can discover where to go if they're interested in actively working on some feature or area.
This is the set of topics on which this group should be consulted. In particular, consultation means that the group may have feedback, but they are not going to make any final decisions.
This is the set of topics on which this group should be informed. This means that the group will not provide feedback on the topic.
The goal for this section is that some teams would benefit from knowing of particular decisions or events, but don't need to engage on the process itself. One example is changes made in rust-lang/rust with sufficient weight that we want to mention them in release notes - the relnotes label is a way to passively inform the release team of this.
This section establishes the process (or processes) by which the team makes decisions. This is useful for both team members and outside parties. Any normative documents produced by the team (for example, the Reference for lang team) should also be listed here.
The membership expectations can be diverse for various groups. Some groups can meet multiple times a week and expect team members to devote time outside these meetings to drive proposals and otherwise contribute, while other teams can have no synchronous meetings and expect bursts of work from time to time.
Especially when multiple teams are interfacing, or a new member is asked to join a team, having this documentation is immensely valuable to communicate up front the ground rules for involvement.
This can include the meeting platforms used and chat channels. It’s the contact information for the whole group, not just the contact person noted previously.
This question is aimed at aiding parties within the Rust organization outside the team to identify who to approach with questions or feedback. This may be a team lead, but could also just be a point of contact.
Currently, not all teams have such a clearly defined point of contact. This makes it hard for people seeking to interface with the team to establish communications, especially when they don’t currently know Rust’s governance.
This is likely not the person that should be contacted e.g. requesting mentoring help as a new contributor or when looking for something to do. However, the core team or other project leaders may reach out here to help with e.g. scheduling a meeting with the team. If there's a lead (or leads), it can often be true that they are also the point of contact, but some groups don't have leads. All groups should have a point of contact, though.
Today, Rust teams decide individually where to host documents and have discussions. We do not want to take away these choices from the Rust teams: we believe that teams know best what works for them. However, sometimes the divergence here is unintentional, and providing defaults that work well can be an excellent way to remove friction.
The specific details of the vocabulary and processes that we will seek to unify are not yet clear, primarily because there is no one place where all of the specifics of team activity are laid out. As we begin to establish charters over the course of the year, we will begin to identify common needs and current choices, and will work to diverge only when needed.
Some examples of currently divergent process and vocabulary:
A frequent concern -- even amongst our most active team members -- is that knowing what is going on in teams can be difficult. It can be difficult to identify what efforts are active or temporarily paused, and what kind of feedback is sought for on proposals.
As part of our charter and unified process/vocabulary work, we would like to surface the ongoing work in teams in a common way. The aim is to target contributors/maintainers, both existing and new, not people aiming to propose a new project. (It may be a useful gauge of how much bandwidth the team has left, though).
It is expected that the road towards tracking team efforts for all of our teams is going to require more work than we can fit in this coming year. That said, a number of our teams have already established or are working to establish similar tracking dashboards: the language, library, and crates.io teams. We expect to unify the structure of these existing dashboards and publish guiding documentation which other teams can use as a framework for making their own; by the end of the year we want to add a compiler team dashboard but do not expect to be able to expand the set much further.
Rust’s roadmap process was established by RFC 1728 in 2016. Since then, we have had 4 roadmaps, all of which have included some amount of governance work:
In the 2017, 2019, and 2020 roadmaps, a major challenge of following through on the aims for Rust governance has been a lack of explicit, achievable, goals. In 2018, we did a much better job of identifying explicit goals, but the 2018 edition and related work pulled significant resources from the governance work proposed in the roadmap. This year, we expect our primary focus to be governance. We also lay out a very concrete set of tasks for teams this year. Work this year in the language and library teams in particular has helped us formalize exactly what is needed from charters and how to help teams be productive.
This RFC does not lay out any technical work items, including the 2021 edition. It is expected that teams will continue to work on these throughout the year, but in conducting internal surveys from team leads, it is our impression that there is no unifying theme for these efforts. The core team encourages individual teams to also perform internal planning on what they'd like to do over the next year, and ideally post those in public places (such as Inside Rust or the main blog, depending on intended audience). The core team has been doing some more thinking on the 2021 Edition RFC, but we are fairly confident that the contents of this roadmap will not be altered by the final shape of those efforts.
The project will not directly set a roadmap for the Foundation, though the project’s roadmap efforts are likely to play into the Foundation's own roadmapping work.
None major enough to document here yet.
None yet.