New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
mrjoro opened this Issue Sep 6, 2018 · 5 comments

Comments

Projects
None yet
6 participants
@mrjoro
Member

mrjoro commented Sep 6, 2018

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

This comment has been minimized.

Show comment
Hide comment
@cramforce

cramforce Sep 18, 2018

Member

Let's talk about the new governance model!
ampproject/meta#1

Member

cramforce commented Sep 18, 2018

Let's talk about the new governance model!
ampproject/meta#1

@rsimha

This comment has been minimized.

Show comment
Hide comment
@rsimha

rsimha Oct 3, 2018

Collaborator

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

Collaborator

rsimha commented Oct 3, 2018

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

@aghassemi

This comment has been minimized.

Show comment
Hide comment
@aghassemi

aghassemi Oct 5, 2018

Member

If time allows: I like to discuss how to expose accurate geo-location lon/lat values: #8929 (comment)

Member

aghassemi commented Oct 5, 2018

If time allows: I like to discuss how to expose accurate geo-location lon/lat values: #8929 (comment)

@prateekbh

This comment has been minimized.

Show comment
Hide comment
@prateekbh

prateekbh Oct 10, 2018

Member

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

Member

prateekbh commented Oct 10, 2018

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

@mrjoro

This comment has been minimized.

Show comment
Hide comment
@mrjoro

mrjoro Oct 10, 2018

Member

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
Member

mrjoro commented Oct 10, 2018

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

@mrjoro mrjoro closed this Oct 10, 2018

@mrjoro mrjoro changed the title from Design Review 2018-10-10 20:00 UTC (Americas) to Design Review 2018-10-10 20:00 UTC (governance proposal) Oct 10, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment