dae93af09d
- make pep8 working by removing ChangeLog that is not generated - make maven working by removing condidation for user - make legacy dsvm working by using $USER intstead of hardcoded jenkins Change-Id: I30f2edc4d34d0fad63f961f99dcecaf5c767f57f
109 lines
3.7 KiB
ReStructuredText
109 lines
3.7 KiB
ReStructuredText
=======================
|
|
Contribution Guidelines
|
|
=======================
|
|
|
|
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, as with all OpenStack projects, is written with the following
|
|
design guidelines in mind:
|
|
|
|
* **Component based architecture**: Quickly add new behaviors
|
|
* **Highly available**: Scale to very serious workloads
|
|
* **Fault tolerant**: Isolated processes avoid cascading failures
|
|
* **Recoverable**: Failures should be easy to diagnose, debug, and rectify
|
|
* **Open standards**: Be a reference implementation for a community-driven api
|
|
|
|
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
|
|
-------------------
|
|
|
|
.. toctree::
|
|
:maxdepth: 1
|
|
|
|
code
|
|
|
|
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>`_.
|