openstack
/
qa-specs
Code Issues Proposed changes
OpenStack QA Specifications
22 Commits 1 Branch 0 Tags 3.1 MiB
Python 100%
Go to file
Matthew Treinish eda8c84cab Add optional spell checker target 
Add a tox target using sphinxcontrib-spelling to let
authors run a spell checker against documents before
submitting them.

Based on nova-specs change: If519fb63bc4b0923a48df9e0435125fd66ab5c0c

Change-Id: I5b5bb10fada71c14ae1753e72a450e16d0683cb0
 		2014-04-16 14:59:17 -04:00
doc/source Add optional spell checker target 2014-04-16 14:59:17 -04:00
specs Merge "Add spec for bp:config-verification" 2014-04-10 11:48:49 +00:00
tools add basic rst sanity checker 2014-03-18 15:51:46 -04:00
.gitignore Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
.gitreview Added .gitreview 2014-03-14 23:10:06 +00:00
LICENSE Add a license file 2014-03-25 18:27:36 -04:00
README.rst Update process flow 2014-03-17 11:10:25 -04:00
requirements.txt Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
run_tests.sh add basic rst sanity checker 2014-03-18 15:51:46 -04:00
setup.cfg Mirror tox and sphinx fixes from nova-specs repo 2014-04-01 13:13:48 -04:00
setup.py Add sphinx support to qa-specs repo 2014-03-24 13:36:43 -04:00
template.rst Make build_sphinx warning proof 2014-04-06 12:20:51 -04:00
tox.ini Add optional spell checker target 2014-04-16 14:59:17 -04:00

README.rst

QA Specs Repository

This is a git repository for doing design review on QA enhancements as part of the OpenStack program. 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 blueprint stub in tempest blueprint repository
  2. Propose review to qa-specs repository (ensure bp:blueprint_name is in the commit message
  3. Link Read the full specification to the gerrit address of the spec
  4. Bring forward the proposed item to the openstack-qa meeting for summary
  5. Review happens on proposal by qa-core members, and others
  6. Iterate until review is Approved or Rejected

Once a Review is Approved...

  1. Update blueprint, Copy summary text of blueprint to there
  2. Link Read the full specification to the git address of the spec
  3. Profit!

Revisiting Specs

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 spec 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.