Merge pull request #156 from alice-i-cecile/dead-links

Fix dead links

Author: nikomatsakis

design-meeting-minutes/2021-02-24-Lints-and-editions.md

@@ -2,7 +2,7 @@
 
 We have a lang-team calendar that shows the time for our various meetings.
 Meetings are generally open to anyone who wants to listen in. We also try to
-post [minutes](./minutes.md) (and recordings, if any) on a "best-effort" basis from our
+post [minutes](https://github.com/rust-lang/lang-team/tree/master/minutes) (and recordings, if any) on a "best-effort" basis from our
 meetings.
 
 - [View calendar][caldav] -- use this to view the calendar online and add it to your Google Calendar

src/calendar.md

@@ -128,7 +128,7 @@ fn main() {
 
 However, this will fail to compile with the following error:
 
-> error[E0277]: the trait bound `fn() {my_callback}: Default` is not satisfied
+> error\[E0277\]: the trait bound `fn() {my_callback}: Default` is not satisfied
 
 ## Implementing the `Default` trait
 

src/design_notes/fn_type_trait_impls.md

@@ -5,16 +5,16 @@ Typically initiatives are changes to the language, but they could also be docume
 
 ## [Active initiatives][pb]
 
-Active initiatives are initiatives that have been assigned a lang-team [liaison] and which are actively underway. A complete list can be found in [this GitHub project board][pb]. Note that this list doesn't represent all unstable features; older features in particular were added without active initiatives.
+Active initiatives are initiatives that have been assigned a lang-team [Liaison] and which are actively underway. A complete list can be found in [this GitHub project board][pb]. Note that this list doesn't represent all unstable features; older features in particular were added without active initiatives.
 
 Each initiative on the project board is linked to a tracking issue and has a status:
 
-* The [owner] and [liaison] are assigned to the issue.
+* The [Owner] and [Liaison] are assigned to the issue.
 * If the initiative has a dedicated repository, the issue is created on that repository (some initiatives don't require their own repos; they are found on rust-lang/rust or rust-lang/lang-team).
-* The [stage] of the initiative:
+* The [Stage] of the initiative:
     * [Experimental] -- Drafting RFC; implementation work may begin on nightly as well
     * [Development] -- Approved RFC; implementation is in progress on nightly
-    * [Feature complete] -- Implementation is complete on nightly and ready for widespread testing
+    * [Feature complete][fc] -- Implementation is complete on nightly and ready for widespread testing
     * [Stabilized] -- Implementation is complete and available on stable
         * To be stabilized, there must be a pending PR adding the feature to the Rust reference, but this PR may not yet have landed.
         * Other forms of integration, such as rustfmt, often take place after stabilization as well.
@@ -31,10 +31,10 @@ It's easy! You just open a short issue describing your idea. Read more in the [p
 
 [pb]: https://github.com/orgs/rust-lang/projects/16/
 [proposal]: ./initiatives/process/stages/proposal.md
-[experimental]: ./initiatives/process/stages/experimental.md
-[development]: ./initiatives/process/stages/development.md
-[feature complete]: ./initiatives/process/stages/feature_complete.md
-[stabilized]: ./initiatives/process/stages/stabilized.md
-[Stage]: ./initiaives/process/stages.md
-[Owner]: ./initiaives/roles/owner.md
-[Liaison]: ./initiaives/roles/liaison.md
+[Experimental]: ./initiatives/process/stages/experimental.md
+[Development]: ./initiatives/process/stages/development.md
+[fc]: ./initiatives/process/stages/feature_complete.md
+[Stabilized]: ./initiatives/process/stages/stabilized.md
+[Stage]: ./initiatives/process/stages.md
+[Owner]: ./initiatives/process/roles/owner.md
+[Liaison]: ./initiatives/process/roles/owner.md

src/initiatives.md

@@ -47,11 +47,11 @@ Once a proposal has been seconded and the FCP has expired:
 ## 
 
 [pb]: https://github.com/orgs/rust-lang/projects/16/
-[proposal]: ./initiatives/process/stages/proposal.md
-[experimental]: ./initiatives/process/stages/experimental.md
-[development]: ./initiatives/process/stages/development.md
-[feature complete]: ./initiatives/process/stages/feature_complete.md
-[stabilized]: ./initiatives/process/stages/stabilized.md
-[Stage]: ./initiaives/process/stages.md
-[Owner]: ./initiaives/roles/owner.md
-[Liaison]: ./initiaives/roles/liaison.md
+[proposal]: ./stages/proposal.md
+[experimental]: ./stages/experimental.md
+[development]: ./stages/development.md
+[feature complete]: ./stages/feature_complete.md
+[stabilized]: ./stages/stabilized.md
+[Stage]: ./stages.md
+[Owner]: ./roles/owner.md
+[Liaison]: ./roles/liaison.md

src/initiatives/process/checklists.md

@@ -10,9 +10,6 @@ Presuming that an initiative continues successfully, it will go through the foll
 | [Feature complete]                    | Gathering feedback                        | Advertisting the initiative as "feature complete"                                             | Stabilization proposal approved                           |
 | [Stabilized]                          |                                           | Use on stable branch                                                                          | (none)                                                    |
 
-[liaison]: ../roles/liaison.md
-[owner]: ../roles/owner.md
-
 The "experimental" stage can be skipped if the initiative is sufficiently simple that a RFC doesn't seem necessary; see ["simple initiatives"](#simple-initiatives) below.
 
 Initiatives can also become [inactive] for a variety of reasons.
@@ -23,13 +20,14 @@ Initiatives can also become [inactive] for a variety of reasons.
 [feature complete]: ./stages/feature_complete.md
 [stabilized]: ./stages/stabilized.md
 [inactive]: ./stages/inactive.md
+[liaison]: ./roles/liaison.md
 
 ## Simple initiatives
 
 The above process is the ideal, but there are alternative routes that occur in practice for simple initiatives. The most common is one that begins with a PR:
 
 - Implement the idea and open a PR.
-- [Nominate](/how_to/nominate.md) the PR to the lang team's attention.
+- [Nominate](../../how_to/nominate.md) the PR to the lang team's attention.
 - The lang team may opt to either approve the PR (skip directly to "feature complete"), assign an owner (skip directly to "development"), or to request a proposal.
 
 ## Umbrella initiatives

src/initiatives/process/stages.md

@@ -18,7 +18,7 @@ In addition, it's a good place to explain how any "unresolved questions" from th
 
 In addition to evaluating the feature, this is a good period to prepare "reference" documentation that explains the changes in depth. This is typically included in the [Rust reference] but may appear in other documentation as well, such as the Necronomicon. These changes will be reviewed as part of the stabilization report and will land after the feature is stabilized.
 
-[Rust reference]:
+[Rust reference]: https://doc.rust-lang.org/reference/
 
 ## Exit: Stabilization report prepared and approved
 

src/initiatives/process/stages/feature_complete.md

@@ -1,5 +1,3 @@
 # Inactive groups
 
-As an alternative to stabilization, initiatives may become _inactive_. This could be because we decided the idea doesn't work, but it could also be that people just no longer had time to work on it and so the idea was paused until somebody else shows up with time and energy. When marking an initiative as inactive, we try to do a final retrospective that judges how well the experience went. We also try to prepare a summary of the final state in case someone wants to start working on the design again (or perhaps a small piece of it; a common failing for initiatives is trying to tackle too big of a problem). These technical summaries can be placed in the [design notes] section of this website.
-
-[design notes]: /design_notes.md
+As an alternative to stabilization, initiatives may become _inactive_. This could be because we decided the idea doesn't work, but it could also be that people just no longer had time to work on it and so the idea was paused until somebody else shows up with time and energy. When marking an initiative as inactive, we try to do a final retrospective that judges how well the experience went. We also try to prepare a summary of the final state in case someone wants to start working on the design again (or perhaps a small piece of it; a common failing for initiatives is trying to tackle too big of a problem). These technical summaries can be placed in the [design notes](../../../design_notes.md) section of this website.

src/initiatives/process/stages/inactive.md

@@ -1,5 +1,5 @@
 # Stage 5: Stabilized
 
-This is the final stage. The development is done and support transitions to the regular team members. The initiative is now considered [inactive]. However, the stream often sticks around as a convenient place to ping the people who were involved in implementing the feature for follow-up questions and for fixing bugs or other maintenance. The expectation is that if you helped to develop a feature, you will stay involved for some period of time after it hits stable to help in resolving problems that arise.
+This is the final stage. The development is done and support transitions to the regular team members. The initiative is now considered [inactive](inactive.md). However, the stream often sticks around as a convenient place to ping the people who were involved in implementing the feature for follow-up questions and for fixing bugs or other maintenance. The expectation is that if you helped to develop a feature, you will stay involved for some period of time after it hits stable to help in resolving problems that arise.
 
 After stabilization, the owner and liaison should meet to do a final retrospective on how everything went and what could have been improved. This should be done within a few weeks of stabilization, while the memories are fresh.

src/initiatives/process/stages/stabilized.md

@@ -7,7 +7,7 @@ This table lists past initiatives which were stabilized.
 | [Disjoint closure capture]    | ✅           | [▰▰▰▰▰] | nikomatsakis    |           |
 
 [Disjoint closure capture]: https://github.com/rust-lang/project-rfc-2229/
-[▰▰▰▰▰]: ./initiatives/process/stages/stabilized.md
-[Stage]: ./initiaives/process/stages.md
-[Owner]: ./initiaives/roles/owner.md
-[Liaison]: ./initiaives/roles/liaison.md
+[▰▰▰▰▰]: ./process/stages/stabilized.md
+[Stage]: ./process/stages.md
+[Owner]: ./process/roles/owner.md
+[Liaison]: ./process/roles/liaison.md