Want to contribute to Split? That's great! Here are a couple of guidelines that will help you contribute. Before we get started: Please note that this project is released with a Contributor Code of Conduct to ensure that this project is a welcoming place for everyone to contribute to. By participating in this project you agree to abide by its terms.
- Contribution workflow
- Setup instructions
- Reporting a bug
- Contributing to an existing issue
- Our labels
- Additional info
- Fork the project.
- Make your feature addition or bug fix.
- Add tests for it. This is important so I don't break it in a future version unintentionally.
- Add documentation if necessary.
- Commit. Do not mess with the Rakefile, version, or history. (If you want to have your own version, that is fine. But bump version in a commit by itself I can ignore when I pull.)
- Send a pull request. Bonus points for topic branches.
- Discussion at the Google Group
You can find in-depth instructions to install in our README.
Note: Split requires Ruby 1.9.2 or higher.
So you've found a bug, and want to help us fix it? Before filing a bug report, please double-check the bug hasn't already been reported. You can do so on our issue tracker. If something hasn't been raised, you can go ahead and create a new issue with the following information:
- When did the error happen?
- How can the error be reproduced?
- If possible, please also provide an error message or a screenshot to illustrate the problem.
If you want to be really thorough, there is a great overview on Stack Overflow of what you should consider when reporting a bug.
It goes without saying that you're welcome to help investigate further and/or find a fix for the bug. If you want to do so, just mention it in your bug report and offer your help!
We've got a few open issues and are always glad to get help on that front. You can view the list of issues here. Most of the issues are labelled, so you can use the labels to get an idea of which issue could be a good fit for you. (Here's a good article on how to find your first bug to fix).
Before getting to work, take a look at the issue and at the conversation around it. Has someone already offered to work on the issue? Has someone been assigned to the issue? If so, you might want to check with them to see whether they're still actively working on it.
If the issue is a few months old, it might be a good idea to write a short comment to double-check that the issue or feature is still a valid one to jump on.
Feel free to ask for more detail on what is expected: are there any more details or specifications you need to know?
And if at any point you get stuck: don't hesitate to ask for help.
We've outlined the contribution workflow here. If you're a first-timer, don't worry! GitHub has a ton of guides to help you through your first pull request: You can find out more about pull requests here and about creating a pull request here.
Especially if you're a newcomer to Open Source and you've found some little bumps along the way while contributing, we recommend you write about them. Here's a great article about why writing about your experience is important; this will encourage other beginners to try their luck at Open Source, too!