Update status of this document #142
Conversation
|
Note: @himorin we'll need to add new bikeshed-boilerplate files to recognize this as a joint publication. |
you just need to do the same thing as contact-picker
note, I realized that I need to update text related to Process dated version... |
index.bs
Outdated
| @@ -17,7 +17,10 @@ Abstract: This specification defines several new DOM events that provide informa | |||
| Boilerplate: omit issues-index, omit conformance, repository-issue-tracking no | |||
| Include MDN Panels: if possible | |||
| Issue Tracking: DeviceOrientation Event Specification Issues Repository https://github.com/w3c/deviceorientation/issues | |||
| Status Text: <p>This specification was initially published as a <a href="https://www.w3.org/TR/2016/CR-orientation-event-20160818/">Candidate Recommendation</a> in August 2016 and was <a href="https://www.w3.org/TR/2017/NOTE-orientation-event-20170530/">retired</a> in 2017 due to the Geolocation Working Group closure. In 2019 Devices and Sensors Working Group adopted this specification and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the <a href="#changes">Changes</a> section. These changes aligned the specification with widely available implementations. In 2024 this specification became a joint deliverable between the Devices and Sensors Working Group and WebApps Working Group.</p><p>This document is maintained and updated at any time. Further changes are expected to be reflected in revised Candidate Recommendation Drafts and Snaphots as deemed appropriate to align the specification with existing implementations. Before requesting transition to Proposed Recommendation, the Working Groups will seek to demonstrate there is at least two independent, interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other.</p> | |||
There was a problem hiding this comment.
Can we move the first paragraph to a "Change log" or "History" section instead?
The second section just states stuff that's already part of the W3C Process, no? I don't think it's necessary to restate what's part of the W3C Process or the Charter.
For example, the spec is already going to link to:
https://www.w3.org/standards/types/#x4-2-2-candidate-recommendation-snapshot
There was a problem hiding this comment.
The first section is a summary for busy people and SOTD is an appropriate place for this text. It may feel superfluous to you because you have tracked this specification closely. You are not the target audience :-) The Changes section complements this high-level summary and provides more details for readers such as yourself Marcos. Please review that section instead and let us know if you suggest any changes there.
It is important to document the success criteria here for this joint deliverable to avoid conflicts between the success criteria sections of the charters. Please let us know if you have suggestions for concrete changes to this text, otherwise we'll keep it as is. In particular we want to hear if there are any "at risk" features to document here.
Hearing no further concerns, I plan to merge this PR to prepare for the upcoming publication. Thank you for your support in making that happen.
There was a problem hiding this comment.
Wait! hold up. You're literally dismissing my feedback based on who I am?
I'm literally an implementer of the specification and representing people who implement the specification. If the specification is not written for me as the intended audience, there is something very wrong here.
There was a problem hiding this comment.
No. I'm saying the status text in SOTD is primarily for other than implementers. People who want to get the big picture quickly, look at many things. There are many audiences. Your feedback has been considered.
I still need your help to review and improve the Changes section. This is supposed to be helpful for implementers. The next level down is the commit log, but it has some noise. We cannot rewrite that.
We appreciate your implementation experience very much Marcos.
There was a problem hiding this comment.
I'm ambivalent on whether the full history in the first paragraph is worth including in the SOTD section or could be put in a separate "History" section. The link to the "Changes" section at a minimum assists new readers.
As discussed at TPAC the joint deliverables need to operate under the requirements of both working groups. It looks like the boilerplate above mentions both groups' patent policies but the lone "This document was produced by..." line only mentions one group. Similar to the patent policy text, I think a section linking to the "Success criteria" sections of both working group charters would be more precise and helpful than trying to summarize the intersection here.
There was a problem hiding this comment.
I've build for test and pushed at: https://das.w3c.himor.in/CR-orientation-event-20240320.html (w/ 4 lines below added)
(note, no companion files - images or xhtml is placed there)
Please add this line
Implementation Report: https://wpt.fyi/results/orientation-event?label=master&l
abel=experimental&aligned
and if anyone interested to include test links, use this line
WPT Path Prefix: orientation-event
I'll add Date and Deadline at the point of publication.
|
note, ED boilerplate does not have joint deliverable line for document has produced by. |
index.bs
Outdated
| @@ -17,7 +17,10 @@ Abstract: This specification defines several new DOM events that provide informa | |||
| Boilerplate: omit issues-index, omit conformance, repository-issue-tracking no | |||
| Include MDN Panels: if possible | |||
| Issue Tracking: DeviceOrientation Event Specification Issues Repository https://github.com/w3c/deviceorientation/issues | |||
| Status Text: <p>This specification was initially published as a <a href="https://www.w3.org/TR/2016/CR-orientation-event-20160818/">Candidate Recommendation</a> in August 2016 and was <a href="https://www.w3.org/TR/2017/NOTE-orientation-event-20170530/">retired</a> in 2017 due to the Geolocation Working Group closure. In 2019 Devices and Sensors Working Group adopted this specification and during 2019-2024 made substantial interoperability, test automation, privacy and editorial improvements as outlined in the <a href="#changes">Changes</a> section. These changes aligned the specification with widely available implementations. In 2024 this specification became a joint deliverable between the Devices and Sensors Working Group and WebApps Working Group.</p><p>This document is maintained and updated at any time. Further changes are expected to be reflected in revised Candidate Recommendation Drafts and Snaphots as deemed appropriate to align the specification with existing implementations. Before requesting transition to Proposed Recommendation, the Working Groups will seek to demonstrate there is at least two independent, interoperable implementations of every feature defined in the specification, where interoperability can be verified by passing open test suites, and two or more implementations interoperating with each other.</p> | |||
There was a problem hiding this comment.
I'm ambivalent on whether the full history in the first paragraph is worth including in the SOTD section or could be put in a separate "History" section. The link to the "Changes" section at a minimum assists new readers.
As discussed at TPAC the joint deliverables need to operate under the requirements of both working groups. It looks like the boilerplate above mentions both groups' patent policies but the lone "This document was produced by..." line only mentions one group. Similar to the patent policy text, I think a section linking to the "Success criteria" sections of both working group charters would be more precise and helpful than trying to summarize the intersection here.
For CR publication purposes.
See exclude-if directives in includes: https://github.com/speced/bikeshed-boilerplate/tree/main/boilerplate/dap
Use a version defined in the Bikeshed include instead: https://github.com/speced/bikeshed-boilerplate/blob/main/boilerplate/dap/status-CR.include To produce a test build: bikeshed spec --md-status=CR --md-deadline=yyyy-mm-dd Where yyyy-mm-dd is the earliest CR exit.
|
Thanks for your review folks. I pushed an update to address the remaining comments. TAG folks appreciated the history lesson and the high-level summary, so I recommend we keep it. PTAL @reillyeon @marcoscaceres @himorin I noticed @himorin's build pulled the PR entrance / CR exit criteria from the bikeshed boilerplate file (status-CR.include) so I removed the similar text from this PR to not duplicate it. There's still a minor imperfection in that it says "Working Group", while it should say "Working Groups" or "Working Group(s)". I'll let @himorin handle those tweaks to the bikeshed boilerplate files. @himorin this PR should be good to merge. Please verify it builds with your CR config. Let us know if you spot any other bugs. |
Ahh,, yes. Also do we want to include mail lists of both WebApps and DAS into feedback section? (I'm not sure what we can do on this front, although.. - We could update SoTD part to include both, since it's just a text part of boilerplate)
please check updated build also. |
SHA: 1d42f14 Reason: push, by anssiko Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
|
@himorin these text macros: text macro: JOINT yes Seem to cause a "deliverer-changed" error in echidna, see https://labs.w3.org/echidna/api/status?id=5094fa41-b80c-460a-8a46-c6f2c2c8db72 and look into a fix. |
|
@anssiko this is not an error from bikeshed, but is from a change on spec metadata - single WG publication to joint publication. |
|
@himorin thanks for debugging this. I followed up on the CfC topic via mail. |
For CR publication purposes.
Preview | Diff