Governance/Reboot

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

The Mozilla project's governance mechanisms have not kept pace with changes within the project in terms of the breadth and scope of what we do. The module ownership system may now cover as little as 25% of the project's activities. Other mechanisms of governance, like the MoCo organization's management hierarchy, have naturally moved to fill the gap - but this leaves a transparency problem, as well as widening a divide between employees and volunteers.

Having a comprehensive and clear community governance system promotes transparency and accountability within the project, as well as providing clear paths for contributors of all types to go from "involved" to "heavily involved" to "being a leader".

This page outlines a plan to reinvigorate the community governance system.

High-Level Outline

The plan involves the following steps:

1. Survey the project and make a list of areas of activity or code which make sense as an ownable "unit"
2. Decide who is the right person or persons to own each area (the 'module owner')
3. Each module owner appoints assistants ('peers'), if they feel they need them
4. Keep a close eye on new initiatives and make sure that modules are created for them

In parallel with all that, we need to work out what the best mechanism is for storing, updating and accessing the "who's in charge of what" information. Is the current template-based wiki system adequate, or will it groan under the strain of 4x as much data, and things will end up being hard to find? Can we use mozillians.org, or is there not sufficient scope for metadata there yet?

Survey The Project

The first task is to take stock of the project and its activities, and try and split it up into sensibly-sized, ownable chunks. This might be best done by a single person, who would consult with senior project figures in the various areas.

As part of this process, we need to work out what the right "shape" is for the governance system. Is it a big flat list of modules? Something hierarchical? Or something in between? At the moment, the list is fairly flat but there are some modules, such as Firefox and Thunderbird, which oversee other modules. So there is a hierarchy, but it's pretty flat. We should consult the community on this question.

The resulting structure may have some semblance to the MoCo org chart, or it may not. There is certainly no requirement that it does; MoCo may decide that their security employees are best managed in e.g. two teams, but we may end up with e.g. four security-related modules, one of which cuts across the two teams. While looking for the wisdom behind MoCo organizational decisions, we should not consider them as normative.

Also, we should confirm we still have the right terminology. This page, for convenience, uses the terms "Module Owner" and "Peer" - is that still the best way to refer to these leadership roles?

Appoint Module Owners

Through some form of public discussion, we appoint an owner for each identified area. It may be that Brendan, Mitchell and/or the current Module Ownership team make a list of nominations which are then discussed, or the process may be somewhat different. This is very much undefined at the moment. I would expect most appointments to be uncontroversial; the fact that the project currently runs pretty smoothly means that in most areas, there is a clear owner, even if that is not officially recorded.

There is a risk here of upsetting people; we need to manage the process very carefully with that in mind.

It may be that parts of the new system look very much like the old one. That's OK; this is not some secret plot to depose existing module owners. But I would suggest that old owners are not automatically grandfathered; while we are here, it's a good opportunity to sanity-check existing ownerships, both in terms of whether a person is the right person, and also in terms of individual workload.

It's OK, in the beginning, not to have an owner for a module - not finding one is a useful flag to us that an activity or piece of code is unowned. It's much better to have an unowned module than a system where a module doesn't exist at all if no-one could be found to own it.

Appoint Peers

Each module owner should then, taking whatever counsel they see fit, appoint a number of peers to help them in their work. This process does not have to be public.

Module owners should be actively encouraged to seek peers, both to increase the bus factor for their module, and also to provide opportunities for growth for community members. While there will be no affirmative action, it would be great if all or most modules had at least one non-employed peer.

Keep It Current

We need to build the governance system much more into the daily life of the project. So the list of module owners should be the first port of call whenever anyone asks "Who's the person to contact about X?", and there should be complaints if it isn't up to date. When we start something new, creating a module for it should be an early step in the process.

If there is some sort of hierarchy to the new system, owners of "super-modules" can be made responsible for making sure that appropriate "sub-modules" are created when new initiatives start in their area of responsibility.

Ideas are welcome as to how to make this more likely than simply having good intentions :-).