You are more than welcomed to do so!
The following is a set of guidelines and best practices for contributing to Eval. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a Pull Request.
Nothing serious, all I ask is to be respectful and as helpful as you would expect others commnicating with you.
The easiest channel is Twitter. You can reach out to me @tevelee, or feel free to write a mail at tevelee [at] gmail [dot] com.
If you have bigger concerns, feel free to write a GitHub issue.
First of all, please read the documentation pages, and feel free to check out the examples.
There are a few things you need to be aware of when contributing:
- The repository is only opened to a very selected set of contributors. If you need any code modifications, you need to fork and create a Pull Request.
- There is a CI up and running
- I use SwiftLint with build-in rules to keep the code as nice as possible
- There is Danger configured with some rules, auto-checking contributions before I do
- I intend to keep the code test coverage as high as possible. Please be mindful about this when contributing
Feel free to use the same channels as I described in the README:
The easiest channel is Twitter. You can reach out to me @tevelee, or feel free to write a mail at tevelee [at] gmail [dot] com.
If you have bigger concerns, feel free to write a GitHub issue.
Please use git rebase keep your number commits as low as possible.
I use a standard style of markdown pages in the README.md and in the Documentation folder.
I also document the code, most importantly the public interfaces. I intend to keep the line documentation coverage of the publicly available methods and classes a 100%.
No rules you need to be aware of