nova/doc/source/blueprints.rst
Joe Gordon 1f7f9a8588 Make blueprints doc a reference for nova blueprints
Previously  kilo.blueprints was a document to propose a change to the
blueprints process. Turn the document into a reference for blueprints,
specs and priorities in nova.

* Just state current policy instead of references to how it was
  before. This information will still be around in the git history if we
  never need to look it up.
* Now that we have been doing this for a cycle we don't need hypothetical
  examples anymore.
* Make this reflect the fact that we just use an etherpad to track
* priority reviews.

Change-Id: I0d6e568fe1a8ef40de1d7f7d7e45260b1400e407
2015-06-03 17:52:40 +09:00

66 lines
2.5 KiB
ReStructuredText

==================================
Blueprints, Specs and Priorities
==================================
Like most OpenStack projects, Nova uses `blueprints`_ and specifications (specs) to track new
features, but not all blueprints require a spec. This document covers when a spec is needed.
.. note:: Nova's specs live at: `specs.openstack.org`_
.. _`blueprints`: http://docs.openstack.org/infra/manual/developers.html#working-on-specifications-and-blueprints
.. _`specs.openstack.org`: http://specs.openstack.org/openstack/nova-specs/
Specs
=====
A spec is needed for any feature that requires a design discussion. All
features need a blueprint but not all blueprints require a spec.
If a new feature is straightforward enough that it doesn't need any design
discussion, then no spec is required. In order to provide the sort of
documentation that would otherwise be provided via a spec, the commit
message should include a ``DocImpact`` flag and a thorough description
of the feature from a user/operator perspective.
Guidelines for when a feature doesn't need a spec.
* Is the feature a single self contained change?
* If the feature touches code all over the place, it probably should have
a design discussion.
* If the feature is big enough that it needs more then one commit, it
probably should have a design discussion.
* Not an API change.
* API changes always require a design discussion.
Project Priorities
===================
* Pick several project priority themes, in the form of use cases, to help us
prioritize work
* Generate list of improvement blueprints based on the themes
* Produce rough draft of list going into summit and finalize the list at
the summit
* Publish list of project priorities and look for volunteers to work on them
* Update spec template to include
* Specific use cases
* State if the spec is project priority or not
* Keep an up to date list of project priority blueprints that need code review in an etherpad.
* Consumers of project priority and project priority blueprint lists:
* Reviewers looking for direction of where to spend their blueprint review
time. If a large subset of nova-core doesn't use the project
priorities it means the core team is not aligned properly and should
revisit the list of project priorities
* The blueprint approval team, to help find the right balance of blueprints
* Contributors looking for something to work on
* People looking for what they can expect in the next release