Building Mozilla’s Core Strength

I was lucky enough to be invited to “Mozlando” and was really pleased with the 3 pillars Chris Beard revealed for Mozilla in 2016. Especially the concept of building core strength. As a ballet dancer I’ve actually used this analogy myself when making suggestions for projects I’ve been involved in. Of course the issue always is turning concepts into practice, getting people to actually apply them practically when they go back to work.

Community should be one of Mozilla’s core strengths. It’s been taken for granted, not very well understood, and no one seems to really be sure how to measure its strength let alone build it. There are some really great people trying to approach the problem from different angles, but I think we’re overlooking the basics and not applying knowledge and process that we already have.

Minimum Viable Product

I assume most of you reading this are familiar enough with Agile best practices to recognize this term. George Roter brought it with him to the Participation Team (or at least used the term more often than his predecessors). We need to identify the MVP for community strength at Mozilla. What is the least thing that needs to happen to be able to say we have a healthy community? We need to identify it, and then realign everything necessary until we’re capable of shipping it.

Mobilize the Base

I think anyone that works with a movement understands that if you can’t mobilize your base, then you’re lost. It’s the definition of a movement. Mozilla has hundreds and thousands of volunteers, and volunteers-in-waiting. It’s a massive untapped resource that should be the single litmus test of Mozilla’s success:

Can Mozilla mobilize its base?

The answer is pretty clear, whether or not it can, it doesn’t. I think this should be the single most important goal for 2016, and it supports all the initiatives already identified. Technical teams are focusing on making what’s already in the browser better. That’s great, because you need to give your base a product it can believe in if you want them to be moved to action.  Done on its own, it’s much harder to come up with a direction, or a definition of success. But if you’re trying to get your base excited about your product again, all of a sudden you have something you can measure, and someone to whom you can listen to guide your progress.

Obviously where this weakness exposes itself the most is in non-technical teams and especially in marketing. In this age of viral advertising and the sharing economy, Mozilla came with a built in network of savvy internet citizens. Getting our message out there should be our core strength. We should have a network of professionals who know how to leverage that network. We should be intentionally investing in attracting and retaining those members of the community that can be mobilized, and cutting out practices that don’t further this goal. No other problem should be prioritized above this.

This must be our core strength, our minimum viable product. We make products but ultimately we’re an organization built on a mission, on values, on a movement. We must be able to mobilize our base before we can accomplish anything else worth accomplishing.

No one should be able to beat us at this.
This isn’t a nice-to-have.

This is how we survive.


Moving lines

One of the parts that is hard about this situation for Mozilla is that we don’t know where to draw the line now. People are worried that this is now a slippery slope, or that anyone could be pushed out because of outside views. I think as a community we need to accept the truth that Brendan wasn’t a viable CEO and figure out where this leaves the lines.

I think there is an obvious set of boundaries in this case that hopefully we can restrict this kind of scrutiny to stay within. The CEO is an outward facing position. When asked about the responsibilities of CEO vs CTO, Brendan answered that the CEO does a lot of working with partners and hiring. So the CEO interacts with people currently outside the Mozilla community. People who haven’t had the chance to build trust in us, in our CEO, in our way of doing things. I think if a director of HR had made a similar donation, it would also make it hard for people who must interact with that person to feel safe and trust them, even if they leave their personal beliefs at the door.

I am worried that next we’ll be expected to thoroughly vet candidates on their political views and actions. I think the problem in this case was that we already knew about Brendan’s donation, and still asked everyone to trust him anyway. But if we don’t thoroughly vet someone, and something comes to light, will we be expected to ask them to step down as well? I have a feeling the answer is yes.

I think for me the biggest lesson here is that the world doesn’t know us, and therefore they don’t trust us. I think this is partly our fault, we have focused on trying to win with users, and not on values. If the world knew us for our values, and not for our features, maybe we’d have had more people defending us, trusting us that we wouldn’t hire a CEO that would harm our contributors. They may still have called for Brendan to step down, but they would have been much more thoughtful about separating Brendan the individual from Mozilla the organization.

Is that wishful thinking? Sure, but we’re Mozilla. We’re good at wishing things, and we’re pretty damn awesome at making sure they come true.

How Reps Cut Their Meeting Times in Half…

…And you can, too!

We did it with one simple rule:

Only items that have already been raised on the mailing list are allowed on the agenda.

Using this rule, Reps Council cut their average meeting time from 2 hours (yes! you read that right!) to the target 1 hour. It’s really that simple.  Here’s why it works:

The Problems

Topic 101

We realized that most of the meeting was taken up with the “stupid” questions that inevitably come up with a new topic, asking for clarification on what was meant, asking for background on the topic. Getting everybody on the same page on a new topic can take 15 – 30 minutes depending on how complicated or contentious the subject is.

Language Barrier

By the way, this is why Reps meet on IRC. I like to say that “you guys don’t type with an accent!” when I mention my preference to IRC meetings over voice calls. Depending on the English skills of the people attending, they may need more time to understand what was said, or have it explained a different way.  At least on IRC non-native speakers can form their thoughts while others are typing.

Using speech, the accent issue can cause delays both ways. Not all English speakers’ accents are created equal. When the Reps mentors met in Berlin, it was often requested that I speak because my Canadian accent was easily understood, while some people whose written English was very good, couldn’t be understood by many when speaking.

The language barrier does cause delays even on IRC. It can add 15 minutes or more while people try to understand what was said, then formulate their response, and have to speak slowly. More worrying is the time that isn’t taken up by those that don’t understand the topic well enough to discuss it in the moment.

Forming an Opinion

Before you make a decision on a topic, you need to know how you feel about it. In well functioning teams this also means taking time to consider how the rest of the team feels, and why. An opinion can’t be formed in a moment. It takes consideration, some mulling, maybe even research. We could easily take a whole hour discussing one new topic, but here is another 15 minutes at least of discussion.

The 80% Rule

In Athens, Gunner introduced a very good rule for group discussion. He said (paraphrasing), “For a feature to be included in Firefox, it has to be relevant to 80% of the users. Only ask questions that you think apply to 80% of the group.” If a meeting is the primary discussion mechanism for a group, or team, it becomes the place where people ask questions that only apply to a small portion of the team, or even just themselves. Everyone else has to wait for these discussions before moving on to the next 80% topic. Even the time it takes for someone to ask the question and be told to ask it privately later can add up. It can sometimes take 5 minutes or more for the person to explain their question and for the other participants to understand that it’s not really applicable to the group.

The Solution

Using a mailing list, newsgroup, forum or other asynchronous discussion tool prevents many of these topics from running down the clock in your meeting.

Going Async

This is a time trade-off. Obviously the 101 discussions and opinion arguments need to happen. Having them asynchronously allows people to choose the time that best suits them for contributing to the discussion. It allows people to participate that can’t make the meeting time. People can skim over the topics they’re not interested in, or don’t have anything to add to. In a synchronous meeting, they must sit and wait while these discussions happen, unable to completely context shift away from the meeting as they need to follow along to know when the discussion reaches a topic of interest.

Background and 101

You can give a much more complete background of a topic asynchronously. Asking people to read a blog post or proposal before a meeting means people can come to the discussion well informed, which a chance to point out missing pieces of the background. Again people can choose when to do this on their own time and will be able to give it more time and consideration than if you give them 5 minutes in a meeting to get familiar. People who are familiar with the topic can skim the discussion without having to wait through that portion of the meeting.

Forming an Informed Opinion

How many of us have epiphanies on subjects while in the shower, or taking a walk? We all need time to consider someone else’s point of view. I think we all tend to be more aggressive about our own opinions when discussing them real-time. Our brains don’t have time to explain ourselves while trying to understand someone else in the moment. When we have time to think about what we’re saying, and what others are saying we have time to form better responses, better consider what the other is saying, and even time to walk away, calm down, and come back with a fresh perspective.

Discussing opinions on a topic before a meeting also allows those in the meeting to recap and consider the opinions of those who can’t make the meeting. Someone else can raise a good point that was made in the async discussion, even if it wasn’t their own.

Making Decisions and Moving Forward

When topics are presented and discussed on the mailing list (or your tool of choice) it leaves you prepared to recap and make a decision in the meeting, identify the next steps, assign action items and move on. All of a sudden a topic that used to take up 15 – 30 minutes of your meeting can be reviewed and acted upon in under 5. People can call out where they need still need help or have completed past action items, and use “discuss on list” as an action item liberally!

The n00b’s Guide to Running an IRC Channel

This is a repost of the etherpad guide I created and shared a while back. Contributing to Mozilla sometimes means you need to run an IRC channel before you’re really familiar with IRC. This is everything you need to know to be a channel owner on Mozilla’s IRC network.

First of all, IRC is old school hardcore internet stuff, but it’s really useful.  Because it’s old school, you can think of it kind of like a terminal program (which it probably is).  So that means that you get one text field to type your chat and your  commands. Many IRC programs today have a lot of  buttons and graphics and things so you don’t have to type all the  commands, depending on how involved you end up getting.


  • Commands always start with / as the first character you type.  That’s how the service knows it’s a command.
  • Just like chat, you hit enter when you’re ready to send your command.
  • If you put a space first, it will send it as chat, not as a command.

To demonstrate typing into the  text input area I will use [         ] so pretend that’s the box, these aren’t characters to type.


[/join #remo       ] <– this will send the command

[ /join #remo       ] <– this will show these words in the channel

Tip: “channel” is the IRC term instead of “chat room” and almost always begins with a # symbol.


Basic Commands


  • This command allow you connect an irc server
  • Example: [/server]


  • This command allow you join a channel manually. When you choose your IRC client you can tell it what channels you want it to join automatically when it starts.
  • Example: [/join #remo], [/join #firefox]


  • This command allow you quit a channel manually.
  • Example: [/part] (inside a channel), [/part #remo]


  • This command allow you change your nickname
  • Example [/nick your_new_nick_here]



  • Ops means operator status.  That means you get some control over the channel and its members, eg if a spambot has joined the channel you can kick it out. not covered in this guide
  • Users with ops show up in the channel list differently, so
  • We use ops on Mozilla’s IRC server to show users and new people to the channel who’s on the team, and who they can ask for help.

Mozilla’s IRC has some built in services that help us manage our channels, especially NickServ and ChanServ.



  • ChanServ lets you register your channel so it will remember who the owner is and automatically perform commands for you
  • ChanServ can remember who is supposed to have ops, but only if you have registered your nickname with NickServ – otherwise someone could pretend to be you and use your name to take over the channel.

Back in the day you had to do all of this yourself, which meant if everyone left the channel, say to go to bed,  the channel would no longer exist and someone else could take it over.



To register your nickname, or “nick” with NickServ you simply send it a private message with the right commands and information.

  • First of all, make sure you’re using the nick you want to register.
  • If you need to change your name the command is /nick eg [/nick Lucy   ]

Tip: Don’t worry about this too much though, if you decide you need to use a  different nick later (maybe yours is too long or you want to switch to  your real name) you can “group” multiple nicknames. Grouping nicks is explained in the next guide.

  • When you’re ready to register your nick use the command to ask NickServ for help: [/msg nickserv help register   ]
  • NickServ will message you back the info you need to provide.

Tip: /msg is the command to send chat privately to one person.  In my IRC client it shows nickserv’s  messages in the same channel that I sent the command from (but only to me) depending on your client, it might put them all in their own channel/window and you might have to switch over to continue.


Identify With NickServ aka Getting Your Ops

  • Once you’ve registered your nickname you will want to find the setting in your IRC client that will automatically identify you with nickserv when you join IRC.
  • If not you will have to type the command /msg nickserv identify <your password>.
  • If your client identifies with NickServ before it joins any channels, once you join those channels you’ll automatically be given your ops (if you have them for that channel).
  • If  you identify with nickserv after you join your channels you will then need to ask ChanServ for your ops with this command: /msg chanserv op

It’s a bit complicated at first if you’re not used to using terminals (I’m not! IRC is the only one I use regularly) but as you can see it really follows a pattern and all the commands make sense in English.


Choosing an IRC Client

  • In terms of what program to use – I use IRC  enough that I use its own program. I like this because it has its own  alerts and it’s easy to switch back and forth.
  • For those of you that are  only using IRC for meetings, or just a couple channels, you can try something more basic first.
  • I suggest starting with Chatzilla  (this is the link for the Firefox extension, but you can get it in  Thunderbird if you prefer). It’s very easy to use, it’s very customizable and it’s easy to get support if you have trouble getting  started.
  • If you’re already using something like Pidgin that has built in IRC support, you can give that a try.

Tip: If you find IRC is too hard, I really really strongly suggest getting a dedicated IRC client before giving up. A good UI should solve most of the problems.


Recommended IRC Clients to Try First

  • Firefox/Thunderbird extension: Chatzilla (see above for download link)
  • Linux: Xchat, Empathy, Pidgin, Xchat Gnome, Irssi
  • iOS: Colloquy
  • Android: AndChat

Good luck! and once you’re comfortable let me know, I’m happy to recommend  more channels you might be interested in hanging out in. And of course  if you have any other questions, I’m happy to help, as are many IRC regulars!

Bugzilla Update, too

Thanks to the guys in #bugzilla for catching some bad instructions left in the dreamhost wiki. Not only did they help me fix the issue  – just had to run the Bugzilla set-up file again, it really is made to be simple! – but justdave updated the wiki-page.

It’s a really great example of the open source style. I tried it and talked about it, they checked it out and helped me and even helped others. Neither of us would have done it without the other.

Bugzilla Update the First

Once I figured out the CPAN issue (thanks Biesi!) it was relatively simple to install Bugzilla. Remember, while I’m a more advanced computer user, I don’t code – not one line. I even managed to figure out how to lock it down so only my family members can access the information.

A couple pain-points so far:

  • After editing components of a product it doesn’t offer you an option to go back to the product. Definitely annoying after deleting a component.
  • The Hardware, OS etc fields aren’t removable or editable. Though I’m told the fix for this is coming in 5.0, it’s a bit silly for my uses!

Pleasure-points so far:

  • Installation was hella easier than I expected it to be. Good work guys!
  • Nothing surprising yet, but the fact that it’s working the way I expected is a good thing. I’ve added a product and some components.

Time to file some bugs!

This Mother’s Life with Bugzilla

Open source really is a way of life and a way of thinking about things. About not accepting lack of control and being able to wield technology in the way that makes sense to your life. My family has been open source for 8 years now.  Not just in the sense that we use Firefox.  We’ve been using Sunbird for years to track our schedules (I can get on a very good rant about how it’s no longer supported and how we had a release quality product and are now forcing people to use google… but that’s best done with alcohol), my kids use Google docs and Libre Office instead of Word for assignments, but it really sunk in during the divorce.


It can be really jarring going from an open source world to an old fashioned one. Lawyers, at least our lawyers, are definitely still old fashioned  – though not always their own fault, my lawyer told me they’re required to keep pen and paper notes by law.  We were constantly having to remind them that mconnor is paid twice a month, not every two weeks. I’m not kidding, this came up every visit for at least the first 5 meetings.  My goodness did we want diffs when we were shown revised agreements, and how much easier it would have been if we could have submitted patches for the changes we wanted. About half-way through we realized that if we had it to do over again, we’d totally use Bugzilla.


Bugzilla also keeps coming up when we forget an arrangement we made for this holiday or that extra fee as we couldn’t remember if we’d made the arrangement via email (searchable), IM (searchable, but which one?) or using voice (SOL) and if we’d made a new arrangement after the last one we could find in our logs.  It comes up with the health benefits, too. We’re both really bad with paper. We’ve learned that receipts get scanned and emailed ASAP, but then there’s getting to the requests, and digging up the receipts. The usefulness of a bug tracker starts to be really apparent when you’re relying on someone who gets as much mail as mconnor does to remember to see that receipt and act on it next time he’s free.


Then there’s the kids. I have often mused on being able to assign bugs to them rather than having to either rely on them to do the things I asked them to do, or remind them constantly, though a robust task tracker rather than a bug tracker would probably be a better fit.  More importantly it would be great for them to be able to file bugs for me – sign that form for that field-trip, remember those school supplies they need me to pick up.


So I’ve done it. I’ve managed to install Bugzilla 4.2.4 on my dreamhost hosting – the instructions here are still relevant,  thanks to Biesi for the assist with CPAN. I’m not using it for a start-up or a side software project. I’m using it for my life.  I’ll keep you all posted with the ups and downs.

Bienvenu Mozilla Quebec!

In August I took the train over to Montreal to support the local Mozillians in their first meet-up. It was a great mix of volunteers and paid staff as well as languages and cultures. Case in point, you can now check out the gorgeous (and still improving) Mozilla Quebec website made by newcomer-to-Canada Fredy Rouge.


Keep an eye out for upcoming events and a friendly rivalry with Mozillians Toronto!


P.S. Sorry for the missing accents on the french! Need to learn how to make them on my kb.

“Do-ocracy” and Why Mozilla Shouldn’t Be One

For years the Mozilla community has prided itself on being a “merit-ocracy”: those with the talent and the skills got the recognition. Not only is it a wonderful concept, it was true. I know because my life has been incredibly affected by it. Those of you who have been around a while may remember a drunken and rambly (but well received!) toast I made in 2006 about my family’s path and the role Mozilla has played in it. Mozilla didn’t care about resumes and past history, they simply saw the invaluable contributions made to the project and did what they could to support those contributions continuing and flourishing. Because mconnor demonstrated his “merit,” he was trusted and asked to “do” more.

So what’s wrong with a “do-ocracy?”

Somewhere along the way, and I have my own opinions on exactly when and how, things got flipped. In the last year I am starting to hear more and more about Mozilla being a “do-ocracy”: the people who get things done get the recognition.  I personally feel this concept is toxic to a thriving and open community.  I am not suggesting that by using the term people feel the things I describe as negative are good, I do suggest the term is oversimplifying. Here’s why:

While you’re doing, where is everyone else?

The emphasis on getting things done precludes the idea of taking time to involve and teach others. Mconnor didn’t become the owner of the browser module because he already knew how. He was willing to learn and had the seemingly rare ability to put up with Ben Goodger (or maybe it was Ben who had the ability to put up with Mike? but I’m teasing)! This is where the subtlety of the difference in terms comes in. Yes, mconnor earned his merit with Mozilla by “do-ing” things, but he did other things to earn the trust and respect to move up to new roles. Similarly, there were mentors in place who weren’t just “do-ing” but also helping him learn and prove his “merit.”

Inviting people to participate can get you the results you want better.

I was encouraged when the original article made its rounds, and recently there is a new blog post about another instance of increasing the percentage of women speakers at tech events going around. How did they do it? They actively engaged the women they wanted to see participate. They recognized the “merit” of the women who in actuality weren’t “do-ing!” The organizers persisted in encouraging the women to participate and it benefited everyone involved. Once these women were confident that others saw their “merit”, they started “do-ing.” Before MoCo was formed this was built in to a degree. Needed help? You couldn’t hire someone to take that feature off your hands, you had to cultivate help from the community.

The fastest way to get things done is to pay someone.

A concern many people had when MoCo was founded was that eventually it would take over and there would no longer be a community of volunteers, just a compnay. Even if this was never anyone’s intention, it’s still a valid concern.  With the competition in the browser market heating up Mozilla understandably chose to add employees to help stabilize development and keep progress moving. Because it’s easier to get something done with paid employees than volunteers. That’s a truth we have to be wary of, if we truly value Mozilla as an open community of volunteers and employees alike. If getting something done is the primary motivation, using volunteers, and certainly allowing them into leadership roles, doesn’t make sense. Neither does recruiting from the community. Go out and find the people who have already added a particular task to their resume and hire them to do it again.


HR should be a “do-ocracy.”

This is one case where I feel the term applies nicely. I think we all know someone in public service that can’t get that promotion they’ve worked hard to earn because all jobs have to be posted publicly and interviewed for to be sure the absolutely best possible candidate – on paper anyway – gets the job. If there is the need for a paid position and someone is already doing the job, hire them! If someone is already doing the job, but they could be doing it better, don’t just hire someone else into it, help them become better!  I know there is a need to balance hiring out of the community and creating an expectation that community members will be hired, however I do worry the pendulum has swung too far. I think that if 2004 mconnor (and others) applied for Mozilla today he would have a very hard time competing with the intern program.

Long live “merit-ocracy!”

There is more to earning and displaying merit than getting something done. Merit also lives in how something is done. Being willing to learn, being friendly and encouraging to others. Having the experience to know why something is or isn’t a good idea, mentoring those who are “do-ing.”  Standing up for the community’s values.  You can’t “do” openness, it’s not an end result but a method.  Mozilla has been a values organization, it has always won on values. Products and features are just the vehicles for the values. To remain a thriving and open community Mozilla must continue to “do,” but to “do” with “merit.”  For these reasons, I believe we should stick with the traditional term “merit-ocracy” when trying to describe Mozilla and what it aspires to be.

Simply “do-ing” makes us the same as everyone else.

That’s Not My Name!

They call me Lucy

Lucy isn’t my name. It’s not my middle name either.  My best friend from high school and I loved Bram Stoker’s Dracula (with Gary Oldman) and during one of our many viewings she became Mina and I became Lucy. Since I already answer to it in real life, it became a natural online handle.  Lucy does me very well in online chats, ordering coffee and reserving tables. Everyone knows how to spell it and how to pronounce it whereas Majken fails both of these tests about as hard as a name could fail.

However, I feel a little awkward asking professional contacts to call me Lucy. There’s an odd feeling of deceit to it because it’s not obviously a nickname and the story of how I came to be Lucy is a story best told over drinks, not business.  Given my involvement with Mozilla, and my continuing leadership in the Reps program, I feel I’ve come to the point that everyone else does where I need to drop the old gaming/message board nick and start using my real name. Except that won’t work.

They call me Madge-ken

Majken is hard enough to pronounce in real life, let alone to figure out online. Turns out even I was saying it a little wrong. It wasn’t until the early 2000’s when some Swedish friends drunk dialed me that I finally heard my name pronounced correctly. Turns out a Swedish accent is the difference between love and hate (Google’s new Swedish voice incorrectly blends the jk if you don’t include the space). If I start using Majken, I will be forever Madge-ken. This will not do. I can’t stand it, though I don’t blame anyone who calls me that, it’s not your fault!

Funny story, my first GP called me Madge-ken for 12 years. We gave up trying to correct him when I was little and he was a very nice man so I didn’t mind. On my very last appointment with him before we moved away he finally noticed how my grandmother pronounced my name. Needless to say he was mortified, and to this day I feel bad for him.

They call me ???

I need a nickname that’s obviously derived from my real name but is EN readable, but Lucy is the only nickname that has ever stuck.  In that sense Majken was a bit of a blessing, try making fun of it!  “Bikin’ Majken” was the best the boys in Gr 4 could do. In Gr 7 our class clown was very talented and managed to get to “My Chicken” and “Magic Johnson.” Not very insulting for me, or satisfying for them, so they inevitably moved on to names easier to manipulate. Thankfully any play on Mike is out of the question since mconnor has the Mike Connor market cornered.

Maybe Kensie!

But wait! My name has two syllables! Thanks to the surge of Mackenzies in the world there are some very cute nicknames rooting from “Ken” and I’m going to blatantly appropriate one for myself. As awkward as it is to pick your own nickname, I need one, and Kensie Connor is just way too awesome a name to pass up! I already use Majken for twitter, facebook and my email address, so the transition shouldn’t be too rough. I just wanted to put a background out there and give people a heads up to make it as smooth as possible.