Skip to content

Latest commit

 

History

History
60 lines (40 loc) · 3.83 KB

CONTRIBUTING.md

File metadata and controls

60 lines (40 loc) · 3.83 KB
Raw

How to contribute

Thank you for taking time to contribute to this repository! This guide should help you effectively do so by following the systems already in place for maintaining the repository.

Table of contents

Code of conduct

This repository and everyone contributing to is subject to follow the adopted code of conduct. Should you choose to contribute, you will be expected to uphold this code. Please report any violations to @gkapfham or @philmcminn.

Raising an issue

First, check the Issue Tracker to make sure it has not already been made there. If it would be a new issue, go ahead and raise it! We just ask that you:

  • give it a descriptive title
  • provide any relevant information
  • add any labels that apply to it
    • or suggest labels if you do not have permission to add them
  • reference any other related issues

Making a pull request

When making a pull request, we ask that you do the following:

  • give it a descriptive title
  • include language that will close all issues it is proposing fixes for
  • describe any issues that it is proposing to fix that are not in the issue tracker to give a greater idea as to why the pull request should be approved
  • fully describes all of the changes it is proposing and why succinctly states why they should be approved
  • add any labels that apply to it
    • or suggest labels if you do not have permission to add them
  • includes all relevant updates to documentation if warranted by the proposed changes

Coding standards

All of the following subsections must be adhered to:

Code style

All of the code in the repository is written in Java and must conform to the Google check style for Java so that all code is in a single form. Currently, the requirement for having Javadoc comments is disabled, but they should be included with new code.

Testing

All pull requests should either maintain the current level of code coverage or increase it. Any amount of coverage lost will not be accepted and the pull request will not be merged. Test cases should be made to cover any new code added. This should be kept in mind while writing code so that it can tested easily and as much of it can be covered as possible. The goal will always be to have as high of a code coverage as possible and ultimately everything, or as much as possible if not everything can be refactored to be covered.

Updating .gitignore file

The .gitignore file should be updated to include any and all origins of where local files could originate and be added to the repository when they should not. The website gitignore.io may be of use for finding what should be added to the file based off of what is used while working on this project. It typically provides everything that should be considered for a given tool, IDE, etc. but does not always include everything. Care should also be taken in case parts of the .gitignore file generated by the site are taken out or have additional parts included with them when a newly generated version is being added to the file.

External resources

If you would like more information on the repository and project as whole, feel free to read the paper associated with it or visit its website.

Thanks for taking the time to read this!