Part 2 of Proposal re Module Owners System
Mitchell Baker
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.
Thoughts?
Mitchell
Mike Beltzner
> 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.
This makes a lot of sense to me. There are many arms within Mozilla
community governance. Off the top of my head I can think of, and some
of these might be wrong:
- Module Ownership
- Security Group Membership
- Certificate Authentication Policy
- Trademark / Logo use (for marks & logos maintained by mozilla.org)
- MPL and Licensing?
> 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 also find that this encourages mentorship and teaching within the
community by growing the breadth of the pool of qualified and educated
leaders. It also makes us more agile in that we're not as gated on one
or two people before being able to move forward.
>
cheers,
mike
Robert Kaiser
> 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.
This surely makes sense. Perhaps we can one time have a dynamic list
somewhere that can show sub-modules. We also have such a hierarchical
sub-module structure in SeaMonkey, calling them "project areas" there.
Robert Kaiser
Mitchell Baker
This is great, it means a bunch more people have been working with
submodules.
And yes, we need a list of sub-modules. Actually, we'll need a list of
all non-code modules, with sub-modules if they exist. I think I have an
open bug on figuring our whether only the non-coding modules should be
on a wiki, or whether our current auto-generation technique for code
modules should also be replaced with a wiki or other method, either
because the auto-generation technique is (a) awkward, or (b) not
necessarily going to work with new repositories and therefore won't be
complete even for code (I don't know if this will be the case, but it's
been raised); or (c) easy for code, is it better to have all module
owners listed in the same place.
It's not a new bug, I'm a bit embarrassed to say, but I'm finally able
to carve out a bit of time to turn to this.
Mitchell
Robert Kaiser
> Robert Kaiser wrote:
>> We also have such a hierarchical
>> sub-module structure in SeaMonkey, calling them "project areas" there.
>
> submodules.
BTW, http://www.seamonkey-project.org/dev/project-areas is what we
currently have in SeaMonkey. It's more than just one level of
sub-modules, and it probably should be looked at again (it's dating back
almost 3 years, shortly after the start of the project), but it gives
you an impression of how we're doing it.
Robert Kaiser