Monday meetings -- staff, contributors, etc
Mitchell Baker
Darin asked about the Monday meetings that started out as mozilla.org
staff and now include mozilla foundation and mozilla corporation
employees. Renaming certainly makes sense, but something more could be
useful.
My intitial thought has been to agree with Darin-- these meetings
discuss topics that would be useful to other contributors as well. In
particular, we usually start with a discussion of where we are with
releases. Our wiki info is often broken out by particular products,
it's been useful to summarize these in a discussion where we are with
the various alpha, betas for 1.0.x, 1.5.0.x, 2, etc.
So I've started working on a plan to reconstitute the meetings. We need
to separate out things that related to employment, HR, confidential and
partner relationships and get these topics into some other forum. We
will also need to specify the purpose of the meeting, who attends and
why, and so on. This turns out to be a lot of work, requiring
something akin to a policy document. My working, incomplete proposal is
below. Comments welcome.
I'm also interested in your thoughts on whether this is something that
is worth doing. I'm more than happy to spend the time to develop the
framework for this if it's worthwhile (as are Frank Hecker and Zak of
the Mozilla Foundation as well. I'll let Zak decide what ). But if
people feel improved open newsgroups solve the problem and that they
wont' really attend a meeting then we might prioritize our efforts
elsewhere.
Name: General Status Update [better name ideas? Something like "Weekly
Sanity Check" has been suggested.]
Purpose: keep a critical mass of contributors who are actively involved
in Firefox and Thunderbird on the same page -- schedules, releases,
issues, features, etc.
Other Goals:
--Make the most effective use of the precious time of our active
contributors.
-- Take and publish minutes or summaries. Recognize that these aren't a
substitute for continued communcation in the problem solving forums.
Type of Meeting:
-- "Air Traffic Control." To date, these meetings have been to ferret
out surprises, to find places where we expect everyone to have the same
understanding and we're surprised when we don't.
-- These are not primarily problem solving meetings. We're looking for
areas where we may have unknown problems or differing expectations.
Problem solving and communication should occur in the standard forums.
-- These are not a informational meeting for those generally interested
in Mozilla, Firefox or Thunderbird. We should undoubtedly find ways
forums for this, but this is not the place to do so.
-- These are not meetings about "how to work with mozilla" or "how to
build on top of Mozilla" or "how to develop with Mozilla technology."
We need to communicate on these topics as well, but we don't need our 30
or 40 or X most active contributors all in one place to do this -- we
can communicate effectively using less of our most limited resources.
So it's not a meeting for extension developers, for example.
Who
-- people expected to provide leadership in developing our products,
release cycles, features, platform development, IT infrastructure,
developer and general communications, etc.
-- one key indicator is whether branch management, porting bugs from one
branch to another, the differences between the 1.0.x, the 1.5.0. x
branches and the trunk are important to your work. If not, this
probably isn't the meeting for you.
-- people must be able to keep confidential info confidential
How:
-- Like the security group, or drivers, or super-reviewers.
-- Start with a group, let that group decide who else should be involved.
-- People can ask to join, and be vetted by the group.
-- We should figure out how people stop being part of the group (this is
true of a range of roles in the project, it's recently been pointed out
that people shouldn't necessarily automatically keep every status forever)
-- I'd like to include Mozilla Foundation employees, since the
Foundation governs the project. I'd also like to include Mozilla
Corporation employees as well since corporation employees are hired to
coordinate the entire project.
Logistics
-- We'll have to figure out the logistics of this. Not sure if there is
a limit on how many people can call in, whether people care about
knowing who's on the phone, whether some web conferencing solution would
be helpful, or what.
Mitchell
Zak Greant
To sum up, I am happy to help. For more details and comments on the
ideas, read on.
If the choice is made to move ahead with the meetings, I am happy to
support Mitchell's work here.
> Name: General Status Update [better name ideas? Something like "Weekly
> Sanity Check" has been suggested.]
Weekly Sanity Check is cool. :)
What about, "Weekly Contributor Meeting", if something more formal is desired.
> Purpose: keep a critical mass of contributors who are actively
> involved in Firefox and Thunderbird on the same page -- schedules,
> releases, issues, features, etc.
>
> Other Goals:
>
> --Make the most effective use of the precious time of our active contributors.
> -- Take and publish minutes or summaries. Recognize that these aren't
> a substitute for continued communcation in the problem solving forums.
I might add one other thing here; it seems that it is important for
active contributors to have one place to go where they can be kept
up-to-date on the most key issues - this might really help the projects
act more effectively and coherently.
> Type of Meeting:
>
> -- "Air Traffic Control." To date, these meetings have been to ferret
> out surprises, to find places where we expect everyone to have the same
> understanding and we're surprised when we don't.
> -- These are not primarily problem solving meetings. We're looking for
> areas where we may have unknown problems or differing expectations.
> Problem solving and communication should occur in the standard forums.
> -- These are not a informational meeting for those generally interested
> in Mozilla, Firefox or Thunderbird. We should undoubtedly find ways
> forums for this, but this is not the place to do so.
> -- These are not meetings about "how to work with mozilla" or "how to
> build on top of Mozilla" or "how to develop with Mozilla technology."
> We need to communicate on these topics as well, but we don't need our
> 30 or 40 or X most active contributors all in one place to do this --
> we can communicate effectively using less of our most limited
> resources. So it's not a meeting for extension developers, for example.
Sounds spot on to me.
No further comments.
--
Zak Greant
Mozilla Foundation, Ombudslizard
http://zak.greant.com/ombudslizard
Axel Hecht
I'm personally a bit bothered. Meetings like this usually don't start
before 8pm for me, with unkown end. Or, that evening is spent. I guess
that the cost of a meeting for on-site employees is much less, but still
to be considered, as a meeting usually disrupts ones workflow much more
than just the actual time spent on that meeting.
So doubling that cost should pay back. Moving up with meeting costs will
make it more work to actually endourse communication about non-public
topics, and I kind of doubt that the private meeting wouldn't turn into
discussing topics that could be done in public. Rescheduling the same
thread into the public meeting sounds like something costly, too.
The scheme that beltzner put up for fx2,
http://wiki.mozilla.org/Firefox2/StatusMeetings, seems to give a good
amount of visibility without having everyone to participate in the call.
Note that the pages are actually filled out with the reports before the
meeting, so those are not "what Gerv caught up on the phone"-type
summaries. Being on the phone myself, there is really a technical limit
on what one hears and can add to the minutes.
Maybe we could set up a more general meeting to be held once a month,
either replacing the staff meeting or in addition to that, to do a more
free-form governance/reporting brainstorm meeting.
Axel