So You Want to Contribute…¶
For general information on contributing to OpenStack, please check out the contributor guide to get started. It covers all the basics that are common to all OpenStack projects: the accounts you need, the basics of interacting with our Gerrit review system, how we communicate as a community, etc.
Below will cover the more project specific information you need to get started with Monasca.
Communication¶
For communicating with Monasca Team, you can reach out to us on #openstack-monasca IRC channel at OFTC.
We hold weekly team meetings in our IRC channel which is a good opportunity to ask questions, propose new features or just get in touch with the team.
You can also send us an email to the mailing list openstack-discuss@lists.openstack.org. Please use [Monasca] tag for easier thread filtering.
Contacting the Core Team¶
Name |
IRC nick |
|
|---|---|---|
Martin Chacon Piza |
chaconpiza |
|
Witek Bedyk |
witek |
|
Doug Szumski |
dougsz |
|
Adrian Czarnecki |
adriancz |
|
Joseph Davis |
joadavis |
New Feature Planning¶
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.
Stories¶
New features can be proposed in Storyboard 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.
Specifications¶
We use the 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¶
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.
Task Tracking¶
We track our tasks in Storyboard
https://storyboard.openstack.org/#!/project_group/monasca
If you’re looking for some smaller, easier work item to pick up and get started on, search for the ‘low-hanging-fruit’ tag.
Kanban Board¶
Progress on implementation of important stories in Ussuri release is tracked in Monasca Board on StoryBoard.
Reporting a Bug¶
You found an issue and want to make sure we are aware of it? You can report them on Storyboard.
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.
All open bugs can be found in this Worklist.
Getting Your Patch Merged¶
All changes proposed to Monasca requires at least one Code-Review +2 votes
from Monasca core reviewers before one of the core reviewers can approve
patch by giving Workflow +1 vote.
Reviews Prioritisation¶
Monasca project uses Review-Priority field in Gerrit to emphasize prioritized code changes.
Every developer can propose the changes which should be prioritized in weekly team meeting or in the mailing list. Any core reviewer, preferably from a different company, can confirm such proposed change by setting Review-Priority +1.
Prioritized changes can be listed in this dashboard.
Project Team Lead Duties¶
All common PTL duties are enumerated in the PTL guide.
