anssik: We met in Jan. Made lots of progress since then.
… Will talk about publication plan and new charter today.
https://github.com/w3c/sensors/issues/299
<anssik> https://github.com/w3c/sensors/issues/299#issuecomment-369924348
anssik: In the TAG issue (https://github.com/w3ctag/design-reviews/issues/207), we got a lot of feedback
… also got feedback from Security IG and PING
<anssik> Search "Proposed changes:"
anssik: Search "Proposed changes:" in this issue to find PRs corresponding to the feedbacks
<anssik> Summary: Based on the group's assessment, TAG review feedback did not yield normative changes to the specifications under wide review. The review comments helped improve various informative aspects of the specifications and readability was further improved. The review comments further reinforced group's view that the specifications are ready to advance to Candidate Recommendation stage in the near future.
anssik: the sensors specs are ready to go to CR
<anssik> https://github.com/w3c/sensors/projects/4
anssik: I would like to congratulate the group to close all Level 1 issues of Generic Sensor
<anssik> Throw exception when screen coordinate system is not supported
<anssik> https://github.com/w3c/accelerometer/issues/35
anssik: propose to discuss open issues of concrete sensors specs today
anssik: I personally think feature detection of this is useful
… WDYT?
<anssik> OrientationSensor interface to provide Euler angles
<anssik> https://github.com/w3c/orientation-sensor/issues/43
[silence]
anssik: ok, we will make it in L1
alexander_shalomov: manual conversion in JS is needed currently
… if you search "how to use motion sensors on the web", the results use old APIs
anssik: we need to decide if this feature is in scope [in L1]
anssik: should we defer this to L2, or in a new CR of L1?
<anssik> GeomagneticOrientationSensor interface
alexander_shalomov: L2, I think.
<anssik> https://github.com/w3c/orientation-sensor/issues/15
anssik: ok then.
<anssik> Improve guidance on UI for user consenting
anssik: we'll defer orientation-sensor#15 to L2 too
<anssik> https://github.com/w3c/sensors/issues/352
anssik: this is a very recent issue
… it's about guidance on UI for user consenting
… what the spec does now is providing extension points
<anssik> https://github.com/w3c/sensors/pull/353
<anssik> https://w3c.github.io/sensors/#security-and-privacy
anssik: this PR basically adds a note
… in my opinion the issue is addressed
… any comment?
Mikhail_Pozdnyakov: in my opinion, this is beyond our scope
… the mitigation strategies already mitigate the potential risks
anssik: this spec is a huge improvement over the previous APIs in terms of security and privacy
… propose to close this issue; feel free to comment/reopen if you have further comments.
<anssik> https://github.com/w3c/sensors/issues/355
anssik: I created a meta issue
<anssik> Generic Sensor API - https://w3c.github.io/sensors/
<anssik> Ambient Light Sensor - https://w3c.github.io/ambient-light/
<anssik> Accelerometer - https://w3c.github.io/accelerometer/
<anssik> Gyroscope - https://w3c.github.io/gyroscope/
<anssik> Magnetometer - https://w3c.github.io/magnetometer/
<anssik> Orientation Sensor - https://w3c.github.io/orientation-sensor/
anssik: the CR scope is clear
… I went through the CR requirements in the Process
… we have requested and received wide review
<anssik> must show that the specification has met all Working Group requirements, or explain why the requirements have changed or been deferred,
<anssik> https://w3c.github.io/sensors/usecases
<anssik> https://w3c.github.io/motion-sensors/
anssik: based on my assessment, the specs meet the requirements set forth in the DAS WG Charter
… and satisfy Sensor Use Cases as demonstrated in Motion Sensors Explainer
<anssik> must document changes to dependencies during the development of the specification,
<anssik> must document how adequate implementation experience will be demonstrated,
anssik: see changes to dependencies in the issue
… we have test suites and preliminary implementation reports
<anssik> Propose: The CR exit criterion is two interoperable deployed implementations of each feature.
<anssik> must specify the deadline for comments, which must be at least four weeks after publication, and should be longer for complex documents,
anssik: CR exit criteria means "when are we ready to move to the next stage (PR)?"
<anssik> Proposal: This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than [six weeks after its publication].
<anssik> must show that the specification has received wide review,
<anssik> Wide review received, see tracker https://github.com/w3c/sensors/issues/299
anssik: we will use six weeks for the deadline for comments, because there're multiple specs
<anssik> may identify features in the document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation.
<anssik> Proposal: No features are marked as 'at-risk'.
anssik: "at risk" means if you're not confident whether a feature will be in the final recommendation, you can mark it "at risk" and remove it before PR
… I don't identify such features in the sensors specs
… I'll send a Call for Consensus for the CR
Mikhail_Pozdnyakov: for Chrome implementation we don't need throw exception [when screen coordinate system is not supported]
anssik: W3C Management (hopefully) reviewed the draft charter yesterday
… do you have more info, xfq?
xfq: not currently, will check.
anssik: I'll be on vacation
Succeeded: s/from PING/from Security IG and PING/
Succeeded: s/Level 1 issues/Level 1 issues of Generic Sensor/
Succeeded: s/decide to//
Succeeded: s/requested/requested and received/
Succeeded: s/when screen coordinate system is not supported/[when screen coordinate system is not supported]/