Publish project policy and governance documentation

[ehuss]

Part of RFC 3392 sets up a requirement for publishing policy decisions, but did not specify exactly where or how to do that, or quite what exactly that means. This issue is for tracking that, and collecting ideas and feedback on it.

[ehuss]

TLDR: I want to publish project policy and governance on the Rust Forge.

Project Policy Publication

This is a proposal for how to publish and track Rust-lang Project governance policy and project-wide processes.

Motivation

RFC 3392 (and previously RFC 1068) established some policies of the Rust project, as well as process for evolving that policy, but did not go into detail on how policy should be recorded or communicated. RFCs do not serve as living documents, which makes them ill-suited for a holistic reference of project policy. This document is a proposal to establish a central place to record and version this information, and keep it up-to-date.

Contents

This governance documentation should include the following:

• A copy of the majority of RFC 3392, which establishes the Leadership Council and authority granted to them.
  • This includes:
    • The existence, definition, authority, duties, expectations, membership, structure, decision-process, evaluation, and transparency of the Leadership Council.
    • The definition, structure, and rules of evolution of the top-level teams of the Project.
    • The moderation structure of the Project.
  • The exact text will be adjusted to fit the form of stating what the policy is, and not what it is proposing to be. For example, the following should not be included:
    • The proposal and ratification aspects of RFC 3392 (it has already been accepted).
    • The phrasing of "RFC" (this is no longer an RFC).
    • Suggestions on what the Council should start with (that isn't policy).
    • Reference materials (it will have a single link to RFC 3392 for reference).
• The rules and requirements of updating this governance documentation.
• Any new policy decisions made by the Leadership Council, as allowed by the current policy, and that have gone through the accepted process. Some examples of upcoming policies are:
  • Process and interaction with the Rust Foundation.
    • Project Director selection.
  • Establishing definitions and boundaries of Project membership.
  • Process for managing legal requirements and issues for the Project and its participants.
  • Process for improving and coordinating cross-team communication and cohesion.
  • Management of credentials and privileges of the Project.
  • The RFC decision process.
• Team charters and contact information.

This documentation will not contain:

• Internal team processes. This documentation should be managed by each team in a place that is appropriate for them.
• Explicit version history of changes as text in the documents. The history will be available implicitly via the git log of the respective files. Git comments must contain enough information to explain why changes were made, and be clear about where the change came from (for example, a link to an RFC, or a proposal agreed on by the Council that shows that approval and the motivation/justification). It is ok to include links for context of new policy (such as new RFCs) as it seems useful.

Location

I am proposing to host this documentation on the Rust Forge. This site serves as a central hub for the development of Rust, and already tracks the governance and policy of the project (although very outdated).

An alternative proposal is to use https://github.com/rust-lang/governance as a site for hosting governance documentation. I personally would like to avoid spreading information too thin across different sites, potentially making it more difficult for people to discover or find information. I also don't feel any particular downsides to using the Forge, and it is an already established site and system.

Policy Change Process

Only Leadership Council members are allowed to commit non-trivial changes to the policy. Trivial changes, such as typos or technical formatting, can be committed by anyone with permissions on the Forge site (which itself needs some clarification in the near future).

Changes must be allowed by existing policy, and have followed the process as required by existing policy (such as via accepted RFCs).

The Council Librarians will be responsible for ensuring that the documentation is kept up-to-date, and that changes get committed within a reasonable time frame.

Non-trivial changes must have been publicized in some way to the community before they are committed. For example, the approval of an RFC serves as sufficiently public notice.

Management of team charters will be defined later once the Council has decided on the team chartering process and format. For example, minor changes to team charters, such as changes in how to contact the team, or changes in team membership rules, could be approved by a single Council member when it is clear the team has approved it.

[yaahc]

Would this also serve as a location for policy for subteams? I noticed the mention of charters, but the definition of charters is currently ambiguous. In T-style we have a separate charter and team policy document. Our principle for differentiating what goes where is that any policies that are "foundational" insofar as they inform other policies goes into the charter, and everything else goes into the policy document¹.

My hope is that we end up with a system where each team can maintain they're own policies and that all the teams policies are organized in a way that mirrors the tree structure of the project itself.

Footnotes

1. admittedly this rule still feels pretty nebulous to me ↩

[ehuss]

My thinking is that the charter would include just the basics (such as their mission, membership requirements, contact information), and all process and policy information would be documented wherever the team wants. Generally it would include the bare minimum information we want to ensure every team has.

I think that will be a much longer term goal, and I probably should have clarified in that point that it is a hypothetical of the kinds of things we might also want to include. I didn't mean to imply that was anything definite, and we'll need to decide how to handle that once we start that process.

[yaahc]

Looping that back because there's some ambiguous wording ("that longer term goal"), and I wanna make sure I understand correctly before I reply:

You said that your plan is to just focus on the core fundamental information that every team needs to document. The goal of "creating a centralized location for all policies for all teams" is a much longer-term goal that you didn't intend to imply as part of this proposal.

If so, understood. I don't think I agree that the follow-up goal needs to be a much longer term goal, though I guess getting it all inline will probably take a lot more doing. I could totally imagine just having "links to those additional policies" being part of the set of basic information expected for each charter. That said, this doesn't represent a blocking objection or anything to this proposal as stated. I'm focusing separately on the goal of making it easier to navigate and understand team processes across the project. I'm happy to separate this out into a follow-up proposal once you've landed this one. I appreciate the clarification and thank you for working on this!

[ehuss]

Oh, sorry for the ambiguity! Yes, that is correct. And yea, I would like to get some movement on documenting team charters more clearly sooner than later, but my expectation is that will be a slow process (getting everyone to agree what to include, getting teams to write the missions and team requirements, etc.). And I would love to have your help with it! Soon I'll open some tracking issues for this kind of stuff.

[ehuss]

I have posted rust-lang/rust-forge#698 to close this out.

[rylev]

Does rust-lang/rust-forge#698 completely close this issue? It seems that we still need a place for policy documentation to go.

[ehuss]

That was my intent. Can you say more about what might not be clear about what kinds of policy gets documented and where it goes?

My intent is that all internal Council policy goes into this repo (https://github.com/rust-lang/leadership-council/tree/main/procedures, https://github.com/rust-lang/leadership-council/tree/main/committees, etc.), and that all policy that affects the project as a whole goes into https://forge.rust-lang.org/governance/. To start off, there is governance/council.html and governance/moderation.html, and the intent is to add chapters as we build up more policy. Some examples of things that might show up there in the future:

• A chapter that better defines what teams/working-groups/project-groups/etc are, and what constitutes the Project.
• Chapters defining charters/missions of the teams, and some other basic properties of each team.
• Recommended decision making processes that teams should follow (basically something like https://rust-lang.github.io/rfcs/1068-rust-governance.html#decision-making, but maybe a little clearer, and maybe tied to any improvements of the RFC process we tackle).
• Various miscellaneous things like maybe a chapter on licensing policy.

I don't have a really concrete plan on what exactly goes there and what it'll look like, but those are some rough ideas of how it might grow.