Re: Google/Mozilla Presentation API update

I have filed issues #8 - #19 in the GitHub issue tracker based on
discussions in the CG and attempted to back-reference them (some of the
threads were very long so this is not precise).  It may not be exhaustive
and I encourage others to add or edit issues.

https://github.com/webscreens/presentation-api/issues

I propose a workflow where we continue to discuss issues here, and use GH
to record the resolution of issues when consensus has been reached.  After
resolution, a pull request can be used to propose updates to the
specification documents for one or several issues.

My assumption is that the majority of these issues would carry over to the
WG as well.   If you anticipate a different workflow (i.e. will we move
away from GitHub for issue tracking and change management) then we can deal
with it then, but a heads up would be appreciated.

Cheers,
m.



On Wed, Sep 3, 2014 at 1:19 PM, mark a. foltz <mfoltz@google.com> wrote:

> On Fri, Aug 22, 2014 at 4:49 AM, Kostiainen, Anssi <
> anssi.kostiainen@intel.com> wrote:
>
>> Hi MarkF, All,
>>
>> On 21 Aug 2014, at 03:15, mark a. foltz <mfoltz@google.com> wrote:
>>
>> > You're welcome.  You said you would work on incorporating them into the
>> spec draft, is your idea to wait for the outcome of this discussion and
>> them create a pull request on GH?  (Just want to get an idea of the process
>> for spec updates at this stage.)
>>
>> It is up to the group to decide whether to use Commit-Then-Review (and
>> revert if concerns) or Review-Then-Commit, as long as we maintain
>> consensus. GitHub makes it pretty easy to use the R-T-C model.
>>
>> Concretely, I propose a model, where the editor, or other active group
>> participant, prepares a PR based on group’s feedback and then asks the
>> group on the mailing list for review. The PR will be updated based on the
>> group’s feedback until consensus is reached (the Chair should be consulted
>> to determine the consensus of the group, if not obvious), and finally, the
>> editor merges the PR when the group is happy.
>>
>> Since Dominik is out of office for a couple of days (and welcomed your
>> PRs!), it’d be great if you could start with a PR that updates the spec IDL
>> as per the Google/Mozilla proposal for parts that were agreed upon in the
>> group (i.e. no concerns). Dominik is back next week, so if you’d like to
>> work together on the update that’s fine too (meanwhile, to get you up and
>> running, you may want to familiarise yourself with the toolchain -- we’re
>> using Anolis [1] for this spec).
>>
>> Some changes for which I think we did not hear any concerns were outlined
>> in my mail [2]; I think these would make a good first PR:
>>
>> [[
>>
>> * drop “onpresent” event handler from the NavigatorPresentation interface
>> * add “session” attribute to the NavigatorPresentation interface
>> * drop the PresentEvent interface
>> * The “session” attribute exists on the “presenting" page only. The
>> “controlling" page can get hold of the session via requestSession()
>>
>> ]]
>>
>
>
> Sorry for the delay, but I got my environment set up to edit the spec and
> have created a pull request with these changes.  PTAL
>
> https://github.com/webscreens/presentation-api/pull/7
>
>
>> Changes and proposals that are still being actively discussed we should
>> record by opening issues at [3]. Any of the group participants could open
>> issues, so feel free to contribute here as well. Given the mailing list
>> discussions are archived [4], we can point to them in the issues.
>>
>
> I will start working on this today as well.
>
> m.
>
>
>>
>> This is just one implementation of the process in accordance with the CG
>> Charter we have agreed upon.
>>
>> All - suggestions are welcome on what type of process you’d prefer to
>> use, or if there are concerns with the above process proposal.
>>
>> After the expected WG migration, we’ll follow the W3C Process document
>> [5] in the WG. Many details of the work mode are left as implementation
>> details by that document, so in principle, we’d go about as in this CG
>> (when crafting the CG Charter, we wanted to make this group a transparent
>> and fair forum to ease potential migration into a WG).
>>
>> Thanks,
>>
>> -Anssi
>>
>> [1] http://wiki.whatwg.org/wiki/Anolis
>> [2]
>> http://lists.w3.org/Archives/Public/public-webscreens/2014Aug/0007.html
>> [3] https://github.com/webscreens/presentation-api/issues
>> [4] http://lists.w3.org/Archives/Public/public-webscreens/
>> [5] http://www.w3.org/Consortium/Process/
>
>
>