First check the reported issues by searching on GitHub under Issues. You may be experiencing a known issue which you can contribute to diagnosing.
If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
Open a new GitHub pull request with the patch.
Ensure the pull request description clearly describes the problem and solution. Include the relevant issue number if applicable.
Note: If this is your first contribution then follow Sign a CLA below.
Open a new GitHub pull request with the feature.
Ensure the pull request description clearly states:
- what the feature does
- why this feature is useful
- a summarization of the changes contained within
Include the relevant issue number if applicable.
You can always discuss your proposed feature with the community first:
your topic branch
Clone bel.rb and create a branch specifically for your patch or feature work. Then you are ready to submit a pull request to the next branch.
next
The next branch aggregates new/unstable code intended for a future release. When code stabilizes (e.g. feature-complete, tests included and pass) it is merged to master.
master
The master branch represents stable code where releases are tagged from. When a release of master is ready a semantic version tag should be created and the subsequent gem pushed to rubygems.
We'd love for you to contribute and to make this project even better than it is today! If this interests you, please begin by reading our contributing guidelines. The contributing document will provide you with all the information you need to get started.
Once you have read that, you will need to also sign our CLA before we can accept a Pull Request from you. More information on the process is included in the contributor's guide.