Skip to content

Latest commit

 

History

History
86 lines (48 loc) · 5.33 KB

CONTRIBUTING.md

File metadata and controls

86 lines (48 loc) · 5.33 KB
Raw

Contributing

Code of conduct

All members of the project community must abide by the Contributor Covenant, version 2.0. Only by respecting each other can we develop a productive, collaborative community. Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting opensource@telekom.de and/or a project maintainer.

We appreciate your courtesy of avoiding political questions here. Issues which are not related to the project itself will be closed by our community managers.

Engaging in our project

We use GitHub to manage reviews of pull requests.

  • If you are a new contributor, see: Steps to Contribute

  • If you have a trivial fix or improvement, go ahead and create a pull request, addressing (with @...) a suitable maintainer of this repository (see CODEOWNERS of the repository you want to contribute to) in the description of the pull request.

  • If you have found a bug, go ahead and follow the instructions of Bug Reports.

  • If you plan to do something more involved or have feature request, please feel free and create an GitHub issue describing your proposal. This will avoid unnecessary work and surely give you and us a good deal of inspiration, but please be willing to implement at least some code for the new feature.

  • Relevant coding style guidelines are available in the respective sub-repositories as they are programming language-dependent.

Bug Reports

  • Before opening a new bug in our GitHub issue tracker, please have a look at the open issues to avoid duplicates as early as possible.

  • If you don't find an open or - even better - already closed issue addressing your problem, please feel free to create an issue providing at least the information that will be asked in the issue template.

  • To give your bug more credit you may add a testcase addressing your problem to make it easier for us to reproduce your error. But, please don't worry if you don't.

  • Remember that bug reports should be able to reproduce and allow other members of the community to collaborate on it. Please do not expect that the bug will automatically see any activity to fix it. Creating a bug just is the start of the path of fixing a problem.

Steps to Contribute

Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on. This is to prevent duplicated efforts from other contributors on the same issue.

If you have questions about one of the issues, please comment on them, and one of the maintainers will clarify.

We kindly ask you to follow the Pull Request Checklist to ensure reviews can happen accordingly.

Contributing Code

You are welcome to contribute code in order to fix a bug or to implement a new feature.

The following rule governs code contributions:

  • Contributions must be licensed under the Apache 2.0 License
  • Newly created files must be opened by an instantiated version to the file 'templates/file-header.txt'
  • At least if you add a new file to the repository, add your name into the contributor section of the file NOTICE (please respect the preset entry structure)

Contributing Documentation

You are welcome to contribute documentation to the project.

The following rule governs documentation contributions:

Pull Request Checklist

  • Branch from the master branch and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master you may be asked to rebase your changes.

  • Commits should be as small as possible while ensuring that each commit is correct independently (i.e., each commit should compile and pass tests).

  • Test your changes as thoroughly as possible before you commit them. Preferably, automate your test by unit/integration tests. If tested manually, provide information about the test scope in the PR description (e.g. “Test passed: Upgrade version from 0.42 to 0.42.23.”).

  • Create Work In Progress [WIP] pull requests only if you need clarification or an explicit review before you can continue your work item.

  • If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment.

  • Post review:

    • If a review requires you to change your commit(s), please test the changes again.
    • Amend the affected commit(s) and force push onto your branch.
    • Set respective comments in your GitHub review to resolved.
    • Create a general PR comment to notify the reviewers that your amendments are ready for another round of review.

Issues and Planning

  • We use GitHub issues to track bugs and enhancement requests.

  • Please provide as much context as possible when you open an issue. The information you provide must be comprehensive enough to reproduce that issue for the assignee. Therefore, contributors may use but aren't restricted to the issue template provided by the project maintainers.

  • When creating an issue, try using one of our issue templates which already contain some guidelines on which content is expected to process the issue most efficiently. If no template applies, you can of course also create an issue from scratch.