Proposal: Firefox Technical Leadership Module

[Dave Camp]

Hello Governance folks,

I've been working with Mitchell and some other folks over the past few
months to better reflect Firefox technical leadership in the module
ownership system. I think we're at a point where we're ready to make the
first proposal:

Introduction
=========

The Mozilla Module system was historically structured with the assumption
that Brendan Eich was responsible for the software side of technical
decisions (as the former owner of the Module Ownership System). Brendan is
also listed as the current owner of the top-level directory module (with no
peers), but is no longer involved in Mozilla engineering. The result has
been a lack of clarity about technical decision making, and some avoidance
of decisions when escalation paths are unclear.

It seems clear that the module system should document ownership for the
technical side of Firefox code, development practices, and tools. We
propose to restructure the Firefox-related modules under control of a new
“Technical Leadership Module Committee” (TLMC), as described below.

FTLM Scope and Operation
=====================

The FirefoxTLM is responsible for engineering coordination and escalation
among the modules that make up Firefox. The TLMC (described below) would
generally try to avoid day-to-day involvement in module operation, but
would be involved in case of either decisions which are explicitly cross
module or issues cannot be resolved at lower levels, such as:

* Resolution of decisions that don’t fall clearly into any specific
module or set of modules
* Escalation of disputes beyond the module owner level

In addition, the Module Ownership System module would delegate its
responsibilities for the modules that make up Firefox to the FTLM. This
delegated authority includes topics such as those listed below.
Escalations regarding this set of issues would escalate to the Module
Ownership System module.

* Filling vacant roles where appropriate
* Ensuring module owners are fulfilling their responsibilities, and
replacing those who are not
* Creating and staffing new modules where new parts of the project evolve.
* Figuring out what to do if a module isn't getting enough attention
* Resolving conflicts among module owners

The TLMC decision making process would be to attempt to form consensus
among stakeholders, with the committee empowered to resolve disputes when
that consensus cannot be reached, and the chair empowered when consensus
can’t be reached within the committee.

FTLM Proposed Structure
====================

Instead of a single owner, the Technical Leadership would be governed by a
Technical Leadership Module Committee (TLMC) consisting of the
DE/Fellow/CTO cohort and the head of Firefox Engineering. Additional
members will be selected from the technical staff as needed to reach a six
member minimum and ensure a broad coverage of domain knowledge. These
additional members will serve two-year terms. The initial proposed members
are:

* Eric Rescorla (Firefox CTO) - Chair
* Dave Camp (Vice President, Firefox Engineering)
* Boris Zbarsky (DE)
* David Baron (DE)
* Dave Townsend
* Luke Wagner

If any of the existing members cease to be active, or upon the expiry of
the non-DE members’ two year terms, new replacement members would be
proposed by the remaining members and selected by the Module Ownership
System module owner (currently Mitchell Baker).

Appendix: Proposed List of Applicable Modules

* Firefox
* Toolkit
* Core
* Submodules
* Browser
* Tier 1 Platforms
* Other:
- Add-On SDK
- Android Background Services
- Firefox for Metro
- BrowserID
- Firefox Accounts
- Devtools
- Fennec
- SyncLoop
- MLS
- Mozstumbler
- URL Classifier
- Tree Sheriffs
* Governance
- Security Policy
- CA Certificate Policy
- Code Review Policy
- Performance Regression Policy
- CA Certificates
- Commit Access Policy

[Justin Dolske]

Overall, +1 on filling this gap in the module system.

One comment/question...

IME a significant number of possible-escalation grumbles have been less
about the _technical_ aspects, and more about general disagreements around
outcomes or direction. Things like random objections to feature removals
come to mind. I think it's still healthy to have an escalation path... But
I'd also assume that path, in such cases, to be more of a procedural review
than a full-on de novo review. e.g. As long as the normal process was
followed, the right people consulted, data gathered, etc – the presumption
would be that the the outcome was reasonable without having to grind
through the whole decision-making process in detail. (Of course there will
always be exceptions, and it would be up to the committee to determine
what's appropriate.) Or in different framing, I think there's value in
having both fast-path and slow-path options for dispute resolution.

Is this something the TLMC would also handle and consider?

Justin

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

[Ben Kelly]

On Fri, Mar 2, 2018 at 2:49 PM, Dave Camp via governance <
gover...@lists.mozilla.org> wrote:

> FTLM Proposed Structure
> ====================
>
> Instead of a single owner, the Technical Leadership would be governed by a
> Technical Leadership Module Committee (TLMC) consisting of the
> DE/Fellow/CTO cohort and the head of Firefox Engineering. Additional
>

Why is this tied to the Mozilla Corporation org chart?

AIUI the module system exists for the project which is separate from the
corporate entity. While we traditionally have most owners/peers working as
employees, I didn't think it was a requirement. It seems strange to make a
formal connection like this from the project to particular slots in the
corporate organization.

Could we not simply propose these same individuals as the initial committee
without linking them to their titles and roles within MoCo?

Thanks.

Ben

[mhoye]

On 2018-03-02 4:43 PM, Ben Kelly via governance wrote:

> Why is this tied to the Mozilla Corporation org chart?

I have a similar concern; this proposal seems to imply long-term
commitment to on the part of the Mozilla Corporation to a specific
organizational structure supporting it.

I can see good arguments for and against that, so think I have a case
there either way. But I do think that if this proposal requires that
commitment on the part of MoCo, we should be explicit in specifying (and
obtaining!) that commitment.



- mhoye

[Dave Camp]

On Fri, Mar 2, 2018 at 1:43 PM Ben Kelly <bke...@mozilla.com> wrote:

> On Fri, Mar 2, 2018 at 2:49 PM, Dave Camp via governance <
> gover...@lists.mozilla.org> wrote:
>
>> FTLM Proposed Structure
>> ====================
>>
>> Instead of a single owner, the Technical Leadership would be governed by a
>> Technical Leadership Module Committee (TLMC) consisting of the
>> DE/Fellow/CTO cohort and the head of Firefox Engineering. Additional
>>
>

> Why is this tied to the Mozilla Corporation org chart?
>

> AIUI the module system exists for the project which is separate from the
> corporate entity. While we traditionally have most owners/peers working as
> employees, I didn't think it was a requirement. It seems strange to make a
> formal connection like this from the project to particular slots in the
> corporate organization.
>

I'm reminded of something Mike Shaver said when handing Firefox module
ownership to Gavin Sharp:

> While being an employee of Mozilla is by no means a necessity for module
> ownership in Mozilla, the Firefox module is so critical and so active
> that it really deserves the attention of someone who can spend 8(+)
> hours a day thinking, watching, and living Firefox.

The intent here isn't really to create a new formal, long-term requirement
of MoCo employment specifically. But it is meant to clarify that we believe
this role requires full time employment in a Firefox leadership role. And
(particularly in light of the situation we're trying to fix) we would like
that role to be revoked upon no longer holding such a position, rather than
leaving that unspecified.

We could consider adjusting the wording to clarify that Mozilla Corporation
doesn't need to be the entity providing this full-time employment (it
doesn't currently specify Mozilla Corporation, although it does reference
roles that exist in the Mozilla Corporation hierarchy at the moment). But I
think the module ownership system is at its best when it's honestly
documenting the decision making processes that exists.

It's easy for us to change this description if other centers of full-time
Firefox leadership emerge. This module is still subject to the Mozilla
Module Ownership System module owner, who we trust will not let us use a
description of how we work now get in the way of evolving how we could work
differently for the good of the project.

-dave


> Thanks.
>
> Ben
>

[Byron Jones]

Dave Camp wrote:
> I've been working with Mitchell and some other folks over the past few
> months to better reflect Firefox technical leadership in the module
> ownership system. I think we're at a point where we're ready to make the
> first proposal:

> [..]

awesome :)

> It seems clear that the module system should document ownership for the
> technical side of Firefox code, development practices, and tools. We
> propose to restructure the Firefox-related modules under control of a new
> “Technical Leadership Module Committee” (TLMC), as described below.

> [..]

is part of this proposal to restructure the existing firefox-related
modules, or will this just to add a new "top-level" module above the
existing modules (thereby making a restructure easier if required)?

what is the proposed process for requesting feedback/decisions from the
TLMC?

> Appendix: Proposed List of Applicable Modules

there's a few modules listed as applicable at first glance appear to be
obsolete:

> - Add-On SDK

> - Firefox for Metro
> - BrowserID

> - SyncLoop
i assume this is "Sync" and "Loop". loop has been shutdown.


--
glob — engineering productivity — moz://a

[Ryan Kelly]

On 8 March 2018 at 01:27, Byron Jones via governance <

gover...@lists.mozilla.org> wrote:

> there's a few modules listed as applicable at first glance appear to be
> obsolete:
>

> - BrowserID
>>
>
I can confirm that this module is 100% obsolete. The few remaining places
where we use BrowserID-derived technology are squarely under the "Firefox
Accounts" module.
I have an item my todo list that says "email governance about removing
BrowserID module" which this is a good reminder to follow up on; I'll send
a new top-level email for completeness.


Ryan

[Dave Camp]

Would EKR and my commitment (representing moco leadership) and Mitchell's
commitment (representing project leadership) that we'll revisit and revise
the description if the org structure changes be sufficient to address your
concerns?

On Fri, Mar 2, 2018 at 10:32 PM mhoye via governance <
gover...@lists.mozilla.org> wrote:

> On 2018-03-02 4:43 PM, Ben Kelly via governance wrote:
>

> > Why is this tied to the Mozilla Corporation org chart?
>

> I have a similar concern; this proposal seems to imply long-term
> commitment to on the part of the Mozilla Corporation to a specific
> organizational structure supporting it.
>
> I can see good arguments for and against that, so think I have a case
> there either way. But I do think that if this proposal requires that
> commitment on the part of MoCo, we should be explicit in specifying (and
> obtaining!) that commitment.
>
>
>
> - mhoye
>
>
>
>

[Dave Camp]

On Wed, Mar 7, 2018 at 2:27 PM Byron Jones <gl...@mozilla.com> wrote:

> Dave Camp wrote:
> > I've been working with Mitchell and some other folks over the past few
> > months to better reflect Firefox technical leadership in the module
> > ownership system. I think we're at a point where we're ready to make the
> > first proposal:

> > [..]
>
> awesome :)

>
> > It seems clear that the module system should document ownership for the
> > technical side of Firefox code, development practices, and tools. We
> > propose to restructure the Firefox-related modules under control of a new
> > “Technical Leadership Module Committee” (TLMC), as described below.

> > [..]
>
> is part of this proposal to restructure the existing firefox-related
> modules, or will this just to add a new "top-level" module above the
> existing modules (thereby making a restructure easier if required)?
>

More the latter - no restructure is laid out here, but we propose that this
is the group that should be held responsible for the structure of those
modules (and so I'd expect restructuring proposals down the line).

> what is the proposed process for requesting feedback/decisions from the
> TLMC?
>

For now let's continue to use the governance list. We'll let this list
know if that changes.

> > Appendix: Proposed List of Applicable Modules
>

> there's a few modules listed as applicable at first glance appear to be
> obsolete:
>

Yeah - we were assuming responsibility for cleaning those up, but if
existing owners there want to disband those modules that's fine too.


>
> > - Add-On SDK

> > - Firefox for Metro
> > - BrowserID
>

> > - SyncLoop
> i assume this is "Sync" and "Loop". loop has been shutdown.
>

> Yeah, that was a formatting error.

Thanks,
-dave

[mhoye]

On 2018-03-07 2:16 PM, Dave Camp wrote:
> Would EKR and my commitment (representing moco leadership) and
> Mitchell's commitment (representing project leadership) that we'll
> revisit and revise the description if the org structure changes be
> sufficient to address your concerns?

Yes, definitely. Beyond solving our immediate problem, I think long term
it's only going to get more important that Mozilla be willing to modify
or replace tools (like governance structures) that have become
ineffective. So I'm glad that we're explicitly spelling out that part of
the process.

- mhoye

[Mike Connor]

On Fri, 2 Mar 2018 at 16:29 Justin Dolske via governance <
gover...@lists.mozilla.org> wrote:

> Overall, +1 on filling this gap in the module system.
>
> One comment/question...
>
> IME a significant number of possible-escalation grumbles have been less
> about the _technical_ aspects, and more about general disagreements around
> outcomes or direction. Things like random objections to feature removals
> come to mind. I think it's still healthy to have an escalation path... But
> I'd also assume that path, in such cases, to be more of a procedural review
> than a full-on de novo review. e.g. As long as the normal process was
> followed, the right people consulted, data gathered, etc – the presumption
> would be that the the outcome was reasonable without having to grind
> through the whole decision-making process in detail. (Of course there will
> always be exceptions, and it would be up to the committee to determine
> what's appropriate.) Or in different framing, I think there's value in
> having both fast-path and slow-path options for dispute resolution.
>
> Is this something the TLMC would also handle and consider?

This a really interesting question. I think there's actually two questions:

1) Does this group act as a point of escalation for non-technical decisions?

I think the answer to that is clearly no, and any solution is well beyond
the scope of what Dave's proposing here. It might be worth identifying
such a group, but it's a very different problem, and one we've never really
solved. I do think it'd be great to solve for product/UX leadership in a
way we haven't really described to date. But that's not this group.

2) Does this constitute an avenue of appeal for technical decisions, and if
so what process should be followed?

Probably yes. But I'm pretty comfortable with not having a formal process.
I trust this group to exercise effective oversight for any given situation.

-- Mike

[Dave Camp]

Hello,

Thanks everyone for comments on the first version of this proposal both on
and off list. Below is our second attempt. The changes revolve around two
points:

* First, only two of the positions are explicitly tied to the Mozilla
Corporation, the rest are left unspecified. This felt like a better
compromise between the intent of the module system and the reality of the
Mozilla Corporation's role in Firefox development.
* Second, it explicitly calls out the responsibility of the Module Owner
Module (Mitchell) to revisit this makeup if the relationship between
Firefox development and Mozilla Corporation or other entities funding
Firefox development.

Introduction
============

The Mozilla Module system was historically structured with the assumption
that Brendan Eich was responsible for the software side of technical
decisions (as the former owner of the Module Ownership System). Brendan is
also listed as the current owner of the top-level directory module (with no
peers), but is no longer involved in Mozilla engineering. The result has
been a lack of clarity about technical decision making, and some avoidance
of decisions when escalation paths are unclear.

It seems clear that the module system should document ownership for the

technical side of Firefox code, development practices, and tools.. We

propose to restructure the Firefox-related modules under control of a new
“Technical Leadership Module Committee” (TLMC), as described below.

FTLM Scope and Operation

The FirefoxTLM is responsible for engineering coordination and escalation
among the modules that make up Firefox. The TLMC (described below) would
generally try to avoid day-to-day involvement in module operation, but
would be involved in case of either decisions which are explicitly cross
module or issues cannot be resolved at lower levels, such as:

* Resolution of decisions that don’t fall clearly into any specific module
or set of modules
* Escalation of disputes beyond the module owner level

In addition, the Module Ownership System module would delegate its
responsibilities for the modules that make up Firefox to the FTLM. This
delegated authority includes topics such as those listed below.
Escalations regarding this set of issues would escalate to the Module

Ownership System module:

* Filling vacant roles where appropriate
* Ensuring module owners are fulfilling their responsibilities, and
replacing those who are not
* Creating and staffing new modules where new parts of the project evolve.
* Figuring out what to do if a module isn't getting enough attention
* Resolving conflicts among module owners

The TLMC decision making process would be to attempt to form consensus
among stakeholders, with the committee empowered to resolve disputes when
that consensus cannot be reached, and the chair empowered when consensus
can’t be reached within the committee.

FTLM Proposed Structure

=======================

Instead of a single owner, the Technical Leadership would be governed by a

Technical Leadership Module Committee (TLMC). The TLMC would consist of
the CTO and VP of Engineering from the Mozilla Firefox organization, plus
additional members that reflect the technical leadership of the project.
The additional members will be selected as needed to reach a six member
minimum and ensure broad coverage of domain knowledge. In most cases, we
would expect those leaders to be more or less full-time on the project.

These additional members will serve two-year terms. The initial proposed
members are:

* Eric Rescorla (Firefox CTO) - Chair
* Dave Camp (Vice President, Firefox Engineering)
* Boris Zbarsky

* David Baron

* Dave Townsend
* Luke Wagner

The Module Ownership System module owner (currently Mitchell Baker) is
expected to revisit these membership criteria upon any substantial changes
to the management structures or relationships to corporate entities with
the project.

Appendix: Proposed List of Applicable Modules

=============================================

* Firefox
* Toolkit
* Core
* Submodules
* Browser
* Tier 1 Platforms
* Other:
- Add-On SDK
- Android Background Services

- Firefox for Metro
- BrowserID

- Firefox Accounts
- Devtools
- Fennec
- Sync

- MLS
- Mozstumbler
- URL Classifier
- Tree Sheriffs
* Governance
- Security Policy
- CA Certificate Policy
- Code Review Policy
- Performance Regression Policy
- CA Certificates
- Commit Access Policy

On Fri, Mar 2, 2018 at 11:49 AM Dave Camp <dc...@mozilla.com> wrote:

> Hello Governance folks,

>
> I've been working with Mitchell and some other folks over the past few
> months to better reflect Firefox technical leadership in the module
> ownership system. I think we're at a point where we're ready to make the
> first proposal:
>

> Introduction
> =========
>
> The Mozilla Module system was historically structured with the assumption
> that Brendan Eich was responsible for the software side of technical
> decisions (as the former owner of the Module Ownership System). Brendan is
> also listed as the current owner of the top-level directory module (with no
> peers), but is no longer involved in Mozilla engineering. The result has
> been a lack of clarity about technical decision making, and some avoidance
> of decisions when escalation paths are unclear.
>

> It seems clear that the module system should document ownership for the
> technical side of Firefox code, development practices, and tools. We
> propose to restructure the Firefox-related modules under control of a new
> “Technical Leadership Module Committee” (TLMC), as described below.
>

> FTLM Proposed Structure
> ====================
>
> Instead of a single owner, the Technical Leadership would be governed by a
> Technical Leadership Module Committee (TLMC) consisting of the
> DE/Fellow/CTO cohort and the head of Firefox Engineering. Additional

> members will be selected from the technical staff as needed to reach a six
> member minimum and ensure a broad coverage of domain knowledge. These
> additional members will serve two-year terms. The initial proposed members
> are:
>
> * Eric Rescorla (Firefox CTO) - Chair
> * Dave Camp (Vice President, Firefox Engineering)
> * Boris Zbarsky (DE)
> * David Baron (DE)
> * Dave Townsend
> * Luke Wagner
>
> If any of the existing members cease to be active, or upon the expiry of
> the non-DE members’ two year terms, new replacement members would be
> proposed by the remaining members and selected by the Module Ownership
> System module owner (currently Mitchell Baker).
>

> Appendix: Proposed List of Applicable Modules
>

> * Firefox
> * Toolkit
> * Core
> * Submodules
> * Browser
> * Tier 1 Platforms
> * Other:
> - Add-On SDK
> - Android Background Services

> - Firefox for Metro
> - BrowserID

[Eric Rescorla]

Per previous discussion[1], I am happy to announce that we have now
created the new Firefox Technical Leadership Module[2], governed
by the Technical Leadership Module Committee. One
of the committee’s first steps will be to clean up the existing list
of modules, removing now obsolete modules and trying to find new
owners for modules that are currently unowned.

-Ekr [for the TLMC]

[1] https://groups.google.com/forum/#!topic/mozilla.governance/YTTqUzWaJ00
For some reason Mitchell's approval (copied below) as Module System Module
Owner does not appear in the archives.
[2] https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership


On Thu, Jul 5, 2018 at 5:23 PM Mitchell Baker <mitc...@mozilla.com> wrote:
>
> Yes, I'm OK with this version.
>
> I recognize that the founding aspirations of the Module System have been
> that all roles are independent of employment relationship. Today I
> think it is unrealistic to think that the Firefox product could ship
> without someone at Mozilla Corporation involved formally. So I am OK
> with a Module that describes reality. Much better than having an
> unwritten rule ...
>
> I do agree it is important that we acknowledge this could change again,
> to where there are no roles related to employment, so it's good to see
> that made explicit as well.
>
>
> Mitchell

[Eric Rescorla]

Per previous discussion[1], I am happy to announce that we have now
created the new Firefox Technical Leadership Module[2], governed
by the Technical Leadership Module Committee. One
of the committee’s first steps will be to clean up the existing list
of modules, removing now obsolete modules and trying to find new
owners for modules that are currently unowned.

-Ekr [for the TLMC]

[1] https://groups.google.com/forum/#!topic/mozilla.governance/YTTqUzWaJ00
For some reason Mitchell's approval (copied below) as Module System Module
Owner does not appear in the archives.
[2] https://wiki.mozilla.org/Modules/Firefox_Technical_Leadership


On Thu, Jul 5, 2018 at 5:23 PM Mitchell Baker <mitc...@mozilla.com> wrote:
>
> Yes, I'm OK with this version.
>
> I recognize that the founding aspirations of the Module System have been
> that all roles are independent of employment relationship. Today I
> think it is unrealistic to think that the Firefox product could ship
> without someone at Mozilla Corporation involved formally. So I am OK
> with a Module that describes reality. Much better than having an
> unwritten rule ...
>
> I do agree it is important that we acknowledge this could change again,
> to where there are no roles related to employment, so it's good to see
> that made explicit as well.
>
>
> Mitchell
>
>
> On 6/22/18 12:26 PM, Dave Camp wrote: