Synthetic economy to tackle email overload

Standard

Today is First Monday (somehow), and so I got a pointer in the mail about the last issue of the online magazine by the same name. There’s an interesting story in there about email overload. The abstract is:

The productivity of information workers is jeopardized by too much e–mail. A proposed solution to e–mail overload is the creation of an economy that uses a scarce synthetic currency that senders can use to signal the importance of information and receivers can use to prioritize messages. A test of the virtual economy with corporate information workers showed that people in a large company used different amounts of the currency when sending e–mail messages, and that the amount of currency attached to messages produced statistically significant differences in how quickly receivers opened the messages. An analysis of the network of virtual currency trades between workers showed the different roles that participants played in the communication network, and showed that relationships defined by currency exchanges uncovered social networks that are not apparent in analyses that only examine the frequency, as opposed to the value of interactions.

In other words: what if people could “pay” to mark their email as important, using a scarce resource? This experiment is just an experiment, but it’s certainly a problem worth attacking.

Mice everywhere

Standard

Clay Shirky has another great essay out, which I recommend you go read now.

Just like Robert Sayre, I find it resonating with me, in a few ways. First, I certainly see the societal possibilities of amplifying what feels like an already existing trend. Second, the writers’ strike was for me a great personal kick in the pants that I needed to watch less TV. It’s as if the drug dealer is out of dope, and so you find that you can just do other things with your time, and you find you don’t miss the thing! Third, while my thinking on Thunderbird 3 has long been about how to make it fit within a web-enabled world, Clay’s piece explains both the higher level why: “enabling an architecture of participation”, and a metaphorical how: “mice” everywhere (if you didn’t read the essay, that won’t make sense), so that Thunderbird developers, add-on developers, communication channel providers, and most broadly Thunderbird users can find mice that fit their hands.

Notes from Germany

Standard

I spent much of last week traveling to Germany — Berlin and Hamburg. Time for an update.

I started off with a day-trip to Berlin, which could have been exciting given my complete lack of German, but I spent it instead with Axel Hecht, localization coordinator for Mozilla, which meant that the chances of my getting lost were pretty slim. What I learned:

  • Berlin is a city under massive change. It’s history is mostly erased, with lots of new buildings blurring the once stark divisions between east and west. You have to know that the line of bricks on the ground marks the old wall. Unfortunately, it was drizzly and cold for most of the day, which didn’t let the architecture shine. Still, I got a feel for the city, and I’ll definitely go back and spend more time there.
  • Axel and I talked a lot about localization, a topic that I have deliberately not dived into yet because it seems in relatively good shape. Figuring out how to coordinate the work of 50 teams of volunteers across the world is something that I know we’ll have to taken on soon, but not this week. It’s nice to be able to learn from Axel and get his perspective on what works/doesn’t work.
  • I found a lot of echoes of my childhood, and brought some of them back: marzipan, Struwwelpeter. I also brought back weird chocolates (pomegranate and chili chocolate anyone?). Who knew germans were so culinarily experimental?
  • Hamburg is a very pleasant city, especially if the weather cooperates. Unfortunately I had camera troubles so didn’t take as many shots as I should have. But I liked the blend of canals, modern architecture and older buildings, and a general feeling of highly functional buildings. Recommended.
  • Strangely enough, while we certainly had our share of good beer, we had only one schnitzel and no sausages. Don’t know why, that’s something to be corrected in the future.
  • Work meetings went well. It was I think very helpful to have Dan, Bryan, Mark and I in the same room as many of the Calendar contributors, including Daniel Boelzle, Simon Paquet, Philipp Kewisch, Christian Jansen, and more. See Bryan’s photo to match names and faces. I also have some untagged pictures for less formal shots. I’ll write more about the calendar project in another post.
  • I’ve discovered a special area of Schipol airport with really nice relaxing chairs, a good place to spend 4h layovers

For the record, a few great places to eat:
In Berlin:

In Hamburg:

Hamburg: Thunderbird, Calendar, Accessibility, CouchDB?

Standard

In day 3 of a Calendar meeting face-to-face, we had a few deviations from the core of the main topics (Lightning, Sunbird, Thunderbird integration), with two cool side-trips.

First, Marco Zehe came to talk about the state of accessibility in Thunderbird and Calendar. The take-away message to me was that accessibility for “trunk” (Thunderbird 3, etc.) is pretty good, thanks to all the work done at the platform level. There are some outstanding issues, which we agreed to consider as blocking Thunderbird 3, but it’s one of those areas where the next version of Thunderbird will be significantly better than the current one for a subset of users.

Second, at my instigation, Jan Lenhardt gave a talk about CouchDB, which was nicely off topic but thought-provoking. The coolest bit is that about an hour after the end of Jan’s talk, Philipp Kewisch, Calendar hacker extraordinaire, and author of the GData add-on for Calendar, had whipped up a proof-of-concept CouchDB provider for Lightning, meaning that calendar data (events, etc.) can be stored in a couchdb repository.

Kudos to the CouchDB and Calendar teams for building systems that clearly are easy to extend, and to HTTP/REST and JSON for providing great building blocks.

Berlin/Hamburg

Standard

Forgot to mention that I’ll be in Berlin Friday, and Hamburg Saturday-Tuesday, for the Calendar project face-to-face, along with Dan Mosedale, Bryan Clark, Mark Banner, and a bunch of the Calendar contributors. It should be a great meeting where we iron out a lot of the roadmap for Lightning/Thunderbird collaboration and integration.

Would Planet Thunderbird be useful?

Standard

Would readers of this blog be interested in a Planet Thunderbird aggregator that included all posts explicitly about Thunderbird, not just mine or those of Thunderbird engineers, but whatever other regular bloggers on the topic made sense? Or are all those readers already reading Planet Mozilla and happy to deal with that firehose?

Leak control!

Standard

Thunderbird work is all about leaks these days, of various kinds:

  • A study at CMU to test an extension that suggests people you might have forgotten to include in an email, and whether you might be leaking something to people you didn’t intend to include (via Shawn Wilsher),
  • A related post I’ve been meaning to refer to for a while from David Teller about adding MLS (multi-level security) to Thunderbird.
  • Only linguistically related work from Mark Banner on adding metrics to detect memory leaks in the Mail/News code that Thunderbird relies on.

Accepting Nominations for Thunderbird 3.0a1/3.0 blockers

Standard

Mozilla project planning, for those not in the know, happens primarily through bugzilla entries, which include bugs, feature requests, work items, everything. It may not be the best way to organize things that aren’t really software defects, but it’s what we have, and somehow it works out ok.

As a case in point, the way releases get planned (what should be in which release) is through flags — bugs can be nominated for a release (by anyone), and then a group of people with a good overall perspective on the release (called “release drivers”) either accept a nomination or reject it — or redirect it to another release. Furthermore there are bugs that are considered blocking, while others are considered wanted. The former are the bugs that we’d delay a release in order to get them fixed, while the latter are nice-to-haves, but they wouldn’t block a release.

It’s a remarkably distributed process, with discussions about which bugs should be addressed and why distributed across the bugs. We then use bugzilla queries to get a holistic picture of the release, which gets particularly important close to the end-game. Over time, I think we can build better mechanisms, but the bird in the hand…

Importantly, release planning starts with people nominating bugs for either ‘wanted’ or ‘blocking’ status. We currently have flags in place for two releases: Thunderbird 3.0a1, and Thunderbird 3. The former is imminent, the latter not so much.

For 3.0a1, our release goal is first and foremost to actually do a release, which will exercise a bunch of muscles and mechanisms which have not been exercised in a while. Nominations for 3.0a1 should focus on bugs which significantly impact the ability of alpha users to give feedback on the product. Common crashers, bugs causing data loss, and significant usability problems are the most obvious candidates. We’re not being feature-driven for this early alpha, so don’t bother nominating new features for this release.

For 3.0, we’re definitely willing to consider all kinds of bugs. These will help us scope the extent of work needed, but also help us get a broader, “crowd-sourced” picture of the state of the product — what, among the thousands of contributed ideas and bug reports, impacts the most people. The easiest way to express “support” for a bug is simply to vote on it. Don’t add comments to the bug if you’re not contributing new information beyond your support — that makes the bugs harder to read, hence harder to fix. Instead, vote on your favorites. (I know voting on bugs is far from ideal — but it’s better than any other current alternative)

To nominate a bug, you need to be logged in to bugzilla, and you should set the appropriate flag (under the CC area) to ?. Only drivers are allowed to set + or – flags, so please don’t.

For more information, see the wiki.

MozCamp in Vancouver

Standard

Next Sunday, just before the Open Web conference, we’re organizing a get-together of people who hack on Mozilla-related code. Details from Shane Caraveo:

MozCamp Vancouver, Sunday April 13, 12pm to 5pm

Location:
ActiveState
1700-409 Granville Street
Vancouver

I am glad to announce Mozcamp, an informal gathering of developers who
work on XUL applications and extensions. We’ll start the day with a brief intro from each attendee, covering what they work on and what they are interested in discussing. We can then self organize for the rest of the afternoon. Any topic is accepted, from development issues to strategy and beyond.

Vancouver and Victoria have a number of organizations that currently
develop mozilla-based applications, such as Mozilla Messaging
(Thunderbird), Flock, Songbird, Brand Thunder and ActiveState (Komodo
IDE). Representatives from these organizations will be attending, and
as well this event is also open to anyone who works on mozilla-based
applications, extensions, or related technologies. ActiveState is
providing the space, Mozilla is providing the pizza. Space is limited,
so please RSVP to Shane Caraveo (shanec at ActiveState-dotcom)
as soon as possible.

Should be good!

Think Schools, Think Email?

Standard

I spent yesterday at Think Schools, an all-day gathering of people looking for constructive ways to solve a crisis facing the local school district: given that we need to seismically retrofit the existing school stock, can we do so intelligently, not destroying the vibrant community hubs that many of these old schools have become, but instead build upon them?

I was struck by the similarities and differences faced by this group and by the people I work with whether when discussing email or Mozilla.

The differences are easiest to describe: The people involved in Vancouver schools are naturally roughly co-located (although some of the issues go beyond the city boundaries, it’s still a local issue), while the people involved in the future of the internet are stunningly distributed.

On the flip side, at least the people involved in Mozilla, are self-selected and hence roughly aligned on broad themes, such as the Mozilla Manifesto. We’ll argue vociferously on some issues, no doubt — but there is still a stated common goal, and a lot of shared culture. In contrast, the people involved in the future of schools span an wide gamut, including community activists and parents, teachers, principals, custodians, school board staff and elected trustees, provincial ministerial staff and elected representatives, engineering firms, architects, geoscientists, and more. Needless to say, initial thoughts about “ideal outcomes” across these groups are often not even close to aligned.

The differences in vocabulary, perspectives, timelines, budgetary and organizational scales that these groups have to span, and the emotional issues that lie very close to the surface (such as child safety, trust, reputation, integrity), make diplomacy a real requirement for forward motion. Overlaid on this, the governmental regulation and budgetary scale for capital improvements bring in old-fashioned political skills. (On that note, it was nice to see some city councillors in the room like Peter Ladner and Raymond Louie, clearly learning about the issues affecting their city, even though the city has little influence on school construction issues. It was disheartening not to see anyone from the Ministry of Education, who has the most authority over the issue.)

Still, there are strong similarities between the “school renewal” and “email renewal” exercises. The leaders in both cases are deliberately working on a collaborative community building effort, out of necessity as much as ideology. In both cases, there is a constant healthy tension between trying to be thoughtful and inclusive, and needing to make real progress quickly. Also, I am routinely struck by the realization that behind the differences in names, personality types, job titles, backgrounds, or level of commitment, there are such things as Good Ideas, and once they are explained carefully and understood, these ephemeral things can bring very disparate groups in alignment.

In the case of the Think Schools event, it was hard to find people who didn’t appreciate the elegance of an old idea: that our schools shouldn’t be thought of (and budgeted for) as single purpose “teaching boxes”, but instead as multi-purpose community hubs, leveraging precious real estate to provide a variety of civic services (libraries, gyms, meeting spaces, cafeterias, playing fields), with an appropriate funding model. We had a presentation from someone involved in that setup in Seattle, which was inspirational.

The possible synergies from such a model are appealing no matter which perspective you take:

  • From an educational point of view, it creates an educational environment that is part of a broader civic landscape, integrating childhood and education into the broader community, and by bringing in more users into a facility, can provide funding for essential non-funded spaces, such as libraries, music & arts spaces, daycare, and more.
  • From an environmental and energy point of view, you can build and maintain buildings that are used by different populations at different times.
  • From a civic policy point of view, you build neighborhood anchors in a city with few alternative assets to host them.
  • From a public health point of view, you encourage walkable neighborhoods and community sports & health facilities, neighborhood libraries and community centers.
  • From a maintenance and policing point of view, you have buildings and grounds that are in use almost all the time, reducing vandalism and the like.

The largest obstacle before this vision is the as-yet invisible path to that outcome past jurisdictional and budgetary silos, and, so far, a lack of political will. Everyone is aware that it is a huge obstacle. Still, getting 130 motivated people in a room for a day was a great start.

When it comes to the future of email, I don’t feel like we as an industry have yet figured out what the desired outcome is — we’re still at an early stage of visioning, with a rich cacophony of ideas, each one striking an interesting note, but without harmony yet. To stretch the musical metaphor, I’m hoping that what we in Mozilla can do is to provide both a “standard” (in the Jazz standards sense), and a couple of places to jam, and see what happens. Yesterday got me wondering whether having a face-to-face meeting on “envisioning the future of email” would be a good idea, even though the logistical challenges of doing so with a global community are enormous. Something to ponder.