Skip to content

Latest commit

 

History

History
53 lines (41 loc) · 2.75 KB

CONTRIBUTING.md

File metadata and controls

53 lines (41 loc) · 2.75 KB
Raw

How to contribute to Unity Weld

👍🎉 First off, thanks for taking the time to contribute! 🎉👍

Reporting bugs

Any bug reports are useful, although there are a few things you can do that will make it easier for maintainers and other users to understand your report, reproduce the behaviour, and find related reports.

  • Use a clear and descriptive title for the issue to identify the problem.
  • Describe the exact steps which reproduce the problem in as many details as possible. Code examples or links to repos to reproduce the issue are always helpful.
  • Describe the behaviour you observed after following the steps and point out what exactly the problem is with that behaviour.
  • Explain which behaviour you expected to see instead and why. This makes it easier to work out what went wrong and whether the behaviour was in fact a bug or was by design.
  • Check the existing open issues on GitHub to see if someone else has had the same problem as you.

Make sure to file bugs as GitHub issues, since that way everyone working on the library can see it and potentially help.

Pull requests

All new code committed to the repository must be reviewed by at least one other person on the Unity Weld team before it can be merged.

Before we merge pull requests there are a few things we look for to make sure the code is maintainable and up the same standard as the rest of the library.

  • Make sure that the examples project still works correctly with the new changes.
  • Check that your code conforms to the same style as existing code. Ensure that your editor is set up to read the .editorconfig file for consistent spacing and line endings. We also try to keep our code style consistent with the Microsoft C# Coding Conventions and Framework Design Guidelines.
  • Make sure that the Travis CI build succeeds. This should run automatically when you create a pull request, but should have the same result as building the solution and running all the tests locally. We will not accept any pull requests that fail to build or contain failing tests.
  • If you have added a new feature, add a section to README.md describing the feature and how to use it.

In addition, if your pull request breaks any existing functionality you'll need to provide a good justification for why it's worth breaking backwards compatibility.