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

@@ -69,10 +69,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.