Meeting minutes
<Jem> https://
Setup and Review Agenda
Jem: With only five people present, this may be an abbreviated meeting
<jugglinmike> Next meeting: February 27
Next publication
Matt_King: We have two infrastructure-related patches ready
Matt_King: One is about enforcing code quality upon merging
Matt_King: The other is a change to the skipTo library
Matt_King: That's everything that I'm aware of which is currently ready or about to be ready
Matt_King: We want to cut the publication branch for those things on next Monday (February 26)
Jem: Nick has been helping us, but he has not been able to attend this meeting
Jem: Our thanks to Nick!
howard-e: Regarding the coverage report which was merged: there was a failing build (Nick also commented on that about an hour ago)
howard-e: Nick is suggesting here that when a pull request affects the examples is merged to the "main" branch, it has to be merged on the same date that is referenced
howard-e: That doesn't seem feasible; it means asking contributors to always run the coverage report before submitting their patch
Matt_King: Should I revert the merge?
howard-e: The "main" branch is failing because the date is stale
Matt_King: That wouldn't normally happen, right? Isn't it only happening because we ran it manually?
howard-e: If someone were to modify the Alert pattern on one day, and the reviewer approves it the next day, then when they merge the patch, it will fail
Matt_King: I thought this script only re-runs the coverage report at the time that any pull request is merged. So if I merged to the "main" branch, the workflow will re-run the report at that time. Isn't that right?
howard-e: it re-runs it, but it doesn't push the updated date back to the repository
howard-e: it works now because it gets updated whenever a contributor pushes to their branch. The problem comes in when a patch is merged more than one day after the final commit is pushed
Matt_King: We already maintain a date like this for the index page. Can we update the workflow to work the same way?
howard-e: I think so, yes
Matt_King: Sounds like we need a new patch
Matt_King: The script seems to be working; we just need to change how we schedule its invocation
howard-e: I think we can solve this by ignoring the workflow in response to "push" to the main branch
Matt_King: That sounds like the opposite of how we solved this for the date listed in the index
howard-e: When should we capture the date? When the contributor makes their changes, or when the pull request is merged to the "main" branch?
Matt_King: When the pull request is merged to the "main" branch
Jem: I agree
<Jem> https://
<Jem> this is the part Nick mentioned.
Matt_King: Will it create more problems if I merge the "main" branch into the open pull requests for the examples right now?
howard-e: Yes, it will
Matt_King: Okay, then I'll hold off on doing that until we have the fix in place
<Jem> https://
Plan issue triage process kickoff
https://
Matt_King: Since our last meeting, I added a paragraph to the summary of the "intake" process
Matt_King: Likewise, I added a second paragraph to the following section ("Bug reproduction documentation process details")
Matt_King: It seems that I forgot to add some text describing what happens in the event that the bug is not reproducible. I'll do that, next
Matt_King: I simplified the first step of the "intake" process describing the determination of "in scope" versus "out of scope"
Matt_King: I also simplified the third step--the one about categorizing the feedback
Matt_King: I updated the labels to match these
[discussion about the current draft's two distinct definition of the term "out of scope"]
Matt_King: I'll resolve that by qualifying each use of the term--"out of scope for the triage process" and "out of scope for APG"
Matt_King: Or maybe we don't need the first two steps. Maybe we just start with step 3 and if it's not one of these five things, there could be another bucket...
Matt_King: After all, when we create issues for ourselves, we can add the appropriately labels immediately at that time. That way, those issues won't go through this triage process
Matt_King: I've been trying to write this in such a way that we can handle both new issues and all the old issues (some of which already have labels)
Matt_King: So we might remove step 1 and 2, but we'll have to decide what to do with all those issues that have already gone through some form of a triage process
Matt_King: What's missing is that we don't have criteria for determining what's in-scope for the issue triage process
Matt_King: I don't want to get too stuck on this problem right now. Let's assume that this part of the process will be ironed out in the next few days. What are the next steps for the team?
Jem: I'm willing to be the first leader of the triage team
Matt_King: Great! What that means is coordinating the schedule for the rotation
Matt_King: I imagine that includes intake and bug reproduction/documentation
Matt_King: Also, there's deciding whether the team wants to have its own communication channel(s)
Matt_King: I don't know if/how you want to handle that, or if you'd rather just do it all in the issues
Jem: A Slack channel sounds good to me. I think we already have a Slack channel for the APG under the W3C Slack account
Jem: I'll take responsibility for identifying a communication channel
Matt_King: Alrighty. I'll keep thinking about how to debug the first part of the process document so that it's more clear
Fix to make combobox labels clickable
github: w3c/
Jem: We need a code reviewer and a functional reviewer
Matt_King: It could be the same person
Matt_King: This is a very small pull request!
Matt_King: I posted a question to the patch
Matt_King: I don't know why it changes the "label" element to a "div" element. I don't think it has any practical effect either way, but the "label" element seems more semantically accurate
Jem: Hearing no volunteers for review, we'll leave this on the agenda for next week
Link checker
github: w3c/
howard-e: The link checker fails to find a GitHub link with an ID matching the anchor
howard-e: It worked once. The reason it no longer works is that there is a server-rendered element now rendered on that page which is not easily identified using the link checker implementation
howard-e: The server-side-rendered element seems to be hiding the one we want
howard-e: I have some thoughts about the stability of this solution, but I haven't reviewed the latest changes (Erika has made more changes since I last shared feedback)
howard-e: I will be taking a look again this week
Matt_King: This is really about testing the fragment part of the link. We're not worried about the link checker failing because the URL of the page is wrong. It's just that if we specify a fragment and the fragment is invalid--that's a problem
Matt_King: We want to catch those kinds of errors when we can
Matt_King: Okay howard-e, you merge this when you think it's ready
howard-e: Will do