Code change:
<del> # Contributors Guide </del> <ins> # Contributor's Guide </ins> ## I want to help! We welcome pull requests from Free Code Camp campers (our students) and seasoned JavaScript developers alike! Follow these steps to contribute: <del> 1.  Check our [public Waffle Board](https://waffle.io/freecodecamp/freecodecamp). 2.  Pick an issue, let us know you're working on it, and start working on it. If you've found a bug that is not on the board, [follow these steps](#found-a-bug). 3.  You can find issues we are seeking assistance on by searching for the [Help Wanted](https://github.com/FreeCodeCamp/FreeCodeCamp/labels/help%20wanted) tag. 4.  Feel free to ask for help in our [Help Contributors](https://gitter.im/FreeCodeCamp/HelpContributors) Gitter room. </del> <ins> 1.  Find an issue that needs assistance by searching for the [Help Wanted](https://github.com/FreeCodeCamp/FreeCodeCamp/labels/help%20wanted) tag. 2.  Let us know you are working on it, by posting a comment on the issue. 3.  Feel free to ask for help in our [Help Contributors](https://gitter.im/FreeCodeCamp/HelpContributors) Gitter room. If you've found a bug that is not on the board, [follow these steps](#found-a-bug). </ins> ## Contribution Guidelines 1.  Fork the project: [How To Fork And Maintain a Local Instance of Free Code Camp](https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/How-To-Fork-And-Maintain-a-Local-Instance-of-Free-Code-Camp) 2.  Create a branch specific to the issue or feature you are working on. Push your work to that branch. ([Need help with branching?](https://github.com/Kunena/Kunena-Forum/wiki/Create-a-new-branch-with-git-and-manage-branches)) 3.  Name the branch something like `fix/xxx` or `feature/xxx` where `xxx` is a short description of the changes or feature you are attempting to add. For example `fix/email-login` would be a branch where I fix something specific to email login. <del> 4.  You should have [ESLint running in your editor](http://eslint.org/docs/user-guide/integrations.html), and it will highlight anything doesn't conform to [Free Code Camp's JavaScript Style Guide](https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/Free-Code-Camp-JavaScript-Style-Guide) (you can find a summary of those rules [here](https://github.com/FreeCodeCamp/FreeCodeCamp/blob/staging/.eslintrc). Please do not ignore any linting errors, as they are meant to **help** you and to ensure a clean and simple code base. Make sure none of your JavaScript is longer than 80 characters per line. </del> <ins> 4. [Set up Linting](#linting-setup) to run as you make changes. 5. When you are ready to share your code, run the test suite `npm test` and ensure all tests pass.  For Windows contributors, skip the jsonlint pretest run by using `npm run test-challenges`, as jsonlint will always fail on Windows, given the wildcard parameters. </ins> 5.  Squash your Commits. Ref: [rebasing](https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/git-rebase) <del> 6.  Once your code is ready, submit a [pull request](https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/Pull-Request-Contribute) from your branch to Free Code Camp's `staging` branch. We'll do a quick code review and give you feedback, then iterate from there. </del> <ins> 6.  Submit a [pull request](https://github.com/FreeCodeCamp/FreeCodeCamp/wiki/Pull-Request-Contribute) from your branch to Free Code Camp's `staging` branch.  [Travis CI](https://travis-ci.org/FreeCodeCamp/FreeCodeCamp) will then take your code and run `npm test`.  Make sure this passes, then we'll do a quick code review and give you feedback, then iterate from there. </ins> Prerequisites

Related discussion:
text: I'm a new contributor to this project and have run into a few confusing points on that I'd like to clarify for other new contributors. .io - From a few other contributors, I've been told this is no longer used. I'd suggest removing this from the contributor's guide. npm dependencies. This project has a dependency to which is confusing to set up for new NodeJs developers. I'd propose to mention this link to get new Node developers started, especially for Windows, since it involves some unusual installations like Visual Studio for the C++ compiler. isn't any mention of running tests before submitting a pull request. This is something that could be easily missed and cause a pull request to fail the TravisCI build. I've learned that one pre-test dependency, JSONLint, doesn't work for the Windows filesystem. As a workaround, I'd suggest all contributors on Windows to run the tests directly by skipping the pre-test lint run. An additional step could be to manually run JSONLint on individual files, without using the problem-causing wildcard *. For non-Windows contributors, it should be mandatory to run before a pull request.
These all sound like reasonable changes. Go ahead and get a PR going for it.
I'll get started on it.