Meeting minutes
Recent and upcoming app changes
<Matt_King> Rich: shipped test plan version updater. Is now in prod as of March 30.
<Matt_King> no reported issues as of today.
<Matt_King> Current work underway is for capturing browser and AT versions.
<Matt_King> May 17 is target date for sandbox and reviews starting on 19th
<Matt_King> prod launch on May 23
<Matt_King> Didn't find a way to deliver in phases
<Matt_King> so it will all come at once
<Matt_King> mk: this is blocker for more testing. How can we continue testing in the meantime.
<Matt_King> Seth: perhaps we can find a way to collect the data offline and then backfill it.
Screen Reader Developer Engagement
Matt King: we're meeting with screen reader vendors to kick off the effort in the next 2 weeks (JAWS/Vispero, Apple) and we'll have the first 8 plans ready for the community group by April 26 and then ready for screen reader vendors in May
Matt_King: plan is to have the reports in a state where screen reader vendors can provide feedback with the tools that we have
Matt_King: since these are the least contentious 8 plans, we think we might be able to avoid handling a more complex review / reconciliation process
Screen Reader Dev Journey
Screen Reader Developer User Journey
<s3ththompson> https://
Matt_King: I would like to make this week about the Developer User Journey and next week the Administrator User Journey
<s3ththompson> https://
s3ththompson: the link goes to the wiki page we have created for these journeys
s3ththompson: 3 scenarios listed and all related to reviewing candidate test plans
Matt_King: I am thinking that in terms of planning app changes I was imaging a Job to be Done.
s3ththompson: I believe we can massage these into that form
Matt_King: A job to be done sounds like "I want to indicate that I have reviewed it". I wonder if we want something similar to GH review.
james: this user journey implies they will file an issue and I don't believe that is the case
Matt_King: you need to know which ones at the test level and not at the test plan level
Matt_King: not at the assertion level
Matt_King: reviewing at a test would be reasonable
Matt_King: 1. Provide Approval 2. Request Changes 3. Have Questions - we want to make it easy to track these
s3ththompson: I agree and can share those with Isaac
Matt_King: we want to know where the bugs are raised and we would capture that information
Matt_King: The trigger to rerun automation should be the release of a new version
Matt_King: success is measured by how the SR developers change and react to it.
s3ththompson: what are the requirements around the process of reading these reports. The reports page is a better summary of information for someone coming new to the page to view it v. the runner.
Matt_King: I think the reports format is pretty good but I imagine something similar to the queue so they can see a list in their queue.
Matt_King: I think it will have to look something like a to-do list
s3ththompson: we have not talked about authentication, we would obviously want this to be a privileged role
Matt_King: we can assume all SR vendors will have GH accounts
Matt_King: these approvals are more of a project tracking as opposed to a formal approval. Would want to be careful on how we cast that.
Matt_King: there will be some political sensitivity as the project gains public credibility. how demanding we can be.
s3ththompson: I will revise this on the issue and I believe Isaac will be amenable to this. Then process to convert these to a set of requirements.
Matt_King: I think we might have to have a longer workshop.