You want to contribute to this module? Many thanks to you! π π
Here are some guidelines that will help us integrate your work!
You are welcome to create pull requests on any of those subjects:
- π bug fix
- π translation / i18n / l10n
If you want to implement a new feature, please create a corresponding ticket for review.
If you ever want to begin implementation, do so in a fork, and add a link to the corresponding commits in the ticket. As maintainers of the module we favor generic solutions, i.e. the ones that address most use cases instead of just a very specific need.
For all security related subjects, please see our security policy.
This iTop module is distributed under the AGPL-3.0 license (see the license.txt file), your code must comply with this license.
Combodo has the copyright on each and every source file in this repository: please do not modify the existing file copyrights.
Anyhow, you are encouraged to signal your contribution by the mean of @author annotations.
If you want to use another license or keep the code ownership (copyright), you may create another extension.
All developments are done on the master branch. If needed, a support/* branch might be created from a tag for compatibility reasons. You should always base your developments on the master branch.
A dedicated page is available in the official wiki.
- Create a fork from our repository (see Working with forks - GitHub Help)
- Create a branch in this fork, based on the develop branch
- Code !
Do create a dedicated branch for each modification you want to propose : if you don't, it will be very hard for us to merge back your work !
Please follow our guidelines.
Please create tests that covers as much as possible the code you're submitting.
Our tests are located in the test/ directory, containing a PHPUnit config file : phpunit.xml.
- Describe the functional change instead of the technical modifications
- Use the present tense ("Add feature" not "Added feature")
- Use the imperative mood ("Move cursor to..." not "Moves cursor to...")
- Limit the first line to 72 characters or less
- Please start the commit message with an applicable emoji code (following the Gitmoji guide).
Beware to use the code (for example:bug:) and not the character (π) as Unicode support in git clients is very poor for now...
Emoji examples :- π
:globe_with_meridians:for translations - π¨
:art:when improving the format/structure of the code - β‘οΈ
:zap:when improving performance - π
:bug:when fixing a bug - π₯
:fire:when removing code or files - π
:green_heart:when fixing the CI build - β
:white_check_mark:when adding tests - π
:lock:when dealing with security - β¬οΈ
:arrow_up:when upgrading dependencies - β¬οΈ
:arrow_down:when downgrading dependencies - β»οΈ
:recycle:code refactoring - π
:lipstick:Updating the UI and style files.
- π
When your code is working, please:
- Squash as much as possible your commits,
- Rebase your branch on our repo last commit,
- Create a pull request. Detailed procedure to work on fork and create PR is available in GitHub help pages.
- Pull request description: mind to add all the information useful to understand why you're suggesting this modification and anything necessary to dive into your work. Especially:
- Bugfixes: exact steps to reproduce the bug (given/when/then), description of the bug cause and what solution is implemented
- Enhancements: use cases, implementation details if needed
- Mind to check the "Allow edits from maintainers" option !