« Transitions | Main | Flock 1.0 beta, now with 100% more code review! »

It begins

I'm already beginning to fulfill one of the goals I set out for myself when I started with Flock.  Yesterday, I opened my first bug to push some Flock code back upstream to Mozilla. I had queried Flock developers during my interview process on how much code they had already pushed back upstream.  The response was almost as if on cue.  Groaning (in unison) was followed by everyone's favourite (and unfortunately valid) complaint of patches sitting in review queues for months without any action.  That wasn't the only issue brought up, and many of the issues can and will be mitigated.  However, the point to take away was that while these developers were "bought in" to the whole Mozilla community/ecosystem and "giving back" thing, the issues they encountered with the review process basically skewed the diminishing returns ratio to the point that people stopped bothering. In reviewing this oft-repeated complaint, I came up with this short list of issues...
  1. Outside contributors often don't know the drill.  There is a real art to getting code into the tree.  While the process is documented, it's the subtle details that determine whether this process involves much pain and suffering or instead is efficient and streamlined.  As an admittedly lengthy example: if the bug is hastily written, or doesn't describe a compelling enough problem to the reviewers and drivers that read it, there's a good chance it'll be WONTFIXed.  You have to context-switch out of "internal dev" mode and into "talking to folks that don't live in my codebase every day" mode.  drivers@m.o probably won't know all the issues you're facing because something's an AUTF8String instead of an AString.  Explain yourself well.  Write your bug summary, and then have a co-worker read it for sanity.  Link to the bug in your defect tracking system if it's available to the public, but remember that linking to your tracker doesn't excuse you from explaining yourself well in the bug on Mozilla's.
  2. Patches sitting eternally in review queues demotivate contributors.  This one is obviously not outside contributor-specific, but is often experienced by them in an uneven ratio.  Outside folks often don't know who to request r? and a18xx? from, they pick someone whose queue is insanely long, or they use the despot-driven module owners page and don't know that it's out of date and so-and-so is no longer working on foo, etc.  Recently, pavlov's made serious progress in cleaning it up, but it's almost always going to be at least a little out of date.  Knowing who to request review from is as important as writing the bug.  Use bonsai to check the CVS check-in history for the component, directory or file you're touching.  Read the most recent check-in comments to get a sense of who the active reviewers are.  If you're still not sure, try pinging one of them in IRC.
  3. Whomever checks in is responsible for bustage.  If a driver checks in your seemingly innocuous patch, they're on the hook to watch the tinderboxes for the next couple hours in case your patch breaks the build.  This is a non-trivial commitment of time on their part, and means it's more work than simply reviewing the patch and ticking the box.  This is where being a jerk in steps 1 and 2 comes back to bite you.  So as Chris Rock says, "Be polite."  If at all possible, be around on IRC in case you're needed to debug the bustage.  This is also where hiring existing Mozilla developers to work on your project can pay off.  If the reviewer personally knows the coder, and the coder has check-in rights, the burden on the reviewer is much less.  The reviewer knows that the coder will be the one watching for tinderbox flames for the next two hours, and so they're more likely to give that patch r+.
Let's return to the patch I submitted.  While it is both small and almost Flock-specific, I thought it was simple enough to gauge how much pain we as outside contributors truly faced when trying to "give back."  I must say that the process didn't feel much worse than it did being a calendar developer.  Like I was when on Sunbird, I am still one-step removed from Firefox, but I'm not Mr. Unknown.  In this case, I've met the reviewer, Gavin Sharp, in person.  I was able to discuss the patch with him a bit on IRC, and in doing so he gained some understanding of why we made this fix.  I was also able to address some of his concerns, thus the r+. So the moral of this story for me is that if you're working on a Mozilla-based product, hire an existing Mozilla contributor when possible, and engage the community in dialogue often.  Become known for good work, and even better behaviour.  Opening a bug, attaching a patch, and expecting it to stand on its own seems foolish given the scarcity of resources and a reverse scarcity of code.  Open lines of communication help avert your patches being from summarily rejected, and may make you think through why you needed to fork in the first place.  

Tags: ,

TrackBack

Listed below are links to weblogs that reference It begins:

» hard but not impossible from Asa Dotzler - Firefox and more
Over his blog, lilmatt's got a great post up on what it often takes to get code into Mozilla. He offers some really good advice and anyone that's trying to get code into Mozilla, whether working on Firefox, some other Mozilla-hosted app like Calendar, ... [Read More]

Comments (4)

matt, great post! thanks for taking the time to write this up -- it's something we're always thinking about & working on. glad you're at flock!

dave:

Just a random thought, but have the various non-Mozilla developers thought about organizing peer-review of each others contributions?

After all, if it gets into Mozilla then it's going in to your codebase too, you all should have at least some understanding of the relevant issues and if a 3rd party is telling you that your explanation isn't clear or that your code could be improved by doing X then it takes away from the Us vs Them scenario where Mozilla reviewers are seen as the 'bad guys' and hopefully will result in slightly fewer but much higher quality patches for them to review.

It would also be a forum for sharing exactly the kind of info you present here

Clint Talbert:

Before becoming a Mozilla Calendar community contributor, I was one of these "outside" contributors. My company had taken the Thunderbird 0.8 codebase and was working with it. I can remember first-hand the issues we faced with both points 1 (trying to understand the drill) and 2 (submitting patches and never understanding why they weren't being looked at).

This only changed when we changed our interaction with the Thunderbird and Calendar project and became proactive about being involved in the community. This was not easy to do.

When you're working on a closed source, closed company project, making the mental shift to embrace an open source style and philosophy is hard. It really changes the way you work. And perhaps even more importantly, it's even harder to explain that to your superiors who still expect you (the developer) to control all aspects of the project.

At my old job, we did this by explaining (several times) and finally demonstrating (with results) that the only way we were going to be effective at truly "giving back" our code to the community was to become part of that community. And then we'd have the benefit of staying current in that communal codebase rather than being a forked offshoot of code that has long since been obsoleted.

I'm not sure how this process could be made easier, but it would be a huge win for the Mozilla project and all its related projects if it could be done.

Fantastic post!

There is some irony that that is a rather poorly written bug report from my perspective as a testers. I know this is a fairly trivial case, but you also used it here as your own example ;-)

http://wiki.flock.com/index.php/Test:Reporting_a_bug shows an example of a well written bug.

In this bug, you did not clearly describe the problem.

Bug summary: What does "doesn't handle" mean?

Nor do either of the related Flock bug reports have great Summaries.

A bug report should start with the symptom experienced.

With the way the attachment is added to a comment in bugzilla, your bug report actually starts with your proposed solution, "If uri has a pipe, only load the first page".

Dave above makes a great point about the opportunity to involve more members of your team. A QA member of your team could have reviewed your bug report and be cc'd to help with any testing, etc.

The bug report should include all the relevant details, here you have to go to https://bugzilla.flock.com/show_bug.cgi?id=7662 for import details.

The bug itself is not Flock specific as I recall Firefox supporting multiple home pages. Surprised that it has not been previously reported, but I also can't find a duplicate.

"So the moral of this story for me is that if you're working on a Mozilla-based product, hire an existing Mozilla contributor when possible, and engage the community in dialogue often."
Actually, is that the moral? I come away thinking that if a well written bug report for a severe issue does not get attention then Mozilla has a serious problem -- which I have no reason to believe that they do.

Maybe the moral is: For non-severe bugs, if you want the issue to be addressed in a timely manner then you have to give a little more back.

Most often, most bugs are not worth fixing (now).

About

This page contains a single entry from the blog posted on May 17, 2007 2:15 PM.

The previous post in this blog was Transitions.

The next post in this blog is Flock 1.0 beta, now with 100% more code review!.

Many more can be found on the main index page or by looking through the archives.

Powered by
Movable Type 3.32