diff --git a/src/SUMMARY.md b/src/SUMMARY.md
index 5eac9a12..7c85576f 100644
--- a/src/SUMMARY.md
+++ b/src/SUMMARY.md
@@ -40,7 +40,7 @@
 - [Using Git](./git.md)
 - [Mastering @rustbot](./rustbot.md)
 - [Walkthrough: a typical contribution](./walkthrough.md)
-- [Bug Fix Procedure](./bug-fix-procedure.md)
+- [Procedures for Breaking Changes](./bug-fix-procedure.md)
 - [Implementing new features](./implementing_new_features.md)
 - [Stability attributes](./stability.md)
 - [Stabilizing Features](./stabilization_guide.md)
diff --git a/src/bug-fix-procedure.md b/src/bug-fix-procedure.md
index 2f5e2471..65881c24 100644
--- a/src/bug-fix-procedure.md
+++ b/src/bug-fix-procedure.md
@@ -1,4 +1,4 @@
-# Rustc Bug Fix Procedure
+# Procedures for Breaking Changes
 
 <!-- toc -->
 
@@ -169,6 +169,13 @@ there were no errors before.
 
 #### Crater and crates.io
 
+[Crater] is a bot that will compile all crates.io crates and many
+public github repos with the compiler with your changes. A report will then be
+generated with crates that ceased to compile with or began to compile with your
+changes. Crater runs can take a few days to complete.
+
+[Crater]: https://github.com/rust-lang/crater
+
 We should always do a crater run to assess impact. It is polite and considerate
 to at least notify the authors of affected crates the breaking change. If we can
 submit PRs to fix the problem, so much the better.
diff --git a/src/contributing.md b/src/contributing.md
index 47f91bd1..a96e1e98 100644
--- a/src/contributing.md
+++ b/src/contributing.md
@@ -83,30 +83,9 @@ features.](./implementing_new_features.md)
 
 ### Breaking Changes
 
-As mentioned above, Rust has strong backwards-compatibility guarantees. To this
-end, we are reluctant to make breaking changes. However, sometimes they are
-needed to correct compiler bugs (e.g. code that compiled but should not) or
-make progress on some features.
+Breaking changes have a [dedicated section][breaking-changes] in the dev-guide.
 
-Depending on the scale of the breakage, there are a few different actions that
-can be taken.  If the reviewer believes the breakage is very minimal (i.e. very
-unlikely to be actually encountered by users), they may just merge the change.
-More often, they will request a Final Comment Period (FCP), which calls for
-rough consensus among the members of a relevant team. The team members can
-discuss the issue and either accept, reject, or request changes on the PR.
-
-If the scale of breakage is large, a deprecation warning may be needed. This is
-a warning that the compiler will display to users whose code will break in the
-future. After some time, an FCP can be used to move forward with the actual
-breakage.
-
-If the scale of breakage is unknown, a team member or contributor may request a
-[crater] run. This is a bot that will compile all crates.io crates and many
-public github repos with the compiler with your changes. A report will then be
-generated with crates that ceased to compile with or began to compile with your
-changes. Crater runs can take a few days to complete.
-
-[crater]: https://github.com/rust-lang/crater
+[breaking-changes]: ./bug-fix-procedure.md
 
 ### Major Changes