-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[wg/browser-tools-testing] Browser Tools and Testing WG (WebDriver) rechartering #438
Comments
no comments or requests from APA. |
(pinging @w3c/w3c-group-52497-chairs in case this is of interest) |
|
Thanks for catching that — fixed now
OK — added those
I replaced those because the use of “should” throughout the charter template seems weird to me. It seems like the core purpose of the charter is for us to define normative “must” requirements for the group (the group will do these things) — not general “nice to have if you feel like doing them” things (the group should do these things). But I don’t feel particularly strongly about it at all. I’m very happy to change them all back to “should”. Shall I go ahead and do that? |
no comment or request from i18n |
No comment from PING |
@ruoxiran @matatk @JaninaSajka AT Driver was added to the charter: AT Driver defines a protocol for introspection and remote control of assistive technology (AT) such as screen readers, using a bidirectional communication channel. If this is a concern for APA, please let know. Keep in mind that this would only be enabled in testing environment. |
thanks, PLH, we will review it this week. |
Deliverables are missing Draft state, Expected completion, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter. (see charter template and webapps charter example). Is there WHATWG coordination needed related to Test Utils? Shouldn't we list WPT in coordination as well? In charter history, "AT Driver deliverable added." is listed as added in 2021. But isn't it 2024? |
Sorry for the delay, we need one more week to follow up with AT vendors. See minutes at: https://www.w3.org/2024/03/06-apa-minutes.html#t04 |
Does the Group want to produce a Recommendation or produce/update Candidate Recommendation Snapshots (Living-REC vs Living-CR)? |
Yes — added both
Thanks for catching that — fixed
Will talk to the chair, and then update the charter based on that discussion |
The current charter has a mix of "living standard" at the top and "going to rec" at the bottom. |
Thanks for catching that — I’ve now removed the “In order to advance to Proposed Recommendation” paragraph from the Success Criteria section. Lemme know if I missed anything else. |
For the record here, the answer to that is, the group does not intend to produce any RECs but instead plans to publish CR snapshots (I was reminded yesterday that the group had already made a decision about that during a TPAC discussion quite a while ago) |
So now that we have confirmation that the group in fact does not intend to produce Recommendation-track deliverables, do we need to include the “Draft state, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter” info in the charter? I ask that because in the Process doc at https://www.w3.org/2023/Process-20231103/#WGCharter I see:
But if the group only plans to take their deliverables to CR Snapshot, doesn’t that mean the deliverables are not Recommendation Track? It’s not completely clear to me at least that the Process document intends for CR Snapshots to be considered Recommendation-Track deliverables for the purposes of that requirement to include the “Draft state, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter” info in charters. At https://www.w3.org/2023/Process-20231103/#w3c-recommendation-track I see this:
…with the implication (to me at least) that for a deliverable to be considered a Recommendation-Track deliverable, it needs to be intended to eventually complete all those steps — not just the first 3. And the intro paragraph to the https://www.w3.org/2023/Process-20231103/#rec-track section says, “These technical reports undergo cycles of revision and review as they advance towards W3C Recommendation status” — but CR Snapshots are explicitly not intended to advance toward W3C Recommendation status. Given all that, it would seem like the “must include “Draft state, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter” charter requirement isn’t intended to apply to CR-Snapshot-track deliverables. |
You still need to include those information. It's relevant for the patent policy.
I guess we could replace /consists/contains/ to make it clearer that REC-track does not systematically means that the document will reach the REC maturity stage. cc @frivoal just in case. |
Well they aren't Notes and they are not Registries. So they are Rec-track (consider the name historical, standards-track would be better) |
This makes it clear that a document that uses the various publication types and transitions of the REC-track is indeed on the REC-track, even if it isn't planning to go all the way to the end. Some groups for instance have a declared intention of only going as far as CR. That doesn't make the documents on the "CR track", as there's no such thing. See w3c/strategy#438 (comment)
APA WG is happy for this to proceed. We are still engaging with external community stakeholders, but we are mindful that we did not spot any showstoppers ourselves, and we will have the opportunity to provide feedback on the AT Driver spec as it progresses (and we'll help anyone in the wider accessibility community who wants to, to provide feedback as it comes in). Thanks for your patience! |
This makes it clear that a document that uses the various publication types and transitions of the REC-track is indeed a REC-track document, even if it isn't planning to go all the way to the end. Some groups for instance have a declared intention of only going as far as CR. That doesn't make the documents on the "CR track", as there's no such thing. See w3c/strategy#438 (comment)
From a security perspective, they should include in the Success Criteria a precise structure of the "Security Considerations" Section, which has already been identified any way in the different issues of the deliverables.
This section's structure is indicated by the Security and Privacy Questionnaire and the referenced RFC3552—Guidelines for Writing RFC Text on Security Considerations. In this specific case, it should be interesting to consider potential abuse cases of the APIs/Driver both from user perspectives and use by bots for scraping. |
New charter proposal, reviewers please take note.
Charter Review
Charter: https://w3c.github.io/charter-drafts/2024/btt-wg.html
What kind of charter is this?
For responses or questions about this draft charter, please add comments to this issue.
The text was updated successfully, but these errors were encountered: