Re: Proposal: Firefox Technical Leadership Module
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 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: > > 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
Re: Proposal: Firefox Technical Leadership Module
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 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
Re: Proposal: Firefox Technical Leadership Module
On Fri, 2 Mar 2018 at 16:29 Justin Dolske via governance < governance@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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
On Wed, Mar 7, 2018 at 2:27 PM Byron Jones 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 > > -- > glob — engineering productivity — moz://a > > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
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 < governance@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 > > > > > ___ > governance mailing list > governance@lists.mozilla.org > https://lists.mozilla.org/listinfo/governance > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
On 8 March 2018 at 01:27, Byron Jones via governance < governance@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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
On Fri, Mar 2, 2018 at 1:43 PM Ben Kelly wrote: > On Fri, Mar 2, 2018 at 2:49 PM, Dave Camp via governance < > governance@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 > ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
On Fri, Mar 2, 2018 at 2:49 PM, Dave Camp via governance < governance@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 ___ governance mailing list governance@lists.mozilla.org https://lists.mozilla.org/listinfo/governance
Re: Proposal: Firefox Technical Leadership Module
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 On Fri, Mar 2, 2018 at 11:49 AM, Dave Camp via governance < governance@lists.mozilla.org> 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 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 > -
