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

Reply via email to