Nomic Report

January 11th, 2019
nomic
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.

Comment via: facebook

Recent posts on blogs I like:

A Big Problem With The Going To Bed Book

One day my dad was reading this book called the "Going to Bed Book" to my sister Nora. The book is basically about a bunch of animals who are getting ready for bed on a boat. They go down the stairs, take a bath, hang their towels on the wall, find…

via Lily Wise's Blog Posts September 18, 2023

Investing in boundaries with young kids

Putting in some work to get the behavior you want The post Investing in boundaries with young kids appeared first on Otherwise.

via Otherwise August 15, 2023

Self-driving car bets

This month I lost a bunch of bets. Back in early 2016 I bet at even odds that self-driving ride sharing would be available in 10 US cities by July 2023. Then I made similar bets a dozen times because everyone disagreed with me. The first deployment to pot…

via The sideways view July 29, 2023

more     (via openring)