New Activities Modules
Gervase Markham
Modules" - non-code activities undertaken by the Mozilla project - and
applying the module owner structure to them.
https://wiki.mozilla.org/Module_Owners_Activities_Modules
The existing Activities Modules are "Governance", "Planet Mozilla" and
"CA Certificates".
The advantages of having these is that it makes clear who is responsible
for a particular area of project life, and gives the module owner(s) a
recognized authority to resolve conflict in that area when necessary.
I think it would be useful to gather input from the community on what
other non-code areas you think would benefit from having a module owner
in this way. Does anyone have any suggestions?
One example proposal to kick things off:
Module Name: Education
Discussion Forum: mozilla.education
Scope: Mozilla's activities working with educational
institutions to include Mozilla and open-source-related modules and
projects in their curricula.
Rationale: It is useful for educational institutions to have
certainty about who has the authority to represent the project.
It might be better if proposals don't include nominations for module
owner and peers; in some cases they will be obvious, but in all cases
that's a decision for the owner of the Governance module :-)
Gerv
davidwboswell
> other non-code areas you think would benefit from having a module owner
> in this way. Does anyone have any suggestions?
Module Name: Websites
Discussion Forum: mozilla.dev.mozilla-org
Scope: Guidance of Mozilla's community and product narrative as told
on our websites.
Rationale: Mozilla's story is told across dozens of sites that
currently have a limited amount of coordination. Having a mechanism
for thinking about our story across sites will help us improve our
narrative and will reduce confusion.
Note: This module isn't intended to add layers to any existing site,
but rather aims to create a mechanism for developing a consistent
community voice.
Mitchell Baker
of authority; they do a lot of coordination, but there is some point at
which they ultimately have decision over that module. (subject to
enough problems to warrant escalation to the module ownership peers).
We'll need to decide if that is true with Activities Modules or not.
That's one reason we've gone slowly in creating them -- those that exist
so far do have ultimate decision making authority for some set of
decisions.
So as we think about new modules we need to think about whether this is
the case, or if we are identifying coordination or "point of contact"
roles. The latter is fine, a very good thing to do. We need to be clear
though.
As to the specific example, I could see identifying a point of contact.
But I'm not yet sure what sort of authority would be involved.
Now that I think of it, I wonder if a "point of contact" type role might
be very valuable. We may increasingly have subject areas where lots of
different things are happening -- labs, some stuff in product, maybe
both in firefox and thunderbird, various other organizations involved.
On the other hand, it's certainly easier not to create a new type of role.
mitchell
Mike Shaver
> Rationale: It is useful for educational institutions to have
> certainty about who has the authority to represent the project.
What does that authority mean, exactly? (Represent them in what
contexts? Make what commitments that bind the project?)
"Authority to represent the project" is an interesting way to look at
module ownership. Pondering how that concept maps to our code
modules, too. Hmm. Generally our ownership thinking is more about
internal role -- making decisions about how an area evolves -- rather
than external perception or interaction, but that may not be inherent.
Hmm, I say!
Mike
Frank Hecker
> One thing to think about is that our current module owners have a level
> of authority; they do a lot of coordination, but there is some point at
> which they ultimately have decision over that module. (subject to
> enough problems to warrant escalation to the module ownership peers).
>
> We'll need to decide if that is true with Activities Modules or not.
> That's one reason we've gone slowly in creating them -- those that exist
> so far do have ultimate decision making authority for some set of
> decisions.
In the example case (Mozilla Education) it's not clear that there is
such a set of decisions.
> Now that I think of it, I wonder if a "point of contact" type role might
> be very valuable. We may increasingly have subject areas where lots of
> different things are happening -- labs, some stuff in product, maybe
> both in firefox and thunderbird, various other organizations involved.
> On the other hand, it's certainly easier not to create a new type of role.
I think having a "designated contact" role is worth considering; ditto
having a "designated representative" role, which is sort of the reverse
(representing the project to others vs. handling in-bound queries and
problems).
I think a "designated contact/representative/liason" role is a much
better match for what we'd like to have in the example "Mozilla
Education" non-code activity. The same pattern appears elsewhere in the
project, e.g., having designated representatives to standards committees
or to industry forums in which Mozilla participates (e.g., the
CA/Browser Forum), for any government affairs stuff, and so on.
Frank
--
Frank Hecker
hec...@mozillafoundation.org
Frank Hecker
> On Wed, Oct 28, 2009 at 6:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> Rationale: It is useful for educational institutions to have
>> certainty about who has the authority to represent the project.
>
> What does that authority mean, exactly? (Represent them in what
> contexts? Make what commitments that bind the project?)
As noted in my previous message, I think in the example of Mozilla
Education this is more about representing the project in certain
contexts (in this case, when reaching out and working with educational
institutions interested in teaching Mozilla-related topics) than it is
about making commitments that would bind the project.
> "Authority to represent the project" is an interesting way to look at
> module ownership. Pondering how that concept maps to our code
> modules, too. Hmm. Generally our ownership thinking is more about
> internal role -- making decisions about how an area evolves -- rather
> than external perception or interaction, but that may not be inherent.
As I noted previously, I think the "represents the project" role is both
useful in certain contexts and also separable from the "module owner"
role. In some cases the same person would fill both roles, but it's also
possible to imagine these being filled by two different people. In the
extreme case you could have a person who is authorized to speak for the
project in a given area but doesn't actually make any of the decisions
for that area -- this is basically what, e.g., a press secretary does
for the government official or agency they're representing.
Mitchell Baker
I have the same questions about this module as I do about Gerv's
education example. And in this one the questions may even be more
pronounced, since we have people making decisions about very websites.
I talk to Sam Sidler about this a bit and he had some examples of the
kinds of activities that might make sense
identifying what websites we have
monitoring the health of the various websites
what do we do with a website like service week? should we end of life
it?
identifying and coordinating things like "how to get involved",
creating a central spot somewhere (probably mozilla.org) and referencing
specific how to get involved sites for activities
These all seem like very worthwhile activities. I'm not yet sure how
to define a scope of authority.
This is a bit different from the education piece, where Gerv suggested
the authority to represent the product, which is externally facing.
I wonder if we want something like a Task Force? hmm, more on that in a
bit, either tonight or tomorrow.
mitchell
Mitchell Baker
education (gerv's example) and website health and coordination (david
boswell's suggestion).
In both cases I stumble over the question of "what authority are we
delegating?"
I see the "authority" aspect of module ownership as important. A
module owner is the decision-maker for his / her module -- unless and
until enough controversy develops to escalate (as always, to brendan or
me, and today also to the module ownership module). This makes us
different from some projects that work only by consensus; we've always
tried to have a clear decision-maker.
I prefer not to create modules that are something different.
On the other hand, we do need some way to represent Mozilla to the
world, and we need to coordinate some activities among many groups.
Education and websites are two good examples.
I'm starting to think we should create something -- a Website Task Force
for example, to address website coordination. The Task Force would be
named people, with a named scope. It would be a resource for people
wanting to address an issue.
The work of a Task Force might demonstrate that there is some area where
decision-making authority ought be delegated. Or it might function
quite well a a coordination, resource body.
For example, I'm not ready to say a specific group of people has the
authority to decide what community and product narrative *must* be
displayed on each and every Mozilla website. That seems like creating
trouble. But identifying a set of people who are working on this issue,
have special expertise and are a resource would be great.
Any thoughts on this?
mitchell
On 10/29/09 11:29 AM, davidwboswell wrote:
Deb Richardson
> For example, I'm not ready to say a specific group of people has the
> authority to decide what community and product narrative *must* be displayed
> on each and every Mozilla website. That seems like creating trouble. But
> identifying a set of people who are working on this issue, have special
> expertise and are a resource would be great.
>
> Any thoughts on this?
>
I'm not sure I fully understand task forces yet. I'm not trying to dissuade
anyone from the idea, I just want to understand it more clearly:
* What would the task forces actually do? Is there an example of a specific
problem exists that a task force would solve?
* How would people be chosen for or assigned to the task forces? Module
owners become module owners largely because they're already acting as module
owners, as I understand it. Module ownership is more a formalization of
existing authority than creating something new. Are task forces similar, or
are they something entirely new?
* My primary fear is that task forces could easily get bogged down in
consensus building, when that energy could be better focused elsewhere. How
would that be avoided?
* Task forces look a lot like they would largely be made up of module owners
(in that they exist to address meta-module or cross-module issues). Would
task forces have any authority over these modules or would they be more for
communication and advisory work?
I'm also not sure "task force" is a great term...I tend to think of a task
force as a small group of people assigned to execute on a very specific,
clearly-scoped, short-term project.
~ deb
Mitchell Baker
On Tue, Nov 3, 2009 at 11:51 PM, Mitchell Baker <mitc...@mozilla.com> wrote:
For example, I'm not ready to say a specific group of people has the authority to decide what community and product narrative *must* be displayed on each and every Mozilla website. That seems like creating trouble. But identifying a set of people who are working on this issue, have special expertise and are a resource would be great.
Any thoughts on this?
I'm not sure I fully understand task forces yet. I'm not trying to dissuade anyone from the idea, I just want to understand it more clearly:
* What would the task forces actually do? Is there an example of a specific problem exists that a task force would solve?
There are many activities(or activity types or topics or issues) that live in many places in Mozilla, and no clear, easily knowable way to (a) coordinate now, or (b) for those who are coordinating to be found. Similarly, because these activities are in many places, it makes me uncomfortable to say, "OK, you're the Education module owner, you have decision-making authority over everything we do with education across the Mozilla project. " Same with our website.
I've put more details on the problems at the end of the message.
* How would people be chosen for or assigned to the task forces? Module owners become module owners largely because they're already acting as module owners, as I understand it. Module ownership is more a formalization of existing authority than creating something new. Are task forces similar, or are they something entirely new?
* My primary fear is that task forces could easily get bogged down in consensus building, when that energy could be better focused elsewhere. How would that be avoided?
* Task forces look a lot like they would largely be made up of module owners (in that they exist to address meta-module or cross-module issues). Would task forces have any authority over these modules or would they be more for communication and advisory work?
I'm also not sure "task force" is a great term...I tend to think of a task force as a small group of people assigned to execute on a very specific, clearly-scoped, short-term project.
more details on website, as i understand it from Sam
~ deb
identify, keep track of Mozilla TLD in active use for websites (apparently there are more than one would imagine)
guidance re rationalizing these. When and how to end of life some of these
guidance on describing Mozilla on the various websties.
Gervase Markham
> So as we think about new modules we need to think about whether this is
> the case, or if we are identifying coordination or "point of contact"
> roles. The latter is fine, a very good thing to do. We need to be clear
> though.
I think we are identifying authority. And if the people we are
considering don't have that authority, we either need to give it to them
or to pick the person who has it and make the first person a peer. Or
not create that Activity Module at all.
IOW, I agree that conflating the roles of "Module Owner" and "Point of
Contact" is a mistake.
Gerv
Gervase Markham
> On Wed, Oct 28, 2009 at 6:15 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> Rationale: It is useful for educational institutions to have
>> certainty about who has the authority to represent the project.
>
> What does that authority mean, exactly? (Represent them in what
> contexts? Make what commitments that bind the project?)
Good question :-)
> "Authority to represent the project" is an interesting way to look at
> module ownership. Pondering how that concept maps to our code
> modules, too. Hmm. Generally our ownership thinking is more about
> internal role -- making decisions about how an area evolves -- rather
> than external perception or interaction, but that may not be inherent.
You are right. However, it does seem there's some correlation between
Activities Modules and things which are more externally-facing. (I'll
leave the question about whether that indicates an deficiency in
external-facingness among our developers ;-). So it's useful to consider
what it means to be a module owner when it comes to a) talking about and
b) making commitments on behalf of the project.
As Frank says, you can entirely separate a) and b) - the press secretary
example. So I think we have figure out whether we want to do that, or
whether our belief in a meritocracy means that necessarily the person
who merited the module owner position therefore also makes the decisions
and speaks for the project on that matter.
Gerv
Gervase Markham
> I think the generalized statement of the problem is: we don't have a
> mechanism today for identifying and legitimating groups working on
> coordination and knowability; our modules identify and legitimate
> decision-making authority.
I'm not quite sure what you mean by "coordination and knowability".
Could you expand?
> There are many activities(or activity types or topics or issues) that
> live in many places in Mozilla, and no clear, easily knowable way to (a)
> coordinate now, or (b) for those who are coordinating to be found.
> Similarly, because these activities are in many places, it makes me
> uncomfortable to say, "OK, you're the Education module owner, you have
> decision-making authority over everything we do with education across
> the Mozilla project. " Same with our website.
I agree with your nervousness; this sort of thing in a business context
leads to bailiwicks. "You can't do that because it relates to educating
someone, and Fred has to clear everything to do with Education." OTOH,
there are some things on which a consistent cross-project position is
valuable, such as publicity and messaging, and it being clear who to
talk to about that is a good thing.
> identify, keep track of Mozilla TLD in active use for websites
> (apparently there are more than one would imagine)
Indeed. Looking at a recent downtime report, there was a list there of a
load of websites that I had no idea we had. library.mozilla.org, anyone?
Gerv
Deb Richardson
> I agree with your nervousness; this sort of thing in a business context
> leads to bailiwicks. "You can't do that because it relates to educating
> someone, and Fred has to clear everything to do with Education." OTOH,
> there are some things on which a consistent cross-project position is
> valuable, such as publicity and messaging, and it being clear who to
> talk to about that is a good thing.
>
I'm not sure why you think we'd be immune to similar bailiwicks within the
Mozilla project. :)
I'd like some further clarification on the "consistent cross-project
position" thing. Let's say Marketing develops a new website that has a
unique target audience, message and purpose. As a result, they use a
different core narrative for the site that doesn't conform with the
"consistent cross-project position" put forth and approved by the Website
module owner.
What happens then? Will the marketing team that owns the website be
expected to change their site to conform with the approved consistent
narrative? Does the Website module owner have the authority to force that
change? What if they disagree and want to stick with their original
narrative and messaging? Would they need to get approval from the Website
module owner at any point during development, or prior to or after launch?
My issue in this particular example is that almost every aspect of the
Mozilla project involves putting something on the web. A "Website" module
would be an umbrella over all of these, touching on dozens of different
projects -- Planet, mozilla.com, mozilla.org, AMO, MDC, Hacks, wiki.mo, a
wide variety of blogs, a multitude of marketing projects, SFX, Labs, etc etc
etc. I'm just not sure what a Website module owner would do in relation to
all of these various projects. What authority would that module owner have
over the people and teams that already own these websites?
Could this not be better accomplished by improving communications,
coordination, and cooperation between the people who already own and have
authority over these projects? I think this is where Mitchell was heading
with the "task force" idea -- rather than appoint a module owner in a
position of authority over these disparate projects, formalize and recognize
that there is already a group of people doing these things, and encourage
that group to talk to each other more, and to coordinate and cooperate where
useful and beneficial.
Each of these groups could then appoint a single point of contact if they
deem it necessary. You seem to dismiss this idea elsewhere, but I think
it's a very useful idea -- figuring out who to talk to about various things
can be very confusing, and having a single, publicized person as a contact
would be very useful. I just don't think that person needs to have any
particular decision-making authority or ownership, but does need to have a
deep knowledge of that particular part of the project.
~ deb
davidwboswell
> owners become module owners largely because they're already acting as
> module owners, as I understand it. Module ownership is more a
> formalization of existing authority than creating something new.
At least with the Websites example, coordination among some sites has
started happening and this would be a formalization of that.
> I'd like some further clarification on the "consistent cross-project
> position" thing. Let's say Marketing develops a new website that has a
> unique target audience, message and purpose. As a result, they use a
> different core narrative for the site that doesn't conform with the
> "consistent cross-project position" put forth and approved by the
> Website module owner.
>
> What happens then?
In this example, I think a formally recognized group would help us
avoid getting into this sort of situation by providing a forum for
talking through ideas and by providing style guides and other assets,
like a community site template (see the recent redesign of Planet
based on the new www.mozilla.org design).
This is almost wholly a coordination role to fill a need that's not
being served, although I could see a situation where this group feels
that something is wrong and asks to have it changed. Based on
experience, these sorts of issues arise when something is unowned so
there's no conflict here between a module owner and the task force.
To give one example, the Mozilla Party Central site at http://mozillaparty.com
talks about the upcoming Firefox 3 launch and all party information
dates to 2008. This site is effectively unowned and confuses our
story and I think it would be completely fine for the task force to
drive fixing that.
In the case where there is a genuine conflict between the task force
and a module owner, perhaps the role is to flag this as a concern and
bring it to the governance group as needed instead of over-ruling
anything itself?
> My issue in this particular example is that almost every aspect of the
> Mozilla project involves putting something on the web. A "Website"
> module would be an umbrella over all of these, touching on dozens of
> different projects
Perhaps 'Websites' isn't the best term. IMO, this is more an issue
about telling our story and that happens to be done mainly through
websites, so maybe something like 'Community Narrative Group' or
something works better?
> Could this not be better accomplished by improving communications,
> coordination, and cooperation between the people who already own and have
> authority over these projects?
Certainly some things could be fixed just by better communications
among different groups, but I think part of this involves the project
stating that a consistent narrative, for example, is important to
us.
If there's no ownership to recognize, I agree that the main thing is
the step of recognizing something as a community concern (versus the
concern of a particular community member).
> I just don't think that person needs to have any
> particular decision-making authority or ownership, but does
> need to have a deep knowledge of that particular part of the project.
What about with the Mozilla Party Central example above? Would it
make sense for a task force to go ahead and make a decision here?
David
Gervase Markham
> I'd like some further clarification on the "consistent cross-project
> position" thing. Let's say Marketing develops a new website that has a
> unique target audience, message and purpose. As a result, they use a
> different core narrative for the site that doesn't conform with the
> "consistent cross-project position" put forth and approved by the Website
> module owner.
David?
> My issue in this particular example is that almost every aspect of the
> Mozilla project involves putting something on the web.
You are right that everything we do involves putting content on the web,
and so defining the role of a Website module owner in particular has to
be done carefully to avoid overreaching.
> Each of these groups could then appoint a single point of contact if they
> deem it necessary. You seem to dismiss this idea elsewhere, but I think
> it's a very useful idea
I don't think I dismissed that idea; I just said that I don't think we
want to tie the role to that of the module owner, or call it "module
owner". It may turn out that they are the same person, but I think it's
a mistake to bake that in.
Gerv
Axel Hecht
> On Thu, Nov 5, 2009 at 7:25 AM, Gervase Markham<ge...@mozilla.org> wrote:
>
>
>> I agree with your nervousness; this sort of thing in a business context
>> leads to bailiwicks. "You can't do that because it relates to educating
>> someone, and Fred has to clear everything to do with Education." OTOH,
>> there are some things on which a consistent cross-project position is
>> valuable, such as publicity and messaging, and it being clear who to
>> talk to about that is a good thing.
>>
>
> I'm not sure why you think we'd be immune to similar bailiwicks within the
> Mozilla project. :)
>
> I'd like some further clarification on the "consistent cross-project
> position" thing. Let's say Marketing develops a new website that has a
> unique target audience, message and purpose. As a result, they use a
> different core narrative for the site that doesn't conform with the
> "consistent cross-project position" put forth and approved by the Website
> module owner.
>
> What happens then? Will the marketing team that owns the website be
> expected to change their site to conform with the approved consistent
> narrative? Does the Website module owner have the authority to force that
> change? What if they disagree and want to stick with their original
> narrative and messaging? Would they need to get approval from the Website
> module owner at any point during development, or prior to or after launch?
I guess this is taking the thread outside of its original scope, but
nevertheless:
Websites we do never face "just that target audience". They're on the
web, and they'll be seen by people all over the world. There will be
members of our community that want to localize it, and there will be
people that think "what the hell are they smoking?".
If someone came up with "I gotta say something that's not our narrative
for X", they probably got the answer wrong. Or they really intend to
talk to the wrong people, though unlikely. If someone puts it on the web
anyhow, we should already have someone to talk to them, and take it down
if the answer can't be fixed.
Axel
Mitchell Baker
-- website maintenance -- is the party site up to date, or filled with
obsolete material?
-- mozilla website cohesion -- do the various sites fit together
I'm not sure how to parcel out decision-making authority for either of
these yet. I agree they are both good things to do. So that's not an
answer yet.
I have a proposal for a metrics model where these topics seem much
clearer to me. I'll make that proposal very shortly; perhaps it will
help us make progress on these topics as well.
mitchell