From eb1030f1065c0b0de3ffa143f6669dfbc0129e91 Mon Sep 17 00:00:00 2001 From: Vaddiraju Surya Teja <112264612+suryavaddiraju@users.noreply.github.com> Date: Wed, 1 May 2024 19:35:25 +0530 Subject: [PATCH] Create CONTRIBUTING.md --- .github/CONTRIBUTING.md | 54 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 54 insertions(+) create mode 100644 .github/CONTRIBUTING.md diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 0000000..14d6bd2 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,54 @@ +# Contribution Guidelines + +Before opening any issues or proposing any pull requests, please read +our [Contributor's Guide](https://dev.vaddiraju.in/irctc-api/contribution). + +To get the greatest chance of helpful responses, please also observe the +following additional notes. + +## Questions + +The GitHub issue tracker is for *bug reports* and *feature requests*. Please do +not use it to ask questions about how to use Requests. These questions should +instead be directed to [Stack Overflow](https://stackoverflow.com/). Make sure +that your question is tagged with the `node-irctc-api` tag when asking it on +Stack Overflow, to ensure that it is answered promptly and accurately. + +## Good Bug Reports + +Please be aware of the following things when filing bug reports: + +1. Avoid raising duplicate issues. *Please* use the GitHub issue search feature + to check whether your bug report or feature request has been mentioned in + the past. Duplicate bug reports and feature requests are a huge maintenance + burden on the limited resources of the project. If it is clear from your + report that you would have struggled to find the original, that's ok, but + if searching for a selection of words in your issue title would have found + the duplicate then the issue will likely be closed extremely abruptly. +2. When filing bug reports about exceptions or tracebacks, please include the + *complete* traceback. Partial tracebacks, or just the exception text, are + not helpful. Issues that do not contain complete tracebacks may be closed + without warning. +3. Make sure you provide a suitable amount of information to work with. This + means you should provide: + + - Guidance on **how to reproduce the issue**. Ideally, this should be a + *small* code sample that can be run immediately by the maintainers. + Failing that, let us know what you're doing, how often it happens, what + environment you're using, etc. Be thorough: it prevents us needing to ask + further questions. + - Tell us **what you expected to happen**. When we run your example code, + what are we expecting to happen? What does "success" look like for your + code? + - Tell us **what actually happens**. It's not helpful for you to say "it + doesn't work" or "it fails". Tell us *how* it fails: do you get an + exception? A hang? A non-200 status code? How was the actual result + different from your expected result? + - Tell us **what version of Requests you're using**, and + **how you installed it**. Different versions of Requests behave + differently and have different bugs, and some distributors of Requests + ship patches on top of the code we supply. + + If you do not provide all of these things, it will take us much longer to + fix your problem. If we ask you to clarify these and you never respond, we + will close your issue without fixing it.