How do you become a Firefox peer? The answer may surprise you!

So you want to know how someone becomes a peer? Surprisingly the answer is pretty unclear. There is no formal process for peer status, at least for Firefox and Toolkit. I haven’t spotted one for other modules either. What has generally happened in the past is that from time to time someone will come along and say, “Oh hey, shouldn’t X be a peer by now?” to which I will say “Uhhh maybe! Let me go talk to some of the other peers that they have worked with”. After that magic happens and I go and update the stupid wiki pages, write a blog post and mail the new peers to congratulate them.

I’d like to formalise this a little bit and have an actual process that new peers can see and follow along to understand where they are. I’d like feedback on this idea, it’s just a straw-man at this point. With that I give you … THE ROAD TO PEERSHIP (cue dramatic music).

  1. Intro patch author. You write basic patches, request review and get them landed. You might have level 1 commit access, probably not level 3 yet though.
  2. Senior patch author. You are writing really good patches now. Not just simple stuff. Patches that touch multiple files maybe even multiple areas of the product. Chances are you have level 3 commit access. Reviewers rarely find significant issues with your work (though it can still happen). Attention to details like maintainability and efficiency are important. If your patches are routinely getting backed out or failing tests then you’re not here yet.
  3. Intro reviewer. Before being made a full peer you should start reviewing simple patches. Either by being the sole reviewer for a patch written by a peer or doing an initial review before a peer does a final sign-off. Again paying attention to maintainability and efficiency are important. As is being clear and polite in your instructions to the patch author as well as being open to discussion where disagreements happen.
  4. Full peer. You, your manager or a peer reach out to me showing me cases where you’ve completed the previous levels. I double-check with a couple of peers you’ve work with. Congratulations, you made it! Follow-up on review requests promptly. Be courteous. Re-direct reviews that are outside your area of expertise.

Does this sound like a reasonable path? What criteria am I missing? I’m not yet sure what length of time we would expect each step to take but I am imagine that more senior contributors could skip straight to step 2.

Feedback welcome here or in private by email.

New Firefox and Toolkit module peers

Please join me in welcoming another set of brave souls willing to help shepherd new code into Firefox and Toolkit:

  • Luke Chang
  • Ricky Chien
  • Luca Greco
  • Kate Hudson
  • Tomislav Jovanovic
  • Ray Lin
  • Fischer Liu

While going through this round of peer updates I’ve realised that it isn’t terribly clear how people become peers. I intend to rectify that in a coming blog post.

New Firefox and Toolkit module peers in Taipei!

Please join me in welcoming three new peers to the Firefox and Toolkit modules. All of them are based in Taipei and I believe that they are our first such peers which is very exciting as it means we now have more global coverage.

  • Tim Guan-tin Chien
  • KM Lee Rex
  • Fred Lin

I’ve blogged before about the things I expect from the peers and while I try to keep the lists up to date myself please feel free to point out folks you think may have been passed over.

Thoughts on the module system

For a long long time Mozilla has governed its code (and a few other things) as a series of modules. Each module covers an area of code in the source and has an owner and a list of peers, folks that are knowledgeable about that module. The full list of modules is public. In the early days the module system was everything. Module owners had almost complete freedom to evolve their module as they saw fit including choosing what features to implement and what bugs to fix. The folks who served as owners and peers came from diverse areas too. They weren’t just Mozilla employees, many were outside contributors.

Over time things have changed somewhat. Most of the decisions about what features to implement and many of the decisions about the priority of bugs to be fixed are now decided by the product management and user experience teams within Mozilla. Almost all of the module owners and most of the peers are now Mozilla employees. It might be time to think about whether the module system still works for Mozilla and if we should make any changes.

In my view the current module system provides two things that it’s worth talking about. A list of folks that are suitable reviewers for code and a path of escalation for when disagreements arise over how something should be implemented. Currently both are done on a per-module basis. The module owner is the escalation path, the module peers are reviewers for the module’s code.

The escalation path is probably something that should remain as-is. We’re always going to need experts to defer decisions to, those experts often need to be domain specific as they will need to understand the architecture of the code in question. Maintaining a set of modules with owners makes sense. But what about the peers for reviewing code?

A few years ago both the Toolkit and Firefox modules were split into sub-modules with peers for each sub-module. We were saying that we trusted folks to review some code but didn’t trust them to review other code. This frequently became a problem when code changes touched more than one sub-module, a developer would have to get review from multiple peers. That made reviews go slower than we liked. So we dropped the sub-modules. Instead every peer was trusted to review any code in the Firefox or Toolkit module. The one stipulation we gave the peers was that they should turn away reviews if they didn’t feel like they knew the code well enough to review it themselves. This change was a success. Of course for complicated work certain reviewers will always be more knowledgeable about a given area of code but for simpler fixes the number of available reviewers is much larger than it was otherwise.

I believe that we should make the same change for the entire code-base. Instead of having per-module peers simply designate every existing peer as a “Mozilla code reviewer” able to review code anywhere in the tree so long as they feel that they understand the change well enough. They should escalate architectural concerns to the module’s owner.

This does bring up the question of how do patch authors find reviewers for their code if there is just one massive list of reviewers. That is where Bugzilla’s suggested reviewers feature comes it. We have per-Bugzilla lists of reviewers who are the appropriate choices for that component. Patches that cover more than one component can choose whoever they like to do the review.

 

More new Firefox/Toolkit peers

A few things are happening which means there are a bunch of new Firefox/Toolkit peers to announce.

First since I’m now owner of both Firefox and Toolkit I’ve decided it doesn’t make much sense to have separate lists of peers. Either I trust people to review or I don’t so I’m merging the lists of peers for these modules. Practically since Toolkit already included all of the Firefox peers this just means that the following folks are now Firefox peers in addition to already being Toolkit peers:

  • Nathan Froyd
  • Axel Hecht
  • Mark Mentovai
  • Ted Mielczarek
  • Brian Nicholson
  • Neil Rashbrook
  • Gregory Szorc
  • David Teller

Second we’re updating the list of suggested reviewers in bugzilla for Toolkit. In doing so I found that we have a number of reviewers who weren’t already listed as peers so these folks are now considered full Firefox/Toolkit peers:

  • Kit Cambridge
  • Tantek Çelik
  • Mike Hommey
  • Matt Howell
  • Mike Kaply
  • François Marier
  • Nicholas Nethercote
  • Gian-Carlo Pascutto
  • Olli Pettay
  • J Ryan Stinnett
  • Andrew Sutherland
  • Gabriele Svelto
  • Jan Varga
  • Jonathan Watt

All of these folks have been doing reviews for some time now so this is largely just book-keeping but welcome to the fold anyway!

Welcome to a new Firefox/Toolkit peer, Shane Caraveo

It’s that time again when I get to announce a new Firefox/Toolkit peer. Shane has been involved with Mozilla for longer than I can remember and recently he has been doing fine work on webextensions including the new sidebar API. As usual we probably should have made Shane a peer sooner so this is a case of better late than never.

I took a moment to tell Shane what I expect of all my peers:

  • Respond to review requests promptly. If you can’t then work with the patch author or me to find an alternate reviewer.
  • Only review things you’re comfortable with. Firefox and Toolkit is a massive chunk of code and I don’t expect any of the peers to know it all. If a patch is outside your area then again work with the author or me to find an alternate reviewer.

Please congratulate Shane in the usual way, by sending him lots of patches to review!

hgchanges is down, probably for good

My little tool to help folks track when changes are made to files or directories in Mozilla’s mercurial repositories has gone down again. This time an influx of some 8000 changesets from the servo project are causing the script that does the updating to fail so I’ve turned off updating. I no longer have any time to work on this tool so I’ve also taken it offline and don’t really have any intention to bring it back up again. Sorry to the few people that this inconveniences. Please go lobby the engineering productivity folks if you still need a tool like this.

Globes

I got bored over the weekend and decided to try my hand at fractal art again. I used to play around with this years ago but not so much recently. I was pretty disappointed to find that nothing has really changed when it comes to the tools available for creating fractals. Most of them haven’t been updated in years and there don’t seem to be much in the way of new kids on the block that I can see either. About the only new tool I found is Chaotica which hasn’t been updated in a year and only slowly before then. I used it to create the above piece.

I’ve yet to find my ideal tool for editing fractals, particularly flame fractals. All of them focus on the details of editing all of the parameters that go into the fractal. None of them pay any attention to the workflow. I’d love to see something that let me edit fractals like Lightroom with virtual copies allowing for branching histories of edits so I can compare what my edits are doing. This is particularly important when rendering even thumbnails is slow business. Maybe I’ll just give up and write my own tool one of these days.

On Firefox module ownership

It has been over eleven years since I first wrote a patch for Firefox. It was reviewed by the then-Firefox module owner, Mike Connor. If you had told me then that at some point in the future I was going to be the module owner I probably would have laughed at you. I didn’t know at the time how much Mozilla would shape my life. Yet yesterday Dave Camp handed over the reigns to me and here we are.

When Dave proposed me as the new module owner he talked about how he saw Firefox as a code module, responsible for the code that ships with the app, rather than the decisions about what the app needs to do. Those are delegated to other teams with better grasps of the situation like Product and UX. I agree with this wholeheartedly. It isn’t my role as an engineer to make those kinds of decisions. The Firefox module owner is focused on the implementation of the code in the browser and pretty much nothing else.

But in the Firefox module even the implementation decisions have always been heavily delegated to the peers of the module. I don’t intend to change that. I’m here to help guide those working on the code when they need a broader view, not to put my foot down and insist on how things should happen. I’m here to direct you to the peer most able to help you when you need a reviewer or run into problems. On some occasions I will also be here to listen and advise when you think the peers are wrong. In fact I see this role as less about being a module owner and more being a module steward, staying out of the way mostly but applying a gentle hand to the tiller when needed.

Those of you keeping an eye on things will note that I’m also the Toolkit module owner. That hasn’t changed and while I have always approached that module in much the same way as I plan to approach Firefox there are a few differences. I’ll talk about those another day.