Mozilla Roles and Leadership
The Mozilla project is governed by a virtual management team made up of experts from various parts of the community. Some people with leadership roles are employed to work on Mozilla and others are not. Leadership roles are granted based on how active an individual is within the community as well as the quality and nature of his or her contributions. This meritocracy is a resilient and effective way to guide our global community. The different community leadership roles include:
Module Owners and Peers
Module owners are responsible for leading the development of a module of code or a community activity. This role requires a range of tasks, including approving patches to be checked into the module or resolving conflicts among community members. Lists of code module owners and non-code module owners are available.
Super-reviewers are a designated group of strong hackers who review code for its effects on the overall state of the tree and adherence to Mozilla coding guidelines. Super-review generally follows code review by the module owner, and the approval of a super-reviewer is generally required to check in code. More information on code review can be found in the mozilla.org code review FAQ.
Release drivers provide project management for milestone releases. The drivers provide guidance to developers as to which bug fixes are important for a given release and also make a range of tree management decisions.
Bugzilla Component OwnersBugzilla component owners are the default recipient of bugs filed against that component. Component owners are expected to review bug reports regularly, reassign bugs to correct owners, ensure test cases exist, track the progress toward resolving important fixes, and otherwise manage the bugs in the component. The Bugzilla component owner and the related module owner may be the same person, but in many cases they will be different.
Former Module Owners
When module owners and similar leaders pass on their leadership and authority to others we refer to them as Former Module Owners. This allows us to continue to acknowledge their contributions to our (collective) success -- mentoring new leadership and passing on authority to new leaders is an important part of maintaining a healthy project. "Former" status can apply to people who move to other roles within Mozilla, and to people who are no longer active in Mozilla. It is intended to be factual, not subjective or evaluative.
Reps are deeply passionate Mozillians who represent Mozilla in their country or region and are committed to educating and empowering people to support the Mozilla mission and contribute to the project. They are the eyes, ears and voice of Mozilla on the ground.
Mozilla Reps Mentors
Mentors provide mentorship and guidance to ensure that Reps are successful in fulfilling their responsibilities. Mentors are also responsible for reviewing monthly reports, budget requests and swag requests filed by their Reps.
Mozilla Reps Council
The Council is the program's 9-member governing body and its 7 volunteer members are elected. The Council exists to ensure that the Mozilla Reps program runs smoothly, oversees the governance and finances of the program and serves as an advisory body within the Mozilla organization.
Stewards are responsible for the growth and health of the community around functional and regional areas. Although everyone in Mozilla has a responsibility to help new people join the community, Stewards maintain the contribution pathways that connect potential contributors to teams that have contribution opportunities. Stewards also run recognition, education and metrics projects that keep those pathways functioning well.
The ultimate decision-maker(s) are trusted members of the community who have the final say in the case of disputes. This is a model followed by many successful open source projects, although most of those communities only have one person in this role, and they are sometimes called the "benevolent dictator". Mozilla has evolved to have two people in this role - Brendan Eich has the final say in any technical dispute and Mitchell Baker has the final say in any non-technical dispute. This has been the case since 1998 for Brendan and 1999 for Mitchell.