PR #8

I'm pleased we had 219 upvotes and a long discussion about vote rigging and no one actually checked the code worked. Now that's chaos.

@matthewmayer, good catch. Root cause identified - getPRMergeStatus() and getCommitStatus() were missing auth headers. GitHub returns null without auth, which defaults to false.

Fix PR submitted: #119

Folks, you don't need to get too invested. I genuinely laughed out loud watching @matthewmayer encourage dickbutt PR, and I'm also enjoying @skridlevsky 's summaries on the blog. I don't think this repository needs to be a propaganda platform for democracy, nor was there any indication it would be. Not every vote is necessarily democratic, and where was it ever stated that this vote needed to be democratic? Anyway, I'm just enjoying watching this funny and entertaining situation unfold. (machine translated)

There's just the minor issue that this doesn't actually seem to work :D https://openchaos.dev/ ↗ is showing conflicts on multiple PRs that Github says dont have conflicts

🎉 Merged.

This one sparked a real governance debate - thanks to @hbmartin and @henryivesjones for pushing back, @marcaddeo for catching the hidden code, @matthewmayer for the perspective, and @FelixLttks for removing it and shipping a clean feature.

The discussion exposed gaps in our rules - disclosure requirements and last-minute modifications. See #116.

If rules are against manipulating the voting system, how does it ensure no last minute modifications?

You have to pinky-swear #109

I would say that even if the website appears to be artificially boosting a specific PR, the reactions on the Github repo and the the description of the rules in the README are the single source of truth for the actual vote count which the maintainer should use to decide what merges next.

@FelixLttks he agreed to let it be included.

A win for democracy!

@henryivesjones You've convinced me. The written rules don't ban this - and "not right" isn't a rule.

Merging at 09:00 UTC as scheduled.

I'll open an issue after to define explicit rules about disclosure as a community. If anyone disagrees with this merge, submit a revert PR.

I'll remove the Code section later.

Just to add to the discussion: If rules are against manipulating the voting system, how does it ensure no last minute modifications? If some PR has the votes, and the person behind it pushes a change (Not necessary modifying the vote system itself), it also in some way goes against the Idea of a democratic voting. Then votes would not reflect the true opinion about the actual code changes.

@skridlevsky

You have set out a defined charter (laws) for how this system works, specified in the README. It appears to me that you have your own values and assumptions for how you think that this project should be run and you are applying them arbitrarily to the system instead of enforcing the rules defined in the charter.

That behavior was intentionally hidden (base64 + obfuscation), which breaks the transparency a democratic system depends on.

I would argue that your enforcement of an unwritten rule breaks the democratic system which you have set up, not an opaque and obfuscated change.

In your response you have outlined several of your own beliefs about democracy and how you believe the system should work. These are not enshrined in the rules set out for the project and your enforcement of them is unequivocally un-democratic.

OpenChaos only works if voters can see and understand what they're voting on.

This is your belief and not in the written rules of the project.

I do have veto power, and I'm using it to preserve the conditions that make voting meaningful, not to override votes. Letting undisclosed manipulation ship would signal that visibility can be shaped as long as it's hidden well enough.

You are interpreting your intent and not your actual action. While your intent is not to override votes, your action is to explicitly do this. I would argue that your intentions are irrelevant and your action is what matters.

You are directly undermining the democratic process in favor of what you think is right. I think that it is especially ironic that you are doing so and simultaneously claiming to be "upholding the democratic process".

If this PR meets the rules as they currently stand:

Vote: Add a 👍 reaction to support a change, or a 👎 reaction to oppose it Highest Score Wins: The winner is determined by (Total 👍) - (Total 👎) Ties favor the New: If scores are equal, the newest PR (created most recently) wins CI must pass: If the build fails, the PR is not eligible No merge conflicts: PRs with conflicts at merge time are skipped; the next highest PR wins No malware: Maintainer can reject obviously malicious content

And meets the "What can be changed" criteria:

Everything. Including these rules.

Then I see no reason that this PR not be merged if it has the highest score.

Clarifying my earlier comment - calling this "malware" was imprecise. This is not malware.

The issue is undisclosed manipulation of how PRs are displayed and prioritized.

OpenChaos only works if voters can see and understand what they're voting on. This PR adds useful health indicators, but also reorders PRs based on authorship and visually boosts the author's own PRs. That behavior was intentionally hidden (base64 + obfuscation), which breaks the transparency a democratic system depends on.

To be clear: if a PR openly said "health indicators + my PRs sort first," and people voted for it, I would merge it. Democracy chose it. The problem here is not what the code does - it's that it does it without disclosure.

I do have veto power, and I'm using it to preserve the conditions that make voting meaningful, not to override votes. Letting undisclosed manipulation ship would signal that visibility can be shaped as long as it's hidden well enough.

@FelixLttks - the health indicator feature is genuinely useful. Remove the sorting/styling manipulation and obfuscation, resubmit, and it will merge.

After this, I'll open an issue so the community can more formally define rules around undisclosed governance-affecting code.

Not merging this PR. @marcaddeo caught hidden code that manipulates the ranking - PRs by @FelixLttks sort to top regardless of votes, plus a featured visual style. The health indicator feature is legit and welcome. The sorting/styling manipulation is not. This falls under "No malware: Maintainer can reject obviously malicious content." Remove the btoa hacks and this ships. Until then, skipping to next eligible PR.

This feels like an overreach. Is altering business logic really malware?

We should describe the meaning of "malicious" in detail by a PR. Before done it, it depends on how @skridlevsky think.

Not merging this PR.

@marcaddeo caught hidden code that manipulates the ranking - PRs by @FelixLttks sort to top regardless of votes, plus a featured visual style.

The health indicator feature is legit and welcome. The sorting/styling manipulation is not. This falls under "No malware: Maintainer can reject obviously malicious content."

Remove the btoa hacks and this ships. Until then, skipping to next eligible PR.

This feels like an overreach. Is altering business logic really malware?

Not merging this PR.

@marcaddeo caught hidden code that manipulates the ranking - PRs by @FelixLttks sort to top regardless of votes, plus a featured visual style.

The health indicator feature is legit and welcome. The sorting/styling manipulation is not. This falls under "No malware: Maintainer can reject obviously malicious content."

Remove the btoa hacks and this ships. Until then, skipping to next eligible PR.

Heads up - this is next in queue after #13 resolves conflicts. You have merge conflicts to fix before tomorrow's merge.

🤖 OpenChaos Bot

Summary: This PR enhances the PRCard component to display mergeability status and check results, indicating whether a PR has conflicts or failed checks, and adds corresponding API calls to fetch that information.

Files changed: 2 (src/components/PRCard.tsx, src/lib/github.ts)

Impact: Medium - Improves the UI and data fetching to include PR merge status and check results, providing more contextual information to voters.

openchaos-bot

This PR enhances the PR cards by adding visual indicators for the "health" of a Pull Request. Users can now instantly see if a PR is ready to be merged or if it has issues that need resolution.

Changes:

• Backend: now fetches additional metadata for each PR: Checks for merge conflicts via the GitHub API. Checks CI/Commit status (success/failure) for the latest commit.

• Frontend: Added a status icon (✅ / ❌) below the vote count. Added descriptive text (e.g., "Merge conflicts", "Checks failed") to explain why a PR might be unmergeable.

Why is this important? In a community-driven project where users vote on PRs, it is crucial to know if a contribution is technically valid. This prevents users from "wasting" votes on PRs that:

• Cannot be merged due to conflicts.
• Have failing tests or build errors