Skip to content

Latest commit

 

History

History
55 lines (44 loc) · 3.8 KB

CONTRIBUTING.md

File metadata and controls

55 lines (44 loc) · 3.8 KB
Raw

Contributing

Table of Contents

How to file a bug report

To file a bug report, visit the Issues page, and search if the bug has already been reported. If it has not, then open a new issue, giving a short, descriptive title explaining the bug. From there, you will get a template file that outlines how to describe your bug and what information we are looking for when you submit it.

How to suggest a new feature

Same as filing a bug report, open a new Issue and follow the guidelines in the template.

How to set up your environment and run tests

Presently, the Visual Studio 2017 IDE is the only supported environment. Users are encouraged to suggest new environments in our Issues section.

Refer to the README on the front page for a complete setup instructions.

The types of contributions we're looking for

Refer to our VISION file for a better roadmap of this project. To summarize the points it makes, the following contributions are greatly supported:

  • Unit/Benchmark tests
  • Source code documentation
  • Bug fixes
  • Cross-platform support
  • Cross-IDE support

Below are some things we think wouldn't be helpful for contributions

  • Creating issues with minimal descriptions. Try to explain as much of the problem as possible.
  • Saying "I can't build on my computer" without providing details on what you tried, citing the README and the CONTRIBUTING file.
  • Submitting a pull request with no description of what the code does. Even if it's a typo fix, mention that it's a typo fix.
  • Submitting a pull request without opening an Issue first. Every pull request should be a solution to an existing issue. For very trivial things like typos, this is an exception. However, one line bug fix patches should still have an issue open to address the bug.
  • Submitting a bug fix without an accompanying unit test to catch the bug from now on (except in cases of bugs that were typos e.g. if (x = true) to if (x == true).
  • Requesting a feature that is far outside the scope of our VISION (e.g. Make an N64 emulator).

Our vision for the project

Refer to VISION for a complete description of our project's vision.

Code styles

Refer to our CODE STYLES guide for an in-depth discussion on how to write your code for this project.

Commit messages

This article does a great job describing the value of a formatted git commit message. The things to take away from it are

  1. Separate subject from body with a blank line
  2. Limit the subject line to 50 characters
  3. Capitalize the subject line
  4. Do not end the subject line with a period
  5. Use the imperative mood in the subject line
  6. Wrap the body at 72 characters
  7. Use the body to explain what and why vs. how

Try to comply to these rules as much as possible.