Proposal re Module Owners System
Mitchell Baker
for a give-and-take discussion, so I'm posting the full text here as well.
Mitchell
+++
The Module Owner System
The module owner system is at the heart of how we manage ourselves.
We’ve used this system for coding activities for many years, and I’ve
got an open bug for extending this to cover non-coding activities as
well. We have an identified set of modules, module owners and a policy
document describing the responsibilities and authority of a module
owner. (In brief, we divide our code into logical chunks called modules.
A person with a good reputation for the area covered by a module is
tapped to become the module owner, and he or she is responsible for that
module.)
We also have a final decision-maker for conflicts among module owners or
issues with a particular module owner; that decision maker is Brendan
Eich. Brendan has been doing this since 1998. For those not familiar
with Mozilla, our basic rule has been that Brendan is the ultimate
decision-maker for technical matters within the Mozilla project, and I
am the ultimate decision-maker for other issues. We each try to use that
authority only when necessary– when the people involved in the daily
activities get stuck, or there is disagreement or some other problem
that requires a decision. This is not weakness. It stems from the
realization that Mozilla succeeds because many people make decisions,
find ways to solve problems, and provide leadership. It is more
effective in the long run for us when a group of peers solves a problem
together. Distributed authority is the norm. Overuse of a central, final
decision-making power will not make Mozilla healthy.
So we have a system that works well for us on a daily basis and we have
an ultimate decision-maker for settings where we need one. But what we
don’t have today is a group of people with responsibility for the health
of the module ownership system. These topics include:
* Filling vacant roles where appropriate;
* Ensuring module owners are fulfilling their responsibilities, and
replacing those who are not;
* Creating and staffing new modules as new parts of the project evolve;
* Figuring out what to do if a module isn’t getting enough attention;
* Resolving conflicts among module owners.
I propose we create such a group. More precisely, I propose that we
create this group as a module within the module owner system. I’ve put
the details of how I think this module would be organized and operate in
a subsequent post. First I want to address the functions of the group
and why I believe it’s important. Then we can turn to whether the
precise structure I’m proposing makes sense.
Responsibilities of the Proposed Group
There should not be a giant amount of work to do on a daily basis. Over
the years David Baron and Brendan have periodically updated the list of
module owners. Last year Stuart took on and completed a review and
updating of our modules, which was overdue. These things should happen
periodically. Occasionally there is a question of whether a particular
module owner is still active enough to be a module owner, or we need to
identify new module owners. Every so often there are questions about a
module owner’s work. We should look at whether the policy document
governing modules and module owners should be updated. We might want to
think about better ways to handle modules that are under-owned, or where
someone is module owner out of a sense of civic duty rather than an
inherent interest in the module. One part of the role will probably be
providing advice as we extend the module owners system to non-coding
activities. So I don’t envision this group having a giant amount of work
on a daily basis. There will be some periods of focused activity.
If there isn’t a huge amount of work, why do I think it is worth
formalizing a group of people to do it? Several reasons.
* The work is really important. Module owners have a high degree of
authority. This is part of ensuring our vitality as a project, and
ensuring we have clear roles based on merit, reputation and general
acclaim. We will be stronger when we have a group of people proactively
thinking about the module system and working though some of the issues
listed above.
* It’s important to build a group of people who are knowledgeable and
experienced in governing important areas of our project such as the
module ownership system. Even if Brendan and I were quick and perfect in
all our decisions (which we most certainly are not) having only one or
two people involved in making decisions is a weakness in our system.
More people with experience is better.
* We’re bound to have some conflicts, that’s how life is. Having a group
of people who have been working through issues in calm times is very
helpful when something comes up and tensions rise.
* The clearer the system is the easier it will be to extend it to new,
non-coding activities.
Criteria
Members of this group should be module owners (of either coding or
non-coding activities). In addition they should have:
* Interest in how we govern ourselves. Ideally, a person has previously
demonstrated this interest by some set of activities. Someone could be a
great module owner but still poorly suited for this role;
* Appropriate understanding of Mozilla activities as a whole and the
“pulse” of a good chunk of the project;
* A good feel for whether suggestions, comments, and complaints are
broadly applicable or represent an unusual viewpoint;
* Interest and ability to help others accomplish things. This is
probably more important than what one can accomplish oneself for this role;
* Ability to balance varying perspectives and needs;
* Internal understanding of the value of non-coding activities to the
Mozilla project.
Structure of the Group
I propose we create this group as a module and use the module ownership
system as the basic governance. That way we’ll have a module owner,
peers and a way of interacting that we understand. I will put a more
precise description of how I think this will work in the module owner
system in a follow up post, mostly because I think it will be helpful to
separate the mechanics of how this might work from the discussion of
whether such a group is valuable in the first place.
Deb Richardson
wrote:
> I posted this in my blog as well, but this seems the most natural place
> for a give-and-take discussion, so I'm posting the full text here as well.
>
> Mitchell
>
>
> +++
>
> The Module Owner System
>
[snipped]
Hi,
I think that this is a great idea that feels very much in the spirit of the
project as a whole, with the added bonus of giving us a way to get some of
this internalized knowledge out to a larger group. The project is
increasingly big and complex, and I think the addition of this group is a
sensible way to scale up a bit without getting too committee-bound and
formal. Assuming, of course, the right people get involved. That could be
the tricky part.
~ deb