Meeting minutes
calendar reminders and announcements: AGWG All-day, survey for joint ACT meeting, 30 min AGWG issues meeting
Jeanne's announcements: Reminder of all day joint meeting for April 29 with AGWG
<jeanne> https://
Jean's second announcement: next All day Joint meeting with ACT, poll in IRC for date
Jeanne's third announcement: 30 minutes after this call, we are invited to the first 30 min of AGWG for live issue processing
Issue handling training
Alastair to discuss how AGWG processes issues
<alastairc> https://
Alistair: AGWG process might apply to Silver, even though outcomes are different
alistair: responses need to be created to comments. Could be an update to the documentation, or a response why the comment isn't being adopted
<Zakim> sajkaj, you wanted to ask whether draft response goes on github?
Initial discussion on comment decides to adopt response, agree with documentation update, or if there is not agreement then another discussion is required.
<Fazio> Responses that disagree with an isssue/comment should be diplomatic thanking the commenter and saying we consider their comment
<JustineP> +1 David
Janina asked - should draft responses go into github directly? Alistairs answer is they can, as long as they are marked as draft. If it is controversial, drafts can be in email.
<jeanne> +1 David
<JustineP> Should we formally assign ourselves to issues using Github tags?
alistair: use email if you aren't confident of your response
alistair: you can send a "holding" response that says effectively: "we are going to examain this in the future"
Jeanne: can you update a number of issues simultaneously?
<Zakim> jeanne, you wanted to ask at what point you close the issue where there are multiple comments on the same issue
Alistair: yes, you can close multiple issues with a single updte
Jeanne: clarification - you don't update the ticket until the proposed large change is ready? Alister agreed
<Zakim> bruce_bailey, you wanted to suggest GitHub labels for grouping
Bruce: should we use labels to group?
Alistair: there are topic labels and lifecycle labels (surveys were the example he provided of a lifecycle survey)
<bruce_bailey> very nice, adding key word as first word in labels
Alistair: if you aren't sure about a label leave it to your label manager
<bruce_bailey> i retract my suggestion to look into the GitHub "Project" feature
<jeanne> https://
Jeanne: We have 200 issues that aren't assigned to a subgroup. Those are the ones we need editors to help. Label is "needs proposal"
Jeanne: Create a github account if you don't have one
<Zakim> JustineP, you wanted to follow up on question about formally assigning ourselves to issues in Github for tracking purposes
Alister: once you have created an account, email Michael so he can attach your account to the repository. Then you can assign yourself issues
<jeanne> I have updated the link to only include issues that Need proposal AND are not assigned.
Alistair: survey should only include things that have a clear response so you understand what is being proposed.
Alistair: survey gives you 4 options: accept as is, accept with mods, leave as is, something else
Alistair: AGWG did one survey per SC
Alistair then walked through an example with IBM's comment #500 which hd multiple parts
<bruce_bailey> i wish we had thought to do a video recording of this session!
sorry audio problems
Alister: it would be best if we could tell from the ticket who generated the comment. If the commenter added their ticket in Github directly, you can comment in the ticket.
Jeanne: Tickets that were emailed in should have a link to the email at the beginning of the ticket
Alister: if the commenter doesn't respond to the request for more info, you can close the ticket with the proposal and finish with "if you aren't happy with this response, please open a new ticket"
Jeanne: sometimes there are lively discussions in the thread. What do we do with those?
Alister: focus the discussion on the original comments. Sometimes new issues come up in the discussion, those need to be separated out into their own tickets
Alister: it is useful in complicated tickets if you write a recap, and then you can search for your name later to find it
<Zakim> jeanne, you wanted to ask about summarizing discussions in the thread
Chuck: once you have a resolution, what then?
<Fazio> The commentor doesn't necessaarily have to agree
Alister: If there is an agreed change, someone needs to make the update. The easiest way is to put the PR containing the change in the survey
Alister: the PR should state which issue is being closed
Alister: Issue gets closed after change gets merged in
Alister: use the surveys as the nexus point
Alister: David is right, only the group has to agree, the commenter doesn't have to agree
<JustineP> If issue is very simple (e.g., typographical error) should we just implement via pull request and close issue afterwards?
Jeanne: All of our surveys are open, otherwise community groups don't have access
<Fazio> Surveys for issues feels like a lot of inundating emails
Alister: simple issues like typos can be fixed and closed without surveys
Jeanne: don't let lack of git knowledge stop you. The hard part is the proposals. Other folx can handle the tech bits for you
<Fazio> I find surveys hard
<Fazio> the format is hard for me to read cognitively
Jeanne: to answer David's comment, it should be one email per week announcing the survey. Please keep your comments IN the survey and not in the email thread
<Fazio> I like the thread better
<Fazio> in github
<bruce_bailey> very nice overview !
<Lauriat> +1, thank you!
<jeanne> +1, thank you!
<alastairc> WCAG 2.x, but similar... https://
Chuck: in the AGWG call we can review one where we have a proposed a response. We need to increase confidence on proposed responses.
Jeanne: Several comments are about usability. If you are a usability specialist, please look at the label "section: usability issues"