You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: text/3533-combine-infra-and-release-teams.md
+5-8Lines changed: 5 additions & 8 deletions
Original file line number
Diff line number
Diff line change
@@ -15,7 +15,7 @@ Historically the Release team has had a much smaller scope than other teams. It
15
15
16
16
[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 Release team fits these points, there are arguably two aspects where it does not neatly fit:
17
17
* "Have a purview that is foundational to the Rust Project": while Rust releases are obviously extremely important, it is hard to argue that they are "foundational". Just like there is no CI team (despite CI also being extremely important), the release process is not a foundational piece of what makes Rust, Rust.
18
-
* "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 the Infrastructure team's purview is roughly "to maintain and administer all logistical activities for the continuing operation of the Rust project" which would then be a superset of what the Release team's purview is.
18
+
* "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 the Infrastructure team's purview is roughly "to maintain and administer all logistical activities for the continuing operation of the Rust project" which would then be a superset of what the Release team's purview is. The Infrastructure team's purview already contains user-facing components (e.g.,the Rust Playground and crates.io CDN infrastructure) so adding additional user-facing concerns is not a categorical expansion of that purview.
19
19
20
20
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. This RFC specifically called out the need for re-examination of which teams are top-level, and this proposal is the first attempt at such a re-examination. The most immediate practical reason for being strict with the definition of "top-level" is to balance "the desire for a diverse and relatively shallow structure while still being practical for productive conversation and consent."
21
21
@@ -29,6 +29,10 @@ Once this proposal is accepted, the Release team will move to be a subteam of In
29
29
30
30
The Infrastructure team's Council representative would continue to serve on the Council while the Release representative would immediately stop counting as a representative for all purposes.[^plan]
31
31
32
+
As part of this change, wg-triage will move out from under the Release team and move to be a part of Launching Pad until a more appropriate home for the working group can be found.
33
+
34
+
[^plan]: It is currently the unofficial plan that Ryan Levick will step down in his role as the Infrastructure representative, and Mark Rousskov would take over as the rep, but this would be made official after the merger through internal Infrastructure team process.
35
+
32
36
# Alternatives
33
37
34
38
## Combining Infra and Release into a new team
@@ -48,10 +52,3 @@ It is not clear that there are any benefits to this alternative that are worth t
48
52
Crates.io is arguably the other team next to Release with the smallest purview compared to other teams. We may want to merge at least part of the team (i.e., the part responsible for running the crates.io infra) into Infrastructure.
49
53
50
54
This is not included in this proposal, because there are more open questions in this case than in the case of the Release team (e.g., where would the other part of the crates.io team - in charge of crates.io policy - go?).
51
-
52
-
# Open questions
53
-
54
-
* Should the team still be called *Infrastructure*?
55
-
* What happens to wg-triage? Should this be moved out of Release as a working group of Infrastructure? Should it instead move to another team (perhaps compiler)?
56
-
57
-
[^plan]: It is currently the unofficial plan that Ryan Levick will step down in his role as the Infrastructure representative, and Mark Rousskov would take over as the rep, but this would be made official after the merger through internal Infrastructure team process.
0 commit comments