| 1 |
|
| 2 | # Contributing to Request
|
| 3 |
|
| 4 | :+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
|
| 5 |
|
| 6 | The following is a set of guidelines for contributing to Request and its packages, which are hosted in the [Request Organization](https://github.com/request) on GitHub.
|
| 7 | These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
|
| 8 |
|
| 9 |
|
| 10 | ## Submitting an Issue
|
| 11 |
|
| 12 | 1. Provide a small self **sufficient** code example to **reproduce** the issue.
|
| 13 | 2. Run your test code using [request-debug](https://github.com/request/request-debug) and copy/paste the results inside the issue.
|
| 14 | 3. You should **always** use fenced code blocks when submitting code examples or any other formatted output:
|
| 15 | <pre>
|
| 16 | ```js
|
| 17 | put your javascript code here
|
| 18 | ```
|
| 19 |
|
| 20 | ```
|
| 21 | put any other formatted output here,
|
| 22 | like for example the one returned from using request-debug
|
| 23 | ```
|
| 24 | </pre>
|
| 25 |
|
| 26 | If the problem cannot be reliably reproduced, the issue will be marked as `Not enough info (see CONTRIBUTING.md)`.
|
| 27 |
|
| 28 | If the problem is not related to request the issue will be marked as `Help (please use Stackoverflow)`.
|
| 29 |
|
| 30 |
|
| 31 | ## Submitting a Pull Request
|
| 32 |
|
| 33 | 1. In almost all of the cases your PR **needs tests**. Make sure you have any.
|
| 34 | 2. Run `npm test` locally. Fix any errors before pushing to GitHub.
|
| 35 | 3. After submitting the PR a build will be triggered on TravisCI. Wait for it to ends and make sure all jobs are passing.
|
| 36 |
|
| 37 |
|
| 38 | -----------------------------------------
|
| 39 |
|
| 40 |
|
| 41 | ## Becoming a Contributor
|
| 42 |
|
| 43 | Individuals making significant and valuable contributions are given
|
| 44 | commit-access to the project to contribute as they see fit. This project is
|
| 45 | more like an open wiki than a standard guarded open source project.
|
| 46 |
|
| 47 |
|
| 48 | ## Rules
|
| 49 |
|
| 50 | There are a few basic ground-rules for contributors:
|
| 51 |
|
| 52 | 1. **No `--force` pushes** or modifying the Git history in any way.
|
| 53 | 1. **Non-master branches** ought to be used for ongoing work.
|
| 54 | 1. **Any** change should be added through Pull Request.
|
| 55 | 1. **External API changes and significant modifications** ought to be subject
|
| 56 | to an **internal pull-request** to solicit feedback from other contributors.
|
| 57 | 1. Internal pull-requests to solicit feedback are *encouraged* for any other
|
| 58 | non-trivial contribution but left to the discretion of the contributor.
|
| 59 | 1. For significant changes wait a full 24 hours before merging so that active
|
| 60 | contributors who are distributed throughout the world have a chance to weigh
|
| 61 | in.
|
| 62 | 1. Contributors should attempt to adhere to the prevailing code-style.
|
| 63 | 1. Run `npm test` locally before submitting your PR, to catch any easy to miss
|
| 64 | style & testing issues. To diagnose test failures, there are two ways to
|
| 65 | run a single test file:
|
| 66 | - `node_modules/.bin/taper tests/test-file.js` - run using the default
|
| 67 | [`taper`](https://github.com/nylen/taper) test reporter.
|
| 68 | - `node tests/test-file.js` - view the raw
|
| 69 | [tap](https://testanything.org/) output.
|
| 70 |
|
| 71 |
|
| 72 | ## Releases
|
| 73 |
|
| 74 | Declaring formal releases remains the prerogative of the project maintainer.
|
| 75 |
|
| 76 |
|
| 77 | ## Changes to this arrangement
|
| 78 |
|
| 79 | This is an experiment and feedback is welcome! This document may also be
|
| 80 | subject to pull-requests or changes by contributors where you believe you have
|
| 81 | something valuable to add or change.
|
| 82 | |
| \ | No newline at end of file |