• Posts
  • RSS
  • ◂◂RSS
  • Contact

  • 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:

    Be less scared of overconfidence

    deferring to markets • deferring to experts • deferring to low-information heuristics • why they fail • blindness to outliers • what to do instead

    via benkuhn.net November 30, 2022

    Corncob Dolls

    I went to a farm and at the farm I got to see a corncrib and the corn that had fell out of the corncrib that no one wanted I got to use my fingers to take off the corn kernels and once the cobs were empty I put them in a bag and then once I got back to the…

    via Anna Wise's Blog Posts November 7, 2022

    Light Switch

    When I got my loft bed it was just so annoying every morning to have to get out of bed, climb down the ladder, turn the light on, and climb back up, just so I could see stuff. I decided to make a string for my light switch because I really wanted to be abl…

    via Lily Wise's Blog Posts November 7, 2022

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact