Merge "Add Contributor Guide"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
1798e8bb35
|
|
@ -2,12 +2,11 @@
|
|||
Contribution Guidelines
|
||||
=======================
|
||||
|
||||
In the Contributions Guide, you will find documented policies for
|
||||
developing with monasca-api. This includes the processes we use for
|
||||
blueprints and specs, bugs, contributor onboarding, core reviewer
|
||||
memberships, and other procedural items.
|
||||
In the Contribution Guide, you will find documented policies for
|
||||
developing with Monasca. This includes the processes we use for
|
||||
blueprints and specs, bugs and other procedural items.
|
||||
|
||||
monasca-api, as with all OpenStack projects, is written with the following
|
||||
Monasca, as with all OpenStack projects, is written with the following
|
||||
design guidelines in mind:
|
||||
|
||||
* **Component based architecture**: Quickly add new behaviors
|
||||
|
|
@ -16,9 +15,85 @@ design guidelines in mind:
|
|||
* **Recoverable**: Failures should be easy to diagnose, debug, and rectify
|
||||
* **Open standards**: Be a reference implementation for a community-driven api
|
||||
|
||||
This documentation is generated by the Sphinx toolkit and lives in the source
|
||||
tree. Additional documentation on monasca-api and other components of
|
||||
OpenStack can be found on the `OpenStack wiki <http://wiki.openstack.org>`_.
|
||||
Workflow
|
||||
~~~~~~~~
|
||||
|
||||
Our process is meant to allow users, developers, and operators to express their
|
||||
desires for new features using Storyboard stories. The workflow is very simple:
|
||||
|
||||
* If something is clearly broken, submit a `bug report`_ in Storyboard.
|
||||
* If you want to change or add a feature, submit a `story`_ in Storyboard.
|
||||
* Monasca core reviewers may request that you submit a `specification`_ to
|
||||
gerrit to elaborate on the feature request.
|
||||
* Significant features require `release notes`_ to be included when the code is
|
||||
merged.
|
||||
|
||||
.. _bug report:
|
||||
|
||||
Bug Reports
|
||||
-----------
|
||||
|
||||
Current bugs can be found in this `Worklist
|
||||
<https://storyboard.openstack.org/#!/worklist/213>`_.
|
||||
|
||||
When filing a bug please remember to add the *bug* tag to the story. Please
|
||||
provide information on what the problem is, how to replicate it, any
|
||||
suggestions for fixing it, and a recommendation of the priority.
|
||||
|
||||
.. _story:
|
||||
|
||||
Stories
|
||||
-------
|
||||
|
||||
New features can be proposed in `Storyboard
|
||||
<https://storyboard.openstack.org/#!/project_group/59>`_ as new Story.
|
||||
|
||||
The initial story primarily needs to express the intent of the idea with
|
||||
enough details that it can be evaluated for compatibility with the project
|
||||
mission and whether or not the change requires a `specification`_. It is *not*
|
||||
expected to contain all of the implementation details. If the feature is very
|
||||
simple and well understood by the team, then describe it simply. The story is
|
||||
then used to track all the related code reviews. Team members will
|
||||
request more information as needed.
|
||||
|
||||
.. _specification:
|
||||
|
||||
Specifications
|
||||
--------------
|
||||
|
||||
We use the `monasca-specs <https://github.com/openstack/monasca-specs>`_
|
||||
repository for specification reviews. Specifications:
|
||||
|
||||
* Provide a review tool for collaborating on feedback and reviews for complex
|
||||
features.
|
||||
* Collect team priorities.
|
||||
* Serve as the basis for documenting the feature once implemented.
|
||||
* Ensure that the overall impact on the system is considered.
|
||||
|
||||
.. _release notes:
|
||||
|
||||
Release Notes
|
||||
-------------
|
||||
|
||||
The release notes for a patch should be included in the patch. If not, the
|
||||
release notes should be in a follow-on review.
|
||||
|
||||
If any of the following applies to the patch, a release note is required:
|
||||
|
||||
* The deployer needs to take an action when upgrading
|
||||
* A new feature is implemented
|
||||
* Plugin API function was removed or changed
|
||||
* Current behavior is changed
|
||||
* A new config option is added that the deployer should consider changing from
|
||||
the default
|
||||
* A security bug is fixed
|
||||
* Change may break previous versions of the client library(ies)
|
||||
* Requirement changes are introduced for important libraries like oslo, six
|
||||
requests, etc.
|
||||
* Deprecation period starts or code is purged
|
||||
|
||||
A release note is suggested if a long-standing or important bug is fixed.
|
||||
Otherwise, a release note is not required.
|
||||
|
||||
Developer reference
|
||||
-------------------
|
||||
|
|
@ -35,3 +110,7 @@ Changelog
|
|||
:maxdepth: 1
|
||||
|
||||
history
|
||||
|
||||
This documentation is generated by the Sphinx toolkit and lives in the source
|
||||
tree. Additional documentation on Monasca and other components of OpenStack can
|
||||
be found on the `OpenStack wiki <http://wiki.openstack.org>`_.
|
||||
|
|
|
|||
Loading…
Reference in New Issue