Mozilla Project Weekly Status mtg: likes/dislikes?
Tim Riley
usefulness of the Monday 11am PDT mtg.
Who is the audience?
I think it is anyone in the community (includes volunteers, people in
other companies working on Mozilla projects/products, and MoCo members)
interested in highlights of who is going what for the Project. This is
broader than the Tuesday Platform or Wednesday Delivery meeting audiences.
What is the purpose:
I think it is to provide medium high (10,000ft level) and broad
highlights of what is going on around the Mozilla project. This
includes project highlights (ex: Firefox, Thunderbird, Labs) along with
other related project activities (ex: Mozilla Foundation, L10n,
community marketing, add-ons, and community testing just to name a few).
Also, this is a great opportunity to acknowledge great work by friends
of the tree.
What parts of the all-hands do people like and dislike? I see a point
made that schedules and activities for Firefox major releases and
security releases overlap between the Monday all-hands, Tuesday Platform
meeting and even the Wednesday Delivery meeting. But other topics don't
overlap or at least there are some aspects that are broader/higher level
than Firefox; like Metrics, IT infrastructure (project IT, *not* MoCo
IT), Marketing/PR, QA community.
One way to simplify the meeting is to put the Firefox and Thunderbird
schedules and highlights in the wiki and then I could just ask if anyone
has any questions about this. That gives people affected by, but not
necessary in every Platform or Delivery mtg, a chance to see and ask
questions about these projects. If no questions or comments, then we
have just reduced three separate speakers, down to 10sec.
Do people like the Community Marketing and Foundation updates? I do.
These are areas where I can't follow all the blogs and various other
postings on a daily basis. The weekly roll-up is great. That is true for
most of the other areas in the meeting.
Does the All-Hands make more sense and offer a valuable forum if it
provides a 10,000 foot view of cross functional project topics?
Emphasizing the boarder topics like l10n, add-ons, web dev, Mozilla
foundation that people have trouble keeping up with on a regular basis
seems valuable.
If you have a few moments, look over this list of agenda items and tell
us if you would keep, change, or delete the item from how it currently
is presented:
1 Friends of the Tree
2 Development Updates
* 2.1 Firefox
* 2.2 Gecko
* 2.3 Branch work: Firefox 3.0.x / Firefox 3.5.x / Thunderbird
2.0.0.x
* 2.4 TB 3
* 2.5 Mobile
* 2.6 IT
* 2.7 Release Engineering
* 2.8 QA
* 2.9 Security
* 2.10 Marketing/PR
* 2.11 Support
* 2.12 Metrics
* 2.13 Evangelism
* 2.14 Labs
* 2.15 Developer Tools
* 2.16 Add-ons
* 2.17 Webdev
* 2.18 L10n
3 Foundation Updates
4 Misc
* Introductions
* Intern show and tell
--Tim
L. David Baron
> What is the purpose:
> I think it is to provide medium high (10,000ft level) and broad
> highlights of what is going on around the Mozilla project. This
> includes project highlights (ex: Firefox, Thunderbird, Labs) along with
> other related project activities (ex: Mozilla Foundation, L10n,
> community marketing, add-ons, and community testing just to name a few).
> Also, this is a great opportunity to acknowledge great work by friends
> of the tree.
I think the reality is that it has two purposes (the one you give is
basically my #2):
(1) Provide updates that are important to signifcant numbers of
people working on the project or that require feedback from
significant numbers of people across the project. Some examples of
this (some made up): Firefox x.y is shipping on Wednesday, there's
a big server downtime tomorrow, we're thinking about switching to
different wiki software and want feedback, we're working on
redesigning the mozilla.org Website.
(2) Announce highlights of things that have already happened so
that others are aware of and recognize people's contributions.
I want to get the information in (1), which I think totals an
average of 5-10 minutes per meeting, but I don't want to sit through
45 minutes of (2).
If the primary purpose of the meeting is really (2), could we do
something to ensure that all the (1)-type information in the meeting
is also disseminated in other ways that really do reach the breadth
of the community, so that those of us who want (1) but not (2) can
get it efficiently? In other words, can we say that an announcement
in the project meeting is not sufficient notice to the community for
the types of things in (1). (I think *most* of these things are
already widely-enough announced outside the project meeting, but I'm
not confident that all of them are.)
-David
--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
Benjamin Smedberg
> What is the purpose:
> I think it is to provide medium high (10,000ft level) and broad
> highlights of what is going on around the Mozilla project. This
> includes project highlights (ex: Firefox, Thunderbird, Labs) along with
> other related project activities (ex: Mozilla Foundation, L10n,
> community marketing, add-ons, and community testing just to name a few).
> Also, this is a great opportunity to acknowledge great work by friends
> of the tree.
Is a synchronous meeting really the best way to solve that problem?
I feel like people who regularly speak at the meeting (group managers) often
feel the need to say something even if there's not anything especially
important to say. I would feel much more comfortable about the meeting if
people would self-edit before presenting. When people say "there's an update
with links in the wiki", do they really expect that people are going to go
to the wiki, open and read the links? I know I don't, and if I did what is
currently a 30-minute timesink would become a 2-hour timesink.
Another problem is that it's smack in the middle of Monday afternoon and
really cuts up the workday. It was actually a bit better for me in the
former timeslot because it was right at the end of the workday.
> Does the All-Hands make more sense and offer a valuable forum if it
> provides a 10,000 foot view of cross functional project topics?
> Emphasizing the boarder topics like l10n, add-ons, web dev, Mozilla
> foundation that people have trouble keeping up with on a regular basis
> seems valuable.
Often it feels like, as we've grown, the 10k foot view becomes less useful:
the amount of time and energy I'd have to spend keeping the big overview up
to date isn't worth it and wouldn't actually improve the project as a whole
or my particular activities... and I know that I'm probably a lot more
"connected" that most people. That's why we have product leads and managers,
who can spend more time keeping the big picture in mind so that individuals
don't always have to.
In some ways I'd almost prefer a 10 minute recorded video every morning,
where somebody who's been working on something really important could give a
short overview. It would be more total time per week, but it wouldn't cut
into the day and it might cause the content to be better-prepared.
--BDS
chris hofmann
> On Tuesday 2009-09-01 09:37 -0700, Tim Riley wrote:
>
>> I think it is to provide medium high (10,000ft level) and broad
>> highlights of what is going on around the Mozilla project. This
>> includes project highlights (ex: Firefox, Thunderbird, Labs) along with
>> other related project activities (ex: Mozilla Foundation, L10n,
>> community marketing, add-ons, and community testing just to name a few).
>> Also, this is a great opportunity to acknowledge great work by friends
>> of the tree.
>>
>
> basically my #2):
>
> (1) Provide updates that are important to signifcant numbers of
> people working on the project or that require feedback
or I would add "Action."
If the meetings focused more to rally action on key places where more
people could help out that would be a benefit to many, but not all that
attend or listen in on the call.
Once in awhile this happens in the meetings now.
-chofmann
Mike Shaver
> My main issue with the meeting is that it does not really cover project
> highlights, e.g. what is going on with Firefox, Thunderbird, SeaMonkey,
> Calendar, Camino, etc. but that in reality the meeting is 99% about
> Firefox.
It's 100% about what people want to present in the meeting. We
recently adjusted the timing to make it easier for non-Pacific-Time
people to participate, and I would *love* to have someone from
Calendar give an update in the meetings. Likewise with SeaMonkey and
Camino. What should I be getting up to say about Calendar, so that it
would be represented in the project highlights? I don't really know
anything about the project at this point, I have to confess.
It's certainly the case that the talk will be where the action is, so
I wouldn't be surprised to see more Firefox-related stuff in the
meeting than Calendar-related, but that's the case for bug traffic
too, and I would catch some holy hell if I proposed to just make
bugzilla.m.o be about Firefox only!
The meeting is an opportunity for the Mozilla community to present
their work and ask for help and so forth, regardless of which part of
the project they work on. If there isn't sufficient activity or
interest in a part of the project community for someone to even bother
adding it to the roundtable section, I'm not sure what can be done.
I'm all for holding it open until there is something interesting
enough to share, though, regardless of who it comes from.
> You list a lot of projects, but the meeting is not about what's going on
> with community marketing, it is about what#s going on with *Firefox*
> community marketing.
I don't think that would be a bad thing, but I think it's not the
case: service week and the creative collective, plus the foundation's
internet health checkup thing are good examples just from the last 2-3
weeks.
> The same goes for RelEng, QA, Support, Metrics,
> Security, WebDev, L10n, Evangelism, Marketing/PR, Developer Tools,
> Friends of the Tree, Add-ons and Labs and in most cases IT as well.
I'm trying to think of something that Developer Tools has done that is
tied into Firefox -- Bespin and TestSwarm are intentionally
browser-agnostic, and that's been most of their updates of late. Can
you remind me of one?
Mike
Mike Beltzner
> Who is the audience?
> I think it is anyone in the community (includes volunteers, people in
> other companies working on Mozilla projects/products, and MoCo members)
> interested in highlights of who is going what for the Project. This is
> broader than the Tuesday Platform or Wednesday Delivery meeting audiences.
Do you think it's highlights, or something more? Right now our meeting
oscillates between a project status report, a news show, and a set of
calls (pleas?) for input or participation.
Those are different things, and I agree with whomever stated that it
feels like instead of chunking things by organizational unit, we should
chunk by type of information.
> What is the purpose:
> I think it is to provide medium high (10,000ft level) and broad
> highlights of what is going on around the Mozilla project. This includes
> project highlights (ex: Firefox, Thunderbird, Labs) along with other
> related project activities (ex: Mozilla Foundation, L10n, community
> marketing, add-ons, and community testing just to name a few). Also,
> this is a great opportunity to acknowledge great work by friends of the
> tree.
I think project highlights are great, but would hope that various groups
would avoid a laundry list of "What I did this week" and instead think
of presenting things like an (informational!) news segment. Keep each
topic to no more than 30 seconds. Provide links for people to find out more.
The friends of the tree thing is interesting, but I think could be
better served as a community "Thank You Soap Box" segment, perhaps near
the end of the meeting where anyone could step forward and pubicly thank
someone for their contribution. That also would make it bilateral and
participatory, instead of nomination and acceptance based.
> One way to simplify the meeting is to put the Firefox and Thunderbird
> schedules and highlights in the wiki and then I could just ask if anyone
> has any questions about this. That gives people affected by, but not
> necessary in every Platform or Delivery mtg, a chance to see and ask
> questions about these projects. If no questions or comments, then we
> have just reduced three separate speakers, down to 10sec.
I think where dates don't change this is good, but any time a new
project-wide deadline comes up it should be announced, and perhaps again
when it's a week out.
> Do people like the Community Marketing and Foundation updates? I do.
> These are areas where I can't follow all the blogs and various other
> postings on a daily basis. The weekly roll-up is great. That is true for
> most of the other areas in the meeting.
I definitely like hearing about things from areas of the project that
I'm not actively involved in, but again, since there's so much to cover,
which that people would editorialize more. My attention is not free, and
if it gets squandered by Group C, it's even harder for Group D to regain it.
> If you have a few moments, look over this list of agenda items and tell
> us if you would keep, change, or delete the item from how it currently
> is presented:
As mentioned above, I can see times when there could be something or
nothing to say for each of these areas. I think that we should organize
on type of content, not source of content.
cheers,
mike
Gervase Markham
> Who is the audience?
> I think it is anyone in the community (includes volunteers, people in
> other companies working on Mozilla projects/products, and MoCo members)
> interested in highlights of who is going what for the Project. This is
> broader than the Tuesday Platform or Wednesday Delivery meeting audiences.
I think the vital purpose of the Monday event is "community glue".
Particularly for people new to or on the periphery of the project, it's
a great way to see what's going on and to feel part of something which
is much larger than oneself or one's small area of work. I say "event"
because it's actually more like a video podcast than a "meeting". And
that's fine IMO. It also does the "10,000 foot" role well - keep
everyone peripherally aware of major events in other areas of the project.
I think that the current format meets these goals reasonably well -
certainly much better than it did, say, two years ago. However (if there
were agreement that this were the aim) there are some things we could
change to make it better. In particular, it should be a maximum of a
half an hour in length, not including intern show-and-tell (I think it's
managed that most weeks recently), and it should be recorded and made
available immediately so people can watch it at their own convenience.
It would also be good if people from timezones for which the time was
inconvenient such as the NZ office could submit video reports, and they
could be inserted live into the session (and played in MV on the big
screen for people participating there).
It may well be that people who are core contributors have less need of
such an event than people who are a bit farther out. We need to make
sure that, when assessing its role and usefulness, we don't just get
input from people right at the centre of the project.
> If you have a few moments, look over this list of agenda items and tell
> us if you would keep, change, or delete the item from how it currently
> is presented:
Might it be better to try and get consensus on purpose before doing
detailed surgery on the agenda?
Gerv
Deb Richardson
----- "Gervase Markham" <ge...@mozilla.org> wrote:
> I think the vital purpose of the Monday event is "community glue".
I think this is part of it, but certainly not all of it.
If we were to step back and start from scratch:
1) What are the primary goals we have?
2) What secondary effects are we hoping to achieve?
3) What audience(s) are we trying to reach?
My take on this is:
1) Goals
* Communicating key information about projects, direction,
governance, status, events, calls-to-action, and other
activities within the greater Mozilla Project.
2) Secondary effects
* Strengthening community coherence and the sense of being
part of something big and important.
* Recognizing top contributors and doling out the whuffie.
* Reinforcing the fundamental vision, goals, and values of
the Mozilla Project.
* Ensuring openness and transparency.
3) Audience
* All contributors within the Mozilla Project.
* The silent mass of almost-contributors who are interested
in what we're doing, and trying to figure out how to get
involved.
* Interested observers -- industry watchers, the tech press,
and similar.
What's your take?
Perhaps once we have a better understanding of the goals,
effects, and audience we'll be able to more easily figure
out what we should be doing here.
~ deb
Lukas Blakk
environment and the setup is like this:
* 2 facilitators and 1 time keeper run the meeting (anywhere from 80 -
300 people attend)
* The facilitators call for topics from the floor to create the agenda
(this could be replaced with ahead of time wiki input)
* The facilitators take a moment to organize the topics in logical
chunks based on type of topic
* Each person who submitted a topic is then called on to introduce it,
announce, whatever it is they needed to say
* People can then respond to this topic for an allotted amount of time
(limit 1 minute per person's response) -- and this step is probably
not needed in Mozilla's case since we don't do a lot of talking back
at the meeting
* When the topics have run out we have "appreciation time" where
people can just speak of whatever/whoever they are enthused or
grateful about
What's interesting to me about this kind of meeting is that it lets
people share thoughts and start discussions that can be continued
after the meeting ends. What often happens when a particularly juicy
topic comes up is that a second meeting of interested parties is
planned to go more in depth. This allows the large group meeting to
carry on. Though this kind of meeting is not one where actions
happen, where people are assigned to tasks, or where any types of
decisions are made and while that can be frustrating to the community
sometimes it's still a great forum for connecting with your fellow
community members. Regardless of the occasional boredom that might
come from listening to someone talk about something that you feel
doesn't affect you I think it's important for large communities who
want to be close and engaged with each other to practice this kind of
gathering and sharing of information.
Lukas
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
L. David Baron
> * People can then respond to this topic for an allotted amount of time
> (limit 1 minute per person's response) -- and this step is probably not
> needed in Mozilla's case since we don't do a lot of talking back at the
> meeting
I think we used to have more discussion at the meetings, but I think
that stopped as:
* the meetings got larger
* the meetings became more about "what happened last week" than
"what's happening in the coming weeks"
I'd be more likely to attend a meeting that has discussion. I can
always just read about the status updates in a meeting that has no
discussion (and that's quite a bit faster than listening).
Tim Riley
> On Wednesday 2009-09-02 09:55 -0400, Lukas Blakk wrote:
>> * People can then respond to this topic for an allotted amount of time
>> (limit 1 minute per person's response) -- and this step is probably not
>> needed in Mozilla's case since we don't do a lot of talking back at the
>> meeting
>
> I think we used to have more discussion at the meetings, but I think
> that stopped as:
>
> * the meetings got larger
I am confused by the length issue that several people have raised. The
Project Status meetings average between 20-30 minutes (not including
intern show and tell). We can't have a meaningful live discussion on a
project this size in less than 20 mins.
As I recall when I started almost 4 years ago, the all-hands around the
big table in Bldg K lasted 45-60 minutes. Maybe it is not the actual
length but more that they feel longer now(?). :(
>
> * the meetings became more about "what happened last week" than
> "what's happening in the coming weeks"
This is a great suggestion. These should be about action, impact,
participation, and teamwork rather then retrospection.
Tim Riley
>> * People can then respond to this topic for an allotted amount of time
>> (limit 1 minute per person's response) -- and this step is probably not
>> needed in Mozilla's case since we don't do a lot of talking back at the
>> meeting
>
> I think we used to have more discussion at the meetings, but I think
> that stopped as:
>
> * the meetings got larger
I am confused by the length issue that several people have raised. The
Project Status meetings average between 20-30 minutes (not including
intern show and tell). We can't have a meaningful live discussion on a
project this size in less than 20 mins.
As I recall when I started almost 4 years ago, the all-hands around the
big table in Bldg K lasted 45-60 minutes. Maybe it is not the actual
length but more that they feel longer now(?). :(
>
> * the meetings became more about "what happened last week" than
> "what's happening in the coming weeks"
This is a great suggestion. These should be about action, impact,
participation, and teamwork rather then retrospection.
>
Philip Chee
> On Tue, Sep 1, 2009 at 5:17 PM, Simon Paquet<si...@gmx.de> wrote:
>> My main issue with the meeting is that it does not really cover project
>> highlights, e.g. what is going on with Firefox, Thunderbird, SeaMonkey,
>> Calendar, Camino, etc. but that in reality the meeting is 99% about
>> Firefox.
>
> It's 100% about what people want to present in the meeting. We
> recently adjusted the timing to make it easier for non-Pacific-Time
> people to participate, and I would *love* to have someone from
> Calendar give an update in the meetings. Likewise with SeaMonkey and
> Camino. What should I be getting up to say about Calendar, so that it
> would be represented in the project highlights? I don't really know
> anything about the project at this point, I have to confess.
Oh I just naturally assumed that this was exclusive to MoCo and that
community projects like SeaMonkey were excluded. Somehow I missed the
invite to the SeaMonkey people.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Boris Zbarsky
>> * the meetings got larger
>
> I am confused by the length issue that several people have raised.
That doesn't seem to be the issue dbaron raised, though.
> The Project Status meetings average between 20-30 minutes (not including
> intern show and tell).
Why not including it?
> We can't have a meaningful live discussion on a project this size in less than 20 mins.
Probably true; do we need a meaningful live synchronous
everyone-participates discussion every week?
> As I recall when I started almost 4 years ago, the all-hands around the
> big table in Bldg K lasted 45-60 minutes. Maybe it is not the actual
> length but more that they feel longer now(?). :(
As I said elsewhere, given the scheduling the "feel" length of this
meeting for me is about 4 hours: from end of lunch to end of workday on
Monday. Benjamin said much the same thing.
-Boris
Philip Chee
> The friends of the tree thing is interesting, but I think could be
> better served as a community "Thank You Soap Box" segment, perhaps near
> the end of the meeting where anyone could step forward and pubicly thank
> someone for their contribution. That also would make it bilateral and
> participatory, instead of nomination and acceptance based.
Recently there was some discussion in the #seamonkey channel about
setting up a "Friends of the SeaMonkey Tree" but if SeaMonkey specific
contributors are allowed to be nominated for your FOTT I guess we won't
need to set up our own.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Time travel gives me nosebleeds. - LaForge
* TagZilla 0.066.6
L. David Baron
> On 9/2/09 6:58 AM, L. David Baron wrote:
>> On Wednesday 2009-09-02 09:55 -0400, Lukas Blakk wrote:
>> I think we used to have more discussion at the meetings, but I think
>> that stopped as:
>>
>> * the meetings got larger
>
> I am confused by the length issue that several people have raised. The
> Project Status meetings average between 20-30 minutes (not including
By larger, I meant "more people are present".
Though I think part of the effect I thought was related to the size
might also be that having a fixed set of usual speakers discourages
participation by others.
>> * the meetings became more about "what happened last week" than
>> "what's happening in the coming weeks"
-David
Deb Richardson
----- "Boris Zbarsky" <bzba...@mit.edu> wrote:
> Probably true; do we need a meaningful live synchronous
> everyone-participates discussion every week?
This is sort of the question I was leading towards with my previous mail -- if we have some method of doing what we're trying to do here (maybe a newsletter, maybe a topic-specific multi-author blog, maybe both, maybe something else...) would we really need to have this meeting at all?
The smaller project and team meetings (of which there are many) are probably much better suited to actual discussion due to size, topic-specificity, etc. If there are things that need to be discussed with a larger group, use the Monday-broadcast to inform people of that and invite them to participate during the regular team/project meeting later in the week.
If the general Monday status meeting is used primarily as a way to broadcast information out (which it sort of seems to be), maybe there's a better medium for it?
~ deb
Justin Dolske
> It's 100% about what people want to present in the meeting. We
> recently adjusted the timing to make it easier for non-Pacific-Time
> people to participate, and I would *love* to have someone from
> Calendar give an update in the meetings. Likewise with SeaMonkey and
> Camino.
I think it would be good to hear of important changes from other projects.
OTOH, given the origin of this thread, it's a little ironic to be
talking about adding more content to a meeting some already consider to
be an ineffective use of time!
Justin
Gervase Markham
>> The Project Status meetings average between 20-30 minutes (not
>> including intern show and tell).
>
> Why not including it?
Presumably because Tim views it (as do I) as something which happens
after the meeting for convenience, rather than something which is an
integral part of it.
> As I said elsewhere, given the scheduling the "feel" length of this
> meeting for me is about 4 hours: from end of lunch to end of workday on
> Monday. Benjamin said much the same thing.
When does it happen in your timezone?
Gerv
Gervase Markham
> If the general Monday status meeting is used primarily as a way to
> broadcast information out (which it sort of seems to be), maybe
> there's a better medium for it?
I think there are significant advantages to the current medium. Going on
with my "community glue" theme, it's hard to feel you know someone if
all of your interactions with them are via written communication. Seeing
them live on screen, even for a few minutes, allows you to put a face to
a name, and get some idea of their personality which you will remember
when you next interact with them in written form. Even a photo doesn't
achieve this all that well.
In its ideal form (and I agree we aren't quite there), I would be able
to watch the video and think "Ah, that's Tim, he's in charge of QA. And
that's John - he's in charge of RelEng. And that's Jono, the kung-fu
Ubiquity guy." And so on.
I certainly feel when I'm watching the meeting video that people feel
more real to me. It would be even better, of course, if the stream was
captioned with names like used to happen with the old flash-based
system. More tools to build :-)
Gerv
Gervase Markham
> My take on this is:
>
> 1) Goals
> * Communicating key information about projects, direction,
> governance, status, events, calls-to-action, and other
> activities within the greater Mozilla Project.
>
> 2) Secondary effects
> * Strengthening community coherence and the sense of being
> part of something big and important.
... and part of achieving that coherence is making the community seem
smaller and more personal.
> * Recognizing top contributors and doling out the whuffie.
> * Reinforcing the fundamental vision, goals, and values of
> the Mozilla Project.
> * Ensuring openness and transparency.
>
> 3) Audience
> * All contributors within the Mozilla Project.
> * The silent mass of almost-contributors who are interested
> in what we're doing, and trying to figure out how to get
> involved.
> * Interested observers -- industry watchers, the tech press,
> and similar.
>
> What's your take?
I'd pretty much agree with all that. I don't know where "...in a form
which as many project members as possible are willing to consume" fits
in - which speaks to length (if it's a broadcast) and to format - but
apart from that, you've got it.
Gerv
Boris Zbarsky
> Presumably because Tim views it (as do I) as something which happens
> after the meeting for convenience, rather than something which is an
> integral part of it.
This might be a corporation-specific issue, but the mozilla corporation
all-hands meeting is scheduled for "a few minutes after the project
status meeting" (including the intern stuff). So in practice one has to
at least keep half an ear on it just so one knows when the othermeeting
starts... Granted, I think that's a problem with the corporation
meeting, not the status meeting per se.
>> As I said elsewhere, given the scheduling the "feel" length of this
>> meeting for me is about 4 hours: from end of lunch to end of workday on
>> Monday. Benjamin said much the same thing.
>
> When does it happen in your timezone?
In the new timeslot, 2pm. So after lunch I typically have about 1.5
hours before the meeting and about 1.5-2 hours after (depending on how
long the meeting runs).
-Boris
Boris Zbarsky
> I think there are significant advantages to the current medium. Going on
> with my "community glue" theme, it's hard to feel you know someone if
> all of your interactions with them are via written communication. Seeing
> them live on screen, even for a few minutes, allows you to put a face to
> a name, and get some idea of their personality which you will remember
> when you next interact with them in written form. Even a photo doesn't
> achieve this all that well.
I'd buy this if the video stream of the meeting were viewable. It
hasn't been, for me: lots of pauses, lots of buffering, skips, etc.
So the meeting is being audio-only anyway over here.
A working (say non-streamed if that's what it takes) video that I could
watch at my convenience would be a much better medium for me, at least.
-Boris
Simon Paquet
>> My main issue with the meeting is that it does not really cover
>> project highlights, e.g. what is going on with Firefox,
>> Thunderbird, SeaMonkey, Calendar, Camino, etc. but that in
>> reality the meeting is 99% about Firefox.
> It's 100% about what people want to present in the meeting.
I know, but I see two problems here:
1. It seems to me that it is not widely known that this meeting isn't
a MoCo-, MoMo-only thing. i know that I only learned of its
inclusiveness when dmose told me about it.
2. This leads to chicken-egg problem: if the meeting is 99% about
Firefox, the meeting will be seen as a Firefox-only meeting. If the
meeting is seen a Firefox-only meeting, no people from other projects
will show up.
> We recently adjusted the timing to make it easier for
> non-Pacific-Time people to participate, and I would *love* to have
> someone from Calendar give an update in the meetings. Likewise with
> SeaMonkey and Camino. What should I be getting up to say about
> Calendar, so that it would be represented in the project highlights?
> I don't really know anything about the project at this point, I
> have to confess.
I guess I could set myself a recurring task, to update the meeting wiki
page with some details about Calendar once a week. You, as the former
project lead, could then give an update on things ;)
> It's certainly the case that the talk will be where the action is,
> so I wouldn't be surprised to see more Firefox-related stuff in the
> meeting than Calendar-related, but that's the case for bug traffic
> too, and I would catch some holy hell if I proposed to just make
> bugzilla.m.o be about Firefox only!
I have no problem with Firefox dominating the agenda. Like you said,
there's certainly more action in the Firefox space than in the Calendar
or Camino space. My issue was mainly that the meeting is dominated
more by Firefox than I think is appropriate. Firefox issues/events may
cover 80%-85% of the mozilla project, but not 99% IMO.
Simon
--
Thunderbird/Calendar Localisation (L10n) Coordinator
Thunderbird l10n blog: http://thunderbird-l10n.blogspot.com
Calendar website maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Robert Kaiser
> Mike Shaver wrote on 01. Sep 2009:
>> We recently adjusted the timing to make it easier for non-Pacific-Time
>> people to participate, and I would *love* to have someone from
>> Calendar give an update in the meetings. Likewise with SeaMonkey and
>> Camino. What should I be getting up to say about Calendar, so that it
>> would be represented in the project highlights? I don't really know
>> anything about the project at this point, I have to confess.
>
> I guess I could set myself a recurring task, to update the meeting wiki
> page with some details about Calendar once a week. You, as the former
> project lead, could then give an update on things ;)
Since the time was shifted, I have been watching the meeting at least
over video most of the time, sometimes even dialed in. I still was
unsure as to if and when in what place in the meeting to give a status
update on SeaMonkey.
Robert Kaiser
Gervase Markham
> This might be a corporation-specific issue, but the mozilla corporation
> all-hands meeting is scheduled for "a few minutes after the project
> status meeting" (including the intern stuff). So in practice one has to
> at least keep half an ear on it just so one knows when the othermeeting
> starts... Granted, I think that's a problem with the corporation
> meeting, not the status meeting per se.
Hmm. Yes, I keep forgetting the Corporation meeting follows on, and this
makes the whole shebang a much bigger deal for MoCo folk. It's also true
that the MoCo meeting can't be viewed later offline (I assume doing that
regularly would be frowned upon, even if it is recorded :-)
So perhaps the fix here is to do intern show-and-tell _before_ the All
Hands? That would also teach them things about keeping to time ;-) Then
people who are less interested in that can turn up only for the all
hands part.
Gerv
Gervase Markham
> I'd buy this if the video stream of the meeting were viewable. It hasn't
> been, for me: lots of pauses, lots of buffering, skips, etc.
>
> So the meeting is being audio-only anyway over here.
>
> A working (say non-streamed if that's what it takes) video that I could
> watch at my convenience would be a much better medium for me, at least.
OK. So we need to track down these problems - if only to make sure it's
not issues with our <video> implementation.
Unfortunately, all our <video> hackers are asleep during the meeting ;-)
Perhaps we need to point the Air Mozilla camera at something moving for
a few days (a fish tank? ;-) and give them access to the streaming
server as well, so they can look at it.
(Was it better when we used Mogulus, or did you not watch it back then?)
Gerv
Gervase Markham
> 1. It seems to me that it is not widely known that this meeting isn't
> a MoCo-, MoMo-only thing. i know that I only learned of its
> inclusiveness when dmose told me about it.
OK. So if this issue still isn't fixed, how would we fix it? Post a "by
the way, did you know...?" message to the relevant newsgroups?
Gerv
Gervase Markham
> Since the time was shifted, I have been watching the meeting at least
> over video most of the time, sometimes even dialed in. I still was
> unsure as to if and when in what place in the meeting to give a status
> update on SeaMonkey.
If you add "Seamonkey Update" to the wiki agenda, you'll get asked to
give it at that point in the meeting.
Gerv
Robert Kaiser
> A working (say non-streamed if that's what it takes) video that I could
> watch at my convenience would be a much better medium for me, at least.
In my experience, using the video stream with a non-browser viewer makes
it much more usable (and my browser not wanting to give me working audio
on this machine makes this option even more relevant). I'd guess though
that we are not using the best ogg encoder on the video yet as well.
Robert Kaiser
Boris Zbarsky
> OK. So we need to track down these problems - if only to make sure it's
> not issues with our <video> implementation.
We have bugs on this, by the way.
But it might also just be that the stream being pushed out is too
high-bandwidth for my connection...
> (Was it better when we used Mogulus, or did you not watch it back then?)
This is the first time I've heard of Mogulus, so I didn't watch it back
then. ;)
-Boris
Robert O'Callahan
> Boris Zbarsky wrote:
>> A working (say non-streamed if that's what it takes) video that I could
>> watch at my convenience would be a much better medium for me, at least.
>
> In my experience, using the video stream with a non-browser viewer makes
> it much more usable (and my browser not wanting to give me working audio
> on this machine makes this option even more relevant).
Hmm, I'd heard the opposite. But yes, viewing the stream with VLC for
example is a good way to determine whether the problems are in the
client or the stream.
Rob
Mark Surman
Tim, Deb and Gerv: thanks for taking the initiative on this and for
making it a constructive conversations.
After today's status meeting, folks in the Toronto office took a few
minutes to discuss this topic. I'll let people post their own thoughts
in detail, but some highlights included:
1. Most people believe we need a mechanism to keep in touch with
what's up across the whole of Mozilla. That's the goal we should keep
our eye on.
2. It's not just a matter of employees vs. not, but also of connecting
across the different Mozilla organizations. This is our only regular
mechanism to do that.
3. The current Monday meetings do this, but the format could get
better. One approach is to introduce more drama and focus into the
meetings. Two ideas we bounced around:
a. Limit each group to one or two items per week.
b. Create a rotating 'project (or 'team') update' time slot where
teams provide much more detailed info and future plans.
Who knows if these are the right specific approaches. The main point
we discussed is that things might be better if teams had to decide
what's most important to communicate rather than listing everything
they are working on.
Based on the discussion here, many people think this meeting is
important.
ms
Boris Zbarsky
> 1. Most people believe we need a mechanism to keep in touch with
> what's up across the whole of Mozilla. That's the goal we should keep
> our eye on.
> 3. The current Monday meetings do this
For what it's worth, they don't really for me. I find it very difficult
to make out what's being talked about, and rarely hear things that are
not in either the meeting agenda wiki or planet.mozilla.org blog posts.
I have no problem with the meeting existing in addition to those, of
course, since it seems to work for some people, as long as important
announcements are not limited to the meeting (so that not attending the
meeting doesn't mean you miss them).
-Boris
Gervase Markham
> For what it's worth, they don't really for me. I find it very difficult
> to make out what's being talked about, and rarely hear things that are
> not in either the meeting agenda wiki or planet.mozilla.org blog posts.
It would be good if we could do more technically to help watchers
understand who is speaking and what their area is. Although perhaps you
know most of the people, so it wouldn't help you.
It may also be that we admit that the meeting is not designed to be
required viewing for every single project member.
> I have no problem with the meeting existing in addition to those, of
> course, since it seems to work for some people, as long as important
> announcements are not limited to the meeting (so that not attending the
> meeting doesn't mean you miss them).
If they are important and mentioned in the meeting, they should
certainly also be on the meeting wiki page.
Gerv
Boris Zbarsky
> It would be good if we could do more technically to help watchers
> understand who is speaking and what their area is. Although perhaps you
> know most of the people, so it wouldn't help you.
Right. My problem is being unable to tell what the _topic_ is half the
time.
> It may also be that we admit that the meeting is not designed to be
> required viewing for every single project member.
Right. At the moment it claims to be.
> If they are important and mentioned in the meeting, they should
> certainly also be on the meeting wiki page.
Would be nice, yes.
-Boris
Benjamin Smedberg
> It may also be that we admit that the meeting is not designed to be
> required viewing for every single project member.
I sure hope we already admit that already! Because there are many people,
even within MoCo, who don't attend due to travel, vacations, timezones, or
just breaking up an otherwise productive workday. I don't think you'll be
able to change that even if you wanted to!
>> I have no problem with the meeting existing in addition to those, of
>> course, since it seems to work for some people, as long as important
>> announcements are not limited to the meeting (so that not attending the
>> meeting doesn't mean you miss them).
>
> If they are important and mentioned in the meeting, they should
> certainly also be on the meeting wiki page.
That sounds undesirable. Even though I run the scripts which end up posting
the meeting wiki notes to planet mozilla, even when reading it's hard to
figure out which things are important and which are noise.
The general rule has been/should be: if there's an important announcement
that the Mozilla community as a whole needs to be aware of, a post should go
to mozilla.dev.planning. No other mechanism is going to be sufficient.
--BDS
Mitchell Baker
To me, the most important goal of the Monday meetings is to strengthen
the Mozilla project. I'm not set on how we do this. In particular,
I'm not at all sure that the "overview of everything" approach we're
using now is the best use of time to strengthen the project.
I've put some alternative possibilities below. I can thing of other
possibilities, hopefully you can too. I've include a few here to get a
reaction to the idea of doing something quite different. Feel free to
say "No! I want updates." I certainly don't want to do a lot of work
on something new and find out later people prefer the current approach,
with some tweaks.
Possible ways a regular, semi-structured "all-hands" project meeting
could be used to strengthen the Mozilla project:
1. We have a set of goals for the Mozilla project -- the 2010 goals.
We could spend some time each week discussing progress, changes and
threats to these goals. This would include some product stuff , and
we'd have to learn how to talk about products in this context. But of
course this is part of what we should be thinking about anyway, so that
could be a good effect. It might also reduce the duplication and give
the product teams i time to think about the big picture beyond the bugs.
2. Discussion of topics that relate to our mission --- threats,
progress, etc. For example, ideas about what Mozilla might do for the
millions who access the Web through a phone, if at all. Or perhaps a
discussion of the trend toward far-reaching laws, like the one in France.
3. In depth discussion of a product, or technology, or activity. For
example, periodically it will be helpful for lots of people to
understand a security vulnerability (what does "escape the quotes" mean,
anyway? ) Or a deep discussion of in outreach / marketing activity.
Or something related to getting to know the members of some of our very
highly distributed teams, such as the localization and support
communities.
4. Discussions / brainstorming with other organizations / projects that
are building "open" communities -- either on the web or elsewhere.
For example, what would "open government" folks like to know about /
from Mozilla? What about "open science" or "open education?" The One
Web Day folks are interested in much the same things we are -- maybe a
discussion with them would be interesting / good for Mozilla as a project.
Changing the format to focus on something like this will take more work,
and a few people focused on it. And we probably want to keep space
for important announcements, so there's some thinking to do there as well.
Any thoughts?
Mitchell
Benjamin Smedberg
> Possible ways a regular, semi-structured "all-hands" project meeting
> could be used to strengthen the Mozilla project:
It's not clear whether you mean for these meetings to continue to be "all
hands", or "come if you feel like it". All of the things you propose are
discussions, and I don't think we've ever found a way for super-large
discussions to work effectively, especially when many of the people are
remote. A lot of what you're talking about sounds like the public brownbags
which Mozilla hosts occasionally, where attendance is not *expected*.
Perhaps those should be formalized a bit more?
I'm not opposed to any of the ideas you mention, although I imagine that I
wouldn't want to attend the meetings all the time: only if a topic was
relevant to the current set of things I'm working on. For instance, I would
be really interested in a good presentation from the Firefox UI guys (I
happened to go to one when I was in Mountain View and it was really
informative). I'd also be interested in a presentation/discussion on open
education. But I really wouldn't want to go to a Thunderbird goals/roadmap
meeting, or to a deep discussion of some marketing/outreach activity.
--BDS
Mitchell Baker
have something that most people attended, or tried to attend most of the
time. Complete self-selection makes it hard to build shared understanding.
I used the examples with some thought. Understanding what a security
vulnerability is seems important to me across functions, even if most
people aren't involved in fixing it.
An understanding of a central outreach marketing effort also seems
important to me *accross the organization.* Outeach is how we identify
the Mozilla project and our products to the world. That's a critical
piece of our success / failure, and I think we're a lot better off if
everyone has some overview of that.
The current "overview of everything" strategy touches one slice of this
-- a weekly snippet of activities. I'm currently uncomfortable with
losing all of this where people self-select to what they are already
interested / involved with.
I recognize people self-select by not listening, or not watching for
those outside the time zone.
mitchell
Benjamin Smedberg
> Yeah, this is a good topic. My starting point is that I would like to
> have something that most people attended, or tried to attend most of the
> time. Complete self-selection makes it hard to build shared understanding.
>
> I used the examples with some thought. Understanding what a security
> vulnerability is seems important to me across functions, even if most
> people aren't involved in fixing it.
>
> An understanding of a central outreach marketing effort also seems
> important to me *accross the organization.* Outeach is how we identify
> the Mozilla project and our products to the world. That's a critical
> piece of our success / failure, and I think we're a lot better off if
> everyone has some overview of that.
>
> The current "overview of everything" strategy touches one slice of this
> -- a weekly snippet of activities. I'm currently uncomfortable with
> losing all of this where people self-select to what they are already
> interested / involved with.
It's the *discussion* part in particular that makes me uncomfortable. It
might be helpful to see a 20-30 minute presentation on marketing or security
vulns or whatever, especially if I could do it asynchronously at a
convenient time of day. If you scheduled them in advance, this would give
the presenter time to make a compelling presentation instead of the
haphazard notes that seem to be the norm now.
But I've never seen a useful 30-minute interactive discussion with more than
5 people: by the time you've framed the discussion and taken one
question/answer you're done! And all of the timezone issues make it likely
that the discussion will focus on people in Mozilla Standard Time, which
seems like the opposite of what you actually want.
--BDS
Gervase Markham
the meeting is no longer in any sense an "All Hands". That doesn't make
the ideas necessarily bad, but it's worth noting that we are
fundamentally changing the character of what's going on.
Also as Ben says, I'm not sure a more discussion-y direction would work
very well. It seems to me that the project is now of sufficient size
that we can't have a useful discussion involving everyone. Even at a
Firefox Plus Summit or similar event, we never try and have a discussion
with the whole group - the closest we get are presentations from the
front with questions afterwards and an IRC back-channel. And that's with
everyone in the same room; if many of the participants are on the phone,
it would be even harder.
I was more thinking of moving in the opposite direction. I can't
remember who suggested it, but someone suggested moving towards a
presented podcast. I'm not sure if we'd need it to be presented, but I
do think that's a better way to think about it - The Week in Mozilla, if
you like. Each group presents a report of what's happened that's cool
and what's upcoming that's important. It would be great if these reports
could be prepared beforehand, either video or audio (better quality than
over the phone), submitted and then played into the stream, with
captions to say who is speaking and what their area is.
On 18/09/09 06:26, Mitchell Baker wrote:
> 1. We have a set of goals for the Mozilla project -- the 2010 goals. We
> could spend some time each week discussing progress, changes and threats
> to these goals. This would include some product stuff , and we'd have to
> learn how to talk about products in this context. But of course this is
> part of what we should be thinking about anyway, so that could be a good
> effect. It might also reduce the duplication and give the product teams
> i time to think about the big picture beyond the bugs.
In contrast to what we have now, several of the directions you suggest
would inevitably lead to quite high-level discussion. I'd also wonder
whether our progress and the nature of the threats to our goals changes
on a week-to-week basis, in a way which requires more structured
discussion than a water-cooler conversation about Oracle buying Sun.
> 3. In depth discussion of a product, or technology, or activity. For
> example, periodically it will be helpful for lots of people to
> understand a security vulnerability (what does "escape the quotes" mean,
> anyway? ) Or a deep discussion of in outreach / marketing activity. Or
> something related to getting to know the members of some of our very
> highly distributed teams, such as the localization and support communities.
I think that videocasts on these subjects would be great things to do,
and make available to the community, assuming those who have the
knowledge also have the time, but this feels to me like something
separate from Mondays.
Gerv