...there's no support team. When you create an Issue, it will be seen by the other users of SVGKit. If someone answers, it's because they're a fellow user and they're trying to help.
Some of them are kind enough to fix things for other developers - but please note they're doing it out of generosity!
The Issues that get fastest response / resolved best are often the shortest - but not TOO short.
Adam wrote an ultra short guide: How to write a good Issue - it's worth a quick read!
We love Pull Requests. Most get accepted within hours.
But there's a couple of hard and fast rules, to protect all of us:
- A Pull Request MUST be a small, self-contained feature or fix, or a couple of fixes at most. It could stretch over many files, but usually it will be 2-5 files at most.
- ...because: a Maintainer will manually check every line of code in the Pull Request, and make sure it doesn't break anything else
- If your code breaks other stuff, we'll tell you why and help you to fix it
- EVERY PULL REQUEST should be first tested using the "Demo-iOS" app (or "Demo-OSX" app) to make sure it works with all our current SVG files
- If you're fixing a bug, PLEASE CREATE A SIMPLE SVG FILE THAT DEMONSTRATES THE BUG, and then a Maintainer can add it to the Demo app, and use it to "prove" that your fix works. (or you can add it yourself directly, as part of your commit)
- When you send a Pull Request, you warrant that it's your own code, or that you have permission to donate it to the project (this should be obvious! It's open-source!)
We have very few rules for coding style. But there are a couple of things that affect other programmers:
- Don't reformat existing code unless it's VERY badly formatted - it makes it TEN TIMES HARDER for us to check your changes (it will mess up all the diff's)