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 > - URL Classifier > - Tree Sheriffs > * Governance > - Security Policy > - CA Certificate Policy > - Code Review Policy > - Performance Regression Policy > - CA Certificates > - Commit Access Policy > _______________________________________________ > 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