open source – Page 2

How to test new features in Firefox 34 Aurora

September 11, 2014 Liz

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.

Aurora

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 irc.mozilla.org; 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 bugzilla.mozilla.org. 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.

Mozilla Summit 2013: bugs, crafts, and fun

October 10, 2013 Liz

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.

Awesome bugzilla-tricks-slides2 from Liz Henry

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 bugzilla.mozilla.org! 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 Bugzilla.mozilla.org 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:

Vu gave a shout out to bug 780076,

And here is another bracelet featuring bug 808964,

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.

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:

And this Maker Party necklace!

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.

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!

Thanks for a great and inspiring Summit, everybody!

FirefoxOS phone beta testing

October 3, 2013 Liz

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.

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 1.1.0.0-prerelease. 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:

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.

Journalists don't understand Wikipedia sometimes

April 25, 2013 Liz

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.

File a bug: the missing manual, now with unicorns

April 9, 2013 Liz

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!

March 27, 2013September 24, 2022 Liz

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!

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!

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

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!

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.

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.

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.

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

CodeTriage looks very cool!

March 1, 2013 Liz

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

February 21, 2013 Liz

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!

December 11, 2012 Liz

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.

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

May 23, 2012September 24, 2022 Liz

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!”

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!