Meeting minutes
New Issue Triage
jamesn: #1870
… no new issues
… need to assign?
spectranaut_: nope
New PR Triage
jamesn: #1872
spectranaut_: will discuss later
jamesn: #188
jcraig: I think related issue is merged
… two more followed it
… need to merge #187 first
jamesn: we’ve got enough reviewers
jamesn: #1871
spectranaut_: we talked about this last week
pkra: on hold
Deep Dive planning
jamesn: any deep dive suggestions for next week?
jcraig: I’m out next week
jamesn: there was something we’d planned for early March?
jcraig: yes, 2 weeks from today, but I don’t see it on my calendar
… it‘s the minimum role topic
spectranaut_: 2/23?
jamesn: 2/23 is for aria-actions
spectranaut_: we’ll do minimum role on 3/2
cyns: for Aaron, morning will be better
jamesn: ok, 3/2, but nothing for next week
jamesn: decision: minimum role on 3/2
Explain how values are obtained
jamesn: we discussed *which* spec to put this in and chose accname
… anyone have issues with it being in accname?
jcraig: name, description, and value seem reasonable in accname
jamesn: basically good for text-y things
chlane: this is actually an accname change, then? won’t be core-aam?
jamesn: core-aam will probably need to reference it
chlane: we need to talk to BGaraventa about it
melsumner: I just spoke with BGaraventa last night and can take assignment of this issue
… and can either work on it or bring back a resolution
Does the "Presentational Roles Conflict Resolution" always apply?
pkra: I agenda'd this since it seemed to slip through the cracks, but doesn’t need to be a big item
jamesn: button might be an outlier on some of these things
… certainly Chrome and some other user agents have changed and ignore the fact that button has an implicit presentation role
… so that could be a reason behind it
… if we are going to have this test, we should probably do something where the children presentational property of something is more respected. Perhaps img?
melsumner: I’d like to work on this one
jamesn: great, first, get some examples that don’t use button
… if no one is supporting its implicit role, why do we have it in the spec?
jcraig: I think I’m getting close to having web driver tests working, and this would be a great example of where we could write an automated test to see how browsers perform
… I can run web driver tests already, there are basic tests for label and role
… haven’t started on accname computation yet because there was suggestion that it’d be easier long-term to set up some infrastructure and additional test driver methods that don’t force every author to use web driver to test
… infrastructure to make tests easier to write
jamesn: would you like to work with melsumner to develop tests for this?
jcraig: yes, can help set up repo
… there’s a whole project called Interop 2023 Investigation
jamesn: I’d like to see that
spectranaut_: me too
… are there regular meetings?
jcraig: not yet, it’s all been in GitHub
<jcraig> web-platform-tests/
jcraig: linked to accname #174 and then there are a bunch of cross-references
Readme should document expectations of for New PR template and New Issue template (order, optionality, etc.)
pkra: should we do a deep dive on the last topic?
jcraig: sure, would love to. It’s early stages still, but once we get first few commits up & running in WPT with results, that’ll be a good time for a deep dive
… then others in the group could start writing tests
jamesn: would that before F2F?
jcraig: would be good to cover at F2F; in-person is better
… we can troubleshoot Python together :-)
1.3 blocking issues agendabot]
Readme should document expectations of for New PR template and New Issue template (order, optionality, etc.)
spectranaut_: this was an issue from jcraig about the PR template that we started to use
… that there should be more information about the order tasks should be done for people opening new PRs
… there is a process doc that I started after the last F2F at TPAC
… I edited it a little with jcraig’s suggestions
<Jem> https://
spectranaut_: structured some of the information
… would be great to get people to review
… I also updated the Normative Change Checklist to give it a little more clarity
jcraig: this is a good time to talk about it bullet-by-bullet
spectranaut_: Consensus is the first important step
… this happens in an ad hoc way and we don’t always record our decisions
… sometimes in minutes
… but in general, we only merge things where there were no objections
jcraig: the definition of “has been discussed”...
… is that verbally in a meeting? Or does a thread in GitHub suffice?
spectranaut_: we could outline that more, a lot of times PRs have been opened _before_ there’s consensus as a means of getting to it
<Jem> AG is do voting for the change and create the "resolution" statement.
jamesn: we can’t quantify how much discussion is needed before merging in concrete terms
jcraig: how about “the ARIA WG” instead of “a working group”
spectranaut_: good point, should be more specific
jamesn: don’t think we’ve ever merged a PR without any discussion
MattKing: is it sufficient, though? To say “it’s been discussed in a meeting”?
jamesn: this is only the first step, followed by a review process, and several others
MattKing: oh, I see
… if a normative change is in the works, it’s important to identify that so the timeline/urgency will be clear to all members
jamesn: since this is 1 of 6 steps, maybe we should run through the rest and make sure that concern is addressed in the whole process
… we don’t want to go back to a process that relies too heavily on email
spectranaut_: I appreciate that, and we can make this step clearer. We can leave PRs in draft as a signal that there’s not consensus
MattKing: yes, a stronger meaning for draft vs. non-draft — that’s a good idea
spectranaut_: we do have a lot of open PRs right now; maybe some of them should be in draft
… moving on to step 2: Review
… 3 approving reviews for a normative change
… added a bullet: the review should be based on the text & meaning of the change, not on whether the checklist has been fulfilled
MattKing: one thing we could do here is address specific significant stakeholders
… if we could identify those people while the PR is in the draft stage, then by the time we get to review, they’ll be prepared
jamesn: we should add something like “you can always add yourself as a reviewer”
jcraig: and the PR owner should also recommend specific reviewers
Matt_King: are there people outside the group who may not be able to add themselves?
… or even _be_ added?
jamesn: Jamie had been the hard one, but he’s in the group now
spectranaut_: I think we basically do already have the process you’re describing
jamesn: as chairs, we always try to involve reviewers we know would care
<Zakim> jcraig, you wanted to suggest something like the CSSWG's discussion bot ("this issue was discussed in [link to minutes]") would be helpful
jcraig: sometimes we’ll ask for 4 reviewers if there are API-specific changes
<Jem> This is a great process for the woarking group. I am so glad to see this effort.
<jamesn> fyi CSSbot issue - dbaron/
jcraig: in step 3, Test, we should add that “if the change is testable, tests should be written” _before_ merge
spectranaut_: yes, agreed, happy to make that change
spectranaut_: except for validators, norms for tests are a bit in flux — so for now, good to just create an issue in the ARIA repo describing the tests that need to be written
jamesn: we do occasionally have a PR with a bunch of reviewers, and we’ll accept them even when not everyone has approved. Do we need a process to be able to ignore some reviewers?
spectranaut_: need a distinction between mandatory and optional reviewers?
jcraig: some GitHub repos are very strict about that and require a ~3-day review period
<melsumner> I think it would be super useful for our group to have a time limit on reviews, even if it's pretty long. Sometimes it feels like an issue can sit for so long that we all forget what the original driving purpose was.
Matt_King: we do need to be careful. If it’s a single person who said they wanted to review but there’s some life event keeping them from reviewing, we should at least reach out
<pkra> "more optional reviewers" => "additional reviewers" ?
Matt_King: maybe explicitly get consent from them to dismiss their review
… maybe at the point a PR goes from draft to ready-for-review, we start a ~30-day timer
jcraig: I don‘t think we should minute reaching out to absent reviewers, it could resemble public shaming
… we should rely on the documented process
<melsumner> What if we add language that chairs can use reasonable discretion for exceptions
spectranaut_: great, I’ll make another draft after this meeting
… next, a step regarding APG: if a change is required there
jcraig: I think APG should be last in the process
Matt_King: it depends, I think there will be some features — like aria-actions — where APG would be helpful to tackle earlier
… recommend we add a tag to identify those (e.g., “aria-specification-dependency”) and agree on when it should occur
Jem: I agree, it should be a continuous part of the process, not at the end
jamesn: we’re trying not to have wiki pages
<Jem> ARIA does not have apg label yet so apg label will be great.
spectranaut_: the next requirement is implementation
… in my experience, implementation often results in feedback on the PR
… so at least one needs to happen before merge
Matt_King: yes, this is similar to APG — that can also result in feedback
<Zakim> jcraig, you wanted to discuss the implementation step #6. what pointer should we use for the implementation bugs
spectranaut_: the PR checklist requires browser issues are linked to
jcraig: I haven’t found a great place to point implementation bugs to until the content is in the editor’s draft
jcraig: do we have a recommendation for how to point to the current version even when it’s not merged?
jamesn: great point, need to see why the Preview link is so often broken
spectranaut_: last one is related spec changes
jcraig: my only concern with this is potential merge conflicts
Matt_King: at F2F, we said if you’re the owner of a PR, you should be rebasing/merging on a regular basis
… so this shouldn’t normally be a problem
spectranaut_: we’ll have to work this out
<Jem> Again, this is super awesome discussion. (APG label in ARIA Github will be great.)
spectranaut_: but at the end of the meeting
<jamesn> w3c/
jamesn: good news — ARIA 1.2 has had a transition request sent out with an estimated publication date of Feb 21
… now requires a director to approve
daniel-montalvo: hope to have an update on that this Friday
jamesn: once transition is approved, it goes to PR, then AC reps have to approve it before it goes to recommendation?
daniel-montalvo: yes
jamesn: hopefully it will be done before next week‘s meeting and we can all ping our AC reps
jcraig: thank you spectranaut_ for all the process doc work