Contributing to Request

👍🎉 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.

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:

  ```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).

Submitting a Pull Request

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.

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.

Rules

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:
- node_modules/.bin/taper tests/test-file.js - run using the default taper test reporter.
- node tests/test-file.js - view the raw tap output.

Releases

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.

3.2 KiB Raw Blame History