Issues are always very welcome - after all, they are a big part of making sequelize better. However, there are a couple of things you can do to make the lives of the developers _much, much_ easier:
### Tell us:
* What you are doing?
* Post a _minimal_ code sample that reproduces the issue, including models and associations
* What do you expect to happen?
* What is actually happening?
* Which dialect you are using?
* Which sequelize version you are using?
If you can even provide a pull request with a failing unit test, we will love you long time! Plus your issue will likely be fixed much faster.
# Pull requests
We're glad to get pull request if any functionality is missing or something is buggy. However, there are a couple of things you can do to make life easier for the maintainers:
* Explain the issue that your PR is solving - or link to an existing issue
* Make sure that all existing tests pass
* Add some tests for your new functionality or a test exhibiting the bug you are solving. Ideally all new tests should not pass _without_ your changes.
- Use [promise style](https://github.com/petkaantonov/bluebird#what-are-promises-and-why-should-i-use-them) in all new tests. Specifically this means:
- don't use `EventEmitter`, `QueryChainer` or the `success`, `done` and `error` events
- don't use nested callbacks (use [Promise.bind](https://github.com/petkaantonov/bluebird/blob/master/API.md#binddynamic-thisarg---promise) to maintain context in promise chains)
- don't use a done callback in your test, just return the promise chain.
- Small bugfixes and direct backports to the 1.7 branch are accepted without tests.
* If you are adding to / changing the public API, remember to add API docs, in the form of [JSDoc style](http://usejsdoc.org/about-getting-started.html) comments. See [section 4a](#4a-check-the-documentation) for the specifics.
Still interested? Coolio! Here is how to get started:
### 1. Prepare your environment
Here comes a little surprise: You need [Node.JS](http://nodejs.org). In order to be a productive developer, I would recommend the latest v0.10.
### 2. Install the dependencies
Just "cd" into sequelize directory and run `npm install`, see an example below:
```console
$ cd path/to/sequelize
$ npm install
```
### 3. Database... Come to me! ###
For MySQL and PostgreSQL you'll need to create a DB called `sequelize_test`.
For MySQL this would look like this:
```console
$ echo "CREATE DATABASE sequelize_test;" | mysql -uroot
```
**CLEVER NOTE:** by default, your local MySQL install must be with username `root` without password. If you want to customize that, you can set the environment variables `SEQ_DB`, `SEQ_USER`, `SEQ_PW`, `SEQ_HOST` and `SEQ_PORT`.
For Postgres, creating the database and (optionally) adding the test user this would look like:
```console
$ psql
# create database sequelize_test;
# create user postgres with superuser;
```
**AND ONE LAST THING:** Once `npm install` worked for you (see below), you'll
get SQLite tests for free :)
#### 3a. Docker
If you don't feel like setting up databases and users, you can use our [docker](http://docker.io)[image](https://index.docker.io/u/mhansen/sequelize-contribution/) for sequelize contribution.
Getting the image:
```console
$ sudo docker pull mhansen/sequelize-contribution
```
Start the container and save references to container id and ip:
```console
$ CONTAINER=$(sudo docker run -d -i -t mhansen/sequelize-contribution)
$ make all || mysql || sqlite || pgsql || postgres || mariadb || postgres-native
$ # alternatively you can pass database credentials with $variables when testing
$ DIALECT=dialect SEQ_DB=database SEQ_USER=user SEQ_PW=password make test
```
#### 4a. Check the documentation
This step only applies if you have actually changed something in the documentation. To generate documentation for the `sequelize.js` file, run (in the sequelize dir)
```console
$ node docs/markdox.js --file lib/sequelize.js
```
The generated documentation will be placed in `docs/tmp.md`.
### 5. That's all ###
Just commit and send your pull request. Happy hacking and thank you for contributing.
### 6. Some words about coding style ###
Have a look at our [.jshintrc](https://github.com/sequelize/sequelize/blob/master/.jshintrc) file for the specifics. As part of the test process, all files will be linted, and your PR will _not_ be accepted if it does not pass linting.
