2006-02-27 - Summary of mozilla.org staff meeting

[Gervase Markham]

2006-02-27 - Summary of mozilla.org staff meeting
-------------------------------------------------

Present: aravind, autonome, bc, beltzner, bienvenu, brendan, bsmedberg,
chofmann, coop, davel, dria, dveditz, enn, graydon, jay, Jesse, josh,
jst, justdave, justdave, justin, karen, marcia, mconnor, mitchell,
mrbkap, mscott, myk, pike, polvi, preed, rebron, rob_strong, sicking,
stuartp, timr, vlad

*Around the World, Around the World*

- jlilly and schrep are in Japan for a Mozilla Japan event
    - http://www.mozilla-japan.org/events/200603/seminar
- The Mozilla Japan staff are planning to come to MozHQ soon, perhaps
  for the quarterly all hands meeting
- cbeard and pkim are at FOSDEM and talking with ad agencies in London

*Firefox 1.0.8*

- keep finding critical security bugs before release
- hoping to get them in today and get the builds started (about 3 days
  later than last scheduled date)

*Firefox 1.5.0.2*

- http://wiki.mozilla.org/Firefox:1.5.0.2:Schedule
- hope to have it wrapped by Friday, about 16 bugs left to land
- turns out this works well since the team is busy testing 1.0.8
- still aiming for published release date
- QA is going to feel the crunch as testing requirements for Firefox 2
  increase

* Suite 1.7.x *

- shaver and beard will come up with a crisp message about the
  support/maintenance path for Suite/Seamonkey

* Firefox 2 *

- http://wiki.mozilla.org/Firefox2
- need to finish product requirements document, based on that we can
  come up with a better schedule that has more realistic dates (still
  aiming at 3Q2006)
- discussion on wiki.mozilla.org/Firefox2 and
  [hidden email]
- mitchell: so we need to get that first document in place and then get
  a much more global understanding of what Firefox 2 is, and when it's
  coming, because it's coming up quick
- sicking: when we do platform fixes, we're landing on trunk and the 1.8
  branch almost automatically, is that slowing us down?
   - shaver: I think that the things we're taking there are known-wanted
     compatibility fixes. Anything we put in 1.8 should come through the
     trunk. Haven't seen anyone complaining yet. So far it's been pretty
     conservative stuff (crash fixes, etc) and we should be trying to
     take them earlier than later, but if this starts to be a problem we
     should back those things out to minimize churn.
   - mconnor: as long as we're maintaining API compatibility, it
     shouldn't slow us down at all

*Trunk/Firefox 3*

- cairo has been turned on by default on windows trunk builds
- we've also started to move to VC8
- there's been some pain points, but things are working pretty well
- preed: need to figure out what the tinderbox build farm needs to look
  like in terms of compilers
- mscott: want to point out that stuart and vlad did an excellent job in
  assisting with that transition
- things are looking good for making the move to cairo on all platforms
- sicking: when places landed on trunk/branch, Tp went up by 100% ; we
  should avoid that sort of thing happening again.
   - brendan: regression tests should be run locally before patches of
     that size are dropped on the trunk
   - sicking: we need some sort of rules about what size of regressions
     will cause automatic backout
   - brendan: those are the rules for sheriffing, and if we need to be
     more aggressive there, we need to talk about it. currently sheriff
     is #developers, but maybe that's too distributed
   - shaver and brendan to take this issue to drivers@

*Other Engineering*

- bsmedberg: if you notice interesting linux distribution packaging
  issues with Firefox, or XULRunner, please let me know, I'm trying to
  build a list
- shaver: just so you know, we've been trying to go top-down to
  address this with the major linux distributors
- mitchell: it's a big discussion, and there are lots of issues to be
  explored; shaver and jlilly have been digging into this, but go,
  benjamin!

*Marketing*

- Extend Firefox contest winners will be announced this week

*Foundation*

- FOSDEM went well, look for Gerv's blog post soon
- Foundation is sponsoring a booth at the CSUN Conference on Technology
  for People with Disabilities
- Frank will be in California next week for the Mozilla Foundation Board
  meeting
- Progress is being made on the Mozilla Code Relicensing
- Chris Blizzard's recent trip to India was interesting, and shows that
  there's some opportunity there if we can find the actors to make it
  happen
- mitchell is still looking at the history of "choice and innovation" as
  the Mozilla Mission Statement, and hopes to get something published
  about that soon

Mike (Beltzner)
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Darin Fisher-2]

I've been meaning to ask... are these meetings mozilla.org staff
meetings or mozilla.com staff meetings?  They seem to have morphed
into the latter.  Is there a reason why these meetings are not open to
the entire mozilla development community?

-Darin



On 3/6/06, Gervase Markham <[hidden email]> wrote:

> 2006-02-27 - Summary of mozilla.org staff meeting
> -------------------------------------------------
>
> Present: aravind, autonome, bc, beltzner, bienvenu, brendan, bsmedberg,
> chofmann, coop, davel, dria, dveditz, enn, graydon, jay, Jesse, josh,
> jst, justdave, justdave, justin, karen, marcia, mconnor, mitchell,
> mrbkap, mscott, myk, pike, polvi, preed, rebron, rob_strong, sicking,
> stuartp, timr, vlad
>
> *Around the World, Around the World*
>
> - jlilly and schrep are in Japan for a Mozilla Japan event
>     - http://www.mozilla-japan.org/events/200603/seminar
> - The Mozilla Japan staff are planning to come to MozHQ soon, perhaps
>   for the quarterly all hands meeting
> - cbeard and pkim are at FOSDEM and talking with ad agencies in London
>
> *Firefox 1.0.8*
>
> - keep finding critical security bugs before release
> - hoping to get them in today and get the builds started (about 3 days
>   later than last scheduled date)
>
> *Firefox 1.5.0.2*
>
> - http://wiki.mozilla.org/Firefox:1.5.0.2:Schedule
> - hope to have it wrapped by Friday, about 16 bugs left to land
> - turns out this works well since the team is busy testing 1.0.8
> - still aiming for published release date
> - QA is going to feel the crunch as testing requirements for Firefox 2
>   increase
>
> * Suite 1.7.x *
>
> - shaver and beard will come up with a crisp message about the
>   support/maintenance path for Suite/Seamonkey
>
> * Firefox 2 *
>
> - http://wiki.mozilla.org/Firefox2
> - need to finish product requirements document, based on that we can
>   come up with a better schedule that has more realistic dates (still
>   aiming at 3Q2006)
> - discussion on wiki.mozilla.org/Firefox2 and
>   [hidden email]
> - mitchell: so we need to get that first document in place and then get
>   a much more global understanding of what Firefox 2 is, and when it's
>   coming, because it's coming up quick
> - sicking: when we do platform fixes, we're landing on trunk and the 1.8
>   branch almost automatically, is that slowing us down?
>    - shaver: I think that the things we're taking there are known-wanted
>      compatibility fixes. Anything we put in 1.8 should come through the
>      trunk. Haven't seen anyone complaining yet. So far it's been pretty
>      conservative stuff (crash fixes, etc) and we should be trying to
>      take them earlier than later, but if this starts to be a problem we
>      should back those things out to minimize churn.
>    - mconnor: as long as we're maintaining API compatibility, it
>      shouldn't slow us down at all
>
> *Trunk/Firefox 3*
>
> - cairo has been turned on by default on windows trunk builds
> - we've also started to move to VC8
> - there's been some pain points, but things are working pretty well
> - preed: need to figure out what the tinderbox build farm needs to look
>   like in terms of compilers
> - mscott: want to point out that stuart and vlad did an excellent job in
>   assisting with that transition
> - things are looking good for making the move to cairo on all platforms
> - sicking: when places landed on trunk/branch, Tp went up by 100% ; we
>   should avoid that sort of thing happening again.
>    - brendan: regression tests should be run locally before patches of
>      that size are dropped on the trunk
>    - sicking: we need some sort of rules about what size of regressions
>      will cause automatic backout
>    - brendan: those are the rules for sheriffing, and if we need to be
>      more aggressive there, we need to talk about it. currently sheriff
>      is #developers, but maybe that's too distributed
>    - shaver and brendan to take this issue to drivers@
>
> *Other Engineering*
>
> - bsmedberg: if you notice interesting linux distribution packaging
>   issues with Firefox, or XULRunner, please let me know, I'm trying to
>   build a list
> - shaver: just so you know, we've been trying to go top-down to
>   address this with the major linux distributors
> - mitchell: it's a big discussion, and there are lots of issues to be
>   explored; shaver and jlilly have been digging into this, but go,
>   benjamin!
>
> *Marketing*
>
> - Extend Firefox contest winners will be announced this week
>
> *Foundation*
>
> - FOSDEM went well, look for Gerv's blog post soon
> - Foundation is sponsoring a booth at the CSUN Conference on Technology
>   for People with Disabilities
> - Frank will be in California next week for the Mozilla Foundation Board
>   meeting
> - Progress is being made on the Mozilla Code Relicensing
> - Chris Blizzard's recent trip to India was interesting, and shows that
>   there's some opportunity there if we can find the actors to make it
>   happen
> - mitchell is still looking at the history of "choice and innovation" as
>   the Mozilla Mission Statement, and hopes to get something published
>   about that soon
>
> Mike (Beltzner)
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Darin Fisher-2]

On 3/6/06, Gervase Markham <[hidden email]> wrote:
> - sicking: when places landed on trunk/branch, Tp went up by 100% ; we
>   should avoid that sort of thing happening again.
>    - brendan: regression tests should be run locally before patches of
>      that size are dropped on the trunk
>    - sicking: we need some sort of rules about what size of regressions
>      will cause automatic backout
>    - brendan: those are the rules for sheriffing, and if we need to be
>      more aggressive there, we need to talk about it. currently sheriff
>      is #developers, but maybe that's too distributed


Guys, the decision was made to enable places on the trunk at the FF2
planning meeting.  We knew it would have issues, but we felt that it
was worth it to get it enabled to help expedite the feature.  As I
recall, everyone at that meeting was in agreement with this plan.
Yes, not everyone was at the meeting, and that makes it hard to make
exceptional decisions such as the one that was made, so perhaps
communication could have been better?

When the performance problems hit, Brett and others scrambled to fix
the problems.  Eventually, the feature was reverted to being disabled
by default.  Improvements were made, and then the feature was
re-enabled.  Each time it was enabled, we learned several very
valuable things.  For example, we learned about difficult-to-reproduce
data loss bugs, and those bugs have been getting fixed.  Having this
feature enabled in some nightly builds was invaluable.  I think it
would have been a huge mistake to disable places after that first
round of bad numbers from our performance regression tests.

That said, I agree that it is good to run as many regression tests as
is feasible prior to checkin.  We now have a dedicated Tp server at
our office, and Brett is in the process of setting up a dedicated Tp
client machine so we can more accurately test changes that may impact
Tp.  I think that's a step in the right direction.


> shaver and brendan to take this issue to drivers@

Huh?  Why discuss this on the private drivers mailing list?  What will
that solve?  Why not discuss this in the open with the development
community?  (I sent mail before to drivers asking why it had to be a
closed mailing list, and I was given "good" reasons.  Stuff like this,
however, makes me quite dismayed.)

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Ben Goodger]

Darin Fisher wrote:
>> shaver and brendan to take this issue to drivers@
>
> Huh?  Why discuss this on the private drivers mailing list?  What will
> that solve?  Why not discuss this in the open with the development
> community?  (I sent mail before to drivers asking why it had to be a
> closed mailing list, and I was given "good" reasons.  Stuff like this,
> however, makes me quite dismayed.)

The Mozilla project, even within the context of a single project
(Firefox) has too many distinct, mysteriously populated groups. This is
a source of great confusion to many contributors.

In my opinion, we need to focus on using /these/ (lists.mozilla.org)
/public/ discussion lists for all project related communications where
people are seeking consensus or resolution.

I asked yesterday in IRC where the canonical place for development
discussion was and the answer shaver gave me was "here" (#developers). I
don't think that's good enough for the long term viability of the
project. People need to see how and why decisions were made.
This was a problem with Firefox development and part of the reason why I
evangelized folk to use the dev-apps-firefox group so strongly.

I don't want to just complain though. I want to help. Is anyone else
interested in tackling this?

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[beltzner]

On 3/8/06, Ben Goodger <[hidden email]> wrote:
> In my opinion, we need to focus on using /these/ (lists.mozilla.org)
> /public/ discussion lists for all project related communications where
> people are seeking consensus or resolution.

As I understood things, /those/ (lists.mozilla.org) discussion lists
are meant to be more stable in terms of heirarchy and existence (ie:
there will always be a dev.planning, there will always be a
dev.apps.firefox) whereas /these/ (mail.mozilla.org) lists are meant
to be fluid and based on subprojects. Thus, discussion about
development of Firefox goes in dev.apps.firefox, but discussion about
the Bon Echo project management goes to [hidden email], since the
Bon Echo project will end in a relatively short time, but Firefox
development will go on forever.

Perhaps we should close bonecho@ and move that discussion into
dev.planning, though. I'd be fine with that. Should we do that with
all the lists at mozilla.org?

> I don't want to just complain though. I want to help. Is anyone else
> interested in tackling this?

Very. My ENTJ brain yearns for structure and easing entry and
understanding of where people go to participate/research certain
decisions. If one asked me, I would propose that the best way to do
this would be:

- a wiki page is used as the "home" for each project, release & feature
- projects point to 1..n releases, releases point to 1..n features
- features can exist that aren't targeted to a specific release
- the wiki page holds documentation, plans, decisions, meeting notes, etc
- the wiki pages link to the appropriate discussion forums for that thing

That way the more permanent things have a home on the web (with
completely visible revision history, etc) and pointers to the more
transient discussion forums. Whereever possible, the wiki records of
decision points should link to the discussion forum threads (thanks,
Google Groups)

</rambling>

cheers,
mike

--
-------
mike beltzner, user experience lead, mozilla corporation
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Gervase Markham]

Mike Beltzner wrote:
> Perhaps we should close bonecho@ and move that discussion into
> dev.planning, though. I'd be fine with that. Should we do that with
> all the lists at mozilla.org?

I haven't looked at the list of lists, but it seems to me to make sense
to try and have as much discussion as possible in long-lived (and
therefore more complete and easily-searchable) groups.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Gervase Markham]

Darin Fisher wrote:
> I've been meaning to ask... are these meetings mozilla.org staff
> meetings or mozilla.com staff meetings?  They seem to have morphed
> into the latter.

They were mozilla.org staff meetings. Then they sort of became
Foundation meetings. When the Corporation was founded, they became sort
of sequential staff and Corporation meetings.

staff used to discuss more confidential items than is now the case; a
lot of the business development stuff, for example, is now with the
Corporation.

This ties into the as-yet-unsettled question of the role of mozilla.org
staff in the new world.

> Is there a reason why these meetings are not open to
> the entire mozilla development community?

It's certainly arguable that the type of meeting they now are should be
open to more people.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Gervase Markham]

Ben Goodger wrote:
> I asked yesterday in IRC where the canonical place for development
> discussion was and the answer shaver gave me was "here" (#developers). I
> don't think that's good enough for the long term viability of the
> project. People need to see how and why decisions were made.

Sure. Although we should probably also have a web-accessible log of the
IRC channel.

> This was a problem with Firefox development and part of the reason why I
> evangelized folk to use the dev-apps-firefox group so strongly.

And I think it's made a really big difference. Thank you for doing that.

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Mike Pinkerton]

Ben wrote:
"I don't want to just complain though. I want to help. Is anyone else
interested in tackling this?"

I'm interested. Anything that can improve the community's communication is in all our best interests.

-Pink

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Ben Goodger]

Gervase Markham wrote:
> Mike Beltzner wrote:
>> Perhaps we should close bonecho@ and move that discussion into
>> dev.planning, though. I'd be fine with that. Should we do that with
>> all the lists at mozilla.org?
>
> I haven't looked at the list of lists, but it seems to me to make sense
> to try and have as much discussion as possible in long-lived (and
> therefore more complete and easily-searchable) groups.

I agree. When bugs or specific issues are discussed in a project
management meeting/list and the effect hits a bug (being minused, or
some other such change), people often wonder what happened or why.

Should we start a communication grouplet (group of folk) whose focus is
ensuring these issues get fixed? I think this is one of the reasons this
longstanding problem has never been fully addressed. I know you've been
doing a lot of hard work Gerv, but imagine you'd appreciate some help :-)

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Darin Fisher-2]

On 3/8/06, Mike Beltzner <[hidden email]> wrote:

> On 3/8/06, Ben Goodger <[hidden email]> wrote:
> > In my opinion, we need to focus on using /these/ (lists.mozilla.org)
> > /public/ discussion lists for all project related communications where
> > people are seeking consensus or resolution.
>
> As I understood things, /those/ (lists.mozilla.org) discussion lists
> are meant to be more stable in terms of heirarchy and existence (ie:
> there will always be a dev.planning, there will always be a
> dev.apps.firefox) whereas /these/ (mail.mozilla.org) lists are meant
> to be fluid and based on subprojects. Thus, discussion about
> development of Firefox goes in dev.apps.firefox, but discussion about
> the Bon Echo project management goes to [hidden email], since the
> Bon Echo project will end in a relatively short time, but Firefox
> development will go on forever.
>
> Perhaps we should close bonecho@ and move that discussion into
> dev.planning, though. I'd be fine with that. Should we do that with
> all the lists at mozilla.org?

You mean all the lists at mail.mozilla.org?  Yes, I think so.  I'd imagine
that people have a hard time finding all the various mailing lists and
discussion forums involved with this project.  I definitely think that
bonecho@ should go away.  I suspect that very few people even
know about it.  We should simplify.  list.mozilla.org all the way :-)

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Robert Kaiser]

Darin Fisher schrieb:
> On 3/8/06, Mike Beltzner <[hidden email]> wrote:
>> Perhaps we should close bonecho@ and move that discussion into
>> dev.planning, though. I'd be fine with that. Should we do that with
>> all the lists at mozilla.org?
>
> You mean all the lists at mail.mozilla.org?  Yes, I think so.

I actually think the mail.mozilla.org lists should stay where they are a
contact address for a very specific group of people, and should only be
used as an information channel to contact those groups, or to
communicate internal stuff that is _not_ meant to be public. This
applies to e.g [hidden email], [hidden email], I guess also
[hidden email] and [hidden email] ;-)

But everything that is of community interest and should be made public,
esp. discussions about development decisions, etc. should really go to
[lists|news].mozilla.org so that a wider community can read what's going
on, can take part, and it's permanently available.

In many cases, it might be a good idea to have a wiki document that
reflects the outcome of discussions (i.e. drafts/documents planned or
done work), it should probably get drafted with a proposal and changed
according to the lists/news discussion.

Fast ad-hoc communcation, development help and fun talk probably still
have a good reason to happen on IRC, but if development decisions are
made there, those should be reflected where appropriate (wiki,
lists/news and/or relevant bug reports), avoid to completely hide those
from the community. The same is true for stuff coming out of the
remaining mail.m.o lists.

I think this way, we could leverage the tools and infrastructure we have
while also holding up community communication, which should be an
important topic in an open source project...


Perhaps it would additionally be a good thing to have someone write up a
weekly report of happening in the mozilla.org community, like Kernel
Traffic or Wine Weekly News do, but I guess it would not only be hard to
summarize the plethora of things happening around here, but also to find
someone who'd write up that report...

Actually, the staff meeting minutes are the nearest thing to such a
report that we have - and they cover only staff meetings, not a broader
range of dicussions like the others do...

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Darin Fisher-2]

On 3/8/06, Gervase Markham <[hidden email]> wrote:

> Darin Fisher wrote:
> > I've been meaning to ask... are these meetings mozilla.org staff
> > meetings or mozilla.com staff meetings?  They seem to have morphed
> > into the latter.
>
> They were mozilla.org staff meetings. Then they sort of became
> Foundation meetings. When the Corporation was founded, they became sort
> of sequential staff and Corporation meetings.
>
> staff used to discuss more confidential items than is now the case; a
> lot of the business development stuff, for example, is now with the
> Corporation.
>
> This ties into the as-yet-unsettled question of the role of mozilla.org
> staff in the new world.
>
> > Is there a reason why these meetings are not open to
> > the entire mozilla development community?
>
> It's certainly arguable that the type of meeting they now are should be
> open to more people.

OK, I'm glad to hear that you agree.  How do we make this change happen?

-Darin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Ben Goodger]

Darin Fisher wrote:
> OK, I'm glad to hear that you agree.  How do we make this change happen?

Thinking on a global scale, I think we need to identify all of the
closed discussion groups that could be public, refactoring where
necessary and then discuss this with the owners of each venue. Feel free
to tell me to buzz off if you want to focus on staff first.

Oh and, is this the right list to be discussing this sort of thing?

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[beltzner]

> Oh and, is this the right list to be discussing this sort of thing?

Almost surely not, since I'm pretty sure that the principals of the
Mozilla Corporation -- who do indeed use these meetings to discuss
confidential Mozilla Corporation -- aren't reading this list.

Right now the meetings seem to serve two purposes:

 1. Act as an all-hands weekly update for employees of MoCo
 2. Discuss the status of the primary MoCo/MoFo projects

I think what you really want/mean to suggest is that the second part
be separated out and placed in some sort of public forum. Or maybe you
mean both parts ... you tell me! :)


cheers,
mike

--
-------
mike beltzner, user experience lead, mozilla corporation
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Ben Goodger]

Mike Beltzner wrote:
> I think what you really want/mean to suggest is that the second part
> be separated out and placed in some sort of public forum. Or maybe you
> mean both parts ... you tell me! :)

I'm thinking about all such project lists. A few come to mind aside from
  bonecho... Darin's original point was that the non-confidential(*)
discussions that take place on drivers should be open.

What else? mozilla2.0, marketing-private etc. A lot of dead lists too.

(* things not relating to requests from companies relating to sensitive
product info etc communicated to mozilla for consideration in
prioritization)

-Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[beltzner]

On 3/8/06, Ben Goodger <[hidden email]> wrote:
> I'm thinking about all such project lists. A few come to mind aside from
>   bonecho... Darin's original point was that the non-confidential(*)
> discussions that take place on drivers should be open.

Yes, but we got onto meetings didn't we? Or did I totally misread?

> What else? mozilla2.0, marketing-private etc. A lot of dead lists too.

I know that marketing-private is being used quite a bit, and should
remain private, as it includes things like confidential press
announcements that can't be released due to contractual obligations,
etc. Those things are going to happen, so there will still need to be
some private lists, just like there are some private bugs. Brendan's
running mozilla2.0, but from the content that's going by in that list,
there's nothing that couldn't be done in the public.

> (* things not relating to requests from companies relating to sensitive
> product info etc communicated to mozilla for consideration in
> prioritization)

Ah, yes, you're already on this point :)

cheers,
mike

--
-------
mike beltzner, user experience lead, mozilla corporation
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Scott MacGregor]

Mike Pinkerton wrote:
> Ben wrote:
> "I don't want to just complain though. I want to help. Is anyone else
> interested in tackling this?"
>
> I'm interested. Anything that can improve the community's communication
> is in all our best interests.
>
> -Pink

I'm interested in helping to solve this transparency problem as well!

Simplifying and reducing the number of closed lists is one way and
there's already discussion in this thread on that front. Solving this
problem also requires a lot of self discipline whenever we submit
something. Who am I sending this to? Is that list public? Is there a
reason why my post shouldn't go to an open list? I find it's very easy
to fall into this trap if I'm not consciously thinking about it when
posting to say drivers, something which could just as easily go to the
planning newsgroup. It's an easy habit to slip into.

With regards to Darin's comments specifically about drivers,  I agree
that a lot of the drivers conversations could (and should) be more
public. There will still be a need for a private list for drivers. For
instance, during the release cycle for security releases, we'll
frequently discuss and talk about respins for unannounced, confidential
security bugs and other more release driver centric issues that can't be
made public.

Maybe we need more watchdogs on drivers to help keep us honest. But that
would just help one specific case and not the other private or
semi-private mailing lists we use.

-Scott
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Axel Hecht]

Gervase Markham wrote:

> Darin Fisher wrote:
>> I've been meaning to ask... are these meetings mozilla.org staff
>> meetings or mozilla.com staff meetings?  They seem to have morphed
>> into the latter.
>
> They were mozilla.org staff meetings. Then they sort of became
> Foundation meetings. When the Corporation was founded, they became sort
> of sequential staff and Corporation meetings.
>
> staff used to discuss more confidential items than is now the case; a
> lot of the business development stuff, for example, is now with the
> Corporation.
>
> This ties into the as-yet-unsettled question of the role of mozilla.org
> staff in the new world.
>
>> Is there a reason why these meetings are not open to
>> the entire mozilla development community?
>
> It's certainly arguable that the type of meeting they now are should be
> open to more people.

I would like to add that the corporation-only does contain sensitive
information. Another thing is that the mofo-moco common part doesn't
have that many discussions, but is mostly reporting (which is OK given
that 40 people participate).

Maybe the term "mozilla.org staff meeting" doesn't really cut it anymore
for these meetings. I take it that the original purpose of that meeting
was taken over by the steering committee meetings?

One way to make the staff meetings more open could be to reuse the
scheme that beltzner uses for running the bonecho meetings, writing the
agenda on the wiki, getting the line item holders to fill in and then go
over that during the meeting.

As there needs to be one meeting including possibly confidential stuff,
I'd rather not open up "staff meeting" to a wider audience itself, as
that seems like it would just create yet another meeting with little
additional value. Or lead to more opaqueness inside the corporation again.

Axel
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

[Ben Goodger]

Mike Beltzner wrote:
> I know that marketing-private is being used quite a bit, and should
> remain private, as it includes things like confidential press
> announcements that can't be released due to contractual obligations,
> etc. Those things are going to happen, so there will still need to be
> some private lists, just like there are some private bugs. Brendan's
> running mozilla2.0, but from the content that's going by in that list,
> there's nothing that couldn't be done in the public.

OK. Rather than continue here with incomplete data and midway through a
thread that started about something else, I'd like to adjourn this
somewhere else. I'm going to start another thread on mozilla.dev.general
for lack of a more specific place.

-
Ben
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning