Amphtml: Design Review 2018-10-10 20:00 UTC (governance proposal)

[mrjoro]

Time: 2018-10-10 20:00 UTC (add to Google Calendar)
Location: Video conference via Google Hangouts

The AMP Project holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[cramforce]

Let's talk about the new governance model!
https://github.com/ampproject/meta/pull/1

[rsimha]

If time permits, I'd like to present the results from last time's discussion on Canary releases. This should take ~10 mins.

[aghassemi]

If time allows: I like to discuss how to expose accurate geo-location lon/lat values: https://github.com/ampproject/amphtml/issues/8929#issuecomment-427457837

[prateekbh]

We are working on automatic service worker generation for AMP docs. Would love to discuss if we have time left

[mrjoro]

Governance

• do OWNERS have write access to the repo?
  
  
  
  • OWNERS is used entirely for the ability to control changes
  
  
  • e.g. amp-twitter; ideally it's owned by someone that is familiar with it (e.g. a Twitter employee); you'd also need someone with write access to repo (it could be the same person)
  
  
• proposal says Advisory Committee will be 6-12; it's likely we'll end up a bit higher than this
• should there be rotating slots (like a 1 month rotation) in the Advisory Committee?
  
  
  
  • @cramforce: that could be an interesting idea; we should think about this because it could mean more varied representation over time
  
  
  • do we have expiring seats or not? for the AC, currently they're selected as a person rather than the seat being assigned to the company
  
  
  • how does "no more than 1/3 from one company" requirement intersect with this? if the employer changes for people on the AC then people may need to step down to accommodate this
  
  
• what happens when the AC and the TSC disagrees on something? the TSC wins--the AC is an advisory body, so it doesn't have decision-making capabilities... but it's not a sustainable state if this situation happens all the time
  
  
  
  • is there a process for the AC and TSC to seek consensus? no defined way of doing this; consensus-based process is within the committees
  
  
• TSC defines & follows the project guidelines; should these core tenets be harder to change? no; with a simple majority the TSC could change the guidelines
• what happens if someone wants to exit the TSC? how does this interact with the 1/3 requirement? this is perhaps more likely for a company wanting to pull out--should there be a requirement that they give notice?
• @mrjoro is working on a default working mode document for Working Groups; @tobie is working on something similar for the AC; the TSC will decide how their day-to-day work will happen after the group is constituted and meets
• how would the TSC be involved in design reviews?
  
  
  
  • design reviews will likely continue similar to how they are now
  
  
  • designs need approvals
  
  
• is there an SLA for the TSC? no; the TSC should define this
• what if the TSC wants to rebuild AMP from the ground up? how do they seek advice from the WG? they'd create a "Rewrite AMP" Working Group
• do WG work with the Advisory Committee? the best answer is "we'll see"; there are probably examples where this makes a lot of sense; let's not forget the project is made up of humans and we can continue to talk to each other
  
  
  
  • would a WG turn to the AC for advice? the AC is likely providing higher-level advice; if that's what's needed by a WG then that should be possible
  
  
• do we need to clarify when the TSC should meet face-to-face at AMP events (like at AMPConf, ACS, etc.), like requiring 2/3 of the membership to show up? likely the TSC should be at these if possible
• what about day-to-day conversations? should we document best practices? yes--these are the work mode docs mentioned earlier on this; one key point is that the conversations within groups shouldn't be using internal channels
• are Working Groups nested, e.g. UI Working Group and then an amp-twitter Working Group? no; not everything has to be a Working Group
• should the goals be part of the governance document? currently it's in the PR but not in GOVERNANCE.md; perhaps we should add this as a preamble? or meta README.md; it's better to keep the official governance model document more constrained