Merge pull request #28 from rust-lang/team

Add documentation about the libs teams and membership.

Author: m-ou-se

book.toml

@@ -7,7 +7,7 @@ multilingual = false
 src = "./src"
 
 [build]
-create-missing = false
+create-missing = true
 
 [rust]
 edition = "2018"
@@ -19,6 +19,6 @@ renderer = ["html"]
 [output.linkcheck]
 
 [output.html]
-default-theme = "rust"
-git-repository-url = "https://github.com/rust-lang/std-dev-guide"
 git-repository-icon = "fa-github"
+git-repository-url = "https://github.com/rust-lang/std-dev-guide"
+edit-url-template = "https://github.com/rust-lang/std-dev-guide/edit/master/{path}"

src/SUMMARY.md

@@ -4,7 +4,10 @@
 
 [Getting started](./getting-started.md)
 
-[Reviewer checklist](./reviewer-checklist.md)
+- [The library team](./team.md)
+  - [Meetings](./meetings.md)
+  - [Membership](./membership.md)
+  - [Reviewing](./reviewing.md)
 
 ---
 

src/meetings.md

@@ -0,0 +1,21 @@
+# Meetings
+
+Currently, both the Library Team and the Library API Team have a weekly hour-long meeting.
+Both meetings are open to non-members by default, although some might be (partially) private when agenda topics require that.
+
+The meetings are held as video calls through [Jitsi](https://meet.jit.si/), but everyone is welcome to join without video or even audio.
+If you want to participate in meeting discussions through text, you can do so through Jitsi's chat function.
+
+Meetings and their agendas are announced in the [#t-libs/meetings](https://rust-lang.zulipchat.com/#narrow/stream/259402-t-libs.2Fmeetings) channel on Zulip.
+
+Agendas are generated by the [`fully-automatic-rust-libs-team-triage-meeting-agenda-generator`](https://github.com/rust-lang/libs-team/tree/main/tools/agenda-generator),
+which will include all relevant issues and PRs, such as those tagged with `I-nominated` or `S-waiting-on-team`.
+
+If you have any specific topics you'd like to have discussed in a meeting, feel free to open an issue on the [`libs-team`](https://github.com/rust-lang/libs-team/) repository
+and mark it as `I-nominated` and `T-libs` or `T-libs-api`. Or just leave a message in the Zulip channel.
+
+All the meetings, including those of the library working groups, can be found on our Google Calendar:
+
+<iframe width="100%" height="500px" src="https://calendar.google.com/calendar/embed?src=9kuu8evq4eh6uacm262k0phri8%40group.calendar.google.com"></iframe>
+
+[ICS link](https://calendar.google.com/calendar/ical/9kuu8evq4eh6uacm262k0phri8%40group.calendar.google.com/public/basic.ics)

src/membership.md

@@ -0,0 +1,35 @@
+# Membership
+
+## Library Contributors
+
+Membership to Library Contributors can be offered by the Library Team once
+a regular contributor has made a number of significant contributions over some period of time,
+and has shown to have a good judgement on what changes are acceptable.
+
+## The Library Team and Library API Team
+
+The Library Team and Library API Team pick their own members,
+although it's expected that new members come from the Library Contributors or another Rust team,
+and have already been involved in relevant library work.
+
+## The process
+
+In all cases, the process of adding a new members goes as follows:
+
+1. A member of the Library (API) Team proposes the addition of a contributor on our private mailing list.
+   This proposal includes:
+   - A short description of what this person has been working on; how they have been contributing.
+   - A few specific examples of cases where this person clearly communicated their ideas.
+   - A few specific examples that show this person understands what are and what aren't acceptable changes.\
+     Someone who makes significant contributions but usually needs to make large adjustments to their PRs might be a wonderful external contributor,
+     but might not yet be a good match for membership with review permissions expecting to judge other contributions.
+2. Every single team member is asked for their input. No team member must have any objections.
+   - Objections are ideally shared with the entire team, but may also be shared privately with the team lead or the moderation team.
+   - Objections ideally include examples showing behavior not in line with the expectations described under step 1
+     (or the code of conduct).
+3. The team lead reaches out to the moderation team to ask if they are aware of any objections.
+4. Only once the team members and the moderation team agree, the new contributor is invited to join.
+5. If the new contributor agrees too, a PR is sent to the `team` repository to add them.
+6. A blog post is published in the Internals Blog with a short introduction of the new contributor.
+   The contents of this post can be based on some of the points brought up in the email from step 1.
+   The contents are first checked with the new contributor before it is published.

src/reviewer-checklist.md

@@ -0,0 +1,36 @@
+# Reviewing
+
+Every member of the Library Team, Library API Team, and Library Contributors has 'r+ rights'.
+That is, the ability to approve a PR and instruct [`@bors`](https://bors.rust-lang.org/)
+to test and merge it into Rust nightly.
+
+If you decide to review a PR, thank you!
+But please keep in mind:
+
+- You are always welcome to review any PR, regardless of who it is assigned to.
+  However, do not approve PRs unless:
+    - You are confident that nobody else wants to review it first. If you think someone else on the team would be a better person to review it, feel free to reassign it to them.
+    - You are confident in that part of the code.
+    - You are confident it will not cause any breakage or regress performance.
+    - It does not change the public API, including any stable promises we make in documentation, unless there's a finished FCP for the change.
+      - For unstable API changes/additions, it can be acceptable to skip the RFC process if the design is small and the change is uncontroversial.
+        Make sure to involve `@rust-lang/libs-api` on such changes.
+- Always be polite when reviewing: you are a representative of the Rust project, so it is expected that you will go above and beyond when it comes to the Code of Conduct.
+
+## High-five rotation
+
+Some of the members of the team are part of the 'high-five rotation';
+the list from which the high-five bot picks reviewers to assign new PRs to.
+
+Being a member of one of the teams does not come with the expectation to be on this list.
+However, members of this list should be on at least one of the three library teams.
+
+If the bot assigns you a PR for which you do not have the time or expertise to review it,
+feel free to reassign it to someone else.
+To assign it to another random person picked from the high-five rotation,
+use `r? rust-lang/libs`.
+
+If you find yourself unable to do any reviews for an extended period of time,
+it might be a good idea to (temporarily) remove yourself from the list.
+To add or remove yourself from the list, send a PR to change the
+[high-five configuration file](https://github.com/rust-lang/highfive/blob/master/highfive/configs/rust-lang/rust.json).

src/reviewing.md

@@ -0,0 +1,62 @@
+# The Library Team
+
+The Rust standard library and the official `rust-lang` crates are
+the responsibility of the Library Team.
+The Library team makes sure the libraries are maintained,
+PRs get reviewed, and issues get handled in time,
+although that does not mean the team members are doing all the work themselves.
+Many team members and other contributors are involved in this work,
+and the team's main task is to guide and enable that work.
+
+## The Library API Team
+
+A very critical aspect of maintaining and evolving the standard library is its stability.
+Unlike other crates, we can not release a new major version once in a while for backwards
+incompatible changes. Every version of the standard library is semver-compatible
+with all previous versions since Rust 1.0.
+
+This means that we have to be very careful with additions and changes to the public interface.
+We can deprecate things if necessary,
+but removing items or changing signatures is almost never an option.
+As a result, we are very careful with stabilizing additions to the standard library.
+Once something is stable, we're basically stuck with it forever.
+
+To guard the stability and prevent us from adding things we'll regret later,
+we have a team that specifically focuses on the public API.
+Every RFC and stabilization of a library addition/change goes through a FCP process
+in which the members of the Library API Team are asked to sign off on the change.
+
+The members of this team are not necessarily familiar with the implementation details
+of the standard library, but are experienced with API design and understand the details
+of breaking changes and how they are avoided.
+
+## The Library Contributors
+
+In addition to the two teams above, we also have a the Library Contributors,
+which is a somewhat more loosely defined team consisting of those who regularly contribute
+or review changes to the standard libraries.
+
+Many of these contributors have a specific area of expertise,
+for example certain data structures or a specific operating system.
+
+## Team Membership
+
+The Library Team will privately discuss potential new members for itself and Library Contributors,
+and extend an invitation after all members and the moderation team is on board with the potential addition.
+
+See [Membership](./membership.md) for details.
+
+### r+ permission
+
+All members of the Library Team, the Library API Team, and the Library Contributors
+have the permission to approve PRs, and are expected handle this with care.
+See [Reviewing](./reviewing.md) for details.
+
+### high-five rotation
+
+Some of the members of the team are part of the 'high-five rotation';
+the list from which the high-five bot picks reviewers to assign new PRs to.
+
+Being a member of one of the teams does not come with the expectation to be on this list.
+However, members of this list should be on at least one of the three library teams.
+See [Reviewing](./reviewing.md) for details.