diff --git a/contributors/design-proposals/release/versioning.md b/contributors/design-proposals/release/versioning.md
index 05e7faed7..da7f1bbb7 100644
--- a/contributors/design-proposals/release/versioning.md
+++ b/contributors/design-proposals/release/versioning.md
@@ -70,7 +70,7 @@ especially for production-critical components.
 
 We expect users to be running approximately the latest patch release of a given
 minor release; we often include critical bug fixes in
-[patch releases](#patch-release), and so encourage users to upgrade as soon as
+[patch releases](#patch-releases), and so encourage users to upgrade as soon as
 possible.
 
 Different components are expected to be compatible across different amounts of
@@ -114,7 +114,7 @@ version changes, not new major nor minor versions).
 rolling upgrade across their cluster. (Rolling upgrade means being able to
 upgrade the master first, then one node at a time. See [#4855](https://issues.k8s.io/4855) for details.)
   * However, we do not recommend upgrading more than two minor releases at a
-time (see [Supported releases](#supported-releases)), and do not recommend
+time (see [Supported releases and component skew](#Supported-releases-and-component-skew)), and do not recommend
 running non-latest patch releases of a given minor release.
 * No hard breaking changes over version boundaries.
   * For example, if a user is at Kube 1.x, we may require them to upgrade to