tripleo-specs/specs/policy-template.rst
Ben Nemec 7760f4a2ec Add expedited approvals policy
In general, TripleO follows the standard “2 +2” review standard,
but there are situations where we want to make an exception. This
policy is intended to document those exceptions.

It has recently come to my attention that not all reviewers are
on the same page regarding some of our review policies, so this
is my attempt to document it in a reviewable location.  Some of
this information is already on the wiki, but that is not easy for
the team to review before changes are made and is probably going
away in the future.

Since this is not a release-specific document, I've added a new
section to our specs index for cross-release policies like this.
It is based on the oslo-specs policy section.  I would anticipate
this being useful for other policy type information in the future,
especially as the wiki is being phased out.

Change-Id: Ie2d357813ebc194a94ee26464d6882a6d8abe13a
2016-07-13 16:40:02 +00:00

127 lines
3.6 KiB
ReStructuredText

..
This template should be in ReSTructured text. For help with syntax,
see http://sphinx-doc.org/rest.html
To test out your formatting, build the docs using tox, or see:
http://rst.ninjs.org
The filename in the git repository should match the launchpad URL,
for example a URL of
https://blueprints.launchpad.net/oslo?searchtext=awesome-thing should be
named awesome-thing.rst.
For specs targeted at a single project, please prefix the first line
of your commit message with the name of the project. For example,
if you're submitting a new feature for oslo.config, your git commit
message should start something like: "config: My new feature".
Wrap text at 79 columns.
Do not delete any of the sections in this template. If you have
nothing to say for a whole section, just write: None
If you would like to provide a diagram with your spec, ascii diagrams are
required. http://asciiflow.com/ is a very nice tool to assist with making
ascii diagrams. The reason for this is that the tool used to review specs is
based purely on plain text. Plain text will allow review to proceed without
having to look at additional files which can not be viewed in gerrit. It
will also allow inline feedback on the diagram itself.
=========================
The title of the policy
=========================
Introduction paragraph -- why are we doing anything?
Problem Description
===================
A detailed description of the problem.
Policy
======
Here is where you cover the change you propose to make in detail. How do you
propose to solve this problem?
If the policy seeks to modify a process or workflow followed by the
team, explain how and why.
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 policy?
Alternatives & History
======================
What other ways could we do this thing? Why aren't we using those? This doesn't
have to be a full literature review, but it should demonstrate that thought has
been put into why the proposed solution is an appropriate one.
If the policy changes over time, summarize the changes here. The exact
details are always available by looking at the git history, but
summarizing them will make it easier for anyone to follow the desired
policy and understand when and why it might have changed.
Implementation
==============
Author(s)
---------
Who is leading the writing of the policy? If more than one person is
working on it, please designate the primary author and contact.
Primary author:
<launchpad-id or None>
Other contributors:
<launchpad-id or None>
Milestones
----------
When will the policy go into effect?
If there is a built-in deprecation period for the policy, or criteria
that would trigger it no longer being in effect, describe them.
Work Items
----------
List any concrete steps we need to take to implement the policy.
References
==========
Please add any useful references here. You are not required to have
any references. Moreover, this policy should still make sense when
your references are unavailable. Examples of what you could include
are:
* Links to mailing list or IRC discussions
* Links to notes from a summit session
* Links to relevant research, if appropriate
* Related policies as appropriate
* Anything else you feel it is worthwhile to refer to
Revision History
================
.. list-table:: Revisions
:header-rows: 1
* - Release Name
- Description
* -
- Introduced
.. note::
This work is licensed under a Creative Commons Attribution 3.0
Unported License.
http://creativecommons.org/licenses/by/3.0/legalcode