File a bug: the missing manual, now with unicorns

At countless conference talks I have heard standard advice on “how to get involved in an open source project”. It goes something like this:

Step 1. File a bug!
Step 2. Submit a patch! (repeat steps 1 and 2 for a while)
Step 3. Now you are ready to write some new features and stuff! Fly and be free!

I always thought that was interesting because it is an attempt to reassure people that you don’t have to leap into immediate coding. Just file a bug, that is the first step. This results in people coming into projects and wondering vaguely how to find bugs.

Part of what I want to do as bugmaster for Mozilla is to put in another step — look at the bugs already reported, since there are a squizillion of them, and see what you can do to improve the meta information of those bugs.

Today on Planet Mozilla I noticed some really good advice from Jason Smith on how to find bugs: WebRTC testing: Try out conversat.io and file bugs. It is really sensible and practical. Jason’s blog has a few posts like this that advise focus in a particular area, like WebRTC or Desktop web apps, by incorporating use of those tools in your daily life. Our “get involved in open source” sequence now looks more like this,

Step 1. Find some feature that could use testing.
Step 2. Figure out how to use it regularly.
Step 3. Use it.
Step 4. Encounter behavior you think is a bug.
Step 5. FILE A BUG (BUT HOW?)

There is a lot of background knowledge necessary to actually file a bug in the complicated system that is bugzilla.mozilla.org (or BMO).

So let’s take the WebRTC example. Say you’ve followed Jason’s advice, used conversat.io for a while, and found A BUG. Jason helpfully provides a link directly into Bugzilla to the enter_bug form, with the Product and Component pre-filled out to be for a bug with WebRTC (the component) and Core (the product.) Bugs in BMO are categorized according to Product, like Firefox Desktop, Firefox for Android, FirefoxOS, Thunderbird, etc. “Core” is the product for the code that is shared between many other products. If you were looking to file a bug with WebRTC from scratch you would probably not know which product to file it under, though you have to choose one. So it’s great that Jason gives a link to the right product and component!

But wait. There is so much more background, or context, to understand. You don’t have to, but it is very good to understand it!

First of all you have to have a bugzilla account for the link to work properly. If you do that, you will be a new bugzilla user, and some of the bug entry forms will look different to you — you’ll be automatically directed to a “guided bug entry form” which is broken into several steps, rather than the form that shows you the whole “advanced view” with several dozen fields and dropdown menus.

Second, how about looking at the list of all the components in the Core product. This is a good part of the background knowledge – a little piece of the map or geography of Bugzilla. As you can see, there are a lot of components that are part of Core. Scrolling down to the WebRTC bit, you can see that there are several sub categories: WebRTC, WebRTC:Audio/Video, WebRTC:Networking, and WebRTC:Signaling. Click on the general WebRTC component to see a list of open WebRTC bugs. This is where your geography lesson gets useful.

Right now there are 113 open bugs for WebRTC. You might look over them simply to get an idea of what kinds of bugs others have found. More about this later!

The important thing at this moment is: Is your bug already reported? Depending on how many bugs there are in this list, and your levels of interest and patience, you might want to either quickly read through the summaries (the title of the bug) or do a search down the page for words that might be in the bug you’re about to file.

If you find something in that list that you think is your bug, take a closer look at it. Read it and the comments and try to understand what they’re talking about. If it is the same as your bug, you may want to leave a comment describing what you saw happen.

But let’s say you don’t find your bug on that list. Aha! Here we use the File a bug link from the original blog post, link to file a bug with WebRTC. If you are me, or a user of Bugzilla who has made more than 25 edits or comments to bugs, you will see the advanced bug entry form, which is huge (you can see it from space) and looks like this:

Enter bug webrtc advanced

If you are a relatively new user of Bugzilla, you’ll come first to a guided entry form, broken into several screens. (At any point, you can switch to the advanced entry form with a link at the bottom of the page, if clicking through multiple screens annoys you.) The first screen for guided bug entry would normally be for selecting the product and component. Since you have these already chosen in Jason’s convenient link, you start on Screen 2, where you can enter the summary for your bug. In this case I am reporting a sort of unicorn invasion:

Enterbug webrtc screen2

After you enter a summary you will see a list pop up underneath the summary field, of bugs that may be similar. It is worth reading through those to see if anyone else has reported unicorns invading their conversat.io screens in Firefox. In this case, definitely not.

Enterbug webrtc screen2 list

Since no one else has reported this bug, I click the “My issue is not listed” button, and advance to screen 3, which suggests how I can describe my actions or steps to reproduce the issue, exactly what happened that I think is a bug, and what I think should have happened instead.

Enter bug screen3 unicorn jpg

Great, we have filed a bug! Back to that list of “how to contribute to an open source project”:

Step 1. Find some feature that could use testing.
Step 2. Figure out how to use it regularly.
Step 3. Use it.
Step 4. Encounter behavior you think is a bug.
Step 4.5 Make a bugzilla.mozilla.org account.
Step 4.6 Confirm it with the email confirmation.
Step 4.7 Log in to bugzilla.mozilla.org.
Step 5. FILE A BUG (which we now know how to do!!!)

But wait, there’s more — or there can be if you want to get your bearings on that map of Bugzilla. Take a look back at the list of all the general open WebRTC bugs. What can we understand from this list?

As I look over the current list it is pretty mysterious. From the language in the summaries, I would guess some of the bugs are notes by the development team for their own to-do list, and some of them look like bugs discovered by general users of the software. My first impulse is to sort the page a few different ways to see what that reveals. Sorting by Status shows the UNCONFIRMED bugs at the top and the NEW bugs listed just underneath. There is one titled getUserMedia freeze all system that isn’t confirmed yet and may be a good example.

Here is an interesting one, No event when remote peer disappeared. My view of this bug is going to be different from yours, if you are new to Bugzilla, because I have more magic powers, ie, canconfirm and editbugs permissions, as well as some extra admin stuff. There is a lot of stuff on the page. It’s extremely “busy” with text! You have to learn to skim it and parse it mentally so that you can see and notice the stuff that is important to you at the moment. Here is what this bug looks like for a new Bugzilla user.

Example webrtc bug2

What I can see from reading this bug is that there is at least one person actively looking at newly filed bugs, triaging them, and working on the project. And in fact as I click around and read more of the bugs for WebRTC I can see Jason is actively engaged with most of them, which is not a big surprise since he is blogging about the subject.

Jason’s blog looks like a quite useful place to find out areas that welcome testers and bug-finders. You can also look at the QMO quality assurance and testing pages which explain how to run nightly builds and participate in QA’s bug test and triage days.

My bigger point here, though, is that to start contributing to an open source project, aside from reporting one-off bugs you accidentally discover, it is super helpful to learn the landscape of the project. Adopt the project and poke around to learn about it. If you are reporting a bug, look at the other bugs. Look at who is commenting and working on those bugs. Join their IRC channel and read their wiki pages and (usually more formal than the wiki pages…) developer documentation. Or simply google the project to learn more about what’s going on with it. In this case I found that conversat.io is quite new and was developed partly to show off what WebRTC is and what it can do.

It was really apparent, from my morning of poking around, how much transparency there is at Mozilla, and the amazing technical depths you can get to from half a day’s reading and bug surfing. As a society we really have yet to realize the implications for education and educational institutions. It is a major cultural shift I am happy to be part of.

Noisebridge! Best thing ever!

On April 2nd and 3rd I am going to spend several hours teaching at least 70 high school physics students how to solder and some alluring information about contributing to open source software!

They are doing a project to design and build a solar home. If you know anything about electronics or solar energy cells please join us a do some teaching!

rowan learning to solder

I spent $250 of my own money to buy a crapload of little LED kits so they can have a conveniently teachable soldering project – that is how much I love Noisebridge, and geeky things, and teaching, and non hierarchical anarchist/mutualist community spaces!

I am thinking of the Hackability group that meets at Noisebridge to fix and mod their wheelchairs and mobility scooters! We take over a classroom, gank all the workshop tools, and get on the floor where none of us think it is weird that we scoot and crawl and roll across the floor to pick up a screwdriver just out of reach, laughing at all this solidarity! We bravely dismantle our cyborg leg-wheels and bolt them on again covered with LED lights, jazzed up with arduinos to measure battery voltage, then roll on out into the town!

potentiometer and its lever

And the fierce, fun feminist hacker hive that is a chaotic unstructured network of strength and curiosity and information sharing, that stretches from Noisebridge to sudo room and LOLSpace, and beyond!

Claudia

We need more paying affiliate members — we need you! We need your cold, hard bitcoins or your cash!

I am thinking of all the people I’ve given tours to who come in from out of town and are all starry-eyed and inspired, who meet people and go to Python and Ruby and web dev and Linux classes and eat the strange productions from the Vegan Hackers, the laptops that people at Noisebridge fix and give away, the cameraderie I always find there and the fabulous energy of young people just moving to San Francisco to do a startup or find some kind of freedom or empowerment and hope to find at least part of it at this weird ever changing junkyard coffeehouse-feeling co-op workshop. We made this place that isn’t anything like any other place and it can also be YOURS. Meddle in it!f

surface mount soldering

SUBSCRIBE to support Noisebridge’s rent, its freely provided wifi, its bins of electronics parts that anyone can rummage through and pillage, its beautiful giant robot, its classrooms and electricity, its ADA-compliant bathroom custom built specially by Noisebridge folk, its elevator, its devotion to support accessibility for all, all its copies of keys that I and others have distributed as Keys to the City, the library of excellent technical books, well used and loved and read!

Hacker moms visiting Noisebridge

Our rent went up this year, and our people’s job security and income went down. It’s exactly at that point, when the economy is hard on us all, that we need collectives and co-ops and hackerspaces. We have to band together in the best ways we can come up with.

me and maria zaghi at noisebridge

People visit Noisebridge and like it so much that they move to the Bay Area. They come to Noisebridge for education, to find peers and mentors, to teach, and sometimes to find as close as they can get to home and family when they are hackers down on their luck.

Noisebridge - looking west

They come to speak in public for the first time at 5 minutes of fame. They sound a little odd and then they turn out to be geniuses. They drudge to clean the floors and toilets and scrub the kitchen and buy toilet paper, doing the unglamorous physical domestic labor of maintaining this place that’s used heavily 24 hours a day 7 days a week.

noisebridge

We do good work together as best we can. We give a lot to our community! We give access, tools, skills, time, belief, trust, fantastic spectacles, beauty and humor and art. With a sense of wonder and playfulness people walk in and look around – I see it on their faces – like they have just had a million new ideas churn around in their heads – So many possibilities and they know they can be part of it.

Noisebridge table

circuit hacking monday

And we need widespread, ongoing support.

Donate, sign up for a monthly subscription, be a fabulous affiliate of Noisebridge!

If you can spare any, we need your exclamation points as I have used most of them in this post!!

Noisebridge tea cart

CodeTriage looks very cool!

André Klapper showed me a nifty tool called CodeTriage yesterday. I really like its simplicity, its friendliness, and what it conveys about open source bug management.

Once you sign into CodeTriage with your github account you can browse code repositories by programming language. I picked flask and codetriage repos to follow.

Codetriage homescreen

Codetriage then sends me a daily email with link to a random issue from each repo, asking me to triage the bug.

Codetriage email sample

This makes it beautifully clear that, with only a little time and thought, without any particular programming skill, anyone can contribute useful work to an open source project. Each email comes with a little pep talk about the goals of triage:

* Help share the weight of maintaining a project
* Minimize un-needed issues
* Prevent stale issues
* Encourage productive communication
* Teach good citizenship
* To become a better coder

Short, sweet, and to the point. The how-to-triage part of the email is not specific to any programming language or project, yet, or to the bug itself, but is an overview of the concepts of improving the quality of any bug.

It gave me a nice feeling that I had been helpful, when I tried it this morning.

André and I were talking excitedly all afternoon about shaping the idea of bugmastering (or triage) for our communities. Bug management is a great way for contributors to become familiar with a project and ease into development or become experts in QA. It’s a good evolution of a definite role in open source ecosystems.

So CodeTriage gets across exactly what I want to convey to aspiring Mozilla bugmasters. I feel super inspired to build something to hook into bugzilla.mozilla.org with a similarly lovely interface. Thanks to Richard Schneeman for creating CodeTriage!

Bugs and sheriffs in London

Travelling Bugmaster update! I am in London with a bunch of the automation tools team for a work week. Ed, jeads, Chris, Ryan, dave, and mauro have been neck deep in making decisions about the structure of a new version of TBPL. By eavesdropping in their conference room I have learned a bit about how Ed and RyanVM and others watch the tree (sheriffing). Also, dkl and gerv and I met up to talk about bugzilla.mozilla.org and I got to bounce some ideas off them about possible ways to tweak the incoming bug triage workflow.

The London office is right between Trafalgar Square, Chinatown, and Covent Garden. It’s very accessible. If you come to Mozilla London offices and are a wheelchair user, you should know that the Tube stations near the office are not accessible. Give up and take the Heathrow Express to Paddington and then a taxi.

Lanterns sky

The BMO and IT teams (glob, dkl, and fox2mike, mostly) are planning to upgrade bugzilla.mozilla.org on March 8th. You can give it a test drive here: bugzilla-dev.allizom.org. This brings Mozilla’s implementation in line with the upstream version of Bugzilla 4.2. In theory, the new server hardware and architecture will also make BMO much faster.

I’m mostly excited about the user and product dashboards in this release. They look extremely cool — great for people who are doing bugmaster and triaging work. Someone who wants to drop in to triage Firefox bugs, or to get a mental image of what’s happening with bugs of interest to them, will be able to do so easily, without having set up a sort of pachinko palace labyrinth of bugmail and filters.

Bugzilla user dashboard 500

So if you would like a sneak preview of the user and product dashboards, take a look on bugzilla-dev.allizom.org and poke around! You can talk to us on #bmo or #bugmasters on irc.mozilla.org if you have feedback. And do please help us by filing bugs!

Besides the upgrade and move, and the archictecture of bzAPI current and possible future — gerv, dkl and I discussed the re-framing of early bug triage as “Bugmaster” or bug management work. We kicked around some ideas and it was very helpful to me to get their advice.

I am adding links to current wiki docs into the show_components.cgi descriptions and dkl has promised to expose those descriptions in show_bug.cgi views of individual bugs. My thought is that within the bug itself, the reporter and triagers, or an aspiring new developer, will have multiple ways to dive deeper into the bug.

We talked about adding common reply templates, which I am collecting in the Bugmaster Guide but which would work well, I think, built into Bugzilla. It turns out that dkl already has an extension started, canned comments, to do exactly this. Very intriguing!

Another thing I’d like to see is something that invites extra information when a bug is filed. This can be context sensitive, so that, if you file a bug in Firefox for Android in a particular component, there can be a link to relevant support forums, wiki pages, the irc channel, and the module owner information. This landing screen could also invite the bug reporter to add bits of information they have not included. If they haven’t attached a screenshot or included a url there could be an attempt to elicit them, or a few “next steps to help make this bug more reproducible” suggestions.

I am still thinking about the READY status flag and other ways to mark “early triaging is happening, or should be happening” vs. “in the hands of dev team”. That is a fuzzy boundary and different conditions would lead to it for different products/components. In this discussion we looked at Gerv’s and Jesse Ruderman‘s proposals for BMO workflow:
* Workflow Proposal 1 which simplifies the status chain.
* Workflow Proposal 2 which more radically changes the flow and statuses to a “next action” framing.

I can see benefits and drawbacks to both models.

It would be helpful from a triaging point of view to be able to declare, in an obvious-to-all way, that a bug is as triaged as we can get it for the moment and it either is ready for a developer to look at or is in some sort of Bug Limbo waiting for later re-assessment. We can do that with some assortment of existing tags and keywords but it may lack clarity and ease of use.

We brought up the idea that if I am doing some triage on a bug but don’t feel it is “ready” yet — for example perhaps I have identified its component, but not reproduced it, or vice versa — I can list myself as the QA contact. What would that indicate, though? Would it keep away other triagers? That is not what I’d want, of course. We could end up with some sort of “needstriage” checkbox, or make a tagging taxonomy that is well documented and evangelize it.

On Sunday I spent some time wandering around in a rented mobility scooter. It is possible now in London to hire a scooter for 70 pounds a week. Very much worth it not to have to push myself over thousands of cobblestones. I have only run over one person’s foot so far in the swarms of tourists, theater-goers, schoolchildren going to museums, and Londoners purposefully striding around in overcoats staring at their mobile phones. Though the scooter delivered is bigger than most cars in this country. It is like an enormous Mecha Gundam Wing suit on wheels so my adventures in the London streets are reminiscent of the Pacific Rim movie trailer.

Lion unicorn palace

In London, when confronted with a giant wheeled exoskeleton, people generally give a tiny gasp and start (theatrically), mutter apologies, and make a show of getting out of the way while looking bewildered. They are relatively good at not acting shocked that I exist. That’s kind of pleasant really. Some buildings and restaurants are somewhat accessible. I get along here as long as I don’t think too hard about how I can’t use the Tube at all and I can afford the glorious taxis.

In Vienna, I used my manual chair. Almost nowhere is accessible even when it is declared to be. People there would loudly gasp, almost a little shriek, and leap forward to grab me, which reminded me of how people act in Beijing when they see an independent person using a wheelchair. They scream, and they leap, like kzinti. More details on hilarious wheelie adventures in the Hofburg, coming soon. Travel is lovely but I’ll be glad to be back in San Francisco at the end of the week.

First day at Mozilla!

I spent yesterday in the San Francisco Mozilla office, meeting people, setting up my laptop, and getting a general orientation. It’s in the Hills Brothers Coffee building across the plaza from Google, so I went past a hilarious statue (too late from the bus to study it in any detail) into a marble-floored entry hall and into one of those dark woodpaneled elevators with a mirror that are successfully posh, but need cheering up or art on the wall or something to look at other than the reflection of elevator-awkwardness. In elevators I have the choice of lining up my wheelchair or scooter foolishly backwards to back in, then emerge with dignity; barrelling in over-fast to jump the gap and scaring anyone already in the elevator, then waiting facing the “wrong” way; or, jumping the gap forwards and then executing a clumsy or neat 7 or 5 or 3 point turn which definitely scares everyone else’s feet. Sometimes I forget to slow the scooter speed and crash into the elevator wall.

Enough about that! The 7th floor is more cheerful, light, full of colored couches and enormous refrigerators and baskets of candy and snacks enough to feed armies of squirrels. An extremely nice person named Peter gave me a laptop and pointed me at a videoconference set up on a tablet in a sort of tablet holster with headphones so that I could be in the HR orientation, which was fairly painless and lasted about an hour. I am one of the first batch of new hires to go through their new “onboarding” system, which has been bombarding me for a week with exhortations to Join the Glorious Mozillian Cause, Comrade, join every mailing list/newsgroup/irc channel in the world, and fill out my forms. It seems a good system. “Firehose” is too weak of a term.

mozilla lizard logo

I kept notes on all the tiny errors in the process, throughout last week, to report them in batches. I felt that I was already working there, without being paid, which, well, why not when they are so awesome and it is free/open source and a huge worldwide volunteer community! Onwards!! I spent some time last week, and then, much more fiercely yesterday, coming up with ways to organize these huge tributaries of information and systems for myself to skim off the bits necessary to move something forward, respond or act. I feel like a little space station way out somewhere, beginning to turn on its ansible and light up, coming online in a giant network of ships and stars.

Right, where was I. I was introduced as a new hire at an amazingly competent video conferenced short Mozilla weekly meeting. I had already looked at past meetings while studying up on what was going on at the company, to interview. Then was on irc, on the #qa and #ateam channel, then meeting the Bugzilla team who are in town for the week and who were very amiable. I wonder if they would like to come to Noisebridge? It is amusing to work at a grownup job where people are introduced to you with names like “glob” and “potch” and it is normal for me to be named “lizzard” since it has been my irc name for forever. I listened to the Bugzilla folks for a while. They super nicely offered to take me with them tomorrow on a datacenter tour, where I will arrive as a sort of wheely cyborg surprise to whoever is squiring us around. Then had lunch (free, catered, very nice lunch on Mondays) with Lukas Blakk, ran into Tantek, met Boris and Dave and the guy with the purple mohawk, and Heather who showed me around the building. My cube is in a somewhat depressing cube farm on the 3rd floor, but everyone was super nice and I decided to work in the community room on the 7th floor where there is a beautiful view of the Bay Bridge and the water. There are couches on the roof, and tables to work at. Lukas and I hung out (we know each other from geekfeminism.org already) and I got to see a lot of great and promising stuff built on top of Bugzilla’s API, just the sort of thing I was hoping to (someday) build to visualize Mozilla’s bug data.

This is more about first impressions and my enjoyment of them than an organization of facts and information and my systems to keep them neat. Those systems, right now, live in my private TiddlyWiki instance, a new lizzardZilla wiki separate for work where I brain dump, then organize everything. I will try to convey actual information later today! But, in short, I am the Bugmaster, and on “The Ateam” and cannot wait to order business cards that say “Bugmaster” on them. Maybe with this picture on the back, shopped with some extra -zillatude to it:

All shall triage bugs with me and despair make awesomeness possible!

Changing the World with Open Source

Today I was on a panel, Changing the World with Open Source, for the Women Who Tech Telesummit. I came away feeling charged up and inspired at the thought that the other panelists and I were really on the same page as far as F/LOSS culture, free culture and non-hierarchical and non-traditional methods of collaboration as being world-changing in themselves. Process is as important as product! It was almost eerie, but very heartening, to realize how deeply I agreed with Arthur and Jane. I thought, “My god… the world already has changed!”

logo for women who tech

The talk had around 90 attendees out of about 600 registered for the conference. It was recorded and broadcasted in various places including in the learning theaters in Microsoft stores.

We mentioned many resources and practical tips for engaging with open source projects and communities. Answering questions in support forums or IRC, submitting a patch, entering the project with a friend (as equals) rather than picking a mentor or teacher and working alone, going to events like WordCamp, DrupalCon, or Wikimedia hackathons were mentioned. Arthur talked about The Ada Initiative, (which just got its non-profit status approved, hooray!) and I mentioned Dreamwidth as a particularly friendly project for contributors. I also gave a hat tip to hackerspaces and to Women Who Code.

So, I recall making a few good points that I think added to the political depth of the conversation, or that reframed it as important activism. As women at this moment in history we are engaged in a long, drawn out struggle to take our places in the public sphere. Much of the advice on “women in F/LOSS” is pitched to newbies and inexperienced developers. But I wanted to speak to experienced women “in tech” too. While we might feel suspicious as developers and as women of anything asking us to do work for free — since our labor as women is so often exploited — it is a political act for us to take credit for our work in the public sphere. Coming into the public as writers or as developers, our mere assertion of that right (and the right to have attention paid to our work) brings a hostile reaction, no matter how nice or helpful we are. As we like to talk about at geekfeminism.org, it is crucial for us to support each other and for good F/LOSS projects to foster a supportive culture.

Thanks @janeforshort, @sarahnovotny, @awjrichards, and @WomenWhoTech, @brainwane and @Sarah_Stierch! And of course to anyone listening. I enjoyed our conversation very much!

Support open data and defend Aaron Swartz

I fully support Aaron Swartz as he fights unjustified charges from the U.S. government, and hope that my readers will support him too. Aaron is a researcher who works with huge datasets and has worked on many open data projects. Aaron is being charged for having accessed JSTOR, a repository of academic journal articles, and downloading them.

JSTOR itself didn’t want to press charges and says it hasn’t suffered loss or damage. But the U.S. Government indicted Aaron because they feel like they “caught a hacker”.

Aaron Swartz
Aaron Swartz

I’m incredulous that they would pursue this case against a well known researcher and activist who allegedly was doing something quite benign — scraping data.

I worry that this case will have a chilling effect on open data projects. The government has gone to great lengths here to stop a respected activist’s work, siccing the Secret Service on him and wasting an incredible amount of resources to trump up this case. The FBI has already investigated Aaron at least once for downloading PACER data . It looks bad to me, like the government was basically waiting for any excuse to build some sort of charge against Aaron for his briliant open data activism.

Here’s Aaron’s background in open data and analyzing large data sets:

In conjunction with Shireen Barday, he downloaded and analyzed 441,170 law review articles to determine the source of their funding; the results were published in the Stanford Law Review. From 2010-11, he researched these topics as a Fellow at the Harvard Ethics Center Lab on Institutional Corruption.

He has also assisted many other researchers in collecting and analyzing large data sets with theinfo.org. His landmark analysis of Wikipedia, Who Writes Wikipedia?, has been widely cited. He helped develop standards and tutorials for Linked Open Data while serving on the W3C’s RDF Core Working Group and helped popularize them as Metadata Advisor to the nonprofit Creative Commons and coauthor of the RSS 1.0 specification.
In 2008, he created the nonprofit site watchdog.net, making it easier for people to find and access government data. He also served on the board of Change Congress, a good government nonprofit.
In 2007, he led the development of the nonprofit Open Library, an ambitious project to collect information about every book ever published.

I would also like to say that I think that libraries and academics should stop buying into the JSTOR model. JSTOR aggregates academic journal articles which it doesn’t even own, and sells limited access to those articles to large institutions for thousands of dollars. Libraries and universities should act to enable access to information, not to limit it.

ETA: Here is JSTOR’s official statement on the case.

Small press in a box

I met David Merritt at linux.conf.au in Wellington, New Zealand earlier this year. He had a table in the exhibitor’s hall on Open Day and was making tiny books there with his son. He was carrying around Landrover Farm Press in his suitcase. His idea is that publishers should carry their means of production with them in a box. I got instantly very excited! I’ve been making xerox zines since 1986 and carried that forward over the years to many small press poetry books and journals as well as riot grrl zines.

fabulous poet

David was taking the poems (previously printed or xeroxed), cutting them out at the table, stapling them into inside-out hardback book covers, pasting a label for his press on the inside cover, and then stamping the book titles on the front cover with alphabet block rubber stamps while chatting with his customers. Here is his “press in a box”:

david merritt's means of production

Most people were buying a tiny book called “Geek Prayers”. I bought one for 5 bucks.

outside front cover of geek prayers

The poem itself made me think of Len Andersen’s “Beep“, a parody of Howl which I put up on the web a few years ago with his permission. Like Beep, it attempts to include computers, technology, and the experience and culture of the Internet into poetic experience, but unlike Beep it pushes into the territory of embodying that culture. All it needs is a web site where you can print and construct your own version…

As I looked over my hastily constructed Geek Prayers book, the cleverness of its design struck me.

This poem is structured in separate phrases rather like the giant sentence that’s the first section of Howl. The sections can be in any order, which is pretty handy for the book binding. The last part of poem is printed and cut out separately and glued to the back cover. You could print out the double-sided pages of poem snippets on a sheet of paper, then cut them across and fold them in any order. I thought this was a very clever way of avoiding fuss in the page-collating and binding process by using randomness. It is in itself an excellent geek solution for a geek poem!

inside back cover of geek prayers

Here is the outside cover unfolded, showing how the inside endpapers of the original cover look when dissected, stapled, and stamped. Frayed bits of mull, endpaper, and the spine’s cardboard backing stick out like torn lace. One cover is stamped with a library mark and “discarded” giving a pleasant retro feel to a book that now sports its new and more meaningful rubber stamp marks. The poem has a sort of wistful history in its covers, a ghost existence underlying its new incarnation as a book. We are ephemera!

Of course David and I got to talking about publishing and poetry. As we talked he just kept giving me more books and showing me more poems, which I read instantly and which made my head explode. Most poetry leaves me a bit bored, if not completely nauseated. I get VERY EXCITED when a poem is fabulous, weird, thoughtful, unexpected, out there, or has anything at all FREE in it. As in a song, there has to be a break. A disruption between order and disorganization that exposes something. I like the arcs of big ideas, and I like supercompressed symbolist narratives, and along with it all, disruption of language and something new.

I think we babbled for a couple of hours about being our own movement, the unnamed inheritors of the Beat, just writing a ton and scattering it out into the world without any constipated fretting about copyright and Being Important. I went on an extended rant about wankery poetry scenes, stuckup expensive journals that no one reads except to figure out how to get in them and that become instant landfill, my old projects to wheatpaste poetry all over Austin — OPUS or OccuPations of Uninhabited Space (after Takver’s mobiles in Ursula Le Guin’s anarchic epic, The Dispossessed). And while I like Book Arts people I cannot really get into the idea of a book as a precious one of a kind handmade object. I like better to churn out sloppy handmade books, mass-production style, that are affordable enough for anyone to buy and read them, or that are cheap and easy enough for me to produce that I don’t mind giving them away.

At some point I wheeled away to beg the use of the linux.conf.au organizers’ office printer, then was able to hand David a big batch of my own long ranting poems and a few translations. I talked about F.A. Nettelbeck and the tiny books he prints called “This Is Important” and how I look for the books printed by Alta in the 70s and early 80s and wrote letters with Cid Corman about bookmaking and short poems. If you haven’t seen Cid Corman’s tiny books, he did so much more than Origin (which rocks… but I love little handmade books.) We talked about short poems and long poems, form and performance and spoken word. It was really nice and unexpected to have this conversation at a technical conference!!

Here is David’s “first friday in fifteen”, which is one big 11 x 17 sheet trimmed down the long side to fit inside the cover, and folded up from the bottom so that the entire very long poem is on one page.

friday out

And here is a copy of his poem “nice things”, to show how interesting endpapers can jazz up an inside-out book:

outside of "nice things" book

The poem “nice things” is totally fucking awesome!

the single unfolded page of Nice Things

I’ll write another post about my explorations of making inside-out books over the past few months, inspired by David Merritt’s books from Landrover Farm Press, along with a step by step guide on how to do some recycled bookbinding!