- From: mark a. foltz <mfoltz@google.com>
- Date: Wed, 3 Sep 2014 13:19:03 -0700
- To: "Kostiainen, Anssi" <anssi.kostiainen@intel.com>
- Cc: "Rottsches, Dominik" <dominik.rottsches@intel.com>, "public-webscreens@w3.org" <public-webscreens@w3.org>, Jonas Sicking <jonas@sicking.cc>, Anton Vayvod <avayvod@google.com>, Marco Chen <mchen@mozilla.com>, Wesley Johnston <wjohnston@mozilla.com>, Evelyn Hung <ehung@mozilla.com>
- Message-ID: <CALgg+HH=J6ENvQCS76J=eybCJ-xfSz2RbG5qMtCwYnVe6bH+2w@mail.gmail.com>
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/
Received on Wednesday, 3 September 2014 20:19:50 UTC