The only "official" Node Inspector repository is https://github.com/node-inspector/node-inspector. For code, docs, tests, or anything else, node-inspector/node-inspector is the repository where all patches have to end up if they are going to be in the release. To submit a patch fork the repository and send a pull request via github to node-inspector/node-inspector.

• Miguel de Icaza has a good post on Open Source Contribution Etiquette that is worth reading, as the guidance he gives applies well to Node Inspector.
• Create a github issue for large changes and discuss the change there before coding
• Javascript code style should follow Google's JavaScript style guide and be run through the linter. npm run lint to validate, you need to have GJsLint installed.

Node Inspector comes with an automated test suite run via "npm test". The tests are written in BDD style using mocha and chai.

Commit messages should follow follow 50/72 format, i.e.

• First line is 50 characters or less and summarises the commit
• Then a blank line
• Remaining text should be wrapped at 72 characters and provide longer/additional information.

Commits must have the author field properly filled out with your name and email address.

Use GitHub Flow for your work on Node Inspector:

1. Clone the git repository.
2. Create a branch for you change/feature off of the master branch.
3. Make your change. Remember to update tests as well as code!
4. Commit your change and push it to github.
5. Use github's pull requests to submit the patch.

Once you have submitted a pull request, Node Inspector maintainers will review the changes. More often than not, some of your code needs to be improved before the patch is accepted.

You don't have to create a new pull request to update your patch. Simply add more commits to your branch, github will automatically add them to the pull request. This way it's also easier to know what has been changed from the last review, which makes the life of maintainers much easier.

When all issues are resolved and the code is good to merge, you can squash the commits to keep the history concise. Google for git rebase interactive to learn how to clean up your git history.

Note that after the history was rewritten, git push will be rejected by the git server. Don't worry about that, just tell git to push it anyway: git push -f.