<tink> scribe: tink
CMN: Lots to get through.
... Have talked to Shwetank and Bruce.
... Do others have issues they're unlikely to complete, or time to take on more issues?
... Or issues where you want help?
SD: I've taken up a few.
CMN: We have lots of issues raised by Programmer3000
... Most issues are valid, though editorial, and fixing them would be good - but they can be done after this milestone.
... We need to focus on substantive issues in this milestone.
SD: Can we go through the substantive issues?
CMN: We can.
... The Custom Elements issues are assigned to Bruce. Everyone is welcome to pick these up and help out though.
#1311 and #1312 are privacy issues that would be good to resolve in this milestone.
scribe: We will ask both Security and Privacy WGs to review.
... #1298 and #1299 are also substantive.
... #1296 is a simple one. Assigned to Xiaoqian, who is sick, so help is appreciated.
... #1256 is another.
... I'm hopeful Bruce will merge the bulk of the Custom Elements content today.
... Following that, some comparitive evaluation will probably turn up smaller issues.
... Help appreciated.
... #44 is worth looking at.
... #214 is another.
... #255 is another worth looking at if we can.
... If anyone needs help with issues, today is a good day to ping me.
PG: Help with #773 wuld be welcome.
CMN: I can do that.
... Reminder that if we don't get substantive changes into this milestone, it is very hard to do so later.
CMN: Bruce is working on this today.
... This is a significant change.
... Also likely that there will be out-dated content, which will result in issues.
LW: Are you merging from the W3C spec and verifying currency?
CMN: Yes, but the validity verification is spotty.
<chaals> ... e.g. we are believeing MDN and CaniUse if they agree, but we know that is not a guarantee and we will need to test
CMN: We need to complete an implementation report to exit CR.
... ... As you make changes, please update the implementation report for all substantive changes.
LW: It's a bit late for all the changes already committed.
... Don't mind adding those, it didn't take long last time.
CMN: Yes.
<chaals> scribe: chaals
SD: What do we do when we know there is not much browser support?
... this is a request for input tye=currency
... i.e. a feature request.
CMN: We usually suggest they make a proposal on discourse.wicg.io and get some buy-in from developers, provide use cases and requirements that explain why we would need this, and try to get buy-in from implementations
<shwetank> yeah, now its up
SD: Discourse is not reliable
CMN: Yes. It is *not* dead, but it does keep falling over :(
... So usually we mark these as needs incubation and close them.
SD: Suppose something is proposed on WICG, and discussion fades out...
zakim: take up item 4
<sangwhan> Outside of Asia is tricky for me, mostly because I'm self funded. Thailand might be possible in a stretch, but I couldn't find a member host there
CMN: We are currently split between Asia and Europe so we need a decision, and timing is either first week or so of June, or third week or so (18th - 25th)
CMN: So the next thing we do is produce a Working Draft that we send "for wide review".
... specifically we ask accessibility, i18n, privacy, security people to look at it, and any community who is obviously affected by some particular change.
... We encourage you to spread the word and ask for feedback.
... That should be in within about a month so we can wrap it into a new draft, and we will ask the Working Group to approve that draft as a Candidate recommendation.
<sangwhan> I would suggest the chairs to maybe keep an eye on this, which will be touched on during the Tokyo F2F.
<sangwhan> https://github.com/w3ctag/design-reviews/issues/174
CMN: In principle that menas a feature freeze, and the only sustantive changes are removing things we already marked "at risk" becausee they didn;t get the implementation to convince the W3C Director that they belong in a Rec.
... CR lasts for at least a month, typically more like 2. e need to produce our implementation report during CR.
... Then we ask for the next WD to be approved y the WG as a Proposed Recommendation.
... At that point we are done, and the W3C members aand Director decide to publish it (or not)
... We can branch at some point to continue work on a new version. Probably for now we will not do so much before PR, since there are a lot of editorial changes that would be useful and it's easier not to merge across branches - we can hold substantive changes in issues for a couple of months.
SD: e.g. figuring out whether to deprecate object/embed/both
... what should we do?
CMN: Deprecatng things takes time - the goal is to remove them from the web.
... so the first thing is to establish that by and large people don't want the feature and there isn't a *LOT* of objection to removing it.
... Then we get some real consensus to mark it deprecated, which usually means we move it to the obsolete section, becausee most of the time browsers still need to know how to handle it and it still needs ot be parsed becausee it is in the wild
[examples of things we deprecated - plugins, appcache, keygen]
<sangwhan> https://wiki.mozilla.org/ExposureGuidelines#Intent_to_unship
<sangwhan> Chromium example: https://groups.google.com/forum/#!topic/mozilla.dev.platform/3b700_oeAzo
<sangwhan> ...sorry, that was also mozilla.
[adjourned]
<sangwhan> Chromium/Blink: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/nQl0ORHy7sw/HNpR96sqAgAJ