Initial commit

Author: suryavaddiraju

.github/CODEOWNERS

@@ -0,0 +1 @@
+*  @suryavaddiraju

.github/CODE_OF_CONDUCT.md

@@ -0,0 +1,128 @@
+# Contributor Covenant Code of Conduct
+
+## Our Pledge
+
+We as members, contributors, and leaders pledge to make participation in our
+community a harassment-free experience for everyone, regardless of age, body
+size, visible or invisible disability, ethnicity, sex characteristics, gender
+identity and expression, level of experience, education, socio-economic status,
+nationality, personal appearance, race, religion, or sexual identity
+and orientation.
+
+We pledge to act and interact in ways that contribute to an open, welcoming,
+diverse, inclusive, and healthy community.
+
+## Our Standards
+
+Examples of behavior that contributes to a positive environment for our
+community include:
+
+* Demonstrating empathy and kindness toward other people
+* Being respectful of differing opinions, viewpoints, and experiences
+* Giving and gracefully accepting constructive feedback
+* Accepting responsibility and apologizing to those affected by our mistakes,
+  and learning from the experience
+* Focusing on what is best not just for us as individuals, but for the
+  overall community
+
+Examples of unacceptable behavior include:
+
+* The use of sexualized language or imagery, and sexual attention or
+  advances of any kind
+* Trolling, insulting or derogatory comments, and personal or political attacks
+* Public or private harassment
+* Publishing others' private information, such as a physical or email
+  address, without their explicit permission
+* Other conduct which could reasonably be considered inappropriate in a
+  professional setting
+
+## Enforcement Responsibilities
+
+Community leaders are responsible for clarifying and enforcing our standards of
+acceptable behavior and will take appropriate and fair corrective action in
+response to any behavior that they deem inappropriate, threatening, offensive,
+or harmful.
+
+Community leaders have the right and responsibility to remove, edit, or reject
+comments, commits, code, wiki edits, issues, and other contributions that are
+not aligned to this Code of Conduct, and will communicate reasons for moderation
+decisions when appropriate.
+
+## Scope
+
+This Code of Conduct applies within all community spaces, and also applies when
+an individual is officially representing the community in public spaces.
+Examples of representing our community include using an official e-mail address,
+posting via an official social media account, or acting as an appointed
+representative at an online or offline event.
+
+## Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be
+reported to the community leaders responsible for enforcement at
+https://dev.vaddiraju.in/contact.
+All complaints will be reviewed and investigated promptly and fairly.
+
+All community leaders are obligated to respect the privacy and security of the
+reporter of any incident.
+
+## Enforcement Guidelines
+
+Community leaders will follow these Community Impact Guidelines in determining
+the consequences for any action they deem in violation of this Code of Conduct:
+
+### 1. Correction
+
+**Community Impact**: Use of inappropriate language or other behavior deemed
+unprofessional or unwelcome in the community.
+
+**Consequence**: A private, written warning from community leaders, providing
+clarity around the nature of the violation and an explanation of why the
+behavior was inappropriate. A public apology may be requested.
+
+### 2. Warning
+
+**Community Impact**: A violation through a single incident or series
+of actions.
+
+**Consequence**: A warning with consequences for continued behavior. No
+interaction with the people involved, including unsolicited interaction with
+those enforcing the Code of Conduct, for a specified period of time. This
+includes avoiding interactions in community spaces as well as external channels
+like social media. Violating these terms may lead to a temporary or
+permanent ban.
+
+### 3. Temporary Ban
+
+**Community Impact**: A serious violation of community standards, including
+sustained inappropriate behavior.
+
+**Consequence**: A temporary ban from any sort of interaction or public
+communication with the community for a specified period of time. No public or
+private interaction with the people involved, including unsolicited interaction
+with those enforcing the Code of Conduct, is allowed during this period.
+Violating these terms may lead to a permanent ban.
+
+### 4. Permanent Ban
+
+**Community Impact**: Demonstrating a pattern of violation of community
+standards, including sustained inappropriate behavior,  harassment of an
+individual, or aggression toward or disparagement of classes of individuals.
+
+**Consequence**: A permanent ban from any sort of public interaction within
+the community.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant][homepage],
+version 2.0, available at
+https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
+
+Community Impact Guidelines were inspired by [Mozilla's code of conduct
+enforcement ladder](https://github.com/mozilla/diversity).
+
+[homepage]: https://www.contributor-covenant.org
+
+For answers to common questions about this code of conduct, see the FAQ at
+https://www.contributor-covenant.org/faq. Translations are available at
+https://www.contributor-covenant.org/translations.

.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 @aws-sdk/{repoName}. These questions should
+instead be directed to [Stack Overflow](https://stackoverflow.com/). Make sure
+that your question is tagged with the `javascript & api & aws-sdk` 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.

.github/FUNDING.yml

@@ -0,0 +1 @@
+github: [suryavaddiraju]

.github/SECURITY.md

@@ -0,0 +1,104 @@
+# Security Policy
+
+This sections helps users how to report security issues privately.
+
+## Supported Versions
+
+versions of the project that are currently being supported with security updates.
+
+| Version | Supported          |
+| ------- | ------------------ |
+| 3.x.x   | :white_check_mark: |
+| 2.0.x   | :x:                |
+| 1.0.x   | :x:                |
+
+## Vulnerability Disclosure
+
+If you think you have found a potential security vulnerability in
+requests, please email [Vaddiraju Surya Teja](mailto:suryavaddiraju@proton.me)
+and [Vaddiraju Rama Narasimha](mailto:vaddiraju.ramanarasimha@gmail.com) directly.
+
+**Do not file a public issue.**
+
+Our PGP Key fingerprints are:
+- ASAt 7xmp EQhK boIl zSb0 D9Fa n15c 1U9S wN4lb sVEVN HH3go ([suryavaddiraju](https://keybase.io/suryavaddiraju))
+
+You can also contact us on [Keybase](https://keybase.io) with the
+profiles above if desired.
+
+If English is not your first language, please try to describe the
+problem and its impact to the best of your ability. For greater detail,
+please use your native language and we will try our best to translate it
+using online services.
+
+Please also include the code you used to find the problem and the
+shortest amount of code necessary to reproduce it.
+
+Please do not disclose this to anyone else. We will retrieve a CVE
+identifier if necessary and give you full credit under whatever name or
+alias you provide. We will only request an identifier when we have a fix
+and can publish it in a release.
+
+We will respect your privacy and will only publicize your involvement if
+you grant us permission.
+
+## Process
+
+This following information discusses the process the requests project
+follows in response to vulnerability disclosures. If you are disclosing
+a vulnerability, this section of the documentation lets you know how we
+will respond to your disclosure.
+
+### Timeline
+
+When you report an issue, one of the project members will respond to you
+within two days *at the outside*. In most cases responses will be
+faster, usually within 12 hours. This initial response will at the very
+least confirm receipt of the report.
+
+If we were able to rapidly reproduce the issue, the initial response
+will also contain confirmation of the issue. If we are not, we will
+often ask for more information about the reproduction scenario.
+
+Our goal is to have a fix for any vulnerability released within two
+weeks of the initial disclosure. This may potentially involve shipping
+an interim release that simply disables function while a more mature fix
+can be prepared, but will in the vast majority of cases mean shipping a
+complete release as soon as possible.
+
+Throughout the fix process we will keep you up to speed with how the fix
+is progressing. Once the fix is prepared, we will notify you that we
+believe we have a fix. Often we will ask you to confirm the fix resolves
+the problem in your environment, especially if we are not confident of
+our reproduction scenario.
+
+At this point, we will prepare for the release. We will obtain a CVE
+number if one is required, providing you with full credit for the
+discovery. We will also decide on a planned release date, and let you
+know when it is. This release date will *always* be on a weekday.
+
+At this point we will reach out to our major downstream packagers to
+notify them of an impending security-related patch so they can make
+arrangements. In addition, these packagers will be provided with the
+intended patch ahead of time, to ensure that they are able to promptly
+release their downstream packages. Currently the list of people we
+actively contact *ahead of a public release* is:
+
+-   Vaddiraju Surya Teja, Node (@suryavaddiraju)
+
+We will notify these individuals at least a week ahead of our planned
+release date to ensure that they have sufficient time to prepare. If you
+believe you should be on this list, please let one of the maintainers
+know at one of the email addresses at the top of this article.
+
+On release day, we will push the patch to our public repository, along
+with an updated changelog that describes the issue and credits you. We
+will then issue a npm release containing the patch.
+
+At this point, we will publicise the release. This will involve mails to
+mailing lists, Tweets, and all other communication mechanisms available
+to the core team.
+
+We will also explicitly mention which commits contain the fix to make it
+easier for other distributors and users to easily patch their own
+versions of requests if upgrading is not an option.

.github/workflows/build.yml

@@ -0,0 +1,19 @@
+name: Create jsdeliver index.min.mjs script
+on:
+  workflow_dispatch:
+jobs:
+  build:
+    runs-on: ubuntu-latest
+    permissions:
+      contents: write
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with:
+          node-version: 'lts/*'
+      - name: Run Node.JS Script
+        run: node setup.mjs
+        env:
+          GPG_KEY: ${{ secrets.GPG_KEY }}
+          GPG_KEY_ID: ${{ secrets.GPG_KEY_ID }}
+          GITHUB_TOKEN: ${{ github.token }}