|
| 1 | +# Contribution Guidelines |
| 2 | + |
| 3 | +Before opening any issues or proposing any pull requests, please read |
| 4 | +our [Contributor's Guide](https://requests.readthedocs.io/en/latest/dev/contributing/). |
| 5 | + |
| 6 | +To get the greatest chance of helpful responses, please also observe the |
| 7 | +following additional notes. |
| 8 | + |
| 9 | +## Questions |
| 10 | + |
| 11 | +The GitHub issue tracker is for *bug reports* and *feature requests*. Please do |
| 12 | +not use it to ask questions about how to use Requests. These questions should |
| 13 | +instead be directed to [Stack Overflow](https://stackoverflow.com/). Make sure |
| 14 | +that your question is tagged with the `python-requests` tag when asking it on |
| 15 | +Stack Overflow, to ensure that it is answered promptly and accurately. |
| 16 | + |
| 17 | +## Good Bug Reports |
| 18 | + |
| 19 | +Please be aware of the following things when filing bug reports: |
| 20 | + |
| 21 | +1. Avoid raising duplicate issues. *Please* use the GitHub issue search feature |
| 22 | + to check whether your bug report or feature request has been mentioned in |
| 23 | + the past. Duplicate bug reports and feature requests are a huge maintenance |
| 24 | + burden on the limited resources of the project. If it is clear from your |
| 25 | + report that you would have struggled to find the original, that's ok, but |
| 26 | + if searching for a selection of words in your issue title would have found |
| 27 | + the duplicate then the issue will likely be closed extremely abruptly. |
| 28 | +2. When filing bug reports about exceptions or tracebacks, please include the |
| 29 | + *complete* traceback. Partial tracebacks, or just the exception text, are |
| 30 | + not helpful. Issues that do not contain complete tracebacks may be closed |
| 31 | + without warning. |
| 32 | +3. Make sure you provide a suitable amount of information to work with. This |
| 33 | + means you should provide: |
| 34 | + |
| 35 | + - Guidance on **how to reproduce the issue**. Ideally, this should be a |
| 36 | + *small* code sample that can be run immediately by the maintainers. |
| 37 | + Failing that, let us know what you're doing, how often it happens, what |
| 38 | + environment you're using, etc. Be thorough: it prevents us needing to ask |
| 39 | + further questions. |
| 40 | + - Tell us **what you expected to happen**. When we run your example code, |
| 41 | + what are we expecting to happen? What does "success" look like for your |
| 42 | + code? |
| 43 | + - Tell us **what actually happens**. It's not helpful for you to say "it |
| 44 | + doesn't work" or "it fails". Tell us *how* it fails: do you get an |
| 45 | + exception? A hang? A non-200 status code? How was the actual result |
| 46 | + different from your expected result? |
| 47 | + - Tell us **what version of Requests you're using**, and |
| 48 | + **how you installed it**. Different versions of Requests behave |
| 49 | + differently and have different bugs, and some distributors of Requests |
| 50 | + ship patches on top of the code we supply. |
| 51 | + |
| 52 | + If you do not provide all of these things, it will take us much longer to |
| 53 | + fix your problem. If we ask you to clarify these and you never respond, we |
| 54 | + will close your issue without fixing it. |
0 commit comments