diff --git a/HACKING.rst b/HACKING.rst
index eafa81b..1db1e26 100644
--- a/HACKING.rst
+++ b/HACKING.rst
@@ -1,3 +1,7 @@
+Tempest Coding Guide
+====================
+
+
 Test Data/Configuration
 -----------------------
 - Assume nothing about existing test data
diff --git a/doc/source/HACKING.rst b/doc/source/HACKING.rst
new file mode 120000
index 0000000..a2f06b7
--- /dev/null
+++ b/doc/source/HACKING.rst
@@ -0,0 +1 @@
+../../HACKING.rst
\ No newline at end of file
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 1ca7344..e8fdf2c 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -3,9 +3,9 @@
    You can adapt this file completely to your liking, but it should at least
    contain the root `toctree` directive.
 
-===================================
+=======================
 Tempest Testing Project
-===================================
+=======================
 
 Contents:
 
@@ -13,11 +13,11 @@
    :maxdepth: 2
 
    overview
+   HACKING
 
-
--------------------------------
+------------
 Field Guides
--------------------------------
+------------
 Tempest contains tests of many different types, the field guides
 attempt to explain these in a way that makes it easy to understand
 where your test contributions should go.
diff --git a/tempest/api/README.rst b/tempest/api/README.rst
index cf0aac7..617fda4 100644
--- a/tempest/api/README.rst
+++ b/tempest/api/README.rst
@@ -1,9 +1,9 @@
 Tempest Guide to API tests
-========
+==========================
 
 
 What are these tests?
---------
+---------------------
 
 One of Tempest's prime function is to ensure that your OpenStack cloud
 works with the OpenStack API as documented. The current largest
@@ -21,7 +21,7 @@
 
 
 Why are these tests in tempest?
---------
+-------------------------------
 
 This is one of the core missions for the Tempest project, and where it
 started. Many people use this bit of function in Tempest to ensure
@@ -34,7 +34,7 @@
 
 
 Scope of these tests
---------
+--------------------
 
 API tests should always use the Tempest implementation of the
 OpenStack API, as we want to ensure that bugs aren't hidden by the
diff --git a/tempest/cli/README.rst b/tempest/cli/README.rst
index 4742d4a..76b05a3 100644
--- a/tempest/cli/README.rst
+++ b/tempest/cli/README.rst
@@ -1,16 +1,16 @@
 Tempest Guide to CLI tests
-========
+==========================
 
 
 What are these tests?
----------
+---------------------
 The cli tests test the various OpenStack command line interface tools
 to ensure that they minimally function. The current scope is read only
 operations on a cloud that are hard to test via unit tests.
 
 
 Why are these tests in tempest?
----------
+-------------------------------
 These tests exist here because it is extremely difficult to build a
 functional enough environment in the python-*client unit tests to
 provide this kind of testing. Because we already put up a cloud in the
@@ -20,14 +20,14 @@
 
 
 Scope of these tests
----------
+--------------------
 This should stay limited to the scope of testing the cli. Functional
 testing of the cloud should be elsewhere, this is about exercising the
 cli code.
 
 
 Example of a good test
----------
+----------------------
 Tests should be isolated to a single command in one of the python
 clients.
 
diff --git a/tempest/scenario/README.rst b/tempest/scenario/README.rst
index c5fa0d3..98b74e4 100644
--- a/tempest/scenario/README.rst
+++ b/tempest/scenario/README.rst
@@ -1,9 +1,9 @@
 Tempest Guide to Scenario tests
-========
+===============================
 
 
 What are these tests?
---------
+---------------------
 
 Scenario tests are "through path" tests of OpenStack
 function. Complicated setups where one part might depend on completion
@@ -17,13 +17,13 @@
 
 
 Why are these tests in tempest?
---------
+-------------------------------
 This is one of tempests core purposes, testing the integration between
 projects.
 
 
 Scope of these tests
---------
+--------------------
 Scenario tests should always test at least 2 services in
 interaction. They should use the official python client libraries for
 OpenStack, as they provide a more realistic approach in how people
@@ -34,7 +34,7 @@
 
 
 Example of a good test
---------
+----------------------
 While we are looking for interaction of 2 or more services, be
 specific in your interactions. A giant "this is my data center" smoke
 test is hard to debug when it goes wrong.
diff --git a/tempest/stress/README.rst b/tempest/stress/README.rst
index 2fcdf2e..661763c 100644
--- a/tempest/stress/README.rst
+++ b/tempest/stress/README.rst
@@ -1,5 +1,5 @@
 Tempest Field Guide to Stress Tests
-======================================================
+===================================
 
 Nova is a distributed, asynchronous system that is prone to race condition
 bugs. These bugs will not be easily found during
@@ -9,7 +9,7 @@
 
 
 Environment
-------------
+-----------
 This particular framework assumes your working Nova cluster understands Nova
 API 2.0. The stress tests can read the logs from the cluster. To enable this
 you have to provide the hostname to call 'nova-manage' and
diff --git a/tempest/whitebox/README.rst b/tempest/whitebox/README.rst
index dabf758..0e45421 100644
--- a/tempest/whitebox/README.rst
+++ b/tempest/whitebox/README.rst
@@ -1,9 +1,9 @@
 Tempest Guide to Whitebox tests
-========
+===============================
 
 
 What are these tests?
---------
+---------------------
 
 When you hit the OpenStack API, this causes internal state changes in
 the system. This might be database transitions, vm modifications,
@@ -20,7 +20,7 @@
 
 
 Why are these tests in tempest?
---------
+-------------------------------
 
 Especially when it comes to something like VM state changing, which is
 a coordination of numerous running daemons, and a functioning VM, it's
@@ -28,7 +28,7 @@
 
 
 Scope of these tests
---------
+--------------------
 
 White box tests should be limitted to tests where black box testing
 (using the OpenStack API to verify results) isn't sufficient.
@@ -40,7 +40,7 @@
 
 
 Example of a good test
---------
+----------------------
 
 Pushing VMs through a series of state transitions, and ensuring along
 the way the database state transitions match what's expected.