additional minutes from Aleecia

I don't have any means to interleave these with Brendan's scribing on IRC, but
it is very nice to have a second view (even of a short meeting).  Sending here so
that I can link them into the official minutes for today's meeting.

....Roy


Begin forwarded message:

From: "Aleecia M. McDonald" <aleecia@aleecia.com>

Scribing here, 
Roy: ok with general direction but would like to fix working. 
David: you'll take the action to polish?
Roy: yes
... will get that done this week.

David: other things needed before 2nd CR?
Rob: editorial, section on fingering printing could move from section 7.10 to "privacy considerations," is there a reason not to move it?
David: indeed it is
Roy: yes, I could move that.
David: we have security & privacy considerations section?
Roy: yes, we do
David: objections to moving? (None) Great, let's do that.
... are there any other issues here or in github tracker?

Roy: I'll look for any editorial. I know Aleecia still had an issue. A number of others were closed when I was not on the call.
... going to change API names for the APIs that changed.
Mike: if we're going to change the names we should discuss that, don't want to break MSFT's implementation 
Roy: the API changed so they no longer have an implementation (anyway)
Mike: only the effects of the confirm change, so it wouldn't break their world (paraphrased)
... can return the boolean results immediately, very minor change, 
David: could you do a pass through, Roy? Take a look?
Roy: can do so and look at what's actually implemented. Prior MSFT experience, it's easier to replace than make a change to existing no matter how small
(discussion of changes anyway)
Aleecia: we did agree to change the names
David: Roy, please give it a go and post a draft for WG consensus to push it to WD and then CR
Roy: (agreement)
David: this week we hope to see that

Aleecia: issue 35, path a appeared not to draw objections, 
Roy: https://github.com/w3c/dnt/issues/35
David: this should be the website presenting rather than the UA
Aleecia: you are correct, we should change that. 
Roy: could be this release or we could get it in next release and discuss it now
Shane: important for CA residents, but still the rest of the globe.
... for these matters of TPE language want MAY not SHOULD
Shane: compliance specific should be not in the TPE
... lack of compliance document is pushing discussions into the TPE where it shouldn't be
... think technical standard is not the right place
Aleecia: we only have a tech standard
Mike: can't see objections to what Aleecia's saying
Roy: could add examples of how we expect people to use it and what might be provided in a compliance document, non-normative 
... don't want to constrain the space of how compliance is implemented and don't see that as valuable
... then we've had to agree to one standard. but examples are fine.
David: could have best practices
Roy: one example is... this in compliance, this in tracking status, this provided to user
Shane: do have a compliance & scope document just aren't moving it forward. can do examples. wouldn't use "encouraged" just examples.
David: could propose text?
Shane: take Aleecia's original note, add MAY
David: collabotate on that with examples and MAY?
Shane: ok with MAY and examples
Aleecia: can live with this
David: MAY in normative text plus examples
Roy: could be an example of a compliance spec requiring steps
... just an example of how TPE works with that, anyone can define a compliance spec
David: think we can converge 
Aleecia: not what I thought I'd agreed to.
... would change SHOULD to MAY with examples
David: try drafting and see if we can get there. 
... change SHOULD to MAY, fix UA, add examples
David: issue 35, try to do that in a day or two
... might make it in

Received on Monday, 19 June 2017 16:46:45 UTC