Reports of crash bugs require a variety of skills to turn into useful bugs: knowing common support issues, tactfully interacting with bug reporters, reducing testcases, finding regression ranges, and knowing how to get each bug to the correct developer(s). I don't expect every triager to be a guru at all of these, so my guide incorporates a workflow that should allow triagers with differing skills to work together efficiently.

I'm going to work with the QA team to organize some "crash bug days" on IRC, but I'm interested in feedback before that as well.

• Dailymotion to add Ogg support,
• The Pirate Bay to create a new site, The Video Bay, which features Ogg-only video, and
• Wikimedia to accelerate the addition of videos to Wikipedia articles. (Articles that already have videos include Geyser and Flywheel.)

And Firefox 3.5 hasn't even been released yet. This Open Video thing might just work.

The scariest part is that we don't know whether the large number of crashes is due to a single bug or multiple bugs. (All crashes in JIT code appear with the same signature because the crash reporter does not understand the structure of the generated code.) We might not even know until we fix one bug and ship a new release candidate to a large number of users.

We have a list of 3000 URLs associated with js_MonitorLoopEdge crash reports. Bob Clary is going to try loading all 3000 pages. Damon Sicore has already identified one page that crashes reliably. While Andreas Gal debugs it, I'm going to try to make a reduced testcase.

These efforts should fix any crashes triggered by simply loading popular web pages, but might not catch other bugs that involve extensions or when interacting with web pages in a specific way.

If you've been hitting crashes in js_MonitorLoopEdge, please try to figure out how to reproduce them and share what information you can. Click the links in about:crashes to find out if your crashes are in this function. The sooner we figure this out, the sooner we can ship a stable Firefox 3.5.

Virginia's courts found that since the Racial Integrity Act punished the two Lovings equally, it did not discriminate against any race. They also came up with justifications for the law, some of which seem bizarre by today's standards:

Almighty God created the races white, black, yellow, malay and red, and he placed them on separate continents. And but for the interference with his arrangement there would be no cause for such marriages. The fact that he separated the races shows that he did not intend for the races to mix.

The Supreme Court of the United States, in contrast, could find no rational basis for the law. Instead, they described it as "designed to maintain White Supremacy", as it only divided whites from non-whites rather than trying to protect the "integrity" of every race.

That alone might have been enough to overturn Virginia's law, but the supremes went further. They held that "equal application does not immunize the statute" from the strict scrutiny applied to laws involving race. It would take much more than a supposed rational basis to justify a state law against interracial marriage.

The Supreme Court's unanimous decision concluded beautifully:

Marriage is one of the "basic civil rights of man," fundamental to our very existence and survival.... To deny this fundamental freedom on so unsupportable a basis as the racial classifications embodied in these statutes, classifications so directly subversive of the principle of equality at the heart of the Fourteenth Amendment, is surely to deprive all the State's citizens of liberty without due process of law.

Loving v. Virginia brought the end of anti-miscegenation laws, not only in Virginia, but throughout the Southern United States.

I am struck by how recently this decision came: June 12, 1967 was only 42 years ago. That I grew up considering multiracial couples normal is a testament to the success of the previous generation's civil rights movement.

In the spirit of the court's decision, I would like to wish all couples a happy Loving Day.

I'll save the jealousy for February.

Quests

World of Warcraft organizes your quests according to where you discovered them, not according to where you can make progress on them. You can easily have your character in the right town but forget to advance one of your quests.

Since the game's quest organization is so unwieldy, it limits players to 25 quests. This forces some players to abandon quests with the intent of picking them up again later. But more importantly, "only write down the most important stuff" is the wrong message to send to our children.

Having to maintain your own lists outside of the game makes playing the game too much like work. If instead, the game subtly taught players how to work effectively, they might have more time to play.

Mail

Thunderbird's default set of color labels reflects priorities and reasons (important, work, personal, to do, later). These labels don't really help move messages out of the inbox.

Instead, Thunderbird should suggest contexts and non-action sets (home, office, errands, waiting for reply, reference).

Bookmarks

Firefox has the distinction of containing three dangerous stuff magnets: the bookmarks menu, the bookmarks toolbar, and session restore. I've seen several coworkers fall into the session restore trap, and it's not pretty: with hundreds of tabs, Firefox can take minutes to start.

I like Jono's suggestion of replacing bookmarks with features that speak more directly to use cases like to-read, sharing, and reference. Firefox 3's tags make reference possible but not much else.

To-read is the trickiest, since it can't really be organized. Separating to-read from sharing and reference is enough to keep those other categories clean, but to-read has to work if it's going to be used. Maybe Firefox can include hints about how to use to-read effectively, like having an "airplane" button you click to open all of them in tabs just before you disconnect from the tubes. Or maybe Firefox can keep those items ready for reading without the overhead of having them open in tabs all the time.

Everywhere

What other software could encourage people to discover contexts and the next-action principle? Where else can workflows be improved, so collection buckets are emptied naturally, and users don't need to make a special effort to "stay organized"?

What use cases are important and not covered well by the (new) graph server, johnath's performance dashboard, and the automated posts to mozilla.dev.tree-management? What would help us notice and track down performance regressions quickly?