Small improvements and clarifications

Author: GuillaumeGomez

src/rustdoc/index.md

@@ -7,7 +7,7 @@ read about how the compiler and rustdoc work and instructions on how to set up a
 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?*
+  - *How do I subscribe to the rustdoc team's calendar?*
 - [Meetings](./meetings.md)
   - *What meetings do the rustdoc team run and how can I attend?*
 - [Membership](./membership.md)

src/rustdoc/meetings.md

@@ -1,8 +1,7 @@
 # Meetings
 
-The rustdoc team hosts a meeting every second Monday on each month on the 
-[t-rustdoc/meetings channel on zulip](https://rust-lang.zulipchat.com/#narrow/channel/393423-t-rustdoc.2Fmeetings)
-at 21:00 CET (UTC+1) and CEST on summer (UTC+2).
+You can check when the rustdoc team meetings are
+[here](https://github.com/rust-lang/calendar/blob/main/rustdoc.toml).
 
 A new thread is open a month ahead of time to remind people who want to attend about the time
 and the agenda.

src/rustdoc/membership.md

@@ -46,7 +46,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 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].
 

src/rustdoc/proposals-and-stabilization.md

@@ -29,20 +29,23 @@ the nature of the proposal, described below.
     proposal mechanism, reserved for significant changes.
   - RFC proposals can only be approved by *FCPs*.
 - Pull Request (PR)
-  - PRs are pull requests to the [`rust-lang/rust`][rust] repository and are a light-weight
-    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).
+  - Opening a pull request on the [`rust-lang/rust`][rust] repository is a lightweight
+    mechanism suitable for most proposals. This is preferred in cases such as stabilization
+    of a rustdoc flag or addition of a new target.
   - PR proposals can be approved by *FCPs* or *r+*. See *When are FCPs/RFCs required?*
     section below when *r+* isn't sufficient alone.
+- Issues
+  - Opening an issue on the [`rust-lang/rust`][rust] repository are also a good starting
+    point if you don't know which of the previous ways is the best fit.
 
 [rustdoc zulip thread]: https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc
 
 ### When are FCPs/RFCs required?
 
-An FCP will be needed for any stabilization of small user-facing changes, like UI/UX changes, new
-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.
+An FCP will be needed for any stabilization of small user-facing changes, like UI/UX changes in
+the GUI web interface, new 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 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.