mozilla.org staff, project drivers, and technical oversight
Mike Connor
and I think that in places it is hurting us, since we don't have
clear "buck stops here" groups for issues outside of per-module code
decisions, and issues are difficult to bring to resolution without
getting Brendan or Mitchell to exercise executive power and bring
discussion to an end. Even in private conversations with members of
drivers, there is not a clear understanding of the role drivers@m.o
plays, given that to my knowledge, people like Jay, Vlad, Beltzner
and myself are not on that list, yet we're among the most active in
terms of pushing out the actual releases.
I've actually been trying to wrap my head around this for the last
year, since there's been a significant amount of time spent on
discussions and non-decisions. I don't know exactly who belongs in
each bucket, and I suspect that there will be overlap for certain key
people initially, but I think there are three groups that need to
exist, and need to be small and focused enough that everyone in those
groups is playing an active part. These groups would ideally work on
the following principles:
* Small groups, preferably 5-7 people, comprised of active and
committed members
* Members who become inactive should cycle out as appropriate , to
ensure that the group consists of active and responsive individuals
* Issues brought to these groups should be dealt with as active
issues to resolve in a timely fashion (black holes are not an option)
The three groups I see a need for are as follows (sample groups are
to give an idea of the mix of people):
Policy and process (inheriting from the largely-dead staff@m.o and
sort of drivers@m.o, list names are kinda random)
- Make final decisions mozilla.org policy and focus (including
community feedback etc)
- Ensure that strong module ownership is maintained and improved
- sample group: mitchell, frank, dria, myk, brendan, dmose
- Becomes projec...@mozilla.org
Project Management (inheriting from drivers@m.o)
- Release timing/scheduling and active management of releases
- Needs involvement from apps/Gecko/build/QA/products
- This is a core/overall group trying to minimize conflicts and plan
together
- Should be supplemented by driver groups (i.e. dveditz/jay/sicking
are driving the 1.8.x security branches, a larger group is driving
Fx3/1.9)
- Sample group: schrep, mconnor, timr, preed, beltzner, vlad, jay
- Becomes project...@mozilla.org
Technical Oversight (inheriting from drivers@m.o)
- Help ensure that we are prioritizing the right technology initiatives
- Foster better practices across the codebase (APIs on the outside,
unit testing, etc)
- drive technical roadmap and requirements
- Sample Group: Brendan, shaver, bsmedberg, boris, dbaron, roc
- Becomes project-...@mozilla.org
We would probably want to create new list names, with auto-responses
for both staff and drivers explaining the new groups.
Thoughts? I realize this is coming out of nowhere a bit, but I think
its important to establish this structure before the new year,
otherwise we just won't have the time to come to a conclusion.
-- Mike
Axel Hecht
> Its been a long time since we've had traction or a clear vision here,
> and I think that in places it is hurting us, since we don't have clear
> "buck stops here" groups for issues outside of per-module code
> decisions, and issues are difficult to bring to resolution without
> getting Brendan or Mitchell to exercise executive power and bring
> discussion to an end. Even in private conversations with members of
> drivers, there is not a clear understanding of the role drivers@m.o
> plays, given that to my knowledge, people like Jay, Vlad, Beltzner and
> myself are not on that list, yet we're among the most active in terms of
> pushing out the actual releases.
>
> I've actually been trying to wrap my head around this for the last year,
> since there's been a significant amount of time spent on discussions and
> non-decisions. I don't know exactly who belongs in each bucket, and I
> suspect that there will be overlap for certain key people initially, but
> I think there are three groups that need to exist, and need to be small
> and focused enough that everyone in those groups is playing an active
> part. These groups would ideally work on the following principles:
>
> * Small groups, preferably 5-7 people, comprised of active and committed
> members
I guess that the amount of drivers is making it somewhat more tempting
to let things go by with "some other driver is going to handle this".
Giving more focus may help, in particular, it may reduce noise on the
policy/process side.
> * Members who become inactive should cycle out as appropriate , to
> ensure that the group consists of active and responsive individuals
> * Issues brought to these groups should be dealt with as active issues
> to resolve in a timely fashion (black holes are not an option)
>
> The three groups I see a need for are as follows (sample groups are to
> give an idea of the mix of people):
>
> Policy and process (inheriting from the largely-dead staff@m.o and sort
> of drivers@m.o, list names are kinda random)
>
> - Make final decisions mozilla.org policy and focus (including
> community feedback etc)
> - Ensure that strong module ownership is maintained and improved
> - sample group: mitchell, frank, dria, myk, brendan, dmose
> - Becomes projec...@mozilla.org
>
> Project Management (inheriting from drivers@m.o)
>
> - Release timing/scheduling and active management of releases
> - Needs involvement from apps/Gecko/build/QA/products
> - This is a core/overall group trying to minimize conflicts and plan
> together
> - Should be supplemented by driver groups (i.e. dveditz/jay/sicking are
> driving the 1.8.x security branches, a larger group is driving Fx3/1.9)
> - Sample group: schrep, mconnor, timr, preed, beltzner, vlad, jay
> - Becomes project...@mozilla.org
I am on drivers@ these days, being at least on the watch for release
timing etc.
Would this list be the one that is getting the bugmail? Basically,
drivers@ gets an email for any change of a set of bugzilla flags, sounds
like this is the one.
Getting those mails enabled me to have an eye on bugs that sounded like
late-l10n during string freeze, without actually being at each triage
meeting.
Axel
Robert Kaiser
> Project Management (inheriting from drivers@m.o)
>
This sounds good to me, is it planned to have all major apps involved
there? I think it would be good if the project management of all major
sub projects would at least be reading the discussions there, so that
information about Mozilla-wide project planning (e.g. release dates?) is
communicated down to those projects (like, say, SeaMonkey, Camino or
Sunbird).
Robert Kaiser
Robert O'Callahan
Rob
Robert Sayre
> Its been a long time since we've had traction or a clear vision here,
> and I think that in places it is hurting us, since we don't have clear
> "buck stops here"
That might be true. Do we have concrete evidence, or is this just a
general feeling of unease?
> * Issues brought to these groups should be dealt with as active issues
> to resolve in a timely fashion (black holes are not an option)
In all seriousness, black holes are an extremely effective management
strategy. Issues that don't matter a wit are constantly brought to the
attention of groups like drivers@m.o.
Is there concrete evidence here?
>
> The three groups I see a need for are as follows
Whoa. If it's not clear what drivers@m.o does, we should not make three
of them. Maybe we should consider deleting it with no replacement.
I fully agree that drivers@m.o has a poorly defined mission. I think
it's possible that's an indicator of well-designed buck-stoppage.
I've also heard it said that the absence of individual release drivers
on drivers@m.o is a problem. I'm not sure that's true. It does mean that
the authority resting with various release drivers is unclear. Once
again, I'm not sure that's a bad thing.
I would like to see some evidence of damage here. If we find some, does
the fallout consist of bad decisions, upset release drivers, or both?
-Rob
Boris Zbarsky
> That might be true. Do we have concrete evidence, or is this just a
> general feeling of unease?
We've had a number of incidents of release management, module ownership, and
general project direction issues falling through the cracks in the last few
years. It's not just a "general feeling of unease".
> In all seriousness, black holes are an extremely effective management
> strategy. Issues that don't matter a wit are constantly brought to the
> attention of groups like drivers@m.o.
Actually, apart from the incessant blocking/approval bugspam very little that
doesn't matter gets sent to drivers@m.o.
> I fully agree that drivers@m.o has a poorly defined mission. I think
> it's possible that's an indicator of well-designed buck-stoppage.
I don't think we have such buck-stoppage, no.
> I've also heard it said that the absence of individual release drivers
> on drivers@m.o is a problem.
More precisely, there are two problems:
1) When project management discussion _does_ happen on drivers@m.o the release
drivers don't see it.
2) There's no reliable way to contact the release drivers.
> I would like to see some evidence of damage here. If we find some, does
> the fallout consist of bad decisions, upset release drivers, or both?
Most of the fallout is stress for people who are trying to figure out what the
plan is, decisions never getting made, problems effectively being ignored and
allowed to fester, lack of coordination between the various parts of the project.
Simply making it clear that drivers@m.o is defunct would help in one way, at
least -- people would stop worrying about trying to get it to solve the other
issues that exist.
-Boris
Vladimir Vukicevic
Robert Sayre wrote:
> Mike Connor wrote:
> > Its been a long time since we've had traction or a clear vision here,
> > and I think that in places it is hurting us, since we don't have clear
> > "buck stops here"
>
> That might be true. Do we have concrete evidence, or is this just a
> general feeling of unease?
There's plenty of concrete evidence. Just ask anyone who's been told
to "ask drivers" in the last 6 to 12 months whether they actually got a
concrete answer (or even any answer at all -- or even whether they
mailed drivers@ or just mailed dev.apps.firefox!).
> > * Issues brought to these groups should be dealt with as active issues
> > to resolve in a timely fashion (black holes are not an option)
>
> In all seriousness, black holes are an extremely effective management
> strategy. Issues that don't matter a wit are constantly brought to the
> attention of groups like drivers@m.o.
>
> Is there concrete evidence here?
See above. As mconnor said, there are three distinct types of issues
that are brought up to drivers, and different sets of people should be
involved in the distinct decisions.
> > The three groups I see a need for are as follows
>
> Whoa. If it's not clear what drivers@m.o does, we should not make three
> of them. Maybe we should consider deleting it with no replacement.
>
> I fully agree that drivers@m.o has a poorly defined mission. I think
> it's possible that's an indicator of well-designed buck-stoppage.
Not really; that's a well-designed "the buck gets lost here, and
hopefully you'll forget you ever had it" system. If the alternate
solution is that if you want a technical decision made, you talk to
brendan/schrep; if you want a product decision you talk to cbeard; if
you want a mozilla.org decision made you talk to mitchell/frank...
well, that's fine, I have no problem with that. Those people are most
likely going to seek the input from a similar set of people that
mconnor suggested in the three divisions, except that they'll do it in
a much less formal setting (hallway, personal email) that makes it very
difficult to have people outside of moco involved in that decision
making process.
drivers@ right now serves no useful purpose that I can see, and we
really should change it into something useful. Scrapping it entirely
would result in even less outside visibility into that "buck stoppage"
process, but hey, I'm ok with that too.
- Vlad
Robert Sayre
> Robert Sayre wrote:
>> Mike Connor wrote:
>>> Its been a long time since we've had traction or a clear vision here,
>>> and I think that in places it is hurting us, since we don't have clear
>>> "buck stops here"
>> That might be true. Do we have concrete evidence, or is this just a
>> general feeling of unease?
>
> There's plenty of concrete evidence. Just ask anyone who's been told
> to "ask drivers" in the last 6 to 12 months whether they actually got a
> concrete answer
The one time I sent mail to drivers (regarding unreviewed patches in
danger of slipping), it seemed to work.
>>
>> Is there concrete evidence here?
>
> See above.
You claimed it was obvious, but that's not been my experience. That's
just one data point, so I think you should present at least a few others
that contradict it.
> As mconnor said, there are three distinct types of issues
> that are brought up to drivers, and different sets of people should be
> involved in the distinct decisions.
And if you care about any of those issues, you should know who to
contact instead of drivers first. I don't think having three mailing
lists will help. People with something to contribute have many channels
available to them. The only distinguishing characteristic of three more
mailing lists is that the sender is supposed to be entitled to a response.
>
>>> The three groups I see a need for are as follows
>> Whoa. If it's not clear what drivers@m.o does, we should not make three
>> of them. Maybe we should consider deleting it with no replacement.
>>
>> I fully agree that drivers@m.o has a poorly defined mission. I think
>> it's possible that's an indicator of well-designed buck-stoppage.
>
> Not really; that's a well-designed "the buck gets lost here, and
> hopefully you'll forget you ever had it" system. If the alternate
> solution is that if you want a technical decision made
False dichotomy. If you encounter silence, another alternative would be
to assume it's unimportant, make the decision, and tick the review flags
in bugzilla until your manager tells you to work on something else. ;)
>
> drivers@ right now serves no useful purpose that I can see, and we
> really should change it into something useful.
OK, so we should delete it. I don't see how segmentation of the unknown
will result in Something Useful.
> Scrapping it entirely
> would result in even less outside visibility into that "buck stoppage"
> process, but hey, I'm ok with that too.
>
I don't think there's meaningful transparency delta here. It's not like
any of the three proposed lists would be public.
-Rob
Peter Weilbacher
two things happened:
- mozilla.governance was created
- There were a couple of "Minutes from drivers meeting" posted
Well, the former didn't help at all. That group/list has stayed empty
apart from 4 spam messages. The latter was great, but stopped around
April: why?
Or am I confusing things? Because I cannot find the last discussion in
the Google archive any more to read up on it...
Peter.
Axel Hecht
> I somehow remember that the last time there was a discussion like this,
> two things happened:
>
> - mozilla.governance was created
> - There were a couple of "Minutes from drivers meeting" posted
>
> Well, the former didn't help at all. That group/list has stayed empty
> apart from 4 spam messages. The latter was great, but stopped around
> April: why?
No more driver meetings, at least I haven't seen an invite lately. Which
may be a bad idea. I don't totally recall if we dropped them completely
or if we just paused them for release stress and too many scheduling
conflicts and didn't pick them up again.
Axel
Gervase Markham
> The three groups I see a need for are as follows (sample groups are to
> give an idea of the mix of people):
>
> Policy and process (inheriting from the largely-dead staff@m.o and sort
> of drivers@m.o, list names are kinda random)
How do you see this group in relation to the Mozilla Foundation? Or,
conversely, what role (if any) do you see for the Foundation in setting
policy and process?
> - Make final decisions mozilla.org policy and focus (including
> community feedback etc)
> - Ensure that strong module ownership is maintained and improved
> - sample group: mitchell, frank, dria, myk, brendan, dmose
> - Becomes projec...@mozilla.org
>
> Project Management (inheriting from drivers@m.o)
How do you see this group in relation to the Corporation, given that
they as an organisation have been delegated the task of shipping
Firefox(TM) and Thunderbird?
> - Release timing/scheduling and active management of releases
> - Needs involvement from apps/Gecko/build/QA/products
> - This is a core/overall group trying to minimize conflicts and plan
> together
> - Should be supplemented by driver groups (i.e. dveditz/jay/sicking are
> driving the 1.8.x security branches, a larger group is driving Fx3/1.9)
...and each one should have an email alias with a consistent naming
convention.
Gerv
Gervase Markham
> I somehow remember that the last time there was a discussion like this,
> two things happened:
>
> - mozilla.governance was created
> - There were a couple of "Minutes from drivers meeting" posted
>
> Well, the former didn't help at all.
It has content now, as people have begun to discuss governance issues
:-) Do jump in.
Gerv
Mike Connor
On 11-Dec-06, at 9:33 AM, Gervase Markham wrote:
> Mike Connor wrote:
>> The three groups I see a need for are as follows (sample groups
>> are to give an idea of the mix of people):
>> Policy and process (inheriting from the largely-dead staff@m.o and
>> sort of drivers@m.o, list names are kinda random)
>
> How do you see this group in relation to the Mozilla Foundation?
> Or, conversely, what role (if any) do you see for the Foundation in
> setting policy and process?
I think that the Foundation should be represented within this group,
but should not have a dominant position (no one should). The
Foundation should be facilitating these decisions and ensuring that
the right frameworks are in place to make real progress (conference
calling infrastructure, travel if appropriate, etc).
>> - Make final decisions mozilla.org policy and focus (including
>> community feedback etc)
>> - Ensure that strong module ownership is maintained and improved
>> - sample group: mitchell, frank, dria, myk, brendan, dmose
>> - Becomes projec...@mozilla.org
>> Project Management (inheriting from drivers@m.o)
>
> How do you see this group in relation to the Corporation, given
> that they as an organisation have been delegated the task of
> shipping Firefox(TM) and Thunderbird?
Obviously there's going to be a heavy Corporation skew here, since
we're driving the bulk of releases/project management, but ideally
there's at least a couple people from other projects there to keep us
honest.
>> - Release timing/scheduling and active management of releases
>> - Needs involvement from apps/Gecko/build/QA/products
>> - This is a core/overall group trying to minimize conflicts and
>> plan together
>> - Should be supplemented by driver groups (i.e. dveditz/jay/
>> sicking are driving the 1.8.x security branches, a larger group is
>> driving Fx3/1.9)
>
> ...and each one should have an email alias with a consistent naming
> convention.
Each driver group for releases should? Yep, absolutely, and that's
on my to-do list for this week.
-- Mike
Mitchell Baker
can you say a bit more about what you're planning to do on this topic
this week?
mitchell
fantasai
>
>Gerv Markham wrote:
>>
>>Mike Connor wrote:
>>>
>>> Policy and process (inheriting from the largely-dead staff@m.o and sort of drivers@m.o, list names are kinda random)
>>>
>>> - Ensure that strong module ownership is maintained and improved
>>> - sample group: mitchell, frank, dria, myk, brendan, dmose
>>
>> How do you see this group in relation to the Mozilla Foundation? Or,
>> conversely, what role (if any) do you see for the Foundation in
>> setting policy and process?
>
> I think that the Foundation should be represented within this group, but
> should not have a dominant position (no one should). The Foundation
> should be facilitating these decisions and ensuring that the right
> frameworks are in place to make real progress (conference calling
> infrastructure, travel if appropriate, etc).
I agree with that. I see the Foundation as serving more of an advisory
and support role than a leadership role at mozilla.org. I'd expect a
Foundation staff member to be involved in leadership at mozilla.org
not because s/he's a Foundation staff member, but because that person
is otherwise involved and qualified in making mozilla.org decisions.
Same goes for anyone else: employment shouldn't matter, and members
should be selected based on their own personal merits.
>>> Project Management (inheriting from drivers@m.o)
>>
>> How do you see this group in relation to the Corporation, given that
>> they as an organisation have been delegated the task of shipping
>> Firefox(TM) and Thunderbird?
>
> Obviously there's going to be a heavy Corporation skew here, since we're
> driving the bulk of releases/project management, but ideally there's at
> least a couple people from other projects there to keep us honest.
I think it's important that Mozilla's release schedule be determined by
a group that a) represents all the mozilla.org projects strongly affected
by the schedule and b) is a group owned by mozilla.org, not by a single
company, even if that company is MozCorp. The bias given to Firefox and
Thunderbird should exist because all the members of that group share an
understanding of its importance to the Mozilla Project, not because those
two products have any inherent precedence over the others.
[Follow-up to mozilla.governance.]
~fantasai