oslo-specs/specs/new-library-template.rst

117 lines
3.1 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.
========================
Proposed new library XXX
========================
Introduction paragraph -- why are we proposing new library?
Proposed library mission
=========================
A detailed description of the problem.
Consuming projects
==================
Who is going to use this (project involvement).
Alternatives library
====================
Existing similar libraries (if any) and why they aren't being used
Proposed adoption model/plan
============================
which adoption model the new library will choose ?
Reviewer activity
=================
who will be responsible for reviewing, how many reviewers are active,
how many could be active.
Implementation
==============
Author(s)
---------
Who is leading the proposal of the new library? Must have at least two
individuals from the community committed to triaging and fixing bugs, and
responding to test failures in a timely manner.
Primary authors:
<launchpad-id or None>
<launchpad-id or None>
Other contributors:
<launchpad-id or None>
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