Today, Mark Surman begins as the new Executive Director of the Mozilla Foundation. David, Zak and I would like warmly to welcome him, but we also want to take a moment to recognize Frank Hecker's excellent work as our ED from 2006 until today.
While Frank is staying with the Foundation, this is still a significant change for him and a good chance for us to show that we still like him even when he isn't signing our paycheques :-)
Over that last few years, we've seen Frank's character in many different situations, including some that have been rather trying. In each case we've appreciated, benefitted from and sometimes marvelled at Frank's diligence, wisdom, kindness, generosity and good nature.
Frank tends to contribute very quietly. Much of the good work that he does goes unsung, but he has had a hand in many of the positive things that have happened in the community since the Mozilla project began ten years ago. He's been a particularly strong champion of accessibility for Firefox and for the web, and the community's work in this area has led to Mozilla products becoming highly respected by, for example, the visually impaired.
Frank's blog regularly demonstrates that has a strong understanding of where Mozilla has been over the years and also many insights into where the community should be going in the future, so all three of us feel fortunate that we will continue to be able to work with Frank as he moves to a new role.
3 weeks on, IE 8 Beta 2 is now available in an additional 21 languages, bringing the total to 25. As a comparison, as far as I can tell that's only one fewer than IE 5.5 and 6 were released in, ever. Another sample Microsoft beta, that for Windows Server 2008, is only available in 15.
As one of the l10n team said the other day, it seems that this is another example of us driving innovation even for people who don't use our product :-) I wonder if they would be doing the beta in that many languages if we hadn't raised the bar by regularly simul-shipping in 40-something?
All the usual suspects are there, although they seem to be doing a version of Chinese specifically for Hong Kong, which we currently don't do. Can anyone comment on what might be different about Hong Kong which requires a separate build?
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.
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.
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:
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.
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.
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.
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 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.
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:
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:
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?