CR checklist

[marcoscaceres]

For all Transition Requests, to advance a specification to a new maturity level other than Note, the Working Group:

• [x] must record the group's decision to request advancement.
• [ ] must obtain Director approval.
• [x] must provide public documentation of all substantive changes to the technical report since the previous publication.
• [x] must formally address all issues raised about the document since the previous maturity level.
• [x] must provide public documentation of any Formal Objections (None)
• [x] should provide public documentation of changes that are not substantive.
• [x] should report which, if any, of the Working Group's requirements for this document have changed since the previous step. (No requirements have changed)
• [x] should report any changes in dependencies with other groups. (No dependencies have changed)
• [x] should provide information about implementations known to the Working Group.
  • Chrome (Android and beginning on desktop), Edge, Facebook, Samsung Internet Browser
  • See also Caniuse on Payment Request API

To publish a Candidate recommendation, in addition to meeting the general requirements for advancement a Working Group:

• [x] must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred, (No requirements have changed)
  • Key requirements have been met: distributed naming possible (constrained URL syntax), use of URLs to fetch manifest files, small set of standardized short strings for convenience.
• [x] must document changes to dependencies during the development of the specification, . (No dependencies have changed)
• [x] must document how adequate implementation experience will be demonstrated,
• [x] must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents, (2017-10-31)
• [x] must show that the specification has received wide review, and
  • Reviews by TAG, PING, I18N Core, and input from W3C management
• [x] may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation. (No features at risk)

[marcoscaceres]

@ianbjacobs, would appreciate your help with this one.

[ianbjacobs]

Hi @marcoscaceres, @zkoch, @adrianba, @sideshowbarker,

For CR-readiness, the main topics that need some attention are:

• Resolving small number of open issues or marking as editorial or whatever.
• Establishing how we will show interop for validation and comparison of both types of PMIs (URL and short string). I imagine some of that can been demonstrated through tests written elsewhere (e.g., comparison of URLs). What is the plan for a test suite for these features?

[marcoscaceres]

@ianbjacobs I added a placeholder for the implementation report: https://w3c.github.io/payment-method-id/reports/implementation.html

[marcoscaceres]

Ok, all issues addressed (well, PRs sent for them)! 🎉 Now just need "Director Approval".

[marcoscaceres]

Actually, still need "must document how adequate implementation experience will be demonstrated,". Need to put something about tests and link to implementation report. The spec contains a link to the implementation report already, but I'ld like something in the SoTD.

[marcoscaceres]

About testing, let's just write some tests using the examples I proposed today (using payment request) and "basic-card". I have a few tests locally that we can reuse.

That should be enough to pass for the purpose of CR.