Re: Google/Mozilla Presentation API update

Anssi,

Thanks.  I will get up to speed on Anolis and author a PR as suggested.
 Also I don't mind filing issues under discussion in GH.

m.



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()
>
> ]]
>
> 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.
>
> 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/