Contribution Guidelines

We would love to see contributions from you! If you want to help us, please feel free. But there are several issues that you should keep in mind when contributing to Force Feedback Programming. Please follow the contribution guidelines that are defined below.

1. General Rules

1. We are committed to the Contributor Covenant and will enforce the code of conduct. As a contributor, you are expected to also commit to it.
2. Please follow our Issue Workflow.
3. Please follow our Coding Conventions and ensure that your code applies to them.
4. Talk to us! Use issues for discussions or reach us on Gitter before submitting code.
5. Send us suggestions! Please use issues for feature requests, ideas, bugs etc.
6. Please ask us, how you can help. Especially if you do not know where to start. We will discuss and assign an issue to you.
7. Keep the discussions focused. When a new or related topic comes up it's often better to create new issue than to side track the discussion.
8. Keep things small. Deliver quality rather than thousands of lines of code.
9. Give priority to the current style of the project or file you're changing even if it diverges from the general guidelines.
10. Blog and tweet (or whatever) about your contributions, frequently!

2. Commit Messages

Please format commit messages as follows. As the .NET team does, we like to point to this blog post about commit messages as well.

Summarize change in 50 characters or less

Provide more detail after the first line. Leave one blank line below the
summary and wrap all lines at 72 characters or less.

If the change fixes an issue, leave another blank line after the final
paragraph and indicate which issue is fixed in the specific format
below.

Fix #42

Also do your best to factor commits appropriately, i.e not too large with unrelated things in the same commit, and not too small with the same small change applied N times in N different commits. If there was some accidental reformatting or whitespace changes during the course of your commits, please rebase them away before submitting the PR.

3. Pull Requests

1. We only accept contributions via pull requests.
2. We only accept pull request against the development branch.
3. Fork the repository, create a branch based on development, do your changes and submit the code via pull requests.
4. We only accept pull requests for code that was successfully built by our continuous build process.
5. We only accept pull requests that can be merged with the development branch.
6. If your code differs too much from the development branch, we maybe will ask you to merge the development branch into your branch first and then to push it again.
7. Please don't send pull requests for style changes.
8. Please don't send big pull requests. Instead, file an issue and start a discussion so we can agree on a direction before you invest a large amount of time.
9. Contributions beyond the level of a bug fix must be discussed with the team first, or they will likely be declined.
10. When the pull request process deems the change ready it will be merged directly into the tree.