1# Contributing Guidelines
 2
 3## Code of Conduct
 4
 5This is probably way overkill, but this is by far my most active project in
 6terms of contributions, and somewhere along the way I was convinced that it
 7was a good idea to have this in place sooner rather than later:
 8
 9I want to provide a safe, healthy environment for all contributors/participants
10regardless of gender, sexual orientation, disability, race, religion, etc.
11As such, I don't tolerate harassment of participants in any form. In particular
12this applies to my issues tracker, but also to any other means of communication
13associated with this project that might come up. Anyone who violates these
14basic rules may be sanctioned/banned/have-their-comments-deleted/etc by my
15discretion.
16
17Glad we cleared that up.
18
19## Branching
20
21Before working on your fix/feature/whatever, you should create a new branch to
22work on. Do something like:
23
24```sh
25$ git checkout -b 'my-sweet-new-pull-request'
26```
27
28## Please Please Please Start With A Test
29
30ecstatic has some pretty gnarly branching/logic underneath. Tests are extremely
31important because they (a) prove that your feature/fix works, and (b) avoid
32regressions in the future. Even if your patch is problematic enough to not be
33merged, a test will still be very helpful for confirming any future fix.
34
35I won't reject your patch outright if it's missing new tests, but it sure
36helps!
37
38## Code Style
39
40Ecstatic's code base follows a relatively consistent style. The closer your
41patch blends in with the status quo, the better.
42
43A few PROTIPS off the top of my head:
44
451. Variables don't need to all be declared at the top, BUT variable *blocks*
46should do the whole one-var, tons-of-commas thing.
472. Look at how spacing is done around conditionals and functions. Do it like
48that. 
493. `else`'s and similar should be on the line *after* the preceding bracket.
50
51We can refine this as the need arises.
52
53## A Few Other Minor Guidelines
54
551. Keep your pull requests on-topic. A pull request purporting to tackle A
56shouldn't also have commits changing B and C. Feel free to make separate pull
57requests. For instance: A pull request should generally only update
58dependencies when doing so is required to add the feature or fix the bug. This
59feature can, of course, consist of updating dependencies.
602. I prefer maintaining the changelog and package.json version myself. This is
61because I try to make a single commit for a tagged release contain all
62changelog additions and the version bump, and this breaks down when there are
63interstitial commits making updates to either.
643. In case you were wondering about dependencies, you may find this helpful:
65[![dependencies status](https://david-dm.org/jfhbrook/node-ecstatic.svg)](https://david-dm.org/jfhbrook/node-ecstatic)
664. Please add yourself to CONTRIBUTORS.md if you haven't done so! Fill in as
67much as makes you comfortable.
68
69## Pull Request
70
71Make a pull request against master with your new branch. Explain briefly what
72the patch does to the code, along with any concerns.
73
74(If you don't have a description, it's hard for me to put the changes in
75context. That makes it more difficult for me to merge!)
76
77## Keep It Moving
78
79I don't always notice new PRs, and sometimes I will forget to follow up on
80them. If this happens to you, you can bump the PR thread or find me on
81IRC or twitter.
82
83## LAST RULE
84
85HAVE FUN :v :v
86