Add Smaug spec directory
Add the skeleton and template Change-Id: I72c06c93ce02d8e0a14ed1f935c8b47b4bd9bdb2
This commit is contained in:
parent
186ccdba2f
commit
b119e22bce
23
doc/source/specs/skeleton.rst
Normal file
23
doc/source/specs/skeleton.rst
Normal file
@ -0,0 +1,23 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
==========================================
|
||||
Title of your RFE
|
||||
==========================================
|
||||
|
||||
|
||||
Problem Description
|
||||
===================
|
||||
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
|
132
doc/source/specs/template.rst
Normal file
132
doc/source/specs/template.rst
Normal file
@ -0,0 +1,132 @@
|
||||
..
|
||||
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||
License.
|
||||
|
||||
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||
|
||||
====================================
|
||||
Example Spec - The title of your RFE
|
||||
====================================
|
||||
|
||||
Include the URL of your launchpad RFE:
|
||||
|
||||
https://bugs.launchpad.net/smaug/+bug/example-id
|
||||
|
||||
Introduction paragraph -- why are we doing this feature? A single paragraph of
|
||||
prose that **deployers, and developers, and operators** can understand.
|
||||
|
||||
Do you even need to file a spec? Most features can be done by filing an RFE bug
|
||||
and moving on with life. In most cases, filing an RFE and documenting your
|
||||
design is sufficient. If the feature seems very large or contentious, then
|
||||
you may want to consider filing a spec.
|
||||
|
||||
|
||||
Problem description
|
||||
===================
|
||||
|
||||
A detailed description of the problem. What problem is this blueprint
|
||||
addressing?
|
||||
|
||||
Use Cases
|
||||
---------
|
||||
|
||||
What use cases does this address? What impact on actors does this change have?
|
||||
Ensure you are clear about the actors in each use case: Developer, End User,
|
||||
Deployer etc.
|
||||
|
||||
Proposed Change
|
||||
===============
|
||||
|
||||
How do you propose to solve this problem?
|
||||
|
||||
This section is optional, and provides an area to discuss your high-level
|
||||
design at the same time as use cases, if desired. Note that by high-level,
|
||||
we mean the "view from orbit" rough cut at how things will happen.
|
||||
|
||||
This section should 'scope' the effort from a feature standpoint: how is the
|
||||
'smaug end-to-end system' going to look like after this change? What Smaug
|
||||
areas do you intend to touch and how do you intend to work on them?
|
||||
|
||||
|
||||
Alternatives
|
||||
------------
|
||||
|
||||
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.
|
||||
|
||||
Data model impact
|
||||
-----------------
|
||||
|
||||
|
||||
REST API impact
|
||||
---------------
|
||||
|
||||
|
||||
Security impact
|
||||
---------------
|
||||
|
||||
Describe any potential security impact on the system. Some of the items to
|
||||
consider include:
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Please add any useful references here. You are not required to have any
|
||||
reference. Moreover, this specification should still make sense when your
|
||||
references are unavailable.
|
||||
|
||||
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>
|
||||
|
||||
Other contributors:
|
||||
<launchpad-id or None>
|
||||
|
||||
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 smaug, or in other
|
||||
projects, that this one either depends on or is related to.
|
||||
|
||||
* If this requires functionality of another project that is not currently used
|
||||
by Nova (such as the glance v2 API when we previously only required v1),
|
||||
document that fact.
|
||||
|
||||
* 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?
|
||||
|
||||
|
||||
Testing
|
||||
=======
|
||||
|
||||
|
||||
Documentation Impact
|
||||
====================
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Please add any useful references here. You are not required to have any
|
||||
reference. Moreover, this specification should still make sense when your
|
||||
references are unavailable. Examples of what you could include are:
|
Loading…
Reference in New Issue
Block a user