docs: enhance contributing guidelines to be more accessible

Problem:

The contributing and development guidelines in this repository could benefit from
an improvement pass to make workflows, expectations, and intentions clearer.

Solution:

Rework/refactor the CONTRIBUTING.md, DEVELOPMENT.md, GitHub issue templates, and pull
request template with the goal of improving understandability to those not familiar with
the code base, hatch-based workflows, GitHub pull request workflows, and our use of
conventional commits

Signed-off-by: Daniel Neilson <53624638+ddneilson@users.noreply.github.com>

@@ -1,33 +1,63 @@
 name: "\U0001F41B Bug Report"
 description: Report a bug
-title: "Bug: TITLE"
-labels: ["bug"]
+title: "Bug: (short bug description)"
+labels: ["bug", "needs triage"]
 body:
+  - type: markdown
+    attributes:
+      value: |
+        Thank you for taking the time to fill out this bug report!
+
+        ⚠ If the bug that you are reporting is a security-related issue or security vulnerability,
+        then please do not create a report via this template. Instead please
+        notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/)
+        or directly via email to [AWS Security](aws-security@amazon.com).
+
+  - type: textarea
+    id: description
+    attributes:
+      label: Describe the bug
+      description: What is the problem? A clear and concise description of the bug.
+    validations:
+      required: true
+
   - type: textarea
     id: expected_behaviour
     attributes:
       label: Expected Behaviour
+      description: What did you expect to happen?
     validations:
       required: true

   - type: textarea
     id: current_behaviour
     attributes:
       label: Current Behaviour
+      description: What actually happened? Please include as much detail as you can.
     validations:
       required: true

   - type: textarea
     id: reproduction_steps
     attributes:
       label: Reproduction Steps
+      description: |
+        Please provide as much detail as you can to help us understand how we can reproduce the bug.
+        Step by step instructions and self-contained code snippets are ideal.
     validations:
       required: true

   - type: textarea
-    id: code_snippet
+    id: environment
     attributes:
-      label: Code Snippet
+      label: Environment
+      description: Please provide information on the environment and software versions that you are using to reproduce the bug.
+      value: |
+        At minimum:
+        1. Operating system: (e.g. Windows Server 2022; Amazon Linux 2023; etc.)
+        2. Output of `python3 --version`:
+        3. Version of this library.
+
+        Please share other details about your environment that you think might be relevant to reproducing the bug.
     validations:
       required: true
-

@@ -1,8 +1,8 @@

 name: "📕 Documentation Issue"
 description: Issue in the documentation
-title: "Docs: TITLE"
-labels: ["documenation"]
+title: "Docs: (short description of the issue)"
+labels: ["documenation", "needs triage"]
 body:
   - type: textarea
     id: documentation_issue

@@ -1,17 +1,37 @@
 name: "\U0001F680 Feature Request"
 description: Request a new feature
-title: "Feature request: TITLE"
-labels: ["feature"]
+title: "Feature request: (short description of the feature)"
+labels: ["feature", "needs triage"]
 body:
   - type: textarea
-    id: use_case
+    id: problem
     attributes:
-      label: Use Case
+      label: Describe the problem
+      description: |
+        Help us understand the problem that you are trying to solve, and why it is important to you.
+        Provide as much detail as you are able.
     validations:
       required: true
+
   - type: textarea
     id: proposed_solution
     attributes:
       label: Proposed Solution
+      description: |
+        Describe your proposed feature that you see solving this problem for you. If you have a
+        full or partial prototype implementation then please open a draft pull request and link to
+        it here as well.
+    validations:
+      required: true
+
+  - type: textarea
+    id: use_case
+    attributes:
+      label: Example Use Cases
+      description: |
+        Provide some sample code snippets or shell scripts that show how **you** would use this feature as
+        you have proposed it.
     validations:
       required: true
+
+

@@ -1,17 +1,19 @@
 name: "🛠 Maintenance"
 description: Some type of improvement
-title: "Maintenance: TITLE"
-labels: ["feature"]
+title: "Maintenance: (short description of the issue)"
+labels: ["feature", "needs triage"]
 body:
   - type: textarea
     id: description
     attributes:
       label: Description
+      description: Describe the improvement and why it is important to do.
     validations:
       required: true
   - type: textarea
     id: solution
     attributes:
       label: Solution
+      description: Provide any ideas you have for how the suggestion can be implemented.
     validations:
       required: true

@@ -1,3 +1,5 @@
+Fixes: *<insert link to GitHub issue here>*
+
 ### What was the problem/requirement? (What/Why)

 ### What was the solution? (How)
@@ -6,10 +8,27 @@

 ### How was this change tested?

+See [DEVELOPMENT.md](https://github.com/OpenJobDescription/openjd-model-for-python/blob/mainline/DEVELOPMENT.md#testing) for information on running tests.
+
+- Have you run the unit tests?
+
 ### Was this change documented?

+- Are relevant docstrings in the code base updated?
+
 ### Is this a breaking change?

+A breaking change is one that modifies a public contract in a way that is not backwards compatible. See the
+[Public Interfaces](https://github.com/OpenJobDescription/openjd-model-for-python/blob/mainline/DEVELOPMENT.md#the-packages-public-interface) section
+of the DEVELOPMENT.md for more information on the public contracts.
+
+If so, then please describe the changes that users of this package must make to update their scripts, or Python applications.
+
+### Does this change impact security?
+
+- Does the change need to be threat modeled? For example, does it create or modify files/directories that must only be readable by the process owner?
+    - If so, then please label this pull request with the "security" label. We'll work with you to analyze the threats.
+
 ----

 *By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.*
\ No newline at end of file

@@ -6,62 +6,106 @@ documentation, we greatly value feedback and contributions from our community.
 Please read through this document before submitting any issues or pull requests to ensure we have all the necessary
 information to effectively respond to your bug report or contribution.

+Table of contents:
+
+* [Reporting Bugs/Feature Requests](#reporting-bugsfeature-requests)
+* [Development](#development)
+    * [Finding contributions to work on](#finding-contributions-to-work-on)
+    * [Talk with us first](#talk-with-us-first)
+    * [Contributing via Pull Requests](#contributing-via-pull-requests)
+    * [Conventional Commits](#conventional-commits)
+* [Licensing](#licensing)
+
 ## Reporting Bugs/Feature Requests

 We welcome you to use the GitHub issue tracker to report bugs or suggest features.

 When filing an issue, please check existing open, or recently closed, issues to make sure somebody else hasn't already
-reported the issue. Please try to include as much information as you can. Details like these are incredibly useful:
-
-* A reproducible test case or series of steps
-* The version of our code being used
-* Any modifications you've made relevant to the bug
-* Anything unusual about your environment or deployment
+reported the issue. Please try to include as much information as you can.

 ## Development

-Please see [DEVELOPMENT.md](./DEVELOPMENT.md) for more information.
+We welcome you to contribute features and bug fixes via a [pull request](https://help.github.com/articles/creating-a-pull-request/).
+If you are new to contributing to GitHub repositories, then you may find the
+[GitHub documentation on collaborating with the fork and pull model](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/getting-started/about-collaborative-development-models#fork-and-pull-model)
+informative; this is the model that we follow.
+
+Please see [DEVELOPMENT.md](./DEVELOPMENT.md) for information about how to navigate this package's
+code base and development practices.
+
+### Finding contributions to work on
+
+If you are not sure what you would like to contribute, then looking at the existing issues is a great way to find
+something to contribute on. Looking at
+[issues that have the "help wanted" or "good first issue" labels](https://github.com/OpenJobDescription/openjd-model-for-python/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+issue%22%2C%22help+wanted%22)
+are a good place to start, but please dive into any issue that interests you whether it has those labels or not.

-## Contributing via Pull Requests
+### Talk with us first
+
+We ask that you please [open a feature request issue](https://github.com/OpenJobDescription/openjd-model-for-python/issues/new/choose)
+(if one does not already exist) and talk with us before posting a pull request that contains a significant amount of work,
+or one that proposes a change to a public interface such as to the interface of a publicly exported Python function or to
+the command-line interfaces' commands or arguments. We want to make sure that your time and effort is respected by working
+with you to design the change before you spend much of your time on it. If you want to create a draft pull request to show what
+you are thinking and then talk with us, then that works with us as well.
+
+We prefer that this package contain primarily features that are useful to many users of it, rather than features that are specific
+to niche workflows. If you have a feature in mind, but are not sure whether it is niche or not then please
+[open a feature request issue](https://github.com/OpenJobDescription/openjd-model-for-python/issues/new/choose). We will do our best to help
+you make that assessment, and posting a public issue will help others find your feature idea and add their support if they
+would also find it useful.
+
+### Contributing via Pull Requests

 Contributions via pull requests are much appreciated. Before sending us a pull request, please ensure that:

-1. You are working against the latest source on the *main* branch.
+1. You are working against the latest source on the *mainline* branch.
 2. You check existing open, and recently merged, pull requests to make sure someone else hasn't addressed the problem already.
 3. You open an issue to discuss any significant work - we would hate for your time to be wasted.
+4. Your pull request will be focused on a single change - it is easier for us to understand when a change is focused rather
+   than changing multiple things at once.

 To send us a pull request, please:

 1. Fork the repository.
-2. Modify the source; please focus on the specific change you are contributing. If you also reformat all the code, it will be hard for us to focus on your change.
-3. Ensure local tests pass.
-4. Commit to your fork using clear commit messages.
+2. Modify the source and add tests for your change; please focus on the specific change you are contributing.
+   If you also reformat all the code, it will be hard for us to focus on your change.
+   Please see [DEVELOPMENT.md](./DEVELOPMENT.md) for tips.
+3. Ensure tests pass. Please see the [Testing](./DEVELOPMENT.md#testing) section for information on tests.
+4. Commit to your fork using clear commit messages. Note that all AWS Deadline Cloud GitHub repositories require the use
+   of [conventional commit](#conventional-commits) syntax for the title of your commit.
 5. Send us a pull request, answering any default questions in the pull request interface.
 6. Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.

 GitHub provides additional documentation on [forking a repository](https://help.github.com/articles/fork-a-repo/) and
 [creating a pull request](https://help.github.com/articles/creating-a-pull-request/).

-## Finding contributions to work on
-
-Looking at the existing issues is a great way to find something to contribute on. As our projects, by default, use the default GitHub issue labels (enhancement/bug/duplicate/help wanted/invalid/question/wontfix), looking at any 'help wanted' issues is a great place to start.
-
+### Conventional commits

-## Code of Conduct
+The commits in this repository are all required to use [conventional commit syntax](https://www.conventionalcommits.org/en/v1.0.0/)
+in their title to help us identify the kind of change that is being made, automatically generate the changelog, and
+automatically identify next release version number. Only the first commit that deviates from mainline in your pull request
+must adhere to this requirement.

-This project has adopted the [Amazon Open Source Code of Conduct](https://aws.github.io/code-of-conduct).
-For more information see the [Code of Conduct FAQ](https://aws.github.io/code-of-conduct-faq) or contact
-opensource-codeofconduct@amazon.com with any additional questions or comments.
+We ask that you use these commit types in your commit titles:

+* `feat` - When the pull request adds a new feature or functionality;
+* `fix` - When the pull request is implementing a fix to a bug;
+* `test` - When the pull request is only implementing an addition or change to tests or the testing infrastructure;
+* `docs` - When the pull request is primarily implementing an addition or change to the package's documentation;
+* `refactor` - When the pull request is implementing only a refactor of existing code;
+* `ci` - When the pull request is implementing a change to the CI infrastructure of the packge;
+* `chore` - When the pull request is a generic maintenance task.

-## Security issue notifications
+We also require that the type in your conventional commit title end in an exclaimation point (e.g. `feat!` or `fix!`)
+if the pull request should be considered to be a breaking change in some way. Please also include a "BREAKING CHANGE" footer
+in the description of your commit in this case ([example](https://www.conventionalcommits.org/en/v1.0.0/#commit-message-with-both--and-breaking-change-footer)).
+Examples of breaking changes include any that implements a backwards-imcompatible change to a public Python interface,
+the command-line interface, or the like.

-We take all security reports seriously. When we receive such reports, we will
-investigate and subsequently address any potential vulnerabilities as quickly
-as possible. If you discover a potential security issue in this project, please
-notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/)
-or directly via email to [AWS Security](aws-security@amazon.com). Please do not
-create a public GitHub issue in this project.
+If you need change a commit message, then please see the
+[GitHub documentation on the topic](https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/changing-a-commit-message)
+to guide you.

 ## Licensing

@@ -1,26 +1,124 @@
+# Development documentation

-# Development
+This documentation provides guidance on developer workflows for working with the code in this repository.

-## Command Reference
+Table of Contents:
+* [Development Environment Setup](#development-environment-setup)
+* [The Development Loop](#the-development-loop)
+* [Testing](#testing)
+   * [Writing tests](#writing-tests)
+   * [Running tests](#running-tests)
+* [Things to Know](#things-to-know)
+   * [Package's Public Interface](#the-packages-public-interface)
+   * [Coding Style Requirements](#coding-style-requirements)

-```
-# Build the package
-hatch build
+## Development Environment Setup
+
+To develop the Python code in this repository you will need:
+
+1. Python 3.9 or higher. We recommend [mise](https://github.com/jdx/mise) if you would like to run more than one version
+   of Python on the same system. When running unit tests against all supported Python versions, for instance.
+2. The [hatch](https://github.com/pypa/hatch) package installed (`pip install --upgrade hatch`) into your Python environment.
+
+You can develop on a Linux, MacOs, or Windows workstation, but you will find that some of the support scripting is specific to
+Linux workstations.
+
+## The Development Loop
+
+We have configured [hatch](https://github.com/pypa/hatch) commands to support a standard development loop. You can run the following
+from any directory of this repository:
+
+* `hatch build` - To build the installable Python wheel and sdist packages into the `dist/` directory.
+* `hatch run test` - To run the PyTest unit tests found in the `test/` directory. See [Testing](#testing).
+* `hatch run all:test` - To run the PyTest unit tests against all available supported versions of Python.
+* `hatch run lint` - To check that the package's formatting adheres to our standards.
+* `hatch run fmt` - To automatically reformat all code to adhere to our formatting standards.
+* `hatch shell` - Enter a shell environment where you can run the `deadline` command-line directly as it is implemented in your
+  checked-out local git repository.
+* `hatch env prune` - Delete all of your isolated workspace [environments](https://hatch.pypa.io/1.12/environment/)
+   for this package.
+
+If you are not sure about how to approach development for this package, then we have some suggestions.
+
+1. Run python within a `hatch shell` environment for interactive development. Python will import your in-development
+   codebase when you `import openjd.model` from this environment. This makes it easy to use interactive python, the python
+   debugger, and short test scripts to develop and test your changes.
+   * Note that if you make changes to your source and are running interactive Python then you will need to use
+    [importlib.reload](https://docs.python.org/3/library/importlib.html#importlib.reload) to reload the the module(s) that
+    you modified for your modifications to take effect.
+2. Run the unit test suite frequently (See [Testing](#testing)), and modify/add to it as you are developing your change, rather than
+   only when your change is complete. The test suite runs very quickly, and this will help surface regressions that your change may
+   cause before you get too far into your implementation.
+
+Once you are satisfied with your code, and all relevant tests pass, then run `hatch run fmt` to fix up the formatting of
+your code and post your pull request.
+
+Note: Hatch uses [environments](https://hatch.pypa.io/1.12/environment/) to isolate the Python development workspace
+for this package from your system or virtual environment Python. If your build/test run is not making sense, then
+sometimes pruning (`hatch env prune`) all of these environments for the package can fix the issue.
+
+## Testing
+
+The objective for the tests of this package are to act as regression tests to help identify unintended changes to
+functionality in the package. As such, we strive to have high test coverage of the different behaviours/functionality
+that the package contains. Code coverage metrics are not the goal, but rather are a guide to help identify places
+where there may be gaps in testing coverage.
+
+All tests are all located under the `test/` directory of this repository. If you are adding or modifying
+functionality, then you will almost always want to be writing one or more tests to demonstrate that your
+logic behaves as expected and that future changes do not accidentally break your change.
+
+### Writing Tests
+
+If you want assistance developing tests, then please don't hesitate to open a draft pull request and ask for help.
+We'll do our best to help you out and point you in the right direction. We also suggest looking at the existing tests
+for the same or similar functions for inspiration (search for calls to the function within the `test/`
+subdirectories). You will also find both the official [PyTest documentation](https://docs.pytest.org/en/stable/)
+and [unitest.mock documentation](https://docs.python.org/3.8/library/unittest.mock.html) very informative (we do).
+
+Our tests are implemented using the [PyTest](https://docs.pytest.org/en/stable/) testing framework,
+and unit tests occationally make use of Python's [unittest.mock](https://docs.python.org/3.8/library/unittest.mock.html)
+package to avoid runtime dependencies and narrowly focus tests on a specific aspect of the implementation.
+
+As a rule, we aim to keep usage of `unittest.mock` to a bare minimum in this package's tests. Using a mock inherrently
+encodes assumptions into the tests about how the mocked functionality functions. So, if a change is made that
+violates those assumptions then the test suite will not catch it, and we may end up releasing broken code.
+
+### Running Tests
+
+You can run tests with:

-# Run tests
-hatch run test
+* `hatch run test` - To run the tests with your default Python runtime.
+* `hatch run all:test` - To run the tests with all of the supported Python runtime versions that you have installed.

-# Run linting
-hatch run lint
+Any arguments that you add to these commands are passed through to PyTest. So, if you want to, say, run the
+[Python debugger](https://docs.python.org/3/library/pdb.html) to investigate a test failure then you can run: `hatch run test --pdb`

-# Run formatting
-hatch run fmt
+### Super verbose test output

-# Run a full test
-hatch run all:test
+If you find that you need much more information from a failing test (say you're debugging a
+deadlocking test) then a way to get verbose output from the test is to enable Pytest
+[Live Logging](https://docs.pytest.org/en/latest/how-to/logging.html#live-logs):
+
+1. Add a `pytest.ini` to the root directory of the repository that contains (Note: for some reason,
+setting `log_cli` and `log_cli_level` in `pyproject.toml` does not work for us, nor does setting the options
+on the command-line; if you figure out how to get it to work then please update this section):
+```
+[pytest]
+xfail_strict = False
+log_cli = true
+log_cli_level = 10
+```
+2. Modify `pyproject.toml` to set the following additional `addopts` in the `tool.pytest.ini_options` section:
+```
+    "-vvvvv",
+    "--numprocesses=1"
 ```
+3. Add logging statements to your tests as desired and run the test(s) that you are debugging.
+
+## Things to Know

-## The Package's Public Interface
+### The Package's Public Interface

 This package is a library wherein we are explicit and intentional with what we expose as public.

@@ -65,7 +163,7 @@ class _PrivateClass:
         pass
 ```

-### On `import os as _os`
+#### On `import os as _os`

 Every module/symbol that is imported into a Python module becomes a part of that module's interface.
 Thus, if we have a module called `foo.py` such as:
@@ -91,17 +189,42 @@ import os as _os
 from typing import Dict as _Dict
 ```

-## Use of Keyword-Only Arguments
+### Coding Style Requirements

-Another convention that we are adopting in this package is that all functions/methods that are a
+#### Use of Keyword-Only Arguments
+
+A convention that we adopt in this package is that all functions/methods that are a
 part of the package's external interface should refrain from using positional-or-keyword arguments.
 All arguments should be keyword-only unless the argument name has no true external meaning (e.g.
 arg1, arg2, etc. for `min`). Benefits of this convention are:

 1. All uses of the public APIs of this package are forced to be self-documenting; and
 2. The benefits set forth in PEP 570 ( https://www.python.org/dev/peps/pep-0570/#problems-without-positional-only-parameters ).

-## Exceptions
+For example:
+
+```python
+# Define a public function like this:
+def public_function(*, model: dict[str,Any]) -> str:
+    pass
+
+# Rather than like this:
+def public_function(model: dict[str, Any]) -> str:
+    pass
+```
+
+#### Pydantic Models
+
+The data model is written using [Pydantic](https://github.com/pydantic/pydantic). Pydantic provides the framework for parsing and
+validating input job templates.
+
+1. We intentionally use `Decimal` in place of `float` in our data models as `Decimal` will preserve the
+    precision present in the input whereas `float` will not.
+1. Some classes in the model have "Definition" or "Template" version, as well as a "Target model" version.
+    These exist for parts of the model where instantiating a JobTemplate into a Job changes the model in
+    some way. These are not necessary for all parts of the model.
+
+#### Exceptions

 All functions/methods that raise an exception should have a section in their docstring that states
 the exception(s) they raise. e.g.
@@ -126,35 +249,3 @@ try:
 except ValueError as e:
     # Error handling...
 ```
-
-## About the data model
-
-1. The data model is written using Pydantic. Pydantic provides the framework for parsing and validating
-    input job templates.
-1. We intentionally use `Decimal` in place of `float` in our data models as `Decimal` will preserve the
-    precision present in the input whereas `float` will not.
-1. Some classes in the model have "Definition" or "Template" version, as well as a "Target model" version.
-    These exist for parts of the model where instantiating a JobTemplate into a Job changes the model in
-    some way. These are not necessary for all parts of the model.
-
-## Super verbose test output
-
-If you find that you need much more information from a failing test (say you're debugging a
-deadlocking test) then a way to get verbose output from the test is to enable Pytest
-[Live Logging](https://docs.pytest.org/en/latest/how-to/logging.html#live-logs):
-
-1. Add a `pytest.ini` to the root directory of the repository that contains (Note: for some reason,
-setting `log_cli` and `log_cli_level` in `pyproject.toml` does not work, nor does setting the options
-on the command-line; if you figure out how to get it to work then please update this section):
-```
-[pytest]
-xfail_strict = False
-log_cli = true
-log_cli_level = 10
-```
-2. Modify `pyproject.toml` to set the following additional `addopts` in the `tool.pytest.ini_options` section:
-```
-    "-vvvvv",
-    "--numprocesses=1"
-```
-3. Add logging statements to your tests as desired and run the test(s) that you are debugging.

@@ -391,7 +391,12 @@ For example, if you would like to verify your download of the wheel for version

 ## Security

-See [CONTRIBUTING](CONTRIBUTING.md#security-issue-notifications) for more information.
+We take all security reports seriously. When we receive such reports, we will
+investigate and subsequently address any potential vulnerabilities as quickly
+as possible. If you discover a potential security issue in this project, please
+notify AWS/Amazon Security via our [vulnerability reporting page](http://aws.amazon.com/security/vulnerability-reporting/)
+or directly via email to [AWS Security](aws-security@amazon.com). Please do not
+create a public GitHub issue in this project.

 ## License


### What was the problem/requirement? (What/Why)

The contributing and development guidelines in this repository could benefit from an improvement pass to make workflows, expectations, and intentions clearer.

### What was the solution? (How)

Rework/refactor the CONTRIBUTING.md, DEVELOPMENT.md, GitHub issue templates, and pull request template with the goal of improving understandability to those not familiar with the code base, hatch-based workflows, GitHub pull request workflows, and our use of conventional commits

### What is the impact of this change?

The hope is that the development and contribution process should be much clearer for everyone.

### How was this change tested?

N/A

### Was this change documented?

It is documentation, so yes.

### Is this a breaking change?

No.

----

*By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.*

openjd-model-for-python

Provides a Python implementation of the data model for Open Job Description's template schemas.

docs: enhance contributing guidelines to be more accessible (#138)

Problem:

The contributing and development guidelines in this repository could benefit from
an improvement pass to make workflows, expectations, and intentions clearer.

Solution:

Rework/refactor the CONTRIBUTING.md, DEVELOPMENT.md, GitHub issue templates, and pull
request template with the goal of improving understandability to those not familiar with
the code base, hatch-based workflows, GitHub pull request workflows, and our use of
conventional commits

Signed-off-by: Daniel Neilson <53624638+ddneilson@users.noreply.github.com>


## [![Quality Gate Passed](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/checks/QualityGateBadge/qg-passed-20px.png 'Quality Gate Passed')](https://sonarcloud.io/dashboard?id=OpenJobDescription_openjd-model-for-python&pullRequest=138) **Quality Gate passed**
Issues
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 New issues](https://sonarcloud.io/project/issues?id=OpenJobDescription_openjd-model-for-python&pullRequest=138&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/accepted-16px.png '') [0 Accepted issues](https://sonarcloud.io/project/issues?id=OpenJobDescription_openjd-model-for-python&pullRequest=138&issueStatuses=ACCEPTED)

Measures
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0 Security Hotspots](https://sonarcloud.io/project/security_hotspots?id=OpenJobDescription_openjd-model-for-python&pullRequest=138&issueStatuses=OPEN,CONFIRMED&sinceLeakPeriod=true)
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Coverage on New Code](https://sonarcloud.io/component_measures?id=OpenJobDescription_openjd-model-for-python&pullRequest=138&metric=new_coverage&view=list)
![](https://sonarsource.github.io/sonarcloud-github-static-resources/v2/common/passed-16px.png '') [0.0% Duplication on New Code](https://sonarcloud.io/component_measures?id=OpenJobDescription_openjd-model-for-python&pullRequest=138&metric=new_duplicated_lines_density&view=list)

[See analysis details on SonarCloud](https://sonarcloud.io/dashboard?id=OpenJobDescription_openjd-model-for-python&pullRequest=138)

SonarQubeCloud

SonarQube Cloud (formerly SonarCloud) is a SaaS code analysis tool designed to detect coding issues in 30+ languages, frameworks, and IaC platforms. Your code is checked against an extensive set of rules that cover many attributes of code, such as maintainability, reliability, and security issues, on each merge/pull request.

For those requiring US-based hosting, [SonarQube Cloud US](https://sonarqube.us/) offers the perfect alternative. If you need data residency outside the US or within the EU, [SonarQube Cloud](https://sonarcloud.io/) with this GitHub app is the ideal solution.

SonarQube Cloud integrates seamlessly into your GitHub workflow and provides clear guidance for resolving any code quality and security issues detected. The majority of popular languages can be analyzed automatically; no configuration is required!

With [SonarQube Cloud](https://sonarcloud.io/github), you get:

-   Fast, precise static analysis and feedback on your code

-   Support for popular languages, frameworks, and IaC tools

-   Free analysis for open-source projects and private projects up to max 50k LoC

-   Automatic analysis of pull requests and branches with results reported inline

-   IDE Support with [SonarQube for IDE](https://www.sonarsource.com/products/sonarlint/) integration

-   Quality Gate (added as a GitHub check) acting at two different levels - first, preventing you from merging pull requests that contain issues - and later, helping you to release only clean, safe code

-   Sign up for SonarQube free tier and begin scanning your private and public repositories

A [GitHub Action](https://github.com/marketplace/actions/sonarcloud-scan) is available in the marketplace to make it easy for you (for projects where automatic analysis isn't available). SonarQube Cloud also integrates smoothly with Jenkins, CircleCI, TravisCI, CirrusCI, and many other tools.

A free tier is available that allows you to explore the benefits of SonarQube Cloud using your public and private repositories. We also provide a no-commitment, [14-day trial](https://www.sonarsource.com/products/sonarcloud/signup/) of SonarQube Cloud Team for unlimited team members, up to 1.9M LoC, AI CodeFix recommendations, and more. No need to speak with a sales rep or request a license key - get automatic code analysis results on your private projects in minutes! Want to see more examples of SonarCloud in action? You can [explore current Open Source projects in SonarCloud](https://sonarcloud.io/explore/projects?sort=-analysis_date) that are using the [Clean as You Code](https://www.sonarsource.com/solutions/our-unique-approach/) methodology.

What are you waiting for? SonarQube Cloud helps you consistently deliver cleaner, secure software that future developers will appreciate and your users will love. Start writing Clean Code. [Now](https://www.sonarsource.com/products/sonarcloud/signup/)!

read


read


@@ -6,62 +6,106 @@ documentation, we greatly value feedback and contributions from our community.
 Please read through this document before submitting any issues or pull requests to ensure we have all the necessary
 information to effectively respond to your bug report or contribution.

+Table of contents:
+
+* [Reporting Bugs/Feature Requests](#reporting-bugsfeature-requests)
+* [Development](#development)
+    * [Finding contributions to work on](#finding-contributions-to-work-on)
+    * [Talk with us first](#talk-with-us-first)
+    * [Contributing via Pull Requests](#contributing-via-pull-requests)
+    * [Conventional Commits](#conventional-commits)
+* [Licensing](#licensing)
+
 ## Reporting Bugs/Feature Requests

Somewhere in this file it might be useful to point users to the OJD spec repository if they have an OJD request. This repo is just for the Python implementation of the spec.


I believe that's covered by the intro paragraph of the README. Do you think that some additional clarification should be added there?


I could see someone working with the Python library, wishing it supported something, then raising an issue here that really would be a spec update. But maybe the README covers it. We can always add something later if people do raise issues in the wrong place.