Skip to content

Latest commit

 

History

History
38 lines (29 loc) · 2.67 KB

CONTRIBUTING.md

File metadata and controls

38 lines (29 loc) · 2.67 KB
Raw

Contributing

Hi there! We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.

Please note that this project is released with a Contributor Code of Conduct. By participating in this project you agree to abide by its terms.

Creating Issues

  • Like many open source projects, we strongly urge you to search through the existing issues before creating a new one.
  • Please include as many details as possible.
    • Consider the target audience when filling out an issue or enhancement.
    • If you can include a use case of how you think a new model should work, all the better.
  • All issues should be filed under the milestone "Up for Discussion" until the team moves it under a particular release or other related issue management action.

Pull Requests

  1. Create a branch to work on a fix/feature (a fix/feature should have a companion bug/enhancement issue). Start the branch with either "feature/..." or "bug/...".
    • If you're not a member of the repository team, fork the repository and follow the same process.
  2. Before sending out a pull request, please make sure that:
    • If working on a schema bug/feature, the resulting code passes all tests and, ifworking on a new feature, it has an accompanying function or unit test (NB: the granularity of the testing suite is team/project dependent).
    • If working on a documentation bug/feature, the documentation must build with no errors, if using an automated system.
  3. Once it's done and tested, create a pull request to move it into the current working branch.
    • If working with a continuous integration/deployment environment (e.g. Travis CI, BuildKite, or Drone) with a direct connection to the GitHub repo, all tests must pass in the pull request.
  4. At that point, some discussion might happen. In order to get approval for the pull request, you will need approval from two people on the development team.
  5. When it's reviewed and accepted by the team within a reasonable timeframe (TBD), it's merged into the current working branch by the developer who created the pull request, if the developer has write permissions. If not, one of the core developers will be responsible for the merge after approval.
  6. Delete the feature/bug branch.

Resources