CONTRIBUTING.md
# Contributing to Turnpike
Wow! First of all, if you're reading this, thank you! I'm excited to see this community grow
If you are interested in contributing, please read on. We'll strive to keep this brief and simple.
## I use this framework!
Awesome! If you want to be listed as a user, open up an issue with the following info:
1. The name of your company
2. The name of the site
3. The URL where we can find your site
Once you've opened that issue, you can (but by no means need to) open a pull request updating the README
file. We'll be listing these at the end of the file. the format isn't decided yet, so you can even be the
one who decides how that list will look!
## Submitting issues
### Security Issues
DON'T OPEN AN ISSUE IN GITHUB!
Just email me with any security issues: unleet.42@gmail.com.
Thanks.
### Bugs
The format for these is pretty standard. Include the following information, in this order:
1. The expected behavior
2. Why your expectation makes sense
3. The observed behavior
That's really all that's needed. Bug reports missing any of this information will be closed.
### Feature requests
If you are requesting new features, please be sure to include the following:
1. A brief overview of the feature
2. Why it would be useful (include examples)
3. A broad overview of what you think the API for your issue should look like
Additionally, you can, but do not need to, include more information, such as:
1. A detailed API description
2. Acceptance criteria for automated tests
### Questions
Unlike more mature projects, currently questions are **encouraged** in the issue queue. Very
likely you won't get a direct answer though. Questions are still very helpful. By posting
them, we'll know where we need to beef up the documentation. When the documentation is updated
to answer your question, the issue will be closed with our thanks.
## Pull requests
Pull requests **must** address an open issue. Any pull request that does not reference an open
issue in the queue will be closed without comment. Otherwise, pull requests are welcome.
If you want to open a pull request, keep the following in mind:
1. Try to keep the scope as narrow as possible. Some issues in the queue are intentionally very broad.
If you're addressing one of those, then make your pull request address one aspect of that issue. If
you want to address more of the issue, feel free to open more pull requests for those.
2. Make sure all existing linting and tests pass before opening your pull request. Pull requests that
don't pass testing will not be merged. There are no exceptions to this rule, but you may push
additional commits to fix these issues after your pull request is open.
3. If your pull request includes new features, try to add tests for these new features. If you're not
sure how to go about that, don't worry too much. You can ask for help, and will probably get it.
4. Very soon (if it hasn't happened yet) there will be programmatic enforcement of coding style. Make
sure that check passes before you open your pull request.
5. Open your pull reuqest intially against the `master` branch unless otherwise instructed.
6. It is very likely you will be asked to rebase your pull request against the branch where the next
major release is being built, but sometimes we might want your changes to go into an earlier release.
So, don't be too surprised if you're asked to rebase once or twice before your work will be merged.
7. Feedback is **good**, even if you get criticism. If your pull request gets feedback, then it means
it's good enough to consider including! So, even if you're asked to make changes (possibly major
ones), get excited. It probably means your work is on track to be included in the project.
## A final thought
This is a list of guidelines, not rules. They are certainly not (at least not yet) carved in stone.
Even these contribution guidelines are open to contributions. If something here can be more clear,
or more welcomming, then please feel free to open an issue for it.