👍🎉 First off, thanks for taking the time to contribute! 🎉👍
The following is a set of guidelines for contributing to Request and its packages, which are hosted in the Request Organization on GitHub. These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
- Provide a small self sufficient code example to reproduce the issue.
- Run your test code using request-debug and copy/paste the results inside the issue.
- You should always use fenced code blocks when submitting code examples or any other formatted output:
```js put your javascript code here ``` ``` put any other formatted output here, like for example the one returned from using request-debug ```
If the problem cannot be reliably reproduced, the issue will be marked as Not enough info (see CONTRIBUTING.md)
.
If the problem is not related to request the issue will be marked as Help (please use Stackoverflow)
.
- In almost all of the cases your PR needs tests. Make sure you have any.
- Run
npm test
locally. Fix any errors before pushing to GitHub. - After submitting the PR a build will be triggered on TravisCI. Wait for it to ends and make sure all jobs are passing.
Individuals making significant and valuable contributions are given commit-access to the project to contribute as they see fit. This project is more like an open wiki than a standard guarded open source project.
There are a few basic ground-rules for contributors:
- No
--force
pushes or modifying the Git history in any way. - Non-master branches ought to be used for ongoing work.
- Any change should be added through Pull Request.
- External API changes and significant modifications ought to be subject to an internal pull-request to solicit feedback from other contributors.
- Internal pull-requests to solicit feedback are encouraged for any other non-trivial contribution but left to the discretion of the contributor.
- For significant changes wait a full 24 hours before merging so that active contributors who are distributed throughout the world have a chance to weigh in.
- Contributors should attempt to adhere to the prevailing code-style.
- Run
npm test
locally before submitting your PR, to catch any easy to miss style & testing issues. To diagnose test failures, there are two ways to run a single test file:
Declaring formal releases remains the prerogative of the project maintainer.
This package uses semantic versioning and semantic-release to auto-publish releases to npm upon merge into the master branch.
This is an experiment and feedback is welcome! This document may also be subject to pull-requests or changes by contributors where you believe you have something valuable to add or change.