Add priority efforts section

Add a section listing priority efforts.  Ensure that there is
exactly one spec listed for each priority effort.  Add stub specs
for efforts which predate the spec process.  Also, publish the
Gerrit search string to see all priority effort changes.

Remove the implemented/ directory so that spec URLs are stable
over time.  We have been linking to them very liberally, so let's
not codify workflow in URLs.

Remove the :glob: options so that specs now need to be listed
individually in the sections in which they should appear.  This
means that spec workflow involves changing the index page rather
than moving files (and URLs).

Change-Id: Ic7f088b7456d66f5ff164dea8504e1c5467bf79d

README.rst

@@ -7,41 +7,26 @@ the OpenStack Project Infrastructure.  This provides an ability to
 ensure that everyone has signed off on the approach to solving a
 problem early on.
 
-Repository Structure
-====================
-The expected structure of the respository is as follows::
-
-  specs/
-      implemented/
-
-
 Expected Work Flow
 ==================
 
 1. Create a story in StoryBoard with a task affecting the
    ``infra-specs`` project.
-2. Propose review to infra-specs repository (ensure Story:<story number> is
-   in the commit message).
-3. Leave a comment with the Gerrit address of the specification.
-4. Bring forward the proposed item to the infra meeting for summary.
-5. Review happens on proposal by infra-core members and others.
-6. Iterate until review is Approved or Rejected.
+2. Propose a change to infra-specs repository (ensure Story:<story
+   number> is in the commit message).
+3. Leave a comment with the Gerrit URL of the specification.
+4. Review happens on proposal by infra-core members and others.
+5. When ready for final approval, bring forward the proposed item to
+   the infra meeting.
 
-Once a specification is Approved...
+Once a specification is approved...
 
 1. Update story, copy summary text of specification to there.
 2. Leave a comment to the git address of the specification.
 
-
 Revisiting Specifications
 =========================
 We don't always get everything right the first time. If we realize we
 need to revisit a specification because something changed, either we
 now know more, or a new idea came in which we should embrace, we'll
 manage this by proposing an update to the specification in question.
-
-Learn As We Go
-==============
-This is a new way of attempting things, so we're going to be low in
-process to begin with to figure out where we go from here. Expect some
-early flexibility in evolving this effort over time.

doc/source/index.rst

@@ -1,21 +1,63 @@
-Infrastructure Design Specifications
-====================================
+========================================================
+ OpenStack Project Infrastructure Design Specifications
+========================================================
+
+Priority Efforts
+================
+
+These are the efforts we focus our review attention on first.  They
+are a great way to get involved collaboratively with other
+infrastructure developers.
+
+.. toctree::
+   :maxdepth: 1
+
+   specs/logs-in-swift
+   specs/dib-nodepool
+   specs/openstackci
+   specs/migrate_to_zanata
+
+Gerrit query for all changes related to priority efforts::
+
+  status:open AND (topic:enable_swift OR topic:dib-nodepool OR topic:zanata OR topic:downstream-puppet)
+
+https://review.openstack.org/#/q/status:open+AND+%28topic:enable_swift+OR+topic:dib-nodepool+OR+topic:zanata+OR+topic:downstream-puppet%29,n,z
+
+Approved Design Specifications
+==============================
+
+These are specifications that have been approved; work may or may not
+have started on these.  Reviewers will review related changes as time
+permits.
 
 .. toctree::
    :glob:
    :maxdepth: 1
 
-   specs/*
-
+   specs/doc-publishing
+   specs/nodepool-launch-workers
+   specs/nodepool-workers
+   specs/public_hiera
+   specs/storyboard_integration_tests
+   specs/storyboard_story_tags
+   specs/storyboard_subscription_pub_sub
+   specs/storyboard_task_branches
+   specs/zuul_split
 
 Implemented Design Specifications
 =================================
 
+These specifications have already been implemented and are listed here
+for historical purposes.
+
 .. toctree::
-   :glob:
    :maxdepth: 1
 
-   specs/implemented/*
+   specs/config-repo-split
+   specs/migrate_askbot
+   specs/puppet-modules
+   specs/server_base_template_refactor
+   specs/test-metrics-db
 
 
 Specifications Repository Information

specs/dib-nodepool.rst

@@ -0,0 +1,95 @@
+::
+
+  Copyright 2015 Hewlett-Packard Development Company, L.P.
+
+  This work is licensed under a Creative Commons Attribution 3.0
+  Unported License.
+  http://creativecommons.org/licenses/by/3.0/legalcode
+
+=================================
+Use Diskimage Builder in Nodepool
+=================================
+
+To ensure identical test environments in different clouds, use
+Diskimage Builder to create images which are then uploaded to each
+cloud used by Nodepool.
+
+Problem Description
+===================
+
+Each cloud provider in use by Nodepool supplies different images which
+can cause tests to perform differently.
+
+Proposed Change
+===============
+
+Rather than try to correct the delta in each provider, create an image
+locally that can be used in any provider and upload it to Glance.
+
+Because it is difficult to use glance in all of its deployment
+variations, move much of the cloud-interaction logic into the "shade"
+library and use that to perform the uploads.
+
+Alternatives
+------------
+
+Keep playing catch-up whenever clouds update their images.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  mordred
+
+
+Gerrit Topic
+------------
+
+Use Gerrit topic "dib-nodepool" for all patches related to this spec.
+
+.. code-block:: bash
+
+    git-review -t dib-nodepool
+
+Work Items
+----------
+
+N/A
+
+Repositories
+------------
+
+N/A
+
+Servers
+-------
+
+N/A
+
+DNS Entries
+-----------
+
+N/A
+
+Documentation
+-------------
+
+N/A
+
+Security
+--------
+
+N/A
+
+Testing
+-------
+
+N/A
+
+Dependencies
+============
+
+N/A

specs/logs-in-swift.rst

@@ -0,0 +1,94 @@
+::
+
+  Copyright 2015 Hewlett-Packard Development Company, L.P.
+
+  This work is licensed under a Creative Commons Attribution 3.0
+  Unported License.
+  http://creativecommons.org/licenses/by/3.0/legalcode
+
+=========================
+Store Build Logs in Swift
+=========================
+
+Rather than store test build logs in a very large filesystem, store them
+in swift.
+
+Problem Description
+===================
+
+For a while, we have been storing test logs from builds in a very
+large filesystem on static.openstack.org.  It is not large enough to
+store all of the data that we wish, and has already reached the
+maximum capacity that we can allocate to it, and it incurs some system
+administration overhead to maintain.
+
+Proposed Change
+===============
+
+Store log files in Swift instead.  Zuul will provide per-job
+credentials to the workers based on the swift tempurl and formpost
+facilities.
+
+Alternatives
+------------
+
+Put logs in AFS or otherwise scale out the static filesystem solution.
+
+Implementation
+==============
+
+Assignee(s)
+-----------
+
+Primary assignee:
+  jhesketh
+
+
+Gerrit Topic
+------------
+
+Use Gerrit topic "enable_swift" for all patches related to this spec.
+
+.. code-block:: bash
+
+    git-review -t enable_swift
+
+Work Items
+----------
+
+N/A
+
+Repositories
+------------
+
+N/A
+
+Servers
+-------
+
+N/A
+
+DNS Entries
+-----------
+
+N/A
+
+Documentation
+-------------
+
+N/A
+
+Security
+--------
+
+N/A
+
+Testing
+-------
+
+N/A
+
+Dependencies
+============
+
+N/A