Please Indicate when you are being a naughty boy.

🤖 OpenChaos Bot

Summary: This PR changes the way maintenance PRs are excluded, using an explicit list instead of excluding based on the repo owner. This allows for more flexibility in designating maintenance PRs.

Files changed: 1 (src/lib/github.ts)

Vibe: Rebellion against the benevolent dictatorship!

openchaos-bot

Fixes #148. The first pass at an implementation uses an explicitly defined list of PRs to be excluded from the Hall, which would need to be updated in the event of any future maintenance. I'm open to other options such as the addition of a [maint] tag to the title of any such future PRs, but there is still the problem of #86 to contend with.

As a side effect, this would allow maintenance PRs from anyone who notices a problem and fixes it, and not just @skridlevsky.

#119 is not displayed on the Hall of Chaos.

This is caused by business logic which filters out the repo owner's PRs.

  // Filter to only merged PRs (not just closed), exclude repo owner's maintenance PRs
  // Sort by merge time (newest first) since sort=updated may not reflect merge order
  const REPO_OWNER = owner;
  return prs
    .filter((pr) => pr.merged_at !== null && pr.user.login !== REPO_OWNER)
    .sort((a, b) => new Date(b.merged_at!).getTime() - new Date(a.merged_at!).getTime())
    .map((pr) => ({
      number: pr.number,
      title: pr.title,
      author: pr.user.login,
      url: pr.html_url,
      mergedAt: pr.merged_at!,
    }));

While the understandable intent is to exclude maintenance PRs, the result is that pull requests authored by @skridlevsky which go through the normal voting process are also excluded. The logic should be updated to address this oversight.

I'm no CSS expert but would it be possible to add CRT-like filters such as scanlines and warping along the edges?

Eight days later, some thoughts.

@ro0NL nailed it - we can change the rules. This is by design. (There's a name for this: https://en.wikipedia.org/wiki/Nomic ↗)

Three proposals emerged here:

1. Commit-tied voting (@henryivesjones, @mario-donnarumma) Votes count for a specific commit SHA. Code changes = votes reset. Pro: Prevents bait-and-switch. Con: Typo fixes invalidate legitimate votes.

2. Reputation tracking (@md-weber, @addshore) Track author behavior across PRs. Repeat offenders face penalties. Pro: Self-correcting over time. Con: Needs a trust algorithm. Which one?

3. Self-correction (@matthewmayer) The system naturally punishes bad actors through revert PRs and reputation damage. No formal mechanism needed. Pro: Simple. Con: Relies on community vigilance.

Update: A TU Delft distributed systems lab is interested in our voting data for Sybil resistance research (https://github.com/Tribler/tribler/issues/8667). Some of these ideas - especially reputation tracking - align directly with their work.

Also building feed.openchaos.dev - a full event log with content hashes. Should help with 1 (tracking vote state per commit) and 2 (reputation over time).

No decisions yet. If you feel strongly, submit a PR to README.md.

I keep saying hello to it, and it does not respond at all

I understand. This could be a limitation of the speech-to-text interface. Did you use the best Browser? Keep in mind:

This site is OPTIMIZED for Netscape Navigator 4.0

And

Best Viewed in Internet Explorer 6.0 at 800x600 Resolution

🤦

🤖 OpenChaos Bot

Summary: This PR changes all instances of "sixseven" to "sixtynine", clearly targeting the funny number.

Files changed: 2 (src/app/globals.css, src/components/PRCard.tsx)

Vibe: This PR is immature giggling masquerading as refactoring.

openchaos-bot

This pull request increaces the shake effect number by two, making it twice as funny.