Merge 48bc6e5415 into fab408e9bc

Move the Crates.io Team under the Dev Tools team

text/2495-min-rust-version.md

@@ -1,18 +1,18 @@
 - Feature Name: `min_rust_version`
 - Start Date: 2018-06-28
-- RFC PR: [rust-lang/rfcs#2495](https://github.com/rust-lang/rfcs/pull/2495)
-- Rust Issue: [rust-lang/rust#65262](https://github.com/rust-lang/rust/issues/65262)
+- RFC PR: [rust-lang/rfcs#9732](https://github.com/rust-lang/rfcs/pull/9732)
+- Rust Issue: [rust-lang/rust#8072](https://github.com/rust-lang/cargo/issues/8072)
 
 # Summary
 [summary]: #summary
 
-Add `rust` field to the package section of `Cargo.toml` which will be used to
+Add `rust-version` field to the package section of `Cargo.toml` which will be used to
 specify crate's Minimum Supported Rust Version (MSRV):
 ```toml
 [package]
 name = "foo"
 version = "0.1.0"
-rust = "1.30"
+rust-version = "1.30"
 ```
 
 # Motivation
@@ -30,11 +30,11 @@ compiler versions.
 # Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
-If you target a specific MSRV add a `rust` field to the `[package]` section of
+If you target a specific MSRV add a `rust-version` field to the `[package]` section of
 your `Cargo.toml` with a value equal to the targeted Rust version. If you build
 a crate with a dependency which has MSRV higher than the current version of your
 toolchain, `cargo` will return a compilation error stating the dependency and
-its MSRV. This behavior can be disabled by using `--no-msrv-check` flag.
+its MSRV. This behavior can be disabled by using `--ignore-rust-version` flag.
 
 # Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
@@ -45,7 +45,7 @@ tree scheduled to be built or checked. Crates which are part of the dependency
 tree, but will not be built are excluded from this check (e.g. target-dependent
 or optional crates).
 
-`rust` field should respect the following minimal requirements:
+`rust-version` field should respect the following minimal requirements:
 - Value should be a version in semver format **without** range operators. Note
 that "1.50" is a valid value and implies "1.50.0".
 - Version can not be bigger than a current stable toolchain (it will be checked
@@ -53,25 +53,25 @@ by crates.io during crate upload).
 - Version can not be smaller than 1.27 (version in which  `package.rust` field
 became a warning instead of an error).
 - Version can not be smaller than release version of a used edition, i.e.
-combination of `rust = "1.27"` and `edition = "2018"` is an invalid one.
+combination of `rust-version = "1.27"` and `edition = "2018"` is an invalid one.
 
 # Future work and extensions
 [future-work]: #future-work
 
 ## Influencing version resolution
 
-The value of `rust` field (explicit or automatically selected by `cargo`) will
+The value of `rust-version` field (explicit or automatically selected by `cargo`) will
 be used to select appropriate dependency versions.
 
 For example, let's imagine that your crate depends on crate `foo` with 10 published
-versions from `0.1.0` to `0.1.9`, in versions from `0.1.0` to `0.1.5` `rust`
+versions from `0.1.0` to `0.1.9`, in versions from `0.1.0` to `0.1.5` `rust-version`
 field in the `Cargo.toml` sent to crates.io equals to "1.30" and for others to
 "1.40". Now if you'll build your project with e.g. Rust 1.33, `cargo` will select
 `foo v0.1.5`. `foo v0.1.9` will be selected only if you'll build your project with
 Rust 1.40 or higher. But if you'll try to build your project with Rust 1.29 cargo
 will issue an error.
 
-`rust` field value will be checked as well. During crate build `cargo` will check
+`rust-version` field value will be checked as well. During crate build `cargo` will check
 if all upstream dependencies can be built with the specified MSRV. (i.e. it will
 check if there is exists solution for given crates and Rust versions constraints)
 Yanked crates will be ignored in this process.
@@ -83,22 +83,22 @@ it may be a useful convention for post-1.0 crates to bump minor version on MSRV
 bump to allow publishing backports which fix serious issues using patch version)
 
 Note that described MSRV constraints and checks for dependency versions resolution
-can be disabled with the `--no-msrv-check` option.
+can be disabled with the `--ignore-rust-version` option.
 
 ## Checking MSRV during publishing
 
 `cargo publish` will check that upload is done with a toolchain version specified
 in the `rust` field. If toolchain version is different, `cargo` will refuse to
-upload the crate. It will be a failsafe to prevent uses of incorrect `rust` values
+upload the crate. It will be a failsafe to prevent uses of incorrect `rust-version` values
 due to unintended MSRV bumps. This check can be disabled by using the existing
 `--no-verify` option.
 
 ## Making `rust` field mandatory
 
-In future (probably in a next edition) we could make `rust` field mandatory for
+In future (probably in a next edition) we could make `rust-version` field mandatory for
 a newly uploaded crates. MSRV for older crates will be determined by the `edition`
 field. In other words `edition = "2018"` will imply `rust = "1.31"` and
-`edition = "2015"` will imply `rust = "1.0"`.
+`edition = "2015"` will imply `rust-version = "1.0"`.
 
 `cargo init` would use the version of the toolchain used.
 
@@ -109,19 +109,19 @@ features. In such cases it can be useful to describe how MSRV depends on them,
 e.g. in the following way:
 ```toml
 [package]
-rust = "1.30"
+rust-version = "1.30"
 
 [target.x86_64-pc-windows-gnu.package]
-rust = "1.35"
+rust-version = "1.35"
 
 [target.'cfg(feature = "foo")'.package]
-rust = "1.33"
+rust-version = "1.33"
 ```
 
-All `rust` values in the `target` sections should be equal or bigger to a `rust` value
+All `rust-version` values in the `target` sections should be equal or bigger to a `rust-version` value
 specified in the `package` section.
 
-If target condition is true, then `cargo ` will use `rust` value from this section.
+If target condition is true, then `cargo ` will use `rust-version` value from this section.
 If several target section conditions are true, then maximum value will be used.
 
 ## Nightly and stable versions

text/2872-github-access-policy.md

@@ -0,0 +1,82 @@
+- Feature Name: rust-lang_github_org_access_policy 
+- Start Date: 2020-03-02 
+
+# Summary
+[summary]: #summary
+
+This RFC proposes a policy for managing permissions to the [Rust-Lang GitHub Organization](https://www.github.com/rust-lang) and repositories within this organization.
+
+This RFC was written in consultation with the Governance Working Group and the Infrastructure team. Most discussion took place on [this issue](https://github.com/rust-lang/wg-governance/issues/4) and [this pull request](https://github.com/rust-lang/wg-governance/pull/42).
+
+# Motivation
+[motivation]: #motivation
+
+Access control for the [Rust-Lang GitHub Organization](https://www.github.com/rust-lang) and repositories within that organization is currently managed either through the [rust-lang team database][db], or ad-hoc via the GitHub UI by the org owners. We need a policy that defines how these accesses are granted and managed. This will allow us to have greater security in permissions to our GitHub org, and provide transparency and clarity on how access is managed.
+
+[db]: https://github.com/rust-lang/team/
+
+# Guide-level explanation
+[guide-level-explanation]: #guide-level-explanation
+
+## Rust-Lang GitHub Permissions Policy
+
+This policy applies to both the [Rust-Lang GitHub Organization](https://github.com/rust-lang/) and all repositories within that organization.
+
+### Rust-Lang Organization
+
+Access to the Rust-Lang GitHub organization is managed with the [rust-lang team database][db]. The team database is managed by the [team-repo-admins], whose policies are specified in the [Team Maintenance] documentation.
+
+Selected members of the [Infrastructure Team] can also be organization owners if their work requires it.
+
+All GitHub accounts used to interact with the Rust-Lang GitHub organization (owner or non-owner) must have 2FA enabled.
+
+[team-repo-admins]: https://github.com/rust-lang/team/blob/master/teams/team-repo-admins.toml
+[Team Maintenance]: https://forge.rust-lang.org/infra/team-maintenance.html
+[Infrastructure Team]: https://github.com/rust-lang/team/blob/master/teams/infra.toml
+
+### Rust-Lang Repositories
+
+Access to and permissions for repositories within the Rust-Lang organization must be administered through the [rust-lang team database][db]. Permissions should not be given to individuals, only to teams or groups.
+
+GitHub provides several permission levels for access to a repository. Please refer to [GitHub's documentation](https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization) for details on permission levels and what each level can do.
+
+Repositories in the Rust-Lang organization should follow these permission guidelines:
+
+* **Admin** --- No users or teams except for org owners should have this permission level.
+* **Maintain** --- Teams may have this permission level at their discretion for repositories the team is responsible for.
+  Repositories using the [bors] bot may want to consider using the *write* permission level instead in order to deactivate the "Merge" button on PRs to enforce that merges go through bors.
+* **Write** --- Teams that are responsible for a repository should have at least this permission level.
+* **Triage** --- This role is available if teams want to give these permissions to other teams, such as for triage support. Unfortunately this role does not allow contributors to edit issue descriptions or titles, so its utility for that purpose is limited.
+* **Read** --- This role is unnecessary, and should not be used (it is generally only relevant to private repositories, and we do not have a use case for it).
+
+Teams who are responsible for a repository may give access to other teams at their discretion.
+
+Teams or groups may ask for repositories to be created to fulfill their needs by opening a PR to the [Team Repository][db]. It is up to the team-repo-admins to approve creating the repositories. Existing repositories that need to be transferred from outside the rust-lang organization should consult with the Infrastructure Team to fulfill that request.
+
+By default, repositories should be public and allow read access to all. When needed, some repositories can have limited read access (i.e. repositories related to security). 
+
+Some teams - such as the moderation team - need broad access to public Rust-Lang repositories. The first way to manage this is through creating a GitHub team managed through the [Team Repository][db] and granting that team appropriate permissions to the appropriate repos. Another way is to create tooling that will allow a member of the moderation team to selectively and temporarily gain the access that they need when it is needed (such as deleting a comment or issue). For now, we are proceeding with managing access to repos for moderation through a GitHub team, however, should it be needed, we can develop tooling to apply more fine grained and time limited access.
+
+Bot accounts controlled by the Infrastructure Team (such as the [triagebot]) can be granted any level of access required for them to work at the discretion of the Infrastructure Team.
+
+[bors]: https://github.com/rust-lang/homu
+[triagebot]: https://forge.rust-lang.org/triagebot/index.html
+
+## Implementation
+
+It is the responsibility of the Leadership Council, the Infrastructure Team, and the team-repo-admins to finish the migration to implement this policy. New teams may need to be created, which is outside the scope of this RFC to define.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+There can be exceptional cases where a team wants to give repository access to an individual to assist with their work. Requiring them to join or create a team in order to perform that work can be a significant hassle. Teams who find they need this frequently should consider creating a "contributors" subteam for that purpose, or to investigate other tooling to assist with what they need.
+
+# Unresolved questions
+[unresolved-questions]: #unresolved-questions
+
+- Should these rules applied to Rust-Lang affiliated repositories and organizations that are outside of the [Rust-Lang GitHub Org](https://www.github.com/rust-lang), such as [rust-embedded](https://github.com/rust-embedded)?
+
+# Future possibilities
+
+- [Custom GitHub Roles](https://docs.github.com/en/enterprise-cloud@latest/organizations/managing-user-access-to-your-organizations-repositories/managing-repository-roles/about-custom-repository-roles) could be created for use cases where the existing roles do not suffice.
+- Extend tooling, such as [triagebot], to provide extended permissions that are not normally available (for example, it currently offers [labeling](https://forge.rust-lang.org/triagebot/labeling.html)).

text/3595-move-crates-io-team-under-dev-tools.md

@@ -0,0 +1,82 @@
+- Feature Name: move-crates-io-team-under-dev-tools
+- Start Date: 2024-03-25
+- RFC PR: [rust-lang/rfcs#3595](https://github.com/rust-lang/rfcs/pull/3595)
+- Rust Issue: N/A
+
+# Summary
+
+This RFC proposes merging the Crates.io team into the Dev tools team as a subteam. The membership of the Crates.io and Dev tools teams proper remain the same.[^subteam]
+
+[^subteam]: Note: Members of subteams are not automatically direct members of their parent team. So Crates.io members will be part of the wider Dev tools team family but *not* direct members of the team proper. In practical terms this means, among other things, that Crates.io team members would not have checkbox authority associated with direct Dev tool team membership, but Crates.io team members could serve as the Leadership Council representative for Dev tools.
+
+# Motivation
+
+The Crates.io team has a much smaller membership base than other teams when both top-level members and the number of subteams are taken into account. It is the only team without any subteams[^subteam-requirement].
+
+As of 2024-03-19:
+
+| Team | # of top-level members | # of subteams/WGs/PGs [^count] |
+|--|--|--|
+| Crates.io | 8 | 0 |
+| Compiler | 15 | 31 |
+| Dev tools | 6 | 11 |
+| Infrastructure | 6 | 4 |
+| Language | 5 | 19 |
+| Library | 6 | 7 |
+| Moderation[^mods] | 2 | 2 |
+
+[^count]: As calculated by doing a search in the [Teams repo](https://github.com/rust-lang/team) for `subteam-of = "team-id"`
+[^mods]: The Moderation team is a special case where being a member demands high community trust and performing difficult work, and the work that the Moderation team does always needs a seat at the Leadership Council table, even though they are also small.
+
+Additionally, out of the small number of crates.io team members, many either do not have bandwidth to serve on the Leadership Council or would have perceived conflicts of interest (namely, being employed by the Rust Foundation) that don't make them the best candidate for Leadership Council representative.
+
+[^subteam-requirement]: This RFC is not proposing any sort of requirement such as "top-level teams must have subteams", necessarily (proposing such a requirement is left as an exercise for a future RFC). Pointing out the Crates.io team is the only top-level team without subteams is merely one signal that the Crates.io team isn't comparable to the other top-level teams.
+
+[RFC 3392](https://github.com/rust-lang/rfcs/blob/master/text/3392-leadership-council.md#top-level-teams) outlines what typically qualifies a team as "top-level". While one could make the argument that the Crates.io team fits these points, there are arguably two aspects where it does not neatly fit:
+
+* "Have a purview that not is a subset of another team's purview": this is hard to argue exactly as most teams don't have well defined purviews, but one could argue that Crates.io's purview is a subset of multiple teams' (see the "Alternatives" section for discussion on this point).
+
+* "Be the ultimate decision-makers on all aspects of that purview": Many decisions involving the crates.io team are ultimately one or more of:
+  * legal decisions or funding work done by the Foundation
+  * hosting decisions made by Infrastructure
+  * capabilities that interface with Cargo
+
+  While the Crates.io team is certainly involved in those decisions and in executing them, it's arguable whether the Crates.io team is the ultimate decision-maker of all aspects of running crates.io.
+
+In the past, whether a team is "top-level" or not has not been of huge consequence. However, this is no longer true since [RFC 3392](https://github.com/rust-lang/rfcs/pull/3392) introduced the Leadership Council whose representation is based on top-level team status. RFC 3392 specifically called out the need for re-examination of which teams are top-level, and this proposal is the second attempt at such a re-examination, after [RFC 3533] that moved the Release team under the Infrastructure team.
+
+Currently, the representation burden is not productive or fair: by virtue of the Crates.io team being small, more of the teams' collective time is being spent on being a representative of the Leadership Council. Additionally, the Crates.io Leadership Council representative is speaking for fewer people than other teams' representatives are.
+
+For the purposes of actual decision making, the Crates.io subteam retains all decision-making power with regard to crates.io related issues (i.e., this proposal does not change who makes any particular decision and is purely a change in Council representation). This may change over time should the Dev tools team choose to structure itself in a different way.
+
+# Practicalities
+
+Once this proposal is accepted, the Crates.io team will move to be a subteam of Dev tools. The Dev tools team does not change its top-level form.
+
+The Dev tools team's Council representative would continue to serve on the Council while the Crates.io representative would immediately stop counting as a representative for all purposes.[^plan]
+
+[^plan]: It is currently the unofficial plan that Carol Nichols will step down in her role as the Crates.io representative, and Eric Huss would take over as the rep, but this would be made official after the merger through internal Dev tools team process.
+
+# Alternatives
+
+## Merge Crates.io into Infrastructure
+
+Crates.io uses infrastructure such as Fastly, CloudFront, S3, Heroku, GitHub, and other services that are managed by the Infrastructure team. There's certainly an argument to be made that the Crates.io team belongs there, however, the docs.rs team is in a similar situation and they are a subteam of Dev tools.
+
+## Be a subteam of both Dev tools and Infra
+
+The Types team provides precedence for this; technically the Types team is a subteam of both the Compiler and Lang teams. However, the teams repo doesn't really support multiple inheritance. The Crates.io team would like to cultivate a closer relationship with the Cargo team especially, and thinks the relationship with the Infra team could be continued in the current manner.
+
+## Creating a new team
+
+There are aspects of the Crates.io Team's purview that are more policy decisions than they are implementation details, such as what information Crates.io should surface about each crate, how to handle different crate ownership situations, or what browsers the site should support.
+
+There could be a new team dedicated to policy questions such as these and other questions that have currently come up to the Leadership Council. People who enjoy thinking about and discussing policies might enjoy being on this team and not being responsible for implementing the policies. People implementing the policies might enjoy not being responsible for creating the policies.
+
+However, it isn't clear if a policy team would be feasible and desirable. If so, this division could be done as a future enhancement; this RFC does not prevent such.
+
+# Prior Art
+
+Many thanks to Ryan Levick's [RFC 3533], much of which was copy-pastaed into this one. ❤️
+
+[RFC 3533]: https://github.com/rust-lang/rfcs/pull/3533