We could use more procedural rigor to coordinate between implementers

[samuelgoto]

As browser vendors make forward progress with their independent implementation, deployment and extension of FedCM, we should try to find ways to have a shared understanding of how to operate.

A few things that are problematic at the moment:

• the spec is a bit messy atm (or was, until @bvandersloot-mozilla made massive editorial improvements)
• normative / substantive PRs have been merged (largely small and by accident) without cross implementer review or a rigorous process
• extensions and proposals are all over the place, e.g. it is not clear which are more critical / mature than others
• it is not clear where each implementer is at in terms of spec support or trajectory
• it is not clear at what level of granularity should we be filling TAG reviews as well as (mozilla's/webkit's) standards position

There is probably more, but these are just a few that occurs to some of us now.

[samuelgoto]

A few of us met (@bvandersloot-mozilla @martinthomson @npm1 @cbiesinger @tttzach and @yi-gu ) and arrived at the following proposal of concrete ways that would help us coordinate with each other:

• what goes into the spec is roughly things that "2 or more implementers are in support of" (e.g. see the "don't write fiction rule" here), which I think is currently the case
• block a review from at least 2 implementers for any normative/substantive PRs
• editorial / non-normative PRs OK to be merged without cross implementer review
• file issues followed by proposals followed by spec PRs, as opposed to explainers, to substantially decrease the cost of engagement (much easier to comment on github issues than to comment on explainers)
• use the engagement on the issue and the cross implementer spec PR review as a tool for signaling implementer support, and file standards positions when any type of objection / question is raised in the spec PR
• use github labels to be clear what issues each implementer is actively working on (and could use each other's review), and what stage each feature is at. Here are a few examples of labels that we could use:
  • early interest for early ideas / problems implementers are actively interested in incubating and looking to each other for early validation
  • design reviews for proposals that we are looking for each other's design guidance (e.g. privacy/security threat modeling, alternatives considered, etc)
  • spec review for normative reviews of features that are further along in implementation and experimentation and are looking to be merged into the spec (e.g. names)
  • editorial for non-normative editorial issues / reviews
  • agenda+ issues that we want to discuss in the next CG call

Many of these are specific ways that we thought we could implement and map some of the procedural rules described in the WHATWG's Mode of Operation.

[johannhof]

You might be aware but there's a WHATWG PR template that can help with this, we use it in SAA: https://github.com/privacycg/storage-access/blob/main/PULL_REQUEST_TEMPLATE.md

[johannhof]

Which reminds me, there's no mention of tests/wpts in here, are those implied in the process?

[samuelgoto]

You might be aware but there's a WHATWG PR template that can help with this, we use it in SAA:
https://github.com/privacycg/storage-access/blob/main/PULL_REQUEST_TEMPLATE.md

That looks great! I think we could adopt that easily.

Which reminds me, there's no mention of tests/wpts in here, are those implied in the process?

Yep.

I think we have so far maintained that property: most (maybe?) normative changes are (sufficiently) covered by WPTs, but having pointers in the PR would make that clearer.

[samuelgoto]

I'm going to close this since (a) we have been operating under this process for a while now, (b) there isn't anything else actionable here and (c) we are now formalizing this process as we form the WG and transition between the CG and the WG.

Feel free to reopen if you feel like there is anything else actionable here.