First off, thanks for taking the time to contribute!
The following is a set of guidelines for contributing to the SEAPATH project. These are mostly guidelines, sometimes rules. Use your best judgment, and feel free to propose changes to this document in a pull request.
License and Developer Certificate of Origin
- Contributing Code
- Styleguides
- Git workflow guidelines
- Testing
- Documentation
- English language convention
This project applies the LF Energy Code of Conduct. By participating, you are expected to uphold this code. Please report unacceptable behavior to the project's Technical Steering Committee [email protected].
By contributing to the SEAPATH project, you accept and agree to the following terms and conditions for your present and future contributions submitted to SEAPATH.
All contributions to this project are licensed under the license stipulated at the corresponding sub-repository. Except where otherwise explicitely indicated, SEAPATH is an open source project licensed under the Apache License, version 2.0.
The project requires the use of the Developer Certificate of Origin (DCO). The DCO is a legally binding statement asserting that you have the right to submit your contribution and to license it under the project's applicable license.
Contributors sign-off that they adhere to the term of the DCO by adding a Signed-off-by line to commit messages. The DCO sign-off must be attached to every contribution made by every contributor.
Here is an example Signed-off-by line, that indicates the contributor accepts the DCO:
This is my commit message.
Signed-off-by: Name Surname <[email protected]>
You can write it manually but Git even has a -s command line option to append this automatically to your commit message:
$ git commit -s -m 'This is my commit message'
Note that checks will be performed during the integration in order to require that commits in a Pull Request contain valid Signed-off-by lines.
There are many ways to contribute:
- By participating in the TSC meeting passively and/or actively so that you can provide technical advice, understand what the project priorities are, and identify contributions you could make ( you can know when the next TSC meeting take place and eventually suscribe to the mailing list here
- By promoting the project
- By proposing new features or improvements/corrections to the project directly on github.com following the best practices detailed below
The code of the project is available here
- Follow the code style of the project, including indentation
- Create a personal fork of the project on Github
- Clone the fork on your local machine
- Make sure to pull upstream changes into your local repository
- Implement/fix your feature, comment your code if needed
- Make sure to split your commit
- Squash intermediary commits (fixes, WIP, …) with git's interactive rebase
- Each commit should only add one feature
- Use two separate commits when adding a package and enabling it
- Make sure that your commit message is consistent with the git history
- Prefix the commit title by the area touch ex: images/seapath-host-common.inc: add STONITH plugins
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
- Sign off your commit
- Push your branch to your fork on Github
- From your fork open a pull request
More details can be found there.
- Run tests on the hardware you want to install the distribution and ensure that no regression are seen (ex: cukinia)
- Provide the hardware specification
- Write or adapt tests as needed
- When possible a cukinia test must be provided for each new functionnality
- Add or change the documentation as needed.
The convention for all the project's documents, including code documentation, website, is to write American English. A list of spelling differences between British and American English is available here for example.