That Zarro Boogs feeling

This is my third Firefox release as release manager, and the fifth that I’ve followed closely from the beginning to the end of the release cycle. (31 and 36 as QA lead; 39, 43, and 46 as release manager.) This time I felt more than usually okay with things, even while there was a lot of change in our infrastructure and while we started triaging and following even more bugs than usual. No matter how on top of things I get, there is still chaos and things still come up at the last minute. Stuff breaks, and we never stop finding new issues!

I’m not going into all the details because that would take forever and would mostly be me complaining or blaming myself for things. Save it for the post-mortem meeting. This post is to record my feeling of accomplishment from today.

During the approximately 6 week beta cycle of Firefox development we release around 2 beta versions per week. I read through many bugs nominated as possibly important regressions, and many that need review and assessment to decide if the benefit of backporting warrants the risk of breaking something else.

During this 7 week beta cycle I have made some sort of decision about at least 480 bugs. That usually means that I’ve read many more bugs, since figuring out what’s going on in one may mean reading through its dependencies, duplicates, and see-alsos, or whatever someone randomly mentions in comment 45 of 96.

And today I got to a point I’ve never been at near the end of a beta cycle: Zarro Boogs found!

list of zero bugs

This is what Bugzilla says when you do a query and it returns 0. I think everyone likes saying (and seeing) “Zarro Boogs”. Its silliness expresses the happy feeling you get when you have burned down a giant list of bugs.

This particular query is for bugs that anyone at all has nominated for the release management team to pay attention to.

Here is the list of requests for uplift (or backporting, same thing) to the mozilla-beta repo:

more zero pending requests

Yes!! Also zarro boogs.

Since we build our release candidate a week (or a few days) from the mozilla-release repo, I check up on requests to uplift there too:

list of zero pending requests


For the bugs that are unresolved and that I’m still tracking into the 46 release next week, it’s down to 4: Two fairly high volume crashes that may not be actionable yet, one minor issue in a system addon that will be resolved in a planned out-of-band upgrade, and one web compatibility issue that should be resolved soon by an external site. Really not bad!

Our overall regression tracking has a release health dashboard on displays in many Mozilla offices. Blockers, 0. Known new regressions that we are still working on and haven’t explicitly decided to wontfix: 1. (But this will be fixed by the system addon update once 46 ships.) Carryover regressions: 41; about 15 of them are actually fixed but not marked up correctly yet. The rest are known regressions we shipped with already that still aren’t fixed. Some of those are missed uplift opportunities. We will do better in the next release!

In context, I approved 196 bugs for uplift during beta, and 329 bugs for aurora. And, we fix several thousands of issues in every release during the approx. 12 week development cycle. Which ones of those should we pay the most attention to, and which of those can be backported? Release managers act as a sort of Maxwell’s Demon to let in only particular patches …

Will this grim activity level for the past 7 weeks and my current smug feeling of being on top of regression burndown translate to noticeably better “quality”… for Firefox users? That is hard to tell, but I feel hopeful that it will over time. I like the feeling of being caught up, even temporarily.

liz in sunglasses with a drink in hand

Here I am with drink in hand on a sunny afternoon, toasting all the hard working developers, QA testers, beta users, release engineers, PMs, managers and product folks who did most of the actual work to fix this stuff and get it firmly into place in this excellent, free, open source browser. Cheers!

Related posts:

Automated test harnesses for Firefox, zooming out a bit

In December I was going through some of the steps to be able to change, fix, and interpret the results of a small subset of the gazillion automated tests that Mozilla runs on Firefox builds. My last post arrived at the point of being able to run mochitests locally on my laptop on the latest Firefox code. Over the holidays I dug further into the underlying situation and broaded my perspective. I wanted to make sure that I didn’t end up grubbing away at something that no one cared about or wasn’t missing the big picture.

My question was, how can I, or QA in general, understand where Firefox is with e10s (Electrolysis, the code name for the multiprocess Firefox project). Can I answer the question, are we ready to have e10s turned on by default in Firefox — for the Developer Edition (formerly known as Aurora), for Beta, and for a new release? What criteria are we judging by? Complicated. And given those things, how can we help move the project along and ensure good quality; Firefox that works as well as or, we hope, better than, Firefox with e10s not enabled? My coworker Juan and I boiled it down to basically, stability (lowering the crash rate) and automated test coverage. To answer my bigger questions about how to improve automated test coverage I had to kind of zoom out, and look from another angle. For Firefox developers a lot of what I am about to describe is basic knowledge. It seems worth explaining, since it took me significant time to figure out.

First of all let’s look at treeherder. Treeherder is kind of the new TBPL, which is the old new Tinderbox. It lets us monitor the current state of the code repositories and the tests that run against them. It is a window into Mozilla’s continuous integration setup. A battery of tests are poised to run against Firefox builds on many different platforms. Have a look!

Current view of mozilla-central on treeherder


Edward Tufte would have a cow. Luckily, this is not for Tufte to enjoy. And I love it. You can just keep digging around in there, and it will keep telling you things. What a weird, complicated gold mine.

Digression! When I first started working for Mozilla I went to the Automation and Tools team work week where they all came up with Treeherder. We wanted to name it something about Ents, because it is about the Tree(s) of the code repos. I explained the whole thing to my son, I think from the work week, which awesomely was in London. He was 11 or 12 at the time and he suggested the name “Yggdrazilla” keeping the -zilla theme and in reference to Yggdrasil, the World-Tree from Norse mythology. My son is pretty awesome. We had to reject that name because we can’t have more -zilla names and also no one would be able to spell Yggdrasil. Alas! So, anyway, treeherder.

The left side of the screen describes the latest batch of commits that were merged into mozilla-central. (The “tree” of code that is used to build Nightly.) On the right, there are a lot of operating systems/platforms listed. Linux opt (optimized version of Firefox for release) is at the top, along with a string of letters and numbers which we hope are green. Those letter and numbers represent batches of tests. You can hover over them to see a description. The tests marked M (1 2 3 etc) are mochitests, bc1 is mochitest-browser-chrome, dt are developer tools tests, and so on. For linux-opt you can see that there are some batches of tests with e10s in the name. We need the mochitest-plain tests to run on Firefox if it has e10s not enabled, or enabled. So the tests are duplicated, possibly changed to work under e10s, and renamed. We have M(1 2 3 . . .) tests, and also M-e10s(1 2 3 . . . ). Tests that are green are all passing. Orange means they aren’t passing. I am not quite sure what red (busted) means (bustage in the tree! red alert!) but let’s just worry about orange. (If you want to read more about the war on orange and what all this means, read Let’s have more green trees from Vaibhav’s blog. )

I kept asking, in order to figure out what needed doing that I could usefully do within the scope of As Soon As Possible, “So, what controls what tests are in which buckets? How do I know how many there are and what they are? Where are they in the codebase? How can I turn them on and off in a way that doesn’t break everything, or breaks it productively?” Good questions. Therefore the answers are long.

There are many other branches of the code other than mozilla-central. Holly is a branch where the builds for all the platforms have e10s enabled. (Many of these repos or branches or twigs or whatever, are named after different kinds of tree.) The tests are the standard set of tests, not particularly tweaked to allow for e10s. We can see what is succeeded and failing on treeherder’s view of holly. A lot of tests are orange on holly! Have a look at holly by clicking through on the link above. Here is a picture of the current state of holly.

Treeherder holly1

If you click a batch of tests where there are some failures — an orange one — then a new panel will open up in treeherder! I will pick a juicy looking one. Right now, for MacOS 10.6 opt, M(2) is orange. Clicking it gives me a ton of info. Scrolling down a bit in the bottom left panel tells me this:

mochitest-plain-chunked 164546/12/14136

The first number is how many tests ran. Scary. Really? 164546 tests ran? Kind of. This is counting assertions, in other words, “is” statements from SimpleTest. The first number lists how many assertions passed. The second number is for assertion failures and the third is for “todo” statements.

The batches of tests running on holly are all running against an e10s build of Firefox. Anything that’s consistently green on holly, we can move over to mozilla-central by making some changes in mozharness. I asked a few people how to do this, and Jim Matthies helpfully pointed me at a past example in Bug 1061014. I figured I could make a stab at adding some of the newly passing tests in Bug 1122901.

As I looked at how to do this, I realized I needed commit access level 2 so I filed a bug to ask for that. And, I also tried merging mozilla-central to holly. That was ridiculously exciting though I hadn’t fixed anything yet. I was just bringing the branch up to date. On my first try doing this, I immediately got a ping on IRC from one of the sheriffs (who do merges and watch the state of the “tree” or code repository) asking me why I had done something irritating and wrong. It took us a bit to figure out what had happened. When I set up mercurial, the setup process and docs told me to install a bunch of Mozilla specific hg extensions. So, I had an extension set up to post to bugzilla every time I updated something. Since I was merging several weeks of one branch to another this touched hundreds of bugs, sending bugmail to untold numbers of people. Mercifully, Bugzilla cut this off after some limit was reached. It was so embarrassing I could feel myself turning beet red as I thought of how many people just saw my mistake and wondered what the heck I was doing. And yet just had to forge onwards, fix my config file, and try it again. Super nicely, Clint Talbert told me that the first time he tried pushing some change he broke all branches of every product and had no idea what had happened. Little did he know I would blog about his sad story to make myself feel less silly….. That was years ago and I think Mozilla was still using cvs at that point! I merged mozilla-central to holly again, did not break anything this time, and watched the tests run and gradually appear across the screen. Very cool.

I also ended up realizing that the changes to mozharness to turn these batches of tests on again were not super obvious and to figure it out I needed to read a 2000-line configuration file which has somewhat byzantine logic. I’m not judging it, it is clearly something that has grown organically over time and someone else probably in release engineering is an expert on it and can tweak it casually to do whatever is needed.

Back to our story. For a batch of tests on holly that have failures and thus are showing up on treeherder as orange, it should be possible to go through the logs for the failing tests, figure out how to turn them off with some skip-if statements, filing bugs for each skipped failing test. Then, keep doing that till a batch of tests is green and it is ready to be moved over.

That seems like a reasonable plan for improving the automated test landscape, which should help developers to know that their code works in Firefox whether e10s is enabled or not. In effect, having the tests should mean that many problems are prevented from ever becoming bugs. The effect of this test coverage is hard to measure. How do you prove something didn’t happen? Perhaps by looking at which e10s tests fail on pushes to the try server. Another issue here is that there are quite a lot of tests that have been around for many years. It is hard too know how many of them are useful, whether there are a lot of redundant tests, in short whether there is a lot of cruft and there probably is. With a bit more experience in the code and fixing and writing tests it would be easier to judge the usefulness of these tests.

I can also see that, despite this taking a while to figure out (and to even begin to explain) it is a good entry point to contributing to Firefox. It has more or less finite boundaries. If you can follow what I just described in this post and my last post, and you can read and follow a little python and javascript, then you can do this. And, if you were to go through many of the tests, over time you would end up understanding more about how the codebase is structured.

As usual when I dive into anything technical at Mozilla, I think it’s pretty cool that most of this work happens in the open. It is a great body of data for academics to study, it’s an example of how this work actually happens for anyone interested in the field, and it’s something that anyone can contribute to if they have the time and interest to put in some effort.

This post seems very plain with only some screenshots of Treeherder for illustration. Here, have a photo of me making friends with a chicken.

Liz with chicken

Related posts:

Make hackerspaces better – support Ada initiative

Hello! I love hackerspaces! And I’m asking hackerspaces around the world to donate to the Ada Initiative in support of making hackerspaces welcoming and safe places for women. My goal is to raise $4096 and if we do, I’ll match the first $1028 donated. **UPDATE** extending the deadline to next Friday, Oct. 3.

Adacamp liz and heidi in tiara

My home base is Double Union, a feminist hackerspace in San Francisco and it’s going strong. It has lively events every week and over 150 members.

A group of us at AdaCamp SF last year decided we could start a maker and hacker space for women. AdaCamp SF is an unconference run by the Ada Initiative for feminist women in open tech and culture. There were so many of us all together at once. So powerful feeling! With months of hard work, it happened — we opened Double Union.

We get to hack there without sexist bullshit or constantly fending off creepy dudes!

The thing is, I believe that any hackerspace can potentially be that way. You, too, could have a hackerspace where many women feel comfortable, welcome, valued, in their creative, coding, and entrepreneurial and activist endeavors, in a space full of allies and comrades of all genders. This can’t happen overnight. It will take work and education and above all, listening to women, not just the few women who have stuck around, but also the ones who left because they were uncomfortable.

I want to persuade hacker and maker spaces around the world that they are missing out on infinite potential. has some good advice on adding anti-harassment policies to the design patterns for running a space. This is exactly the sort of work that Ada Initiative is good at; their Example anti-harassment policy has been used as a template by many events and organizations.

I’d like to challenge all hackerspace members to do two things in support of my campaign:

* Donate to Ada Initiative! I will match up to $1028 donated when we reach the $4096 goal!

* Add your anti-harassment policy to your organization’s page at, and link to it from the list on the Geek Feminism wiki. (And if your space doesn’t have a code of conduct or policy, start the ball rolling to implement one!)

I love Double Union. We have set aside a permanent physical space, equipment, organization, and time that is focused on making and creating things together. We have the keys in our hands and the tools to do whatever we like in a safe, supportive environment free from harassment. We agreed to a basic code of conduct and some assumptions we share about behavior in the space, which helps establish trust for us to share knowledge, time, and tools. We try to follow Community anti-harassment standards. We have members who are also part of, or supporters of, Noisebridge, sudo room, LOLspace, Mothership Hackermoms, Ace Monster Toys, and other San Francsico Bay Area spaces.

Double union shopbot

We’re having writers’ groups, book groups, readings, zine workshops, open source software coding, cryptography meetups, circuit hacking, making stuff with our CNC routers, 3D printer, vinyl cutter, drawing and art supplies, and sewing machines — in short, doing whatever we like and learning a lot from each others’ expertise. We celebrate other women’s work and cultural diversity. Our hackerspace is against putting others down for what they do or don’t know. Once we don’t have to fight to prove we are ‘hacker enough’, great things happen.

Double Union’s founding group had the vision to make this space happen because of the pioneering work of the Ada Initiative. Ada Initiative’s demands for policy changes for events and companies, its fierce uncompromising voice, and especially its empowering and inspiring events, are having a good and useful effect to shift our culture.

More AdaCamps, like the ones this year in Berlin, Bangalore, and Portland, will help improve women’s participation in hackerspaces. With your donation, we could potentially host MORE of these fabulous unconferences for women in open tech and culture.

Please join me in donating to Ada Initiative so they can keep on being a positive force for change in the world!

Liz and Cristin smiling at DU

Related posts:

How to test new features in Firefox 34 Aurora

If you’re a fan of free and open source software and would like to contribute to Firefox, join me for some Firefox feature testing!

There are some nifty features under development right now for Firefox 34 including translation in the browser, making voice or video calls (a feature called “Hello” or “Loop”), debugging information for web developers in the Dev Tools Inspector, and recent improvements to HTML5 gaming.

I’ve written step by step instructions on these
ways to test Firefox 34. If you would like to see what it’s like to improve a popular open source project, trying out these tasks is a good introduction.


First, Install the Aurora version of Firefox. It is best to set it up to use multiple profiles. That ensures you don’t use your everyday version of Firefox for testing, so you won’t risk losing your usual profile information. It also makes it easy to restart Firefox with a new, clean profile with all the default settings, very useful for testing. Sometimes I realize I’m running 5 different versions of Firefox at once!

To test “Hello”, try making some voice or video calls from Firefox Aurora. You will need a friend to test with. Or, use two computers that you control. This is a good task to try while joining our chat channels, #qa or #testday on; ask if anyone there wants to test Hello with you. The goal here is mostly to find and report new bugs.

If you test the translation infobar in Aurora you may find some new bugs. This is a fun feature to test. I like trying it on Wikipedia in many different languages, and also looking at newspapers!

If you’re a web developer, you may use Developer Tools in Firefox. I’m asking Aurora users to go through some unconfirmed bug reports, to help improve the Developer Tools Inspector.

If you like games you can test HTML5 web-based games in Firefox Aurora. This helps us improve Firefox and also helps the independent game developers. We have a list of demo games so you can play them, report glitches, and feel like a virtuous open source citizen all at once. Along the way you have opportunities to learn some interesting stuff about how graphics on the web can work (or not work).

Monster madness

These testing tasks are all set up in One and Done, Mozilla QA’s site to start people along the path to joining our open source community. This site was developed with a lot of community contribution including the design and concept by long-time community member Parul and a lot of code by two interns this summer, Pankaj and Maja.

Testing gives a great view into the development process for people who may not (yet) be programmers. I especially love how transparent Mozilla’s process can be. Anyone can report a bug, visible to the entire world in There are many people watching that incoming stream of bug reports, confirming them and routing them to developer teams, sometimes tagging them as good first bugs for new contributors. Developers who may or may not be Mozilla employees show up in the bugs, like magic . . . if you think of bugmail notifications as magic . . .

It is amazing to see this very public and somewhat anarchic collaboration process at work. Of course, it can also be extremely satisfying to see a bug you discovered and reported, your pet bug, finally get fixed.

Related posts:

Mozilla Summit 2013: bugs, crafts, and fun

The Mozilla Summit in Toronto was a lot of fun. I met so many intense, idealistic, motivated open source contributors, it made me feel renewed energy for my own contribution.

On the first day I heard some of the keynotes but missed Mitchell Baker’s keynote on the Nature of Mozilla, which I’m going to watch today. People were talking about it through the rest of the conference, so I’m curious.

The talk I did was called Awesome Bugzilla Tricks and was a fairly short presentation of some tips for using Bugzilla.

As we went through these tips, the talk turned often into a good discussion of how people use these features of Bugzilla. We thought of a new way to implement Bugzilla tags to look more like browser bookmarks.

People talked about their own workflow as we went around the room describing what we do with! That is usually my favorite part of a workshop level technical discussion. It is like a series of sharing mini-demonstrations about actual working process, what we use and what we do and why. That is very illuminating. I realized in our discussion that I was talking with Kohei who made bzdeck, a tool that makes reading bug reports more like an email inbox. I had particularly wanted to meet him so was very happy he came to the talk and the discussion! 😀

Durng the talk I said something a little weird and abstract that was not in my slides, inspired by the discussion. Here it is…

As a literary critic I find it fascinating that it is a huge collection of textual information which we engage with as authors and readers. It is like the ultimate “difficult work”, like reading James Joyce except 900,000 times better and with a more interesting result. There is no way to make it easy to understand, even if you can make little pieces of it easier to use and learn, the underlying information and tasks are beautifully complex and demanding for anyone who engages with it, which means you can’t fail to learn something if you try.

Then, luckily, we went back to talking about practical things, features, dashboards, and workflow.

The other main activity I did at the Summit was to set up a big table with craft supplies. Based on an idea of Lukas Blakk’s, I set up beads, string, and charms shaped like ladybugs, dragonflies, bees, and beetles so that people could make necklaces, bracelets, and other wearable souvenirs. The beads had numbers and letters so that you could spell out the number of your favorite bug.

People did just that!

I loved seeing people think about what bug was their favorite or most important to them personally. Sometimes a first bug, or one that people were proud of fixing, or one with an important, complicated discussion. Several people told me that during the Summit, they looked up other people’s favorite bugs from the bug bracelets, and learned something interesting.

Bug 356038 was represented by number and by its Bugzilla alias, BCP47:


Rust and Github bug #5677, ‘Rustpkg “ready for use” metabug’ got some love:

Tim with Rust bracelet

Vu gave a shout out to bug 780076,

bug bracelets

And here is another bracelet featuring bug 808964,

Bug 808964 bracelet

For my own favorites I made three objects, one a wire necklace for bug 923590, “Pledge never to implement HTML5 DRM”, and a bracelet and a barette with my first patch because I was proud of submitting a patch. The EME or DRM issue was discussed very intensely on Sunday by many engineers. Feelings definitely ran high and people were determined to continue discussion. I was glad it got an official slot in the schedule for discussion and that there was widespread interest.

Favorite bug maker party

Bug 298619 was put onto a cell phone charm along with a blue and orange glass bead shaped like a beetle!


Many other people made Mozilla or MozReps necklaces, spelled out their names or their loved one’s names, with bug charms, or with wire, like this beautiful and creative copper wire creation:

copper wire necklace

And this Maker Party necklace!

Maker Party!

This resulted in “conference swag” was personal and made on the spot, worn and also given as presents! Many people commented that they felt soothed and comforted by hands-on activity in the middle of intense social interaction. I observed that people discussed what bugs or words to spell, how to design their objects, and what techniques to use, very collaboratively, so it was a nice physical representation of work and process.

Mozilla Summit crafts

After the first day, I left the craft station open 24 hours in the lounge, replenishing it with beads from West Queen Street on day 2 becasue we ran out of the letters Z and A, popular in spelling out “Bugzilla” and “Mozilla”. Of course this was because we were in Canada, where they use a lot of “eh”!

I would do this again at a conference, and now I know from experience what supplies are needed and which things are likely to be popular.

The other silly and fun part of the conference for me was wearing (and lending to people) the brainwave controlled robot fox ears! The looks on people’s faces, so priceless, as they realized the ears were really moving. Everyone who tried it laughed very hard!


robot ears

Thanks for a great and inspiring Summit, everybody!

Related posts:

FirefoxOS phone beta testing

I got my FirefoxOS phone and am doing some testing on FirefoxOS 1.1 beta. I’m about to switch over to using it as my primary phone, but so far I’ve just used its apps and web connection. It seems very responsive and fast.

green and orange FirefoxOS phones

My friend Tiziana and I compared phones. Hers is the orange one, a ZTE phone running OPEN_US_DEV_FFOS_V1.0.0B1. Mine is green and is from Alcatel, running FirefoxOS I definitely notice the difference in the new version of the OS in that it is more responsive and I feel more sure in control of the touchscreen. Typing works well. I miss having something to swipe across the letters so I hope an open source version of type-by-swipe is something in the works.

I have installed a few art and drawing apps as well as games. The only game I’ve tried so far is Little Alchemy, which was very buggy in earlier versions this spring, but works beautifully now.

Email setup worked great, browsing is good, I’ve been taking photos and emailing them. I’ve used the Wikipedia app to look things up, and the “I’m thinking of…” search feature to listen to music on the bus. The Music app comes pre-loaded with some albums but I haven’t figured out a good way to load my own music onto the phone. On the other hand I haven’t needed to since “I’m thinking of…” gets me decently fast connections to YouTube and other music sources.

One nice touch with this was that when I bring up my “I’m thinking of” Janelle Monae search the wallpaper background of my search screen changes to a giant aweseome photo of Monae in a tuxedo and I am offered the things on my phone to do with the search on top, then under a hairline divider, searches on Monae in many other categories like free music, Grooveshark, Google, Twitter, her official website, tickets, Amazon, and so on. Here’s what it looks like:

firefoxOS thinking of search screen

That’s different from my usual mental model of “search”. The result is interesting and, I think, powerful and useful. I’ll be exploring it over the next few days at the Mozilla Summit. And of course reporting bugs, but for now, I just wanted to share that the phone not only quite usable as a smartphone, it’s exciting to explore.

Related posts:

Journalists don’t understand Wikipedia sometimes

This morning I saw some pissed-off twitters that led me to articles about Wikipedia’s sexist bias. Always up for a little early morning smash-the-patriarchy outrage, and well aware of some of the clusterfucks that often play out in Wikipedia admin pages, I forged onwards and read the articles, flaring my nostrils in anticipation. In Wikpedia’s sexism towards female novelists Amanda Filippachi points out that many women tagged with Category: American women novelists aren’t tagged with Category: American novelists. She named several examples. Katie Mcdonough from Salon picked up on this, with Wikipedia moves women to American Women Novelists Category Leaves Men in American Novelists.

Even the most cursory googling shows that this is not a very accurate spin. For example look at Amy Tan, Donna Tartt, and Harper Lee, who are named by Filippachi as missing from American novelists. Here is the Donna Tartt article’s history page going back the last 500 edits to 2004. Tartt was never listed as being in Category: American novelist, not because “Wikipedia is sexist” but because no one thought to put that down amid the hundreds of small edits that incrementally improved the article. Until today when someone added “American novelists” to her page, in virtuous activist response to injustice (which I respect, actually). “Category: American women novelists” was never on Tartt’s page.

Okay, how about Amy Tan. The last 500 edits for Amy Tan’s page go back to 2008. Category:American women novelists was not ever on Tan’s page, but American novelists was added today.

Harper Lee’s history, on the other hand, shows an edit on Feb. 21 removing American novelists and adding American women novelists. If you look at the user who made that edit, they often edit categories, and occasionally makes disputed judgement calls, but they appear to be acting alone and from the pattern of their edits, they do many types of edits in several areas, rather than waltzing around sexist-ly removing women from the category of generic human beings, or even novelists.

Just from these three samples, it does not seem that there is any particular movement among a group of Wikipedia editors to remove women from the “novelists” category and put them in a special women category instead. I would say that the general leaning, rather, is to stop people who would like to label women writers as women writers *in addition* to labeling them as writers, claiming there is no need for Category: American women writers at all and that it is evidence of bias to identify them by gender.

When I add writers to Wikpedia because I love their work or find their lives interesting and significant I often am unsure what the trends in categorization currently are. I may add them as Women writers and also American novelists based on looking at a similar writer’s article. If some of the potential categories aren’t there I hope someone will add them.

mmme_hardy on Twitter pointed out to me immediately that the discussion on this topic amongst Wikipedia editors takes place here: Categories for discussion. There is a proposal here to merge “Category:American women novelists” into “Category: American novelists”. The consensus there is to merge the articles, with some people (including me) mentioning the option to merge and keep the category. Merging the category would remove “Category: American women novelists” from many writers’ pages. That also means the page that lists all the pages in Category: American women novelists would no longer exist.

Thus, a well-meaning attempt to include women in the main categorization for American novelists (where many of them were never listed in the first place) may result in women writers no longer being easily identifiable to those who might want to find them. For example if you are looking for Caribbean women writers and they have all been merged into Caribbean writers that might not be a desirable outcome! Filippache mentionsEdwige Danticat being ‘plucked from “Haitian Novelists” and dumped into “Haitian Women Novelists.”’ But I don’t see that plucking happening from the history! Where did that happen!?

Joanna Russ in How to Suppress Women’s Writing lists miscategorization as one of the ways that women’s work is disappeared over time. In this case I am a bit annoyed at the facile reporting that does not seem to take into account the complexity of how information gets added to Wikipedia. If someone can point me to a Category decision from the past where a bunch of editors agreed to remove women en masse from American novelists and put them in American women novelists, go for it, I would appreciate the help in understanding this.

It is much more often the reverse and it would not be too hard to come up with examples — where someone works rather hard on creating a category for Women activists or American anarchist women and then a bunch of other (often male!) editors step in and say that that is sexist and unnecessary and “ghettoizing”. What would be so hard… or so wrong… about listing writers or other people by gender, race, ethnicity or other factor that people who care about identities and identification may want to browse by? Librarians certainly catalogue writers and works that way, and it is extremely useful! I think that the backlash against identity politics is evident here. Yes Wikipedia editors and admins often have systemic bias. In this case the story has been told in an inaccurate way (that I don’t even have time to debunk thoroughly — I am neglecting my day job right now to write this!) and in a way that both discredits reports of actual systemic and individual bias and that harms the visibility of women writers while trying to help that visibility. The sexist thing we should be up in arms about isn’t labelling women as women! It’s the efforts to delete entire categories (like Haitian women writers, for example) because someone has decided that that meta-information is unnecessary “ghettoization”…. the false belief that we should or can be “gender-blind”, “color-blind”, and so on.

Related posts:

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 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.

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

So let’s take the WebRTC example. Say you’ve followed Jason’s advice, used 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 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 account.
Step 4.6 Confirm it with the email confirmation.
Step 4.7 Log in to
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 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.

Related posts:

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!


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.


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

Related posts:

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 with a similarly lovely interface. Thanks to Richard Schneeman for creating CodeTriage!

Related posts: