2024-01-07 20:43:26 +00:00
|
|
|
# Contributing to iOwO
|
|
|
|
|
|
|
|
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].
|
|
|
|
- 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.
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
- 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.
|
|
|
|
6. Otherwise,
|
|
|
|
- if you have an account at https://forge.katzen.cafe,
|
|
|
|
1. fork the repo
|
|
|
|
2. set it up as a remote using `git remote add`
|
|
|
|
3. push using `git push @ -u`
|
|
|
|
- if you don't,
|
|
|
|
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
|
|
|
|
|
|
|
|
### Tech stack
|
|
|
|
|
|
|
|
The techstack we operate on is
|
|
|
|
|
|
|
|
- [typst] for documents and concrete proposals
|
|
|
|
- [Rust] for the actual code
|
|
|
|
- [Inkscape], [GIMP] and [Blender] for promotional material like logos and posters
|
2024-01-09 09:27:07 +00:00
|
|
|
- [Penpot] for layouting prototypes and the like
|
2024-01-07 20:43:26 +00:00
|
|
|
|
|
|
|
So if you want to contribute functionality, take a look at [The Rust Programming Language book]!
|
|
|
|
If you want to contribute thoughts and techincal designs, then consider taking a ride through
|
|
|
|
[typst's excellent tutorial]!
|
|
|
|
If you want to contribute art or the like, do that in whatever **you** are most comfortable with!
|
|
|
|
|
|
|
|
[typst]: https://typst.app
|
|
|
|
[Rust]: https://www.rust-lang.org
|
|
|
|
[Inkscape]: https://inkscape.org/
|
|
|
|
[GIMP]: https://www.gimp.org/
|
|
|
|
[Blender]: https://www.blender.org/
|
2024-01-09 09:27:07 +00:00
|
|
|
[Penpot]: https://penpot.app/
|
2024-01-07 20:43:26 +00:00
|
|
|
[The Rust Programming Language book]: https://doc.rust-lang.org/book/
|
|
|
|
[typst's excellent tutorial]: https://typst.app/docs/tutorial
|
|
|
|
|
|
|
|
## Politics
|
|
|
|
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
|
|
[code of conduct]: ./CODE_OF_CONDUCT.md
|
|
|
|
[informed consent]: https://en.wikipedia.org/wiki/Informed_consent
|
|
|
|
|