matthewmayer

Incoporated into https://github.com/skridlevsky/openchaos/pull/211

The maintainer is a naughty boy.

Then we need to start a gift shop for the museum to gain enough revenue to fund the AI bill.

Please note the dickbutt has been moved to the Museum https://www.openchaos.dev/museum ↗ so i think it should remain as an important part of our shared heritage.

Achievement for creating a PR? As you dont do this on website directly, would need to check the PR list to see if there's an open or closed PR for the logged in user.

In that vein, I worked to make adding new themes easier with #204. I didn't do an "internet through time" theme because I thought it might feel quite limiting, but I think it's actually worth re-exploring.

Its a very good solution, https://github.com/skridlevsky/openchaos/pull/208 was WAY easier to implement as i could do it as a seperate theme rather than figure out how it would need to interact with every other theme

This is fun. Who pays the bill?

See https://docs.puter.com/user-pays-model/ ↗ - every user gets some free usage on their own Puter account, heavy users would be billed

If the museum is set up successfully we would appreciate new donations to the museum via new PRs.

https://github.com/skridlevsky/openchaos/pull/106#issuecomment-3931932228

So close and yet so far

https://github.com/skridlevsky/openchaos/actions/runs/22262637496/job/64403250325#step:5:1

rhymesWith can't be resolved.

Should also do the check in the automated daily merge action.

ControlledChaos component doesn't really fit well. Suggest either restyle it to match or just remove from this theme (not every theme needs to support every component)

Any chance of making it fit the ascii theme better?

My assumption is that if the daily action works, @skridlevsky will no longer do manual daily merges.

If the action fails he should manually do the merge following the RULES.

Suggest also adding an explanation of how to add a pitch to README .

Doesn't look like there's any risk of injection here

Famous last words

Should truncate to a length limit, to avoid paragraph-long or site-breaking pitches? Eg PR titles are generally max 70 chars and GitHub has a hard limit of 256.

Now that #163 has landed I think an interesting medium term goal which multiple people could work on together could be to try to make the different themes more like reimaginings of how the openchaos website would appear at different times in Internet history.

So they don't necessarily all have to have the same functionality. And we try to avoid anachronisms.

Eg ascii theme might remove emojis and might disguise the discord link behind "View our BBS"

Web2 might add payments https://github.com/skridlevsky/openchaos/pull/198

A future web3 theme might reference blockchain and AI etc.

Still lots of chaos but without needing to style every new component N ways.

Now that #163 has landed I think an interesting medium term goal which multiple people could work on together could be to try to make the different themes more like reimaginings of how the openchaos website would appear at different times.

So they don't necessarily all have to have the same functionality. And we try to avoid anachronisms.

Eg ascii theme might remove emojis and might disguise the discord link behind "View our BBS"

Web2 might add payments https://github.com/skridlevsky/openchaos/pull/198

A future web3 theme might reference blockchain and AI etc.

Still lots of chaos but without needing to style every new component N ways.

Personally I think it should only appear on web2. In the ASCII era we didn't try to charge for everything 😀

As far as I can see there's not actually an enforced cap as described above in the final merged code? Two PRs died today even though there are < 100 PRs currently.

Would it be possible to minimize by default on smaller screens? it's basically unusable on smaller mobile devices as it covers nearly the whole screen (i appreciate Clippy is also pretty bad in this regard)

Cat does not enjoy the player being minimized

https://github.com/user-attachments/assets/664bb840-5c1b-43ec-b66f-7fde04650ff4

this and a few other files were likely added by mistake in this PR

this can be refactored to make it more DRY and avoid a combinatorial explosion i.e.

const issues = [];

if (!pr.isMergeable) issues.push("Merge conflicts");
if (!containsRhymes) issues.push("No rhyme");
if (!pr.hasPicture) issues.push("No pic");
if (!pr.checksPassed) issues.push("Checks failed");

Would it be possible to change the style to ASCII so it matches the current theme? It sticks out a lot at the moment

This seems way too aggressive at the moment then. It's pretty normal to need frequent rebasing to resolve conflicts after the daily merge. And agree it's going to be biased towards people whose time zone means they are awake after the daily merge. I would consider some combination of

• make the dirty multiplier much lower (1.5?)
• run less frequently (eg weekly cull)
• cap daily deaths (eg 1 per day, pick randomly from all marked for possible death)

I appreciate your commitment to the ASCII cause

The Reaper comes with a fatal urge, Memento Mergi — remember to merge! But check #122 for one last time: To get this in, your title must rhyme!

The OIA Cat is a furry delight, And the meows in the code sound exactly right. But per #122, to merge in time, You must change the title to make it rhyme!

Currently I see it more as a collaborative art project in the vein of Reddit's r/place

Collaborative online projects can create great things (Wikipedia) or more commonly a lot of nonsense.

What really separates the successful projects is having a common goal or goals to work towards. That's currently lacking.

Perhaps it should increase by a random integer each time.

I note you can keep on upvoting multiple times and the apparent score gets bigger and bigger. Bug or feature?

We could also probably do this by just allowing you to view the site with any previous revision, Time Machine style.

That load-bearing coconut looks mighty fine, But see #122 for a change in design. To get this merged in and avoid the purge Your title must rhyme if you want to merge!

I'm doubtful that's the issue, as if so then removing scope=public_repo would fix it

Is the client_id definitely correct: Iv23litere2a5PqwFTuc

@skridlevsky

I think the tricky thing is that due to the nature of this project, any significant PR requires multiple rebases and tweaks between when its submitted and when it merges to stay up to date with main. For example my https://github.com/skridlevsky/openchaos/pull/130 has needed several fairly complex tweaks to keep the spirit of other PRs alive (e.g. when the Clippy PR landed, I made an ASCII clippy version). If the votes reset every time, I'd lose interest.

Oh, the irony is thick and the timing is peak, In the OpenChaos repo, the future looks bleak. This PR demands that my title must rhyme, But now there's a regression at the worst time

My PR is ready, my verses are gold But the "Edit" button is gone, or so I am told :(

https://www.reddit.com/r/github/comments/1qvmsvm/edit_button_on_prs_seems_to_have_disappeared/ ↗

What about existing PRs that don't yet rhyme? I don't see a way to change an existing PRs title and if you close and resumit, there goes your votes.

To fix a title that doesn't chime You needn't commit a voting crime. Just click on Edit and engage Near the top of the PR page Rewrite the words to make them flow Then hit Save and you're good to go!

I don't mind them opening a new PR with the same stuff :) I think that's great, but they would loose al votes ect. and I think it would clean it up in a fun and chaotic way!

i mean, you can reopen a closed PR (provided it hasnt been merged) and keep the existing votes

The problem with these various attempts to auto-close old PRs is that nothing prevents the author from reopening them again. If you really want to prevent old PRs from being merged, you need a rule that excludes them.

PR https://github.com/skridlevsky/openchaos/pull/109 demonstrated that a PR author can collect votes on a harmless diff, then force-push completely different code before the automated merge

um, i pinky-sweared that i would not do that.

Well this is exciting!

Equivalent code was included in the merged https://github.com/skridlevsky/openchaos/pull/76 freeDoom pull, so this will no longer be needed.

Need to edit the PR tire too then

The auto merging PR is already depending on the implicit rule, I just explicitly described it.

Currently, the upvote of this PR is just 11, so it is enough just to mention the added rule in the title of PR. (Lazy thinking, maybe)

I'd say the opposite is currently true: the human rules override the GitHub actions. So although there's a (broken) automatic weekly merge the maintainer follows the README and merges daily.

Similarly I would expect this PR to add a bullet point in the README that the oldest PR gets closer each week (and if for some reason the action failed the maintainer would do it manually)

I don't think we need any additional settings for this to work. It should work as written.

Reviewing the changes, the more notable part is the README addition:

Code is Law: Rules are for human guidance. If a GitHub workflow contradicts written rules, the workflow (code) takes precedence. Always inspect the codebase to understand the actual system behavior.

The real question is whether the community wants a "Code is Law" clause.

I agree, this is a bigger deal than the actual code change, and should be probably split into a different PR as its the opposite of the status quo.

gh pr list \
  -L 1000 \
  --search "sort:reactions-+1-desc state:open" \
  --json number,title,mergeable,reactionGroups \
  | jq -r '.[] | 
    (.reactionGroups | map(select(.content == "THUMBS_UP"))[0].users.totalCount // 0) as $up | 
    (.reactionGroups | map(select(.content == "THUMBS_DOWN"))[0].users.totalCount // 0) as $down | 
    "\($up - $down)\t#\(.number) | +:\($up)/-:\($down) \(if .mergeable == "CONFLICTING" then "| CONFLICTING" else "" end) | \(.title)"' \
  | sort -nr

While the site is in whiteout mode, if you have https://cli.github.com/ installed you can run this to get a quick view of all open PRs. Output looks something like this:

480	#13 | +:753/-:273 | CONFLICTING | Rewrite it in rust
75	#12 | +:87/-:12 | CONFLICTING | Add 17 languages and a snow overlay
55	#129 | +:55/-:0  | Deprioritize PRs with merge conflicts in ranking
42	#76 | +:43/-:1  | Runs freeDoom
41	#68 | +:44/-:3 | CONFLICTING | Implement asteroids on the homepage
36	#5 | +:47/-:11 | CONFLICTING | added informative video 😁
34	#90 | +:46/-:12  | 💨 Add fartscroll.js

Vercel seems to have cached the blank page at https://www.openchaos.dev/ ↗ :D Great job team. CHAOS.

But does it go brrr?

Now with ASCII Clippy

To verify a rhyme with a call to the cloud, Is a method too heavy, too slow, and too loud. To burn up a token for "cat" matching "hat," Is killing a fly with a baseball bat.

If the maintainer can trivially fix bugs in merged PRs that's boring.

Let the community decide if it's more important to have maintenance fixes or more cat gifs.

Rebased with https://github.com/skridlevsky/openchaos/pull/71

Now includes an ASCII cat

https://github.com/user-attachments/assets/be1c796a-e927-49f2-834e-451ce0b1899a

if I make a PR that reverts this, would people vote it? I kinda hate the aesthetic 😅

personally i think a straight revert is a bit boring so i have proposed a new theme at #130 which may eventually get merged.

Closing this as I have found new ways to annoy @skridlevsky

Added a requirement for maintainers who bypass the voting process.

Website text should consist of only ASCII encodeable characters.

vote for #130 !

this doesnt match the merge time in Countdown.tsx

If this gets merged as-is I think what will actually happen is:

• Every Sunday at 00:00 UTC the action will run (as it's on the original weekly schedule)
• It will find the most upvoted item which is https://github.com/skridlevsky/openchaos/pull/13 (only counts +1s)
• It will attempt to merge, and that will fail due to merge conflicts (https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#merge-a-pull-request)

So actually a fairly harmless outcome. The broken "Rewrite it in Rust" PR actually protects anything bad from happening.

Manual daily merges would still be the responsibility of the maintainer.

IE6 is great, but lets go even more retro: https://github.com/skridlevsky/openchaos/pull/130

GUIs are so overrated. If we're going retro, lets go proper retro.

Could we also detect actual shaking of device eg

https://dt.in.th/Shake ↗

Impact: Medium - This introduces a new, non-essential feature that modifies the site's appearance based on user interaction. While not critical, it adds an interactive element that can potentially be distracting or fun, depending on user preferences.

It doesnt feel like it appreciates the point of the repo ;)

Maybe the prompt could be tweaked to make it assess how chaotic the proposed changes are.

For the downvoters, just know that you are not anonymous... (ง'̀-'́)ง

there's a 1/8 chance we're actually upvoting you

Enforces a new rule that PRs must contain two rhyming words to be eligible for merge

• ✅ "Add a cat wearing a hat"
• ✅ "It's a must, rewrite in Rust"
• ✅ "the code is a shambles, click if you dare, your upvotes are gambles"
• ❌ "Fix bug in component"

Demo with altered PR titles:

You should also update the README to clarify at what .Beat the daily merge should occur

It would be nice if the bot could edit its comment if further commits are made to the PR after creation.

The current code defaults to believing everything is broken until proven otherwise. This is the only rational way to view modern software engineering.

To fix this is to suggest that we deserve green checkmarks. We do not. Leave the red warning signs as a monument to our sins.

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.

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

I think technically it is very hard to prevent against a bait and switch if an issue has accumulated a large number of upvotes, and then the author pushes something just before the deadline ( as I allude to in #109 ).

Invalidating all upvotes on any commit seems like a draconian solution which would affect genuine PRs. You might have a great idea, and then want to fix a typo in the README.

But I think this should be self-correcting. If a bait-and-switch PR gets merged, then two things "should" happen in a healthy system:

1. A PR to revert the bad change should gain upvotes
2. People would likely be suspicious of the author in future and their future PRs would likely get many downvotes

For #1 for me an open question is whether #1 on the website === winner. I had thought that the winner was decided purely based on the github data. As long as the winner is decided on the github data, then you can do whatever you want on the website side. Manipulation of stats and display is simply affecting perception and exposure. Much like fake news and biased reporting do in democracies.

I agree with this - as I wrote here https://github.com/skridlevsky/openchaos/pull/8#issuecomment-3771674383

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.

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.

Yes. We should add a weeks, months and years counter too.

I never thought I'd say this, but @Mad182 you need to resolve the dickbutt merge conflicts urgently to save us from getting #63 merged tomorrow.

so you only have to verify whether I lie or not.

Do you lie or not?

I have carefully reviewed all 3617 additions and 7603 deletions by hand.

LGTM

Now IE6-compatible

Add a useful explainer video to show how the maintainer @skridlevsky merges winning pull requests

https://github.com/user-attachments/assets/3e2c8558-ffd9-4528-b0fe-a21363375895

inconsequential

how dare you, @openchaos-bot

If our benevolent dictator @skridlevsky is expected to merge daily, perhaps he can suggest what time of day he will be awake (given this changes the merge time from 0900 to 2359 UTC also).

The emojis look too nice and sharp. They should probably all be replaced by pixellated 16x16 GIFs :)

also perhaps a nice collection of 88x31 buttons for the footer

https://anlucas.neocities.org/88x31Buttons ↗ https://cyber.dabamos.de/88x31/ ↗

Uses a random favicon on each load.

Before:

After:

its OpenChaos, not OpenAttemptedMurder

So you're saying we should rapidly switch between light and dark mode regardless of what the user selects in the prompt? Interesting.

My bad, i misread it that you intended to flash rapidly only when they answered "yes".

Think this could use an epileptic mode. When the user switches light/dark mode, at random prompt the user as to whether or not they're epileptic and if they say no rapidly switch between light an dark mode for a few seconds. Thoughts?

its OpenChaos, not OpenAttemptedMurder

I was intrigued to see how you were explicitly going to find news about world chaos, only to find this is literally just the NY Times World News feed. Accurate.

Adds a sun/moon toggle in the top-right corner to make the user think they have an influence on this chaotic world. Do they?

alert("No.")

Does not remember your preference in localStorage.

Always respects the opposite of your system preference, ie a white background in system dark mode, and a dark backgrond in system light mode.

Because every project needs more chaos.