diff --git a/doc/source/contributor/contribute.rst b/doc/source/contributor/contribute.rst
index 36b39a9c22d..72460bd6432 100644
--- a/doc/source/contributor/contribute.rst
+++ b/doc/source/contributor/contribute.rst
@@ -194,7 +194,7 @@ set. Feel free to reach out to the VMT in public or in private.
 
 Also, the VMT is an autonomous subgroup of the much larger `OpenStack Security
 project-team
-<http://governance.openstack.org/reference/projects/security.html>`_. They're a
+<https://governance.openstack.org/tc/reference/projects/security.html>`_. They're a
 knowledgeable bunch and quite responsive if you want to get their opinions or
 help with security-related issues (vulnerabilities or otherwise).
 
diff --git a/doc/source/contributor/effective_neutron.rst b/doc/source/contributor/effective_neutron.rst
index bc850a5b8ce..31dfbd849af 100644
--- a/doc/source/contributor/effective_neutron.rst
+++ b/doc/source/contributor/effective_neutron.rst
@@ -325,7 +325,7 @@ deprecation. Config items have `deprecation options supported by oslo.config
 <https://docs.openstack.org/oslo.config/latest/reference/opts.html>`_.
 
 The deprecation process must follow the `standard deprecation requirements
-<http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html#requirements>`_.
+<https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html#requirements>`_.
 In terms of neutron development, this means:
 
 * A launchpad bug to track the deprecation.
diff --git a/doc/source/contributor/internals/upgrade.rst b/doc/source/contributor/internals/upgrade.rst
index 9c0d7c4cb0b..5e524a76e8d 100644
--- a/doc/source/contributor/internals/upgrade.rst
+++ b/doc/source/contributor/internals/upgrade.rst
@@ -55,7 +55,7 @@ multiple constraints onto the software.
    (otherwise newer services that require the newer schema would not work).
 
 `More info on rolling upgrades in OpenStack
-<http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html>`_.
+<https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html>`_.
 
 Those requirements are achieved in Neutron by:
 
@@ -235,7 +235,7 @@ There are several upgrade related gotchas that should be tracked by reviewers.
 
 First things first, a general advice to reviewers: make sure new code does not
 violate requirements set by `global OpenStack deprecation policy
-<http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html>`_.
+<https://governance.openstack.org/tc/reference/tags/assert_follows-standard-deprecation.html>`_.
 
 Now to specifics:
 
diff --git a/doc/source/contributor/policies/bugs.rst b/doc/source/contributor/policies/bugs.rst
index 35e28fab255..1e2e351acd7 100644
--- a/doc/source/contributor/policies/bugs.rst
+++ b/doc/source/contributor/policies/bugs.rst
@@ -134,7 +134,7 @@ However, you should add Neutron (Or any other project) to that list only if you
 expect that a patch is needed to that repo in order to solve the bug.
 
 It's also worth adding that some of these projects are part of the so
-called Neutron `stadium <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
+called Neutron `stadium <https://governance.openstack.org/tc/reference/projects/neutron.html#deliverables-and-tags>`_.
 Because of that, their release is managed centrally by the Neutron
 release team; requests for releases need to be funnelled and screened
 properly before they can happen. Release request process is described
diff --git a/doc/source/contributor/policies/neutron-teams.rst b/doc/source/contributor/policies/neutron-teams.rst
index bdbe01e4a03..f9ae087c32e 100644
--- a/doc/source/contributor/policies/neutron-teams.rst
+++ b/doc/source/contributor/policies/neutron-teams.rst
@@ -182,7 +182,7 @@ separate repositories with their own core reviewer teams. For each one of
 these repositories in the following repository list, there is a core team
 associated with it:
 
-* `Neutron project team <http://governance.openstack.org/reference/projects/neutron.html>`_
+* `Neutron project team <https://governance.openstack.org/tc/reference/projects/neutron.html>`_
 
 These teams are also responsible for handling their own specs/RFEs/features if
 they choose to use them.  However, by choosing to be a part of the Neutron
diff --git a/doc/source/contributor/stadium/governance.rst b/doc/source/contributor/stadium/governance.rst
index 1584c08021b..da363297b4f 100644
--- a/doc/source/contributor/stadium/governance.rst
+++ b/doc/source/contributor/stadium/governance.rst
@@ -62,7 +62,7 @@ the Neutron umbrella is counterproductive.
 
 These challenges led the Neutron team to find a better balance between autonomy
 and consistency and lay down criteria that more clearly identify when a project
-can be eligible for inclusion in the `Neutron governance <http://governance.openstack.org/reference/projects/neutron.html>`_.
+can be eligible for inclusion in the `Neutron governance <https://governance.openstack.org/tc/reference/projects/neutron.html>`_.
 
 This document describes these criteria, and document the steps involved to
 maintain the integrity of the Stadium, and how to ensure this integrity be
@@ -108,12 +108,12 @@ mature OpenStack projects:
   information on how to do testing, please refer to the
   :doc:`Neutron testing documentation </contributor/testing/testing>`.
 
-* Good release footprint, according to the chosen `release model <http://governance.openstack.org/reference/tags/#release-management-tags>`_.
+* Good release footprint, according to the chosen `release model <https://governance.openstack.org/tc/reference/tags/#release-management-tags>`_.
 
-* Adherence to deprecation and `stable backports policies <http://governance.openstack.org/reference/tags/#stable-maintenance-tags>`_.
+* Adherence to deprecation and `stable backports policies <https://governance.openstack.org/tc/reference/tags/#stable-maintenance-tags>`_.
 
-* Demonstrated ability to do `upgrades <http://governance.openstack.org/reference/tags/assert_supports-upgrade.html>`_
-  and/or `rolling upgrades <http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html>`_,
+* Demonstrated ability to do `upgrades <https://governance.openstack.org/tc/reference/tags/assert_supports-upgrade.html>`_
+  and/or `rolling upgrades <https://governance.openstack.org/tc/reference/tags/assert_supports-rolling-upgrade.html>`_,
   where applicable. This means having grenade support on top of the CI
   coverage as described above.
 
@@ -267,7 +267,7 @@ Checklist
   Once, everything is set up and your project is released, make sure
   you see an entry on the release page (e.g. `Pike <http://releases.openstack.org/pike/index.html#other-projects>`_.
   Make sure you release according to the project declared release
-  `model <http://governance.openstack.org/reference/projects/neutron.html#deliverables-and-tags>`_.
+  `model <https://governance.openstack.org/tc/reference/projects/neutron.html#deliverables-and-tags>`_.
 
 * How to port OpenStack Client over to python-neutronclient: client
   API bindings and client command line interface support must be
diff --git a/doc/source/contributor/stadium/index.rst b/doc/source/contributor/stadium/index.rst
index 43109ed8257..879511c6dbf 100644
--- a/doc/source/contributor/stadium/index.rst
+++ b/doc/source/contributor/stadium/index.rst
@@ -18,7 +18,7 @@ Neutron Stadium
 
 This section contains information on policies and procedures for the so called
 Neutron Stadium. The Neutron Stadium is the list of projects that show up in the
-OpenStack `Governance Document <http://governance.openstack.org/reference/projects/neutron.html>`_.
+OpenStack `Governance Document <https://governance.openstack.org/tc/reference/projects/neutron.html>`_.
 
 The list includes projects that the Neutron PTL and core team are directly
 involved in, and manage on a day to day basis. To do so, the PTL and team