Contributing to Request
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.
Submitting an Issue
- 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:
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).
Submitting a Pull Request
- In almost all of the cases your PR needs tests. Make sure you have any.
npm testlocally. 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.
Becoming a Contributor
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:
--forcepushes 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.
npm testlocally 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.
Changes to this arrangement
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.