Meeting minutes
<Jem> Meeting agenda: https://
<Jem> https://
<Jem> w3c/
Setup and Review Agenda
Jem: Any requests for changes?
Matt_King: I just added an item for issue triage process
Jem: Next meeting: February 20
Next publication
Infrastructure: update skipto.js to version 5.2.1 by jongund · Pull Request #2807 · w3c/aria-practices
Matt_King: I merged that. Thanks to all involved
Matt_King: It should be ready to go
Matt_King: There are two others that are waiting on review from me
Next publication date
Matt_King: I'd like to target the end of February
Matt_King: That would be two weeks from today
Matt_King: I think we'll have "feed", "coverage report", "skipto" and at least one more
Matt_King: Does anyone see any reason we couldn't meet that deadline?
Jem: Sounds doable to me!
Matt_King: Okay, hearing no objections, we'll work toward preparing a release on February 26th
howard-e: that sounds fine to me
Auto-updating of coverage and quality report
Jem: It looks like there is a preview for this
Matt_King: yes, thank you arigilmore!
Matt_King: Whatever the date of the last commit is the date that will show up on the page
Matt_King: The script is triggered by a workflow that runs in response to a commit to the branch
Matt_King: Does the visual presentation look good to everyone?
Jem: Looks good to me
howard-e: there is a bit of whitespace which appears at the beginning of the HTML "p" tag, though
arigilmore: I can remove that, no problem
Matt_King: Then I will merge this, and it can be included in the next publication. Fantastic!
Matt_King: Are there any concerns about the failing checks?
howard-e: I'll do some quick checks and comment in the pull request
howard-e: Erika from Bocoup has submitted a pull request to address the first failure
howard-e: The second failure is a bit more puzzling, so I'm going to need to investigate more deeply
arigilmore: Can you run the script again and then push that change?
arigilmore: Sure
Issue triage process
<Jem> https://
Matt_King: I haven't written the wiki page related to issue severity and prioritization, yet
Matt_King: I wanted to begin with the triage process
Matt_King: This is my proposal. You can shoot as many holes in it as you want!
Matt_King: I think we should form a group of people specifically tasked to clean up the issue tracker
Matt_King: There are four primary steps in this process: intake (totally asynchronous), bug reproduction (if there is a bug--also totally asynchronous), prioritization (in a meeting), and finally "close or reprioritize"
Matt_King: We'd review the team membership on a regular basis (who's on the team, who wants to be on the team, who leads the team, etc.)
Matt_King: I'm hoping to involve the people who aren't ready to write code but who still want to contribute
Matt_King: Let's dive into details
Matt_King: For each of the steps in "intake", the work is done asynchronously
Matt_King: I'd expect these steps to be performed at least once a week
Matt_King: There are a lot of steps, but they are fairly quick. The whole "intake" process ought to take about 15 minutes
Matt_King: this process doesn't handle every possible kind of issue. There are a lot of other kinds of issues in the system, but here, you only consider the stuff that's applicable
Jem: I think step number 6 could be moved as a sub-step to step 4, "if it is a bug"
Jem: So the issue will have at least three labels?
Matt_King: That's right
Matt_King: We only add the "agenda" label to bugs if we find that it's reproducible
Matt_King: I need to add another step to describe what to do if it's not reproducible
Matt_King: The next part is "prioritization"
Matt_King: We'll use a prioritization framework that has yet to be defined
Matt_King: I'll write out the steps for assigning work, but I think the assignment is the part that should happen during meetings
Matt_King: In the past, I think this Task Force has struggled partly because we haven't fully recognized the work that can be done asynchronously. Embracing those should make our meetings more efficient
Jem: Do we really need a label named "feedback"? Under this process, won't all the issues have that label?
Matt_King: There will be issues that don't fit this process and which won't receive the "feedback" label
Matt_King: For instance, questions
Jem: It would be good to define the "feedback" label, to capture the distinction between "internal feedback" and feedback that comes from outside the Task Force and the APG community
Jem: A definition for every label would be nice, actually
<Jem> https://
Matt_King: Definitely. GitHub supports assigning a description to labels, and I agree we should use that feature
Matt_King: I think the next big thing (after we work out the details) would be forming a team of people who can coordinate asynchronously and trade responsibilities
Matt_King: That's just a thought I have on how this could work. The process would be always running and would be always open to relative newcomers--even folks without any relevant engineering experience
Matt_King: Is anyone excited about leading such a team?
Jem: I could do so if no one is interested
Matt_King: Leadership doesn't have to be static. There could be a rotating group of leaders
Jem: We were supposed to have three members in the "editors" team. We've been missing a third for a long time. Would this be a good time to fill the third spot?
Matt_King: In fact, we don't have to have three editors
Jem: Sharing the responsibilities a bit more would reduce some pressure, though
Matt_King: Sure, though designation of an editor with W3C is a somewhat formal process, so I don't know if we want to tie it into the process we've been discussing today
CurtBellew: I appreciate the process that you've proposed today, Matt_King
CurtBellew: Leadership of the new group sounds like a good opportunity for me to take
Matt_King: We currently have 559 open issues. That's a lot! If we had a slow, steady burn, we could make some great strides
Matt_King: I suspect there is a lot of junk in that list. After closing those and assigning priorities to others, we might stand a chance of addressing the highest priority issues relatively soon
dmontalvo: I think this is good. Hopefully it will help us achieve the goals
dmontalvo: I'd like to be part of the team. Maybe not to lead it, but certainly to contribute asynchronously on a regular basis
Jem: Thank you!
CoryJoseph: I've been away over the past month, but from what I'm seeing today, this all makes sense to me
howard-e: I don't have much to add; I agree that this is a good opportunity for a process
Jem: Great!
Matt_King: I think I have clear next steps, then
Matt_King: Maybe next week, we can figure out the first rotation
Matt_King: I've got to finish up some of the documentation, and then next week, we can discuss how we want to proceed from there
Matt_King: Thanks everyone for your input! Here's hoping this process helps things move forward in a faster, easier, and more inclusive way!