Modules for "mozilla.org staff "Activities
Mitchell Baker
newsgroups for discussions.
mitchell
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 realated activites 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.
Thoughts more than welcome. Once again, I'm posting this in the
governance newsgroup (available via <a
href="http://www.mozilla.org/community/developer-forums.html">newsreader
or mailing list</a>, or via the <a
href="http://groups.google.com/group/mozilla.governance/topics">browser</a>).
fantasai
used to perform sounds like a good idea. What I'm not sure of anymore,
though, is who's in charge of things that fall through the cracks?
Things like ownership changes/disputes/whatever, communication meltdowns,
the newsgroup reorg, switching the development focus to FF/TB, retiring
the suite, accepting new projects: these would all fall to the multi-
talented and cross-disciplinary st...@mozilla.org team, which no longer
exists. I'm not convinced creating a "new/dead project module owner",
a "communications system organization module owner", and a "module
ownership issues module owner" makes sense, or that this method would
cover all the bases. Escalating such things to the Mozilla Foundation
Board of Directors certainly makes no sense; it's too far removed from
the project.
Back when it was functional, staff@ was the ultimate authority in the
Mozilla project: they owned the project as a whole, they were ultimately
responsible for everything. As the project matured, more and more of
their day-to-day responsibilities got delegated to other roles, other
people. This, I think is a good thing, and we should continue the trend.
But staff@, afaict, slowly dissolved when it got overloaded after the
Foundation was formed, and maybe I missed the announcement, but there's
no group to replace it. You're kinda handling all the organizational
issues, and brendan is heading the technical side, but the strengths of
staff@, imho, were that it was a small, farsighted team dedicated only
to the good of the project, that it included a broader range of skills
and perspectives, and that it included people representing many different
aspects of the project and multiple employers. These days most things run
a lot more smoothly, especially due to the Corporation and its dedicated
staff, and Gerv's doing a fantastic job of handling things similar to the
newsgroup reorg via discussion and consensus, but I'm wondering what
happens when we run into a problem? Who has final say in making major
decisions? Is MozCorp's upper management the new staff@?
~fantasai
Frank Hecker
> Module ownership for specific day-to-day activities mozilla.org staff
> used to perform sounds like a good idea. What I'm not sure of anymore,
> though, is who's in charge of things that fall through the cracks?
> Things like ownership changes/disputes/whatever, communication meltdowns,
> the newsgroup reorg, switching the development focus to FF/TB, retiring
> the suite, accepting new projects:
> Escalating such things to the Mozilla Foundation
> Board of Directors certainly makes no sense; it's too far removed from
> the project.
You raise a good point worth commenting on; here are my personal
opinions on it (I'm not claiming to speak for the Foundation here):
First, I think there are two separate questions here: How do we ensure
that "unowned" problems get proper attention (particularly issues that
are project wide), and who makes the final decisions on how to resolve
such problems.
On the second question, the legal reality is that the Mozilla Foundation
board is the ultimate authority on a large class of decisions having to
do with the project. This obviously includes issues like what to do with
Foundation-owned trademarks, but from a legal point of view at least
could extend even wider. For example, given that the Foundation operates
the official Mozilla source repositories, one could also argue that the
board also has ultimate jurisdiction over decisions about code module
ownership and the like that at least indirectly determine what code goes
into those repositories.
The board may choose to delegate decision making authority to others,
e.g., to the Corporation board and management, to the Foundation
executive director, etc., but for that large class of decisions there is
not and cannot be any ultimate authority other than the Foundation
board. That's in the end why I think the idea of reviving mozilla.org
staff in its traditional form is not sustainable.
As for the Foundation board being "too far removed from the project" to
deal with issues like "ownership changes/disputes/whatever,
communication meltdowns, the newsgroup reorg, switching the development
focus to FF/TB, retiring the suite, accepting new projects", etc., I can
tell you that during my time with the Foundation all the Foundation
board members have been actively and intelligently involved in strategic
questions of similar nature and importance to the project. This includes
not just discussing issues in board meetings but also going out to
project contributors and directly getting their opinions and advice.
So from my perspective the approach to decision-making outlined by
Mitchell makes sense: identify particular areas where decisions need to
be made in terms of project governance, and a person or persons for each
area to make those decisions. For that (IMO fairly large) class of
decisions where the Foundation board has ultimate authority the board
would in essence be delegating those decisions to others, subject to
oversight by the board itself or by other persons empowered by the board.
As to the first question (how do we ensure that problems get proper
attention and don't fall through the cracks), I think there are multiple
ways to address that. (Some of them are redundant, but that's not
necessarily bad.) For example, a group of people with "a broader range
of skills and perspectives, and ... representing many different aspects
of the project and multiple employers" could be established as a board
of advisors for the project, reporting to the Foundation board directly
or indirectly and meeting with the board and/or with Foundation and
Corporation representatives on a regular basis. One straightforward
approach would be to select this group from the list of module owners
(considered broadly, i.e., including code, non-code, and governance areas).
At the same time we'll also have forums like this one to allow any
project contributor to propose issues for discussion and make their
views known. And to the extent we can achieve at least rough consensus
in forums like this we won't have to rely on some formal body to get
involved and render judgments.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Mitchell Baker
These are great comments. (And beautifully written too; ; something I
admire as I know how hard it is to write well.) Frank's response i s
pretty close to what I would say. But I feel compelled to answer
directly as well, so here goes!
I share the feeling that a system of individual module owners may lack
something about the "overall view" that mozilla.org staff maintained. I
think that's why I tried for so long to figure out a way to reconstruct
it. But it's tough, in part for the reasons Frank outlined in his
response.
And I also agree with you that the Board is not the likely place for
decisions -- even many policy decisions -- that affect daily operations.
It is really hard -- maybe impossible -- to make rational decisions
about - say, the scope of super-review, as it is on my mind these days
-- without being pretty directly involved in how developers are working.
I feel a bit removed to be doing this, and I'm a lot closer to daily
operations than most board members.
I'm not yet sure of the complete answer here. I'm pretty sure that
having module owners is a start, and a big piece of the overall
solution. For example, we might identify a set of module owners who
together cover broad scope of the project, and have some ways for them
to both get input from the various constituencies of the community and
give input to the board. Frank made a similar suggestion.
Bottom line: great issues. I agree with your sense that something of
the past isn't quite there. I believe we need to start by creating the
elements we understand how to make work and build from there. Please
keep sending suggestions out and help us get there.
mitchell
Gervase Markham
> As to the first question (how do we ensure that problems get proper
> attention and don't fall through the cracks), I think there are multiple
> ways to address that. (Some of them are redundant, but that's not
> necessarily bad.) For example, a group of people with "a broader range
> of skills and perspectives, and ... representing many different aspects
> of the project and multiple employers" could be established as a board
> of advisors for the project, reporting to the Foundation board directly
> or indirectly and meeting with the board and/or with Foundation and
> Corporation representatives on a regular basis.
Like Frank, speaking for myself rather than as a Foundation employee):
why is this group not the board itself? Is there a rule to say that
boards have to be small, distant, composed of people busy with other
things and meet only four times a year? (Not that this necessarily
characterises our own board; I exaggerate for effect.)
Gerv
Gervase Markham
> The board may choose to delegate decision making authority to others,
> e.g., to the Corporation board and management, to the Foundation
> executive director, etc., but for that large class of decisions there is
> not and cannot be any ultimate authority other than the Foundation
> board. That's in the end why I think the idea of reviving mozilla.org
> staff in its traditional form is not sustainable.
I think that's a non-sequitur. Arguing against myself in my other post,
perhaps (but we're all brainstorming here): why could staff not exist
simply by the Foundation board delegating to it all the roles that it
traditionally had?
The Board may not wish to delegate some parts of its original role, of
course. But I don't think we can argue that "staff can't exist because
it could never have the ultimate authority it had". The value of staff
we are percieving is their ability to look at the broad picture and make
decisions (due to its unique makeup) in certain areas, not the fact that
it was also the ultimate authority.
Gerv
Mike Connor
As rare as this might seem, I agree 100% here. I don't think that
staff would
be the ultimate authority, the board would have the power to appoint
or remove
individuals from staff, or override decisions if necessary. With
that said, I do
not believe that the board is the right group to directly manage
mozilla.org's
day to day activities, nor should it be the right group. I'm not
even sure that
I believe the Foundation is equivalent in my mind to mozilla.org.
I believe, quite strongly, that staff should be rebuilt as a group of
key module
owners, nominated and voted on by the module owners and approved by the
board. The goal is to ensure that we have a strong, community-based
group
of leaders who have the ability to directly lead and influence the
project. These
leaders would have the moral authority to act in disputes, to
represent the project
as a whole, and to work with the board as delegates of the
community. The
board should continue to provide oversight and guidance, but there
needs to be
a group from the community that drives the community.
-- Mike
Frank Hecker
> Like Frank, speaking for myself rather than as a Foundation employee):
> why is this group not the board itself? Is there a rule to say that
> boards have to be small, distant, composed of people busy with other
> things and meet only four times a year? (Not that this necessarily
> characterises our own board; I exaggerate for effect.)
Just in case anyone was curious about this, the Mozilla Foundation board
holds scheduled board meetings once per month (typically via
teleconference); IIRC we've had quorums for all (or almost all) the
meetings held since I joined the Foundation.
Frank
--
Frank Hecker
hec...@mozilla.org
Frank Hecker
Gervase Markham wrote:
> Arguing against myself in my other post,
> perhaps (but we're all brainstorming here): why could staff not exist
> simply by the Foundation board delegating to it all the roles that it
> traditionally had?
IANAL, but from a legal point of view I think the board could indeed
delegate whatever powers it wished to, to whomever it wished to do so.
See section 3.1 of the Mozilla Foundation bylaws. The question is, where
might such delegation actually make sense from a non-legal point of
view, given the realities of how the project and its associated formal
organizations (i.e., the Foundation and the Corporation) are currently
organized?
> The Board may not wish to delegate some parts of its original role, of
> course. But I don't think we can argue that "staff can't exist because
> it could never have the ultimate authority it had".
But part of the definition of "staff" was that it was in fact the
ultimate authority, at least for some reasonable definition of
"ultimate" and "authority". I'm not claiming that we couldn't constitute
some body that would fill some of the roles that staff had; I'm simply
saying that it's potentially confusing to either refer to such a body as
"staff" or to treat it as a simple continuation of what "staff"
previously was.
> The value of staff
> we are percieving is their ability to look at the broad picture and make
> decisions (due to its unique makeup) in certain areas, not the fact that
> it was also the ultimate authority.
I agree that having this "broad picture" view is important; that's why I
proposed having a body of people that is both representative of the
project and has sufficient moral authority to lent credibility to its
advice (e.g., as provided to the Foundation board) and its decisions
(for those areas where the board might delegate authority to the group).
I think the best way to achieve that representation and authority is to
have the body be composed of (a subset of) module owners ("broadly"
defined).
Frank Hecker
not speaking for the Foundation or its board.)
Mike Connor wrote:
> As rare as this might seem, I agree 100% here.
Noted for the record :-)
> I don't think that staff would be the ultimate authority, the board
> would have the power to appoint or remove individuals from staff, or
> override decisions if necessary. With that said, I do not believe that
> the board is the right group to directly manage mozilla.org's day to day
> activities, nor should it be the right group.
I agree that it is not the place of the board to directly manage
day-to-day activities within the Mozilla project. The board has to
delegate to some set of people and/or organizations. The hard part is
what to delegate and to whom.
> I'm not even sure that I believe the Foundation is equivalent in my mind
> to mozilla.org.
This is an interesting question IMO, especially if like me you are
interested in questions about how formal and informal authority
interact, and how organizations acquire political legitimacy among the
people subject to their decisions. Maybe no one else is interested in
this topic, but I thought it worth taking a brief detour to discuss it.
mozilla.org was originally conceived as "the virtual organization
through which the activities of the community are organized", with
staff, module owners, super-reviewers, etc., being conceived of as roles
within that virtual organization. Although it didn't have formal
authority in the legal sense, the people participating in the
mozilla.org virtual organization had informal authority, and the
allocation of authority among the various roles within the virtual
organization (including the role of staff as the ultimate "deciders")
was accepted as legitimate by the people affected by their decisions.
When the Mozilla Foundation was formed in 2003 one can argue that at
least the authority previously exercised by staff was now transferred to
and legitimately exercised by the Foundation, given that everyone active
on staff at the time ended up either on the Foundation board (Mitchell,
Brendan, Chris Blizzard) or working for the Foundation (e.g., Asa, Gerv,
Myk). This transfer was a bit ambiguous in a way, since it depended more
on people's personal informally accruing to the Foundation, as opposed
to having authority being explicitly transferred to the Foundation
(e.g., through having the Foundation be a member-based organization with
an elected board).
However in practice, and given history since the Foundation was formed,
I think one can argue that the Foundation as an organization, and in
particular the Foundation board, legitimately exercises the authority
once exercised by mozilla.org staff as "ultimate deciders" and "court of
last resort". (If there are remaining questions about such legitimacy, I
think they would be best addressed by tweaks to the Foundation's
organizational structure, e.g., providing for explicit community
representation on the board.)
At the same time, the mozilla.org roles of module owner, super-reviewer,
etc., remained outside the scope of the Foundation proper, given that
there were, are, and (I hope) always will be) people performing those
roles who are not associated in any way with the Foundation.
So, to answer the question you implicitly posed: no, the Foundation is
not equivalent to "mozilla.org" in its original broad sense
(encompassing staff, module owners, super-reviewers, etc.), although in
terms of authority and legitimacy it is IMO the inheritor of mozilla.org
staff specifically.
> I believe, quite strongly, that staff should be rebuilt as a group of
> key module owners, nominated and voted on by the module owners and
> approved by the board. The goal is to ensure that we have a strong,
> community-based group of leaders who have the ability to directly lead
> and influence the project. These leaders would have the moral authority
> to act in disputes, to represent the project as a whole, and to work
> with the board as delegates of the community. The board should
> continue to provide oversight and guidance, but there needs to be a
> group from the community that drives the community.
I don't disagree with you, but as always, the devil is in the details.
The Foundation board has already delegated a significant amount of
decision-making authority, in particular to the Mozilla Corporation. The
question then is, what exactly gets delegated to this new group? The
group is not going to be a literal recreation of staff, because certain
decisions have already been reserved to others. It could presumably be
delegated some authority over day-to-day decisions like mediating
disputes among module owners, and could also provide advice to the
Foundation board on behalf of project participants. It's an open
question as to what other functions could reasonably be transferred to
such a group.
I also agree that having this group be composed of "key module owners,
nominated and voted on by the module owners" is worthwhile. But again,
how do we define "module owners" here, and in particular do we include
"non-code module owners" in the sense Mitchell has discussed? For
example, suppose we decide that there will be "module owners" for
Firefox PR, or for trademark issues, or for representing the project at
trade shows and conferences, or whatever; do those people get to vote
for or serve as members of this new body, and then make decisions about,
say, resolving disputes among module owners for the Foo and Bar
components of Firefox?
Mike Connor
On 19-Jun-07, at 10:05 AM, Frank Hecker wrote:
>> I'm not even sure that I believe the Foundation is equivalent in
>> my mind
>> to mozilla.org.
>
> This is an interesting question IMO, especially if like me you are
> interested in questions about how formal and informal authority
> interact, and how organizations acquire political legitimacy among the
> people subject to their decisions. Maybe no one else is interested in
> this topic, but I thought it worth taking a brief detour to discuss
> it.
I'm actually quite interested (more than I would actually expect). I
think the idea of having an independent board is critical for
oversight, especially given the resources in play, but at the same
time, I wonder if the Foundation should have inherited final
authority. If the module owners are in conflict with the board of
the Foundation, I think that the board lacks the moral authority to
override the module owners. The Foundation controls some key assets
(the MPL, the trademarks, etc) but we are a community organization,
and ultimately the community and those who exert leadership within
the project will set direction and make decisions. I can't imagine
the board making a decision to strip module ownership from an owner,
for example, but a group of key module owners would have that moral
and peer-based authority.
> When the Mozilla Foundation was formed in 2003 one can argue that at
> least the authority previously exercised by staff was now
> transferred to
> and legitimately exercised by the Foundation, given that everyone
> active
> on staff at the time ended up either on the Foundation board
> (Mitchell,
> Brendan, Chris Blizzard) or working for the Foundation (e.g., Asa,
> Gerv,
> Myk). This transfer was a bit ambiguous in a way, since it depended
> more
> on people's personal informally accruing to the Foundation, as opposed
> to having authority being explicitly transferred to the Foundation
> (e.g., through having the Foundation be a member-based organization
> with
> an elected board).
I think that's how it happened, but I believe it actually might be a
problem someday, if the community and the Foundation were to grow out
of sync.
The more I think on it, I actually think that mozilla.org staff,
constituted as a group elected from within the module owners (more on
this below) probably should override the Foundation board on anything
not explicitly related to the assets and the resources of the
Foundation. I don't think the Foundation board has the moral
authority to override module owners on anything involving day to day
operations. Mitchell and Brendan do have that moral authority, but
that is as module owners and long time leaders within the project,
not at all related to their status on the board.
> However in practice, and given history since the Foundation was
> formed,
> I think one can argue that the Foundation as an organization, and in
> particular the Foundation board, legitimately exercises the authority
> once exercised by mozilla.org staff as "ultimate deciders" and
> "court of
> last resort". (If there are remaining questions about such
> legitimacy, I
> think they would be best addressed by tweaks to the Foundation's
> organizational structure, e.g., providing for explicit community
> representation on the board.)
I think that the Foundation is a part of the whole, a key and
significant part of the whole, but more and more I see mozilla.org as
a collection of projects and companies collaborating around the
technology, with the Foundation playing a key role in providing
resources and leadership, but not a commanding one. Seamonkey,
Camino, and other projects operate generally outside of the authority
of the Foundation, but not outside of the sphere of authority of
mozilla.org.
> So, to answer the question you implicitly posed: no, the Foundation is
> not equivalent to "mozilla.org" in its original broad sense
> (encompassing staff, module owners, super-reviewers, etc.),
> although in
> terms of authority and legitimacy it is IMO the inheritor of
> mozilla.org
> staff specifically.
I now tend towards thinking that's something in need of correction.
Were I to resign tomorrow from MoCo, I would still be answerable to
the Foundation and the board as the Firefox module owner, unless I
left the project entirely. That feels like something that fosters an
us vs. them mentality (and I would argue that the perception exists
that anyone not in the Foundation hierarchy has less influence and
authority as a matter of fact). If a portion of the community were
then to fork Firefox and start a new browser project within
mozilla.org, would the Foundation have the authority to stop us? It
seems like you're saying they would, but that feels like something
that the community, not the Foundation, should decide.
>> I believe, quite strongly, that staff should be rebuilt as a group of
>> key module owners, nominated and voted on by the module owners and
>> approved by the board. The goal is to ensure that we have a strong,
>> community-based group of leaders who have the ability to directly
>> lead
>> and influence the project. These leaders would have the moral
>> authority
>> to act in disputes, to represent the project as a whole, and to work
>> with the board as delegates of the community. The board should
>> continue to provide oversight and guidance, but there needs to be a
>> group from the community that drives the community.
>
> I don't disagree with you, but as always, the devil is in the details.
> The Foundation board has already delegated a significant amount of
> decision-making authority, in particular to the Mozilla
> Corporation. The
> question then is, what exactly gets delegated to this new group? The
> group is not going to be a literal recreation of staff, because
> certain
> decisions have already been reserved to others. It could presumably be
> delegated some authority over day-to-day decisions like mediating
> disputes among module owners, and could also provide advice to the
> Foundation board on behalf of project participants. It's an open
> question as to what other functions could reasonably be transferred to
> such a group.
I think that some of the decision making power that MoCo has
exercised would transfer to staff (i.e. roadmap planning). We
(speaking as a MoCo employee now) have exercised power in a vacuum,
but I don't think that's ideal, and contributes to the us vs. them
mentality that's starting to surface more and more.
> I also agree that having this group be composed of "key module owners,
> nominated and voted on by the module owners" is worthwhile. But again,
> how do we define "module owners" here, and in particular do we include
> "non-code module owners" in the sense Mitchell has discussed? For
> example, suppose we decide that there will be "module owners" for
> Firefox PR, or for trademark issues, or for representing the
> project at
> trade shows and conferences, or whatever; do those people get to vote
> for or serve as members of this new body, and then make decisions
> about,
> say, resolving disputes among module owners for the Foo and Bar
> components of Firefox?
(This is why we only have one module owner for Firefox, remember? ;))
I promised more on this, so here goes:
* Non-technical parts of the project should absolutely have a voice
in day-to-day oversight. There are a number of non-technical people
beyond Mitchell who already have earned the respect of the community
who would make excellent staff members.
* I do not believe that one must be technically involved to help
mediate and resolve disputes between technical people.
* As with the original staff@, there will be people more and less
vocal on certain issues, but i don't think this will ever get heavily
technical (I still want some form of a technical oversight group for
this, even if its just staff convening an ad hoc group as needed from
technical module owners).
* I believe that module owners would naturally select people with the
abilities to lead the project, meritocracy breeds a healthy respect
for merit-based selection, IMHO.
-- Mike
fantasai
This group is not the board itself because as Mitchell and others have
noted, the board is too distant from the daily activities of the
organization to be effective in such a role. This does not mean the board
is useless; it has (obviously) many things to deal with for which the
current membership is probably more suitable.
~fantasai
Axel Hecht
Back in the old days, there was some communication forum
(st...@mozilla.org), in which consensus could grow. If that didn't
happen and a decision was required, either Mitchell or Brendan drew
straws. Or something like it.
Now we have .governance and .planning, in which consensus can grow. And
if it doesn't happen, Mitchell or Brendan will draw straws.
I don't necessarily care whether they do that as members of
st...@mozilla.org or the Foundation board.
Which leaves the question of whether the Mozilla community needs formal
control over Mitchell and Brendan. I don't think so. I personally see
planet.m.o as a good organ of raising issues, as are the newsgroups,
maybe to a lesser extent. It worked for the platform discussion, for
example.
Creating sub-groups that could do this or that sounds slightly backwards
and closed-discussion to me, and I'd rather not go there. Let alone
define a process to get there.
The question of whether the boards at large works as everybody expects
it to is a different and distinct question. I don't think that meeting
once a month and agreeing (as Frank pointed out) is the best bet. Not
that Mozilla Europe's board with not meeting nor agreeing and occasional
decisions is a much better example ;-)
Bottom line, I'd prefer more transparency on the boards to more process
and new decision groups, which, in the end, just bubble up to Mitchell
and Brendan again.
Axel
Gervase Markham
> This group is not the board itself because as Mitchell and others have
> noted, the board is too distant from the daily activities of the
> organization to be effective in such a role.
But are you saying that this is inherent in the nature of "a board", or
is this distance merely a function of the particular individuals who
currently make it up?
Gerv
Mitchell Baker
respond to both Axel comments below and mconnor’s post where he
describes why he thinks a staff group is valuable, and suggests we make
this out of module owners (that’s my summary, not his).
I’ll copy the last paragraph of this post here at the top, for those who
want the punchline more than the discussion:
But one thing does seem clear – having modules for governance topics is
a good start. So I propose to move forward on this. I’ll get started
as soon as I can, I have a bunch of things all seemingly critical, and
others are welcome to join in.
-
As Axel points out, we have always had the rule that if a technical
matter can’t be resolved by discussion and consensus building, then
Brendan is the ultimate decision maker. And similarly, if other
decisions can’t be resolved without escalation then I am the ultimate
decision-maker. We try not to get to that point very often, but every
so often we do reach this point.
(As an anecdotal aside, one of the early decisions I made was that the
name of our original product, which we released in 2002, was Mozilla
“1.0” to reflect its first ready for prime time release, and not Mozilla
“5.0” to match the user agent string. This was extremely contentious
decision at the time, and an early example that the Mozilla community
could hold together in the face of some emotionally volatile internal
disagreements.)
I agree with Axel that “governance” is a more open technique than we’ve
had in the past. At the same time, I think it might be helpful to have
identified groups of people to resolve issues. For example, maybe
module owners should deal with complaints about the behavior of module
owners, which do periodically arise. If a module owners group could
resolve this, it would seem to me better than having Brendan or I do so.
If the group couldn’t resolve a module owner problem (half feel the
owner is closed and not accepting patches, the other part feels the
patches are noise and the owner has spent more time than he or she
should dealing with them already), then Brendan or I could get involved.
I like this because distributed self-management is how we have a
strong community that can grow. The more issues that get resolved well
through such mechanisms, the better.
So I agree with Axel on moving towards more transparence, and will work
on this at the baord level. But I’d also like to have some way to
delegate authority for governance topics so that there is some known
status between a newsgroup discussion on the one hand and Brendan or I
on the other.
I don’t see how to do this by creating a mozilla.org staff – like group
and trying to define its sphere of authority / influence vis-à-vis other
groups. I probably disagree with mconnor here. But I notice he’s got
a lot of good ideas and he may get further on this than I have. All my
attempts to date have ended up with overly – complex diagrams of who has
authority for what, how they interact, and so on. Even I could barely
understand then, and most people to whom I showed them seemed politely
overwhelmed.
But one thing does seem clear – having modules for governance topics is
a good start. So I propose to move forward on this. I’ll get started
as soon as I can, I have a bunch of things all seemingly critical, and
others are welcome to join in.
Mitchell
fantasai
It is a function of the particular individuals who currently make it up. The only
members of the Board who I consider to also be members of mozilla.org are Mitchell
and Brendan. Without these two, the Board would, in my mind, have no legitimate
authority in the Mozilla Project besides ownership of its own money and the assets
donated by Netscape. To put Frank's legitimacy analysis on this, staff@ was the
ultimate authority in the Mozilla Project, and it was headed by Mitchell and Brendan.
When it dissolved Mitchell and Brendan assumed that authority, and they invested
it in the Mozilla Foundation Board.
The Board could have been created in the image of staff@, and then it would
have the same ability to respond to issues "on the ground". However, given
the current makeup of the Board, I think that was not the goal of its formation,
and that it has other things to focus on due to the creation of the Foundation:
things that staff@ didn't really focus on or even have to deal with at all, and
for which its current makeup might indeed be more optimized.
In my mind, the Mozilla Foundation Board has assumed the ultimate responsibility
for making sure this organization and this project works, but for getting work done
it has a supporting role, not a leadership one. Within the organization, it serves
mainly as advisory and oversight committee to mozilla.org. It doesn't get involved
much with day-to-day affairs except to make sure we have the resources and leadership
we need to function. Outside of that it doesn't meddle much, and imho it shouldn't.
It doesn't have the right people. What it does have the right people for is
representing Mozilla on more abstract and global scopes. The Board handles practical
negotiations on behalf of mozilla.org with outside parties like the Law, the IRS,
other Foundations, Corporations and educational Institutions. It gets involved with
policy at these levels, and it represents Mozilla's collective conscience on relevant
issues at the levels of Government, Business, Philosophy, and Time Magazine. Its
day-to-day role isn't to manage the project internally, it's to look out for our
interests outside it.
I don't see this as a problem. I trust that the Board is good at what it does, and
that what it does is important and necessary. But I wouldn't equate it with what
staff@ used to do; it is only a (much expanded) subset.
~fantasai
fantasai
> I'm having a more pragmatic thinking here.
>
> Back in the old days, there was some communication forum
> (st...@mozilla.org), in which consensus could grow. If that didn't
> happen and a decision was required, either Mitchell or Brendan drew
> straws. Or something like it.
>
> Now we have .governance and .planning, in which consensus can grow. And
> if it doesn't happen, Mitchell or Brendan will draw straws.
>
> I don't necessarily care whether they do that as members of
> st...@mozilla.org or the Foundation board.
>
> Which leaves the question of whether the Mozilla community needs formal
> control over Mitchell and Brendan. I don't think so. I personally see
> planet.m.o as a good organ of raising issues, as are the newsgroups,
> maybe to a lesser extent. It worked for the platform discussion, for
> example.
One question to think about is what happens if Mitchell or Brendan quits?
Dies in a car crash, or disappears in the Bermuda triangle? I hope that
doesn't happen, but I also do hope the project continues after Mitchell
and Brendan retire. The advantage of having a well-defined role and then
appointing someone to fill it is that you can find someone else to fill
the role. We can't appoint a 'successor to Mitchell' because Mitchell has
her own peculiar package of skills, knowledge, perspective, and talents,
and it's not likely we'll find the same package in anyone else. The
advantage of a group like staff@ is that it's a large collection of skills,
knowledge, perspectives, and talents and while people within it specialized
in one area or another, that specialization was fluid and dynamic. If gaps
needed filling, as happened when members left, the group rebalanced those
undefined roles within itself. A group authority role like staff@ is much
more capable of absorbing the loss of a person, even someone like Mitchell,
than a tailored individual authority role like Chief Lizard Wrangler.
> Creating sub-groups that could do this or that sounds slightly backwards
> and closed-discussion to me, and I'd rather not go there. Let alone
> define a process to get there.
The decision-making process nowadays is much more open than it was eight
years ago, with wide-open discussions and consensus-building taking the
place of various closed decision groups. Mozilla has made great progress
in this respect, and I don't want us to go backwards in our decision-making,
either. But I don't think it would be a step backward to replace Brendan
and Mitchell with a broader group in the role of chief arbiter and rubber
stamp of our open decision-making process. On the contrary I think this
would give us more balanced and broad-viewed decisions when things did
need to be passed up to a higher authority, and it would help ensure such
decisions accurately reflect the "will of mozilla.org" and not some
well-connected subset. It is much easier for one or two people's view of
the project to be skewed or incomplete than it is for a diverse group's
collective perception to be skewed or incomplete.
> Bottom line, I'd prefer more transparency on the boards to more process
> and new decision groups, which, in the end, just bubble up to Mitchell
> and Brendan again.
The difference between having staff@ with Mitchell and Brendan instead of
just Mitchell and Brendan is that most issues that bubble up get caught by
staff@, not just Mitchell or Brendan. The decision fell to Mitchell or
Brendan individually only if staff@ couldn't come up with a consensus within
itself--if after every member of staff@ had at least understood the others'
concerns, Brendan's position on a specific issue differed from every other
member of staff@, I would expect him to accept their position as staff@'s
official response despite his own well-articulated reservations.
~fantasai
fantasai
> Fantasi
>
> These are great comments. (And beautifully written too; ; something I
> admire as I know how hard it is to write well.)
Thanks~ I was a bit nervous about posting, but Gerv asked me to. I've thought
about this issue a lot.
> Frank's response is pretty close to what I would say. But I feel compelled
> to answer directly as well, so here goes!
Your answer is, actually, significantly different from Frank's, specifically
in how you perceive the Board's ability to fill staff@'s role.
> I share the feeling that a system of individual module owners may lack
> something about the "overall view" that mozilla.org staff maintained. I
> think that's why I tried for so long to figure out a way to reconstruct
> it. But it's tough, in part for the reasons Frank outlined in his
> response.
The problem might have been that it wasn't clear what hole your new concept
of staff@ was trying to fill. I think that's what we're starting to define
in this discussion here. This makes sense: there was a lot of reorganization
over the past few years, and our organizational structure hasn't been stable
until fairly recently.
> And I also agree with you that the Board is not the likely place for
> decisions -- even many policy decisions -- that affect daily operations.
> It is really hard -- maybe impossible -- to make rational decisions
> about - say, the scope of super-review, as it is on my mind these days
> -- without being pretty directly involved in how developers are working.
> I feel a bit removed to be doing this, and I'm a lot closer to daily
> operations than most board members.
>
> I'm not yet sure of the complete answer here. I'm pretty sure that
> having module owners is a start, and a big piece of the overall
> solution. For example, we might identify a set of module owners who
> together cover broad scope of the project, and have some ways for them
> to both get input from the various constituencies of the community and
> give input to the board. Frank made a similar suggestion.
I'm a bit skeptical about having "governance module owners", but as I don't
really understand what you have in mind, I can't much comment on that. What
I don't see is how breaking up staff@'s jobs into little pieces and assigning
a person to each one is going to recreate the advantages of a broad view of
the project and complete coverage of all possible issues that were inherent
in the structure of staff@. But maybe that's not what you have in mind at all.
Non-code modules make a lot of sense to me, but I'm having trouble imagining
what a "governance" module would be.
> Bottom line: great issues. I agree with your sense that something of
> the past isn't quite there. I believe we need to start by creating the
> elements we understand how to make work and build from there. Please
> keep sending suggestions out and help us get there.
I think I share mconnor's view in this discussion: I feel the same way about
the situation--the relationship of mozilla.org to MF and MozCorp--as what he
has articulated in his two posts. The only thing I don't agree with is that
members of staff@ should be drawn from the module owner pool. I disagree with
that.
I think the requirements for a staff member are best expressed in the
about/staff document:
"The fundamental requirement of each staff member is that he or she care
about the Mozilla project as a whole, separate from an interest in a
particular Mozilla-based product."
A module owner is chosen to be the module owner because that person is
deeply knowledgeable about that module. The module owner needs to be
aware of and sensitive to his module's interactions with other parts of
the project, but a broad view of the project as a whole is not necessary.
Therefore being a module owner is not sufficient qualification for being
a staff member.
There are a number of people in this project who are not module owners,
however, but who are deeply /and broadly/ involved with the project, have
internalized its values, and "care about the Mozilla project as a whole,
separate from an interest in a particular Mozilla-based product". Gervase
Markham, for example, is such a person and is/was, afaict, an exemplary
mozilla.org staff member. Therefore being a module owner is also not a
necessary qualification for being a staff member.
So while it's quite likely that a lot of the people we'd look to for that
kind of leadership would be module owners of one kind or another, module
ownership should not be a requirement.
~fantasai
Robert Kaiser
> One question to think about is what happens if Mitchell or Brendan quits?
> Dies in a car crash, or disappears in the Bermuda triangle? I hope that
> doesn't happen, but I also do hope the project continues after Mitchell
> and Brendan retire. The advantage of having a well-defined role and then
> appointing someone to fill it is that you can find someone else to fill
> the role.
Hmm, aren't their roles defined as something like "mom" and "dad" to the
project? ;-)
Well, replacing them is probably nearly as impossible as replacing mom
and dad - but sure we should be able to continue the project in case we
some time might leave them. But then, we also managed to continue the
project in some way when we lost Netscape, so I believe we (as a
project) can survive almost anything :)
Robert Kaiser
Mike Connor
Its not _the_ qualification, to be sure, and the fundamental
requirement about caring about the project as a whole should remain
in place. Its an important indication of that individual's ability
to lead and make decisions, and in this community, I think its
essential to already be established.
> There are a number of people in this project who are not module
> owners,
> however, but who are deeply /and broadly/ involved with the
> project, have
> internalized its values, and "care about the Mozilla project as a
> whole,
> separate from an interest in a particular Mozilla-based product".
> Gervase
> Markham, for example, is such a person and is/was, afaict, an
> exemplary
> mozilla.org staff member. Therefore being a module owner is also not a
> necessary qualification for being a staff member.
Of course, in the proposed set of non-code modules, Gerv is a module
owner for CA issues, reflecting the contributions he is already
making, and the leadership within that area that he has already been
exercising. I think that there's a longstanding mismatch between
code and non-code areas, but afaict the non-code members of staff
have been leaders in other areas, module owners of a sort in all but
name.
> So while it's quite likely that a lot of the people we'd look to
> for that
> kind of leadership would be module owners of one kind or another,
> module
> ownership should not be a requirement.
As I noted, I think that Gerv's contributions have generally been on
the non-technical side, where we have not historically had any sort
of module ownership. Once there are modules and owners for non-code
areas, I think that this argument becomes far less compelling. There
is a clear progression in building the moral authority to lead, and I
believe that becoming a module owner is a critical step in gaining
the respect and trust of your peers. If one is not already
exercising day to day leadership within a smaller area, it is very
difficult to imagine effectively exercising leadership on a much
greater scope. Mozilla is a meritocracy, and skipping the module
owner step would not play well within the established community
hierarchy, especially if staff is exercising the role of oversight
for module owners. I don't think that would result in a situation
any better than that of having the board oversee decisions.
-- Mike
fantasai
>
> On 7-Jul-07, at 4:14 AM, fantasai wrote:
>
>> I think the requirements for a staff member are best expressed in the
>> about/staff document:
>> "The fundamental requirement of each staff member is that he or she
>> care
>> about the Mozilla project as a whole, separate from an interest in a
>> particular Mozilla-based product."
>>
>> A module owner is chosen to be the module owner because that person is
>> deeply knowledgeable about that module. The module owner needs to be
>> aware of and sensitive to his module's interactions with other parts of
>> the project, but a broad view of the project as a whole is not necessary.
>> Therefore being a module owner is not sufficient qualification for being
>> a staff member.
>
> Its not _the_ qualification, to be sure, and the fundamental requirement
> about caring about the project as a whole should remain in place. Its
> an important indication of that individual's ability to lead and make
> decisions, and in this community, I think its essential to already be
> established.
I agree with this. It should also be an essential requirement to already
be established as a leader in the community. E.g. simply getting hired by
MozCorp as a manager or MF as a community liaison should not be enough. But
while module ownership is a strong and clear indicator of an individual's
leadership ability and establishment within the community, it's not the
only one.
>> There are a number of people in this project who are not module owners,
>> however, but who are deeply /and broadly/ involved with the project, have
>> internalized its values, and "care about the Mozilla project as a whole,
>> separate from an interest in a particular Mozilla-based product". Gervase
>> Markham, for example, is such a person and is/was, afaict, an exemplary
>> mozilla.org staff member. Therefore being a module owner is also not a
>> necessary qualification for being a staff member.
>
> Of course, in the proposed set of non-code modules, Gerv is a module
> owner for CA issues, reflecting the contributions he is already making,
> and the leadership within that area that he has already been
> exercising. I think that there's a longstanding mismatch between code
> and non-code areas, but afaict the non-code members of staff have been
> leaders in other areas, module owners of a sort in all but name.
Yes, but Gerv would be qualified even if he weren't the CA module owner.
He exercises leadership in the community in other ways, and is very
effective at taking ownership of transient, globally-scoped projects such
as the newsgroup reorganization and the bugzilla components reorganization.
I think we should expect that most members of staff@ would be module owners
of some kind, especially now that we have non-code modules, but we shouldn't
close the door to someone who has, in the mind of the community and its module
owners, already built up the moral authority to lead but hasn't done so
through the module ownership system.
~fantasai
Mike Connor
Such an individual may be able to lead, and hold the appropriate
moral authority, though I'm not sure that they'd be the right person
for staff@ depending on the overall mission of staff. I have some
ideas on this that I need to write, maybe while I'm flying Monday.
-- Mike
Gervase Markham
> As I noted, I think that Gerv's contributions have generally been on the
> non-technical side, where we have not historically had any sort of
> module ownership.
'Twas not always the case (I got into the project via QA, and did write
UI patches during the period when it was practically impossible to
improve the product UI due to process issues) but, for better or for
worse, it's true at the moment. I'd like to spend more time writing
code, but other things get in the way :-(
> Mozilla is a
> meritocracy, and skipping the module owner step would not play well
> within the established community hierarchy, especially if staff is
> exercising the role of oversight for module owners.
Leaving aside the value or otherwise of your argument as a whole, this
particular part is fallacious because it begs the question. Your point
already assumes that there is a hierarchy with staff above module
owners, and one progresses "up the ladder" - and therefore going
straight from ordinary member to staff member is "skipping the module
owner step". But that's precisely the point under discussion.
fantasai is arguing for appointment of module owners from across the
project on merit, rather than merely from the pool of module owners.
This is arguably more meritocratic than a system which restricts the
pool of available talent to those who are module owners.
Gerv
Mitchell Baker
another authority group within Mozilla, whether it's a moral voice or
something else. I believe there *is* a role for some sort of group with
a project-wide perspective, but I've found trying to design it on paper
to be hard. The role of staff before the Foundation evolved; I wrote
most of the documents related to policy based in part on what we were
doing, and in part on what we felt should happen.
So I'd prefer to outline various decisions/ ideas, areas where moral
authority are desired and see you is involved, interested and what
different constituencies there are before designing a group to speak for
this. It was unbelievably hard to figure out the role of staff vs.
netscape; it took years. Thus my focus on identifying modules for such
things.
I also feel that if we end up with some group -- "staff" or otherwise --
that has project wide role, that group should *not* automatically come
from module owners.
There are a number of reasons for :
1. -- module ownership is currently focused on what's useful for
managing our activities. When it's the right thing, modules can be
split up, or combined, as happened somewhat in the last module
reorganization. I think it's really critical that our ability to
reorganize modules be based on the usefulness of particular modules. If
we add some other level of authority, then adjusting modules becomes
more difficult.
2. there are lots of modules, it's really a giant group to try to use
for general decision-making.
3. I think mconnor's point re module owners is aspirational, but I'll
bet we do appoint module owners who are pretty specifically focused on
their areas.
4. My experience has been that many people do not actually like or want
to be involved in a bunch of governance issues. It takes a particular
mindset, and a constant ability to monitor and evaluate one's current
perspective.
Personally, I like the super-reviewer model better. These are
individuals selected precisely because of the project-wide view. So far
we have them only for code, but that's true of most of our early
mechanisms. The SRs have great depth in at least one area, plus real
breadth. They are expected to step outside their own areas of
expertise, their own comfort zone, to improve the overall consistency
and quality of our work.
mitchell
Mitchell Baker
> Mitchell Baker wrote:
>> Fantasi
>>
>>
>
> Your answer is, actually, significantly different from Frank's,
> specifically
> in how you perceive the Board's ability to fill staff@'s role.
>
a set of things. There's a legal obligation that goes with being board
members that can't be delegated to others.
I may disagree with Frank on the relationship of the Board to some of
the daily operations. The Foundation Board was selected to help think
about strategic issues. In the early days this included how to sustain
ourselves. It also includes how to make our goals known in the world,
how to make the most of the Mozilla's success, how to strengthen
community models of involvement, etc. This is the case with many Boards
of Directors; they are not selected to manage (or micro-manage) daily
activities. So I agree that we should not expect the board to do this.
I also argue we wouldn't like it if they tried -- the experts in
managing our code and products and process are those people doing it.
>> I share the feeling that a system of individual module owners may lack
>> something about the "overall view" that mozilla.org staff maintained.
>> I think that's why I tried for so long to figure out a way to
>> reconstruct it. But it's tough, in part for the reasons Frank
>> outlined in his response.
>
> The problem might have been that it wasn't clear what hole your new concept
> of staff@ was trying to fill. I think that's what we're starting to define
> in this discussion here. This makes sense: there was a lot of
> reorganization
> over the past few years, and our organizational structure hasn't been
> stable
> until fairly recently.
I'm with mconnor in spirit here -- Mozilla is a community organization;
it's the set of people who participate who define what Mozilla is.
There are a bunch of things that happen that aren't tied to employment.
it would be good to have organizational mechanisms that reflect this.
We have the module ownership system which reflects this in code
management. But we're a bit short on such mechanisms for other activities.
>
>> And I also agree with you that the Board is not the likely place for
>> decisions -- even many policy decisions -- that affect daily
>> operations. It is really hard -- maybe impossible -- to make rational
>> decisions about - say, the scope of super-review, as it is on my mind
>> these days -- without being pretty directly involved in how developers
>> are working. I feel a bit removed to be doing this, and I'm a lot
>> closer to daily operations than most board members.
>>
>> I'm not yet sure of the complete answer here. I'm pretty sure that
>> having module owners is a start, and a big piece of the overall
>> solution. For example, we might identify a set of module owners who
>> together cover broad scope of the project, and have some ways for them
>> to both get input from the various constituencies of the community and
>> give input to the board. Frank made a similar suggestion.
>
> I'm a bit skeptical about having "governance module owners", but as I don't
> really understand what you have in mind, I can't much comment on that. What
> I don't see is how breaking up staff@'s jobs into little pieces and
> assigning
> a person to each one is going to recreate the advantages of a broad view of
> the project and complete coverage of all possible issues that were inherent
> in the structure of staff@. But maybe that's not what you have in mind
> at all.
Even in the old days, mozilla.org staff members had particular areas of
expertise. Asa was QA and releaase management, dmose and then myk were
toolsmiths, leaf was build and release, brendan was technical
leadership, frank was specialized (security in particular) policy, dawn
was the website, etc. We could have called Asa the module owner for QA,
myk the module owner for mozilla webtools, etc. Each person brought
some particular area of expertise, as well as a concern for the project
as a whole.
The group had some expertise in the major areas of activity that were
important to us moving forward. By creating modules we can start by
identifying these. They will be different today. There may be no QA
module for example. There's QA for sunbird and lightening, for
thunderbird, for firefox, for bugzilla, for AMO, etc. maybe we should
think about QA resources for the project as a whole, but maybe not.
This is all a way of saying that figuring out which activities and
topics can be centrally addressed is important to figuring out what a
staff-like group might do.
Mitchell
Frank Hecker
> I may disagree with Frank on the relationship of the Board to some of
> the daily operations.
I don't think there's a real disagreement here. As I wrote earlier in
response to mconnor, "I agree that it is not the place of the board to
directly manage day-to-day activities within the Mozilla project." In my
previous reply to fantasai I was simply pointing out that the Foundation
board as a whole does have real interaction with the project and its
contributors, and such knowledge does and can inform its decisions. So
in that sense at least the board is not "removed from the project".
Mitchell Baker
ml
Mitchell Baker
ml
fantasai wrote:
>
> One question to think about is what happens if Mitchell or Brendan quits?
> Dies in a car crash, or disappears in the Bermuda triangle? I hope that
> doesn't happen, but I also do hope the project continues after Mitchell
> and Brendan retire. The advantage of having a well-defined role and then
> appointing someone to fill it is that you can find someone else to fill
> the role. We can't appoint a 'successor to Mitchell' because Mitchell has
> her own peculiar package of skills, knowledge, perspective, and talents,
> and it's not likely we'll find the same package in anyone else. The
> advantage of a group like staff@ is that it's a large collection of skills,
> knowledge, perspectives, and talents and while people within it specialized
> in one area or another, that specialization was fluid and dynamic. If gaps
> needed filling, as happened when members left, the group rebalanced those
> undefined roles within itself. A group authority role like staff@ is much
> more capable of absorbing the loss of a person, even someone like Mitchell,
> than a tailored individual authority role like Chief Lizard Wrangler.
I agree completely with the key sentiment -- one goal is to have more
people able to make more decisions so that there is continuity if
someone in a leadership role becomes inactive. Also, there are a number
of things that Brendan and I used to do personally that would be good to
distribute as the project has grown.
One example is responding when there are complaints about the behavior
of a module owner. Many people are wary about making public, pointed
complaints about someone’s behaviour, and so these comments come in
private mail. (I see this as a *good* thing. We are often too hard on
each other, and I believe that it’s often good to try to get people to
change their behaviour privately before the defense mechanisms kick in.
Public mauling someone othen doesn’t help that person change for the
better.) If there is an issue with a module owner, ideally a relevant
peer group should resolve this issue. Module owners seems like a
relevant peer group here. And then if the problem is too contentious
for the peer group to resolve then it would get escalated to Brendan.
It's possible one could say we should have a group that deals with all
issues, like staff used to. But -- to continue with the module
ownership example -- someone would have to dig into the facts about a
module owner's behaviour and how closely it fits our norms. So there
might be significant discussions with other module owners. Maybe this
is better done by the module owners as a peer group rather than a staff
group. In that case i suppose the staff group would be an escalation
path for people who didn't agree with the view of the module owners as a
group. And then maybe there's yet another escalation path to Brendan or
some successor absolute decision maker if we want.
The other path -- and I am showing my incremental side here -- is to
figure out what issues we want to address and see what mechanisms make
sense.
So a general group like staff is one way of doing this. Identifying
some specific issues and figuring out if a generalized group like staff
will work well is another.
>> Creating sub-groups that could do this or that sounds slightly
>> backwards and closed-discussion to me, and I'd rather not go there.
>> Let alone define a process to get there.
>
> The decision-making process nowadays is much more open than it was eight
> years ago, with wide-open discussions and consensus-building taking the
> place of various closed decision groups. Mozilla has made great progress
> in this respect, and I don't want us to go backwards in our
> decision-making,
> either.
This a really important point.
But I don't think it would be a step backward to replace Brendan
> and Mitchell with a broader group in the role of chief arbiter and rubber
> stamp of our open decision-making process. On the contrary I think this
> would give us more balanced and broad-viewed decisions when things did
> need to be passed up to a higher authority, and it would help ensure such
> decisions accurately reflect the "will of mozilla.org" and not some
> well-connected subset. It is much easier for one or two people's view of
> the project to be skewed or incomplete than it is for a diverse group's
> collective perception to be skewed or incomplete.
[snip]
>
> The difference between having staff@ with Mitchell and Brendan instead of
> just Mitchell and Brendan is that most issues that bubble up get caught by
> staff@, not just Mitchell or Brendan. The decision fell to Mitchell or
> Brendan individually only if staff@ couldn't come up with a consensus
> within
> itself--if after every member of staff@ had at least understood the others'
> concerns, Brendan's position on a specific issue differed from every other
> member of staff@, I would expect him to accept their position as staff@'s
> official response despite his own well-articulated reservations.
>
> ~fantasai
Much of this about the value of a group bigger than two makes perfect
sense to me. But I have *never* known Brendan to cede a technical point
simply because of the number of people with a different opinion. One
can convince Brendan, bring different viewpoints, change his mind,
demonstrate other options, bring flexibility, yes. But Brendan has been
the technical leadership of Mozilla. This has never meant being the
spokesperson for a view of staff that he didn't agree with. In fact,
the opposite has been the case. In a tough, tough setting, Brendan made
the call. It had to be a call he believed in -- his role is to lead
here. Same with mine. It's hard to make a call whether other key
people are divided. that's the job though.
ml
Mike Connor
> I don’t see how to do this by creating a mozilla.org staff – like group
> and trying to define its sphere of authority / influence vis-à-vis other
> groups. I probably disagree with mconnor here. But I notice he’s got
> a lot of good ideas and he may get further on this than I have. All my
> attempts to date have ended up with overly – complex diagrams of who has
> authority for what, how they interact, and so on. Even I could barely
> understand then, and most people to whom I showed them seemed politely
> overwhelmed.
>
I'm actually curious to see these overly-complex diagrams, I've gone
down the too-many-dotted-lines path a few times in other areas.
That said, I don't know why staff now would be any more complex than my
perception of staff in the past. Keeping in mind that I have really
only been around the project since a couple of months before the
Foundation spinoff, my perspective may not match that of the original
staff@ members. There's a few key assumptions I'm making in this proposal:
* Staff would be the final authority on day to day operations. I do not
believe that the board of the Foundation is the top of the mozilla.org
pyramid, nor do I believe it should be.
* The strength of our organization comes from our module owners and the
existing leadership, and we should endeavour to enable, not direct them
* We are going to ensure that the non-code side of the project is
reflected and represented in the set of module owners
I think this should be fairly straightforward, but here goes, at least
as far as role and responsibilities go.
------------------------
The Mozilla Project is driven by and thrives on the module owner system,
and in the vast majority of cases decisions are made locally by
individual module owners, or ad hoc groups based on the scope of the
required decision. This system has allowed us to scale exceptionally
well, and works because of the continuing leadership of the module owners.
In order to ensure this system continues to succeed, the Mozilla Project
has selected a small group of leaders (staff@m.o) tasked with the
following responsibilities:
* Maintaining the module owner system:
** Filling vacant roles where appropriate
** Ensuring module owners are fulfilling their responsibilities, and
replacing those who are not
** Creating and staffing new modules where new parts of the project evolve.
* Mediating, and if necessary arbitrating, decisions that affect the
project as a whole, or that cannot be resolved between module owners.
* Ensuring that mozilla.org policies, documented and de facto, continue
to be relevant and appropriate by leading discussion and approving final
changes.
Staff is the final authority on these issues, and should only be
involved as a last resort.
------------------------
A few more notes:
I don't think it would require an explicit statement in the "mission
statement" but I would imagine Mitchell and Brendan would continue to
have a very strong influence over policy and technical decisions, as
before. I believe it is necessary to have module owners choose the
leaders on a term basis (one year would be my first put on a term, in
order to avoid long vacancies, etc). I strongly believe that any
qualified candidate would be a module owner or equivalent, but
nominations should be open to anyone. I would also propose Mitchell and
Brendan as permanent members of staff as long as they wish to continue
in the role, and to have no more than five other members of staff at one
time, to ensure the group remains small enough for individual
accountability (we can quibble about ideal voting systems later though ;)).
-- Mike
fantasai
> Mitchell Baker wrote:
>> I don’t see how to do this by creating a mozilla.org staff – like
>> group and trying to define its sphere of authority / influence
>> vis-à-vis other groups. I probably disagree with mconnor here. But
>> I notice he’s got a lot of good ideas and he may get further on this
>> than I have. All my attempts to date have ended up with overly –
>> complex diagrams of who has authority for what, how they interact, and
>> so on. Even I could barely understand then, and most people to whom
>> I showed them seemed politely overwhelmed.
>
> I'm actually curious to see these overly-complex diagrams, I've gone
> down the too-many-dotted-lines path a few times in other areas.
I'm curious about those diagrams, too. :)
> That said, I don't know why staff now would be any more complex than my
> perception of staff in the past. Keeping in mind that I have really
> only been around the project since a couple of months before the
> Foundation spinoff, my perspective may not match that of the original
> staff@ members. There's a few key assumptions I'm making in this
> proposal:
>
> * Staff would be the final authority on day to day operations. I do not
> believe that the board of the Foundation is the top of the mozilla.org
> pyramid, nor do I believe it should be.
> * The strength of our organization comes from our module owners and the
> existing leadership, and we should endeavour to enable, not direct them
> * We are going to ensure that the non-code side of the project is
> reflected and represented in the set of module owners
Ditto to all that.
BTW, here's a diagram of mozilla.org that Asa and I drew back in 2005.
(This was before MozCorp existed.) I think I left a copy on Mitchell's
desk before I left, but I'm not sure what happened to it. ;)
http://www.flickr.com/photo_zoom.gne?id=777235126&size=l
~fantasai
Axel Hecht
You gotta love how easy it was to remove the suite back then.
Just kidding.
Axel
Mike Connor
>> Mozilla is a
>> meritocracy, and skipping the module owner step would not play well
>> within the established community hierarchy, especially if staff is
>> exercising the role of oversight for module owners.
>>
>
> Leaving aside the value or otherwise of your argument as a whole, this
> particular part is fallacious because it begs the question. Your point
> already assumes that there is a hierarchy with staff above module
> owners, and one progresses "up the ladder" - and therefore going
> straight from ordinary member to staff member is "skipping the module
> owner step". But that's precisely the point under discussion.
>
Actually, it assumes that there exists a hierarchy, at least on the code
side, from new contributors, to those with CVS access, to module peers,
and then to module ownership. Its a clear progression, and people very
rarely skip steps (i.e. going directly to module ownership). Staff is
no longer part of the established hierarchy, though there are
individuals who exercise staff-like authority (I might count myself in
that group).
If one of the primary roles of staff is to maintain and support the
module owner system, I can't imagine feeling that great about elevating
someone to a position of authority over the module owners who isn't
already at that stage of the progression, although I can certainly
believe that there are exceptional people who could do the job well. I
proposed elsewhere that instead, staff would be chosen by module owners,
but open to anyone, as a means to ensure that module owners accept the
authority of staff (in other words, the consent to govern).
> fantasai is arguing for appointment of module owners from across the
> project on merit, rather than merely from the pool of module owners.
> This is arguably more meritocratic than a system which restricts the
> pool of available talent to those who are module owners.
>
In theory, maybe, but I think that at least on the code side, where
module ownership is well established, everyone I can think of who has
the experience and respect to be an effective staff member is also a
module owner in one area or another. Its a bit like any other
organization with a leadership hierarchy, you are very unlikely to have
someone effectively skip over managing a team to managing a group of
teams. There's a possibility that a member of one of the teams might
have the most raw talent for managing that group, but is unlikely to be
the person with the moral authority, experience or accrued respect to
lead effectively.
The qualities necessary to be an effective member of staff have a huge
degree of overlap with the qualities necessary to be an effective module
owner. Going with the people who have already established themselves as
leaders within the community seems like a logical requirement, overall,
but I'm open to the idea that module owners would be willing to accept
someone who isn't a module owner already, based on their standing in the
community.
-- Mike
Gervase Markham
> Actually, it assumes that there exists a hierarchy, at least on the code
> side, from new contributors, to those with CVS access, to module peers,
> and then to module ownership. Its a clear progression, and people very
> rarely skip steps (i.e. going directly to module ownership).
I agree with you this far; but when you said that making non-module
owners into staff was "skipping the module owner step" (and later in
this message, where you talk about "not at that stage of the
progression"), then you have implicitly placed staff above module owners
in your hierarchy.
> Staff is
> no longer part of the established hierarchy, though there are
> individuals who exercise staff-like authority (I might count myself in
> that group).
I would agree. I don't think that staff or a staff-like body are part of
the code-side hierarchy you mention above (at least, in terms of people
moving up through the ranks).
> If one of the primary roles of staff is to maintain and support the
> module owner system, I can't imagine feeling that great about elevating
> someone to a position of authority over the module owners who isn't
> already at that stage of the progression, although I can certainly
> believe that there are exceptional people who could do the job well. I
> proposed elsewhere that instead, staff would be chosen by module owners,
> but open to anyone, as a means to ensure that module owners accept the
> authority of staff (in other words, the consent to govern).
I certainly like the sound of that better.
Gerv
Mike Connor
On 12-Jul-07, at 6:59 AM, Gervase Markham wrote:
> Mike Connor wrote:
>> Actually, it assumes that there exists a hierarchy, at least on
>> the code
>> side, from new contributors, to those with CVS access, to module
>> peers,
>> and then to module ownership. Its a clear progression, and people
>> very
>> rarely skip steps (i.e. going directly to module ownership).
>
> I agree with you this far; but when you said that making non-module
> owners into staff was "skipping the module owner step" (and later in
> this message, where you talk about "not at that stage of the
> progression"), then you have implicitly placed staff above module
> owners
> in your hierarchy.
I think in my other mails I've _explicitly_ placed staff above module
owners, since staff would have the power to appoint and remove module
owners.
>> Staff is
>> no longer part of the established hierarchy, though there are
>> individuals who exercise staff-like authority (I might count
>> myself in
>> that group).
>
> I would agree. I don't think that staff or a staff-like body are
> part of
> the code-side hierarchy you mention above (at least, in terms of
> people
> moving up through the ranks).
I would assert that any group with the power to appoint or remove
module owners is a step up the ladder. One can pretend that's not
the case, but the reality is that anyone who can fire you is above you.
-- Mike
Gervase Markham
> I think in my other mails I've _explicitly_ placed staff above module
> owners, since staff would have the power to appoint and remove module
> owners.
I think there are two senses of "above" here which are getting confused.
Yes, staff are above module owners in the sense that they would have the
power to add and remove them, but (and I think we now agree on this)
they are not above module owners in the sense that one might "rise
through the ranks" from ordinary participant to peer to module owner to
staff - i.e. it is not going to be required that one be a module owner
before being a staff member.
Gerv
Benjamin Smedberg
> Yes, staff are above module owners in the sense that they would have the
> power to add and remove them, but (and I think we now agree on this)
> they are not above module owners in the sense that one might "rise
> through the ranks" from ordinary participant to peer to module owner to
> staff - i.e. it is not going to be required that one be a module owner
> before being a staff member.
Is there a specific proposal being discussed at this point? We seem to have
extended mitchell's original proposal somehow, but it's not clear how.
What is the problem we're trying to solve?
1) Sometimes it is necessary to resolve conflicts between module owners
(extreme case: need to remove a module owner who's hurting the project as a
whole)
2) Need to provide coherent direction and paths forward for the project
(e.g.: switching to Firefox from the suite, or moving to Tamarin and Mozilla2)
There seems to be at least three options here:
A) conflicts and direction should be provided by the benevolent dictators
Brendan/Mitchell
B) conflicts and direction should be provided by the benevolent dictators
Brendan/Mitchell, who gather a group of advisors known as "staff" for
consultation and assistance
C) conflicts and direction should be provided by a group of people known as
"staff". This group is chosen by the module owners as a group. Staff don't
necessarily have to be module owners to be chosen.
"B" seems like the historical model we've been using and should continue to
use. Of course "A" would become "B" very quickly with any BD, and "C" smacks
of unmanageable democracy.
Mitchell's original post in this thread is mainly to be about expanding the
notion of "module ownership" to include activities that don't relate
directly to the source code: marketing, product management, etc. Though
really, I don't know how "governance" fits into that model... what decisions
would a "module owner of governance" be responsible for?
--BDS
Mitchell Baker
mitchell
Mike Connor wrote:
> Mitchell Baker wrote:
>> I don’t see how to do this by creating a mozilla.org staff – like
>> group and trying to define its sphere of authority / influence
>> vis-à-vis other groups. I probably disagree with mconnor here. But
>> I notice he’s got a lot of good ideas and he may get further on this
>> than I have. All my attempts to date have ended up with overly –
>> complex diagrams of who has authority for what, how they interact, and
>> so on. Even I could barely understand then, and most people to whom
>> I showed them seemed politely overwhelmed.
>>
>
> I'm actually curious to see these overly-complex diagrams, I've gone
> down the too-many-dotted-lines path a few times in other areas.
OK, I'll try to dig up some of the diagrams.
>
> That said, I don't know why staff now would be any more complex than my
> perception of staff in the past. Keeping in mind that I have really
> only been around the project since a couple of months before the
> Foundation spinoff, my perspective may not match that of the original
> staff@ members. There's a few key assumptions I'm making in this
> proposal:
>
> * Staff would be the final authority on day to day operations. I do not
> believe that the board of the Foundation is the top of the mozilla.org
> pyramid, nor do I believe it should be.
> * The strength of our organization comes from our module owners and the
> existing leadership, and we should endeavour to enable, not direct them
> * We are going to ensure that the non-code side of the project is
> reflected and represented in the set of module owners
My issue is that I don't have a clear picture of what "day to day
operations" is here. It's not what staff used to do. this used to mean:
product release. We have multiple projects now. Having one group try
to be responsible for Firefox, Calender, SeaMonkey, thunderbird releases
doesn't make sense.
community involvement. Now we have many vectors for community
involvement. QA is different by project, development is different by
project. How does one group manage the daily operations for all this?
I agree we need many mechanisms to keep participation open and porous.
But I don't think identifying a single group to do day to day
operations will solve this.
Governing the tree -- what goes in, who touches it, etc. Our key
policies, in other words. We could create one group that looks at all
policies. But I'd like to figure out what they are first If it's tree
policies only, then one group could address them. But if we end up with
other broad policies (privacy? who knows) then I'm not sure the same
set of people will be the right folks for those.
Managing the tree -- balancing various perspectives. This might be an
open item. It's pretty clear we optimize for the web through Firefox
now. I guess the question is: what group would we empower to change
that? And how? that group has to be able to pull the project. Who is
that group? And if we identify that group, is it the same people who
should look at the various policies? and moderate behavior?
>
> I think this should be fairly straightforward, but here goes, at least
> as far as role and responsibilities go.
>
> ------------------------
>
> The Mozilla Project is driven by and thrives on the module owner system,
> and in the vast majority of cases decisions are made locally by
> individual module owners, or ad hoc groups based on the scope of the
> required decision. This system has allowed us to scale exceptionally
> well, and works because of the continuing leadership of the module owners.
>
> In order to ensure this system continues to succeed, the Mozilla Project
> has selected a small group of leaders (staff@m.o) tasked with the
> following responsibilities:
>
> * Maintaining the module owner system:
> ** Filling vacant roles where appropriate
> ** Ensuring module owners are fulfilling their responsibilities, and
> replacing those who are not
> ** Creating and staffing new modules where new parts of the project evolve.
I absolutely agree that having a group to do these things makes sense.
But I wouldn't necessarily empower that group to be the group
moderating other issues.
>
> * Mediating, and if necessary arbitrating, decisions that affect the
> project as a whole, or that cannot be resolved between module owners.
Let's identify these first before we empower some group to deal with all
of them.
>
> * Ensuring that mozilla.org policies, documented and de facto, continue
> to be relevant and appropriate by leading discussion and approving final
> changes.
Agree completely on updating the policies. I'm proposing we identify a
person for a policy, they should involve the relevant people.
>
> Staff is the final authority on these issues, and should only be
> involved as a last resort.
If that's the case, then we need a mechanism to make things happen.
>
>
I agree fundamentally with the goals. Mozilla is based on the people
who contribute, that needs to be reflected well in everything we do.
Mitchell Baker
> Mitchell's original post in this thread is mainly to be about expanding the
> notion of "module ownership" to include activities that don't relate
> directly to the source code: marketing, product management, etc. Though
> really, I don't know how "governance" fits into that model... what decisions
> would a "module owner of governance" be responsible for?
>
> --BDS
Benjamin
Here are some governance topics where I think it makes sense to consider
using the module owner system.
1. Policies:
say CVS access.
Super-review.
Certificates
Security bugs
Module Oownership
If we do these now, I'm the module owner. But I'm pretty fragmented,
and it takes me numerous starts and returns. I'd like to have a way to
identify people with particular expertise and leadership capabilities
here.
Maybe we end up with one module and sub-modules, as I understand the
front end has. That might let people work through issues and make
recommendations that I, as overall governance module owner would still
have a role in finalizing. That's pretty much how the security policy
has worked. By the time Frank completed the work to put together the
security policy I had seen enough drafts and discussion and
incorporation and consensus to simply agree. I had no substantive input
in drafting or reaching consensus; that had clearly been done.
(That's why I mentioned the members role earlier I'm not ready to hand
off authority on these policies. But I am very eager to identify a
group of people who is interested enough in these topics to figure out
proposals, respond to input and make recommendations. In other words, a
group of people broader than me to whom questions, suggestions and
issues can be raised. the newsgroup gets them out there, but often
discussion doesn't lead to proposals and actions. But I'm not set on the
members idea
2. Mozilla Public License.
3. Module Ownership -- Operational topics. Where does one take issues
with existing module owners? We could do this through a "staff@" as
mconnor suggests. But I prefer trying to create a group to address the
specific issue first.
4. Mozilla Manifesto. this needs to get to a 1.0 version. I'd like to
see some translations before then, so we know if works well in other
languages. We should also figure out how to communicate who we are
better, gets input from new groups and helps us incorporate feedback.
I don't need to be the bottleneck for all of this.
As we take on more activities that aren't strictly code I can imagine
that some things relate to governance. I've got few ideas here but I
think I'll try to get them more focused before attempting to describe.
mitchell
Sergey Yanovich
drop TB support.
On the contrary to the people who have posted comments in this thread, I
am not a mozilla insider. In addition, English is not my mother tongue.
An immediate consequence is that ideas expressed here may fail to
embrace certain logical structures obvious to long-term members of the
community. In an attempt to compensate for that, I will start reasonably
away from the topic and try to form a common ground.
Freedom is the most resilient of forces that moves societies. In the
long run, freedom defies any efforts to substantially curb it.
Mozilla is a community project. Community members are under no means
equal. Each person possesses unique set of skills and experiences.
Societies that tried to ignore this fact proved to be unsustainable.
Anarchy leads nowhere. A group without a leader is a crowd, and a team
otherwise. When free people interact, conflicts tend to arise. The
successful leader will relentlessly extinguish the conflicts
establishing a system of rules. After the system is intact for long
enough, people will oppose any changes to it.
These ideas are not new, and had already been put on the paper in 15th
century by Niccolo Machiavelli (except for mozilla :).
I have read this whole very mozilla-specific thread, because mozilla's
future matters to me. I am one of those who bought "mozilla platform"
ad. I am running a venture that is developing a "box" product based on
xulrunner. There are both money invested and progress seen, so I should
understand where mozilla is heading to do my marketing.
Mitchell Baker's announcement about TB is a very bold move. It sends a
clear signal that mozilla has a leader capable of radical steps. The
question was whether mozilla remains a community project or it is taken
over by MoFo's donors. Those who are inside will smile here, but look at
the comments in Mitchell's weblog, for instance. The phrases about
google and mozilla relationships there are not funny at all.
After reading this thread, the impression is that freedom spirit is
still strong here. Community supremacy is not challenged. Instead, there
seems to be a vacuum of power, that has appeared, after previous body,
referred to as staff@, ceased to function without naming successor.
The source of power in the project used to be an elite called module
owners. As in most societies they are too numerous to be united. The
leader feels the need to fill the vacuum, and she is choosing the
strategy that Jone Paul 2 used to end Italian dominance in Vatican. He
quadrupled the number of cardinals. Although this is known to work, it
may strike back in the long term.
I would risk providing MHO on the sensitive issue of mozilla governance.
History tells us, that the elite is better left its privilege. They tend
to revolt and fork projects otherwise. I know that mentioning Debian
here will not add weight to may arguments, not telling about drawing
parallels with mozilla. So I won't.
Noone seems to challenge the value of module owners system. These people
have a wide respect in the community, and most importantly collectively
owns the knowledge of how the project works. They deserve to be
acknowledged as the root of the power. People who have gone up the
developers hierarchy, may be given this status without a module. Their
number is best be limited to a percentile of actual module owners.
The elite cannot rule directly. From time to time, it may elect a
working body (it may be call Technical Counsel or just staff@) and
appoint a business leader. Using extreme programming approach, the
leader will determine what should be done, while the staff@ will choose
how. This is not a coincidence, that the business leader is a single
person, while the staff@ is not. Business decisions require
responsibility which is best not shared, while technical issues demand
skills and expertise which can be easily joined.
This scheme may give answers to hot issues like who is responsible for
super-review (business branch), cvs access (technical branch) or what is
the status of non-code modules (not required, underlying fields to be
managed by the business leader assignees).
Further details may be stipulated by those who are closer to the
matters. Please, do not take anything personally. I have done my best to
remain polite while being frank. Our common goal is a competitive
browser. And platform :)