After proposing automated nomic last week I coded something up and started a game. After playing for a week, here are some thoughts.

The general idea is, people submit and review PRs, and whether a PR can be merged is up to what validate.py (on master) says should be merged. You win by getting the build to fail with a message saying that you win. We started playing with a validate.py that just implemented the rule "allow merging if you have unanimous approval from all users listed in players.txt".

The first problem we ran into was merge conflicts. While the first two PRs where someone asked to join (#6, #7) went fine, things bogged down as we got more requests (#11, #12, #15, #20, #22). The problem was, all players would need to approve each new PR, but then once that one was merged all the other PRs would need to have merge conflicts manually resolved, and then they'd need to be approved again.

In normal software development this isn't a problem, because you generally allow people to push minor follow-up commits like this without requiring them to get approved again. In a game like this, though, allowing that would quickly let someone win, because they could get an uncontroversial PR approved and then in resolving merge conflicts add something evil.

This meant it was pretty urgent to figure out a way around the merge conflicts, and we decided to go for the directory trick. Instead of players.txt, a list of usernames, we switched (#26) to players/, a folder of empty files, one per player. A situation where two different commits each add a file to a folder is one that git can resolve automatically, which meant PRs didn't need to be re-approved.

Before we could add lots of players, though, there was a risk that we might add someone who would become unresponsive. While we weren't ready to stop requiring approval from everyone before merging a PR, we decided that after three days with nothing getting merged to master the approval threshold would start dropping by one person per day (#23). While this hasn't been used yet, it also adds a bit of urgency to keep making progress.

At this point we had nine players, and wrangling approvals for every change was getting annoying, so we decided (#31) to allow merging PRs with a 2/3 supermajority, as long as no one had rejected the change.

Now we're starting to play around with the idea of points (#32, #33, #47, #49, #50). Points don't actually do anything yet, but they open up a lot of possiblities for things like approving something you don't like in exchange for a few points.

Merge conflicts continue to be a problem, as does everyone needing to re-approve after someone pushes a change to fix a small issue someone has raised. But the game is progressing, and I'm optimistic we can fix all these problems within the framework of the game.