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