search

w3c / deviceorientation

W3C Device Orientation spec
https://www.w3.org/TR/orientation-event/
Other
49 stars 32 forks source link

Wide review tracker #130

Closed anssiko closed 4 months ago

anssiko commented 6 months ago

About

This is a meta issue to track wide review for the DeviceOrientation Event Specification.

An important part of wide review is horizontal review from W3C's key horizontal groups listed below in horizontal groups section. Also feedback from other stakeholders is equally important. Additional pointers are welcome via comments.

Legend: 🔴 Review request not submitted 🟡 Review request submitted 🔵 Review feedback received 🟢 Review closed as completed

History

The reviews may want to know that...

This spec initially reached CR in August 2016 (history) and was retired in 2017 due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the changes section.

A new CR Snapshot publication in expected in Q1'24 if no unresolvable concerns in this wide review are unearthed. We expect to make this a joint deliverable between the DAS WG and WebApps WG.

Horizontal groups

🟢 ♿ Accessibility

🟢 📐 Architecture

🟢 🌍 Internationalisation

🟢 🔍 Privacy

🟢 🔒 Security

Other stakeholders

From who to ask for review:

Horizontal reviews [...] are only a subset of a full wide review, which must also include other stakeholders including Web developers, technology providers and implementers not active in the Working Group, external groups and standards organizations working on related areas, etc.

anssiko commented 6 months ago

@himorin @rakuco @reillyeon if this wide review plan sounds good to you I will start engaging with the horizontal groups seeking your review and input on any materials required.

anssiko commented 6 months ago

The first proposal for the a11y checklist response is available for review and comment in #131. Once the WG is happy we'll submit an a11y review request providing this issue #131 as input.

reillyeon commented 6 months ago

This plan looks good to me. Can we also schedule an ad-hoc WG meeting to triage the currently open issues and tag them with what should or should not be resolved before PR? I think we're looking pretty good but it

himorin commented 6 months ago

The plan also looks good to me. Although it seems there is no possible at-risk feature from current issue list (most non-vnext are clarification?), we also need to think about possible at-risk...

anssiko commented 6 months ago

Thanks for your support.

The first proposal for the i18n checklist response is also available for review and comment in #132. Proposed summary: Based on this self-assessment the WG believes no Internationalization Considerations section is required. Hearing no concerns, I will approach both a11y and i18n groups to start the discussion.

Privacy, Security and TAG reviews are blocked on PR #126. @rakuco we appreciate your review on that PR. Once we merge that PR I will draft a proposal on how to approach TAG to make the best use of their limited review bandwidth. Security review also depends on that PR, but that review forum has been less active recently, while Privacy and TAG I expect to actively provide feedback.

I support an ad-hoc WG meeting to triage the currently open issues. Let's find a timeslot for that.

anssiko commented 5 months ago

I have now requested Accessibility https://github.com/w3c/a11y-request/issues/71 and Internationalization https://github.com/w3c/i18n-request/issues/224 reviews on behalf of the WG.

anssiko commented 5 months ago

I also initiated Privacy https://github.com/w3cping/privacy-request/issues/128 and Security https://github.com/w3c/security-request/issues/63 reviews with a record of our self-review responses as a reference.

anssiko commented 5 months ago

Hidden in the "[DRAFT] Specification review" disclosure element below is the first proposal for the TAG review request. Please peek inside, everyone.

I want us to iterate on this as a group before we file to make sure we include all relevant information and frame this request properly. Contributions wanted via comments to e.g.:

[DRAFT] Specification review I'm requesting a TAG review of DeviceOrientation Event Specification. This specification defines several DOM events that provide information about the physical orientation and motion of a hosting device. - Explainer¹ (minimally containing user needs and example code): This feature has a good [MDN entry](https://developer.mozilla.org/en-US/docs/Web/API/Device_orientation_events) with example code, see also [Motion Sensors Explainer](https://w3c.github.io/motion-sensors/) for an introduction to low-level and high-level motion sensors, key concepts - Specification URL: https://www.w3.org/TR/orientation-event/ - Tests: https://wpt.fyi/results/orientation-event ([expected updates](https://github.com/w3c/deviceorientation/issues/130#issuecomment-1917516374)) - User research: [url to public summary/results of research] - Security and Privacy self-review²: [[self-review]](https://github.com/w3c/deviceorientation/blob/main/security-privacy-self-assessment.md) - GitHub repo (if you prefer feedback filed there): https://github.com/w3c/deviceorientation/ - Primary contacts (and their relationship to the specification): - Reilly Grant (@reillyeon), Google, editor, co-chair - Raphael Kubo da Costa (@rakuco), Intel, editor - Anssi Kostiainen (@anssiko), Intel, co-chair - Organization(s)/project(s) driving the specification: Google, Intel - Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification: - This specification is implemented by the major browser engines, see [MDN browser compatibility](https://developer.mozilla.org/en-US/docs/Web/API/Device_orientation_events#browser_compatibility) and [caniuse.com](https://caniuse.com/deviceorientation). - External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): Further details: - [x] I have reviewed the TAG's [Web Platform Design Principles](https://www.w3.org/TR/design-principles/) - Relevant time constraints or deadlines: A new CR Snapshot expected in March 2024. - The group where the work on this specification is currently being done: Devices and Sensors WG - This specification is expect to become a joint deliverable with the WebApps WG to be jointly published by the two groups before it advances to Rec. - Major unresolved issues with or opposition to this specification: None - This work is being funded by: Google, Intel You should also know that... This spec initially reached CR in August 2016 ([history](https://www.w3.org/standards/history/orientation-event/)) and was [retired in 2017](https://www.w3.org/TR/2017/NOTE-orientation-event-20170530/) due to the Geolocation WG closure. In 2019 DAS WG adopted this spec and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the [changes](https://www.w3.org/TR/orientation-event/#changes) section. These changes since the previous CR Snapshot from 2016 align the specification with widely available implementations, improve interoperability including testability, and add new features for enhanced privacy protections. This is a high-level API whose low-level API correspondence Orientation Sensor was reviewed by TAG in https://github.com/w3ctag/design-reviews/issues/207 The functional diff is explained in [high-level vs. low-level ](https://www.w3.org/TR/generic-sensor/#high-vs-low-level) and [Orientation Sensor](https://w3c.github.io/orientation-sensor/#intro). We'd prefer the TAG provide feedback as (please delete all but the desired option): 🐛 open issues in our GitHub repo for **each point of feedback**

Click to unfold ⤴️

Thanks for your contributions!

rakuco commented 5 months ago

Thanks @anssiko for all the work so far, and apologies for the time it took for me to comment here.

From a testing perspective, I feel like the tests in WPT need to be improved:

anssiko commented 5 months ago

@rakuco thanks for sharing the rationale for the current test failures and a plan on how to address this. I don't think this blocks the TAG review. TAG may want to understand why we're not fully green, so I updated the TAG review request proposal with a link to this issue. When we publish a CR Snapshot, and if we still show significant red, we are similarly expected to share a rationale and a plan on how to address it. The general policy is that for specs in CR and above we have good test coverage.

reillyeon commented 5 months ago

The bit of the draft TAG review request I'm concerned by is the stakeholder feedback section. I don't know how the TAG wants a feature with existing support by multiple implementations that predates the "standards position" concept to be presented. There are of course years of discussion on this specification from many parties but no clear set of authoritative references to point to. My intuition is to simply state that this specification is implemented by the major browser engines and perhaps to link to MDN or caniuse.com as the source for that assertion.

anssiko commented 5 months ago

We've now completed the i18n review. 🥳

Re TAG review, I updated the draft proposal in https://github.com/w3c/deviceorientation/issues/130#issuecomment-1914752227 per @reillyeon's suggestion:

Key pieces of existing multi-stakeholder (e.g. developers, implementers, civil society) support, review or discussion of this specification: This specification is implemented by the major browser engines, see MDN browser compatibility and caniuse.com.

The act of implementing and shipping is the most obvious support signal. This seems appropriate and avoids busywork.

This is the last call for comments to the TAG review request before we submit.

reillyeon commented 5 months ago

It looks good to me. Thank you @anssiko.

anssiko commented 5 months ago

I have submitted the Architecture/TAG design review request: https://github.com/w3ctag/design-reviews/issues/928

With that out of the gate, all the wide review requests are either submitted or completed. I'll bring any review feedback from these reviews to the WG's attention to be addresses in a timely matter.

Related, we'll organize an issue triage working session on 12 Feb 2024. In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for the expected CR Snapshot publication.

himorin commented 5 months ago

Related, we'll organize an issue triage working session on 12 Feb 2024. In this working session the editors and other contributors will triage the remaining DeviceOrientation Event Specification open issues in preparation for the expected CR Snapshot publication.

will we invite interested WebApps colleagues to this call? (I believe this is one of joint deliverables)

reillyeon commented 5 months ago

I think we should extend the invitation, even if the joint deliverable relationship isn't quite official yet.

anssiko commented 5 months ago

@himorin the easiest path would be to extend the invite to the entire WebApps WG, but Meetings policy suggests we can't do that (yet), right? We can however invite "an individual with a particular expertise to attend a meeting on an exceptional basis".

@marcoscaceres qualifies and can identify other WebApps WG participants for consideration who might be interested in joining the upcoming issue triage working session on 12 Feb 2024.

himorin commented 5 months ago

@himorin the easiest path would be to extend the invite to the entire WebApps WG, but Meetings policy suggests we can't do that (yet), right? We can however invite "an individual with a particular expertise to attend a meeting on an exceptional basis".

I believe it's up to chairs to decide who to be invited, so inviting all participants of WebApp WG individually could work and allowed... In charter we just say The meetings themselves are not open to public participation, however., but no limitation is set for number of individual invitations. Also we don't plan to have any call for consensus type discussion during planned call, we don't need to consider of voting right issue. (of course, since Guide for joint deliverables requires individual consensus per each group, we can and need to run CfC within DAS WG independently at some future point.)

anssiko commented 5 months ago

Thanks @himorin, @marcoscaceres has been invited. It might not be the perfect time for him to attend, which I apologize in advance.

To keep this working session productive I prefer to invite only people informed of this specification and its latest developments. Any other individuals interested and brought to our attention will be considered.

anssiko commented 4 months ago

Wide review has been completed. Thank you all! 🥳 🚀

This wide review round resulted in various positive developments summarized below:

Please follow the links in the first comment https://github.com/w3c/deviceorientation/issues/130#issue-2093963178 for details.

Also, please note publication to TR is currently blocked due to a workflow issue related to joint deliverables. We're working to fix it, meanwhile please refer to the ED for the latest: https://w3c.github.io/deviceorientation/