❤ ️A new governance model for AMP #1
Conversation
|
See #2. |
|
... and #3. |
|
... and finally (for now), #4. Thanks! |
There was a problem hiding this comment.
I welcome increased transparency and accountability from the AMP project. I think the policy could be improved in a few areas:
- Define what AMP 'is', legally: Define the legal status of AMP. In the blog post accompanying this governance model, it says "Additionally, we’re exploring moving AMP to a foundation in the future". So currently, decisions made 'by AMP' are expressing the will of what entity? And when it does move to a foundation, of course it is equally important to document that structure.
- Be transparent about funding: Again to quote the blog: "This is real work, and we want to pay for it if it isn’t covered by your day job". Who is 'we' and where does that money come from? I suggest that all individuals who work on AMP for more than 50% of their working hours, should be disclosed and funding sources indicated.
- Include AMP's vision statement: There is a reference in the model to "AMP's vision and goals" but it is not explicitly called out or linked to.
- Assuming that AMP's vision is as an expression of the future capabilities of the web platform, then it is a de-facto polyfill, and the governance policy should commit AMP to contributing to and supporting the development of the standards that it promotes, where there remains a gap between what is supported by AMP and what can be done without it.
- Clarify whether participants in the AC should only be those who agree with the vision, or whether it can include those who don't. ie. does joining the AC or any other AMP group signal your agreement to the overall goals of the AMP project?
- Expand the description of the AC's role to include detail on how exactly it advises the TSC. For example, can the AC issue written findings? If they do, does the TSC have to adhere to them?
It's a great start, and I'm looking forward to seeing the trend toward openness continue as AMP evolves!
|
|
||
| * **End-users**. People who consume content distributed using the AMP format. | ||
|
|
||
| * **Owners**. People who are most familiar with a particular set of code and who have been granted the power (by Owners at a higher level) for approving changes to that code. AMP will use a system similar to [Chromium's OWNERS](https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#OWNERS-files) system. The AMP Project will follow Chromium's [expectation for owners](https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners). |
There was a problem hiding this comment.
"Similar to" seems a little vague for a governance policy
There was a problem hiding this comment.
We're working on the actual software. @mrjoro Maybe we can at least say when we can define this more definitely?
There was a problem hiding this comment.
@rsimha and @erwinmombay are working on getting the details of how this will work published soon (well before the governance review period is done). We'll add a link here when it's done.
Arguably we could just leave this line out of the governance proposal, since it's not really about the governance exactly, and we can leave it to the discretion of the TSC how to actually enforce this.
We should also fix the parenthetical to be "(by the TSC or Owners at a higher level)" since the TSC is the one that provides this power.
There was a problem hiding this comment.
There may also be different policies in place between repositories. The owner process makes sense for amphtml but other lower traffic repositories may opt for something simpler.
There was a problem hiding this comment.
Agree with @mrjoro that the specifics of how Owners are implemented should be left to the discretion of the TSC. It's still useful to have the high-level concept detailed in the same document as Contributors and Collaborator so that the progress ladder is easily discoverable and understandable.
Might be worth prefixing it with "In certain repositories…" or the like, to adress @cramforce's point.
There was a problem hiding this comment.
And while we're at it, we should probably fold in and adapt the requirements listed on the Chromium website and reference that page informationally only (i.e. in a non-binding way).
|
Quick response on the funding side: We don't have this mapped out and it will depend on the individual requirements. What we have been discussing is for Google to fund an the AMP OpenCollective project out of which the AC would fund its members. With a transition to foundation this would then be taken over by it naturally. The first bullet is a dupe of #2. We should probably use the incorporation of the vision, and AC-TSC relationship into their own issue. The membership related points are related to #4, or at least should be spelled out while answering that issue. |
CC @triblondon who asked for this.
|
4dc7e25 links to vision/mission, roadmap, guidelines. |
GOVERNANCE.md
Outdated
|
|
||
| * **Technical Steering Committee (TSC).** A group of people who set AMP's technical & product direction. | ||
|
|
||
| * **Working Group Facilitator.** A member of the Working Group designated by the TSC who is responsible for facilitating the consensus-based decision making process and acting as a representative to the TSC from the Working Group. |
There was a problem hiding this comment.
The AC and TSC will also have a facilitator. The language needs to account for this.
There was a problem hiding this comment.
Changed this to just be "Facilitator" since the more specific roles are discussed under the respective sections.
| * Membership on the Advisory Committee is not time limited. | ||
| * The target size of the Advisory Committee is 6-12 members, but there is no fixed size. | ||
| * Once established the Advisory Committee sets its own membership through the consensus-based process. | ||
| * No more than ⅓ of the Advisory Committee should be from one employer. |
There was a problem hiding this comment.
Do we need to specify here what happens in case this ratio is no longer respected due to affiliation change of a member, or do we want to leave that as the AC's prerogative?
There was a problem hiding this comment.
I think we should not define this. This bullet point here is invariant to that.
|
From review: Add the goals from the PR description into the README of the meta repo |
|
|
||
| * **End-users**. People who consume content distributed using the AMP format. | ||
|
|
||
| * **Owners**. People who are most familiar with a particular set of code and who have been granted the power (by Owners at a higher level) for approving changes to that code. AMP will use a system similar to [Chromium's OWNERS](https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#OWNERS-files) system. The AMP Project will follow Chromium's [expectation for owners](https://chromium.googlesource.com/chromium/src/+/master/docs/code_reviews.md#expectations-of-owners). |
There was a problem hiding this comment.
@cramforce can we clarify here that owners will be a "github collaborator".
also my question earlier in hangout, do collaborators also get "master merge" access
my current implementation is that, they do not have "master merge" access and that they only turn a status check to green and a "collaborator" (one who has approver status) merges the PR for them if they are not a "collaborator"
There was a problem hiding this comment.
also my question earlier in hangout, do collaborators also get "master merge" access
No they shouldn't.
my current implementation is that, they do not have "master merge" access and that they only turn a status check to green and a "collaborator" (one who has approver status) merges the PR for them if they are not a "collaborator"
Yeah, that sounds good.
These are technicalities, however, which you might want to be able to change as needed without having to go through a governance document modification. We want to make sure not too specify this in too much details here.
|
Notes from the design review discussing this proposal are here: ampproject/amphtml#17924 |
|
@triblondon: opened issues #7, #8, #9, #10, added your comment to issue #2, and your last bullet point has already been fixed by 4dc7e25. |
| * Membership on the Advisory Committee is not time limited. | ||
| * The target size of the Advisory Committee is 6-12 members, but there is no fixed size. | ||
| * Once established the Advisory Committee sets its own membership through the consensus-based process. | ||
| * No more than ⅓ of the Advisory Committee should be from one employer. |
There was a problem hiding this comment.
I think we should not define this. This bullet point here is invariant to that.
GOVERNANCE.md
Outdated
|
|
||
| * **Advisory Committee (AC).** A group of people with representation from a variety of AMP's constituencies including Users, End-users and Collaborators who provide advice to the Technical Steering Committee. | ||
|
|
||
| * **Collaborators.** People who have been granted write-access to ampproject repositories. |
There was a problem hiding this comment.
@cramforce can we clarify here if collaborators will have merge access? (since a person can be a github collaborator but not part of the amphtml master mergers group which you need to be in to have merge access)
There was a problem hiding this comment.
Clarified. The amphtml master mergers concept is going away and is being replaced by the Owners mechanism.
There was a problem hiding this comment.
The proposal looks good to me, and I think this is ready to merge and go into effect. Thanks @cramforce and the other people who have provided feedback through this process.
|
@mrjoro Thanks! Agree, and looking forward to the first TSC meeting on Thursday! |
This is the proposal for a new governance model for AMP as announced on the blog.
Goals
For more details on the motivation, please see this blog post. Here is an excerpt from that post mentioning the goals:
Timeline
We’re looking forward to working with you all to refine the governance proposal, including at next week's AMP Contributor Summit. We encourage you to review and comment on the proposal and attend the design review that has been scheduled to discuss the proposal. The review period for the proposal will end on October 25, 2018 with a goal of implementing the new governance model shortly thereafter.
Housekeeping
Please use this PR primarily to discuss specific wording or to request small clarifications.
If you’d like to propose a bigger change or expect significant discussion, please instead create a new issue in this repository and post a link to the issue as a comment here. Moderators may move comment threads on this PR into issues if comment threads get too extensive.
Major changes will need to be discussed during the scheduled design review.
Please stay civil
When people care, discussions can sometimes become heated. We understand. But as always though, please stay respectful and courteous, and remember to abide by our code of conduct. Thank you! 🙏
This pull request was created in collaboration with @tobie, @mrjoro, and many others.