Interview with Bill de Araujo about contributing to Firefox (Part 1/3)

I sat down today with Bill de Araujo. Bill is one of the MSU students working on multitouch gestures for Firefox. I asked Bill about his experience and what he thought about contributing to open-source software.

Check out the video below for the interview (1m 31s):

I also got a chance to interview the other two students working on the project, Brandon Waterloo and Ray Heldt. I’ll be posting their interviews in the coming days.

Firefox Bug Triages

Since our Firefox work week in Toronto, a handful of people working on Firefox have begun triaging some of our older bugs.

The goal of the triage is to look at old bugs (6 years and older) and either:

1. Resolve as fixed (fixed through some other means), wontfix, or invalid
2. Move to a different component, or
3. Leave as-is

Our first three triages focused on the following components:

• Firefox::Tabbed Browser
• Firefox::General
• Firefox::{Menus, Microsummaries, Migration, Page Info Window}

In the first three triage meetings we closed 257 bugs! We have only been focusing on bugs marked as “NEW”, meaning that they have been confirmed but work has not begun to fix them. The Firefox product in Bugzilla currently has 8,579 “new” open bugs, so these three triages have trimmed close to 3% off of our previous total.

How do we run the triages?

Before the triages, I run some Bugzilla queries to gather a list of about 175 bugs within Firefox components. I chose that number of bugs so each person can get about 25 bugs apiece (we tend to have about 7 people triaging).

The bug list is then split in to ranges of about 25 bugs in size and people assign themselves to one of the ranges using our etherpad. I then send out a meeting invite with a link to the etherpad and ask that people triage their assigned bug range individually before our meeting.

About a week later we have our triage meeting, where we discuss bugs that we were unsure of.

Bugs that need retesting are marked as-so on the etherpad. We hope to have a Firefox front-end testday sometime soon to go over the bug list that we have curated.

Where do we go from here?

A lot of these dead bugs were easy to close, but as we’ve cleaned them up the newer bugs (2008 and onward) are getting harder to close. They are more relevant and still exist as valid issues with the product. We are able to associate some of them with newer features that will fix them indirectly, and others we are able to turn in to “good first bugs” or fix outright (see my recent post for one example).

We are continuing to have more bug triages (we had another one today, which has so-far closed 24 bugs). After we have hit all of the Firefox components we should have less dead bugs in the system, and it will be easy to have triages that occur less often but cover the whole Firefox product.

We can also start triaging some of the more recent bugs and being more proactive about closing out bugs that don’t align with our goals.

We also need to schedule that testday that I mentioned above. I (or someone else) will have to coordinate with the QA team to schedule a day where people can help us test and close out some of these bugs.

What have I learned so far?

I’ve had a few takeaways from this process:

1. We should be more open to closing bugs when we know that there is not a realistic chance of the bug getting fixed. This line of communication is important to provide to the people that file bugs, and it also provides a permanent background as to our stance at the time. This is much more helpful when revisiting a bug than finding years of silence and inactivity.
2. Lots of feature requests carry great inspirations for add-ons. As we strive to keep Firefox lean and agile, we need to make sure that features that find their way in to Firefox are useful to over 95% of our users. Implementing an add-on allows greater potential and a deeper feature set than we would be able to pursue if the feature was standard to Firefox. One great example would be to compare Firefox’ click-to-play implementation with that of FlashBlock.
3. Splitting tasks like this up ahead of time allows our meeting to be very focused and fast-moving. I’ve participated in triages before where everybody at the meeting went through a list of bugs and discussed each one individually. While that allows for deep discussion on each bug, it’s not a very effective use of our time. Many bugs are easy to close, and ones that may require a deeper dive can be tabled until our meeting.

Come learn about FirefoxOS at MobiDevDay Detroit

I’m excited to announce that I will be presenting at MobiDevDay Detroit on May 4th on the topic of Firefox OS.

FirefoxOS is Mozilla’s new mobile operating system, based entirely on web technology. FirefoxOS will bring full device capabilities to the web stack, allowing web developers to create immersive experiences in a cross-platform and device agnostic manner.

This talk will briefly cover the motivations of FirefoxOS and then dive in to the new technology and APIs that are being opened up to developers who are looking to create apps for FirefoxOS.

MobiDevDay Detroit was the first conference of its kind. Now in its third year, MobiDevDay is dedicated to bringing the world of Mobile to Michigan’s Software Developer Community. We hope to grow MobiDevDay Detroit into the most important polyglot Mobile Developer conference in the world.

MobiDevDay Detroit 2013 will be held at the Cobo Conference Center on May 4th.

Breakfast, Lunch and Free Parking will be provided.

Register today for the conference before it sells out. I’ll share more details about my talk as the date gets closer.

Ludicrous Speed, GO!

There’s another new feature in today’s build of Firefox Nightly that I want to call attention to.

In Firefox Aurora, web developers can adjust the speed that HTML5 videos are playing at using the mediaElement.playbackRate API. This API lets websites control the speed that videos play at, whether they are in slow-motion, normal, or high-speed.

Starting today in Firefox Nightly, you can adjust the speed that videos play without needing to know JavaScript. To try this out, right-click on a video and enter the Play Speed menu:

The menu, implemented by darkowlzz, allows the user to change the playback to one of four speeds:

• Slow Motion (0.5×)
• Normal Speed
• High Speed (1.5×)
• and … Ludicrous Speed (2×)

I should note that there is still one remaining bug with the feature. Videos that are switched to the non-default playback speed will not switch back to Normal Speed using the context menu. This bug is on file and will need to be fixed before we can ship this feature on our Release channel. A simple workaround is to seek the video, as that will reset the playback speed.

Improved plain-text handling in Firefox

If you’ve ever tried to read a plain-text file in Firefox, you may have noticed that we didn’t have an option to apply word wrapping to the text. New in today’s Firefox Nightly build, we are now applying word wrap to plain text documents by default.

For example, this file is very hard to read when the lines aren’t wrapped. The lines scroll offscreen horizontally, and the user has to use the horizontal scrollbar on the bottom of the screen to read the file (yuck!). Here’s a screenshot of what I’m talking about:

Long lines are not wrapped

With word wrapping applied, the text is much easier to read and the line length will adapt to the size of the browser window:

With long lines wrapped

Some documents aren’t ideal for word wrapping, and to aid that we have made it easy to disable the feature. To toggle whether the document is wrapped on a case-by-case basis, you can change between the “Wrap Long Lines” stylesheet and “No Style”.

If you’d like to disable the feature entirely, you can go to about:config and set the plain_text.wrap_long_lines preference to false.