docs: add contributor resources + a tox.ini

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1 @@
+blank_issues_enabled: false

CODE_OF_CONDUCT.md

@@ -0,0 +1,58 @@
+# Code of Conduct
+
+## 1. Purpose
+
+A primary goal of aws_openai is to be inclusive to the largest number of contributors, with the most varied and diverse backgrounds possible. As such, we are committed to providing a friendly, safe and welcoming environment for all, regardless of gender, sexual orientation, ability, ethnicity, socioeconomic status, and religion (or lack thereof).
+
+This code of conduct outlines our expectations for all those who participate in our community, as well as the consequences for unacceptable behavior.
+
+We invite all those who participate in aws_openai to help us create safe and positive experiences for everyone.
+
+## 2. Open Source Citizenship
+
+A supplemental goal of this Code of Conduct is to increase open source citizenship by encouraging participants to recognize and strengthen the relationships between our actions and their effects on our community.
+
+Communities mirror the societies in which they exist and positive action is essential to counteract the many forms of inequality and abuses of power that exist in society.
+
+## 3. Expected Behavior
+
+The following behaviors are expected and requested of all community members:
+
+- Participate in an authentic and active way. In doing so, you contribute to the health and longevity of this community.
+- Exercise consideration and respect in your speech and actions.
+- Attempt collaboration before conflict.
+- Refrain from demeaning, discriminatory, or harassing behavior and speech.
+- Be mindful of your surroundings and of your fellow participants. Alert community leaders if you notice a dangerous situation, someone in distress, or violations of this Code of Conduct, even if they seem inconsequential.
+
+## 4. Unacceptable Behavior
+
+The following behaviors are considered harassment and are unacceptable within our community:
+
+- Violence, threats of violence or violent language directed against another person.
+- Sexist, racist, homophobic, transphobic, ableist or otherwise discriminatory jokes and language.
+- Posting or displaying sexually explicit or violent material.
+- Posting or threatening to post other people’s personally identifying information ("doxing").
+- Personal insults, particularly those related to gender, sexual orientation, race, religion, or disability.
+- Inappropriate photography or recording.
+- Inappropriate physical contact. You should have someone’s consent before touching them.
+- Unwelcome sexual attention. This includes, sexualized comments or jokes; inappropriate touching, groping, and unwelcomed sexual advances.
+
+## 5. Enforcement
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at [[email protected]](mailto:[email protected]). All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
+
+Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
+
+## 6. Scope
+
+This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
+
+## 7. Our Responsibilities
+
+Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
+
+Project maintainers 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, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant](https://www.contributor-covenant.org/), version 1.4, available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct.html).

SEMANTIC_VERSIONING.md

@@ -0,0 +1,34 @@
+# Semantic Versioning Guide
+
+See [Conventional Commits](https://www.conventionalcommits.org/)
+
+The [release.yml](.github/workflows/release.yml), [checkPullRequest.yml](.github/workflows/checkPullRequest.yml) and [testRelease.yml](.github/workflows/testRelease.yml) Github Action Workflows in this repo are designed to act on the commit comment rules that follow.
+
+As an open-source maintainer, squash feature branches onto master and write a standardized commit message while doing so. The commit message should be structured as follows:
+
+> `<type>`: This represents the type of change made in the commit. Common types include feat (for a new feature), fix (for a bug fix), chore (for routine tasks like updating dependencies), docs (for documentation changes), style (for code style changes), refactor (for refactoring existing code), test (for adding or updating tests), and perf (for performance improvements).
+>
+> `[optional scope]`: This is an optional part that provides additional contextual information, like the part of the codebase the commit modifies.
+>
+> `<description>`: This is a brief description of the changes the commit makes.
+>
+> `[optional body]`: This is an optional part where you can provide a more detailed explanation of the changes.
+>
+> `[optional footer(s)]`: This is also optional and is often used to reference issue tracker IDs.
+
+## Commit Message format
+
+- `feat`: A new feature
+- `fix`: A bug fix
+- `docs`: Documentation only changes
+- `style`: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+- `refactor`: A code change that neither fixes a bug nor adds a feature
+- `perf`: A code change that improves performance
+- `test`: Adding missing or correcting existing tests
+- `chore`: Changes to the build process or auxiliary tools and libraries such as documentation generation
+
+Example
+
+```console
+git commit -m "docs: add an example of a good commit message"
+```

commitlint.config.js

@@ -0,0 +1,57 @@
+const Configuration = {
+  /*
+   * Resolve and load @commitlint/config-conventional from node_modules.
+   * Referenced packages must be installed
+   */
+  extends: ['@commitlint/config-conventional', '@commitlint/config-angular'],
+  /*
+   * Resolve and load conventional-changelog-atom from node_modules.
+   * Referenced packages must be installed
+   */
+  parserPreset: 'conventional-changelog-atom',
+  /*
+   * Resolve and load @commitlint/format from node_modules.
+   * Referenced package must be installed
+   */
+  formatter: '@commitlint/format',
+  /*
+   * Any rules defined here will override rules from @commitlint/config-conventional
+   */
+  rules: {
+  },
+  /*
+   * Array of functions that return true if commitlint should ignore the given message.
+   * Given array is merged with predefined functions, which consist of matchers like:
+   *
+   * - 'Merge pull request', 'Merge X into Y' or 'Merge branch X'
+   * - 'Revert X'
+   * - 'v1.2.3' (ie semver matcher)
+   * - 'Automatic merge X' or 'Auto-merged X into Y'
+   *
+   * To see full list, check https://github.com/conventional-changelog/commitlint/blob/master/%40commitlint/is-ignored/src/defaults.ts.
+   * To disable those ignores and run rules always, set `defaultIgnores: false` as shown below.
+   */
+  /*
+  ignores: [(commit) => commit === ''],
+   * Whether commitlint uses the default ignore rules, see the description above.
+   */
+  defaultIgnores: true,
+  /*
+   * Custom URL to show upon failure
+   */
+  helpUrl:
+    'https://github.com/conventional-changelog/commitlint/#what-is-commitlint',
+  /*
+   * Custom prompt configs
+   */
+  prompt: {
+    messages: {},
+    questions: {
+      type: {
+        description: 'please input type:',
+      },
+    },
+  },
+};
+
+module.exports = Configuration;

tox.ini

@@ -0,0 +1,44 @@
+# setup a basic tox environment for flake8 with the default python3.11
+# environment
+[tox]
+envlist = py3.11,flake8
+skip_missing_interpreters = true
+
+[gh-actions]
+python =
+    3.8: gitlint,py38,flake8
+    3.9: gitlint,py39,flake8
+    3.10: gitlint,py310,flake8
+    3.11: gitlint,py311,flake8
+
+[testenv]
+deps = -rrequirements.txt
+commands = pytest
+
+[flake8]
+ignore = D205,D400,D401,D403,D413
+max-line-length =120
+max-complexity = 10
+
+[testenv:flake8]
+skip_install = True
+deps = flake8
+commands = flake8
+
+[testenv:gitlint]
+skip_install = True
+deps = gitlint
+commands = gitlint {posargs}
+
+[testenv:bumpversion]
+skip_install = True
+passenv =
+  # Git can only find its global configuration if it knows where the
+  # user's HOME is.
+  HOME
+  # We set sign_tags in .bumpversion.cfg, so pass in the GnuPG agent
+  # reference to avoid having to retype the passphrase for an
+  # already-cached private key.
+  GPG_AGENT_INFO
+deps = bump2version
+commands = bump2version {posargs}