diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 0000000..45a9936
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,23 @@
+---
+name: Bug report
+about: Create a report to help us improve
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior.
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Additional context**
+Add any other context about the problem here.
+
+**spinneret version**
+The spinneret version this bug occurred under.
diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md
new file mode 100644
index 0000000..bbcbbe7
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/feature_request.md
@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Suggest an idea for this project
+title: ''
+labels: ''
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.
diff --git a/.github/workflows/ci-cd.yml b/.github/workflows/ci-cd.yml
new file mode 100644
index 0000000..bb29b71
--- /dev/null
+++ b/.github/workflows/ci-cd.yml
@@ -0,0 +1,125 @@
+name: ci-cd
+
+on:
+ push:
+ branches: [main, development]
+ pull_request:
+ branches: [main, development]
+ workflow_dispatch:
+
+jobs:
+
+ ci:
+ # Set up operating system
+ runs-on: ubuntu-latest
+
+ # Define job steps
+ steps:
+ # Set up job requirements
+ - name: Set up Python
+ uses: actions/setup-python@v4
+ with:
+ python-version: "3.11"
+ - name: Check-out repository
+ uses: actions/checkout@v4
+ - name: Install poetry
+ uses: snok/install-poetry@v1
+ - name: Install package
+ run: poetry install
+
+ # Format code and error on issues. This is an easy check to pass.
+ - uses: psf/black@stable
+ with:
+ jupyter: true
+ src: ./src
+ version: "23.7.0"
+ - uses: psf/black@stable
+ with:
+ jupyter: true
+ src: ./tests
+ version: "23.7.0"
+
+ # Analyze code but don't error on issues. This check encourages best
+ # practices and offers flexibility in adoption.
+ - name: Install poetry
+ uses: snok/install-poetry@v1
+ - name: Install package
+ run: poetry install
+ - name: Analyze code with pylint
+ run: |
+ poetry run pylint src/ --exit-zero --disable=C0103,W0621,R0904
+ poetry run pylint tests/ --exit-zero --disable=C0103,W0621,R0904
+
+ # Test
+ - name: Test with pytest
+ run: poetry run pytest tests/ --cov=spinneret --cov-report=xml
+ - name: Upload coverage reports to Codecov
+ uses: codecov/codecov-action@v4.0.1
+ with:
+ token: ${{ secrets.CODECOV_TOKEN }}
+
+ # Build docs
+ - name: Build documentation
+ run: poetry run make html --directory docs/
+
+
+ cd:
+ # Only run this job if the "ci" job passes
+ needs: ci
+
+ # Only run this job if new work is pushed to "main"
+ if: github.event_name == 'push' && github.ref == 'refs/heads/main'
+
+ # Set up operating system
+ runs-on: ubuntu-latest
+
+ # Define job steps
+ steps:
+ - name: Set up Python
+ uses: actions/setup-python@v4
+ with:
+ python-version: "3.11"
+
+ - name: Check-out repository
+ uses: actions/checkout@v4
+ with:
+ fetch-depth: 0
+ token: ${{ secrets.RELEASE_TOKEN }}
+
+ - name: Install poetry
+ uses: snok/install-poetry@v1
+
+ - name: Install package
+ run: poetry install
+
+ - name: Use Python Semantic Release to prepare release
+ env:
+ GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ run: |
+ git config user.name github-actions
+ git config user.email github-actions@github.com
+ poetry run semantic-release version
+ poetry run semantic-release publish
+ git checkout development
+ git merge main
+ git push origin development
+
+# - name: Publish to TestPyPI
+# uses: pypa/gh-action-pypi-publish@release/v1
+# with:
+# user: __token__
+# password: ${{ secrets.TEST_PYPI_API_TOKEN }}
+# repository_url: https://test.pypi.org/legacy/
+
+# - name: Test install from TestPyPI
+# run: |
+# pip install \
+# --index-url https://test.pypi.org/simple/ \
+# --extra-index-url https://pypi.org/simple \
+# spinneret
+
+# - name: Publish to PyPI
+# uses: pypa/gh-action-pypi-publish@release/v1
+# with:
+# user: __token__
+# password: ${{ secrets.PYPI_API_TOKEN }}
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..b07c663
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,142 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[cod]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+pip-wheel-metadata/
+share/python-wheels/
+*.egg-info/
+.installed.cfg
+*.egg
+MANIFEST
+
+# PyInstaller
+# Usually these files are written by a python script from a template
+# before PyInstaller builds the exe, so as to inject date/other infos into it.
+*.manifest
+*.spec
+
+# Installer logs
+pip-log.txt
+pip-delete-this-directory.txt
+
+# Unit test / coverage reports
+htmlcov/
+.tox/
+.nox/
+.coverage
+.coverage.*
+.cache
+nosetests.xml
+coverage.xml
+*.cover
+*.py,cover
+.hypothesis/
+.pytest_cache/
+
+# Translations
+*.mo
+*.pot
+
+# Django stuff:
+*.log
+local_settings.py
+db.sqlite3
+db.sqlite3-journal
+
+# Flask stuff:
+instance/
+.webassets-cache
+
+# Scrapy stuff:
+.scrapy
+
+# Sphinx documentation
+docs/_build/
+
+# PyBuilder
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+.python-version
+
+# pipenv
+# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
+# However, in case of collaboration, if having platform-specific dependencies or dependencies
+# having no cross-platform support, pipenv may install dependencies that don't work, or not
+# install all needed dependencies.
+#Pipfile.lock
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.venv
+env/
+venv/
+ENV/
+env.bak/
+venv.bak/
+
+# Spyder project settings
+.spyderproject
+.spyproject
+
+# Rope project settings
+.ropeproject
+
+# mkdocs documentation
+/site
+
+# mypy
+.mypy_cache/
+.dmypy.json
+dmypy.json
+
+# Pyre type checker
+.pyre/
+**__pycache__
+
+# PyCharm
+.idea/
+
+# RStudio project files
+**.Rproj.user/
+**.Rproj.user*
+**.Rproj
+**.Rhistory
+
+# MacOS
+.DS_Store
\ No newline at end of file
diff --git a/.readthedocs.yml b/.readthedocs.yml
new file mode 100644
index 0000000..092d342
--- /dev/null
+++ b/.readthedocs.yml
@@ -0,0 +1,16 @@
+version: 2
+
+build:
+ os: "ubuntu-22.04"
+ tools:
+ python: "3.11"
+
+sphinx:
+ fail_on_warning: false
+
+python:
+ # Install our python package before building the docs
+ install:
+ - method: pip
+ path: .
+ - requirements: docs/requirements.txt
\ No newline at end of file
diff --git a/LICENSE b/LICENSE
new file mode 100755
index 0000000..438f34a
--- /dev/null
+++ b/LICENSE
@@ -0,0 +1,22 @@
+MIT License
+
+Copyright (c) 2024, Colin Smith
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
diff --git a/README.md b/README.md
new file mode 100644
index 0000000..3a6873f
--- /dev/null
+++ b/README.md
@@ -0,0 +1,19 @@
+# spinneret
+
+[](https://www.repostatus.org/#wip)
+
+[](https://codecov.io/github/clnsmth/spinneret)
+
+For integrating EDI into the Semantic Web
+
+## Installation
+
+Currently, `spinneret` is only available on GitHub. To install it, you need to have [pip](https://pip.pypa.io/en/stable/installation/) installed. Once pip is installed, you can install `spinneret` by running the following command in your terminal:
+
+ $ pip install git+https://github.com/clnsmth/spinneret.git@main
+
+## Demo and Usage
+
+## API Reference and User Guide
+
+The API reference and user guide are available on [Read the Docs](https://spinneret.readthedocs.io).
diff --git a/docs/Makefile b/docs/Makefile
new file mode 100644
index 0000000..d0c3cbf
--- /dev/null
+++ b/docs/Makefile
@@ -0,0 +1,20 @@
+# Minimal makefile for Sphinx documentation
+#
+
+# You can set these variables from the command line, and also
+# from the environment for the first two.
+SPHINXOPTS ?=
+SPHINXBUILD ?= sphinx-build
+SOURCEDIR = source
+BUILDDIR = build
+
+# Put it first so that "make" without argument is like "make help".
+help:
+ @$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
+
+.PHONY: help Makefile
+
+# Catch-all target: route all unknown targets to Sphinx using the new
+# "make mode" option. $(O) is meant as a shortcut for $(SPHINXOPTS).
+%: Makefile
+ @$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
diff --git a/docs/make.bat b/docs/make.bat
new file mode 100644
index 0000000..747ffb7
--- /dev/null
+++ b/docs/make.bat
@@ -0,0 +1,35 @@
+@ECHO OFF
+
+pushd %~dp0
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+ set SPHINXBUILD=sphinx-build
+)
+set SOURCEDIR=source
+set BUILDDIR=build
+
+%SPHINXBUILD% >NUL 2>NUL
+if errorlevel 9009 (
+ echo.
+ echo.The 'sphinx-build' command was not found. Make sure you have Sphinx
+ echo.installed, then set the SPHINXBUILD environment variable to point
+ echo.to the full path of the 'sphinx-build' executable. Alternatively you
+ echo.may add the Sphinx directory to PATH.
+ echo.
+ echo.If you don't have Sphinx installed, grab it from
+ echo.https://www.sphinx-doc.org/
+ exit /b 1
+)
+
+if "%1" == "" goto help
+
+%SPHINXBUILD% -M %1 %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
+goto end
+
+:help
+%SPHINXBUILD% -M help %SOURCEDIR% %BUILDDIR% %SPHINXOPTS% %O%
+
+:end
+popd
diff --git a/docs/requirements.txt b/docs/requirements.txt
new file mode 100644
index 0000000..bf6c8ec
--- /dev/null
+++ b/docs/requirements.txt
@@ -0,0 +1,5 @@
+# Pinning to avoid unexpected breakages.
+# Used by RTD to generate docs.
+Sphinx==7.0.1
+sphinx-autoapi==2.1.1
+myst-parser==2.0.0
\ No newline at end of file
diff --git a/docs/source/CHANGELOG.md b/docs/source/CHANGELOG.md
new file mode 100644
index 0000000..16007ae
--- /dev/null
+++ b/docs/source/CHANGELOG.md
@@ -0,0 +1,17 @@
+# Release History
+
+## Release Process and Guidelines
+
+In our project, we adhere to the principles of [Semantic Versioning](http://semver.org/) when it comes to our releases. By following this release process, we ensure the orderly progression of our project while maintaining compatibility and providing necessary bug fixes and improvements.
+
+*Major Releases*: A major release introduces significant changes, including those that break compatibility with previous versions. These releases are identified with a version number in the format of `X.0.0`. For instance, if the previous release was `1.2.7`, the next major version will be labeled as `2.0.0`.
+
+*Minor Releases*: A minor release does not include breaking changes and primarily focuses on bug fixes and improvements. If the previous version of spinneret was `1.2.7`, a minor release would be denoted as `1.3.0`.
+
+*Patch Releases*: A patch release exclusively addresses any missed bugs from the previous version. If the previous release of spinneret was `1.2.7`, a patch release would be identified as `1.2.8`.
+
+
+
+## v0.0.0 (2024/08/20)
+
+- First release of `spinneret`!
\ No newline at end of file
diff --git a/docs/source/_static/custom.css b/docs/source/_static/custom.css
new file mode 100644
index 0000000..e69de29
diff --git a/docs/source/_templates/docs/sidebarintro.html b/docs/source/_templates/docs/sidebarintro.html
new file mode 100644
index 0000000..1b82d56
--- /dev/null
+++ b/docs/source/_templates/docs/sidebarintro.html
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
+
+
+
\ No newline at end of file
diff --git a/docs/source/_templates/docs/sidebarlogo.html b/docs/source/_templates/docs/sidebarlogo.html
new file mode 100644
index 0000000..b1bf0d5
--- /dev/null
+++ b/docs/source/_templates/docs/sidebarlogo.html
@@ -0,0 +1,27 @@
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
diff --git a/docs/source/_templates/docs/source/_templates/CHANGELOG.md.j2 b/docs/source/_templates/docs/source/_templates/CHANGELOG.md.j2
new file mode 100644
index 0000000..3ebe888
--- /dev/null
+++ b/docs/source/_templates/docs/source/_templates/CHANGELOG.md.j2
@@ -0,0 +1,24 @@
+
+# CHANGELOG
+{% if context.history.unreleased | length > 0 -%}
+{# UNRELEASED #}
+## Unreleased
+{% for type_, commits in context.history.unreleased | dictsort %}
+
+### {{ type_ | capitalize }}
+{% for commit in commits %}{% if type_ != "unknown" %}
+* {{ commit.commit.message.split('\n')[0] }} ([`{{ commit.commit.hexsha[:7] }}`]({{ commit.commit.hexsha | commit_hash_url }})) {% else %}
+* {{ commit.commit.message.split('\n')[0] }} ([`{{ commit.commit.hexsha[:7] }}`]({{ commit.commit.hexsha | commit_hash_url }}))
+{% endif %}{% endfor %}{% endfor %}{% endif -%}
+
+{# RELEASED #}
+{% for version, release in context.history.released.items() %}
+
+## {{ version.as_tag() }} ({{ release.tagged_date.strftime("%Y-%m-%d") }})
+{% for type_, commits in release["elements"] | dictsort %}
+
+### {{ type_ | capitalize }}
+{% for commit in commits %}{% if type_ != "unknown" %}
+* {{ commit.commit.message.split('\n')[0] }} ([`{{ commit.commit.hexsha[:7] }}`]({{ commit.commit.hexsha | commit_hash_url }})) {% else %}
+* {{ commit.commit.message.split('\n')[0] }} ([`{{ commit.commit.hexsha[:7] }}`]({{ commit.commit.hexsha | commit_hash_url }}))
+{% endif %}{% endfor %}{% endfor %}{% endfor %}
diff --git a/docs/source/_templates/docs/source/_templates/sidebarintro.html b/docs/source/_templates/docs/source/_templates/sidebarintro.html
new file mode 100644
index 0000000..1b82d56
--- /dev/null
+++ b/docs/source/_templates/docs/source/_templates/sidebarintro.html
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
+
+
+
\ No newline at end of file
diff --git a/docs/source/_templates/docs/source/_templates/sidebarlogo.html b/docs/source/_templates/docs/source/_templates/sidebarlogo.html
new file mode 100644
index 0000000..b1bf0d5
--- /dev/null
+++ b/docs/source/_templates/docs/source/_templates/sidebarlogo.html
@@ -0,0 +1,27 @@
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
diff --git a/docs/source/_templates/sidebarintro.html b/docs/source/_templates/sidebarintro.html
new file mode 100644
index 0000000..1b82d56
--- /dev/null
+++ b/docs/source/_templates/sidebarintro.html
@@ -0,0 +1,37 @@
+
+
+
+
+
+
+
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
+
+
+
\ No newline at end of file
diff --git a/docs/source/_templates/sidebarlogo.html b/docs/source/_templates/sidebarlogo.html
new file mode 100644
index 0000000..b1bf0d5
--- /dev/null
+++ b/docs/source/_templates/sidebarlogo.html
@@ -0,0 +1,27 @@
+
+
+
+
+
+ For integrating EDI into the Semantic Web
+
+
+Useful Links
+
diff --git a/docs/source/conf.py b/docs/source/conf.py
new file mode 100644
index 0000000..01f8c11
--- /dev/null
+++ b/docs/source/conf.py
@@ -0,0 +1,87 @@
+# Configuration file for the Sphinx documentation builder.
+#
+# For the full list of built-in configuration values, see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Project information -----------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#project-information
+
+project = 'spinneret'
+copyright = '2023, Colin Smith'
+author = 'Colin Smith'
+release = '0.0.0'
+
+# -- General configuration ---------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#general-configuration
+
+extensions = [
+ 'sphinx.ext.autodoc',
+ 'sphinx.ext.napoleon',
+ 'sphinx.ext.viewcode',
+ 'myst_parser',
+]
+
+# Configure autodoc
+import os
+import sys
+sys.path.insert(0, os.path.abspath('../src')) # path to source code
+napoleon_numpy_docstring = True # use numpy
+napoleon_google_docstring = False # not google
+
+templates_path = ['_templates']
+exclude_patterns = []
+
+sys.path.insert(0, os.path.abspath("../src/spinneret"))
+# Get the current version of spinneret for display in the docs
+from importlib.metadata import version
+version = version("spinneret")
+
+
+
+# -- Options for HTML output -------------------------------------------------
+# https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-html-output
+
+html_theme = 'alabaster'
+html_static_path = ['_static']
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+html_theme_options = {
+ "show_powered_by": False,
+ "github_user": "clnsmth",
+ "github_repo": "spinneret",
+ "github_banner": False,
+ "show_related": False,
+ "note_bg": "#FFF59C",
+}
+
+# Custom sidebar templates, maps document names to template names.
+html_sidebars = {
+ "index": [
+ "sidebarintro.html",
+ "sourcelink.html",
+ "searchbox.html",
+ # "hacks.html"
+ ],
+ "**": [
+ "sidebarlogo.html",
+ "localtoc.html",
+ "relations.html",
+ "sourcelink.html",
+ "searchbox.html",
+ # "hacks.html",
+ ],
+}
+
+# If true, links to the reST sources are added to the pages.
+html_show_sourcelink = False
+
+# If true, "Created using Sphinx" is shown in the HTML footer. Default is True.
+html_show_sphinx = False
+
+# If true, "(C) Copyright ..." is shown in the HTML footer. Default is True.
+html_show_copyright = False
+
+# If true, '()' will be appended to :func: etc. cross-reference text.
+add_function_parentheses = False
diff --git a/docs/source/dev/conduct.rst b/docs/source/dev/conduct.rst
new file mode 100644
index 0000000..6b54aa7
--- /dev/null
+++ b/docs/source/dev/conduct.rst
@@ -0,0 +1,54 @@
+.. _conduct:
+
+Code of Conduct
+===============
+
+Our Pledge
+----------
+
+In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in this project and community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
+
+Our Standards
+--------------
+
+Examples of behavior that contributes to creating a positive environment include:
+
+- Using welcoming and inclusive language
+- Being respectful of differing viewpoints and experiences
+- Gracefully accepting constructive criticism
+- Focusing on what is best for the community
+- Showing empathy towards other community members
+
+Examples of unacceptable behavior by participants include:
+
+- The use of sexualized language or imagery and unwelcome sexual attention or advances
+- Trolling, insulting/derogatory comments, and personal or political attacks
+- Public or private harassment
+- Publishing others' private information, such as a physical or electronic address, without explicit permission
+- Other conduct which could reasonably be considered inappropriate in a professional setting
+
+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.
+
+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.
+
+Enforcement
+------------
+
+Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team. The project team will review and investigate all complaints, and will respond in a way that it deems 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.
+
+Attribution
+------------
+
+This Code of Conduct is adapted from the `Contributor Covenant homepage`_, version 1.4.
+
+.. _Contributor Covenant homepage: http://contributor-covenant.org/version/1/4
diff --git a/docs/source/dev/contributing.rst b/docs/source/dev/contributing.rst
new file mode 100644
index 0000000..a9613db
--- /dev/null
+++ b/docs/source/dev/contributing.rst
@@ -0,0 +1,118 @@
+.. _contributing:
+
+Contributor's Guide
+===================
+
+Welcome to the open source community building this toolkit! We're thrilled you're interested in contributing – your ideas and efforts are what make this project thrive.
+
+We encourage you to explore the guide and familiarize yourself with our collaborative development process. If you have any questions or need help getting started, feel free to reach out on our `GitHub issue`_ tracker.
+
+Be Courteous
+------------
+
+In the spirit of collaboration, we emphasize the importance of maintaining a respectful and inclusive environment.
+
+In this project, we uphold a golden rule that applies to all forms of contribution, including bug reports and feature requests: treat everyone involved with respect. We value the diverse perspectives and experiences of our contributors and encourage constructive and courteous interactions.
+
+See the :ref:`Code of Conduct ` for details.
+
+.. _Code of Conduct: https://spinneret.readthedocs.io/en/latest/dev/conduct/
+
+Contribution Suitability
+------------------------
+
+The final decision regarding the suitability of a contribution for the project rests with the project maintainers. While we carefully consider all contributions, there may be instances where certain contributions are not aligned with the project's current goals or needs, and as a result, they may be declined.
+
+Need some feedback on whether your idea is suitable for the project? Open a `GitHub issue`_. We're happy to discuss your ideas and provide feedback!
+
+.. _GitHub issue: https://github.com/clnsmth/spinneret/issues
+
+Code Contributions
+------------------
+
+Steps for Submitting Code
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Here are a sequence of steps to help with your code contribution:
+
+1. Fork the project repository on GitHub.
+2. Create a `feature branch` from the `development` branch.
+3. Install the package by running ``poetry install`` at the command line.
+4. Verify that all tests pass on your system by running ``poetry run pytest`` at the command line. In case of failures, conduct a thorough investigation. If you require assistance in diagnosing the issue, follow the guidelines for filing :ref:`bug-reports`.
+5. Construct test cases that effectively illustrate the bug or feature.
+6. Implement your changes, including any relevant documentation updates following our :ref:`documentation-contributions` guidelines.
+7. Re-run the complete test suite to ensure the success of all tests.
+8. Format and analyze your code according to our :ref:`code-format-and-analysis` guidelines.
+9. Ensure the docs build following the :ref:`documentation-contributions` guidelines.
+10. Check that the sdist and wheels build by running ``poetry build`` at the command line.
+11. Commit your work following our :ref:`commit-message` guidelines.
+12. Submit a GitHub Pull Request to the `development` branch of the upstream repository.
+
+.. _reStructuredText: https://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
+.. _pytest: https://docs.pytest.org/en/latest/
+.. _Angular commit style: https://github.com/angular/angular/blob/convert/CONTRIBUTING.md#-commit-message-format
+
+Code Review
+~~~~~~~~~~~
+
+Once contributions have undergone a code review process, they will be merged. It is generally recommended to incorporate any feedback received during the code review, unless there are strong objections. If, after submitting your objections, it is determined that the original feedback is still applicable, you will have to either implement the suggested changes or retract your contribution.
+
+.. _code-format-and-analysis:
+
+Code Format and Analysis
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+Our project uses a couple tools to ensure the code base has a consistent
+style and format as it grows. We use `Black`_ for code formatting and `Pylint`_ for static code analysis. Both can be run from the command line::
+
+ poetry run black src/ tests/
+ poetry run pylint src/ tests/
+
+.. _Black: https://black.readthedocs.io/en/stable/
+.. _Pylint: https://pylint.pycqa.org/en/latest/
+
+.. _documentation-contributions:
+
+Documentation Contributions
+---------------------------
+
+We greatly appreciate any efforts to enhance the project documentation! The documentation files reside within the ``docs/`` directory and are written in `reStructuredText`_. We utilize `Sphinx`_ to generate a comprehensive suite of documentation. The API documentation is automatically generated by Sphinx from docstrings formatted according to `PEP 287`_.
+
+Build the docs from the command line::
+
+ poetry run make --directory=docs clean html
+
+
+.. _reStructuredText: https://thomas-cokelaer.info/tutorials/sphinx/docstring_python.html
+.. _Sphinx: http://sphinx-doc.org/index.html
+.. _PEP 287: https://peps.python.org/pep-0287/
+
+.. _bug-reports:
+
+Bug Reports
+-----------
+
+We value your help in improving this project! To avoid duplicate reports, it's helpful to quickly check the existing `GitHub issues`_ to see if the bug has already been reported.
+
+If you are reporting a bug, please use the `Bug report`_ issue template. We appreciate it!
+
+.. _Bug report: https://github.com/clnsmth/spinneret/issues/new/choose
+.. _GitHub issues: https://github.com/clnsmth/spinneret/issues
+
+Feature Requests
+----------------
+
+Feature requests help this project grow with the user community. If you have an idea for a new feature, we'd love to hear about it! Before submitting a feature request, we kindly request you to check the existing `GitHub issues`_ to ensure that the feature hasn't been requested.
+
+If you are proposing a feature, please use the `Feature request`_ issue template. Thanks!
+
+.. _Feature request: https://github.com/clnsmth/spinneret/issues/new/choose
+
+.. _commit-message:
+
+Commit Messages
+---------------
+
+Commit messages are incredibly valuable for understanding the project's code. When crafting your commit message, please provide context about the changes being made and the reasons behind them.
+
+To ensure readability, we recommend to keep the commit message header under 52 characters and the body within 72 characters.
\ No newline at end of file
diff --git a/docs/source/dev/design.rst b/docs/source/dev/design.rst
new file mode 100644
index 0000000..880940f
--- /dev/null
+++ b/docs/source/dev/design.rst
@@ -0,0 +1,31 @@
+.. _design:
+
+Project Design
+==============
+
+Welcome to the design document for `spinneret`! This document provides an in-depth overview of the architectural design, key components, and design principles behind our work. It aims to enhance your understanding of our project's design philosophy and empower you to contribute effectively.
+
+We encourage you to explore this document and reach out with any questions or suggestions. Your feedback is invaluable as we continuously improve and evolve our project.
+
+Introduction
+------------
+What it does, why it's important, and who it's for:
+
+Why use it?:
+
+Functional design requirements:
+
+Non-functional design requirements we considered:
+
+Architecture
+------------
+
+The system architecture:
+
+Implementation Overview:
+
+Testing
+-------
+
+Alternative Implementations Considered
+--------------------------------------
diff --git a/docs/source/dev/maintaining.rst b/docs/source/dev/maintaining.rst
new file mode 100644
index 0000000..2bd0989
--- /dev/null
+++ b/docs/source/dev/maintaining.rst
@@ -0,0 +1,200 @@
+.. _maintaining:
+
+Maintainers Guide
+=================
+
+Many thanks for your help maintaining our project! Without your contribution, development would be considerably slower and the user community left waiting longer.
+
+This document complements the `Contributor's Guide `_ by providing additional steps for integrating contributions into the project's code base. As a maintainer, you are also a contributor, so please use the contributor guide when making changes in order to keep the development process open and consistent (note :ref:`developing-features-as-a-maintainer`).
+
+Be Courteous
+------------
+
+Sometimes we need to meet contributors halfway. This means more work on our part but for benefit of the project and community. Please be courteous and patient.
+
+If you are unable to respond fully to a pull request or issue in a timely manner, please let the contributor know that you will get to it as soon as you can.
+
+Pull Request Review
+-------------------
+
+Pull request review facilitates refinement of a contribution before it's incorporated into the project. The goals are to ensure the contribution is consistent with the project's design, is well-documented, and is well-tested. We are not looking for perfection, but rather that the contribution does what it is intended to do.
+
+*Though pull request review is required by the project's GitHub branch protection rules, maintainers are allowed to bypass review. Having said this, we generally encourage review in all cases.*
+
+Here are a steps to help with your pull request review:
+
+1. Start a GitHub review on the pull request.
+2. Check that the :ref:`ci-workflow` passes. Even if successful, check the workflow run logs for Pylint related messages. Though not required, we recommend these messages be addressed.
+3. New features or bug-fixes should include tests demonstrating the change.
+4. Review the diffs of code and related documentation.
+5. Check for compliance with our :ref:`commit-message` style.
+6. Submit the review.
+
+If collaboration on the pull request is needed, create a `feature branch` in GitHub, change the base branch of the pull request from `development` to the newly created `feature branch`, and merge. This allows the maintainer to lend a helpful hand.
+
+When a pull request passes review, it is ready to be merged into the `development` branch (see :ref:`merging-features-into-development`).
+
+Git and GitHub
+--------------
+
+We use a combination of git and GitHub features to version control and manage various aspects of our project. Generally, we prefer small, incremental changes that are easy to review and maintain.
+
+.. _commit-message-style:
+
+Commit Message Style
+~~~~~~~~~~~~~~~~~~~~
+
+Our project uses two different commit message styles. The first is used during feature development (see the Contributor's Guide :ref:`commit-message`). The second is used to convert a squash commit when merging a `feature branch` into `development`, and allows `Python Semantic Release`_ to streamline the reoccurring release process.
+
+This second commit style is the `Angular commit style`_. Our project uses this style in full with the notable exceptions that the `commit message header`_ should not include the `scope` value, and that any related GitHub issues should be referenced. For example:
+
+``feat: add framework for new feature (#3, #5)``
+
+not
+
+``feat(module): add framework for new feature``
+
+.. _Python Semantic Release: https://python-semantic-release.readthedocs.io/en/latest/
+.. _Angular commit style: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit
+.. _commit message header: https://github.com/angular/angular/blob/main/CONTRIBUTING.md#commit-message-header
+
+Do your best to keep the commit message header from exceeding 52 characters in length, but no greater than 72 characters, and keep the commit message body from exceeding 72 characters.
+
+*Note, Semantic Release may be bypassed in special circumstances. To do this, simply remove all Angular style "type" keywords from the commit message header.*
+
+
+
+Branch Management
+~~~~~~~~~~~~~~~~~
+
+The `main` branch always reflects the current stable release, a `development` branch is used for incorporating new features, and `feature` branches implement changes. The `development` branch is always in a releasable state.
+
+.. _feature-branches:
+
+Feature Branches
+^^^^^^^^^^^^^^^^
+
+Any sort of change, including new features, documentation, refactors, and fixes, should be done on a `feature branch` to facilitate iterative collaboration. It can be helpful when feature branch names reference the issue and describes the feature, for example, ``30-release-workflow``.
+
+.. _merging-features-into-development:
+
+Merging Features into Development
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When a feature is complete and ready for integration with the project, it should be merged into `development` following these steps:
+
+1. Pull the remote `feature branch` into your local repository.
+2. Rebase the `feature branch` onto the `development` branch.
+3. Force push your local `feature branch` to the remote `feature branch`.
+4. Ensure the :ref:`ci-workflow` passes.
+5. Squash merge the `feature branch` into `development` using the GitHub pull request interface, and following the Angular commit style mentioned in the :ref:`commit-message-style` guidelines. To do this:
+ i. Edit the commit message header.
+ ii. Preserve the commit message body as is (now a squashed set of commits).
+ iii. Add keywords in the `commit message footer`_ to close out or mention any related GitHub issues.
+ iv. Merge the pull request.
+
+.. _commit message footer: https://github.com/angular/angular/blob/convert/CONTRIBUTING.md#commit-message-footer
+
+If at this point, part of the feature was forgotten, don't restore the `feature branch`, rather open a new pull request on `development`, and iterate back through the contributor process.
+
+Merging Development into Main
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When it's time to create a new release, a project maintainer, with repository write access, will merge the `development` branch into `main` locally, and then push to the remote, which will then kick-start the automated release workflow (see :ref:`cd-workflow`). This approach to merging, is taken in order to preserve a linear commit history and to retain the Angular styled commit messages required by `Python Semantic Release`_.
+
+Here's a sequence of steps for merging `development` into `main` and creating a new release:
+
+1. Open a pull request from the `development` branch to `main`.
+2. Check that the :ref:`ci-workflow` and other requirements pass.
+3. Get a pull request review from another maintainer (if possible).
+4. *Do not merge in GitHub!* Instead follow these steps:
+ i. Pull the remote `development` and `main` branches into your local repository.
+ ii. Merge the `development` branch into `main`.
+ iii. Push your local `main` branch to the remote.
+5. Ensure both the :ref:`ci-workflow` and :ref:`cd-workflow` complete successfully.
+6. Ensure the docs build and deploy successfully on `readthedocs.io`_.
+7. Check the pull request has been merged and closed out.
+8. Pull the remote `main` and `development` branches back into your local repository. This will keep your local branches in sync with the remote, which the semantic release made modifications to during the release process.
+
+.. _readthedocs.io: https://spinneret.readthedocs.io/en/latest/
+
+.. _hot-fixes:
+
+Hot Fixes
+^^^^^^^^^
+
+Hotfixes should always be implemented in a `feature branch`, which is merged into `development`, and then merged into `main` using the approaches outlined above. Implementing a hotfix in `main` and merging into `development` will create problems in the commit history.
+
+Branch Protection Rules
+~~~~~~~~~~~~~~~~~~~~~~~
+
+GitHub branch protection rules are used to help ensure the integrity of the codebase. The following rules are enforced on the `development` and `main` branches:
+
+* Require a pull request approval before merging
+* Require status checks to pass before merging
+* Require branches to be up to date before merging
+* Require conversation resolution before merging
+* Require linear history
+
+*The only protection rule maintainers are allowed to ignore is the "pull request approval" requirement. Having said this, we generally encourage review in all cases.*
+
+Secrets
+~~~~~~~
+
+A GitHub repository secret, containing the personal access token of one of the maintainers with write access, is required for the :ref:`cd-workflow` to complete. This token should be added to the project's repository secrets with the name ``RELEASE_TOKEN``. This authentication is used by `Python Semantic Release`_ to commit changes created during the release proces to the `main` branch, which are then merged into the `development` branch. This latter step ensures the two branches remain synchronized.
+
+Workflows
+~~~~~~~~~
+
+GitHub Actions are used for continuous integration and delivery.
+
+.. _ci-workflow:
+
+CI Workflow
+^^^^^^^^^^^
+
+The CI workflow is run on each pull request and push to the `development` and `main` branches. It performs the following steps:
+
+1. Formats code in *src/* and *tests/* using `Black`_. This check is strictly enforced and will fail the workflow.
+2. Analyzes code in *src/* and *tests/* using the project's `Pylint`_ configuration (see :ref:`code-format-and-analysis`). This check is not strictly enforced and will not fail the workflow. However, generally, Pylint recommendations should be followed.
+3. Runs tests in *tests/* using `Pytest`_. This check is strictly enforced and will fail the workflow.
+4. Builds the documentation (see :ref:`documentation-contributions`). This check is strictly enforced and will fail the workflow.
+
+.. _Black: https://black.readthedocs.io/en/stable/
+.. _Pylint: https://pylint.pycqa.org/en/latest/
+.. _Pytest: https://docs.pytest.org/en/latest/
+
+.. _cd-workflow:
+
+CD Workflow
+^^^^^^^^^^^
+
+The CD workflow is run on push to the `main` branch for releases. It performs the following steps:
+
+1. Runs `Python Semantic Release`_ to build the changelog, convert the distributions, bump the version number, and tag the release.
+2. Merges changes in the `main` branch back into `development` to keep the branches synchronized.
+
+.. _developing-features-as-a-maintainer:
+
+Developing Features as a Maintainer
+-----------------------------------
+
+As a maintainer, when developing a new feature, you don't have to fork the project repository to your personal GitHub, and submit pull requests via that route. Rather, you may create a `feature branch` in the project's remote repository, and submit a pull request to `development` from there.
+
+Dependency and Environment Management
+-------------------------------------
+
+This project uses `Poetry`_ to manage dependencies for development and distribution. Poetry keeps track of necessary packages and their versions, ensuring a consistent development environment.
+
+For those who prefer using `Conda`_ for environment management, we provide environment files to define the Conda environment. This means package dependencies need to be maintained with Conda as well as Poetry. Update the Conda environment definition using the following commands::
+
+ conda env export --from-history --file environment-min.yml
+ conda env export --no-builds --file environment.yml
+
+While Poetry is the recommended method for installation, we offer users an option to install the package using `pip`_. To get a requirements.txt file listing::
+
+ pip list --format=freeze > requirements.txt
+
+.. _Poetry: https://python-poetry.org/
+.. _Conda: https://conda.io/projects/conda/en/latest/
+.. _pip: https://pip.pypa.io/en/stable/
diff --git a/docs/source/index.html b/docs/source/index.html
new file mode 100644
index 0000000..433b648
--- /dev/null
+++ b/docs/source/index.html
@@ -0,0 +1,425 @@
+
+
+
+
+
+
+index.rst
+
+
+
+
+
+
+
+
+
Welcome to py311's documentation!
+
+
System Message: ERROR/3 (/Users/csmith/Code/py311/docs/source/index.rst, line 9)
+
Unknown directive type "toctree".
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents:
+
+
+
+
+
+
+
+
Indices and tables
+
+:ref:`genindex`
+
+
System Message: ERROR/3 (/Users/csmith/Code/py311/docs/source/index.rst, line 18); backlink
+
Unknown interpreted text role "ref".
+
:ref:`modindex`
+
+
System Message: ERROR/3 (/Users/csmith/Code/py311/docs/source/index.rst, line 19); backlink
+
Unknown interpreted text role "ref".
+
:ref:`search`
+
+
System Message: ERROR/3 (/Users/csmith/Code/py311/docs/source/index.rst, line 20); backlink
+
Unknown interpreted text role "ref".
+
+
+
The API Documentation / Guide
+
If you are looking for information on a specific function, class, or method,
+this part of the documentation is for you.
+
+
System Message: ERROR/3 (/Users/csmith/Code/py311/docs/source/index.rst, line 29)
+
Unknown directive type "toctree".
+
+.. toctree::
+ :maxdepth: 2
+
+ api
+
+
+
+
+