Hacking for Christ

Self-Signed Certs

Recently there has been a lot of discussion on the topic of Firefox 3's warnings about SSL certificates which are invalid or not signed by a known authority ("self-signed"). Following on from johnath's earlier excellent blog post, our position on the subject is set out in "Firefox 3 and Self-Signed Certs".

This page explains why Firefox 3's SSL UI was designed the way it was, and why we think it's right.

Nanny State

I have just confirmed with Enfield Council that I can now technically be prosecuted for leaving my bedroom door open because, as of yesterday, it bears an ugly blue "Fire Door - Keep Shut" sign.

The Management of Houses in Multiple Occupation (England) Regulations 2006, section 10, paragraph f).

Time for a change of government, I think.

Old Reviews

One project I haven't had time to get to this summer is doing something about old reviews. Having old reviews lying around is very bad, because it leads to discouraged new contributors. These are often people who don't know how to make sure the have asked the right person for review, or how to agitate to get their review done.

Basically, it would run like this:

1. Allocate a module to each Bugzilla Component
2. Find all reviews older than a certain date in that component
3. Email a link to that list to the module owner

The module owner would then be in a position to go through the list and either cancel the reviews, poke the existing reviewer (if still involved in the project), or reassign the review to someone more likely to do it.

It's not a magic bullet, but it splits a big hairy problem into smaller chunks and allocates them to the people most likely to be able to do something about them. Stage 1 is the complicated part, and that's where I got stuck (with a proposal to move the Module Owners List to a wiki in order to make it easy to add ancillary data like this). So you'd probably need to write a parser for the HTML version of the Module Owners List (because getting the data out of despot directly is hard). Fortunately, Bugzilla is more obliging for the list of Components.

Anyone up for taking this on? You might need to be fairly familiar with the project, in order to do the mapping in stage 1. But perhaps that bit could be crowdsourced.

GSoC Wrapped Up

The Mozilla project's Google Summer of Code participation has just finished, with the completion of the last Final Mentor Survey. Nine of our eleven projects were successful, mostly very successful, and I'd like to thank all our hardworking students and mentors.

IE 8's "Please Break My Website" Button

So instead of standards-compliant websites needing to include an extra <meta> tag to tell IE 8 to render in standards mode, they now need to include an extra <meta> tag to tell IE 8 not to show a "please break my website" button in the chrome.

Fantastic.

Streaming

So far, people seem to have been talking about using the <video> element with static files. But it works fine on streams too. I put together a very rough demo page to show it off (requires very recent nightly - last week's didn't work, today's did).

Expiry Canary

Expiry Canary is a Firefox 3 or SeaMonkey 2 add-on to warn you about certificates which are about to expire. You can alter the warning period and the sites on which it activates, allowing site admins to have a backstop warning about certificate expiry and prevent embarrassing accidents (Google, Yahoo, LinkedIn).

You can find it in the sandbox on addons.mozilla.org for Firefox 3 or Seamonkey 2. Please add feedback :-) And if anyone is able to draw a better icon, please get in touch.

Thoughts On Bug Volume

The Mozilla project is groaning under the load of incoming bugs (see this thread in the newsgroups for some info and stats). Firefox is, I assert, not getting any more buggy (if anything, it's getting less so), and yet the number of bugs filed is going up and up. It may well therefore be that a greater percentage of bugs filed are not actually useful to us.

There's a good chance that any one particular filed bug is actually a bad thing - that is, its existence has a negative impact on the project. Each filed bug takes valuable contributor and/or developer time to triage and assess. If a layout developer spends 20 minutes looking into bug A and finding it's a duplicate of bug B, he's just acquired a small bit of information ("bug B may be more common than I thought") at a very high cost. The time of layout developers is very valuable - there aren't many of them.

More bugs is not necessarily a good thing. Bugs reduce bugzilla.mozilla.org performance, they clog up searches, they inflate numbers (which depresses people) and they tempt people to spend time looking at them.

So as a first step, let's move away from the idea that every incoming bug report is valuable in and of itself, and we have to feel guilty if we don't do anything with it. After all, we've already done this for broken website reports and crashes - all the reports go into Reporter and the crashes into Breakpad, but we aggregate them and look at the most frequent. That means that the reports of some people with rare crashes or with problems on not-popular websites will never be considered at all. No-one suggests that we are telling the reporters of such problems that they are not valuable because we do nothing with their information. So why should this be true of other bug types? Ignoring a bug is not a statement about the personal worth of the person who filed it.

We need to figure out where the greatest concentration of value is and focus on extracting it, rather than trying to answer the question "how do we extract all the value?" Trying to get everything is a Herculean task which will result in miserable and burned-out QA people.

So how do we extract the most value for the least effort?

Firstly, we need to make sure that everyone with a problem ends up in the right place. There are lots of different places they might need to be:

• Bugzilla
• Hendrix
• Broken Website Reporter
• SUMO
• MozillaZine Forums
• Support Newsgroups/Mailing Lists

We need to figure out what the right places are and who needs to go to them when. E.g. when should someone be sent to SUMO, and when to the MozillaZine Forums, and when to the support newsgroups? Do we need to close or deprecate one or more of these support mechanisms in order to pool resources and have a consistent story? Or do they in fact serve different constituencies? If so, what words will direct people to the right one?

One suggestion would be have a well-known URL which explains what options there are, and why you might want each of them, and make sure everyone always links to that rather than any of the individual tools. The top of the front page of Hendrix or of b.m.o. actually looks a little bit like what such a page might be.

This not only benefits the people with a problem, but it benefits us, because we won't get support requests in Bugzilla or bug reports in SUMO.

Once we've done that, there are several things we could do to cut down the flow of incoming bugs:

1. Reduce the number of people who turn up to file (make the bug reporting mechanism harder to find, or direct people elsewhere)
2. Reduce the conversion rate (i.e. scare people off during the process)
3. Get more aggressive about resolving bugs INCOMPLETE
4. Find a way to aggregate general bugs automatically
5. Ignore more bugs (sort of what we are doing now)

I'm sure there are more things than that.

The question is: which of these will be most effective at retaining the valuable and discarding the less valuable? Different options will bias the bug filing process so that different sorts of people are more likely to be successful. For example, option 1) favours the inquisitive.

Here's an important observation. Option 2) favours the persistent. If there is a correlation between that personality trait and bug quality - i.e. persistent people make better bug filers - then making the bug filing process easier to understand might actually be a bad move for the project. This seems counter-intuitive, but I think we need to grasp the idea that if there's one resource that's plentiful here, it's the time of bug filers. And so optimising the process for their time, rather than QA time or developer time, is counter-productive. If it turns out that we can make all bug reports 10% better by adding another five compulsory questions to the Bugzilla Helper (for example) then that would be a good thing. Fewer bugs, better quality. (I'm not saying this is actually true - it's a hypothetical.)

These are only some initial thoughts for discussion. This issue really needs a champion - someone who can look at all the possibilities, do some research and come up with a well-justified plan. Such a person would, I'm sure, be showered with thanks and praises by the whole community. I'm afraid I don't have time. Do you?

"The Top Ten Usability Problems In Mozilla" - Revisited

Back in December 2001, kiwi UI designer "mpt" (Matthew Thomas) wrote a list of "the top ten usability problems in Mozilla" - i.e. the Mozilla Application Suite. It was endorsed by Dave Hyatt as summing up what's wrong "pretty nicely". He kept it updated until June 2002. The release of Firefox 3 seemed like a good moment to revisit his list to see which, if any, of the problems have been addressed in the past six years. mpt now lives in London and does UI work for Ubuntu, but was kind enough to provide up-to-date comments on the original and on my comments.

"The top ten usability problems in Mozilla" - revisited.

Twitter Problems

I may be the last to notice this, but: Twitter - the web command line?

However, I can't try these things out because I've forgotten my twitter password. I ask for a password reset email but one never arrives. I've been trying for the past six weeks, so it's not just Twitter flakiness. My help ticket has gone unanswered.

I know I definitely have an account and I know I'm using the right email address.

Anyone any ideas? What do I do?

Web 2.0 Expo Discount Code

At the London community Firefox launch party in June, I met a lady whose job is promoting O'Reilly's Web 2.0 Expos.

The Europe Expo 2008 is from the 21st to 23rd October in Berlin, and she's been kind enough to offer a 35% discount to Mozilla community members. It's still not cheap - even with the Early Bird price and the discount, a conference-only ticket is €490 or £390 - but if you want to go, the code is webeu08gr3.