docs: apply most review

.envrc

@@ -1 +1,2 @@
-use flake . --impure
+use flake . --impure
+export TYPST_ROOT="$(pwd)/docs"

CODE_OF_CONDUCT.md

@@ -3,7 +3,6 @@ The current maintainers, that is,
 
 - [@Schrottkatze](https://forge.katzen.cafe/schrottkatze)
 - [@multisamplednight](https://forge.katzen.cafe/multisamplednight)
-- @iota-xSK
 
 are the entities to email, message or talk to if you feel like any interaction in the context of
 iOwO is not okay. We'll try to answer as soon as we can.

CONTRIBUTING.md

@@ -4,35 +4,35 @@ Before we get started, thank you for thinking about doing so!
 
 ## Through an issue
 
-- Be excellent to each other. Adhere to the [code of conduct].
+- Be excellent to each other. Adhere to the [code of conduct]
 - About the title: If you had 5 seconds to tell someone the essence of the issue, what would it be?
 
 ### Bugs
 
-- Write out in detail which steps in which order are necessary to reproduce the bug.
+- Write out in detail which steps in which order are necessary to reproduce the bug
 - Include environmental information as well, in specific
   - How did you install iOwO?
   - What version of iOwO are you running?
   - What operating system are you running?
-    In the case of a Linux distro, mention the specific distro and when you last update as well.
+    In the case of a Linux distro, mention the specific distro and when you last update as well
-- If the bug causes a crash, try to get a backtrace or in worse cases, a coredump.
+- If the bug causes a crash, try to get a backtrace or in worse cases, a coredump
 
 ### Feature requests
 
-- Be sure to include a motivation in which case your intended feature would be used,
+- Be sure to include a motivation in which case your intended feature would be used
-  even if it seems obvious to you.
+  even if it seems obvious to you
-- Estimate what would be needed to implement the feature.
+- Estimate what would be needed to implement the feature
   - Is it an addition to the language itself?
   - Is it just a new command?
   - Does it ground-breakingly change how iOwO works?
 
 ## Through a PR
 
-1. Clone the repo.
+1. Clone the repo
-2. Switch to a new appropiately named branch for what you want to do, using `git switch -c`.
+2. Switch to a new appropiately named branch for what you want to do, using `git switch -c`
-3. Implement your code changes with your favorite code editor.
+3. Implement your code changes with your favorite code editor
-4. Try them with `cargo run`.
+4. Try them with `cargo run`
-5. If there are errors or warnings, go to step 3. Commit occasionally.
+5. If there are errors or warnings, go to step 3. Commit occasionally
 6. Otherwise,
   - if you have an account at https://forge.katzen.cafe,
     1. fork the repo
@@ -42,6 +42,8 @@ Before we get started, thank you for thinking about doing so!
     1. combine your patches using `git diff --patch` and throw them in a file
     2. send that file to one of the maintainers per email
       - alongside with a description of what it does
+    3. also mention in the mail that we should consider GitHub and GitLab mirrors,
+       referring to this line
 
 ### Tech stack
 
@@ -68,28 +70,28 @@ If you want to contribute art or the like, do that in whatever **you** are most
 
 ## Politics
 
-- Current maintainers are defined as the entities listed in the [code of conduct].
+- Current maintainers are defined as the entities listed in the [code of conduct]
 
 ### PRs
 
-- Every PR requires an approving review from a maintainer (that is not the author) before merge.
+- Every PR requires an approving review from a maintainer (that is not the author) before merge
-- Maintainers can merge their own PRs.
+- Maintainers can merge their own PRs
-  - But only after approval.
+  - But only after approval
 
 ### Major decisions
 
-- All current maintainers have to agree **unanimously**.
+- All current maintainers have to agree **unanimously**
-- Agreement must be based on [informed consent].
+- Agreement must be based on [informed consent]
-  - In effect, a maintainer has to understand what they agree to.
+  - In effect, a maintainer has to understand what they agree to
 
 # Interacting with PRs
 
-> [!NOTE] Remember, be respectful.
+Remember, be respectful.
-> Entities invest their free time and motivation into making these changes,
+Entities invest their free time and motivation into making these changes,
-> treat them appropiately.
+treat them appropiately.
 
-- Since in iOwO, we mostly work based on forks, [git's remotes] work fairly good.
+- Since in iOwO, we mostly work based on forks, [git's remotes] work fairly good
-- Replace things in pointy brackets (`<>`) respectively (and remove the pointy brackets).
+- Replace things in pointy brackets (`<>`) respectively (and remove the pointy brackets)
 
 ## Initial steps for a new contributor or new local checkout
 
@@ -100,8 +102,8 @@ git remote update <contributor-name>
 
 ## After setting up the remote
 
-- You can repeat this step anytime you want to switch branches or update your local checkout.
+- You can repeat this step anytime you want to switch branches or update your local checkout
-- The PR branch is visible just below the PR title on forgejo, after the colon (`:`).
+- The PR branch is visible just below the PR title on Forgejo, after the colon (`:`)
 
 ```sh
 git switch <pr-branch>

docs/design/iowo-design.typ

@@ -7,19 +7,7 @@
   subtitle: [don't worry, we're just dreaming],
 )
 
-= Type data model
+= Evaluation stages
-
-== Requirements
-
-- Color-aware
-  - It can handle colors and colorspaces for images
-  - OpenColorIO?
-- number/number type support
-- custom types (structs/enums)
-- algebraic enums
-- traits (`Numeric`...)
-
-= Execution stages
 
 #graphics.stages-overview