Mozilla

Module Ownership – Part 2

March 27th, 2008

New Module Proposal

In a previous post I proposed that we create a group of people to be responsible for the overall health of Mozilla’s module ownership system. I also proposed that the group itself be a module within the module system. This way we can build on our shared understanding of how modules work.

More specifically, I propose we use the module and sub-module model currently used by the Firefox front end teams. This system adds another layer of delegation to deal effectively with the scope of activities, while ensuring there is an owner and peers responsible for the integrated whole that people experience as the front-end.

For those interested in more detail, there is an uber-module, known simply as the “toolkit” module. It has an owner and peers. This group has authority across the toolkit module. Within the toolkit module there are sub-modules. These are more specific aspects of the front-end. Each of these has sub-module owners and peers. The sub-module owners and peers have the standard degree of authority in their sub-modules, subject to the authority of the uber toolkit module owners and peers. In reality there’s a lot more consensus and back-and-forth than “subject to the authority of” might imply. But there is an identified escalation path and decision-maker when the need arises.

In this case I propose we create an uber-module called Governance, for which I will be the owner. (For those not familiar with Mozilla, this is not new. I’ve been the ultimate decision-maker for all non-technical decision at Mozilla, including policy and governance, since 1999.) We then create a sub-module called Module Ownership. In the future we’ll create other sub-modules. An example of one that comes to mind immediately is our policy for handling security bugs, for which Frank Hecker has always been the owner.

For the Module Ownership module we should have two owners: Brendan primarily for modules relating to technical matters, and me for modules relating to non-technical matters. We would have a set of peers. This would be a group of about seven to ten people with authority to address issues relating to modules and module ownership. They would act as peers generally do, giving us a set of experienced people, any one of whom could become qualified to become the sub-module owner. This will help us build a deepening set of people with the reputation and authority to lead.

I view my involvement here as part of my Chief Lizard Wrangler role, not related to my employment status. I will count it as a mark of success when it becomes clear that there are several people other than me doing the relevant work who could be a good sub-module owner. It’s a mark of success not because I’m not interested in this. It’s a mark of success because our organization is healthier when there are several people who are able to lead in important areas.

Designating Members

In this proposal, Brendan and I would behave as module and sub-module owners generally do, delegating authority to peers. I don’t have a complete list in mind now, and I don’t think Brendan does either at this point. Naturally, I hope to soon.

Sorry, comments are closed.

Skip past the sidebar