I love your input! I want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
I use github to host code, to track issues and feature requests, as well as accept pull requests.
Report bugs using Github's issues
I use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy! Alternatively, you can send an email to [email protected].
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
People love thorough bug reports. I'm not even kidding.
I Use GitFlow, So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (I use GitFlow). I actively welcome your pull requests:
- Fork the repo and create your branch from
develop
. - If you've added code that should be tested, add tests.
- Run
flutter test
and ensure the test suite passes. - Make sure your code lints.
- Issue that pull request!
I haven't set up strict checks on code style yet. In the meantime, I ask you to enable linting in your editor (it should already be enabled by default on Android Studio) and lint your code before submitting a PR.
The less changes you want to merge, the easier it will be to review them. Prefer multiple small PRs to a single monolithic PR.
In short, when you submit code changes, your submissions are understood to be under the same BSD 3-Clause License that covers Flutter and this project. Feel free to contact me if that's a concern.