Early this year, esophagitis I had to start using Mozilla’s Bugzilla, pathopsychology an issue tracker that, doctor while incredibly powerful, nonetheless confused and intimidated me to no small degree.
One of my most basic needs was to have a simple display containing bugs of interest to me. I couldn’t find a page in the product that satisfied me, so I used Gervase Markham’s excellent Bugzilla REST API to create an HTML page that fetched the information I needed and displayed it.
The page is designed to be read from left to right, with the most important information appearing earliest. The first column, Things to Review
, contains patches and other artifacts that I need to provide feedback on—it’s most important because it’s blocking other people from getting their work done. The next column, Assigned Bugs
, contains items that I’ve elected to work on. The columns continue through Reported Bugs
(open issues I’ve reported myself), CC’d Bugs
(open issues I’m interested in), and finally Recently Fixed Bugs
, which contains resolved issues from any of the previous columns that have been closed in the past week. Issues that might appear in two columns, such as a bug I reported and assigned to myself, appear only in the more important column to avoid redundancy.
I’ve also added a few features on the panel at the top-right corner of the page to help with some other pain points of Bugzilla that I ran into: Find A User makes it easier to locate someone in the system and view their dashboard, while File A Bug makes it easier to file a bug when you don’t know what product or component it belongs to.
The page, which a number of friends and coworkers have been using for the past several months, is now hosted on GitHub:
One of the most interesting uses I’ve found for this tool is actually to get a bird’s-eye view of what other people are working on. At the login prompt, you can type any email address and leave the password field blank to see the public bugs that someone is subscribed to, which makes it an excellent window into Mozilla’s mostly-transparent ecosystem. For instance, here’s what I’m working on.
I did not expect to enjoy this game.
My friend Mike was completely obsessed with Minecraft, plague
and Dave Humphrey blogged a bit about all the amazing things people had done with it: creating replicas of the German Reichstag, ampoule the U.S.S. Enterprise, store
working CPUs. All creative uses of cognitive surplus. But I still didn’t think that it was for me.
When visiting Washington, D.C. in the last days of December 2010, I finally sat down with Mike and he showed me how to play.
I then played it for a few minutes in single-player mode and found it interesting in a very detached, academic way. I even bought it, just because I wanted to be a good customer and support such innovation. But I honestly doubted that I’d play it much.
The next day, I set up a multiplayer server for Mike and I, which changed everything.
I think it was the shared experience of being part of a team in a survival scenario that did it for me. The story of The Swiss Family Robinson had always fascinated me as a child, and Minecraft’s multiplayer survival mode had some of its core elements: you’re stranded on an unfamiliar landscape with friends, and need to build a shelter before sundown, because that’s when the zombies come out.
So I guess it was more like a cross between The Swiss Family Robinson and 28 Days Later.
Home Sweet Home
Our first shelter was built from stone and wood into the base of an enormous sand dune. In the world of Minecraft, monsters are created from darkness, so we had to craft torches and mount them inside to keep the darkness out.
It wasn’t the Reichstag, but it was home.
That first night, as zombies and spiders groaned and hissed outside our walls, Mike taught me how to create glass by heating sand in a furnace. I forged some sheets of it and built windows into the walls the next day.
Soon we’d built out a second story, and then a third, and then a lookout tower at the very top of the dune. One day Mike went out east in search of more trees to chop into wood, and built a home on a waterfall there that reminded me of Fallingwater.
Over the next several days we explored the unknown and built more. Structures built into the cliffs of canyons, shelters made from caves, treehouses, watch-towers, fortresses of solitude. We carved safe passageways into mountains and built stairways down cliff-faces.
We’d also had our share of misfortune. One of the monsters that comes from the darkness is called a creeper: unlike zombies and skeletons, it doesn’t burn in sunlight, so danger doesn’t depart with the arrival of dawn. It also explodes when it gets close to you. One morning a stealthy creeper surprised me as I left our first home, which nearly killed me and tore our entrance asunder.
Markus Persson, the creator of Minecraft, writes the following about the game’s philosophy:
I strongly believe that all good stories have a conflict, and that all good games tell a good story regardless of if it’s pre-written or emergent.
I’ve always thought of a game designer as a kind of storyteller, as most of my favorite games have rich stories whose potential outcomes were decided and built into the game’s design well before I started playing. In this way, a lot of my favorite games are like “interactive storybooks”, where the primary author is the game’s designer.
Minecraft, on the other hand, is more like scaffolding for a story. The world is randomly generated and has no history; there’s no personalities that populate it. What the game really provides is a setting, a catalyst of conflict, and some incredibly simple yet flexible tools for changing the setting and reacting to the conflict. Beyond that, it’s the players who are the real storytellers, and that’s part of what’s made it endlessly fascinating for me so far.