node-query/node_modules/jsdoc/CONTRIBUTING.md

Pull Requests
-------------

If you're thinking about making some changes, maybe fixing a bug, or adding a
snazzy new feature, first, thank you.  Contributions are very welcome.  Things
need to be manageable for the maintainers, however. So below you'll find  **The
fastest way to get your pull request merged in.**  Some things, particularly how
you set up your branches and work with git, are just suggestions, but pretty good
ones.

1. **Create a remote to track the base jsdoc3/jsdoc repository**
   This is just a convenience to make it easier to update your ```<tracking branch>```
   (more on that shortly).  You would execute something like:

        git remote add base git://github.com/jsdoc3/jsdoc.git

   Here 'base' is the name of the remote.  Feel free to use whatever you want.

2. **Set up a tracking branch for the base repository**
   We're gonna call this your ```<tracking branch>```.  You will only ever update
   this branch by pulling from the 'base' remote. (as opposed to 'origin')

        git branch --track pullpost base/master
        git checkout pullpost

   Here 'pullpost' is the name of the branch.  Fell free to use whatever you want.

3. **Create your change branch**
   Once you are in ```<tracking branch>```, make sure it's up to date, then create
   a branch for your changes off of that one.

        git branch fix-for-issue-395
        git checkout fix-for-issue-395

   Here 'fix-for-issue-395' is the name of the branch.  Feel free to use whatever
   you want.  We'll call this the ```<change branch>```.  This is the branch that
   you will eventually issue your pull request from.

   The purpose of these first three steps is to make sure that your merge request
   has a nice clean diff that only involves the changes related to your fix/feature.

4. **Make your changes**
   On your ```<change branch>``` make any changes relevant to your fix/feature.  Don't
   group fixes for multiple unrelated issues or multiple unrelated features together.
   Create a separate branch for each unrelated changeset.  For instance, if you're
   fixing a bug in the parser and adding some new UI to the default template, those
   should be separate branches and merge requests.

5. **Add tests**
   Add tests for your change.  If you are submitting a bugfix, include a test that
   verifies the existence of the bug along with your fix.  If you are submitting
   a new feature, include tests that verify proper feature function, if applicable.
   See the readme in the 'test' directory for more information

6. **Commit and publish**
   Commit your changes and publish your branch (or push it if it's already published)

7. **Issue your pull request**
   On github.com, switch to your ```<change branch>``` and click the 'Pull Request'
   button.  Enter some meaningful information about the pull request.  If it's a bugfix,
   that doesn't already have an issue associated with it, provide some info on what
   situations that bug occurs in and a sense of it's severity.  If it does already have
   an issue, make sure the include the hash and issue number (e.g. '#100') so github
   links it.

   If it's a feature, provide some context about the motivations behind the feature,
   why it's important/useful/cool/necessary and what it does/how it works.  Don't
   worry about being too verbose. Folks will be much more amenable to reading through
   your code if they know what its supposed to be about.