RESENTMENT OS 2.0.0

Governance

Small project, honest structure. This document exists so that nobody has to guess how a decision gets made.

Who decides

RESENTMENT OS is maintained by @PIYUSH-MISHRA-00, who has final say on design and merges. That is a benevolent-dictator model, and it is the right one at this size; pretending otherwise would be theatre.

It is intended to change. The path is written down here rather than left implicit.

Becoming a maintainer

There is no application. The maintainer invites people who have, over time, landed changes that needed real judgement, reviewed other people's changes usefully, and shown they will say "I don't know" and "this is wrong, including when I wrote it". Maintainers get merge rights and are listed in .github/CODEOWNERS. Areas can be owned separately: someone can own the provider layer without owning the lease system.

How decisions are made

Ordinary changes. One maintainer approval, CI green. If the author is a maintainer, still one other approval.

Design changes, meaning anything that alters the os object's surface, a tool's scope, what the digest covers, what the vault stores, or what leaves the browser, go through an issue first with the alternatives written down. The bar is not consensus; it is that the objections have been answered.

Disagreement. In the open thread. If it does not converge the maintainer decides and records the reasoning. A decision with a written reason can be revisited by someone with new information.

Reverting. Anything can be reverted by any maintainer if it breaks make test or the deployed desktop. Re-landing after a fix is the normal path.

What "no" looks like

ROADMAP.md has a section of things this project has decided not to do, with the reason for each.

Branches and releases

v2.0.0 is the operating system; main is the website and these files; v1.0.0 is history. Semantic versioning on the OS as a whole:

A release is tagged from the version branch only when make test and make qemu-test both pass from a clean tree, and the kernel submodule points at a tagged kernel release. CHANGELOG.md is written before the tag.

The kernel

The kernel has its own governance, in its own repository. This project does not carry kernel patches; it bumps the submodule pointer.

Code of conduct

CODE_OF_CONDUCT.md applies to every space this project uses. Report to @PIYUSH-MISHRA-00, or through a private security advisory if the matter is sensitive.

Licence and provenance

Apache 2.0, no CLA. If you contribute code you did not write, say so and say where it came from. The Markdown renderer in tools/mksite.py came from the kernel's site, by the same author, under the same licence, and is credited in the file.