For those who are interested in Mozilla govenance, I’ve proposed an Activities Module for ownership of key Mozilla policies. The proposal is in the mozilla.governance newsgroup, which can also be accessed via Google Groups.
Posts Tagged with “modules”
January 7th, 2009
May 30th, 2008
At the end of March I made a proposal about updating the way we manage the health of our module ownership system. I’m happy so say that the proposal has now been implemented. Specifically this means:
1. We now have official modules — currently known as Activities Modules — for non-coding activities.
2. We now have a Governance module (owner: Mitchell Baker).
3. We now have a sub-module of Governance for Module Ownership (owner: Brendan Eich).
4. We now have an official Planet Mozilla module (owner: Asa Dotzler).
5. The long-standing web page listing module owners for code modules has been undated to also point people to the Activities modules.
6. The Activities modules are described and listed on wiki.mozilla.org.
7. The policy governing module ownership has been updated to reflect the creation of the Module Ownership module.
Thanks to everyone involved, and special thanks to Mike Connor for jumping up and down until I got this underway.
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.
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.
March 26th, 2008
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.
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.
Comments welcome here. If you’re interested in the full discussion, head over to the mozilla.org Governance newsgroup. You can also read a set of past comments and participate through the mozilla.governance Google Group.
June 13th, 2007
In the days before the Mozilla Foundation existed, the Mozilla project was originally managed by a group known as “mozilla.org staff.” Mozilla.org staff was a virtual organization which governed the Mozilla project in general, and did so increasingly unrelated to any employment relationship. Mozilla.org staff managed the project’s day to day activities, and held responsibility for basic technology and policy decisions. Today, some of these functions live in the Foundation — stewardship of the assets, and release of products using the Mozilla name, as examples. So the old model of mozilla.org staff cannot continue unchanged in the world of the Foundation.
Nevertheless, we need a mechanism to address governance issues that are broader than any particular product or project issue. More specifically, we should identify the key activities of the Mozilla project, identify the decision-makers, define the scope of their authority and the criteria by which they are designated.
In the past I’ve thought of trying to modernize or reconstruct a group like mozilla.org staff — a group that would have a set of project-wide responsibilities and obligations. I’ve made several attempts at this. It sounds good in theory, but in reality turned out to be very messy. In the days of mozilla.org staff, there was no Foundation. Trying to create another group in the Mozilla world with another set of responsibilities that would overlap with, or maybe be governed by the Foundation’s Board where required by law, or maybe govern or direct the Board is very complex. And the idea of doing this in a way that people can understand and remember is even more difficult. I’ve stumbled at the effort a couple of times now and find the task pretty daunting.
So I have a new idea that is much more simple. I’m indebted to Mike Connor, who suggested something like it in a newsgroup posting a while back. (Needless to say, if you hate the idea, please leave mconnor out of it )
My new idea is to identify the roles that mozilla.org staff used to play and make modules for these roles. We might have a “governance” set of modules, or a governance module with sub-modules. We’re in the process of creating modules for non-code topics anyway and so we could use a single type of mechanism for code, non-code and governance activities. We would determine governance related activities as well as activities the Mozilla Foundation now handles directly, like management of trademarks. We’d identify a module owner. We would also identify someone (a Peer, or a member) with an acknowledged voice in the Mozilla Foundation. We could do something like arranging for owners, peers or members for these modules to meet periodically with a Foundation representative. In any case, we would develop a mechanism for notifying the Foundation when an important issue has become contentious enough that escalation beyond the module owner is warranted. I’m not sure about the right mechanism here, but am pretty confident we can figure out something workable.
This path means the activities for which mozilla.org staff used to have authority are identified, we are clear about which have become Foundation / Corporation activities and which, if any, are related to employment. We have owners and a way for differing opinions to be expressed.
I like this approach because it allows us to address these issues within a structure and process that is already understood. It requires giving up some of the emotional attachment of a separate mozilla.org staff. I think this is manageable; keeping everything from our past intact will drag us into paralysis. And this offers a good chance of having a working process.