[meta] Publish Candidate Recommendation

[anssiko]

This meta issue tracks progress toward the Remote Playback API Candidate Recommendation (CR) publication. Editor: @mounirlamouri

By publishing a CR we:

• ask the entire W3C membership to provide feedback,
• formally collect implementation experience to demonstrate that the specification works in practice.

The CR requirements are the following from the W3C Process perspective:

• must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,

  • meets requirements

• must document changes to dependencies during the development of the specification,

  • new normative reference since FPWD: [MIXED-CONTENT] CR

• must document how adequate implementation experience will be demonstrated,

  • test plan / test suite
    • https://github.com/w3c/web-platform-tests/tree/master/remote-playback
      • add IDL tests
  • preliminary implementation report / implementation status
    • tracked in Produce a preliminary implementation report #87
  • CR exit criteria
    • PR Add "Candidate Recommendation exit criteria" section #89

• must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents,

  • suggest six weeks

• must show that the specification has received wide review,

  • wide review started in Nov 2016
    • https://lists.w3.org/Archives/Public/public-review-announce/2016Nov/0008.html
  • TAG review
    • Remote Playback API w3ctag/design-reviews#145
  • i18n review
    • https://github.com/w3c/i18n-activity/issues/274
  • privacy review
    • https://lists.w3.org/Archives/Public/public-privacy/2017JanMar/0009.html
    • Feedback addressed in [Privacy] Adds notes clarifying behavior to address privacy review.  #83
  • accessibility
    • https://lists.w3.org/Archives/Public/public-apa/2016Nov/0017.html
  • security - no concerns or comments (to date)
    • https://lists.w3.org/Archives/Public/public-webappsec/2016Dec/0000.html
    • https://lists.w3.org/Archives/Public/public-web-security/2016Dec/0000.html

• 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.

  • address [Meta] Guidance for HTMLMediaElement, HTMLAudioElement, HTMLVideoElement behaviors during remoting #41 to identify possible "at risk" features
    • see https://w3c.github.io/remote-playback/#sotd

[anssiko]

Ping @avayvod @mounirlamouri to check the availability to work on #41 and the test suite update blocking this CR publication.

[anssiko]

Gently nudging @avayvod @mounirlamouri.

Would it be helpful to have a topic-specific WG call to discuss the Remote Playback API plan to CR, associated requirements, things to do? Any specific areas where you'd especially welcome contributions from other WG participants? Let us know.

[markafoltz]

@anssiko It looks like the specification received TAG and privacy feedback so I checked those off. Is i18n review expected to complete soon?

[anssiko]

@mfoltzgoogle, I pinged https://github.com/w3c/i18n-activity/issues/274. The i18n review has been in the "awaiting comment resolution" state since Feb 9.

[anssiko]

The i18n review has been completed, and one issue #70 was identified.

We should try to address this issue before going to CR. An informative note in the respective section should address the issue.

[avayvod]

Do privacy reviews end up being summarized on GitHub like TAG or i18n? I'd like to respond to the comments we've got on public-privacy@w3c.org but not sure if this is the right way or we should wait until all the comments are summarized.

[anssiko]

@avayvod, the privacy folks use the mailing list, and not (yet) GitHub. Please respond on that list. This constitutes all of the privacy review feedback: https://lists.w3.org/Archives/Public/public-privacy/2017JanMar/0009.html

[avayvod]

Thanks @anssiko, I've sent a response here!

[anssiko]

Current status: CR blockers are #41, #83, #87.

All have a proposal or a suggested resolution.

In addition to these blockers, we need to define the CR exit criteria and "at risk" features. @tidoust would you like to take a stab at them?

[tidoust]

In addition to these blockers, we need to define the CR exit criteria and "at risk" features. @tidoust would you like to take a stab at them?

See proposal in PR #89

[anssiko]

Current status: CR blockers are #41, #87.

(Fixed since last week: #83, #89)

[anssiko]

Current status: the remaining CR blocker is #41

@tidoust, could you take a look at the overall CR plan and see whether there are any other issues in your view that we should address prior to advancing to CR? If not, I'd like to issue a CfC to publish a Candidate Recommendation as soon as possible.

[mounirlamouri]

@anssiko sorry for coming late with this question but I thought we did not have two compatible implementations yet and that was a soft rule for CR given that we can't for beyond that stage without it. Is your plan to go to CR with one implementation and wait for another in order to go to PR/REC?

[tidoust]

@mounirlamouri I would personally still go to CR even if we only have one implementation in the pipe.

The Director will most likely wonder about implementation plans when we ask to publish the CR, and it would be way better to have concrete plans to share for at least two implementations. However, that is indeed a soft rule. If we have but one implementation for now, then so be it, publication as a CR is also a way to tell the world that, apart from issues that may appear based on implementation feedback, the Working Group considers that the API is done and ready, which seems useful. It used to be a pain to publish updated CRs but that is no longer the case.

[anssiko]

@mounirlamouri, given the more agile CR publishing process, I'd prefer to go to CR early and publish an updated CR as needed, similarly to what we did with the Presentation API. I think we're about to reach consensus on the remaining blocker #41, please chime in there.

[anssiko]

#95 seems to address #41 for the purposes of the CR publication.

The process doc tells us CR 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.

Are we fine with the following boilerplate?

No feature has been identified as being at risk.

Given the information we have re #41, that seems like the most accurate statement we can make at this time. Even if we end up dropping feature(s), we can still go to PR, we just have to publish another CR in between -- not a major hurdle anymore, a speed bump at most.

[anssiko]

Call for Consensus (CfC) to request publication of a Candidate Recommendation (CR) of the Remote Playback API:
https://lists.w3.org/Archives/Public/public-secondscreen/2017Aug/0033.html

[tidoust]

Current status:

• i18n issues Internationalization considerations #66 and Should the ability to query by language or country be added to watchAvailability() #70 need to be addressed before transition to CR may happen. Done when PRs Fix #70: Note srclang hint to address i18n comment #99 and Add i18n-related informative notes about locale passing between devices #100 are merged.
• We'll then need to get back to the i18n group and ask for final "green light", meaning closure of https://github.com/w3c/i18n-activity/issues/274
• I also noted in Adjust notes with normative content #101 a few notes with normative text which I think we should fix as well before transitioning. Done when PR Adjust notes to clarify informative/normative intent #102 gets merged.

[anssiko]

All the last-minute CR blockers have been addressed and the i18n group has been informed. Thanks for your swift contributions.

@tidoust, please advance with the plan to request publication of a CR.

[tidoust]

Before the specification can transition to a Candidate Recommendation, the definition of the disableRemotePlayback content attribute should be made explicit (#105), and the Second Screen WG should request a review from the Web Platform Working Group (see member-only discussion thread).

[anssiko]

#106 is the proposed fix to #105.

After landing, @tidoust to initiate request to review from the Web Platform WG.

[anssiko]

@tidoust, we should be now ready for the WP WG review.

[tidoust]

I asked the Web Platform WG for review, with a deadline for comments set to 10 October.

[anssiko]

The Web Platform WG review period has ended.

Issue #107 was opened during the review period which may or may not be in response to the review request. Nevertheless, the author of the issue @jyasskin approved the spec editor @mounirlamouri's suggestion. My assessment is the issue raised will not block the CR publication, thus I'd ask @tidoust to advance with the transition to a Candidate Recommendation at the earliest opportunity.

[anssiko]

An update on the logistics of the CR publication:

I pushed a cr branch that needs to be rebased with gh-pages when PRs #108 and #110 are approved and merged. The spec-generator snapshot is used for publication, it passes Pubrules and also Link Checker when the above-mentioned changes are baked into the cr branch. Earliest publication opportunity is 19 October 2017.

I believe we want to keep the WHATWG HTML references in the Editor's Draft, and as such, I suggest we keep 9980f4f in the cr branch for release purposes.

[anssiko]

PRs #108 and #110 have been merged into gh-pages and the cr branch rebased with gh-pages to pull in these changes.

@tidoust, can you please check that we're good to publish 19 October 2017?

The spec-generator snapshot passes Pubrules and Link Checker. You may want to address the Patent Policy warning by manually patching the snapshot, since the ReSpec patch https://github.com/w3c/respec/pull/1388 has not yet been merged. The updated Patent Policy only incorporates editorial updates to be consistent with the 2017 Process.

[tidoust]

The Candidate Recommendation of the Remote Playback API has been published today (19 October 2017). Closing this as a result.

Well done, Second Screen WG!