mozilla – Page 2 – Composite

Screen reader and accessibility bug day

March 11, 2013 Liz

Tomorrow Mozilla is hosting a screen reader and general accessibility bug day.

Len Burns and I have invited screen reader users of Firefox and other Mozilla products to join us in sorting through existing accessibility bugs. Some folks from the Mozilla Accessibility team will be on hand to talk with us.

I’m pretty sure we will also collect some new bugs along the way!

I hope that people will make new connections, and that we can attract a wider accessibility bugmaster team to do ongoing work with Mozilla’s existing developers and a11y experts.

The screen reader landscape for web access is fairly complicated. For example, here are the Firefox Gecko docs for Windows accessibility vendors which explain the relationship between the DOM tree and Microsoft’s accessibility API. Common screen reader software includes NVDA, Window-Eyes, JAWS, and Orca.

Orca2 sm

If you would like a quick overview of common web access issues, look through Aaron Leventhal’s presentation. I like it because he includes some political dimensions and context for accessibility.

So far, the “bugmaster” bug days have been combined with QA’s efforts. I’m hoping to also hold focused bug days like this one, in cooperation with various teams across Mozilla. As we gather more templates for bug managing and triage, I hope we’ll coalesce bugmaster teams with expertise in particular areas. And we can repeat topic-focused bug days periodically.

If you are interested in web accessibility or if you use a screen reader, please drop by on Tuesday and say hello in the #accessibility channel on irc.mozilla.org.

You can also add the name you go by, your irc handle, your contact infomation, or anything else you use to identify yourself, on the wiki page for the bug day under Participants: https://wiki.mozilla.org/Bugmasters/Bug_days/a11y#Participants .

The goals of the screen reader bug day are to improve everyone’s experience of Firefox and other Mozilla tools. We would like for everyone to be able to access the web smoothly. Through collecting more information on accessibility bugs, we hope to connect committed technical users with accessibility developers, and make our community better and more powerful. Our bugmaster work should help to make developers’ work easier. That way they can spend more time fixing stuff.

If you have any questions or feedback, please feel free to email me at lhenry@mozilla.org.

In setting up this event I tried to make sure that the tools we are using are as accessible as possible. Etherpad, which Mozilla teams often use for bug triage events, is not useable for screen readers. The wiki.mozilla.org pages seem readable though editing may be more of a challenge. IRC feels like our best bet for good communication. I also went through about 100 screen-reader-related bugs and emailed the bug reporters and commenters to send them invitations to participate.

Len is particularly interested in developing a plan for Thunderbird and screen reader vendors. If you share this interest I recommend joining the mailing list tb-planning.

Here is what Len has to say on Thunderbird accessibility:

It is complicated, because the issues are really between the two major screen reader vendors and Mozilla. Meaning, that the solution would need to be a cooperative one. Because the screen reader vendors perceive, right or wrong, that little more than security bugs are being updated in Thunderbird, they do not seem terribly motivated. I am not quite sure where to take it.

Unless I could convince the vendors that solving these issues are worthy of their time, I am a bit stuck.

I would definitely be willing to raise the specifics with both vendors if I could give them some reason to encourage a belief that there is a mutual interest in improving things. When I have raised several with GW Micro I hear things like: This has been filed for over a year with no response, and the like.

Those of us using screen readers are currently in quite a pickle regarding email. The choices are quite limited. A lot of us have been using Thunderbird for some time, but when things reach a point where you are spending too much time trying to send a simple email, something must give.

I can also tell you that what finally tipped me were problems between the composition screen, and other open apps on-screen. If I were going to compose an email in TBird right now, I would have to be sure that Skype was minimized, MirandaIM was minimized, etc. If I did not, I would be likely to encounter a range of strange behaviors in the edit window such as being unable to read back the text I am writing, inaability to use my backspace, format distortion, and more.

What has been slowing me down on these issues was a lack of knowing avenues of pursuit. The challenge will be convincing vendors that investing time is a benefit. My position is that I am not sure, but, we have a good chance of catalyzing and contributing to change and possible strengthened relationships.

Len has been a professional system administrator, coder and web accessibility consultant since the Internet was a kinder and gentler place. He makes his living these days free lancing as a web accessibility consultant for colleges and universities and coding the back-end glue of web sites for small to mid-sized businesses.

Thanks to Len for his insights on web dev, email, and access in the last couple of weeks as well as his outreach efforts to talk with vendors, software users, and developers!

Bugzilla hijinks, Tuesday March 5

March 4, 2013 Liz

Tomorrow evening (Pacific time) the bugzilla.mozilla.org and IT folks will be moving BMO to a new infrastructure and upgrading to Bugzilla 4.2.

No bugzilla cartoon

I’ll be up on the 7th floor of the SF office with Shyam and probably others. I know a few comunity contributors will be showing up on IRC around 8pm PST to help test during deployment so if you’d like to participate, let me know!

Earlier on Tuesday, before the outage, there will be a QA-run Firefox unconfirmed bugs day. This is a good event for people new to bugzilla and bug triage! Create a bugzilla.mozilla.org account for yourself and come introduce yourself on irc.mozilla.org on the #qa or #bugmasters channels.

I plan on going through all the Mac bugs that I’m able to, to try to replicate them and add any useful information to the bugs. Right now there are 85 unconfirmed Firefox bugs that were first reported in the last week. That number might be different tomorrow obviously!

I find it very useful in Bugzilla when I get a link to a search like this one, to click “Edit Search” at the very bottom right of the page. From that, I can see what options created that result. And I can narrow the search down further or build something useful for myself, and then save it in my saved searches. Now I have a nice search for just the recent bugs reported for Firefox on MacOSX. I mention this mainly because it took me a while to notice the “Edit Search” link — until then, I was trying to deconstruct and add to the parameters in the URL by hand.

At 8:30pm the Bay Lights are going to come on: a dynamic light show decorating the whole north part of the San Francisco Bay Bridge. I’m hoping to get some awesome photos of the lit-up bridge from the Mozilla office roof. It looks basically like thousands of blinky christmas lights all over the bridge along with some sort of giant arduino mastermind program. It is nice that the bridge will be known for something other than “3rd most destroyed bridge in disaster movies throughout the ages”.

Walking through early bug triage

February 1, 2013 Liz

Here is a good example of a bug that went through several stages of triaging:
Scrolling a page up leaves residue in GTK slider. I would like to walk through what happens in triaging this bug. Blow by blow report!

The bug reporter, Przemek, was new to Bugzilla, so their report was automatically put into the UNCONFIRMED status. The bug summary (the title) was originally “artifacts on scrollbar in seamonkey 2.15” and it was put into the product Seamonkey and component General. (Here is a list of Seamonkey components, if you’re curious.) Przemek attached a screenshot of the problem. At the bottom right corner of the screenshot you can see the scrollbar has some weird stripes on it.

Scrollbar bug screenshot

Matti suggested a possible duplicate bug. That shows us a related problem and which product and component it might belong to. It also can reveal some people who work on this type of issue.

Another commenter, Slim, relatively new to Bugzilla, chimes in to say they have exactly the same issue, in Linux and that it may be a GTK problem. They include the information from about:buildconfig .

A fourth person, Philip, asks if someone who sees the problem (either the reporter or Slim) can try toggling a preference. Slim tries it but it doesn’t fix the issue. He speculates it is related to Bug 297508. Philip uses the NEEDINFO flag to ask Przemek a question (this emails Przemek with particular Bugzilla mail headers). Przemek replies, which
automatically clears the needinfo flag. Philip then decides to move the bug from the product Seamonkey to “Core”. component General to Widget: Gtk. That shows up as General -> Widget:Gtk in the comments.

One week later, Karl shows up in Comment 10. If we look at the list of module owners and peers for Mozilla, we can see that he is the owner for Core::Widget:GTK. I figure he was probably was looking at bugs in that area, or reading his bugmail backlog. There are 328 bugs UNCONFIRMED or NEW for Core::Widget:GTK, which you can see if you do an Advanced Search. Anyway, Karl reproduces the bug and moves its status from UNCONFIRMED to NEW. He added the keyword, “regressionwindow-wanted”. The next day he comes back and adds some info about the regression window and removes the “regressionwindow-wanted” keyword. narrows that window even further. He then moves the bug to
Core:: Layout and adds the keyword “regression”. It is probably out of his hands now. But whose it it in?

There are over 2300 open bugs in Core::Layout, 1809 of them new and not assigned to any particular person. If I look to see how many of them have the keyword “regression” there are only 140, most of them assigned to “nobody”. So if I wanted to fix something in Core, that might be a good place to look for a bug that needs attention.

All the commenters described here were doing bug triage or what I am now calling bugmastering. Five people, two weeks. I think all their efforts and comments were useful in moving the bug along and adding new information to it. It is also instructive (and for me, reassuring) that not everything was “right”, right away. Actually, I think it’s beautiful to see how well everyone communicates, much of the time in Bugzilla.

At this point, if Bugzilla had the READY status implemented, I would call it READY. Not just to signal to developers that it is ready to be worked on, but to signal to other triagers that it may be done and they don’t need to keep looking at it. That is part of why having a clear demarcation point will be useful. Even though there is more than could be done, this is probably enough for someone knowledgeable to take it and work on it. I would consider its “early triage” life to be over and for it to be in the hands of engineering, QA, and rel-eng, who have their own models for triaging internally for their stages of handling the bug.

Now, that doesn’t mean that as your Mozilla Bugmaster, I can blithely ignore all bugs once they are done with early triage. Yet since this is a minor layout bug that does not seem to affect function I think I can let it go and hope that someday it is fixed.

It is possible that we could make some cruft-killer searches, reports, or other views that could pick up this sort of bug 6 months from its first reporting, and do anohter check to see if it still exists. If it’s been cleared up in the meantime, make a comment mark it RESOLVED WORKSFORME. Right now I’m sure some people have figured out good systems to do this, but I think most people stay focused on what’s incoming or what is especially brought to their attention. Re-assessing old bugs, or bugs within a particular time window (6 months to a year old, but not 10 years old) may be a good way for beginning bugmasters to start chipping away at some of the cruft in the system.

Bug history and conversations

February 1, 2013 Liz

David Baron wrote an interesting post recently, Moving bug history out of the primary display of a bug report. I have noticed this problem in Bugzilla, that even if a bug is “ready to be fixed” or has patches submitted it is necessary to read through 5, 10, or 50 comments to understand what is supposed to happen next (if anything). dbaron proposes that the main page of a bug report should show its current state. What is true about it? And what is to be done next? This would be obviously awesome for some bugs, but not for others for which there isn’t a clear state of truth. My first instinct is to question dbaron’s idea, as there might be bugs for which the conversation is the most important aspect.

For example Bug 130835 – Make Bugzilla’s index.cgi (home page) useful for logged-in users has over 150 comments, stretching back 10 years. Here the problem may actually be that the bug (or enhancement request) was not well defined in scope, so had no clear end. It might be worth untangling the useful ends of these 150 comments to close this bug, and open several new and more specific ones for which “current state” *could* be summarized as dbaron suggests.

But what about a bug like Bug 83192184 – Make the plugin click-to-play UI look less like ‘plugin broken/crashed’ UI , where there is a useful active conversation? In that case trying to synthesize the conversation at every step of the way, each time someone comments, is probably not useful.

So in some cases there is clear “current state” or content, as there is on a Wikipedia page, but in some, the conversation is the content. I don’t want to have (or read) conversations in a Bugzilla equivalent of Wikipedia talk pages and am not sure that would be an improvement on the current state of Bugzilla comments. For bugs with a long history, especially ones which have mutated significantly since their beginning, the “current state” field might be an easy way to untangle the mess.

My job, told with Up-Goer Five text editor

January 20, 2013 Liz

Today I had fun reading xkcd’s Up Goer Five cartoon and then playing with the Up Goer Five text editor.

I tried describing my new job:

Many people at my job work together to make free things that go on computers to make it so everyone can see the words and pictures on other computers in the world. Everyone can see the words that make these free things. The biggest thing we make is named after an an animal and fire. Fire Animal Computer thing can go on a a computer, or a phone. It can even start a phone and make it go. That is new!

There are other computer things too, like Rain Noise Flying Animal and Water Tree Animal. They have new parts all the time. When the Fire Animal Computer Thing or the other computer things have a problem, people tell us about the problem. That problem goes in a very big computer box place together with all the other problems. That very big computer box place is named Big Pretend Long Ago Problem Animal.

My new job is to watch all the almost hundred hundred hundred problems in Big Pretend Long Ago Problem Animal. I will remind everyone in the world to work together on a big big team to fix the problems. I have to know many things to help them do it. On this team we will all tell the people to talk to each other. I look at the words and put other words on the computer to tell about the problems. I work with many other people that help put more words on the problems to help fix them.

Some day I will know many more things and many more people who fix the problems, especially with Fire Animal Computer Thing. I will help make ways to make the work easier. There will be more computer things that work almost by themselves to do the work. Then, all the Big Pretend Problem Animal work people like me will tell the computer thing making people some more things to help them fix the problems. We do it in a way that everyone can see!

We will work together so all the people in the world can talk with each other and see pictures with no problems, free, on a computer and on a phone. They can make many more things. We think everyone can help the world this way. Some day, everyone can know all the things. That will be very good.

Thrills, chills, filters, and bugmail

January 17, 2013 Liz

Any bugmail at all is probably way too much bugmail. That means you will need to set up some structures to filter it!

This explanation may be useful for anyone interested in contributing to Mozilla — especially bugmasters, triagers, and developers. Even if you don’t use the same email setup, there’s some good tips.

Byron (aka glob) explained how I could set up my Bugzilla email, or bugmail. Within Bugzilla, in the Email preferences tab, there are a complicated set of checkboxes to control what conditions in Bugzilla trigger your bugmail. Right now, my email notifications are set to fire off email to me whenever anything happens to a bug I may be interested in.

Bugzilla email prefs

I then set up some users to watch, at the bottom of the Email preferences screen. Whenever Matti, Tyler, or Benjamin do anything with a bug, Bugzilla emails me about it. I can also see that Josh is watching my Bugzilla activity. People often refer to this as “stalking” in Bugzilla, without any creepy connotation intended. It is basically TMI about someone else’s bugs (or what bugs they poke at.)

Bugzilla user watching

“If you watch a user, it is as if you are standing in their shoes for the purposes of getting email. Email is sent or not according to your preferences for their relationship to the bug (e.g. Assignee).” The meaning of that takes a while to work out, much like Bilbo Baggins’ famous statement at his eleventy-first birthday party… “I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.”

I have picked two components to watch. Bugs in BMO (bugzilla.mozilla.org) are organized first by Product, such as Firefox, Firefox for Android, Thunderbird, and so on; then by Component, which seems to be a division by who is working on a particular area or project. You can’t pick a Component, or even see it, till you figure out what Product your bug belongs to. Here is a helpful guide from the Mozilla Developer Network with a list of Mozilla Products and their Components, handily all on one page, so it is easily searchable. I have also been using the list of Modules and their owners from the Mozilla.org wiki.

Bugzilla component watching

We don’t even have any bugmail yet, and see how much we have learned about the structure of a giant complicated FLOSS ecosystem! Hurray!!!! *waves pom poms*

Cheerleader cat

At this point, I made some folders in Zimbra inside a general Bugmail folder. While I’m still not sure how I’ll settle on bugmail organization, right now I have separate folders for my watched components and people. Then, in Zimbra preferences,there is a sidebar option for “Filters”.

Bugzilla filters

Create a new filter, then for users you’re watching, filter on header, and set the header name to X-Bugzilla-Watch-Reason. (For other filters, check the full headers and see what X-Bugzilla header info will work best.)

Bugzilla x headers

Since the X-Bugzilla-Watch-Reason filter contains the person’s email, if they change their own bugzilla email address, my filter will break.

Bugzilla user watching

Onward to Thunderbird, which I have set up with IMAP to check my Zimbra account.

Right-click (or command-click for a mac) on your account name in the Thunderbird sidebar, and choose “Subscribe”. This shows you the folders on your IMAP-connected account. Expand the folders and check the tickybox next to the new folders you just created in Zimbra (or whatever else you use). This will create a copy of that folder in Thunderbird.

Bugzilla thunderbird subscribe

One more step. In the Thunderbird sidebar, right-click one of the new folders that was just copied over from your IMAP account. Choose “Properties”. Then check the tickybox labelled “When getting new messages for this account, always check this folder.”

Now your bugmail will nicely filter itself — in both email clients.

That was non-obvious enough that I really wanted to document all the steps. Maybe some other new hire at Mozilla will be helped!

If anyone has bugmail tips for me, I would appreciate that!

Bonus points to anyone reading this who notices my PretendOffice filter and has a good laugh.

In which I explain Yggdrazilla, the World-Tree, and see some fireboats

January 3, 2013 Liz

Yesterday I headed into the Mozilla San Francisco office with my son Milo in tow. It was sunny and beautiful! We had lunch at the High Dive, a little diner right on the waterfront. He tried out my TV-B-Gone delux and we laughed very hard at the feeling of being super-spies with our spy gadget. Or, he might have just been laughing at me. It’s hard to tell!

On the walk back from the diner I pointed out the old SFFD building and that there was a fireboat on the other side of it. We went round to watch the boat pull out of its berth, apparently giving some non-firemen a tour in the sparkly winter sunshine. On its side it was labeled Guardian, boat #2. There was a sign in front of the building explaining the history of San Francisco fireboats. We both avidly read this sort of thing. The more famous of SF’s fireboats is the Phoenix from 1955, which saved the Marina district after the 1989 Loma Prieta quake. “I guess it’s still useful, even though it’s old-fashioned” he commented. The fireboat is also extremely cute; stubby and with a little striped tower, like a tugboat.

At the office I picked up a B2G test drivers phone so I can help test FirefoxOS. Sights of the office for my son were: my cube (unexciting), the shelves of free snack food (from which, abstemiously, he snagged a banana and two starburst candies), and the roof with its view of the Bay Bridge. The night before, I had read him the first few chapters of Flatland. He had picked it up to read on the bus and while I worked, since it’s lighter to carry than the Draconomicon. He kept interrupting my concentration on email and Bugzilla to read me bits from Flatland.

I figured I would return the favor. “So, would you like to know what I am actually working on?” Yes he would. Whatever I do for my job On The Computer is something of a mystery. Even to me . . .

We read the principles in the Mozilla Manifesto. (“Nice, Mom. That sounds like you. But, no offense, but, well, I’m already reading a book where people explain boring things about politics.”) Okay, moving on. I explained that there is a non-profit Mozilla Foundation as well as Mozilla Corporation, then that there is a greater Mozilla community (Mozillians!), who all work on making various tools better: Firefox in various flavors, which he is familiar with, but also Thunderbird, Bugzilla, and other stuff.

He got that Bugzilla is a product anyone can download, install, and use to track problems, but that Mozilla has its own implementation of Bugzilla, which we call BMO (for bugzilla.mozilla.org). Someone puts a bug into BMO; then a lot of people might look at it and do something with or to it.

My job as the newly-fledged Bugmaster is to help manage the huge volume of bugs in BMO. I pointed out that in a search for bugs filed in the last 24 hours the ID numbers for the bugs are up to 82600. So 800,000 bugs have been reported since Mozilla has been around, over 10 years ago.

(ETA: You need to have a bugzilla.mozilla.org login in order to use the above link. Hmmm.)

I’m taking a look at triaging new bugs, or in this case, adding information to bugs with UNCONFIRMED status and moving them to some new status. Generally, a bug that is UNCONFIRMED has not been triaged. My big question right now is, though there is no natural “end” to triaging a bug, how can we demarcate untriaged and partly triaged, bugs from ones that are… let’s say… good enough for now for a developer to look at? I could encourage people who do something with a bug to move it out of UNCONFIRMED. I could invent a system of whiteboard tags or flags to mark up bugs for the bugmastering throngs who live in #bugmasters.

Anyway, I didn’t go into that for Milo. I gave a very quick, hand-wavy explanation of how FOSS projects tend to have a “trunk” which is basically the code that’s been tested and released, trying to give an impression for him that a lot of people touch that code as it gets committed to branches, tested, and merged in to the trunk, watched over by Sheriffs. I showed him the tinderbox push log page which displays commits and a battery of automated tests that they pass or fail. Milo (who is not into programming at all) commented that there is Mozilla, and Bugzilla, and everythingzilla, so there should be Yggdrazilla, like the world-tree from Norse myth, to describe this cool giant tree of code.

I love the name Yggdrazilla! Though I’m not sure what exactly it would describe!

This morning as I fired up to work from home, Milo came in to show me an amazing coincidence! One of his giant phone book sized DC comics compilations from Christmas has a comic book about Center City and its new fireboat, the Phoenix!

We stopped on the way home at a TMobile store to get a SIM card for the B2G test phone, and then excitedly fought over it to play Little Alchemy on the bus and after dinner. I’m going to set aside time to poke at FirefoxOS (aka B2G or Boot2Gecko) every day but am not sure I’m going to use it for my primary phone. I informally reported one UI issue with it, and today would like to double check on that and will probably put it into Bugzilla. It immediately wanted to import all my contacts from Facebook, and all the contact info for my Facebook friends. Wow. Scary but interesting. FirefoxOS is going to released soon and will make smart phones a lot cheaper and therefore more accessible for people. As soon as I can buy one for Milo, I will — it will be his first smart phone. It’s really tempting to try to write an app for it.

First week at Mozilla

December 20, 2012 Liz

My first week (and a half) at Mozilla has been about organizing information. The HR orientation stuff was mostly directions to mozilla.org wiki pages, IRC, and mailing lists, echoing the “Get Involved” path into Mozilla that any volunteer contributor can take. A bunch of the meetings that I joined are public meetings that anyone can attend over IRC, dial-in, video, or Air Mozilla broadcast. Transparency and community inclusion seem to be the default for everything.

I made up stuff for myself to do for the first week, with fairly modest goals. I signed up on the Firefox support forum, which gave me a nifty profile and a list of user questions that need answers. I tried answering a few, and looked at other contributor’s profiles. A hard problem led me to Bugzilla, where I had already created an account. There are hundreds of thousands of bugs listed in bugzilla.mozilla.org and it is now my job to understand what’s going on in there. In the next few weeks I’ll be writing about that! My focus will be not on fixing bugs, but on understanding how to triage them — how to figure out whether they are valid or not, how to mark them up or get and add more information to a valid bug, and how to route the bug to where it needs to go. Rather than zapping, squashing, or stomping the bugs we will tame and herd them!

As part of my path into Bugzilla I picked an active product and component to watch through bugmail. Bugs in bugzilla.mozilla.org, or BMO, is categorized by product, such as Firefox, Firefox for Android, or Thunderbird, then, within those products, categorized by component. In my preferences on the site, under component-watching, I picked Firefox as the product and Untriaged as the component, and turned on email notifications. Whenever something in that component is added or changed, I get bugmail. So far this is around 100 emails per day. I set up filters to route that bugmail into a folder and am watching what happens to those bugs, occasionally trying to triage them myself.

As I navigate all this I will be breaking down bug triage into various workflows and processes. I’m hoping to expose places where we can write tools to help people sort and triage this stuff. Yes, the glamorous life of a bugmaster! Join our cult! Or, at least, our #bugmasters IRC channel!

The Bugzilla for Humans video is useful as an introduction. And there is a weekly QA triage day that I will be going to.

The Mozillians doing this bug wrangling have a huge amount of expertise. I feel so humbled as I watch the flow of information coming into these systems and see what they’re doing.

As part of coming into an open source project to contribute to it, I have to accept that I know nothing, things are confusing, and it will all come together as I go along. It’s inspiring, and I want to live up to its awesomeness.

Being a contributor to Mozilla is amazing not just for the individual people I’m meeting, but because I’m seeing a huge, organically created, largely self-directed system at work. It has a strange beauty.