How can we help people better understand community processes?

[davidwboswell]

One of the most interesting findings for me from the recent
Contributor Lifecycle Audit was that community decision-making
processes are only clear to 1/3 of volunteer contributors and just
over half of paid contributors.

If you missed the recent audit presentation, you can find the video
and slides at the following page (the information I'm referencing is
on slide 29). Note that we'll be adding data used in the audit to
that page soon.

https://wiki.mozilla.org/Contribute/Audit

There are clearly some downsides to not having the community's
decision-making processes be widely understood. So my question is how
can we address this?

I think this is a good transition from the recent discussion about
trust. That seems to be an issue where some teams (Security,
Communications) have understood the way to make a decision about who
should be given access to sensitive information and have moved
forward. There are other teams who haven't known how to deal with the
question about establishing trust and have not moved forward.

The discussion in that thread was pointing to the need to better
promote how teams have solved that issue so that other teams can learn
from and benefit from that information.

Would that work for helping people better understand community
processes in general? Maybe a string of case studies could be done
and then promoted? For instance, how was the decision made to retire
use of the mozilla.com domain?

We could use that to expand the existing governance information that
we're making available at:

https://www.mozilla.org/about/governance.html

Any thoughts on this? Is this something that should be addressed?
Are there other ways to address this?

David

[Gervase Markham]

On 07/02/12 19:22, davidwboswell wrote:
> One of the most interesting findings for me from the recent
> Contributor Lifecycle Audit was that community decision-making
> processes are only clear to 1/3 of volunteer contributors and just
> over half of paid contributors.

There are two broad reasons why this might be so:

1) There is a community decision-making process, but it is not
sufficiently well understood

2) There is no community decision-making process; decisions are taken
(either deliberately or accidentally) 'behind closed doors'

I don't think we can leap to assuming that the problem in all cases is
problem 1). (It won't be problem 2) in all cases either!)

I suggest that Mozilla's community-based governance structures, such as
the module ownership system, are in need of revitalization. Module
owners do not exist for large chunks of the activities that Mozilla does
day-to-day in 2012. And as that system has atrophied, a /de facto/
system based on employment and the (non-visible) MoCo management tree
has emerged. Who's in charge of Project X? Well, obviously, the person
MoCo pays to manage the team working on Project X.

This is not to attribute malice to anyone; I don't think we specifically
chose to go this way. I just think it's what has happened - for a number
of reasons, some social, some technical.

So I think the first thing we need to do is figure out how we want the
governance of the Mozilla project to work, and how we are going to get
there. Once we've done that, we can check again and see if people
understand it :-)

Gerv

[Gavin Sharp]

On Thu, Feb 9, 2012 at 5:16 AM, Gervase Markham <ge...@mozilla.org> wrote:
> I suggest that Mozilla's community-based governance structures, such as the
> module ownership system, are in need of revitalization. Module owners do not
> exist for large chunks of the activities that Mozilla does day-to-day in
> 2012. And as that system has atrophied, a /de facto/ system based on
> employment and the (non-visible) MoCo management tree has emerged. Who's in
> charge of Project X? Well, obviously, the person MoCo pays to manage the
> team working on Project X.
>
> This is not to attribute malice to anyone; I don't think we specifically
> chose to go this way. I just think it's what has happened - for a number of
> reasons, some social, some technical.

I couldn't agree more. The rapid growth of MoCo (and the scope of its
activities) has only really been possible because of a trade-off:
corporate governance strategies were formed and used, rather than the
traditional community-focused Mozilla approach. The gain was mostly
expediency and efficiency - Mozilla needs to move fast and quickly
expand into new areas to be competitive, and "building a community"
takes time and effort, and can be inefficient (or might require
uncommon/specialized skills to do efficiently). The loss was
transparency in decision making, and a reduction of the possibility of
true community involvement, something that many of us value pretty
dearly.

How these things need to be weighed against each other is a matter of
perspective, and as we add more and more Mozillians via MoCo hiring,
the overall sentiment towards community processes gets skewed.
Improving this situation by investing in "employee education" and
revitalizing the Mozilla governance system sounds like a wonderful
idea to me.

Gavin

[Gervase Markham]

On 14/02/12 00:19, Gavin Sharp wrote:
> I couldn't agree more. The rapid growth of MoCo (and the scope of its
> activities) has only really been possible because of a trade-off:

I certainly agree that the way we've grown hasn't all been downside :-)

> corporate governance strategies were formed and used, rather than the
> traditional community-focused Mozilla approach. The gain was mostly
> expediency and efficiency - Mozilla needs to move fast and quickly
> expand into new areas to be competitive, and "building a community"
> takes time and effort, and can be inefficient (or might require
> uncommon/specialized skills to do efficiently). The loss was
> transparency in decision making, and a reduction of the possibility of
> true community involvement, something that many of us value pretty
> dearly.

Yep. That.

> How these things need to be weighed against each other is a matter of
> perspective, and as we add more and more Mozillians via MoCo hiring,
> the overall sentiment towards community processes gets skewed.
> Improving this situation by investing in "employee education" and
> revitalizing the Mozilla governance system sounds like a wonderful
> idea to me.

That too.

Gerv

[fantasai]

Wrt education, I suggest making Gerv's presentation on the relationship
between the community and the corporation from the September All-Hands
required orientation material for every new hire. :)

~fantasai

[Gervase Markham]

On 14/02/12 16:01, fantasai wrote:
> Wrt education, I suggest making Gerv's presentation on the relationship
> between the community and the corporation from the September All-Hands
> required orientation material for every new hire. :)

The presentation of which fantasai speaks can be seen here:
http://blog.gerv.net/2011/09/how-to-be-a-mozillian-how-to-work-in-community/

(Usual disclaimer: don't blame the video team for the poor quality; I
forced them into recording it :-)

Gerv

[Asa Dotzler]

On 2/9/2012 5:16 AM, Gervase Markham wrote:
> On 07/02/12 19:22, davidwboswell wrote:
>> One of the most interesting findings for me from the recent
>> Contributor Lifecycle Audit was that community decision-making
>> processes are only clear to 1/3 of volunteer contributors and just
>> over half of paid contributors.
>
> There are two broad reasons why this might be so:
>
> 1) There is a community decision-making process, but it is not
> sufficiently well understood
>
> 2) There is no community decision-making process; decisions are taken
> (either deliberately or accidentally) 'behind closed doors'

or 3) there never was a community decision making process for a large
number of Mozilla functions and we've always just muddled along. With a
mostly engineering organization, that was probably OK for a couple of years.

Today, there are literally hundreds of full-time Mozilla contributors
working in functions like Product Management, Project Management, User
Experience, User Research, Event coordination, AV and Community IT
Infrastructure, Legal, Privacy, Data and Metrics, Market Insights,
Infrastructure Security, Release Engineering, User Support, User
Engagement, etc, etc.

We've never had module ownership in these areas and yet we've been doing
most of them in some form or another since the beginning of the project.
Today, a full 3/4ths of Mozilla's full-time contributors work in areas
completely outside of the module owner system

Let's face it, our module system, with only a few exceptions, has always
been about the code. If you've ever wanted to know how decisions were
made about UX, or Product, or IT, or Support, or QA, or InfraSec, you
either got hand-waiving, or a pointer to the Mozilla employee with
responsible for that area.

Our module owner system was long ago outrun by the dozens of functions
that hundreds of Mozillians deliver for the project but that were never
given any project authority/responsibility because they weren't people
writing code.

I'm sure there are some code projects that have come along over the
years and don't have official modules, but I assert that fixing those is
little more than a band-aid given how much of what Mozilla does has
nothing to do with coding.

I think the answer is to actually figure out how to extend authority and
responsibility beyond the code base, and not just a new policy module
every year or two, but a comprehensive effort to codify all of the
functions of the project today and to bless module owners and peers for
each of those areas. It's going to be complicated (who do you escalate
to when the module owner of the Support program and the module owner of
the Privacy program disagree?) but anything short of that means that
"Mozilla employees" will be de facto owners with no sanctioned path for
new contributors or even new non-Moco owners.

If we continue to deny the non-code functions in the Mozilla community
of actual project authority and responsibility we're sure to see much of
the decision making behind closed doors. And as long as it's behind
closed doors, it's going to continue to be not only opaque to the
broader community, but exclusionary.

- A

[davidwboswell]

> I think the answer is to actually figure out how to extend authority and
> responsibility beyond the code base, and not just a new policy module
> every year or two, but a comprehensive effort to codify all of the
> functions of the project today and to bless module owners and peers for
> each of those areas.

I definitely think extending the community's authority and
responsibility structure more broadly (and also making sure the Module
system is up to date where it exists today) is a big part of this.

I think it goes beyond this though. Having a comprehensive list of
modules and owners doesn't help if people aren't aware of it or if
people don't know what to do with that information.

Knowing who to go to about a change you're trying to make is one
thing, but knowing how to make an effective case for that change is
something else.

I like fantasai's idea about baking in information about this to the
new hire material (and the People team is starting to think through
this). I also think widely promoting specific case studies about how
to get things done in the community's decision making processes would
be useful too.

David

[Asa Dotzler]

On 2/21/2012 3:51 PM, davidwboswell wrote:
>> I think the answer is to actually figure out how to extend authority and
>> responsibility beyond the code base, and not just a new policy module
>> every year or two, but a comprehensive effort to codify all of the
>> functions of the project today and to bless module owners and peers for
>> each of those areas.
>
> I definitely think extending the community's authority and
> responsibility structure more broadly (and also making sure the Module
> system is up to date where it exists today) is a big part of this.

Let's do it!

> I think it goes beyond this though. Having a comprehensive list of
> modules and owners doesn't help if people aren't aware of it or if
> people don't know what to do with that information.

I think it's awful hard to go beyond when the comprehensive list we have
today is somewhat out of date and even if up to date covers only about
25% activity that happens across Mozilla every day.

Helping people learn about our current module system and leaders and how
to work effectively in that system is a worthwhile effort. Even if we
did that well, though, it addresses an increasingly small part of what
Mozilla actually does as a project.

Further investment in helping people understand our process for
contributing to code should continue, but I think it's even more
important for us to build structure, process, roles and responsibilities
around all of the things that aren't code than it is to try to make the
coding part a bit less opaque.

> Knowing who to go to about a change you're trying to make is one
> thing, but knowing how to make an effective case for that change is
> something else.

Yeah. But if you don't even know who to go to -- or worse, there simply
isn't anyone to go to because the Mozilla project doesn't
recognize/legitimize three quarters of what happens every day, you're
pretty stuck. Step one needs to be "define the process". Step two needs
to be "give people the authority and responsibility for executing on
that process". Then we get to step three, "teach more people about that
process and how to work with the people already involved in that process."

> I like fantasai's idea about baking in information about this to the
> new hire material (and the People team is starting to think through
> this). I also think widely promoting specific case studies about how
> to get things done in the community's decision making processes would
> be useful too

I suspect a disconnect here. I'm not getting something. Can you tell me
what you would say to a new hire about our UX process or our Data and
Metrics process or our Market Insights process? How do those activities
work and how do community members contribute -- or earn reputation, or
leadership roles in any of them?

Again, the problem is that we don't have a community decision making
process for most of what Mozilla does today. We have a module ownership
process and that's basically it.

We can't very well educate new hires or new contributors to our decision
making process when that decision making process doesn't exist for most
people -- or if it does exist, is a MoCo process and not a Mozilla process.

Until we actually build community processes for the rest of what Mozilla
does, we're not in good shape to help people understand our processes :-)

- A

[Gen Kanai]

On 2/22/12 9:36 AM, Asa Dotzler wrote:
> Until we actually build community processes for the rest of what Mozilla
> does, we're not in good shape to help people understand our processes :-)

Agreed.

And yet updating of what we do have already (wrt the existing Module
Owners and Peers) is, I think, something that needs to be done
concurrently so that we have an up-to-date list to broaden/build.

A process also needs to be created so that the Owners/Peers list never
gets very far out-of-date as it is now.

We need someone to drive/own that.

(I would if I was the right person to do so. I doubt that I am.)

Gen


--
Gen Kanai

[Gervase Markham]

On 21/02/12 21:49, Asa Dotzler wrote:
> On 2/9/2012 5:16 AM, Gervase Markham wrote:
>> 2) There is no community decision-making process; decisions are taken
>> (either deliberately or accidentally) 'behind closed doors'
>
> or 3) there never was a community decision making process for a large
> number of Mozilla functions and we've always just muddled along. With a
> mostly engineering organization, that was probably OK for a couple of
> years.

This is a variant on 2) IMO; but yes, I entirely agree that this has
happened.

> Let's face it, our module system, with only a few exceptions, has always
> been about the code. If you've ever wanted to know how decisions were
> made about UX, or Product, or IT, or Support, or QA, or InfraSec, you
> either got hand-waiving, or a pointer to the Mozilla employee with
> responsible for that area.

This is true. We have made an effort with Activities Modules to move it
outside code, but (for whatever reason) that effort has not acquired
nearly enough momentum to make a dent.

> I think the answer is to actually figure out how to extend authority and
> responsibility beyond the code base, and not just a new policy module
> every year or two, but a comprehensive effort to codify all of the
> functions of the project today and to bless module owners and peers for
> each of those areas. It's going to be complicated (who do you escalate
> to when the module owner of the Support program and the module owner of
> the Privacy program disagree?) but anything short of that means that
> "Mozilla employees" will be de facto owners with no sanctioned path for
> new contributors or even new non-Moco owners.

I agree.

> If we continue to deny the non-code functions in the Mozilla community
> of actual project authority and responsibility we're sure to see much of
> the decision making behind closed doors. And as long as it's behind
> closed doors, it's going to continue to be not only opaque to the
> broader community, but exclusionary.

Amen!

Gerv

[Gervase Markham]

On 22/02/12 01:17, Gen Kanai wrote:
> And yet updating of what we do have already (wrt the existing Module
> Owners and Peers) is, I think, something that needs to be done
> concurrently so that we have an up-to-date list to broaden/build.

And there are political issues here. We can't just hash a list of owners
and peers out directly in public - there's a lot of potential for hurt
feelings. We could perhaps hash out a list of owners in public, and then
let the owners choose their peers (which is probably the right thing
anyway).

We need to start with:

- an overview of everything Mozilla currently does
- an idea of how we want to structure the authority.

For the latter, here are two proposals to start us off (although I'm
sure there are more):

1) A fairly flat "Area Owner" and peer module structure, just like now

2) Some sort of combined volunteer and employee hierarchical org chart,
which may or may not look anything like the MoCo org chart

> A process also needs to be created so that the Owners/Peers list never
> gets very far out-of-date as it is now.

That will require cultural change (including in MoCo management, so that
new initiatives driven by MoCo are either placed within the existing
community structure or new structure is created for them) as well as an
observant eye.

Gerv

[JP Rosevear]

On Tue, 2012-02-21 at 16:36 -0800, Asa Dotzler wrote:
> On 2/21/2012 3:51 PM, davidwboswell wrote:

> >> I think the answer is to actually figure out how to extend authority and
> >> responsibility beyond the code base, and not just a new policy module
> >> every year or two, but a comprehensive effort to codify all of the
> >> functions of the project today and to bless module owners and peers for
> >> each of those areas.
> >
> > I definitely think extending the community's authority and
> > responsibility structure more broadly (and also making sure the Module
> > system is up to date where it exists today) is a big part of this.
>

> Let's do it!

Definitely. I suggest you proposed a product module, outline its scope
and responsibility, and propose yourself or whoever as owner. I think
its a similar responsibility of others who think they need a module to
propose it. This will give a concrete basis to discuss.

Thanks,

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

[Robert Kaiser]

Asa Dotzler schrieb:

> I think the answer is to actually figure out how to extend authority and
> responsibility beyond the code base

Actually, we have started this quite some time ago with activities
modules, and the move of the module list to the wiki was driven to a
good part by this (next to despot being not adequate even for code any
more).

We probably need to capitalize more on that - and it would be really
good to have community insight into how even our paid contributors are
structured. After all, we're an open organization. :)

Robert Kaiser

[Clint Talbert]

Sounds good to me. Where are we doing this proposing? On a wiki
somewhere? On this newsgroup?

Happy to help out. This sounds like a great and much needed direction
that we've spent far too long neglecting.

-- Clint

[JP Rosevear]

On Wed, 2012-02-22 at 17:25 -0800, Clint Talbert wrote:
> On 2/22/2012 8:21 AM, JP Rosevear wrote:

> Sounds good to me. Where are we doing this proposing? On a wiki
> somewhere? On this newsgroup?

The last module proposal I saw was by Mitchell on this newsgroup, so
here seems reasonable.

[SmoothPorcupine]

On Feb 21, 1:49 pm, Asa Dotzler <a...@mozilla.org> wrote:
> Who do you escalate

> to when the module owner of the Support program and the module owner of
> the Privacy program disagree?

Dedicated arbitrators. If internal ones don't work, seek out a neutral
third party.


(Also be sure to invite me if you set up a list dedicated to
arbitration.)

[lkcl]

On Feb 9, 1:16 pm, Gervase Markham <g...@mozilla.org> wrote:

> 2) There is no community decision-making process; decisions are taken
>     (either deliberately or accidentally) 'behind closed doors'

for example: i note that the B2G project has a "weekly phone
conference". where is the transcript or an ogg/vorbis copy of each
and every single one of these conference calls available, online, for
people outside of the project, who may have something valuable to
contribute, to review? how can someone participate in these calls
from outside of the United States? are they even *permitted* to
participate in such calls?

additionally it is often incredibly hard to even... remotely find the
appropriate people or the appropriate place to even begin a discussion
on a particular topic. i have no idea, for example, whether this
message will be received or even read by the right people [because
it's a google group interface to a newsgroup]

the python software foundation is in some ways in the same boat:
there was a project (a port of python to mingw32) which has been side-
lined for almost 5 years, yet there is a small community who use and
maintain it. as i went via the route of talking to the python
*developers*, they reacted unfavourably to my initiative to have the
patches (which had had constant maintenance for over 5 years) part of
the mainstream python codebase. i had no idea, until speaking
recently to someone who is familiar with the python software
foundation infrastructure, that you could actually put in formal
proposals to the python software foundation for consideration and
funding. if i had known that, i would have gone via that route at the
time that i was working on that code.

perhaps some insights, here, for you: i don't believe that the public
fully appreciate the significance of the work being done by the
mozilla foundation. it's "just a web browser", right? so... why
should anyone pay attention to it?

by contrast, even the silliest little "buhhhhloooggggguhh" post by
the most random google employee gets a great deal of attention and is
blown up into a really important news report and is discussed to death
by hundreds of thousands of people with the attention span of gnats...
but at least it _is_ discussed, and reaches their brains.

whereas i can't remember - ever - seeing an exciting newsreport in
the technical press about something that the mozilla foundation is
doing (i mean technical details discussion). the only exciting new
thing to be coming out of the mozilla foundation, recently, is B2G.
the rest has basically been the same old boring firefox releases, and
that's not really "news".

i'd like to say more but as i have no idea if this will even be
received i'll wait :)

l.

[Matt Brubeck]

On 02/24/2012 05:46 PM, lkcl wrote:
> for example: i note that the B2G project has a "weekly phone
> conference". where is the transcript or an ogg/vorbis copy of each
> and every single one of these conference calls available, online, for
> people outside of the project, who may have something valuable to
> contribute, to review? how can someone participate in these calls
> from outside of the United States? are they even *permitted* to
> participate in such calls?

https://wiki.mozilla.org/B2G#Meetings has dial-in instructions; callers
outside the US can use the +1-650 number, though they will need to pay
long-distance charges. (VOIP services like Skype can help with this.)
Like all Mozilla project meetings, it's open to anyone who wants to
participate.

The same page has links to the agenda and notes from each meeting, for
example:
https://wiki.mozilla.org/B2G/Meeting/2012-02-07

We don't have a consistent system in place for recording phone
conferences, anyone who can help with note taking or transcription is
very welcome.

> additionally it is often incredibly hard to even... remotely find the
> appropriate people or the appropriate place to even begin a discussion
> on a particular topic.

Most of the daily work of the Mozilla project happens on IRC; feel free
to drop in to #developers at almost any time; if you are patient you
will at least get a pointer to the correct person or place.

> perhaps some insights, here, for you: i don't believe that the public
> fully appreciate the significance of the work being done by the
> mozilla foundation. it's "just a web browser", right? so... why
> should anyone pay attention to it?
>
> by contrast, even the silliest little "buhhhhloooggggguhh" post by
> the most random google employee gets a great deal of attention and is
> blown up into a really important news report and is discussed to death
> by hundreds of thousands of people with the attention span of gnats...
> but at least it _is_ discussed, and reaches their brains.

You must not read the same press I do, because believe me, this happens
with Mozilla too -- sometimes to our chagrin, since the press tends to
take random blog comments or tweets out of context and blow them up into
huge "stories"... This happened to me more than once, including:

http://techcrunch.com/2010/12/27/firefox-iphone-2/

Some more current press coverage (all from the past couple weeks):

http://www.extremetech.com/computing/119571-mozilla-partners-up-with-lg-to-combat-apple-and-google-with-its-own-device

http://arstechnica.com/business/news/2012/02/first-look-mozillas-boot2gecko-mobile-platform-and-gaia-ui.ars

http://www.pcmag.com/article2/0,2817,2400640,00.asp

http://www.webmonkey.com/2012/02/mozillas-persona-project-wants-to-help-manage-your-online-identity/

http://news.cnet.com/8301-30685_3-57376349-264/mozillas-plan-for-2012-break-the-ecosystem-lock/

http://arstechnica.com/business/news/2012/02/mozilla-antarctica-community-site-launched-by-coolest-firefox-fans.ars

The notes for the weekly Mozilla all-hands project meeting (broadcast on
air.mozilla.org every Monday) includes a list of press stories every week:
https://wiki.mozilla.org/WeeklyUpdates

[lkcl]

On Feb 25, 3:09 am, Matt Brubeck <mbrub...@mozilla.com> wrote:
> On 02/24/2012 05:46 PM, lkcl wrote:
>
> >   for example: i note that the B2G project has a "weekly phone
> > conference".  where is the transcript or an ogg/vorbis copy of each
> > and every single one of these conference calls available, online, for
> > people outside of the project, who may have something valuable to
> > contribute, to review?  how can someone participate in these calls
> > from outside of the United States?  are they even *permitted* to
> > participate in such calls?
>

> https://wiki.mozilla.org/B2G#Meetingshas dial-in instructions; callers

> outside the US can use the +1-650 number, though they will need to pay
> long-distance charges.  (VOIP services like Skype can help with this.)

yes... but on a personal note, as a principled free software (libre)
developer who has to turn down employment and contract opportunities
because they request CVs in .DOC format or they demand total ownership
and rights to all work done during the work period, my income over the
past 3 years has averaged around £500 per month (no that's not a joke,
or a spelling mistake), meaning that spending money even on phone
calls on skype is out of the question.

it's also at 2am :)

> Like all Mozilla project meetings, it's open to anyone who wants to
> participate.

that's good to hear.

> >   additionally it is often incredibly hard to even... remotely find the
> > appropriate people or the appropriate place to even begin a discussion
> > on a particular topic.
>
> Most of the daily work of the Mozilla project happens on IRC; feel free
> to drop in to #developers at almost any time; if you are patient you
> will at least get a pointer to the correct person or place.

a one-step-removed process. perhaps that is understandable, given
the complexity and scope of the mozilla project. i grok the patience
thing - i worked with the #htc-linux crowd when it was small: working
in different timezones we asked tim rikers to set up an irc logging
bot so that at least questions could be reviewed and answered that
way, on a 24hr delay if it came to it.

> You must not read the same press I do, because believe me, this happens
> with Mozilla too -- sometimes to our chagrin, since the press tends to
> take random blog comments or tweets out of context and blow them up into
> huge "stories"...  This happened to me more than once, including:

:) slashdot, el reg, wired...

> http://news.cnet.com/8301-30685_3-57376349-264/mozillas-plan-for-2012-break-the-ecosystem-lock/

now this _is_ interesting. i'll post separately about it, explaining
why.

> The notes for the weekly Mozilla all-hands project meeting (broadcast on
> air.mozilla.org every Monday) includes a list of press stories every week:https://wiki.mozilla.org/WeeklyUpdates

ah now this is the sort of thing that imo really ought to be on the
footer of every mozilla web site page, saying "News".

[Boris Zbarsky]

On 2/25/12 1:50 AM, lkcl wrote:
>> https://wiki.mozilla.org/B2G#Meetingshas dial-in instructions; callers
>> outside the US can use the +1-650 number, though they will need to pay
>> long-distance charges. (VOIP services like Skype can help with this.)
>

> meaning that spending money even on phone
> calls on skype is out of the question.

The point is that with Skype you should be able to dial into the
toll-free 1-800 number for the conference no matter where you're
physically located...

The timezone issue is harder to manage, of course.

-Boris

[Matt Brubeck]

On 02/24/2012 10:50 PM, lkcl wrote:
>> https://wiki.mozilla.org/B2G#Meetingshas dial-in instructions; callers
>> outside the US can use the +1-650 number, though they will need to pay
>> long-distance charges. (VOIP services like Skype can help with this.)
>

> it's also at 2am :)

Note that even the scheduling was discussed in the open, though of
course (a) it's never possible to accomodate everyone's needs and (b)
the last discussion involved the participants at the time, not anyone
who came along later:

https://groups.google.com/forum/?fromgroups#!searchin/mozilla.dev.b2g/urgent/mozilla.dev.b2g/isgsN18HlMs/AKe_YkUV_9EJ

[Nukeador]

2012/2/25 lkcl <luke.l...@gmail.com>

> On Feb 9, 1:16 pm, Gervase Markham <g...@mozilla.org> wrote:
>

> > 2) There is no community decision-making process; decisions are taken
> > (either deliberately or accidentally) 'behind closed doors'
>

> for example: i note that the B2G project has a "weekly phone
> conference". where is the transcript or an ogg/vorbis copy of each
> and every single one of these conference calls available, online, for
> people outside of the project, who may have something valuable to
> contribute, to review? how can someone participate in these calls
> from outside of the United States? are they even *permitted* to
> participate in such calls?
>

I think you bring up a very important topic to improve the way Mozilla
employees work.

- Give more visibility to meetings. Maybe a central page listing all
meetings, times in UTC.
- Try to schedule meetings to a time that most people can attend if
possible. (15 UTC is working for Reps Council and we are in 7 different
time zones)
- Record and document every meeting for later review and for people that
couldn’t attend. People from the community could help attending meetings
they like and helping documenting, it's a way to engage volunteers too.
- Use easier ways to participate in the meetings. Skype/Phone call
doesn't work well for a lot of participants. There are other solutions 10
times better than skype (better audio quality, open source... like mumble
audio server).

There are many ways to we all improve this, and it will help both sides,
employees knowing more about the community and the community knowing more
from the employees.

Regards.
--
Rubén Martín (Nukeador)
Mozilla Reps Council member
http://mozilla-hispano.org
http://twitter.com/mozilla_hispano
http://facebook.com/mozillahispano

[Justin Dolske]

On 2/28/12 6:07 AM, Nukeador wrote:

> I think you bring up a very important topic to improve the way Mozilla
> employees work.

I'd generally disagree -- and this thread is already waaaaay off the rails.

> - Give more visibility to meetings. Maybe a central page listing all
> meetings, times in UTC.

This is already done for a number of meetings. It should be the norm,
but realistically the incremental gain is often small. Meetings are dull
and boring unless you're actively involved in the work going on, in
which case you're probably already in the meetings.

> - Try to schedule meetings to a time that most people can attend if
> possible. (15 UTC is working for Reps Council and we are in 7 different
> time zones)

This is nearly impossible to solve. We can't hold every meeting at 15:00
UTC, nor can we pick times that work for everyone in such a distributed
environment. It's already often difficult enough to schedule meetings
around the people who _must_ be there!

> - Record and document every meeting for later review and for people that
> couldn’t attend. People from the community could help attending meetings
> they like and helping documenting, it's a way to engage volunteers too.

I think most folks running meetings would love for help doing this. It's
been tried a number of times before, and people often abandon it because
it's a lot of effort that often has little visible benefit (I'm not
saying it has _no_ benefit, just that it's hard to directly see it
helping someone who reads the page later).

> - Use easier ways to participate in the meetings. Skype/Phone call
> doesn't work well for a lot of participants. There are other solutions 10
> times better than skype (better audio quality, open source... like mumble
> audio server).

The phone (telco/voip/skype) is, alas, still the most stable option.
We've already been using various videoconferencing systems (Polycom,
Vidyo, iChat, various flavors of Air Mozilla, etc) a lot as part of
these meetings, and their success under real conditions, and at scale,
is often unacceptable or poor. Much effort is already going into ways to
improve this, aiui.

Justin

[Majken "Lucy" Connor]

To swing back to the original suggestion, I think the public meetings
(that many people can't make) are too often held up as the way for the
community to participate. You shouldn't have to be able to make it to
phone meetings to participate and follow. I am really happy to have
found this discussion of extending the module system and giving
orientation to new hires.

[Benoit Jacob]

Realistically, non-employees don't care about phone/video meetings. In the Graphics team, we've been doing all we could to advertize our weekly video confcalls, but we've never had any non-paid volunteer ever attend them. The most we ever had was a couple of employees from other companies.

So, I would keep our phone/video meetings open, unchanged, but not place too much hope in them. The community is elsewhere: bugzilla, mailing lists, IRC.

Benoit


> _______________________________________________
> governance mailing list
> gover...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/governance
>