👏 First thing first... Thank you for taking the time to contribute to Centreon project ! 👏 Much appreciated ! 🤘
This article contains guidelines for contributing to Centreon project.
- Where should I report ?
- I have an issue to report
- I have a suggestion of enhancement
- I have a pull request to submit
Any people that wants to contribute and participate in developping the project must respect Centreon Code of Conduct. Please report any unacceptable behavior to community@centreon.com.
Advise: Centreon GitHub is meant for opening issues (code related), feature requests and so on. It is not meant for support. Please refer to the following available ressources, you'll get an answer from a Centreon team or community member.
Centreon community can contribute in many ways to the project.
Issues and feature requests should be done on the appropriate repositories. Here are the repositories maintened by Centreon:
| Modules |
|---|
| centreon-broker |
| centreon-engine |
| centreon-clib |
| centreon-connectors |
| centreon-plugins |
| centreon-dsm |
| centreon-vmware |
Before reporting an issue please make sure that it has not been already reported by checking Centreon Bug Tracker
If your issue has not been reported yet, then the issue should be opened using the following template ISSUE_TEMPLATE.md
Any ideas, enhancements, feature requests are more than welcome. Feature requests should be opened by using the following template FEATURE_REQUEST.md
You have been working on Centreon base code and want to submit it to us. Well... Again you are more than welcome and thank you in advance ! 👏
The pull request must comply with certain requirements which are set out in the following template PULL_REQUEST_TEMPLATE.md
Notice: A pull request which contains more than the described modifications or contains more than one issue will be rejected. Kindly write a detailed description and open one pull request per issue.
If the pull request matches the expected requirements, it will be added to a refinement session with the development team and the product owner. If everything is clear, the pull request will be integrated to the development workflow and will be merged if it successfully passes our Continuous Integration's acceptance tests. Afterwards, our Quality Assurance team will test it again to avoid any regressions before the pull request is released.
If the development team needs more details, they will contact you about the pull request. Please stay tuned.
Warning: Any pull request that does not respect the requirements will ultimately be rejected ! In addition, if you are asked to do so, you must help us understand your changes or behavior, and respond to us within 8 days.
Notice: We used another open source project's contribution model as inspiration to provide better communication on your pull request's status : Visual Studio Code.
Here are the labels and descriptions we may add to your work.
| Label | Reason |
|---|---|
pr/external |
The first badge |
status/accepted |
The development team has approved your modifications |
status/implemented |
The PR has been added or may have already been released in next version |
status/duplicate |
Another PR is already open |
status/invalid |
The requirements are not met |
status/in-backlog |
The development team has groomed your proposition and will work on it soon |
status/could-not-reproduce |
The dev was unable to reproduce the use-case and may need more information |
status/needs-attention |
This PR is on hold. The reason is specified in the issue |
status/needs-merge |
A dev needs to merge your work |
status/too-dangerous |
The modification seems to impact too much features or may introduce side effects |
status/multiple-issues |
The modifications contain more than one issue in a single PR |
status/out-of-scope |
The modifications are out of the described scope |
status/more-info-needed |
A dev asked you for more details and is waiting for your reply |
status/wont-fix |
The modifications do not fix the described behavior |
The commit format should follow this commit template message
<type>(<scope>): <subject>
<body>
<footer>
The format explanation can be found here.
The body section needs to be clear, made of complete sentences introducing the purpose of the commit and the context, making code reviews much easier.
The footer should contain reference(s) to the ticket(s) related to the commit. Applied to the sample ticket
Refs: #5567 (GitHub) or MON-2234 (Jira)
The type can refer to
- feat: adding a feature
- fix: adding a patch
- enh: adding an enhancement
- docs: adding documentation changes
- style: fixing coding style issues
- refactor: code refactoring
- test: adding new tests or fixing old ones
- chore : updating project construction files (Jenkins files, CMakefile, gulp, webpack ...)
The scope is defined by project. Scopes for Centreon Open Source project are related to the modifications. For example: fix(security) or feat(hostgroup)
Centreon software is made of several languages. For each language a specific coding style must be respected.
Notice: For some languages, a bot may ask you to rework the formatting of your code. Until you make the modifications, we won't be able to add your work to the refinement loop.
Since the 18.10 version of Centreon REACT has been introduced and Centreon follows the airbnb react coding style.
For other languages, coding style rules are defined in Centreon GitHub repository
If you want to visualize and suggest modification to the documentation through a pull request you can check the HOW TO build the documentation section here