Tips For Contributing New Features To Mozilla
Learn the codebase and coding practices before you start your feature.
Include learning time in your schedule. Mozilla is a complex codebase. Our portability requirements may be new to even seasoned developers. Our cross-platform component model (“XPCOM”) is similar to COM, but you’ll want to make sure you use it well before going too far with your project. And of course, we have a set of coding practices to help everyone live together. Life will be much easier if your team has one or more members who are already familiar with and to the Mozilla world.
Develop relationships with existing developers in the area of your feature. If you want to add a big new feature to mail, spend some time helping the existing mail developers. Talk to the developers about fixing some of their bugs. Fix some bugs. Have some of your QA team get involved. Once you’re familiar with an area, do the completely unexpected and write a piece of documentation. Developers will be grateful, and you’ll be known as someone seriously interested in contributing. Become familiar with our code review processes. Have someone on your team become Mozilla-savvy enough to obtain CVS access.
Help the existing developers to understand that you are “for real.” That you have a clue about Mozilla development; that your team is going to ship a product. Our developers get a lot of mail, and not all of it is helpful. We appreciate the attention and interest in Mozilla, but the developers have to prioritize how they spend their time. Help them to realize you’re an informed developer who is interested and able to contribute. This will be much easier if you’ve been working on suggestion two.
Designate someone on your team to be involved with the mozilla.org CVS repository on a regular basis. The ease of integrating your feature will increase if someone on your team is intimately involved with the source tree. Reviewing the tree only at the milestone releases is risky if you're doing significant development. Something may have changed that will cause you extra work. And you'll miss the early discussion phase when you can add your perspective to the design work. If you absolutely don't have the resources to do this, then plan for extra integration time.
Work hard to have a developer involved in the core code who is connected to what you are doing. If you can’t make this happen, let mozilla.org staff know and we will try to facilitate this. It’s possible developers may not pay much attention to you because they believe your proposed feature is not a high priority, or is not wanted at all, or that you haven’t demonstrated that you understand the codebase and Mozilla coding practices well enough for them to spend a lot of time with you. In some cases the developers may be in error and staff will work to make this clear and get you connected. In other cases, mozilla.org staff may agree with the developers that it does not make sense for them to spend much time assisting with your project. This is a painful setting and we hope it doesn’t happen often. But our developers are a precious commodity and their time is probably the most important resource we have.
It’s also possible that a developer is over-worked or on vacation or just drops the ball. Obviously, we’ll never reach perfection but we need to reduce these occurrences as much as possible to have a successful project. If this happens to you, let us know. We’ll talk to the developers in question, find others to help you, and try to improve your experience with the project. Eventually you’ll be plugged in enough you won’t need us, you’ll be able to find your own back-ups. We’ll still want to know if a developer is consistently not responding to contributors, but you’ll be able to deal with the occasional problems just by asking someone else.
Design in the open. Post your plans to the appropriate newsgroup. If there is no response, double-check to see if you have been successful with suggestion five.
Try hard to design your feature so that it can be implemented and reviewed in manageable size patches. If you can implement and submit core elements first and build on them in subsequent patches, so much the better. If you think your feature can only be implemented and reviewed in one enormous chunk, ask for design help in the appropriate newsgroup and/or from the developers with whom you have established relationships.
If it is not possible to submit your feature in manageable size patches and you submit a 500k patch, be prepared for several months of review and revision before the patch is ready to be checked in. It may not take this long. But if your team has worked for months on a feature, it is going to take reviewers new to the code a long time to work their way through it. And if it’s not possible to design the feature in bite-size chunks, it probably won’t be possible to review it that way either. We expect our reviewers to understand the code they approve for check-in, not to simply glance at it and say OK. Finding the focus to digest a massive patch in the midst of multiple other demands will take time, even if you’ve done a perfect job. And since few of us are perfect, chances are that revisions will be requested.
If you’ve got a large patch, let the likely reviewers know when they might expect to see it. If your timeframe is tight, check out the Mozilla roadmap for milestone dates and see if your feature will arrive at a time of furious activity. If so, and if your feature is not of general interest, prepare to be a low priority for a while.
Get connected with mozilla.org staff. mitchell@mozilla.org is a good contact for project management discussions. Let us know what you’re doing. If you can find the resources, designate someone on your team as the liaison to mozilla.org for project management issues.
Become familiar with the Code Review FAQ.
Review and super-review take time. Improving the code as requested by the reviewers takes time. Poor quality code also takes time. We’ve opted to spend the time improving code consistency before check-in when the pain is limited to the developers and the reviewers rather than everyone in the tree. We’re committed to this style of development, but recognize that vigilance is necessary to make sure newcomers and their features don’t get lost. If you’re having a particularly bad experience or if you’ve got suggestions on how to improve our process, please let mozilla.org staff know.