- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Fri, 22 Aug 2014 11:49:01 +0000
- To: "mark a. foltz" <mfoltz@google.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>
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/
Received on Friday, 22 August 2014 11:49:33 UTC