feat!(treewide): rewrite COC in TOML; introduce glossary

.editorconfig

@@ -0,0 +1,5 @@
+root = true
+
+[*.py]
+indent_style = space
+indent_size = 4

.github/workflows/generate-readme.yml

@@ -0,0 +1,38 @@
+name: "Generate README.md"
+on: "push"
+jobs:
+  generateREADME:
+    name: "Generate README.md"
+    runs-on: "ubuntu-latest"
+    steps:
+      - name: "Checkout repository"
+        uses: "actions/checkout@v4"
+      - name: "Install Python"
+        run: |
+          sudo apt install python3 -y
+      - name: "Generate .venv"
+        run: |
+          python3 -m venv .venv
+      - name: "Source the venv"
+        run: |
+          source ./.venv/bin/activate
+      - name: "Update pip"
+        run: |
+          pip install --upgrade pip
+      - name: "Install poetry"
+        run: |
+          pip install poetry
+      - name: "Install code_of_conduct"
+        run: |
+          poetry install
+      - name: "Run code_of_conduct"
+        run: |
+          python3 -m code_of_conduct
+      - name: "Commit new README.md"
+        run: |
+          git config --global user.name "${{ github.actor }}"
+          git config --global user.email "${{ github.actor }}@users.noreply.github.com"
+          git add .
+          git commit -m "README.md: Update" -m "[skip ci]"
+          git push
+

.gitignore

@@ -0,0 +1,208 @@
+# Byte-compiled / optimized / DLL files
+__pycache__/
+*.py[codz]
+*$py.class
+
+# C extensions
+*.so
+
+# Distribution / packaging
+.Python
+build/
+develop-eggs/
+dist/
+downloads/
+eggs/
+.eggs/
+lib/
+lib64/
+parts/
+sdist/
+var/
+wheels/
+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/
+cover/
+
+# 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
+.pybuilder/
+target/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# IPython
+profile_default/
+ipython_config.py
+
+# pyenv
+#   For a library or package, you might want to ignore these files since the code is
+#   intended to run in multiple environments; otherwise, check them in:
+# .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
+
+# UV
+#   Similar to Pipfile.lock, it is generally recommended to include uv.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#uv.lock
+
+# poetry
+#   Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
+#   This is especially recommended for binary packages to ensure reproducibility, and is more
+#   commonly ignored for libraries.
+#   https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
+#poetry.lock
+#poetry.toml
+
+# pdm
+#   Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
+#   pdm recommends including project-wide configuration in pdm.toml, but excluding .pdm-python.
+#   https://pdm-project.org/en/latest/usage/project/#working-with-version-control
+#pdm.lock
+#pdm.toml
+.pdm-python
+.pdm-build/
+
+# pixi
+#   Similar to Pipfile.lock, it is generally recommended to include pixi.lock in version control.
+#pixi.lock
+#   Pixi creates a virtual environment in the .pixi directory, just like venv module creates one
+#   in the .venv directory. It is recommended not to include this directory in version control.
+.pixi
+
+# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
+__pypackages__/
+
+# Celery stuff
+celerybeat-schedule
+celerybeat.pid
+
+# SageMath parsed files
+*.sage.py
+
+# Environments
+.env
+.envrc
+.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/
+
+# pytype static type analyzer
+.pytype/
+
+# Cython debug symbols
+cython_debug/
+
+# PyCharm
+#  JetBrains specific template is maintained in a separate JetBrains.gitignore that can
+#  be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
+#  and can be added to the global gitignore or merged into this file.  For a more nuclear
+#  option (not recommended) you can uncomment the following to ignore the entire idea folder.
+#.idea/
+
+# Abstra
+# Abstra is an AI-powered process automation framework.
+# Ignore directories containing user credentials, local state, and settings.
+# Learn more at https://abstra.io/docs
+.abstra/
+
+# Visual Studio Code
+#  Visual Studio Code specific template is maintained in a separate VisualStudioCode.gitignore 
+#  that can be found at https://github.com/github/gitignore/blob/main/Global/VisualStudioCode.gitignore
+#  and can be added to the global gitignore or merged into this file. However, if you prefer, 
+#  you could uncomment the following to ignore the entire vscode folder
+# .vscode/
+
+# Ruff stuff:
+.ruff_cache/
+
+# PyPI configuration file
+.pypirc
+
+# Cursor
+#  Cursor is an AI-powered code editor. `.cursorignore` specifies files/directories to
+#  exclude from AI features like autocomplete and code analysis. Recommended for sensitive data
+#  refer to https://docs.cursor.com/context/ignore-files
+.cursorignore
+.cursorindexingignore
+
+# Marimo
+marimo/_static/
+marimo/_lsp/
+__marimo__/
+

CONTRIBUTING.md

@@ -0,0 +1,113 @@
+# Contributing to the Code of Conduct
+
+> [!NOTE]
+> This is a living document, and will grow with time. Please be aware
+> that nothing in this document will last forever. Check back whenever
+> you want to contribute.
+
+## How the Code of Conduct is created
+
+Rules are made from sections, these sections are in a
+`section{index}.toml` that you can find in `code_of_conduct/sections/`.
+This is done to standardise the code of conduct format, as well as
+making it portable in case it were to be used in our own Tux for
+example. There are some quirks with the format due to using Markdown
+which will be described in this document.
+
+## How to add new rules
+
+A rule can be added by opening the section you want to add a new rule
+to (read [here](#how-to-add-a-new-section) if you want to make a new
+section) and add something of the following format:
+
+```toml
+[[rule]]
+# EXPECTED TO EXIST
+title = "My new rule"
+description = """
+I am describing my new rule.
+"""
+
+# OPTIONAL
+[[rule.expectations]]
+expectation = "Mild"
+description = """
+Hello world! This is your punishment for doing something bad! Feel the
+wrath of the sword!
+"""
+
+[[rule.glossary]]
+word = "describing"
+meaning = "talking about"
+```
+
+You are expected to keep every line around 72 characters long for
+readability purposes. You also should aim to use listing less as
+paragraphs tend to work just about as well without being unmemorable.
+Make sure the quotes and the text are separate from each other for
+readability.
+
+## How to add a new section
+
+To create a new section, you can create a new file in
+`code_of_conduct/sections`. Preferably, you can name it
+`section{index}.toml` for consistency. You must write it out like below:
+```toml
+title = "My section"
+
+[[rule]]
+title = "My rule"
+description = "Description of my rule."
+
+# fill in the rest
+```
+
+## What to do after you made your changes
+
+CI is not setup for this yet. As such, you will have to set up a
+development environment for Python **3.11 and higher** to regenerate
+the README file. This isn't an annoying process but we will eventually
+add CI to make this step irrelevant.
+
+### Setting up your .venv
+
+Before setting up `.venv`, please make sure you are running version
+3.11 or above by running `python --version`. After checking and
+verifying that you have a high enough version, you can setup a .venv by
+running this command in your shell:
+```
+$ python -m venv .venv
+```
+This will create a .venv directory which will contain a local
+development environment you can access by sourcing `.venv/bin/activate`.
+You will want to check for an activation script that supports your shell
+however. If you are on PowerShell, you will need to source
+`.venv/bin/activate.ps1`, fish users must source `activate.fish` and so
+on with other shells.
+
+Once you are in your .venv environment, make sure pip is up to date by
+running this command:
+```
+pip install --upgrade pip
+```
+This is to prevent any vulnerabilities when installing software via pip,
+and therefore it will be safer. We will now need `poetry` as pip doesn't
+have a stable lockfile format as of now.
+
+To install `poetry`, you must run this command:
+```
+$ pip install poetry
+```
+You will then be able to use poetry to install our package as well as
+any dependencies needed for said package. This can be done by running
+the following command:
+```
+$ poetry install
+```
+
+You can then generate the README by running the following command:
+```
+$ python -m code_of_conduct
+```
+The README will then be modified to include your changed you made. You
+can now commit your work and make a pull request.