Meeting minutes
ACT-R status check
JYM: Contacted AGWG subgroup, haven't had an answer
Wilco: Liaison organizing
Dan: Worked on label in name PR, 275
Daniel: Reviewed ARIA / ACT stuff that's piling up
Giacomo: We worked on the page title rule, which aligns with the ACT rule we have. Some interesting questions for the future
Kathy: Heard back from subgroup, waiting for an invite to the meeting
… About the AG meeting, did we do the exercise
Helen: Yes, wilco said he trusts me to do everything
… lot of discussion in AGWG
… I reached out to both subgroups, meeting on Monday. I had lots of questions. There have been a lot of emails
… One person has been pushing back on using ACT. Meeting with JY about this tomorrow
… The exercise got a derailed. We got stuck on a definition
Wilco: Yes
<giacomo-petri> /me +1 Helen
Wilco: Wasn't recorded. I don't think that would have been useful anyway
Helen: The contention point was that a test doesn't cover the whole requirement, how do you break it down, why test something that doesn't cover everything?
Godwin: Got some catching up to do
Shunguo: Attended subgroup meeting yesterday. Was a tough 30 mins about why we are using ACT rules, but it seemed to settle down as it was decided already to use ACT rules for WCAG 3.
… I suggested the group look at existing rules to see if things were covered already, and if there are additions needed.
… The expectations seems a little high, they seem to look at the rule to do everything
… Things are getting started I can see
Daniel: There was a comment on AGWG that rules could be framed as testing techniques
JYM: I suggest we leave the conversation about liaisons for the TF call next week
<Zakim> Daniel, you wanted to say framing rules as testing techniques could help remediate some of the concerns
Which projects should the CG work on?
JYM: We wanted to switch to a project-based approach, rather than having 50 open PRs that aren't moving. The question is, which one(s) should we work on, and who?
… I would suggest that the project could be to finish label in name rewrite?
Wilco: I also think the all rules page redesign is one, and target size
JYM: I think label in name has momentum
Daniel: +1 for the design page
… we should take a look at those last issues and merge as soon as those are done
… Another project is to bring rules that are ready to AGWG
<Helen> act-rules/
Helen: Since we have Dan her, there is a PR waiting for code examples
… that might also be a good example for AG
JYM: We have 5 project proposals, the question is who leads a project
Dan: Yes I can lead
JYM: I can help review
… one project, do we have another?
Godwin: I can lead on the rebuild of the all rules page
Wilco: I'll help review that
Remi: Me too
Kathy: Another project suggestion. We have to update the video transcript rules showing the transcript doesn't need to be visible. There are some related rules that need to be updated as well
JYM: Great, we have six project ideas, that'll keep us going for a while
Shunguo: I've got a lot to do as a liaison at the moment, but I can help with some reviews
https://
Add merge and publication policy – act-rules/act-rules.github.io#2363
Wilco: The problem is that there's a potential risk that a change may get merged and published to the W3C site without enough time for testing tools to update their implementations
… Timing is inconsistent, we don't have moratoria, release candidates, etc
… The proposal indicates that PRs cannot be merged on Friday, Saturday or Sunday, so that if the tool runs on Friday or over the weekend it ensure it can get the most recent results
Jean-Yves: From an implementer's perspective that means we'll have to do our updates during the weekends or on Friday
Remi: 2 questions. Do implementers update their data before changes are published? And if so, what do they use?
Wilco: We pull them directly from github, the json file is updated every week
Remi: Main branch?
Wilco: Yes
Jean-Yves: I pick them from the json file on the W3C website, quite certainly I can change my approach
Remi: You'r trying to give implementers sufficient time. How much time? 2-3 days or more?
Wilco: An hour is probably enough
Jean-Yves: Depends on the changes. Mostly it's just about grabbing the test cases and running them on our side
… More involve changes imply updating the tools, which may mean weeks, though
Kathy: If there's another manual methodology that needs to update their results that will take more than half an hour
giacomo-petri: For automation there is no issue. For the rest (which may require manual activity) it may take longer
… It may be related to the amount of time we define for merging the pull request
… We have two weeks for the Call for Review, so that may be sufficient, but that's before merging
Jean-Yves: We do have the Call for Review period (2-week) for significant changes, but during the call for review periods the new updated test cases are not in the same bucket, because the PR is not merged yet
… And if we update early that could be problematic
Wilco: Is this a real problem? Are people having issues because of this?
Jean-Yves: I'm OK with the current situation, but I see how it could be an issue
Wilco: Giacomo, do you need more than a day?
giacomo-petri: We are in the same situation as Jean-Yves
Wilco: If you need an extension on this period you could request one, same goes for Call for Review
Kathy: Do implementers get any notification when their consistency changes?
Jean-Yves: No, it's up to us to build such a system if we think we want this
Jean-Yves: It'd be fairly easy
Kathy: Maybe for a future consideration, mainly for manual implementations
Jean-Yves: For semi automated or manual the decision would have to be made on whether we update the test cases, even if it's just for editorial changes
giacomo-petri: Do we have a json preproduction environment? Can we build something like a preproduction?
Jean-Yves: We do have the preview, but if you have two pRs running at the same time you'll have to grab those as well
Remi: The easiest way might be for implementers to check out a specific branch where the test cases would be
… When we merge the test cases from main to publication, that doesn't get published automatically, there is an extra manual step
… But in the meantime you can get the publication branch as the "new version" of the test cases that will be published to the WAI website
… When there's new stuff to be published, we open a pr to publication, WAI review, and then I merge
… After that PR is merged, you could deide to stop merging to main from the act-rules.github.io, especially for things that may affect implementations
Jean-Yves: If we do not know when that time frame starts, we cannot decide when to start these processes
… We could have the same thing, like merging a specific day and the publication will happen some days after for implementers to be able to run their scripts
Remi: Do you need a given day or just to know when the delay starts?
Jean-Yves: It'd be easier to run our weekly processes if it's a specific day, otherwise we'd need something else to trigger the workflows
Remi: In the option I introduced, the start would be when we merge from main to publication. That's where you'd stop merging updates coming from the act-rules.github.io to ensure nothing changes
giacomo-petri: Especially for the manual or semi-automated, why don't we freeze a preproduction for one week?
Wilco: I think that's a reasonable idea, but it doesn't appear to be solving any problem
… I suggest we propose a day. W3C already cuts off on Mondays, when the PR is open
Jean-Yves: Agree. I'm hearing this is not a huge problem
… I'd suggest we go with current proposal and see how things are going. IF one day we do find there are problems, we can continue to ellaborate on how to solve them
Shunguo: Good idea, but we have a reality challenges. If we have to release something, what would you include? Some of the items can take a long time to review
… We really don't have a hard release deadline
Jean-Yves: Does anybody thing that the current proposal is going to make things worse? I'd suggest going with this an revisit later if more problems arise.
Shunguo: We can try to adjust
Remi: There are open suggestions in the PR. It might be good to address them
RESOLUTION: Accept Wilco's proposal addressing the existing suggestions in the PR