Selecting members of the AC / TSC / Working Groups

[mnot]

AIUI, the current proposal for the governance model pre-seeds membership of the AC and TSC, and thereafter they become self-selecting. Members are perpetual (unless kicked off by a simple majority vote), and there is no obligation for them to take on people who they don't want to.

This is a not-uncommon model for Open Source; if you don't like what the "insiders" are doing, you fork, and that becomes a constraint on the insiders (assuming that they want to avoid forks where possible).

I question whether this model is suitable for AMP, if the goal of the project is to eventually produce things that become (or feed into) open standards.

Google and those aligned with their interests will choose the initial set of members, and there is very little incentive (and no requirement) for them to broaden membership beyond that. The output will be acceptable to these parties, but could be very unacceptable to the broader community.

Unlike in open source, forking is not a good way to address that tension; it creates fragmentation, rather than a standard that reflects the entire community.

Looking at it another way -- the elephant in the room WRT AMP is the power dynamics between Google as an aggregator of content and other publishers of content. Creating a self-selecting governance model does nothing to address that.

So, if the purpose of the project is to create both software and specifications that eventually become standards, I would suggest a governance model that embodies more of that tension, so that the result is more representative of the overall community.

I.e. -- either embrace your critics by giving them significant and representative power, or seriously limit the scope of the project to manage people's expectations for it.

[cramforce]

Thanks for the issue and sorry for the late response. We've been thinking about this a lot.

What it comes down to is that we haven't been able to find a better way to do it. E.g. all voting systems wouldn't clearly lead to good outcomes (they could e.g. over-bias in a way that a process that has a manual biasing/unbiasing stage can control for) and there is no answer who gets to vote (We also particularly don't like W3C's answer to this question).

So, instead we decided to stick with a model where the existing team pre-seeds the candidates and we'll just try to do a good job at it. It also really helps that we hired @tobie to provide outside-Google perspective and keep us focused on the goals of representation.

This is by no means a perfect process. We hope that the final set will make folks reasonably happy. Over time it certainly makes sense to revisit some key pillars such as

• term limits
• process for new member addition

The process to transition to a foundation would be the natural point to revisit that.

[mnot]

I very much agree re: the undesirability of a membership-funded model / voting scheme.

It could be that the current model is fine; it just depends on who you select as your starting set of leaders. If they don't reflect a diverse set of views, this could lead to problems later on, if you try to standardise what you come up with (which seems necessary not only from a legal perspective, but also if it's going to get adoption in multiple Web browsers, etc).

Engagement with the standards process could take some of this pressure away as well. Jeffrey has done an excellent job bringing his work to the IETF and W3C, and hopefully we'll be able to have a bigger discussion about the work soon.

[tobie]

FYI: We included some of this feedback in the Membership section of the AC's work mode.