diff --git a/doc/source/specs/template.rst b/doc/source/specs/COPYME
similarity index 100%
rename from doc/source/specs/template.rst
rename to doc/source/specs/COPYME
diff --git a/doc/source/specs/index.rst b/doc/source/specs/index.rst
index 6362f98221..97f4ec6990 100644
--- a/doc/source/specs/index.rst
+++ b/doc/source/specs/index.rst
@@ -1,19 +1,40 @@
-Specifications
-==============
+Project Specifications
+======================
 
-Contents:
+Specifications in this repository represent a consensus on the topics covered
+within.  They should be considered a mandate on the path forward with regards
+to the content on which they are drafted.
+
+Here is a list of the current specs:
 
 .. toctree::
    :maxdepth: 1
+   :glob:
 
-   developer-environment.rst
-   osh-lma-stack.rst
-   specifications.rst
-   template.rst
-   neutron-multiple-sdns.rst
-   nginx-sidecar.rst
-   support-linux-bridge-on-neutron.rst
-   fluentbit-fluentd-architecture.rst
-   osh-1.0-requirements.rst
-   values-ordering.rst
-   tenant-ceph.rst
+   *
+
+Specifications Purpose
+----------------------
+
+A specification should precede any broad-reaching technical changes or proposals
+to OpenStack-Helm.  Examples of changes requiring a specification include:  a
+standard format to the values.yaml files, multiple backend support for neutron,
+and the approach for logging and monitoring in OpenStack-Helm.  Some additional
+features will not need an accompanying specification, but may be tied back to an
+existing specification.  An example of this would be introducing a service in
+OpenStack-Helm that could be included under the scope of a specification already
+drafted and approved.
+
+Specifications Process
+----------------------
+
+Before drafting a specification, a blueprint should be filed in Storyboard_
+along with any dependencies the blueprint requires.  Once the blueprint has been
+registered, submit the specification as a patch set to the specs/ directory
+using the supplied template.
+
+More information about the blueprint + specification lifecycle can be found
+here_.
+
+.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
+.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs
diff --git a/doc/source/specs/specifications.rst b/doc/source/specs/specifications.rst
deleted file mode 100644
index 12aa93da56..0000000000
--- a/doc/source/specs/specifications.rst
+++ /dev/null
@@ -1,33 +0,0 @@
-=====================
-Project Specfications
-=====================
-
-Specifications in this repository represent a consensus on the topics covered
-within.  They should be considered a mandate on the path forward with regards
-to the content on which they are drafted.
-
-Purpose
--------
-
-A specification should precede any broad-reaching technical changes or proposals
-to OpenStack-Helm.  Examples of changes requiring a specification include:  a
-standard format to the values.yaml files, multiple backend support for neutron,
-and the approach for logging and monitoring in OpenStack-Helm.  Some additional
-features will not need an accompanying specification, but may be tied back to an
-existing specification.  An example of this would be introducing a service in
-OpenStack-Helm that could be included under the scope of a specification already
-drafted and approved.
-
-Process
--------
-
-Before drafting a specification, a blueprint should be filed in Storyboard_
-along with any dependencies the blueprint requires.  Once the blueprint has been
-registered, submit the specification as a patch set to the specs/ directory
-using the supplied template.
-
-More information about the blueprint + specification lifecycle can be found
-here_.
-
-.. _Storyboard: https://storyboard.openstack.org/#!/project_group/64
-.. _here: https://wiki.openstack.org/wiki/Blueprints#Blueprints_and_Specs