How OpenChaos.dev's Weekly Voting and PR Merge Process Works

OpenChaos.dev is a self-evolving open source project where the community votes on submitted pull requests each week, and the PR with the most votes gets merged. The site frames this as "Control vs Chaos": instead of a fixed maintainer roadmap, the direction of the project is decided by whoever shows up to vote. If you want to influence what the codebase becomes, the loop is: submit or find a PR, get votes before the countdown hits zero, and watch the winner land.

The weekly cycle

The project runs on a repeating weekly rhythm rather than a continuous merge queue. Each cycle has three visible stages:

1. Submission — pull requests are open for the community to review and discuss.
2. Voting — community members vote on the PRs they want to see merged.
3. Merge — when the countdown reaches zero, the highest-voted PR is merged into the project.

The site displays a Next Merge Countdown (--h --m --s) that tells you exactly how much time is left before the current round closes. That timer is the single most important number on the page — it defines your deadline for both submitting and campaigning for votes.

What the countdown actually gates

The countdown is not decorative. It marks the boundary between one decision round and the next. Practically, that means:

• A PR submitted after the timer expires belongs to the next week's round, not the current one.
• Votes cast are only meaningful within the round they're cast in — the winner is decided at the moment the countdown ends.
• There is no "merge whenever it's ready" path for a losing PR; it has to compete again in a later round (or be revised and resubmitted).

The winner's path

Once the countdown ends, the process is deliberately simple: the PR with the most votes is selected as the winner, and the winning PR is merged into the project. There's no maintainer veto described in the site's own framing — the vote is the decision.

The site also keeps a Hall of Chaos — Past Winners section, which is where merged winners are recorded. That hall is the historical record of how the project has evolved week by week.

A practical example

Say you want to add a feature to OpenChaos.dev. Your sequence looks like this:

1. Open a pull request against the project.
2. Share it where the community will see it, and make the case for why it should win.
3. Watch the countdown. If you're short on votes as the timer runs down, you have until zero to change minds.
4. When the countdown hits zero, if your PR has the most votes, it gets merged. If not, it doesn't — and you can try again next round.

The same logic applies if you're only voting: your vote matters most when it's cast before the timer expires, and it matters more in a close round than a landslide.

Known rough edges

The site's own page shows a "GitHub API error: 404" message in place of the winner list, with the note "Try refreshing the page in a minute." That means the Hall of Chaos and possibly other GitHub-backed sections can fail to load when the API call doesn't succeed. If you see that error, the voting and merge mechanics themselves are unaffected — it's the display of past winners that's broken. Refreshing is the suggested fix.

What this model means for you

The core takeaway: OpenChaos.dev replaces maintainer discretion with a weekly popular vote. The countdown is the deadline, the vote is the decision, and the merge is the outcome — every week, on repeat.