One of the easiest ways to contribute is to participate in discussions and discuss issues. You can also contribute by submitting pull requests with code changes.
The best way to get your bug fixed is to be as detailed as you can be about the problem. Providing a minimal project with steps to reproduce the problem is ideal. Here are questions you can answer before you file a bug to make sure you're not missing any important information.
- Did you include the snippet of broken code in the issue?
- What are the EXACT steps to reproduce this problem?
- What package versions are you using (you can see these in the
project.jsonfile)? - What operating system are you using?
GitHub supports markdown, so when filing bugs make sure you check the formatting before clicking submit.
Make sure you can build the code and run the tests. Familiarize yourself with the project workflow and our coding conventions. If you don't know what a pull request is read this article: https://help.github.com/articles/using-pull-requests.
Before submitting a feature or substantial code contribution please discuss it with the team and ensure it follows the product roadmap. You might also read these two blogs posts on contributing code: Open Source Contribution Etiquette by Miguel de Icaza and Don't "Push" Your Pull Requests by Ilya Grigorik. Note that all code submissions will be rigorously reviewed and tested by the Winton team prior to merging.
Here's a few things you should always do when making changes to the code base:
Engineering guidelines
Please follow the existing coding style used in this project.
Commit/Pull Request Format
Summary of the changes (Less than 80 chars)
- Detail 1
- Detail 2
Addresses #bugnumber (in this specific format)
Tests
- Tests need to be provided for every bug/feature that is completed.
- If there is a scenario that is far too hard to test there does not need to be a test for it.
- "Too hard" is determined by the team as a whole.