Clarify rustdoc team roles

Add more information about review policy
Fix typos and links

Author: GuillaumeGomez

src/rustdoc/README.md

@@ -4,7 +4,7 @@ and considering the stabilization of rustdoc features.
 
 We use the Forge to document the team's processes, policies and working practices, if you'd like to
 read about how the compiler and rustdoc work and instructions on how to set up a development environment,
-you're looking for the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/).
+you're looking for the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/rustdoc.html).
 
 - [Calendar](./calendar.md)
   - *How do I subscribe to the compiler team's calendar?*

src/rustdoc/membership.md

@@ -45,6 +45,7 @@ Being promoted to member implies a number of privileges:
 
 It also implies some obligations (in some cases, optional obligations):
 
+- Members are expected to respond to FCPs in maximum 4 weeks (28 days).
 - Members may take part in various other [maintainer activities] to help the team.
 - Members are held to a higher standard than ordinary folk when it comes to the [Code of
   Conduct][CoC].
@@ -71,15 +72,17 @@ we have three main areas:
 - Internals: The internals of rustdoc: interacting with the compiler, doctests, generating
   rustdoc internal code representation, parsing command line arguments, lints, etc.
 
-These groups are NOT full-fledge teams, and as such, to be part of any of these groups, you need to
+These groups are NOT full-fledged teams, and as such, to be part of any of these groups, you need to
 be a member of the rustdoc team.
 
 For now, only the front-end group has an official status in the
 [team repository](https://github.com/rust-lang/team) and is called `rustdoc-frontend`. If a rustdoc
 team member is interested to be part of this group, they can ask to be added into it.
 
-Being part of the front-end group doesn't change your rustdoc team membership. However
-you will be assigned for reviews on front-end pull requests and on front-end FCPs.
+Let's take the front-end group as an example. It is a part of the rustdoc team, so you need to be a
+member of the rustdoc team to be able to join this group. Being part of the front-end group means
+you are encouraged to be part of the review rotations for front-end pull requests and you will need
+to respond on front-end FCPs.
 
 ## How promotion decisions are made
 [hdam]: #how-promotion-decisions-are-made

src/rustdoc/proposals-and-stabilization.md

@@ -9,11 +9,11 @@ There are two mechanisms that the team can use to approve a proposal (not all ap
 are suitable for each method of making a proposal - see below):
 
 - r+
-  - A proposal is r+'d when it is approved to be merged.
+  - A proposal (an RFC or an FCP) is r+'d when it is approved to be merged.
   - r+ can only be used to approve a PR.
 - FCP
-  - A final comment period will require sign-off from a majority of the rustdoc team to approve
-    a proposal and then a ten day waiting period.
+  - A final comment period will require sign-off from a majority (all members minus 2)
+    of the rustdoc team to approve a proposal and then a ten day waiting period.
   - FCPs can be used to approve any form of proposal.
 
 ## Proposals
@@ -33,7 +33,8 @@ the nature of the proposal, described below.
     proposal mechanism, suitable for most proposals. PRs are preferred when the proposal is
     accompanied by a small patchset (such as stabilization of a compiler flag or addition of
     a new target).
-  - PR proposals can be approved by *FCPs* or *r+*.
+  - PR proposals can be approved by *FCPs* or *r+*. See *When are FCPs/RFCs required?*
+    section below when *r+* isn't sufficient alone.
 
 [rustdoc zulip thread]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc
 
@@ -43,8 +44,8 @@ An FCP will be needed for any stabilization of small user-facing changes, like U
 command-line arguments, new attributes, etc. However, if the change is considered too big/important,
 an RFC will need to be written and approved before the change will be accepted.
 
-When opening an FCP, make sure only the relevant subteam is labeled on the issue, to avoid pinging
-people with changes they aren't interested in.
+When starting an FCP, make sure only the relevant subteam is labeled on the issue/PR, to avoid
+pinging people with changes they aren't interested in.
 
 ### What happens if someone makes a contribution that requires an approval and doesn't have one?
 If the approval required for the contribution requires an RFC, then the contribution
@@ -69,10 +70,6 @@ A good proposal will address the following:
 * **Alternatives, concerns, and key decisions:** Were there any alternatives considered? If so, why
   did you pick this design?
 
-## What proposal/approval do I need?
-This section aims to exhaustively detail which proposal and approval is necessary for any given
-circumstance.
-
 [rfcs]: https://github.com/rust-lang/rfcs
 [Haddock]: https://haskell-haddock.readthedocs.io/latest/
 [Wikipedia]: https://www.wikipedia.org/

src/rustdoc/resources.md

@@ -11,6 +11,6 @@ There are various resources which are useful to contributors and team members.
 If there are additional resources which would be useful to a contributor or compiler team member,
 feel free to submit a PR to add it here.
 
-[dev_guide]: https://rustc-dev-guide.rust-lang.org/ 
+[dev_guide]: https://rustc-dev-guide.rust-lang.org/rustdoc.html
 [rustc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/index.html
 [rustdoc]: https://doc.rust-lang.org/nightly/nightly-rustc/rustdoc/index.html

src/rustdoc/reviews.md

@@ -2,3 +2,10 @@
 
 The rustdoc team follows the same review policy as the compiler team. Take a look at
 [their chapter](../compiler/reviews.md) about it.
+
+In addition, it's important to note that:
+ * Anyone is welcome to provide their input as code review, even if you aren't a member of the
+   rustdoc team.
+ * Only team members can approve pull requests for being merged.
+ * New features are usually subject to more in depth review and might need to go through an RFC or
+   an FCP.