Skip to content

Latest commit

 

History

History
84 lines (67 loc) · 5.21 KB

CONTRIBUTING.md

File metadata and controls

84 lines (67 loc) · 5.21 KB

How to contribute

We would love to get contributions from you! To keep the process manageable we please ask you to follow the workflow below. By participating in this project, you agree to abide by the code of conduct. Before your code can be accepted, you will have to sign a CLA and mail it to lmarini@illinois.edu.

Most of the core development happens on NCSA Bitbucket. The master and develop branches are pushed to GitHub nightly.

We encourage contributors to create an account on NCSA Bitbucket and make pull requests there. We also accept contributions directly on GitHub.

Workflow

  • Make sure you have an NCSA opensource account
  • If you want to make your pull request on GitHub make sure you have a GitHub account
  • If it's a new feature or improvement please discuss your ideas with the community on the Slack channel or by sending an email to the mailing list. You can subscribe to the mailing list here.
  • Submit a ticket in Jira for your issue, if one doesn't exist already
    • If it's a bug, clearly describe the issue including steps to reproduce it
    • If it's a new feature, clearly describe requirements and how your proposed solution would fulfill them. For complex new features it might help to create a wiki page
    • If it's an improvement, clearly describe the current behavior and how your contribution will improve current functionality.
  • Create a fork on NCSA Bitbucket or GitHub
  • Check out the develop branch
  • Make a feature branch
    • If you created the fork on NCSA Bitbucket, use the "Create branch" link in Jira. This will properly name the branch and keep the link in the issue
    • If you created the fork in GitHub, follow the Atlassian Bitbucket branch naming scheme when naming your branch. For example feature/CATS-438-validate-all-jsonld.
  • Make your cool new feature or bugfix on your branch
  • From your branch, make a pull request against develop
  • Work with repo maintainers to get your change reviewed on GitHub or NCSA Bitbucket
  • When ready to be merged, the branch will first be pulled into develop on NCSA Bitbucket. It will appear on develop on GitHub after the nightly push.
  • When ready to be merged, the branch will first be pulled into develop on NCSA Bitbucket. Overnight it will be pushed to develop on GitHub.
  • Merge the remote develop into your origin develop
  • Delete your feature branch

Code Reviews

Code reviews for pull requests in GitHub will happen in GitHub. Code reviews for pull requests in NCSA Bitbucket will happen in NCSA Bitbucket. When a pull request is ready to be merged into develop it will first be pushed to NCSA Bitbucket if it's on GitHub. It will then be merged with the develop branch in NCSA Bitbucket. It will become available on develop on GitHub overnight with the nightly updates.

Issues

We use some of the common issue types available in Jira. For the most part they are self explanatory: New Feature, Improvement, Bug.

Make sure to get feedback from the community on your proposed solution before starting implementation, either on Slack) or by sending an email to the mailing list). Given the distributed nature of the team and the different requirements from the different projects using and contributing to Clowder, it's important that contributions to the core are compatible with all projects and the overall design.

Testing

We use the ScalaTest testing framework for our tests. Our testing suite is currently not comprehensive. If you feel brave enough please consider adding a test for your new feature (or for existing ones!).

Continuous Integration

Branches in NCSA Bitbucket are automatically built with Bamboo.

Documentation

Developer documentation is available in Confluence. User documentation (still rough) is available in the source /doc/src/sphinx and online.