Skip to content

Latest commit

 

History

History
56 lines (34 loc) · 2.37 KB

CONTRIBUTING.md

File metadata and controls

56 lines (34 loc) · 2.37 KB

Contributing guide

Want to contribute? Great! We try to make it easy, and all contributions, even the smaller ones, are more than welcome. This includes bug reports, fixes, documentation, examples... But first, read this page (including the small print at the end).


NOTE

Although we love have you contribute to the project, note that this project is a fork of fork, so contribute with understanding that your contributions are not going to be pushed to the main project but only to this fork.

From time to time we do pull in upstream changes into this fork.


Legal

All original contributions to openmessaging-benchmark are licensed under the ASL - Apache License, version 2.0 or later, or, if another license is specified as governing the file or directory being modified, such other license.

All contributions are subject to the Developer Certificate of Origin (DCO). The DCO text is also included verbatim in the dco.txt file in the root directory of the repository.

Reporting an issue

This project uses GitHub issues to manage the issues. Open an issue directly in GitHub.

If you believe you found a bug, and it's likely possible, please indicate a way to reproduce it, what you are seeing and what you would expect to see.

Before you contribute

To contribute, use GitHub Pull Requests, from your own fork.

Also, make sure you have set up your Git authorship correctly:

git config --global user.name "Your Full Name"
git config --global user.email [email protected]

If you use different computers to contribute, please make sure the name is the same on all your computers.

We use this information to acknowledge your contributions in release announcements.

Code reviews

All submissions, including submissions by project members, need to be reviewed by at least one openmessaging-benchmark committers before being merged.

GitHub Pull Request Review Process is followed for every pull request.

Coding Guidelines

  • Please properly squash your pull requests before submitting them. Fixup commits can be used temporarily during the review process but things should be squashed at the end to have meaningful commits.