Meeting minutes
Review agenda and next meeting dates
Matt_King: Let's add an agenda topic for the recent discussion regarding automation and GitHub Actions
Matt_King: Any requests for other changes?
Matt_King: Hearing none, we'll stick with what we've got planned so far
Matt_King: Next Community Group Meeting: Thursday March 6
Matt_King: Next AT Driver Subgroup meeting: Monday March 10
Matt_King: I will be traveling on March 10, so I may not be able to attend that AT Driver Subgroup meeting
https://
Current status
Matt_King: There aren't any significant changes in the status of plans this week
Matt_King: IsaDC and I have started putting together a spreadsheet, and we will probably start including a link to that in the agenda soon
Matt_King: We know what plans we're going to work on for the month of March--we have one more change to go through (an issue with the disclosure navigation menu plan), and then we decided that we're going to focus on getting all the sliders done in the month of March
Matt_King: We're going to try to get through one slider each week
Matt_King: That's essentially the plan for March. The challenge is going to be to keep up with that pace on the testing side
Matt_King: We don't really have enough people to go that fast
Matt_King: I'm going to try to recruit more volunteers at CSUN
Matt_King: It's going to take some time, though. We'll see how long it takes to find more people and onboard more people
Matt_King: In the mean time, there will be no shortage of testing work!
IsaDC: Perhaps we could have a testing award
ChrisCuellar: Bocoup would be happy to shine a spotlight on volunteers here
Matt_King: that's an interesting idea!
Disclosure nav menu testing
github: w3c/
Matt_King: It looks like mmoss has started the work that needs to be done, here
Matt_King: Should we leave this issue open until all the conflicts are resolved?
IsaDC: Yes, I think so. If we close it now, we might lose track of any changes we have made and when we made those changes
Matt_King: Last week, we figured out that mmoss's setting in Safari needed to be changed
Matt_King: mmoss is running some tests again
IsaDC: Yes. Separately, Joe was getting silence and mmoss was getting the word region.
Matt_King: That's a separate issue. We'll need both of them present to address that
Matt_King: It will come up on the agenda next week when we get the new test in place
Radio group testing
Matt_King: Looking across all of the results that we have, I currently see quite a few conflicts
Matt_King: Focusing first on radio group with active descendant
Matt_King: It looked to me like that with JAWS, there is a lot of conflicts. It seems like IsaDC and hadi are getting different output from JAWS
Matt_King: Hadi isn't here, so I don't think we can debug that right now
Matt_King: IsaDC, has hadi responded to your inquiry, yet?
IsaDC: Not yet, but I think most of those conflicts come from the old data that we had. The data that the app populated for us when we re-added the test plan
Matt_King: So what's really required here is that hadi will have to re-run the tests
IsaDC: That's right. That's what I needed to do
Matt_King: So your output is essentially more current
Matt_King: We need to make sure that hadi is running JAWS 2025
IsaDC: There are some new good changes in VoiceOver results but there are also some concerning regressions
IsaDC: This is for macOS 15.3. Some of the results are different--some are positive, but others are not right
IsaDC: I have been focused on roving tab index
Matt_King: Seeing that Joe's status is the same as your status, I'm assuming that he hasn't made any progress on that, yet
IsaDC: He'll be testing more on Monday--he sent an e-mail to that effect
IsaDC: For NVDA, I finished with my test run
Matt_King: It looks like mmoss hasn't started, though
IsaDC: Can I ask Luke from PAC to run these tests?
Matt_King: This would be a good one since mmoss hasn't started and since mmoss has other work. We should have mmoss prioritize macOS for this and for disclosure
Matt_King: Change this one over to Luke
IsaDC: And I'll re-run the bot
IsaDC: We can't re-assign a test plan run from one human to another human
Matt_King: We talked about this feature once, but we decided not to implement it
Matt_King: I wonder what howard-e or jugglinmike thinks about how difficult it would be to implement re-assigning between humans
howard-e: Conceptually, I guess it's the same as re-assigning from the bot. Would we want to also preserve the history of that transfer?
Matt_King: What would happen if we did is that we would have an "incomplete" run by the first person assigned, and then a new run by the second person
howard-e: So the first person's run should continue to exist? In other words, are we creating a copy or doing a full reassignment?
Matt_King: I was thinking of a full reassignment
Matt_King: It would mean that any work done by the first person assigned would be attributed to the second person assigned
howard-e: Conceptually, it shouldn't be that heavy of a lift.
howard-e: I think we should still consider a use case where the original person wants to continue after-the-fact, though that may be a separate design discussion
Matt_King: Let's add that issue to the "general usability" project, and we can prioritize it separately
jugglinmike: Though from a process standpoint, EXTEND_LATER
Matt_King: Yeah, that makes sense. There would be a little bit of ambiguity. The new person will become responsible for the prior person's work
Matt_King: Okay, for the current situation, I suppose IsaDC will have to delete that test plan run (the one assigned to mmoss), create a new test plan run for the bot, and then re-assign that new test plan run to Luke
IsaDC: Got it
Automation cloud budget
jugglinmike: We've been trying to verify Github's policy for number of job runs when we run our automated tests in Github Actions
Specifically, we're concerned about their billing policy, which depends on whether or not the actions are run in a public or private repo. We've stayed within their limits so far and have never been billed. We want to make sure that we don't ever hit whatever the limit is in the future, which is ambiguous
We've been trying to nail down their policy for free and open-source software. I still haven't been able to get a clear answer. I reached out to Michael Fairchild to see if we can determine this together. Our latest thinking is that we could maybe perform some test. We suspect that there may be a 200 minute limit per month for macOS.
It's a 2000 minute limit for Windows but 200 minute for macOS.
The latest plan is to purposely exceed the limit on macOS.
We want to test this in a controlled setting where we don't risk running out of job time. Maybe we can run this test once at the end of the month, so we won't interrupt VO bot usage.
ChrisCuellar: Why don't we run this on someone's personal account to further de-risk the limit test?
Matt_King: Can we run this under the W3C org?
jugglinmike: I can imagine the policy being different for organization than for users
ChrisCuellar: Maybe we can start with users before testing organizations?
jugglinmike: That sounds good. I'll test on my Github user account first.
Matt_King: I don't want to be caught by any surprises here.
Are those limits in place if the repositories are not public?
jugglinmike: The policy is a lot clearer for private repositories. They have a quota for free minutes and beyond that you start getting billed, which all gets tracked.
Matt_King: This sounds like a plan to me.
Matt_King: Have a great afternoon everyone!