Mozilla Modules and Module Ownership
Distributed Decision-Making
Mozilla.org staff members do not make many of the ongoing decisions regarding code appropriateness, quality or readiness to be checked into the CVS source repository. The Mozilla project is far too big for staff to do this. The project includes both a set of core technologies (layout engine, networking libraries, cross-platform component model, etc.) and a set of applications built with those technologies (browser, mail/news reader, Internet Relay Chat client). Mozilla.org staff is not equipped to make the volume of decisions needed for ongoing development. For one thing, it would be presumptuous to believe that the Mozilla hackers on mozilla.org staff are the experts in all areas of the code; this is most certainly not the case. For another, staff is small. The project would slow to a crawl if mozilla.org staff tried to make the majority of decisions regarding particular pieces of code.
Instead, mozilla.org distributes decision-making to a range of participants through its "modules" and module ownership. A module is a set of files that implement a piece of functionality that has reasonably defined boundaries. A module may be the set of files in a directory, such as "accessible" for Accessibility. Or a module may be more conceptual, such as "Stylesheets". In such a case the module would include a number of files in different areas of the source tree. A module could contain just two files (if written in C or C++): a .h file and a .c or .cpp file. (An example is xpcom/ds/pldhash.[ch] which is treated separately from other elements of xpcom.)
Of course, "reasonably defined boundaries" doesn't provide absolute clarity. We use this definition because it reflects the code itself, where there may be overlap and ambiguity as to where a particular functionality ends and a different one begins. Trying to create absolute definitions would require elaborate rules and exceptions which aren't needed in most cases. Rather than spend energy devising such definitions, we prefer to let module owners manage any overlap or shared ownership if possible, with mediation by mozilla.org staff if necessary.
The Module Owner Role
A "module owner" is someone to whom mozilla.org staff delegates leadership of the module's development. This includes a range of responsibilities, such as: improving code quality, implementing revisions and innovations as appropriate, coordinating development with that of the rest of the codebase, developing and maintaining a shared understanding of where the module is headed, developing APIs where appropriate, documenting as much as possible, responding appropriately to code contributions, design suggestions and stated needs of the community; and creating an environment where competent newcomers are welcomed and included.
A module owner's OK is required to check code into that module. In exchange, we expect that the module owner care about what goes in, respond to patches submitted by others, and be able to appreciate code developed by other people. Module owners have a fair amount of flexibility in how they do this. Mozilla.org staff does not have an elaborate set of rules or procedures for how module owners manage their modules. If it works and the community is generally happy, great. If it doesn't, let's fix it and learn.
Module Owners need not do all the work of managing the module themselves. Module owners may identify others who can also approve code for check-in into a module. These developers are known as "peers" and ought to possess many of the qualities of a good module owner. Module owners must designate to a peer the evaluation of their own code; module owners are not permitted to review their own code. If there is no module owner, the OK of a peer is sufficient to check code into that module.
Module owners are not tyrants. They are chartered to make decisions with input from the community and in the best interests of the community. Module owners are not required to write code because the community wants them to. (Like anyone else, the module owners may write code because they want to, because their employers want them to, because the community wants them to, or for some other reason.) Module owners do need to pay attention to patches submitted to that module. However "pay attention" does not mean agree to every patch. Some patches may not make sense for Mozilla; some may be poorly implemented. Module owners have the authority to decline a patch; this is a necessary part of the role. Mozilla.org asks the module owners to describe in the relevant bug their reasons for wanting changes to a patch, for declining it altogether, or for postponing review for some period. We don't ask or expect them to rewrite patches to make them acceptable. Similarly, module owners may need to delay review of a promising patch due to an upcoming deadline. For example, a patch may be of interest, but not for the next milestone. In such a case it may make sense for the module owner to postpone review of a patch until after matters needed for a milestone have been finalized. Again, we expect this to be described in the relevant bug. And of course, it can't go on very often or for very long without some review by mozilla.org staff.
Mozilla.org Staff Review
Mozilla.org will get involved if controversy develops and cannot be resolved otherwise. Sometimes a module owner asks mozilla.org for a public statement of agreement with a particular action. Sometimes other contributors suggest ways in which a module owner might improve. Sometimes there is ongoing controversy. We prefer that the community resolve these issues when possible, but acknowledge that this can't happen all the time. We try to avoid making absolute decisions like "this must happen" but will do so if required.
Criteria for Module Ownership
There are a number of elements which are important for good module ownership. First of course, is the person's expertise with the code in question. But over time we've learned that a set of additional criteria is also important, and that a great hacker can be a poor module owner. The criteria that go into the mix for a good module owner include:
- expertise with the code in the module
- current level of involvement with the module
- understanding/vision of where the module ought be headed
- appropriate understanding of Mozilla codebase as a whole and the module's relationship to it
- ability to evaluate code for that module, including contributions of patches and new features
- ability to evaluate impact of code on other parts of the codebase
- ability to communicate with a diverse, geographically distributed community
- willingness to evaluate contributions on their merits, regardless of their source (i.e., no 'not invented here' syndrome)
- ability to consider varying perspectives and needs of different consumers of that module
- ability to resolve different needs through factoring or other abstraction techniques when appropriate.
Designating a Module Owner
We prefer that an individual work with a module for some time and demonstrate his or her ability to fulfill most of the criteria most of the time (we're not naive enough to require perfection), and that a consensus form about designating this person as the module owner. This way the designation is more of a confirmation than an appointment. We haven't always done this, and we haven't always done it well. But we intend to do a better job from now on.
This means that there will be times when there is no module owner. Especially in cases of modules that have received little attention, have started to rot, and some brave soul steps up to figure things out and get us back on track. We'll shower these folks with thanks for tackling the job, and we can do this immediately. We may not immediately designate these people as module owners. Almost by definition, it will be difficult for this person to have demonstrated some of the criteria, particularly 1-5 until s/he has spent some time working with the module. It's possible that someone's expertise is so broad and so deep that s/he could do this, but we would expect this to be the exception rather than the rule.
In determining a module owner, the criteria above are not necessarily accorded the same weight for each module. The importance of a particular element depends on the module. For example, criteria 4 (appropriate understanding of Mozilla codebase as a whole and the module's relationship to it) and 6 (ability to evaluate impact of code on other parts of the codebase) will be of less importance for modules that are self-contained, and of great importance for modules containing core technologies which affect other parts of the code significantly. Similarly, criteria 9 (ability to consider varying perspectives and needs of different consumers of that module) and 10 (ability to resolve different needs through factoring or other abstraction techniques when appropriate) will be less important to a module which serves a specific, clearly defined function for a small number of contributors, and critical to a module which supports a variety of uses and a broad contributor group.
Tracking Module Owner and Peer Data through Despot
Mozilla.org uses a database known as "Despot" (despot.mozilla.org) to track modules, module owners and peers. The data can be viewed at www.mozilla.org/owners.html. This page also contains an indication of what code makes up each module.
Transfer of Module Ownership
Module ownership is transferred through mozilla.org. A module owner should resign by sending mail to staff@mozilla.org. The module owner should feel free to include recommendations for a new module owner. In some cases, the module will have a peer who has demonstrated the criteria for module ownership, is interested in being the module owner, and is generally accepted as being a logical successor. In such cases, mozilla.org staff will commit the change of ownership to Despot. In other cases there may not be anyone who has demonstrated the ownership criteria with respect to that module. In these cases, the module may go without an owner until an owner develops, with the peers of the module providing the review and OK necessary to check into that module.
Relationship to Bugzilla Component Owners
Occasionally there is some confusion between the role of module owner/peer and that of default owner of a Bugzilla component. The roles are quite different. A component owner is the person best suited to receive incoming bug reports for a particular component; not necessarily the person best suited to make decisions about the direction of the module and the review of its code. There are several reasons for this. First, Bugzilla components do not map exactly to modules. That's because components reflect the way bugs are perceived and experienced, not necessarily the structure of the code. Second, managing bugs is a different task than managing the code of a module. The skills required are different. Some great hackers are not so good at reviewing bug reports regularly, tracking progress, reassigning bugs to correct owners, making sure test cases exist, etc. Some contributors are excellent at these skills but not ready to be module owners. So in some cases the Bugzilla component owner and the module owner may be the same person. But in many cases they will be different.
Poorly Maintained Modules
Periodically a module is not well maintained and no longer interacts well with the rest of the codebase. This can happen where there is no module owner, or when a designated module owner is too busy with other things to tend to the module. Conceivably it could happen when a module owner is active, but has an approach to a module that the community in general believes is inappropriate. Mozilla.org staff prefers that the development community identify such modules, propose a solution, and implement improvement. If this can't happen for some reason mozilla.org staff will get involved to find the best possible resolution.