::  Posts  ::  RSS  ::  ◂◂RSS  ::  Contact

Nomic Report

January 11th, 2019
nomic  [html]
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:

Transfers from Infrequent to Frequent Vehicles

Imagine yourself taking a train somewhere, and imagine the train is big and infrequent. Let’s say it’s the commuter train from New York down the Northeast Corridor to Newark Airport, or perhaps a low-cost OuiGo TGV from Lyon to Paris. Now imagine that you…

via Pedestrian Observations January 20, 2020

Veganism and restrictive eating

I’m reading the book Intuitive Eating, which I highly recommend. I was looking for something like it that could get me back to trusting my biological hunger without worrying that I need to control myself or my weight. It’s raised my consciousness to the w…

via Holly Elmore January 17, 2020

Algorithms interviews: theory vs. practice

When I ask people at trendy big tech companies why algorithms quizzes are mandatory, the most common answer I get is something like "we have so much scale, we can't afford to have someone accidentally write an O(n^2) algorithm and bring the site d…

via Posts on Dan Luu January 5, 2020

more     (via openring)

More Posts:


  ::  Posts  ::  RSS  ::  ◂◂RSS  ::  Contact