W3C

- DRAFT -

Accessibility Guidelines Working Group Teleconference

03 Dec 2019

Attendees

Present
AWK, Brooks, Chuck, Fazio, JF, JakeAbma, Katie_Haritos-Shea, MarcJohlic, Rachael, Raf, janina, johnkirkwood, mbgower, bruce_bailey, Avneesh, PeterKorn, david-macdonald-2, Detlev
Regrets
Chair
AWK
Scribe
JustineP

Contents


<scribe> scribe: JustineP

WCAG 2.2 Information in steps https://www.w3.org/2002/09/wbs/35422/info-in-steps/

AWK: AG seems to feel that SC is on right track but needs more work

Fazio: Lots of comments received over the last week

AWK: Let's focus on this for the first part of the call with a goal of releasing working draft
... priority level (A) has been added
... David MacDonald commented that "shall items are not met"

Fazio: Medical evidence backs up extent to which impact is covered but we can reduce if problematic

David MacDonald: would like to see "or" statements used in Understanding doc

AWK: Do we have to do both steps in process or one or the other?

Fazio: originally one or the other. "Preserved throughout the process" text is new.

Mike Gower: crossouts were my suggestions

scribe: also wrote "preserved throughout..."

AWK: I don't understand what first bullet does. Shall items are met but not sure what that first bullet does. What are the expectations for a web page that conforms to SC?
... how would we know?

Mike Gower: "Preserved" may not be right word. If you're provided information in Step 1 and have to re-enter in Step 5, the information should be readily available at Step 5 or autopopulate

scribe: so you don't have to remember or search for info.
... issue is with problem/remembering and cognitive function breakdown. Example: previous address, phone number
... point is not having to remember things, over and over
... doesn't have to be complicated information

JF: Looking for clarity. When you say "is preserved throughout..." is that the current process or every time you complete a process?
... can see wanting address entry to be carried through but if I do again next week, is intention for info. to be remembered at that point? Can be addressed throughout editorial adjustment.
... We mean current process.

Fazio: Found Alastair's original edits, will share

<Fazio> Alastairs original edits that I like: For user interface components that collect information from the user, and which are part of a process (i.e., a sequence of steps that need to be completed in order to accomplish an activity), the following are true: Information entered by the user remains available to the user throughout the entire process. Subsequent instances of completed fields are auto-populated, unless re-entry is essential.

Mike Gower: First suggestion re: idea of preservation...in a multi-step process shouldn't lose data that was previously entered

scribe: at one point was front and center and wording was lost. Hence introduction of "preservation" wording. Also seems to be redundancy between two bullets.
... tried to differentiate

<Fazio> should it be 3v bullets then

JakeAbma: is not clear what first bullet is trying to accomplish. What does "preserve" wording do? If you need info. throughout a process but it is only shown at the end of the process, it is not applicable.
... need to be more clear with that sentence or consider deleting

<Fazio> Good point, Jake

<Zakim> AWK, you wanted to ask for examples/scenarios of non-preserved information

AWK: David Fazio, do you agree that "preserved" isn't needed?

Fazio: don't see necessity of "information is preserved" since that is the original intent
... we get to core issue with Alastair's orginal wording
... information should be available without the need to search (immediate access at the time you need the info.)
... also made one edit to include "info. also provided by the user"

<david-macdonald-2> previous version https://docs.google.com/document/d/1D8IZS-NOIEjNlRXTw9rIMMrVft-TC9l7h2KbwNUaCKM/edit

would be difficult to remember where you lived 15-20 years ago so once entered, that should be available to user

David MacDonald: we lost "provided to" in the current version

<Fazio> At point of use

scribe: I'm hearing that the idea is for info. to be available without going back. What you're saying David is that a modal dialogue or similar should be available to provide the info.

Fazio: developers can be creative with implementation (e.g., dialogue box, next to relevant area, link) but going back is not a good way to accomplish

David MacDonald: sounds like we're proposing a new convention that doesn't exist on web today

scribe: am I understanding correctly?

Fazio: Not new. If you input info. into form field that info. should be available again when you need it.

David MacDonald: can you share examples of desired implementation?

Fazio: not that I can't think of immediately

Brooks: if anyone has done taxes online, that's a good example

<Fazio> I like this tax example

Brooks: when filling out info. to do taxes, adjusted gross income is available when you need to enter state tax information
... is an example of information that is preserved throughout a process

<johnkirkwood> there are user agents that do it. such as 3rd party password managers like "dashlane"

JakeAbma: you were talking about a calculation that is autopopulated, isn't necessarily about first bullet

<Fazio> We want to include both provided by and to

<Fazio> not everything

<JF> +1 to Jake - scale and scope is concerning to me as well

JakeAbma: about first bullet though, for SC to state that everything in a process must be preserved without describing what that means creates a difficulty

<Fazio> Only what is required to proceed

JakeAbma: to have all information, every time at every step will make it hard. Specifically when current processes become larger (e.g., 14 steps -- some of which lead to a different branch)
... don't think it would be helpful to people intended to be helped by the SC

<Fazio> It's most important in lengthy processes

JakeAbma: maybe we can scope to an overview or certain steps back in a process

Rachael: The goal is if you need to re-enter information, you can see it. Every piece of information doesn't need to be available all the time.
... if you go back in a process you risk losing where you were/orientation for future steps

<Fazio> well said Rachael

<Fazio> that provides the example of availability

<Fazio> Amazon

Rachael: to address example, when you enter billing information in a purchase you have the option to pull that address or enter a different address for shipping

JF: To point Jake raised about amount of data...have we declared a ceiling/maximum level? Seems that at some point, that could be a lot of data that we are asking entities to retain.

<Fazio> Only required data to proceed through a current process

JF: is there a technical limit? Not sure. Not sure about impact on usability. Have those been investigated?
... at some point we should define level of data that should be stored

<Fazio> It doesn't need to be "stored"

JF: Rachael's example -- we can preserve using autocomplete attribute. A lot of that information can be stored in browsers. How much info. are we asking site owners to retain while in session and what is impact on other technical concerns/usability?

<Zakim> AWK, you wanted to ask about scenarios for information not being available in a process, other than autofilling

AWK: For myself, the core ask seems to be information that is put in once doesn't need to be entered again. Exception exists for essential information.
... is the only reason we have other bullets about "preserving" because we anticipated pushback from site owners around making that information filled automatically?
... shipping address/billing address example -- wonder whether that's a problem today. There must be other scenarios where this is an issue.

<Fazio> I have a scenario in the doc

AWK: if we put this out, would we have anyone saying this isn't technically feasible?

<JakeAbma> +1 to possibly delete

<Fazio> Supplier Diversity Applications that require a company to select NAICS codes

Mike Gower: was trying to capture notion of being inside a stepped process. A user realizes they need to go back to a previous step, and action of moving back removes previously entered data.

scribe: thought that was a key issue that was initially raised
... seems that there's redundancy between the two bullets but I remember hearing desire not to have info. reset. If that isn't a need, consider deleting.

<Fazio> Not all just what is required to proceed

scribe: concerned with frame put on the word "preservation". I don't see that meaning everything entered to-date available on the screen.

<JF> +1 to Mike's point about preservation and technique

scribe: also have concerns with word "autofilled" being too prescriptive
... should wording be less directive?

Fazio: Andrew made a point that word "required" should be in SC, haven't had time to add. Is only focused around information that's needed to proceed to a next step. Not all information that has been entered.
... doesn't require storage in my mind, only moving information along in a process
... supplier diversity applications was added to wording as information need to be entered multiple times. A good example.

<JF> There are a number of web technologies that store data of one kind or another on the client-side (i.e., on your local disk). The process by which the browser works out how much space to allocate to web data storage and what to delete when that limit is reached is not simple, and differs between browsers. Source: https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Browser_storage_limits_and_eviction_criteria

Fazio: another example, Amazon purchase process shows billing/shipping address and ask if a different shipping address should be entered

AWK: to Mike Gower's question about bidirectional progress through a form, are we expecting information to be preserved at different steps in a process?

Fazio: Don't want users to have to go back

AWK: my question is about users that want to go back. Example: hotel reservation process, decide you need to change a date entered earlier in process...is system expected to maintain all information entered since that original date selection?

Fazio: No, we didn't intend that with the SC

AWK: A form could be smart enough to determine what information is no longer valid.
... in Google doc, I attempted to reformulate. Seems that first bullet isn't needed as long as we capture its intention.

<mbgower> I distinctly heard this raised as a concern, either in this round or a prior round. If that is not a requirement, the first bullet can go. But I am surprised that's not being covered.

Fazio: I'm fine with that suggestion

AWK: To Mike Gower's comment, I remember challenge was related to backward movement within a form and certain information being preserved

Fazio: That's what I thought "essential" was intended to qualify

+1 to Rachael's suggestion

Fazio: was a discussion about how original wording of SC was only focused on forward movement within a form
... I've encountered the first bullet in numerous situations. If we do keep bullets, keep "essential" inside of both bullets

Mike Gower: If its going to be too difficult, we're okay with removing but we were mostly concerned with forward movement

<Rachael> +1 to trying to tackle this if possible

Fazio: airline booking scenario, if you were going back to change dates information that could be preserved should be preserved, otherwise information could be removed if it didn't meet the requirement
... shouldn't have to re-enter just because you went back in a process

last comments I believe were from Mike Gower, not David Fazio

AWK: seems like there is concern about first bullet. Want to ask Jake and John if Mike Gower's comments regarding forward/backward progress relates to concerns about first bullet? Or separate?

JF: Not sure if its an issue with larger amounts of data that need to be preserved. Want to make sure what we're asking is actually achievable.

<Fazio> both

JF: if moving between two different airline booking sites, should information be carried across sites? I've never seen it happen.

<Fazio> I think iI think it's both to and from but it may be because I start with kayak first

<Fazio> which searches all airlines

AWK: for airline bookings, it wouldn't be expected that information would be preserved in future weeks

<mbgower> I really question needing to put in "current" in the SC. That can be addressed in the understanding doc, in my opinion.

JF: goal is to retain information in the middle of a process, not to retain for some point in the future

<Fazio> no... And what I'm talking about is in subsequent searches in the same hour

JF: want to be sure what we're asking is actually achievable

<mbgower> Yep, looks good

Jake Abma: to Mike's example regarding backward/forward movement...scenario is valid and would be good for SC to cover

<Fazio> How about provided data is not loss when user navigates to a previous step?

scribe: need to word in such a way that its clear regarding backward/forward movement and autopopulation/preservation of information

<Zakim> mbgower, you wanted to say "current" makes it awkward in the SC. Just tackle in the Understanding

scribe: need to reword sentence as it currently exists

Mike Gower: don't see that "current" needs to be in SC text. Can add to Understanding doc.

AWK: agree with Mike's suggestion

<mbgower> scribe, mgower

<mbgower> AWK: There are some comments in the Understanding doc we need to work on. There are some techniques that need to be aligned with what the SC text ends up being.

<mbgower> AWK: We need to point to some implementations. That should be straightforward; we've talked about a few. Do you need help?

<mbgower> scribe, mbgower

<mbgower> AWK: There are some comments in the Understanding doc we need to work on. There are some techniques that need to be aligned with what the SC text ends up being.

<mbgower> AWK: We need to point to some implementations. That should be straightforward; we've talked about a few. Do you need help?

<mbgower> Fazio: With David M and Alastair assisting, I think it's good.

<mbgower> Jake: I'm concerned with the updates to the wording that have chagned during discussion.

<mbgower> AWK: Put a comment in. Let's move on.

WCAG 2.2 Page breaks https://www.w3.org/2002/09/wbs/35422/page-break-nav/

<mbgower> AWK: Welcome Avneesh, Matt and George

<mbgower> AWK: This is talking about page breaks and fixed reference points

<mbgower> AWK: Thanks David for handling this along with others who have joined. Is this the first time we've talked about on wg calls?

<mbgower> David M: It was covered at TPAC and a subsequent call.

<mbgower> AWK: Reads out current wording.

<mbgower> AWK: We've only had a few people review it -- 3 who have filled out the survey.

<mbgower> AWK: Alastair had a comment about being interested in epub perspective.

<mbgower> AWK: Will someone speak to Alastair's comments?

<mbgower> David M: The requirements were driven by the epub team. I've tried to capture it in SC speak. Originally it was 2.

<mbgower> David M: The first one was proposing that if there's a reference that has a fixed layout, the person should be able to navigate to those fixed points.

<Zakim> AWK, you wanted to ask about definition

<mbgower> David M: This is saying if a fixed reference point exists, there's a way to get to it.

<mbgower> AWK: I had a question about fixed reference points definition.

<mbgower> AWK: The SC makes sense to me regarding page numbers.

<mbgower> AWK: But it ended up talking about fixed reference points. I worry about our interpretation not being sufficiently crisp

<mbgower> AWK: Does it make sense to just say 'page breaks'?

<mbgower> David M: That was the original language. Shawn from Google was quite adamant he didn't want it that restricted.

<mbgower> David M: Mike Gower said 'why not call it a fixed reference point'. Personally I would have preferred to see page numbers in here, and I agree 100%

<mbgower> AWK: I remember that conversation as well.

<mbgower> Matt: I was going to speak to the same point. It was originally page break locators. I think we've moved too much away from that. It is very general.

<david-macdonald-2> https://docs.google.com/document/d/1xyxJuz--YltVAlDKRPkjZI6buFSuRih4z1d6vPjFLJM/edit#heading=h.n3esw3alr309 Page break locators

<mbgower> Matt: It becomes confusing if you just have IDs in sections. Do you use a TOC? A page list? I'm concerned it's a little too broad. It may be hard to understand when it applies and what it applies to.

<mbgower> George: I don't know if a person in a publishing industry would recognize that as page number

<mbgower> PeterKorn: I'm curious how this interacts with SCs that require that text can Reflow and other SC that allow the customer to change the text spacing, which would change the page number

<mbgower> PeterKorn: How does a fixed layout document meet that?

<mbgower> George: In the epub, there is a requirement for the content to provide the boundairies for these page break locations. That does not relate to the number of screens the device may have. You should always be able to go to page break 85, which is the reference in the print book. So if a student is in the classroom and the teacher says 'go to page 85' everyone can go to the same location.

<mbgower> PeterKorn: Maybe this gets to the idea of a timestamp. In different published versions, how do you decide where they are?

<mbgower> PeterKorn: Do I need to carry forward the same numbers?

<mbgower> George: The metadata IDs the publication in question.

<mbgower> George: Your book references whatever is specified in the metadata.

<mbgower> PeterKorn: Maybe I need to talk to you more offline. I don't see how this works in practice.

<mbgower> PeterKorn: It feels like there's a lot of questions about how this would work in practice.

<Avneesh> +1 to dvid. this discussion isa bout AAA SC

<mbgower> David M: There are 2 SCs that are being proposed. The one you are talking about is the AAA.

<mbgower> David M: The one at A is saying if there IS a fixed point, there is a way to get there. In most ebooks now, there are page numbers on many ebooks right now.

<mbgower> PeterKorn: The link that I saw from the chat...

<mbgower> David M: That's the AAA.

<david-macdonald-2> https://docs.google.com/document/d/12Zn0_TGcqrM-L_wb0PIFHM4AnHJ64wPsucZyRGlf2Fg/edit#heading=h.n3esw3alr309

<mbgower> PeterKorn: Even if it's at AAA, recognizing it's challenge, we should still have a good understanding. If it's impossible to do, it doesn't seem like a useful contribution.

<Zakim> mbgower, you wanted to say that you address what it applies to in techniques

<AWK> MBGower: the techniques will provide the "how" for meeting the SC - it may be a TOC or page numbers, or something else

<bruce_bailey> AAA is okay so long as *some* technolgy supports it

<Zakim> AWK, you wanted to speak to page question

<mbgower> David M: It's been a few months since we looked at this. We came in with 2. The A was 'if you ahve them, make them findable' . The AAA was you should have them.

<mbgower> AWK: Without talking too much about AAA, how would you meet the first version?

<mbgower> David M: I'd invite anyone from epub to just jump in. I don't want to misrepresent them.

<mbgower> David M: If I understand them correctly, having the page list is what we're after. George?

<mbgower> George: Yes, reading systems today have a go to page and you just type in the number and you're there.

<mbgower> PeterKorn: It doesn't have to marked in a physical sense.

<mbgower> PeterKorn: We have a marker for page break locations. The AAA would require the markers themselves. Or maybe I'm misrepresenting?

<mbgower> AWK: In the text there is now, one is you have to be able to get to the fixed refernce points. The AAA is you have to be able to get there in the reflowable version.

<mbgower> David M: We're assuming that there is a default view of the actual book. If that default view has breaks in it that are visual or structural, there should be a way to get to those.

<Zakim> bruce_bailey, you wanted to ask about scoping to mark languages

<mbgower> Brooks: I had a couple of points. To David's point, I think it's important that the users understand what version of a document they have.

<mbgower> Brooks: Having that information available to me should be part of this.

<mbgower> Brooks: The other issue is what is required. What are we asking content authors to do? Build a page of links that go to location markers they've already put in, or just to allow the user agents to get to them.

<mbgower> George: Right, the page break locator needs to be in the document.

<mbgower> George: When I review these 700 page documents, asking the user agent to walk through the document and build an index dynamically is a burden. So what we have in teh epub spec is a requirement to put in a list of pages. But of course a reading system could do that.

<mbgower> Avneesh: Regarding the difference between A and AAA. The latter is talking about an equivalent. Level A is talking about putting in the locators.

<mbgower> Avneesh: It is not necessary to have fixed locations at A.

<mbgower> Avneesh: AAA is not a prereq. We should treat them differently.

<mbgower> Avneesh: We have experimented. It's not always epub. Sometimes HTML5. It's not reasonable to ask it of a user agent.

<mbgower> AWK: So waht I heard is that AAA needs to have a relation between the master copy and the electonic version

<Zakim> Bruce, you wanted to ask about scoping to mark languages

<mbgower> Bruce: Thanks for attending. I wanted to ask if adding the context of markup language would be appropriate.

<mbgower> Bruce: That may help with the term 'fixed reference point'

<mbgower> Bruce: I wanted to encourage limitation of scope for AAA. It's such important functionality, that I'd like to get it to AA.

<mbgower> Bruce: If it was contained to say markup langauges, in my view it could be contained to AA.

<mbgower> AWK: We'll have to discuss appropriate level later.

<david-macdonald-2> I changed fixed ref point definition to "Structural navigation markers" instead of "Visual or structural navigation markers"

<mbgower> PeterKorn: I'm still trying to figure out how this is operationalized in practice. What happens if I generate sets of fixed reference points at different times?

<mbgower> George: This is used in a range of different methods. Publishers will put in an index. They love these refernces because they can jump to these locations.

<mbgower> PeterKorn: In the index case... The defintion of fixed location... If I don't use page numbers, is that a fixed reference point?

<mbgower> George: There are two ways. One is to the page locator. The other they go to the ID of the paragraph. You need to be able to get to those places. So it seems to me to be level A.

<mbgower> George: I like the AA idea. It's implemented in school books.

<mbgower> PeterKorn: I'm still trying to understand how this works operationally.

<mbgower> PeterKorn: At some point an electronic version gets published. It is laid out at a certain font size.

<mbgower> PeterKorn: Do I need to cache this so that when the teacher says 'go to page 7' I can go to the right location. How does fixedness fit into this?

<mbgower> George: The fixedness is a spot in the print publication where the page breaks. That's a doc_pagebreak in the aria vocabulary. That's waht that object is.

<mbgower> George: It can be used by publishers when they create their titles, from either the page list or the index.

<mbgower> George: In a TOC in an Apple book, you can toggle between the number of screens versus the number of print page markers.

<mbgower> George: IN a Kindle you can tab between number of screens, number of time to read, or fixed print locators.

<mbgower> PeterKorn: It is when there is a print rendition that's known. You talk about an ISBN number.

<mbgower> PeterKorn: I print it and hand it out to my students. Later I hand it out to a different student.

<mbgower> George: What we do in the epub is at any point in time they say "i'm done", it creates the boundaries and indciators and inserts them in there. That's the best way a professor could do it.

<mbgower> George: Not all techologies are doing as good a job with page break locators as we'd like.

<mbgower> George: If the author changed the font face/size, that would change all the page numbers. Youd' just regenerate.

<mbgower> PeterKorn: But for versioning, how do you keep in synch?

<mbgower> George: The metadata identifies the version.

<mbgower> George: If you're going to change one document, you need to change the other.

<Zakim> mbgower, you wanted to say index is perfect example of why page number is too restrictive

<mbgower> George: I totally agree with this notion of using more things than page numbers.

<Zakim> AWK, you wanted to ask about extent. I can see this applying to pages and chapters without a problem, but what about headings and sections?

<mbgower> George: We need more variety than just page break locators. There are many applications for this. Tons.

<mbgower> AWK: Which brings this to my question, which is 'to what extent?'

<mbgower> AWK: In a long-form book, there are chapters. I don't see anyone disputing that.

<mbgower> AWK: Are we also saying there has to be links to paragraphs. What is actually required here?

<mbgower> Avneesh: Do you really want to go into such deep detail?

<mbgower> Avneesh: It depends a lot on the author based on what he decides. It could also be landmarks.

<mbgower> Avneesh: There may be cases of pointing to diagrams, for instance.

<mbgower> AWK: I think the problem is that when people look at the criterion and they are evaluating web content, they are going to apply the SC in whatever way they can. We want to avoid the scenario where someone says 'you don't have enough'

<Zakim> mbgower, you wanted to say the document defines it. If the document doesn't define fixed points, they don't have to do anything

<bruce_bailey> As one good model IMHO is the Federal Registers. Presentation is web-centric, but with fair deference to the print version. Every heading and every paragraph also gets it own ID.

<bruce_bailey> Example: https://www.federalregister.gov/d/2017-00395

<mbgower> AWK: I'm struggling with what's written in proposal 1 and 2.

<mbgower> AWK: Number one is talking about where they're present.

<mbgower> AWK: I'll add that based on what you just described, it almost sounds like the requirement is links aren't broken.

<Zakim> Brooks, you wanted to ask Don't we need to require providing document version information along with page/location indicators?

<mbgower> Brooks: I was just going to say that when I look at the benefit and the intent, it is to allow people to agree on the scope of content they're looking at.

<mbgower> Brooks: It's a pretty important concept when you are talking about sharing information.

<mbgower> Brooks: If that's the true intent, then I think the page number must also be included.

<JF> +1 to Brooks

<mbgower> Brooks: You have to have that information available in order for folks to be able to share info.

<mbgower> David M: Ideally in the second version (AAA), the proposal says 'where content is presented in fixed version. So does it have canonical numbering?

<mbgower> David M: If there's a fixed format presentation, then the second version requires you to put page numbers on those points.

<mbgower> David M: The single A one says that if you have fixed points in your document, then you need a way to get there.

<mbgower> David M: The second one says you have to put them there. The first one says, if the locators are there, then there needs to be a way to get to them.

<mbgower> David M: The definition has brought a lot of discussion. To widen it out the way Michael wants, I agree with, but it's harder.

<mbgower> David M: We could remove the word 'visual' but...

<mbgower> David M: We could say structural instead.

<mbgower> David M: I think that's what the epub team is trying to capture. If they are they, make a link.

<mbgower> AWK: Matt's on the queue, then we'll wrap up.

<mbgower> Matt: For me, one of the questions is the 'fixed' page. Is it relevant to a certain document or not? IF not, then any reference in HTML is fixed.

<mbgower> David M: The level A is not referring to a certain document.

<mbgower> George: The notion of having markers is very useful.

<mbgower> George: People on kindle or apple books can get to the same place.

<mbgower> AWK: Obviously some things we need to sort out.

<mbgower> AWK: HOpefully this helps. Clearly there is a problem and a problem with how we're trying to address it.

<Detlev> one sec

<mbgower> trackbot, end meeting

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/12/03 18:05:26 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/Abnish/Avneesh/
Succeeded: s/George: The link/PeterKorn: The link/
Succeeded: s/mark languages/markup languages/
Succeeded: s/ahve/have/
Succeeded: s/ISBM/ISBN/
Default Present: AWK, Chuck, Raf, Fazio, janina, Rachael, Brooks, Katie_Haritos-Shea, JakeAbma, JF, PeterKorn, johnkirkwood, MarcJohlic, mbgower, bruce_bailey, Avneesh, david-macdonald-, Detlev

WARNING: Replacing previous Present list. (Old list: AlastairC, bruce_bailey, janina, JakeAbma, Jennie, Chuck, Rachael, KimD, Detlev, JF, Raf, MichaelC, Laura, Brooks, johnkirkwood, Jon_Avila, Katie_Haritos-Shea, mbgower)
Use 'Present+ ... ' if you meant to add people without replacing the list,
such as: <dbooth> Present+ AWK

Present: AWK Brooks Chuck Fazio JF JakeAbma Katie_Haritos-Shea MarcJohlic Rachael Raf janina johnkirkwood mbgower bruce_bailey Avneesh PeterKorn david-macdonald-2 Detlev
Found Scribe: JustineP
Inferring ScribeNick: JustineP
Found Date: 03 Dec 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]