Community Management by David Eaves

I’ve seen Dave Eaves give a couple of presentations on/around this topic, and always enjoy his insights. This specific presentation is one that I had not seen before, but heard about from coop. Finding the full slidedeck along with audio recording was really great – I can now get my deaves fix without having to wait until next time he and I are at the same event together.

His informal presentation style, and sense of humour, helps keep you engaged in an uncomfortable “warm fuzzy soft skills” topic that many people in software shy away from.

Some highlights that stuck with me (in no particular order):

1) For any discussion, there are four main categories of communication:
* inquire
* paraphrase
* acknowledge
* advocate
** (Hint: if both sides are doing 100% “advocacy”, its not going to end well.)
** (Related hint: in order to persuade, you need to be open to persuasion.)

2) Don’t tell people how to do something, do tell people why you want something. This leaves it open for everyone to brainstorm whats the best way to implement something – which might turn out to be better/easier/faster then your initial idea.

3) Beware of miscommunications and mistaken assumptions in irc/email/bugs.
* 7-9% are verbal – the dictionary definition of words that you use
* ~38% are paraverbal (tone, accent, volume)
* ~50% are body language

4) Is an open source company a “software company” or a “community management company” ?
* what is the core competency? Code? Code+human communication?
** I think this is what makes it so hard to get used to working in an open source environment. And hence, hard to grow an open source community.
* Ideas are fragile; egos are fragile; You need a safe place in the community where people can suggest new ideas without being immediately shot down and discouraged. Without new ideas, you are dead but just dont know it yet.

David’s presentation is focused on open source community, which makes sense given it was at FSOSS. However, it feels just as relevant to a large closed-source organization or any environment where people who dont know each other well (yet) are trying to figure out a shared solution to a shared problem.

If you work with others, or work by yourself before coordinating all the different pieces with others, then this presentation is for you. Trust me. Watch it. Maybe its something you already know, and practice daily. Or maybe, like me, you’ll find yourself taking notes and wishing you could do-over some conversations.

(Why, oh why, didn’t they teach this in CompSci when I was in university?)

Anniversary of San Francisco’s 1906 earthquake

105 years ago today, at 5:12 a.m. in the morning, San Francisco got hit by “the big one”. The devastation is well documented here. The earthquake was bad, but the fires afterwards did most of the damage – a bad combination of broken gas pipelines causing fires, and most fire hydrants not working because of the broken water pipelines.

Just around the corner from my home is one hydrant that DID work. Because of this hydrant, refugees in Dolores Park were safe, and houses beyond this point were protected from the inferno, so the neighborhoods have lots of houses from before 1906. More details here. Nicknamed “the golden hydrant”, it gets a new layer of gold paint, and some flowers, in a ceremony at 5.12am every year on this day.

Aurora – now with localization!

On Thursday night, we started generating localized nightlies on Aurora. The builds are posted here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/

As part of the whole new rapid release cadence, the Aurora builds are “string frozen”, so localizers can safely use these Aurora builds when localizing the Firefox5.0 release. If you see any problems, with any of these localized builds on Aurora, please let me know, or even better, please file a bug.

For the curious, here’s what the Aurora about box looks like for Spanish (specifically es-ES):

Doctors Without Borders in 2009, by the numbers

Doctors Without Borders / Médecins Sans Frontières just issued their annual report for 2009 (click here for PDF).

Some numbers that jumped out at me were:

  • 7,932,403 Meningitis Vaccinations
  • 1,419,427 Measles Vaccinations

For comparison, I note that the total population of Hong Kong is 7million, and San Francisco is 800,000. That is a *lot* of vaccinations – significantly more then all the war/earthquake/flood/disaster injuries they reported. Also in the list of medical procedures carried out in 2009 was “110,236 baby birth deliveries” – even in the midst of everything else, life goes on.

Mis-communication in a rally car

This in-car camera footage was taken during the rally in Tasmania a few days ago, and catches some mis-communication between the driver and the navigator. The car was doing 118mph (190km/hr) at the final corner.

How people behave, and treat others, when things go wrong is quite telling. In this case, you can hear the first “sorry” while the car is still airborne. Also, they keep working together, and checking on each other, all the way to the end. Nice to see.

Best quote: “You cleared (flew over) the first fence, second fence you went through sideways, and the third fence you went through sideways.”

PS: In case you wonder just how hard can it be to give pre-written directions in a car, here’s a snippet from last years Circuit of Ireland Rally where the driver/navigator team worked really really well together. Note:

  • the navigator reads out directions in a non-intuitive way. The driver is already
    committed to the approaching corner, and has already been told what to expect around the corner. The navigator is telling the driver what to expect after the next corner.

  • the large LED display near the steering wheel shows 1…6 depending on what gear the driver is in. Green is normal, but red means the driver is running engine dangerously fast and should change gear. All other information is distracting, so is removed! This makes it hard to tell speed but you can get an idea how fast they are going by noticing the number of times the driver redlines the car in 6th gear.

The Dawn of Aurora


Very early this morning, legneato merged over the code from mozilla-central to mozilla-aurora. This means FF5.0 is now on Aurora.

Anything that lands on mozilla-central after this point is destined for FF6.0.

We’re still working through lots of mechanical details (name changes on mozilla-central, l10n for aurora, channel changer impact, last minute updater bustage, figuring out tags, …), so please be patient. After all this is our first time doing this! However, with any luck, later today or maybe tomorrow, we should have stable FF5.0 builds on Aurora. (click here for details on the name “Aurora”)

Oh, and by the way, all this happened *without* closing the tree! 🙂

How to merge from mozilla-central to aurora

There have been several questions about the exact merge mechanics going from
mozilla-central –> aurora. While the specific problem is how to handle landing changes from mozilla-central into aurora, along with any possible changes already on aurora, I note that this can happen going from m-c –> aurora or from aurora –> beta or from beta –> releases. The general problem here is how to merge from an upstream repo that has changes into a downstream repo that has other possibly conflicting changes.

Many thanks to bz, catlee and ehsan for the great discussion over lunch last week. Let me know what you think, or if you see anything missing.

  1. Never delete the aurora repo, we need the history.
  2. Pull from m-c to a new head on aurora. Note exact changesets used, as this will be needed for next drop.
  3. Query hg.m.o for list of changes since known changeset / tag of the previous drop.
  4. Human needs to review list of changes since the last drop from m-c, and figure out which changes to bring forward, and which changes to throw away.
  5. Use “hg transplant” to take the changes we want to bring forward and bring over to the new head.
  6. Human needs to resolve any merge conflicts. Note: some specific files need careful human review of any changes, even if there are no merge conflicts. all.js, firefox.js, configure.in, mozconfig
  7. Safety check:
    • Diff new-head-on-aurora vs m-c == list of all previous aurora backouts (smaller list?)
    • Diff new-head-on-aurora vs old-head-on-aurora == list of new code changes in m-c (bigger list?)
  8. Mark the original head as closed, to prevent accidental landings on the wrong head.
  9. Human needs to “hg push” back to aurora
  10. All done.

Note: more details, alternate proposals, and some discussions can be found here in dev.planning newsgroup.