<scribe> scribe: Rachael
<alastairc> I can make next week, no thanksgiving for me.
<JustineP> I will be unable to join
AWK: Who is unable to make next week's call?
AWK: Enough people seem to be able to come or at least think they can that we can move forward with next week's call
... the call is on for next week.
AWK: Charter update. Right now we have some changes that have been proposed back to the commenters. We did have some formal objections raised. The charter was extended so we are in charter but there is set of concerns that have been raised.
... Right now there is a series of proposed resolutions that was sent to the commenters. They have till the end of this week to respond. Some are language changes that many people would not think represent a significant change. Some of the changes relate to the focus on web technologies.
... that represents a major concern. Don't want the scope of work to expanded beyond the W3C's scope
... there is also some changes to the timeline. Getting a 1st public working draft of Silver or WCAG 2.2 out in November so those are being pushed out by a month.
... these changes are being reviewed. We will know more next Tuesday when we ARE having a call.
Alastairc: There was one other aspect about the research basis for 2.2 SC but that is still in discussion as well.
AWK: Questions?
JF: One common thread of formal objections was expanding beyond web technologies. It is unclear how the changes will integrate with Silver.
As they integrate UAAG which is a W3C note. Where does that sit? It isn't clear how the changes will be integrated into silver
AWK: This would be easier to answer if we knew the final form of the silver conformance model. We are not planning on offering normative guidance for operating systems but I believe the intention is for Silver to offer additional clarity to authors and AT on how they can support content trying to address accessibility well.
... that information is not going to be in the guidelines directly but will be provided in a non-normative sense. Shaun, do you want to speak to that?
Lauriat: The exact specifics are not worked out. We've been approaching it from guidance at a higher level and then things like how AT could support would be a method. We haven't specifically stated that methods will not be normative but that is the thinking.
JF: I am just concerned the revised language and direction Silver is going in are not in synch.
<Fazio> should we be spending this much time on silver?
Lauriat: I think the main concerns are around the specifics.
AWK: Question raised by Fazio if we should spend this time in Silver. Silver is part of the charter so it is appropriate to spend some time discussing. Any other questions?
... We will keep you posted and hopefully we can reach a resolution so we can move forward. The longer this takes, the harder it is to get deliverables done.
AWK: Conformance challenges document review.
... Janina and Peter Korn have been leading this. There has been a lot of discussion with Silver and with this call.
... Its getting closer.
PeterKorn: What text is in what repository?
Janina: I checked before the call and the changes had not been merged.
Alastair: I am seeing the changes at this time.
Janina: We pushed new text late last night in response to discussion in the Silver task force. We changed the title becuase the document applied to more than large websites.
PeterKorn: As was just discussed, one of the big questions about WCAG/Silver going forward is around conformance. There has been a lot of efforts to develop scoring and evaluation techniques, but we thought it would be helpful to identify the challenges with the current model today. Where is it challenging to apply this conformance model?
... we initially saw challenges around very large, complex sites. That was the first iteration, but then with additional input from Silver, we began flushing these out. When the goal was to get a first public working draft out this year, we were trying to get this document out at the same time so Silver could reference.
... there has been a rapid push to get it done. Key changes since you saw it last are in the Title, Abstract, and additional critques of success criteria with regards to testability. Particulary when the site is dynamic or large, involving humans isn't scalable.
... the changes in the abstract are mirroring what we did in the title. Challeges for web sites writ large. The issues we identified in this draft lean towards large and complex but we'd like to flesh out all these challenges so that silver can take into account the known challenges.
... Also, what we may think of as not programmatically testable with today's technology may be testable with tech the authors are not aware of.
<david-macdonald> "In other words, too many existing accessibility success criteria expect informed human evaluation. " I think eval methodology provides a reasonable way to integrate human testing.
AWK: I am still seeing the longer title.
<Lauriat> I also still don't see the changes we discussed on Silver's Friday call, guessing something didn't make it in.
Alastair: I thought the bullet points were new so it does seem that it is not updated.
PeterKorn: We may be a few hours too soon to ask for AG's approval to take it to a vote for a first public working draft. Perhaps we can discuss when we can take it forward?
Janina: We also got some great contributions from Jeanne and Detlev that we should incorporate.
AWK: If anyone looking at this has comments, the right path is to file a github issue in the github repository with the label Challenges with Conformance
<Zakim> bruce_bailey, you wanted to ask if Janina and Peter really feel like they have buy-in from silver community group?
<alastairc> this should show the new version: https://raw.githack.com/w3c/wcag/master/conformance-challenges/index.html
Bruce: Do you feel like you have buy in from the Silver community group as initiated by the Silver conformance group?
<AWK> AWK: BRuce do you mean community group or TF?
Bruce: I've only just started attending the conformance meetins (task force not community group). This feels more like a AG document rather than a Silver document.
PeterKorn: It was born in Silver.
Bruce: I think its fabulous but I don't think it addresses the Silver conformance group's needs.
PeterKorn: It was born in Silver and worked on by Silver participants. Jeanne requested attribution on it. Silver Taskforce was listed as an author. We came to AGWG a few weeks ago and discussed that it seems that it best belongs in AGWG. That is why we created the AGWG github repo for it to live in.
AWK: This has been a topic that Peter and I have talked about for some time. It seemed that it was directly applicable to what Silver is thinking about with regards to the new version.
... but the challenges document apply directly to what we have today (2.0, 2.1, 2.2). So if we think about how WCAG conformance is applied around the world, these are challenges we have today and hope to mitigate in Silver.
... I think the document applies to 2X and is beneficial to Silver.
... Silver and AG needs to be comfortable with it and then it would be published as a working group note. We hope it is referencable by and can be used by Silver. May also be useful for updating other AG note on test practices.
PeterKorn: In light of the challenges, what are possible solutions? We didn't want to go too far with solutions without understanding the current challenges.
Janina: We would like to publish as widely as possible and get a wide review.
<Lauriat> +1 to updating EM (Evaluation Methodology) note: https://www.w3.org/TR/WCAG-EM/
Janina: We want feedback from the web world.
david-macdonald: Few things from looking at the document. It looks like it is addressing the evaluation methodology. It is diverging in a different direction. A few concerns. "In other words, too many accessibiilty exisitng SC expect human evaluation..."
... in whose opinion? Ours? Are we saying we made a mistake in how we evaluate? I think there are possible pitfalls in the document that could have unexpected consequences.
<AWK> David, please look at my comment that covers your point (I think): https://github.com/w3c/wcag/issues/956
<Chuck> David's audio is breaking up too much for me to understand.
david-macdonald: I think there are potentially provocative sentences that should be filtered out. A human may not be able to check with all 1000 pages but we can check templates and the bulk of unique content.
<Chuck> must be my side.
PeterKorn: Have you filed issue with this sentence and others you have found?
<JakeAbma> +1 to David, when discussed at TPAC I can remember it seemed like a view from people outside of the WG, not the standpoint of the AGWG itself
david-macdonald: That is all I've seen right now. This one sentence concerns me a lot. It should be read and issue filed.
<bruce_bailey> +1 to what David says about deserve a full reading
AWK: I put a link in IRC for issue 956 that also addresses this point so you can join in or create your own issue.
Janina: If github is a problem, email is also fine.
<AWK> Nothing is normative in this document.
JF: The net result is a note. This is not normative. It is a research document and the work is informative and not normative.
PeterKorn: That is the intent.
AWK: We are not charted to produce this as normative.
JF: Right now this document articulates the challenges. What next? Are we proposing solutions/recommendations? It feels like we are halfway through the process. What is the end state we are trying to achieve?
PeterKorn: My understanding is that one of the explicit purposes of Silver is to develop a new conformance model. We have a path to action on the issues this documetn collects (Silver). I have no opinion as to whether any of those challenges would be addressed in 2.2 vs. Silver.
... Should a separate note or a new version of this note articuate solutions? I think it depends on how the work goes in Silver.
JF: I appreciate you articulated it but its a statement of fact without a next step.
... its not clear to me where we go with this document.
Janina: I'm not sure we've fully articulated all the problems yet. I think we need to take the time to really articulate the challenges. 1 is close to complete but we've only just begun 2, 3, adn 4.
JF: Did early research into Silver include these?
Janina: Jeanne just pulled a lot of it that will be in the next update.
<Fazio_> I proposed looking at an ISO 9001 standards model to integrate Silver conformance with because it is a systematic quality assurance standard that covers all facets including policy. It's also a universal standard applicable to "all" industries. Jeanne and I are exploring how to make this work
JF: I'm not seeing a goal of this document. The intention of the work is not clearly articulted.
<alastairc> From the doc: "The purpose of the document is to help understand these challenges more holistically, so that we can build better solutions in the future."
<Fazio_> this would really address large dynamic sites
JF: I am just trying to work out the goal
PeterKorn: To quote the last couple sentences, The goal of this work is not the avoidance of such situations, because they are as unavoidable on the web as in the physical world. The goal is the eventual establishment of reasonable consensus on expectations that maximize accessibility, and limit service downtime, in the on-line environm
<Zakim> alastairc, you wanted to say there are changes I think should be made prior to wider review.
JF: I think you buried the lead. Move the goal statement way up. Clearly state the goal of the document.
<laura> I too had been wondering if if the impetus for this document was to obtain a "Get Out of Jail, Free Card" for Large, Complex, and / or Dynamic Website & Apps. Thanks for the clarification Peter.
Alastair: In the latest version, the goal statement has been moved up. I just wanted to say that several changes are critical to sending this out as a working draft. I do not think you'll get no github issues but we should flag items to do beforce survey and before public review.
<Detlev> AFK for 2 mins
Janina: I have a task to merge and dedp. I'm not sure we want to close them all. We would like to get feedback on some of the responses. It would be good to get review from the general public.
... Just that we have them in the editors draft, there are some issues that may be closed.
<Zakim> Lauriat, you wanted to clarify Silver authorship attribution prerequisites.
Lauriat: originally got in queue when discussing authorship .
<Lauriat> https://github.com/w3c/wcag/issues?q=is%3Aissue+is%3Aopen+label%3A%22Challenges+with+Conformance%22
I want to clarify what needs to happen before its worth opening it up for discussion. Many of the existing github issues have not been resolved. It would be best to update them before we send it out since many people make the same comments.
Silver's conformance model is unlikely to fix the human involvement. I am find with a line that divides which will be done is fine. Having all the issues in a sinle place is very helfpul.
Janina: I think we can can clsoe the urnabn analagy.
PeterKorn: We did try to address some of them but there are clearly items you all would like to get done.
<alastairc> Is there a way in github to 'vote up' issues?
Woudl it be possible to get AGWG to comment on key concerns?
Lauriat: I think a number of us have but at this poitn commments are getting repetative. Would be more helpful to review first and then revise second.
<alastairc> Agree with dealing with some of the issues before a survey.
AWK: We want to encourage that people familliarzie themselves with the issues. Can we delay this to address more comemnts?
JAanina: This document wasn't getting much attention and then it started to do so.
s/JAnina/Janina
PeterKorn: I am looking at the caelendar. When can we synch back up?
... Should we do a second AGWG reivew on hte 26th?
AWK: Based on conversation, December 3rd would be better
PeterKorn: I have a conflict on the 3rd and should probably attend?
AWK: how does December 10 work?
PeterKorn: I may be able to make December 3. lets aim for that.
<AWK> Plan for Dec 3 to rediscuss
<alastairc> Future agenda updated... https://www.w3.org/WAI/GL/wiki/Upcoming_agendas
AWK: We wil start a survye but please review and comment. Please look at github issues before submitting something new.
Janina and Peter: Commit to condensing the branches so may want to wait to review.
<bruce_bailey> +1 to wait on asking for more comments until later this week, after edits
<Chuck> I'll sign up for one.
<MarcJohlic> Spacing Between Touch Targets doc: https://docs.google.com/document/d/1sszSUKB8t3VuRzxHtOjLfQZjNYCw-xr_EbuMwW7WiGc/edit#heading=h.mntlv4jvrc29
<MarcJohlic> AWK: 6 surveyed saying Shall requirements met, 3 say they have not been met
<MarcJohlic> AWK: WF indicated that the 8px space may not always be required - some possible edits there
<MarcJohlic> AWK: My own edits - wonder if we need to define "inline" - how much text needs to be in a line for a link to be "inline"
<MarcJohlic> AWK: If folks made their hit targets smaller in order to conform that would not be good.
<MarcJohlic> AC: We need feedback from people that work with touch displays - that have some heuristics around this .
<MarcJohlic> AWK: DF expressed concerns around testability - would algorithms be smart enough to handle this.
<MarcJohlic> AWK: DM also expressed concerns around testing
<MarcJohlic> DM: Concerned that this would involve a lot of manual testing. Not sure of ways to automatically test it.
<MarcJohlic> DF: The aspect that we don't clarify yet - actual active area not just the visible area. Difference between visible target and actual target size needs some clarification.
<MarcJohlic> JA: This is focused on the actual touch target size - not the visible size
<MarcJohlic> JA: I asked Wilco about automated testing. Wilco did show that it was possible to automate testing, but there are questions around what we specifically want to test
<MarcJohlic> JA: What should be tested is an interesting question - for example you could be testing breakpoints, but a slight adjustment could change everything. So do we test all variants, or do we set specific breakpoints for testing
<MarcJohlic> JA: We need to clearly define what exactly we want to test
<Zakim> AWK, you wanted to ask what OS vendors provide guidance around spacing? And what do they indicate?
<MarcJohlic> JA: Another question - if something is 42px high, you fail because you need to be 44px. If you have something 150px wide but only 30px high - still fail because your target needs to be 44px high
<MarcJohlic> AWK: 44px and 48px was the previous guidance we looked at from Google and Apple
<MarcJohlic> JA: There is some guidance out there - and it also speaks to the 8 CSS pixels as mentioned in the Understanding document
<MarcJohlic> AWK: Seems like what Wilco is saying, if you have a nav bar with 150px wide, but not 44px high - then you need to have additional space between those targets. That seems to be talking about the visual recognition of it.
<MarcJohlic> AWK: I wonder if we can say something - maybe we can base this on height and width separately
<Detlev> +1 Sounds like a good amendment
<MarcJohlic> AWK: Sounds like Wilco has a good point. Any other thoughts on it?
<david-macdonald> https://www.davidmacd.com/WCAG/spacing.html
<david-macdonald> That link above I think is 8 pixels between
<MarcJohlic> AWK: Seems like we need to get the SC text here nailed down first
<laura> yes
<MarcJohlic> AWK: Shortest link in David's example is "Home" at 47 x 26.
<MarcJohlic> JA: It has 8px between, so yes that works
<MarcJohlic> AWK: Another example is on Amazon - there is a dropdown for Your Account where items are 16px but have 7px between them - so it would need a 1px addition to pass
<MarcJohlic> JA: Correction on David's example - 8px margin doesn't solve the target issue
<MarcJohlic> JA: There's an 8px margin and 8px padding so you won't get the margin because it's a block element - need to do a block element
<Detlev> Are we talking about https://www.davidmacd.com/WCAG/spacing.html?
<MarcJohlic> DM: So these have to be block elements if they want to ensure they have spacing correctly
<MarcJohlic> AWK: Not sure they need to be block elements exactly, but there needs to be 8px of spacing between where they touch - whether it's block element or inline
<alastairc> Jake / David, i think there is a margin collapse issue, but there is 8px clearance between them. https://usercontent.irccloud-cdn.com/file/USzM9GDX/hit%20area.png
<MarcJohlic> Scribe notes - page content was changed during discussion
<MarcJohlic> JF: I don't see being addressed in the context of responsive design and/or zoom
<MarcJohlic> JF: If I pick a site that has reflowed where for example the menu is now a hamburger menu - and is only 8px, but if I zoom in I can make it larger.
<MarcJohlic> JA: If we make an SC, we start w/ a baseline - so from a code perspective you'll always have the 8px no matter how much you're zoomed in.
<jon_avila> It would have to be tested at different different responsive breakpoints and zoom levels
<MarcJohlic> JF: I'm not seeing that addressed here (other than CSS pixels). It doesn't seem to me that you've addressed that question.
<AWK> acl ala
<MarcJohlic> JF: At 150% or 200% I've met that requirement - is that OK? Or do we say it has to be at 100%
<Zakim> alastairc, you wanted to speak to the scenario
<MarcJohlic> AC: Agree that it's somethign that should be addressed in Understanding doc - the more difficult thing is the testing aspect.
<MarcJohlic> AC: If we did consider pinch/zoom to be a reasonable solution then there would be no point to this SC
<mbgower> You don't need to Pinch to zoom. It's a built-in AT in mobile
<MarcJohlic> JA: Pinch/Zoom by definition is not an acceptable solution because some folks can't use it
<MarcJohlic> JF: Just calling out that will responsive design etc it creates a question of "What is the expected baseline". I would like to see that in the Understanding doc. Something like: "Without any other assistive technology" etc
<jon_avila> in 1.4.4 we explicitly say without assistive technology - 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA)
<Zakim> AWK, you wanted to say that there is a common issue here with 2.1's reflow SC and testing for that
<alastairc> Not sure who else is adding to the discussion section at the bottom, but I'm going to de-duplicate, don't panic.
<MarcJohlic> AWK: Part of why we talk about CSS Pixels is because that can be implemented by the author - and zooming in doesn't change that. If there's changes due to responsive layout that's different.
<Zakim> mbgower, you wanted to say you do not need to pinch to zoom content
<MarcJohlic> MG: I want to flag that we'll have to address that pinch/zoom is not the only way of activating zoom and should be called out. Make sure the argument is consistent across SCs
<MarcJohlic> AWK: Some issues - some things to figure out for the MATF group.
<MarcJohlic> AWK: There was some confusion around this one
<mbgower> Resize Text allows user agent zoom to increase text size. We need to address why this isn't allowed for increasing target size
<AWK> Google doc: https://docs.google.com/document/d/1e46eqQnVYqdSyqo29pyJoY1QynRH9v95YW8soTTbfsU/edit
<MarcJohlic> AC: We have the same document from TPAC. Originally was one SC, but then at TPAC we split it up
<MarcJohlic> AC: Under persistent labels we have two versions
<MarcJohlic> Fazio: The mechanism one is the correct/best one. The most current one.
<MarcJohlic> AC: Is the bit below it still needed?
<MarcJohlic> Fazio: Sorry - should have removed that
<MarcJohlic> Version 2 removed
<jon_avila> I wouldn't consider that as a pass of 3.3.2
<MarcJohlic> AC: If you have a form with instructions above it, that would pass if the label disappears on some input.
<jon_avila> The label or instructions need to be for each field.
<MarcJohlic> AWK: If there is generic text like "Please complete this form" it doesn't seem like those instructions are sufficient - just telling you it's a form
<alastairc> "Inputs with labels or instructions display the labels or instructions at all times."
<MarcJohlic> Previous version
<MarcJohlic> Fazio: Typically a form field has either or: labels or instructions. This SC is for situations like that.
<jon_avila> what you describe already fails 3.3.2
<MarcJohlic> Fazio: For example where you have a field where the label disappears as your typing - or worse stays making it harder to see what you're entering
<jon_avila> The definition of Label in 3.3.2
<jon_avila> text or other component with a text alternative that is presented to a user to identify a component within Web content Note 1: A label is presented to all users whereas the name may be hidden and only exposed by assistive technology. In many (but not all) cases the name and the label are the same. Note 2: The term label is not limited to the label element in HTML.
<MarcJohlic> Fazio: Part of the confusion may be what we consider a "label" - maybe that's what we need to better define
<MarcJohlic> AWK: Part of the discussion is whether placeholder text is sufficient. WG has considered placeholder text not sufficient because it goes away
<david-macdonald> "Labels or instructions are provided **when** content requires user input. I think you could say that "when" still is active during entry of data
<MarcJohlic> AWK: If the label disappears of if the text goes on top of it, it doesn't make it clear to the user what the label is (or was)
<MarcJohlic> AWK: That's how the working group have previously interpreted 3.3.2
<Zakim> alastairc, you wanted to say it is the instructions aspect that we are missing
<david-macdonald> true (sadly)
<MarcJohlic> AC: If instructions on a form page at the top were more explicit on exactly what to enter, that would pass
<MarcJohlic> AWK: Exactly - another example would be "Phone number (xxx-xxx-xxxx)" indicating what is expected and then there are 3 fields below
<MarcJohlic> AWK: If you have instructions that don't apply and you have labels that disappear, do you pass?
<MarcJohlic> AC: Grey area
<david-macdonald> id fail it under 1.3.1
<MarcJohlic> AWK: Personally feel it's clear that you wouldn't meet 3.3.2 - what do others think
<jon_avila> I vote to update 3.3.2 understanding document rather than create a new SC.
<AWK> +1 to Jon
<JF> +1 to Jon
<MarcJohlic> Rachael: Have found it unclear in the past. If there's a way to clarify 3.3.2 that might be the better route (than adding new SC).
<alastairc> +1 if we agree that the instruction has to be specific to the input.
<MarcJohlic> +1 to Jon and Rachael
<Detlev> My take: With several fields below the description would have to be specific enough to help users identify where to out in what...
<MarcJohlic> Fazio: My goal was to address some STM loss - as you're filling a field and labels disappear. So however we address that, that's great.
<MarcJohlic> JF: I agree that there's a difference between instructions and labels. Instructions what you're supposed to do - and labels where you're supposed to do it.
<MarcJohlic> AWK: Anyone want to take a crack and our history and see what we decided around this topic?
<MarcJohlic> AWK: Suggest looking through archived content for terms like "placeholder text"
<alastairc> Github issues, not decisions: https://github.com/w3c/wcag/issues/923 & https://github.com/w3c/wcag/issues/673
<MarcJohlic> AWK: Alastair please create an issue in GH around clarifying 3.3.2
<MarcJohlic> AWK: At the top of this same Google doc, the "Information in Steps" section
<MarcJohlic> AC: We don't have "Information in Steps" up for survey this week
<MarcJohlic> AWK: OK - in the few remaining mins maybe we can ask a few questions that will help develop this one
<MarcJohlic> AWK: "Information provided to the user is available throughout the entire process - this seems like it needs a lot of examples to support it. Are there bad examples / good examples?
<MarcJohlic> In general I'm just a bit confused as to what this is mandating"
<MarcJohlic> Fazio: Important phrase missing - about something needed for a subsequent step later on for the sequential process
<MarcJohlic> Fazio: If you enter it once, it should be available to you later on as well so that you don't have to keep going back to retrieve the information.
<MarcJohlic> Fazio: We do have that in the SC text
<MarcJohlic> AWK: I don't think "required" is actually in there
<MarcJohlic> Fazio: Thought it was in there, will look into it
<MarcJohlic> AWK: Any last questions that could help them on this one?
<MarcJohlic> AWK: We can come back and look at this one in more detail.
<MarcJohlic> AWK: Yes, to Rachael - we'll look at revisiting essential controls next week
<MarcJohlic> trackbot, end meeting
<laura> bye
This is scribe.perl Revision of Date Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_HTML_Format (score 0.99) Succeeded: s/UAG/UAAG/ Succeeded: s/needing a full review/deserve a full reading/ Succeeded: s/face/fact/ Succeeded: s/Alastar/Alastair/ Succeeded: s/shoudl/should/ FAILED: s/JAnina/Janina/ Succeeded: s/zoom is not a solution/zoom is not the only way of activating zoom/ Default Present: AWK, janina, Chuck, alastairc, JF, JakeAbma, Detlev, Rachael, Fazio, bruce_bailey, JustineP, Lauriat, MarcJohlic, Laura, Katie_Haritos-Shea, mbgower, jon_avila, david-macdonald WARNING: Replacing previous Present list. (Old list: AlastairC, Katie_Haritos-Shea, Chuck, JakeAbma, JohnRochford, Raf, MarcJohlic, Fazio, MichaelC, Laura, david-macdonald, Detlev, mbgower, johnkirkwood, +1, bruce_bailey) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK WARNING: Replacing previous Present list. (Old list: AWK, janina, Chuck, alastairc, JF, JakeAbma, Detlev, Rachael, Fazio, bruce_bailey, JustineP, Lauriat, MarcJohlic, Laura, Katie_Haritos-Shea, mbgower, jon_avila, david-macdonald) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ AWK, janina, Chuck, alastairc, JF, JakeAbma, Detlev, Rachael, Fazio, bruce_bailey, JustineP, Lauriat, MarcJohlic, Laura, Katie_Haritos-Shea, mbgower, jon_avila Present: AWK janina Chuck alastairc JF JakeAbma Detlev Rachael Fazio bruce_bailey JustineP Lauriat MarcJohlic Laura Katie_Haritos-Shea mbgower jon_avila Regrets: JohnKirkwood Rafal JennieD Found Scribe: Rachael Inferring ScribeNick: Rachael Found Date: 19 Nov 2019 People with action items: WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]