Skip to content

Latest commit

 

History

History
91 lines (76 loc) · 4.62 KB

Contribution.md

File metadata and controls

91 lines (76 loc) · 4.62 KB
Raw

Contributing

Thank you for your interest in contributing to the ETF project. We would appreciate it if you would read this information carefully so that we can propagate your changes as soon as possible.

Please read and follow our Code of Conduct before you interact with the ETF community.

We distinguish between two types of changes to the ETF software that are handled differently:

  • For changes that provide bug fixes a Pull Request can be created that references an existing bug in the ETF webapp repository.
  • Changes that provide improvements to the software must first be discussed in an ETF Improvement Proposal (EIP) and reference an accepted EIP.

The ETF project is governed by a Steering Group which is supported by a Technical Committee (TC) in technical matters. Your Pull Request will be reviewed by the Technical Committee.

Developer Certificate of Origin

ETF is Licensed under the European Public License 1.2. For all project contributions it is necessary to follow the Developer Certificate of Origin (DCO) mechanism.

The DCO is legally binding statement that ensures you are the creator of the contribution, and that you allow the ETF project to use your work. The Developer Certificate of Origin can be found at http://developercertificate.org/ .

The DCO is attached to every contribution made by every developer. In the commit message of the contribution, the developer must add a Signed-off-by statement to agree to the DCO and digitally sign it with a GPG signature.

Please refer to both sources to learn how to configure and use your GIT:

Most GIT clients support adding Signed-off-by to the commit messages but do not support the configuration of signing the commits with GPG. Please check if the settings for user, commit and gpg are set in your local GIT configuration. An example:

[user]
  name = John Doe
  email = [email protected]
  signingkey = 420A420FFF
[commit]
  gpgsign = true
[gpg]
  program = /usr/local/bin/gpg

Pull Request Process

  1. Please read and accept the Developer Certificate of Origin. All commits have to be signed-off and digitally signed. Make sure you have configured your GIT client accordingly.
  2. Fork the repository.
  3. Create a branch in your forked repository that either references an ETF Improvement Proposal (EIP) or an reported bug. The branch name should be 'EIP-NUMBER' for an ETF Improvement Proposal, where NUMBER is the GitHub issue number from governance repository or 'bug-NUMBER' where NUMBER is the GitHub issue number from the ETF webapp repository.
  4. Make the code changes. Please also check the Requirements for a Pull Request section below.
  5. Implement unit tests and test your changes. Run all unit tests of the module with the gradle test task. Note: your unit tests, additional integration and system tests are automatically run by a Continuous Integration system when you create the Pull Request and must also be passed.
  6. Run the gradle spottlessApply task for an uniform code formatting and for ensuring that all Copyright headers are set.
  7. Please do not increase the version number. The TC will increase the version number for you based on the impact of the change.
  8. Push to your branch and then create a Pull Request in our repository. Describe your design decisions for new features in the Pull Request.

Requirements for a Pull Request

  1. A Pull Request can be composed by one or multiple commits. All changes together address one high-level concern. If a Pull Request provides multiple, distinct features from different sections and each section addresses a separate concern, without addressing one common high-level concern, it will be rejected. Examples for bad Pull Requests: a Pull Request that provides a bugfix and adds a feature or a Pull Request that addresses multiple EIPs.
  2. Changes must be traceable in the commit history.
  3. Make sure you have added Javadocs if you have added public interfaces.
  4. Make sure there are no commented out code sections.
  5. English language needs to be used in code and comments.