Flock Blog

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.