tibzejoker/anyPercent5

I contribute to AnyPS5, an open-source tool that ports PS5 executables to Linux and Windows, and some of my pull
requests wait days before anyone looks at them.
That isn't the maintainers' fault. Since coding agents arrived they get far more PRs than a small team can read,
so they did what many projects do: they capped intake. Newcomers wait, a few people carry all the review, and the
cap still doesn't stop a patient attacker who earns trust first (xz-utils, 2024).
any%5 is an attempt at a different setup. Everyone who sends code also reviews code. Reviewers don't choose what
they review, and their accuracy is measured with planted bugs. It all runs inside a normal GitHub repository with
one Action, so there is no server to host.
It's an experiment. I've simulated it and tested it end to end on GitHub, and this repository runs on it, but no
project with real outside contributors has tried it yet. I'd like to hear where it breaks:
issues, discussions.
https://github.com/user-attachments/assets/7324ee94-aff9-45b5-b625-42cddab37499
The rules
1. You review before you submit. It works like jury duty: everyone does it, and nobody earns their way out of it.
There's no reputation to build before you can contribute, and no reputation that gets you lighter checks.
2. Reviews are blind: you see a diff, not its author or title. Some diffs are tests, copies of real pending
changes that are either clean or have one bug planted in them. Finding the bug and naming its line raises your
score. Rejecting a clean copy lowers it. Reviewers are drawn at random from the better-scoring members.
3. The number of reviewers depends on what a change touches (CI, build scripts, dependencies, network, process
execution), not on who wrote it.
4. Tasks are leased. You tell the project what your machine can run (windows, gpu...) and claim a matching
task. If you stop pushing, the task goes back, and the next person picks up from your branch.
5. Approved changes go through a merge queue that runs the project's own tests, then land on main without
waiting for a maintainer. A release only includes changes that have been on main for 14 days.
6. If two randomly drawn auditors confirm a backdoor, the author is banned, their merged work is reverted, and
what their reviewers approved is checked again. An honest bug never gets anyone banned.
The full rules, and why each one is there, are in docs/METHOD.md. Here is a 4-minute
walkthrough for contributors and maintainers:
https://github.com/user-attachments/assets/5fed5c7e-0953-41d7-8da8-f761f5d0b4a3
Does it work?
I simulated 10,000 contributors over 90 days. Among them: lone attackers (1 %), colluding rings of 5 (1 %), a
ring that rejects everything (5 %), careless reviewers (20 %), and honest reviewers who wrongly reject 3 to 10 %
of clean changes. Each run is averaged over 5 seeds, and about 17 % of people are online at any time.
| | Trust levels + review credits | any%5 |
|---|---:|---:|
| Changes merged per day | 2,032 | 2,339 |
| Median time to merge | 17.6 h | 3.0 h |
| Honest changes closed by wrong rejects | 17.7 % | 0.4 % |
| Backdoor attempts that reach main and survive the 14-day soak | 23-26 % | 18-19 % |
If only insiders may submit and review, merges drop to zero by day 90: insiders leave and nobody replaces them.
I'm confident about throughput. It grows linearly from 10 to 100,000 members with no maintainer in the loop. The