qa-specs/template.rst
Matthew Treinish 4cd739e088 Update the template to add section for projects
Now that the specs being added to the qa-specs repo can effect more
than 1 project, it'll be useful to explicitly call out which projects
are intended to be changed as part of the spec. This commit adds a new
section to the qa-specs template to list the projects which need to
be changed.

Change-Id: I1b7b7f86a0b3275eb7ee6f1a298ae1588270eb83
2015-02-03 15:26:18 -05:00

104 lines
2.9 KiB
ReStructuredText

..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
..
This template should be in ReSTructured text. The filename in the git
repository should match the launchpad URL, for example a URL of
https://blueprints.launchpad.net/tempest/+spec/awesome-thing should be named
awesome-thing.rst . Please do not delete any of the sections in this
template. If you have nothing to say for a whole section, just write: None
For help with syntax, see http://sphinx-doc.org/rest.html
To test out your formatting, see http://www.tele3.cz/jbar/rest/rest.html
=============================
The title of your blueprint
=============================
Include the URL of your launchpad blueprint:
https://blueprints.launchpad.net/tempest/+spec/example
Introduction paragraph -- why are we doing anything?
Problem description
===================
A detailed description of the problem.
Proposed change
===============
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If this is one part of a larger effort make it clear where this piece ends. In
other words, what's the scope of this effort?
Include where in the tempest tree hierarchy this will reside.
If the change is designed to test other OpenStack projects then list which ones
it is targeted at.
Alternatives
------------
This is an optional section which applies if the blueprint covers
infrastructure changes to tempest. For example, blueprints which are
just adding more API tests can leave this section empty.
Where it does apply we'd just like a demonstration that some thought
has been put into why the proposed approach is the best one.
Projects
========
List the qa projects that this spec effects. For example:
* openstack/tempest
* openstack/tempest-lib
* openstack-dev/devstack
Implementation
==============
Assignee(s)
-----------
Who is leading the writing of the code? Or is this a blueprint where you're
throwing it out there to see who picks it up?
If more than one person is working on the implementation, please designate the
primary author and contact.
Primary assignee:
<launchpad-id or None>
Can optionally can list additional ids if they intend on doing
substantial implementation work on this blueprint.
Milestones
----------
Target Milestone for completion:
Juno-1
Work Items
----------
Work items or tasks -- break the feature up into the things that need to be
done to implement it. Those parts might end up being done by different people,
but we're mostly trying to understand the timeline for implementation.
Dependencies
============
- Include specific references to specs and/or blueprints in tempest, or in other
projects, that this one either depends on or is related to.
- Does this feature require any new library dependencies or code otherwise not
included in OpenStack? Or does it depend on a specific version of library?