Contribute

Do you want to contribute to Rig Remote? Here is how...

There are at least 3 ways.

Submit a pull request

We will keep a list of issues that are labeled with help wanted. Feel free to pick-up one of those issues and provide us a pull request. Those issues should be well-enough defined to be solvable even without a deep understanding of the whole code base. Those issues are covering something that we want to include in the code. Otherwise send us a pull request on whatever you want/think it should be included in the tool. We need to evaluate how the code change fits in the existing code and provide a code review.

Become a collaborator

Becoming a collaborator is the way of contributing to the project that implies not only writing code but also taking care of the wiki pages, mailing list, design details, milestone definition and prioritization of the issues and so on.

For becoming a collaborator just send us pull requests, we will reach-out to you after checking the pull-request you provided over time.

Fork the project

This is the way we like less... we would like to grow the tool and include all the features requested and on-board all the code changes that may help. This may not be always neither possible nor the best/fastest way.

If you go this way we may follow the evolution of your fork and include/re-implement the same features/behavior, and maybe get in touch with you.

Expectations on code contributions

There is no rocket science, just the usual way of doing things... just written down.

...as a general contributor

What follows is the list of details we would like to request before on-boarding code into Rig Remote. The more boxes a pull-request ticks the faster will be the on-boarding. If your pull request isn't ticking any of the following aspects, the on-boarding of the code change may be very long.

1. every new code should contain a minimal unit-test coverage for all the new features added
2. every method/function/class should follow the actual practice in the code regarding docstrings
3. every method/function/class/variable should have a meaningful naming
4. there is no code duplication in the pull request.
5. the commit messages are meaningful descriptive enough to clarify the work done
6. if the pull request is referring an issue, please put the link in the commit message of the pull request.

...as a collaborator

We want to track the work done through github as much as possible. All the previous request are valid even if you are a collaborator.

1. bug handling.

   • If the bug is reported in master branch then create an issue labeled as bug (report in the issue what branch is affected) and a custom branch from master. The branch name should refer the issue number. Provide the code change along with one or more unit tests (all of them must pass). Merge the change in Master and then merge the same change in devel branch and resolve the issue.

   • If the bug is reported in devel branch then create an issue labeled as bug (report in the issue what branch is affected). The branch name should refer the issue number. Provide the code change along with one or more unit tests (all of them must pass). Merge the change in devel branch and resolve the issue.

2. new feature or improvement.

   • all the relevant development of Rig Remote is tracked in issues. All the relevant issues are grouped in milestones that define the bigger picture of a set of issues.
   • at this point everything starts with an issue and a branch from devel (we try to avoid to progress the tool from master branch). The branch name should reference at least the issue number. Provide the code and the related unit tests, merge the code mentioning the issue link in the commit message and resolve the issue.