How to keep contributors when they are not even contributors yet

Today I wrote this post describing my difficulties in getting started with Ember.js, a quite well known open source project.

Normally, when I find small issues in an existing project, I try to help by sending a PR–some things are just faster to describe by coding them than by writing a bug report. But the case here was something that requires way more involvement than me filing a trivial bug. I tried to offer constructive feedback, and do that in as much detail as possible so that the authors could understand what happens in somebody else’s mind when they approach their project. From a usability and information design perspective, this is great information to have!

Shortly after, Tom Dale contacted me and thanked me for the feedback, and said they were working on improving all these aspects. That was great.

What is not great is when other people insta-ask you to send PRs or file bugs:

Look, I already gave you A FULL LIST OF BUGS in excruciating detail. At this stage my involvement with the project is timid and almost insignificant, but I cared enough to give you good actionable feedback instead of just declaring that your project sucks in a ranty tweet.

The way you handle these initial interactions is crucial as to whether someone decides to stay and get more engaged in your community, or run away from you as fast as they can.

A response like Tom’s is good. He recognises I have more things to do, but offers to listen to me if I have feedback after they fix these issues. I can’t be sure I will work more with Ember in the future, but now I might check it out from time to time. The potential is still there! Everyone’s happy.

An entitled response that doesn’t acknowledge the time I’ve already invested and demands even more time from me is definitely bad. Don’t do this. Ever. What you should do instead is act on my feedback. Go through it and file bugs for the issues I mentioned. Give me the bug numbers and I might even subscribe to them to stay in the loop. I might even offer more feedback! You might even need more input! Everyone wins!

This is the same approach I use when someone who might not necessarily be acquainted with Bugzilla or Firefox tells me they have an issue with Firefox. I don’t just straight tell them to “FILE A BUG… OR ELSE” (unless they’re my friends in which case, yes, go file a bug!).

What I do is try to lead by example: I gather as much information from them as I can, then file the bug, and send them the bug URL. Sometimes this also involves building a test case, or extracting a reduced test case from their own failing code. This is work, but it is work that pays off.

These reporters have gone off to build more tests and even file bugs by themselves later on, not only because they saw which steps to follow, but also because they felt respected and valued from the beginning.

So next time someone gives you feedback… think twice before answering with a “PATCHES WELCOME” sort of answer—you might be scaring contributors away! 🙂

E-mail management tricks that will change your life FOREVER

One of the first things that someone told me shortly after I joined Mozilla was:

I wonder how long until you stop reading all the emails we get.

I was like: oh come on, how could you not read your emails?

But then I started to subscribe to bugs, mailing lists and get involved in STUFF, and guess what happened? Lots of emails, and lots of stress because it never ends! And it’s so hard to separate the important stuff, right?

Well, I’m here to share with you my exquisite set of rules for managing email that will totally change your life.

First things first: make folders for mailing lists, and set rules to direct those messages to those folders. You don’t want these things in your inbox.

For example, I have a folder for all bugzilla-related notifications, then various folders for various mailing lists I follow.

A tip on bugzilla: if you use it, you might want to modify a couple of settings so you get less emails:

Bugzilla email settings

Basically I just want to know when I’m assigned or CC’ed to a bug, when it is closed/resolved or when comments or attachments are added. I don’t want to know when someone CC’s themselves, for example.

Create a folder called “LO-PRI” or similar, and set up rules to move there things that you hardly look at, but might want to look at if you finished all your work and were really bored. For example, build notification emails, or very high noise to ratio mailing lists that don’t deserve their own folder. Usually I just look at the subjects for these and quickly delete all.

Now comes the best trick–and this is what changes lives forever:

  1. create a new folder where things that might not be directly relevant to you go. Mine is called “potentially irrelevant”. I know, that name is amusing. Brings me to giggles every time I see it.
  2. set up a new rule where anything that doesn’t have your email in the To: field goes to this sort of catch-up folder

In my case the rule is “anything that doesn’t contain my email address, or my alias, or my team email address”, so change accordingly.

Once you’ve built all this complex system of filters and rules you should end up with a way leaner inbox, and can actually use it to keep track of things that need to be done, instead of spending half of your day managing your inbox.

And if this filtering isn’t aggressive enough for you, there’s always…


Delete. Delete. Delete.

Firefox OS Simulator is now a component in Bugzilla

So you can now file bugs under Product = Firefox OS, Component = Simulator.

Or look for existing bugs!

PS. Aren’t you AMAZE at my mad bugzilla skillzzz? I created direct links for you to file or search Firefox OS Simulator bugs. Ahhh, the power of query strings in URLs…!