Meeting minutes
<angel> https://w3c.github.io/miniapp/charters/wg-2020.html
angel: today's topic is WG charter
Scope
angel: let's look at the scope section
https://w3c.github.io/miniapp/charters/wg-2020.html#scope
angel: any comments on scope?
… "Web technologies (especially CSS and JavaScript)"
… not sure if we need to mention JavaScript here, but let's hear if people have comment on this
Vitality: I have a question about this sentence
… "Elements and APIs that would enhance the interoperability among different MiniApp platforms, including UI elements, Device API, and those advanced APIs such as Account API and Map API;"
… do we plan to work on all APIs provided by the OS?
angel: I don't think we should work on all APIs, we should only work on the necessary ones
… re "which are the necessary ones", we need some discussions
Vitality: so you have not decided yet
angel: right
Vitality: thank you for clarification
angel: We just listed a few APIs we might work on in the future
xfq: we have a GitHub issue for this sentence
… which is issue #79
https://github.com/w3c/miniapp/issues/79
xfq: w3c strategy team discussed this, and suggested us to narrow the scope, identifying which API(s) to develop specifically
angel: I think we should narrow down the APIs in the Deliverables part, but not in the Scope part
… I understand the concerns in the strategy team, but I don't think we should be too specific in the Scope section
xfq: somewhat related issue https://github.com/w3c/miniapp/issues/92
… what should we do to this sentence?
angel: do we want to narrow down the scope?
… let's hear what others think
yongjing: we may change wording from "including [a list of APIs]" to "such as..." or "for example..."
… it's not realistic at this stage to have a exhaustive list of APIs we want to standardize
… I don't think it's common to decide everything we want to standardize during the early phase of standardization
… my opinion is that we should standardize some APIs and components
… but we can't decide which APIs we want to standardize at this stage
angel: agree. We could change "including" to "initial exploration direction" or "hopefully includes"
xfq: But this is exactly the opposite of my suggestion in https://github.com/w3c/miniapp/issues/79
… the scope is more vague instead of more clear with this change
yongjing: it's hard to be specific
angel: we can change the wording as Yongjing suggested
yongjing: I would also suggest that we change the word "element" to "component"
xfq: make sense to me
Dan_Zhou: How about template language such as .maml?
xiaoqian: Does this correspond to the template element in HTML?
<xfq> https://developer.mozilla.org/en-US/docs/Web/HTML/Element/template
xiaoqian: if that's the case, I think that makes sense
yongjing: we can standardize a template mechanism, not necessarily a template language
… we may or may not need a template language
… we can put "components, template, APIs" in the second bullet
angel: people ok with suggested changes?
[hearing no objections]
https://github.com/w3c/miniapp/issues/89
xiaoqian: issue #89
… heard concerns from some vendors and the TAG about us intending to create new technologies for MiniApp instead of reusing existing Web technologies
… to close the gap between miniapp and web tech, can we state the relation between them in the charter?
Yongjing: fair enough
angel: I understand TAG's concern
… but where do you see it fits in the charter?
xiaoqian: to be more clear, I meant that we try to enrich the web
… "close the gap" may not be the right language
angel: I like the word "enrich" better
yongjing: we'll address the comments. people care more about reusing existing standards
angel: the words "enrich, innovate" are fine
… what can miniapp bring to web? We could communicate with TAG about this
… it's good to leverage existing Web technologies
… but it's more important to see what miniapp can bring to the Web
… it's not about forking the Web
… W3C should learn how to benefit from new stuff, and not just make everything "the Web"
xiaoqian: fair enough
https://github.com/w3c/miniapp/pull/91
angel: last call, we basically agreed to remove the "out of scope" para, comments?
xfq: I've created a PR on GitHub
angel: hearing no objections so we'll remove it
Deliverables
angel: let's go to the Deliverables section
https://github.com/w3c/miniapp/issues/92
angel: adding: we'll add new deliverable in-scope without rechartering
xfq's PR: https://github.com/w3c/miniapp/pull/93
[xfq describes the text in https://github.com/w3c/miniapp/pull/93/files]
angel: I'm fine with xfq's PR
… any objections?
[silence]
Timeline
xfq: we need a timeline before AC review, even if it's just a guesstimate
angel: how about FPWD in 2020-03, which should allow us sufficient time to work on the FPWD
… it depends on how long the AC review is
xfq: the AC review itself is six weeks
… but we also have horizontal review, W3M approval etc.
Chunming: 2020-03 may be too late
xfq: the time length between FPWD/CR, and CR/PR matter more
… FPWD date depends on the AC Review
yongjing: any criteria to publish a FPWD?
xfq: publishing FPWD indicates that the Working Group as a whole has agreed to work on a spec
… no other criteria
angel: hard to estimate the timeline
xfq: it's just a guesstimate
yongjing: why 2021-03?
angel: we aim to launch the WG in Oct. so 2020-12 or 2021-03 should be reasonable?
Chunming: [inaudible]
angel: let's vote
… 2020-12 (1)
… 2021-03 (2)
… no preference (0)
<QingAn> 2021-03
<vzasadnyy> 0
<Chunming> dec 2020
<Yongjing> Mar 2021
Nicole: 1
<xiaoqian> Mar 2021
<xfq> 0
Canfeng: 0
Wanming: 0
Ming_Zu: 2
Angel: 2021-03 then. Of course we can hurry up if needed.
… And xfq can put an estimated time for other milestones as well
xfq: that's the difficult part :)
… may different from spec to spec
… I'll try producing a tentative timeline
Success Criteria
https://github.com/w3c/miniapp/issues/60
xfq: we probably need to a testing policy
… do we want to use wpt?
… when do we do tests, before or during CR?
Yongjing: suggests to put simple rules, referring to other groups'
<angel> https://www.w3.org/2020/06/gpuweb-charter.html
<angel> https://www.w3.org/2019/Process-20190301/#charter-extension
<angel> https://www.w3.org/2020/06/gpuweb-charter.html
Angel: is testing policy a must for the charter?
… will it be a blocking issue?
xfq: I don't think it is required by the Process
… but many group charters have one
angel: we have not started testing yet
… it's very difficult for us to decide the testing policy at this stage
Angel: GPU for the Web Working Group Charter doesn't have a testing policy
… I did a quick search and didn't find it
Angel: let's not add it for now and discuss it in the GitHub issue
Coordination
angel: let's go to the Coordination section
xfq: issues about DID WG, EPUB 3 WG, MiniApp CG, and WebAppSec
https://github.com/w3c/miniapp/issues/81
angel: in the Deliverables section we already mentioned the relationship between WG and CG
xfq: for those WGs who has coorresponding CGs like Immersive Web and WebAssembly, they all mention their CGs
… so suggest to add MiniApp CG as well
https://github.com/w3c/miniapp/pull/82
Angel: +1 to add the MiniApp CG. give chance to members to add more groups during AC review
https://github.com/w3c/miniapp/issues/87
Yongjing: DID issue
… I don't know if we should add this
… there was an explicit request about coordination between MiniApps and DID during the W3C internal Project Review
… shall we address the issue now or wait until AC review?
xfq: I don't see harm to add DID though
angel: no objection from me
… let's add it
https://github.com/w3c/miniapp/issues/77
xfq: I added WebAppSec, for potential devices APIs in the future
… and the MiniApp Manifest has a reqPermissions array
angel: make sense
https://github.com/w3c/miniapp/issues/84
Angel: EPUB?
… I don't see the necessity to add EPUB yet
Yongjing: neither do I
xfq: EPUB group people asked about the MiniApp Package
https://github.com/w3c/miniapp/issues/39#issuecomment-634006034
xfq: we could learn from existing wheels in OCF that are useful for MiniApp packages
Angel: I see very narrow overlap between them, OCF and MiniApp Packaging
Yongjing: I agree
… there is very little commonality
… we cannot explore every existing package fromat
angel: suggest not to add EPUB for now
… otherwise more groups will come and ask "why not us?"
xfq: I'm OK with not adding it for now and see if there's any feedback during the formal AC review
xiaoqian: can we add WICG?
angel: we can, but not sure if they'll take our input
xiaoqian: some proposals can go to WICG browser vendors
… I don't think they will object to that
… I saw several of their proposals mention MiniApps
Angel: ok to add
xfq: it seems not common to include WICG in WG charters
… but not oppose to add it
… I'll craft a PR
Participation & Communication
xfq: this is currently just template text
Xiaoqian: between Participation and Communication, can we add a Working Mode section?
xfq: or extend the "Communication" section, with more info, e.g., GitHub
xiaoqian: we need to tell people we have everything on GitHub
Angel: GitHub, public mailing lists, etc.
Yongjing: it's not a required section, right?
xfq: it's not in the charter template
Xiaoqian: state if implementations support required if substantive changes involved
<angel> https://www.w3.org/2019/05/webapps-charter.html#working-mode
angel: looking at their charter
… good to have the description of GitHub and role of Chairs and Editors
… do not suggest to have support from two or more web platform implementers is required before a substantive change can be made to a spec
… since it's a new group
xfq: agree
… can wait when our specs get more stable
yongjing: I think the first paragraph of Working Mode is already covered
… the second and third paragraphs are not necessary
… the second paragraph is already the default behavior
… and the third paragraph is not necessary because of reasons said by angel and xfq
angel: so let's keep it as it is
… do not add a new working mode section
xiaoqian: ok for me
xfq: we should create a new repo for the WG
… should not reuse the CG repo
… otherwise it would cause difficulties for our IPR bot
angel: absolutely
Other sections
angel: Decision Policy
… any comment?
Yongjing: as long as it follows the good practice of the template
xfq: it is
angel: Patent Policy
… make sure we are using the latest one
… we need a start date
… September or October?
xiaoqian: it can be a placeholder for now
angel: OK
… let's produce a clean version and call for consensus in the CG
Mapping
https://github.com/w3c/miniapp/issues/74
xfq: last issue
… issue #74
… suggesting a coordination of the Maps CG
… somewhat related to https://github.com/w3c/miniapp/issues/79 as well
angel: I don't have any strong preference
Yongjing: we can just remove the Maps API in the charter
… and this issue can be resolved
xiaoqian: +1 to yongjing
angel: we can add it back if we are going to work on Maps in the future
… +1 to yongjing
AOB
Yongjing: the GitHub working mode isn't clear enough to me
… is PR required?
… if so, how many reviewers are require for each PR?
… shall we leave it to future discussion?
angel: good question
… for some groups it require group concensus
xiaoqian: some of my groups require 1 or two reviewer and group consensus
xfq: different from groups to groups
… CSSWG doesn't require the use of pull requests
… but has been using PRs more and more recently
… some groups may require the use of PRs
Yongjing: we can set some rules later
angel: thank you everybody for the discussion
… once we have the updated version
… I'll send out the CfC to the group
… 10 working days for the group to review the charter
… after that we will start the W3C process
… welcome to raise issues
… next CG call will be 9th July
[adjourned]