Skip to content

Latest commit

 

History

History
62 lines (49 loc) · 4.79 KB

CONTRIBUTING.md

File metadata and controls

62 lines (49 loc) · 4.79 KB

Contributing

Welcome!

Hello. My name is Nelson and MushROMs has been a passion project of mine for many years. I currently work three jobs that I love and am working on going to graduate school for astrophysics. I therefore have very little time to commit to my little hobbies and am thus very greatful that you are interested in contributing to MushROMs. It really motivates me to know other people share my interests. Before getting started, however, I would really like you to read over this document to see how I like contributions to be submitted. It is my belief that these guidelines will help all of us best understand each other and collaborate together

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 for MushROMs. 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 idea of what exactly MushROMs is and how I want it to get there. 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
  • Game editing utilities (e.g. Music editor, 3D object editor, etc.)
  • Issue closers

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

  • Opening an issue that says "You should add support for Game X and having no code documentation for the game. I would love to add support for Game X but opening an issue for that with no extra information wouldn't do much for anyone.
  • 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 editor for Super Mario 64).

Our vision for the project

MushROMs is intended to be the core for Super NES game editors.

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.