Meeting minutes
AC review of MiniApp WG charter
angel: we have been hearing some feedback during AC review
… I won't share the objector's information because it's W3C member-only information
… but we can discuss the content of the objection here
proposed WG charter: https://
angel: the major suggested change about the charter is about the scope
… concerns about section 2.2 New Recommendation-track deliverables
[[
The Working Group may work on additional in-scope Recommendation-track deliverables without preparing an updated Charter.
The Working Group will not adopt new proposals until they have matured through the MiniApps Ecosystem Community Group.
]]
angel: one possibility is to delete this section in total
… we can recharter if we want to work on something new
… I'd like to hear from the group
… if this is OK
ThomasSteiner: could you repeat the concerns?
[angel repeats]
ThomasSteiner: Can xfq outline if it would be "legal" by W3C rules to have this section, or if re-chartering is always required.
xfq: default that you can add new deliverables in-scope, unless charter explicitly prohibits
… for example, the Devices and Sensors Working Group charter does not allow additional in-scope REC-track deliverables to be added without rechartering
… but the CSSWG allows that
angel: does xfq's answer answers your question, ThomasSteiner?
ThomasSteiner: yes
angel: can you live with it if we delete this section?
ThomasSteiner: personally yes, but I'm not the person who is experienced with W3C rules
angel: we decided to remove the out of scope section in https://
angel: we received a PR from Huawei
https://
<angel> https://
angel: martin has put some out of scope bullets
… about the first bullet (the CSS one), I hope that's fine with everybody
[silence]
angel: about the second bullet
… would it be okay if we add some conditions
… like we don't work on browser APIs without a concrete plan to work with existing working groups
… if no such working group exists, then we will work on it
… would that be ok, martin?
martin: yes
angel: thank you, martin
angel: the third point: "Define changes to the existing HTML markup language and to the Document Object Model (DOM) specifications"
… is everybody ok with it?
… I don't think this WG is going to touch this field
[silence]
angel: about the last one, a bit tricky
… "Redefine any existing W3C normative specification related to the Web runtime, such as the standards produced by the Web Applications Working Group."
… how does everybody feel for this one?
ThomasSteiner: go back to CSS, sorry
… there are a lot of miniapp platforms that define the "rpx" unit, responsive pixels
… is the WG interested working on it with the CSSWG?
angel: if that's something the CSSWG might be interested in working on, we can provide requirements and make it happen
xfq: The group can indeed provide uses cases and requirements to the CSS WG about density-independent pixels, not necessarily from the MiniApps WG, but also can from the MiniApps CG
… not necessarily from the MiniApps WG, but also can from the MiniApps CG
… the CG can file issues against the w3c/csswg-drafts GitHub repo
angel: during our last phone call we discussed some ideas for the CG to incubate
https://
angel: maybe we can track this in a GitHub issue
ThomasSteiner: sounds good to me
angel: any other thoughts on CSS?
… hearing none, let's get back to the last bullet of the out of scope section:
… "Redefine any existing W3C normative specification related to the Web runtime, such as the standards produced by the Web Applications Working Group."
… Martin, may I hear the logic behind this bullet?
martin: yes
… it's trying to clarify that we won't redefine existing specifications
angel: thank you for the explanation
angel: how does everybody feel about this one?
[silence]
angel: I have some minor concerns about this one
… it's similar to bullet 2
… not sure if our Lifecycle work is considered "related to the Web runtime"
… would that be OK if we delete this one?
… leave us more room
martin: yes
angel: if no one objects, let's remove this one
… I suggest we keep the "This Working Group will not mandate implementation details in terms of security, UI components, [...] best practices and other non-normative documents." paragraph
… thanks martin for the help
… there are other minor suggestions
… paragraph 1 chats about history, which is out of place, and should be in an introduction
… we can move the first few paragraphs to a separate section, as martin did in his PR
… leave the scope section as pure scope
… paragraph 2 uses uses the ambiguous English construction "may not"
… to be more accurate one way to fix it is to change it to "may or may not" to include the browsers as well
ThomasSteiner: sounds good to me
… because it's more inclusive
angel: if there's no objection let's change it to "may or may not be"
… and change "is not based on web resources" to "may or may not be based on web resources"
angel: paragraph 2 says "requirements are identified" and it's not clear if that means that they have been already, or will be
… let's change it to "requirements have been identified"
… since we do had a lot of explorations
… I hear no objections about this one
… one last minor change suggested is the last word of paragraph 3
… "including"
… it only hint at the scope
… what about changing it to "MiniApp features, which is listed as the following"?
… that's all the suggested changes we have heard by far
… could we update the proposed charter during AC review, or we can only do that after the AC review?
https://
https://
xfq: the current draft under Member review can't be modified now, but we can reflect suggested changes in the charter on GitHub and ask the reviewers whether they are ok with the changes
angel: thanks for the explanation
… we have 9 days left, I hope to get more support in the following 9 days
angel: anything the group would like to discuss about the AC review?
GitHub issues
<angel> https://
https://github.com/w3c/miniapp/issues/146
angel: we did not discuss the "WG repo" issue last time
… given that we might launch the WG soon, we can have some good discussion today
… either we use the current one or use a new one
… any opinion?
… the pros for using this one is to keep all things in one place, easier to find and manage
… but IPR policies of CG and WG are different
… I'd like to hear from the CG/WG participants
xiaoqian: W3C has a IPR bot
… if you log in through GitHub and associate your GitHub account with your W3C account
… the bot will detect automatically
… we can accept your pull request only if your organization is a member of the WG
… otherwise the WG will have IPR issues
xfq: as I mentioned in the issue the W3C IPR bot doesn't work well with this model
xiaoqian: it's suggested to create a repo for each document once they move to the REC track
xfq: yes, that will be easier to manage the specs
… although it is a bit troublesome to create a lot of repos, in the long term it will be easier
… because if a spec is moved to another group, there's no need to set up redirect, move issues etc.
angel: you prefer one repo for each spec or one repo for each group?
xfq: one repo for each spec
xfq: There are three ways:
… 1. one repo for all the work in the CG and WG
… 2. two repos, one for CG, one for WG
… 3. multiple repos, one for each spec
… in the long run, I think the third option is better
yongjing: in the one-repo-for-each-spec model, what to do when we move a repo from CG to WG?
xiaoqian: Because the two IPR policies are different, you need to issue CfE for the working group specs
Yongjing: I'm aware of that
… I mean the repo management
xiaoqian: we have a mechanism to associate a repo with a group
… if the group of a spec changes we can change the association as well
… we have an id for each group and the spec is associated with that id in the repo
yongjing: my first impression is that the third option is much too heavy
… if one spec is split into two or more specs, will it cause trouble?
xiaoqian: If we keep the commit & issue history, there is no problem
xfq: it should not appear often, but it does happen from time to time, like the Wake Lock spec in the DAS WG
yongjing: if you want to make a change that's related to two specs, you can't do one pull request
xfq: other groups have similar problems, such as the interdependence of test and spec pull requests
yongjing: OK
… what's the most common practice in W3C?
xfq: All three models exist, as far as I know, the third one, one-repo-for-each-spec, is the most common.
xiaoqian: we can also have a working group repo without any spec
xfq: it can list all specs in this group
yongjing: if we have two repo for two groups we have to maintain two specs in parallel and they can be out of sync
xiaoqian: no, we only have one repo for one spec
yongjing: I mean option 2
xfq: in option 2 we move the specs and issues from the CG repo to the WG repo after they are mature
… and set up redirects for specs and Markdown documents like explainers
xiaoqian: because the IPR policy of the CG and the WG are different
Yongjing: what's the problem for option 2?
xfq: the problem is that we need to move the issues and set up redirects for specs and Markdown documents each time we move a spec
yongjing: So it only happens when we move the specs
… the W3C Team has more work
xiaoqian: if we have one repo for each spec it's much easier
… issue management is also more clear if we have one repo for each spec
yongjing: the cost for the contributors is that they need to maintain a lot of git repos locally
xiaoqian: we can add chairs & editors to github teams
xfq: that's only about access permissions and mentions
… I think what yongjing meant was that it's troublesome to manage too many repos
… This is indeed a problem. In the DAS WG, every motion sensor has its own repo, so there are a lot of repos.
angel: other people's opinion?
… we have spent enough time discussing this today
… we can discuss it on GitHub and hear from new WG participants as well
https://github.com/w3c/miniapp/issues/144
angel: we have rough consensus on this
angel: can you work on it, xfq?
xfq: OK
https://github.com/w3c/miniapp/issues/137
[angel describes the issue]
martin: we can close this issue
https://github.com/w3c/miniapp/issues/126
Tengyuan: I think it's hard to solve this issue
… I think we can close it
AOB
angel: AC review will end in December 19
angel: next call: 14 Jan same time, 12 UTC
angel: hopefully we will have enough support to launch the WG
angel: thank you all!
[adjourned]