Meeting minutes
<Matt_King> https://
<Matt_King> https://
<rob_fentress> + present
Workstream planning
mk: our vendor contracts are still pending, and should happen really soon.
mk: should them finalized by Feb 8
mk: we have a tentative kickoff plan for the different work streams
seth: in the kickoffs we will do meta planning such as figuring out cadence, priorities, stakeholders, roadmap, etc
mk: our tentative date to kick off the app dev workstream is 2/11 during this time
mk: and we would have a 90min agenda instead of 60
mk: for automation, we will also need to find a 90min window with Michael to kick off that work stream
mk: we will offline the coordination of that meeting time
mk: and we will publicly share that time so that others can join
mk: 2/16, we will be kicking off a workstream for the authoring practices at 11 pacific
mk: for testing writing, I don't know that we need a formal kickoff. We do want to prioritize the backlog.
mk: we should also discuss the attribute testing from pattern testing at that time
James: on 2/11, this will be a 90min call. Will the full 90 minutes be for planning?
mk: yes, the entire meeting will be for planning
Working mode updates
mk: issue 375, I just today added another comment with some proposals.
https://
mk: I'd like to discuss those proposals
mk: this is about streamlining the process
mk: running a test is a really good way is to ensure that the test is accurate
mk: and we have the ability to update a test without affecting other tests
mk: that gives us a potentially much faster way to work
<Matt_King> Community group members run tests to achieve two goals: 1) Ensure the tests are sufficiently accurate and complete to publish as draft expectations that
<Matt_King> are ready for stakeholder review; 2) Generate draft test data that is ready for stakeholder review. Editors may publish draft tests and test data at their
<Matt_King> discretion after at least two community group members have generated identical results. Editors are responsible for ensuring the quality and completeness
<Matt_King> of reviews. Reviewers are responsible for raising issues against tests where they do not meet community group quality guidelines.
mk: what do people think of the language that I put in here?
hadi: can you read your proposal?
mf: (reads the comment in the issue)
mf: do you have an example of what a quality guideline would be?
mk: how assertions and instructions are worded in a consistent way, that commands are appropriate for the assertions, etc.
mk: maybe that doesn't need to be a quality guideline, or maybe it does. What do you think, James?
James: I think its worth writing something down. We learned a lot during this process. What would be ideal is if we provide a wiki page with some tips and lessons learned. Then, depending on how the CG group feel about that, we can direct volunteers to that page.
James: The risk is that there are some differences between tests. How they are laid out, how they are worded, etc.
James: Now the Dialog Modal pattern can be used as a reference
mk: we don't have a lot of people that can write tests, if someone like Microsoft wants to contribute tests for Narrator, or Google wants to contribute tests for TalkBack, that wiki page could be helpful
James: that wiki page could also be helpful for people running tests to point out inconsistencies
mk: michael, I wanted your feedback on this too
Michael: I'm still thinking through it, but I think this is a good approach and we can revisit again if we need to
Sina: there is an opportunity for separate pages. One would be test writing procedures. The other would be expectations around testers themselves.
mk: go ahead and experiment with that idea.
jongund: from my experience with APG, there needs to be assignment of reviewers. as new tests are created, we need to assign reviewers.
jongund: otherwise the test authors may have to wait a long time to get feedback
mk: everyone should review this issue and add suggestions / concerns so that we can update the working mode
New test development planning
mk: there is a subset of open issues that are related to the ARIA-AT app
mk: and some are related to automation
mk: we do have a tag for each of those, to say that an issue is for the app or automation
mk: test-runner is the label
James: should I go through and make sure that labels are accurate?
mk: yes, make sure that test-runner is used where appropriate
mk: I think I should add a label for at automation
mk: we have a number of open PRs. Does order matter?
mk: I did see that there is one with merge conflicts
James: there are 3 that I have conflcits
Sina: can we merge and accept a few of them?
mk: I'll also file an issue about making the script that runs smarter
(sorry, that was James)
Sina: should we do the earlier ones first, James?
mk: yes
Sina: do you feel confident resolving the merge conflicts?
James: no, not all of them
Seth: we might be able to help resolve the merge conflicts, but I'm not sure who would do that. An issue would be best.
mk: James, what's the best order to merge these?
James: I don't have a sense for the best order
Sina: is it a good plan to have a couple of these merged in by next week?
mk: yes
mk: is there anyone on the call that can help review?
Jon: I can help Hadi if he needs help
Rob: could I maybe sit on the thing with Hadi?
Jon: We could do the menu button