[meta] Publish First Public Working Draft

[anssiko]

This is a meta issue to keep us aware of the fact that we should attempt to publish a First Public Working Draft (FPWD) of the spec in the near future. FPWD is the first step in the formal Recommendation Track.

To be FPWD ready, we should add some prose to complement the IDL (basically, formalise the draft summaries a bit, no need to be perfect).

@mounirlamouri @avayvod It'd be great if you could triage the open issues and label the ones you feel would benefit the most from the F2F discussion. We could try to publish the FPWD already before the F2F to give it more visibility and attract outside feedback.

[avayvod]

@anssiko any particular label we should use? Would F2F suffice?

[anssiko]

@avayvod F2F label works fine. When we work through the issues at F2F, I'd prefer to give priority to issues that would benefit from the F2F discussion & decision the most.

We have the Tuesday morning reserved for the Remove Playback API, so I'm positive that by the time we break for lunch on that day we have a spec that is FPWD-ready and we can start publication preparations soon after.

[tidoust]

Discussed at the F2F:
http://www.w3.org/2016/05/24-webscreens-minutes.html#item11

Goal is to collect edits from the F2F before publication.

ACTION: Anssi to send a CFC once edits are done
ACTION: Anton to collect edits and coordinate timing with Anssi

[anssiko]

As agreed at the F2F, we will publish the First Public Working Draft (FPWD) of the Remote Playback API when the edits documented as PROPOSED RESOLUTIONs (below) have landed to the Editor's Draft. Time-wise, we agreed to target the end of June FPWD publication. Factoring in a reasonable 10 working days Call for Consensus (CfC) and some wiggle room, I'd like us to have a publication ready spec by 13 June to be referenced in the FPWD CfC.

@avayvod @mounirlamouri Does this timeline sound reasonable to you?

All - please let me know if you have any questions or concerns with this plan.

PROPOSED RESOLUTIONs from the F2F (land before FPWD):

• onstatechange vs. onconnect, onconnecting, etc. (remote.onstatechange vs. remote.on{connect,connecting,disconnect} #36)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item04
  • PROPOSED RESOLUTION: break up the statechange into 3 different events as described in: remote.onstatechange vs. remote.on{connect,connecting,disconnect} #36 (comment)
• Allow websites to stop the remote playback (Allow websites to stop the remote playback #4)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item05
  • PROPOSED RESOLUTION: For issue Allow websites to stop the remote playback #4, no "stop" method, add guidance that UA should provide a way to disconnect, and rename "connect" method into something like "showDevicePicker"
• Define the UA behavior when the disableRemotePlayback attribute is added during the remote playback (Define the UA behavior when the disableRemotePlayback attribute is added during the remote playback #6)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item06
  • PROPOSED RESOLUTION: Refine behavior of existing alg's for attribute, i.e. Promise rejections would reference it.
• Allow the user agent to choose which media element source to play remotely (Allow the user agent to choose which media element source to play remotely #7)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item07
  • PROPOSED RESOLUTION: @avayvod to update spec to be clear that entire source list is considered for availability (if possible) and remote playback
• Specify the transition between the local and remote playback when changing remote.state (Specify the transition between the local and remote playback when changing remote.state #25)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item08
  • PROPOSED RESOLUTION: @avayvod to define local and remote player concepts in spec as source of behavior for media element. In connecting/disconnected state, local player is active. In connected state, remote player is active.

ACTIONs from the F2F (good to land after FPWD):

My expectation is that these ACTIONs we are fine to address after the FPWD, since they seem not to alter the technical scope of the spec, and as such do not impact the Call for Exclusions triggered by the FPWD publication. We can bake these changes into the subsequent Working Draft publication that follows FPWD.

• [Meta] Guidance for HTMLMediaElement, HTMLAudioElement, HTMLVideoElement behaviors during remoting ([Meta] Guidance for HTMLMediaElement, HTMLAudioElement, HTMLVideoElement behaviors during remoting #41)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item09
  • PROPOSED RESOLUTION: Extend the requirements doc as a start, best effort for UAs to reflect remote state locally otherwise.
• Do we need remote.getAvailability()? (Do we need remote.getAvailability()? #39)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item03
  • ACTION: @avayvod to craft a PR to use observe/unobserve pattern for availability
• Define the interaction with Media Session (Define the interaction with Media Session #10)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item10
  • ACTION: @mounirlamouri to update issue with comments about remote and local don't fight over output, and suggestion that remote playback can access keys. No spec changes at this juncture.
• Allow the user agent to choose which media element source to play remotely (Allow the user agent to choose which media element source to play remotely #7)
  • F2F minutes: https://www.w3.org/2016/05/24-webscreens-minutes.html#item07
  • ACTION: Investigate HTML source selection algorithm to decide if it is applicable, possibly on @foolip

[avayvod]

Hi Anssi,

Thanks for summarizing the proposals so neatly! Note, that Mounir and I both will have limited availability (at an internal offsite and BlinkOn) the week of June 13 so more wiggle room might be needed.

That said, I'm going to draft PRs for the proposed resolutions in advance this week and the next in hope there will be no more than minor adjustments to the proposals before the 10 working days deadline (which is June 8, right?). That should allow us to land the PRs in time for June 13, so the plan SGTM.

Thanks,
Anton.

[avayvod]

Also, ideally I'd like to see issue #39 resolved before FPWD as it means backwards incompatible changes to the spec.

[foolip]

ACTION: Investigate HTML source selection algorithm to decide if it is applicable, possibly on

Is the idea here that the UA would be free to pick from any of the source child elements which resource to use from the remote playback? In general I would be very cautious about that, the resource selection algorithm works by picking the first source that works, and doesn't ever switch once playback is in progress.

Is the problem at hand what to do when the resource playing locally cannot be decoded on the remote?

[foolip]

Oops, will comment on #7 instead.

[avayvod]

Hi Anssi et al,

My priorities have switched to another feature in Chrome for the next couple of weeks so I doubt I'll have enough time to fix the issues blocking the FPWD by June 13. Could we move the date to whenever all the blocking issues are closed?

Thanks,
Anton.

[anssiko]

@avayvod Thanks for the heads up. Unless Mounir or someone else is able to back you up, we'll need to delay the publication. Are you able to provide a guesstimate when you think you could close the FPWD blockers so we could plan the publication accordingly. Would e.g. 27 June be too early?

[avayvod]

Let's target June 27 for now and move it to later if needed.

[anssiko]

@avayvod Are we still on track to close the FPWD blockers by June 27 (next Monday), or should we plan with a later date in mind?

[avayvod]

Hi Anssi, probably not. I'm only getting back to work on Remote Playback API next Monday. Let's move by two more weeks, please.

[anssiko]

Let's plan for 11 July to have the FPWD blockers cleared.

The upcoming vacation period might impact our publishing plans, since we'll need W3C team support to publish an FPWD (can only use the automated publication workflow for WDs).

@tidoust any blackout date for the summer months regarding publishing from the team's perspective? Assuming 11 July we have a publication ready FPWD in our hands, when could we possibly publish earliest?

[tidoust]

@anssiko The only blackout dates before TPAC are next week (Geek Week), so no problem for a later publication.

Once we have a publication ready FPWD in our hands, we first need to record the group's approval to publish the FPWD. Once done, I need to get the approval of the Ubiquitous Web domain lead, and request publication (FPWD still need to be published manually, Echidna cannot be used). The first step is the longest:

• CfC - 10 days which would take us to 22 July. Or is the document ready enough to send a conditional CfC early next week?
• Domain lead approval - <1 day (unless Philipp is not available)
• Publication request - ~2 days but may be less, especially if the document passes "pubrules" (and it will!). Publications happen on Tuesdays and Thursdays.

In short, the internal process should not add much overhead, it all depends on the call for consensus.

Note: as part of the CfC, the group needs to agree on a short name for the spec, which I assume will be "remote-playback" (the shortname appears in the URL of the spec: https://www.w3.org/TR/[shortname]).

[anssiko]

CfC: Publish First Public Working Draft of Remote Playback, review by 11 July

Note: the FPWD publication is conditional to the F2F resolutions being integrated into the spec.

@tidoust To plan ahead, assuming we have a publication ready FPWD by 11 July, can you try to schedule a Domain lead approval as well as publication request at the earliest next opportunity after that?

[tidoust]

@anssiko Yes, I will try to arrange things accordingly.

[anssiko]

First Public Working Draft published:
https://www.w3.org/TR/2016/WD-remote-playback-20160714/