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

    EDT with updating double counts

    I recently got confused thinking about the following case: Calculator bet: I am offered the opportunity to bet on a mathematical statement X to which I initially assign 50% probability (perhaps X = 139926 is a quadratic residue modulo 314159). I have acce…

    via The sideways view October 12, 2021

    Meditations on newborns

    [Content: death.]I wrote most of this a couple of months ago when Nora was a newborn, but the first few months are not that conducive to finishing blog posts. New babies put you into a liminal period, both in your own experience and in how others treat yo…

    via The whole sky October 3, 2021

    The value of in-house expertise

    An alternate title for this post might be, "Twitter has a kernel team!?". At this point, I've heard that surprised exclamation enough that I've lost count of the number times that's been said to me (I'd guess that it's more tha…

    via Posts on Dan Luu September 29, 2021

    more     (via openring)


  • Posts
  • RSS
  • ◂◂RSS
  • Contact