[wg/browser-tools-testing] Browser Tools and Testing WG (WebDriver) rechartering

[sideshowbarker]

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?

• [X] Existing WG recharter; diff from previous charter

For responses or questions about this draft charter, please add comments to this issue.

[ruoxiran]

no comments or requests from APA.

[plehegar]

(pinging @w3c/w3c-group-52497-chairs in case this is of interest)

[himorin]

• two section numbers of the Process in "About this charter" section seem old one
• history table needs to have recent extension and this charter?
• not sure why (almost?) every 'should' are replaced with 'will' in success criteria section, but for me one for 'security and privacy implications' seems to be 'should' per recent requests around...

[sideshowbarker]

• two section numbers of the Process in "About this charter" section seem old one

Thanks for catching that — fixed now

• history table needs to have recent extension and this charter?

OK — added those

• not sure why (almost?) every 'should' are replaced with 'will' in success criteria section, but for me one for 'security and privacy implications' seems to be 'should' per recent requests around...

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?

[himorin]

no comment or request from i18n

[plehegar]

Advance notice: https://lists.w3.org/Archives/Member/w3c-ac-members/2023OctDec/0037.html

[plehegar]

No comment from PING

[plehegar]

@ruoxiran @matatk @JaninaSajka

AT Driver was added to the charter: [[ AT Driver

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.

[ruoxiran]

@ruoxiran @matatk @JaninaSajka

AT Driver was added to the charter: [[ AT Driver

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.

[plehegar]

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?

[ruoxiran]

@ruoxiran @matatk @JaninaSajka AT Driver was added to the charter: [[ AT Driver 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.

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

[plehegar]

Does the Group want to produce a Recommendation or produce/update Candidate Recommendation Snapshots (Living-REC vs Living-CR)?

[sideshowbarker]

Is there WHATWG coordination needed related to Test Utils?

Shouldn't we list WPT in coordination as well?

Yes — added both

In charter history, "AT Driver deliverable added." is listed as added in 2021. But isn't it 2024?

Thanks for catching that — fixed

Does the Group want to produce a Recommendation or produce/update Candidate Recommendation Snapshots (Living-REC vs Living-CR)?

Deliverables are missing Draft state, Expected completion, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter. (see charter template and webapps charter example).

Will talk to the chair, and then update the charter based on that discussion

[svgeesus]

The current charter has a mix of "living standard" at the top and "going to rec" at the bottom.

[sideshowbarker]

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.

[sideshowbarker]

Does the Group want to produce a Recommendation or produce/update Candidate Recommendation Snapshots (Living-REC vs Living-CR)?

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)

[sideshowbarker]

Deliverables are missing Draft state, Expected completion, Adopted Draft, Exclusion Draft, and Exclusion Draft Charter. (see charter template and webapps charter example).

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:

For every Recommendation Track deliverable that continues work on technical report published under any other Charter (including a predecessor group of the same name), for which there is at least an existing First Public Working Draft the description of that deliverable in the proposed charter of the adopting Working Group must provide the following information:

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:

In summary, the W3C Recommendation Track consists of:

1. Publication of the First Public Working Draft.
2. Publication of zero or more revised Working Drafts.
3. Publication of one or more Candidate Recommendations.
4. Publication of a Proposed Recommendation.
5. Publication as a W3C Recommendation.

…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.

[plehegar]

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?

You still need to include those information. It's relevant for the patent policy.

In summary, the W3C Recommendation Track consists of:

1. Publication of the First Public Working Draft.
2. Publication of zero or more revised Working Drafts.
3. Publication of one or more Candidate Recommendations.
4. Publication of a Proposed Recommendation.
5. Publication as a W3C Recommendation.

…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.

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.

[svgeesus]

But if the group only plans to take their deliverables to CR Snapshot, doesn’t that mean the deliverables are not Recommendation Track?

Well they aren't Notes and they are not Registries. So they are Rec-track (consider the name historical, standards-track would be better)

[matatk]

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!

cc @ruoxiran @JaninaSajka

[simoneonofri]

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.

The security considerations section must include a comprehensive threat model with threats, attacks, mitigations, and residual risks.

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.