docs: some initial groundwork #2
4 changed files with 31 additions and 41 deletions
3
.envrc
3
.envrc
|
@ -1 +1,2 @@
|
|||
use flake . --impure
|
||||
use flake . --impure
|
||||
export TYPST_ROOT="$(pwd)/docs"
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
- If the bug causes a crash, try to get a backtrace or in worse cases, a coredump.
|
||||
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
|
||||
|
||||
### Feature requests
|
||||
|
||||
- Be sure to include a motivation in which case your intended feature would be used,
|
||||
even if it seems obvious to you.
|
||||
- Estimate what would be needed to implement the feature.
|
||||
- Be sure to include a motivation in which case your intended feature would be used
|
||||
even if it seems obvious to you
|
||||
- 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.
|
||||
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.
|
||||
4. Try them with `cargo run`.
|
||||
5. If there are errors or warnings, go to step 3. Commit occasionally.
|
||||
1. Clone the repo
|
||||
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
|
||||
4. Try them with `cargo run`
|
||||
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.
|
||||
- Maintainers can merge their own PRs.
|
||||
- But only after approval.
|
||||
- Every PR requires an approving review from a maintainer (that is not the author) before merge
|
||||
- Maintainers can merge their own PRs
|
||||
- But only after approval
|
||||
|
||||
### Major decisions
|
||||
|
||||
- All current maintainers have to agree **unanimously**.
|
||||
- Agreement must be based on [informed consent].
|
||||
- In effect, a maintainer has to understand what they agree to.
|
||||
- All current maintainers have to agree **unanimously**
|
||||
- Agreement must be based on [informed consent]
|
||||
- In effect, a maintainer has to understand what they agree to
|
||||
|
||||
# Interacting with PRs
|
||||
|
||||
> [!NOTE] Remember, be respectful.
|
||||
> Entities invest their free time and motivation into making these changes,
|
||||
> treat them appropiately.
|
||||
Remember, be respectful.
|
||||
Entities invest their free time and motivation into making these changes,
|
||||
treat them appropiately.
|
||||
|
||||
- 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).
|
||||
- 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)
|
||||
|
||||
## 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.
|
||||
- The PR branch is visible just below the PR title on forgejo, after the colon (`:`).
|
||||
- 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 (`:`)
|
||||
|
||||
```sh
|
||||
git switch <pr-branch>
|
||||
|
|
|
@ -7,19 +7,7 @@
|
|||
subtitle: [don't worry, we're just dreaming],
|
||||
)
|
||||
|
||||
= Type data model
|
||||
|
||||
== 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
|
||||
= Evaluation stages
|
||||
|
||||
#graphics.stages-overview
|
||||
|
||||
|
|
Loading…
Reference in a new issue