Skip to content

Latest commit

 

History

History
84 lines (66 loc) · 3.74 KB

contributing.md

File metadata and controls

84 lines (66 loc) · 3.74 KB
Raw

Contributing

Checklist:

  • New code is covered by new tests and documentation.
  • Tests pass
  • jsl returns checked n; OK when run on every changed file.
  • package.json contains all new dependencies you introduced.
  • Your PR includes a description of your changes.

So you want to contribute...

In the issue tracker, enhancement requests and known bugs are listed according to the order in which they were reported. If you want to work on one of these, please leave a comment so that others do not duplicate your effort.

If you are uncertain how to proceed, feel free to comment on the issue with a development plan you intend to follow. The maintainers will review it and provide guidance as requested or required. If there is a new feature you would like to see, open a new issue, and describe the feature in English. Providing a sample API for the new feature is also very helpful.

Before you start coding against μnpm, ask yourself if the feature could live as a stand alone library or script. If it can, create new repository for the project. When you are ready, publish it to npm. Then submit a PR which updates μnpm's package.json to include the new dependency, and update the appropriate modules.

You've written code to address the issue...

All contributions should made via pull request and review. After a pull request is made other contributors will offer feedback. They will approve your changes by leaving a +1 or an emoji as a comment on the PR. Once you have two +1s from two different maintainers, your changes will be merged.

If you've never made a PR before, you'll need to create a GitHub account, and read up on GitHub's instructions on forking and pull requests. Reading up on the git source control management system could also be helpful.

Pull requests should be targeted at μnpm's master branch. Before pushing to your GitHub repo and issuing the pull request, please run the full test suite with the npm test command. It is your responsibility to fix any test failures before asking for review. If you introduce code without tests, be prepared to justify why it does not or cannot be tested.

If you have modified the API, make sure to update the documentation accordingly. Make a note of the API in the PR description so the maintainers can update the semantic version appropriately.

We expect your code to pass our style guide, handily encoded by the javascript library, jsl. This is enforced by a test which runs the linter on all code which can be required from the entry point, ./index.js.

It is still up to you to verify any style on scripts, tests, or commands you add. Before submitting your PR, npm install -g jsl, and then run jsl on all such files you have changed. If it exits with a non-zero status code, expect the maintainers to correct your style.

We will also review the substance of your code. Our philosophy is roughly:

Conduct

We operate under the Speak Up! project's code of conduct.

Communication

There is an IRC channel on irc.freenode.net called #unpm. You're welcome to drop in and ask questions, discuss bugs and possible feature development, or just hang out <3