Warning: The content of this article may be out of date. It was last updated in 2004.
Tips For Contributing New Features To Mozilla.
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.
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.
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.
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.
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.
Post your plans to the appropriate newsgroup. If there is no response, double-check to see if you have been successful with suggestion five.
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.
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 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.
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.
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.