AGWG Teleconference -- 19 Oct 2021

<laura> Scribe: Laura

<Rachael> scribe list: https://www.w3.org/WAI/GL/wiki/Scribe_List

<JF> Pesent+

<AWK> +AWK

new members and topics

RM: any new members?

Laura Miller introduced herself.

<Chuck> Welcome aboard Laura

TPAC registration

Rm: Tpac is going on right now. Register if you intend to attend. Need to register in advance.

<sajkaj> https://www.w3.org/2021/10/TPAC/#participation

Queue management

<sajkaj> Above link for TPAC registration

rm: chairs have been hearing concerns.

<alastairc> CEPC - https://www.w3.org/Consortium/cepc/

<Rachael> We’ve had numerous concerns raised about peer behaviors, possible bias and possible CEPC infringements. This had led us to realize that many people are experiencing the environment as highly toxic. As chairs, we have a fundamental responsibility for the environment so we have been carefully evaluating our role and believe that our efforts to date have not been effective at resolving the issues. We have requested that an outside mentor come

<Rachael> to observe meetings and coach us in improving.

rm: chairs have heard that their viewpoints have not been heard.

<Rachael> We have been hearing concerns from individuals that their viewpoints are not being heard or addressed. There are many viewpoints being expressed, from a wide variety of perspectives. As chairs, we need to actively navigate theses viewpoints and perspectives during the meetings. To be more effective, we are changing how we handle surveys and queues to better ensure everyone has an opportunity to express their viewpoints and be heard

rm: will be changing how ques are handled.
... will go through surveys first.

<Rachael> We will be handling survey-based topics by summarizing the survey responses prior to opening the queue. Then we will go through all comments. After survey commenters have all spoken or their comments been read, we will ask if we missed any survey responses. We will then identify topics based on the responses and open the queue for wider group discussion based on those topics.

rm: comments and concerned about WCAG 3.
... want to map concern to actions.
... will be having a proposed process. And having a survey.
... asking to everyone to be respectful.

<Rachael> There have also been comments and concerns raised about the WCAG 3.0 issues, and the fact that these issues have not yet been responded to. We are in fact working on crafting responses by the very work we are facilitating. To create more transparency, we have mapped all issues to the schedule, content subgroups, or editorial fixes such as typos. We will discuss the schedule later this meeting and discuss a proposed process using that uses the

<Rachael> schedule and the proposed markup for documents in detail next week. We will surveying it before discussion.

<Rachael> Finally, solving the environment and culture challenges we are experiencing cannot come solely from chairs. Some factors and solutions go outside of our domain. To that end, we again ask that everyone remain respectful and assume good intent from each other in this meeting and other subgroup meetings. We have a number of difficult technical discussions coming up and it is critical that we focus on the technical issues and avoid making

<Rachael> disagreements personal. If you have not yet read the CEPC, please do so.

rm: critical to concentrate on tech problems

WCAG 2.x design update roll-out

mc: sent an email on design update.
... about ready to deploy it.
... major issue on collapsed sections.
... an easy change if it is a problem.

<MichaelC> https://github.com/w3c/wcag/pull/2012

<alastairc> Techniques: https://draft-wcag-redesign.netlify.app/techniques/

<alastairc> Understanding: https://draft-wcag-redesign.netlify.app/understanding/

mc: intent to take 2.0 and publish with a redirect.

Bruce: seems WAI docs files named with symbols.
... hoping we can push back on that.

<Wilco__> +1 not a fan of that

Mc: could take it up.
... invite bruce in another venue.

<alastairc> AFAIK the URLs are independent of the design update, the files won't be moving based on this change.

Rm: charts will coordinate.

jf: like the new look. Comment on use of red/green.
... rebranded techniques. What happens in 3.0 for methods.

Mc: WCAG 3 may go in a content management system.
... would be completely new.

WCAG 3 - Schedule (40 min)

<Rachael> zakimm, take up item 4

WCAG 2.x design update roll-out

<Lauriat> https://raw.githack.com/w3c/silver/600a2fda8a624489f2d63840abdddbd6af0f7b05/guidelines/index.html#guidelines

WCAG 3 - Adding placeholder guidelines

Shawn: link to rendering of a pull request.
... came from a few requests.
... gives an overall sense of what is to come.
... link foes to the guidelines section
... they are placeholders. Will need to give a warning.
... gives a sense of the guidance.

<JF> will there be any further design changes? Concern over failing to meet 1.4.1 & 1.4.11

Shawn: gives a preview.

Jf: Uses color alone. And afraid it doesn't meet contrast requirements.

<AWK> Would be better if the mouse cursor changed when hovering.

Jf: will put in issue.

<JF> ACTION: JF to file github issues on 1.4.1 & 1.4.11

<trackbot> Created ACTION-353 - File github issues on 1.4.1 & 1.4.11 [on John Foliot - due 2021-10-26].

Jf: note the draftiness of this drafts.

Shawn: note the draftiness of this drafts.

Rm: need to work out the process for this.

Jemma: finds structure confusing with external link of "outcome, details, and method" under each guideline. .

shawn: some of the links don't work yet but will.

<alastairc> Would be good to remove or nullify the links that don't work.

Js: user generated needs to be differentiated. Think about how.

<Lauriat> +1 to Alastair, just thinking the same

shawn: just for placeholders. Haven't got to styling yet.

Awk: where we are in the overall discussion?

<Jemma> My question was about external link of "outcome, details, and method" under each guideline . How is this external link can be strucutured well so that it can be well connected with each guideline conceptually. Current structure was very confusiong to work as the subgroup member.

<alastairc> This is specific to the guidelines aspects, it was something we had wanted to do anyway, but it also lines up with the previous discussions on process & docs.

rm: we have not had the process discussion yet. That will be next week.

<Zakim> mbgower, you wanted to say I was surprised the simple text summaries were styled very similar to the other collapsed sections

Shawn: just placeholder for the guidelines.

mg: surprised that simple text summaries are styled very similar to the other collapsed sections
... make sure it is consistent .

Gv: discussion on placeholders. Issues and barriers.
... point of clarification.

<Jemma> I like the table of content structure. It is very clear.

Rm: that will be surveyed next week. It is a PR.

GV: good to look at.

<Jemma> +1 to shawn

WCAG 3 - Schedule (40 min)

Rm: been revisiting the process.
... now we are going to talk about the Schedule.

<Rachael> https://docs.google.com/spreadsheets/d/1yzR1H0SnNFRELGchb_BJr4Necsrj6xVjDF1n7Tc0kTc/edit#gid=0

Rm: went through and estimated time for topics
... First column Setup Foundational Work - Proposals (Outside Joint Meetings)
... Issues column lists issue numbers
... a lot of concurrent work.
... timing is mapped out.

(Talks through the spreadsheet)

scribe: based on these estimates a late 2024 CR.
... longer timeline that what we wanted.

Jf: appreciate this.
... techniques, methods, and styling. Lots of dependencies.

Rm: around restructuring. Will be iterative.

<alastairc> The first "Rework methods" was a chunk of work, it isn't saying that the methods are done!

Rm: can be adjusted. These are the chunks we need to work though.

Jf: objection to mostly complete.

katie: bringing a pm in is a good thing.
... this is great. More realistic timeline than we had before.

<bbailey> +1 to KHS comment, this is much good work

Peter: helpful to have early straw man proposals.

gv: as soon as you say something is complete, it sets up expectations.

<jon_avila> A straw man is defined as "an intentionally misrepresented proposition that is set up because it is easier to defeat than an opponent's real argument."

<Zakim> Jemma, you wanted to suggest add dependency deatils such as "finsh to start", "start to start", "finish to finish" or "start to finish"

gv: show early drafts are indeed early.

Jemma: PM is a brilliant idea.
... need to clarify dependencies.
... need to add dependency details.

Rm: have we missed anything?
... such a big list. Need to make sure it is comprehensive.

<Jemma> +1 to share milestone publicly.

Gv: if you follow the issues will they be linked to the documents?
... need to be connected.

Ac: maybe build milestones in GitHub.

<Jemma> great job!

rm: can export to excel if needed. Just ask the chairs.

Katie: one document to rule it all would be useful

<sajkaj> Excel export probably useful

WCAG 2.2 Focus appearance (1 new question added) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

<PeterKorn> Thank you Rachael! Bye for now.

What is a complex shape? #2050

<Rachael> https://github.com/w3c/wcag/pull/2051/files

rm: awk has made a PR. https://github.com/w3c/wcag/pull/2051/files

Ac: not seeing all changes in the PR.

<Zakim> alastairc, you wanted to add the change since last week

Ac: (reads his survey comment)
... simplifies definition.
... I think we got through all of the comments last week.

<alastairc> "continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest."

gv: why was "complex" added?

Mg: most are rectangular.

<Ben_> q

<Zakim> JF, you wanted to ask about 'polygon' (ref: Chuck)

Mg: but didn't make sense for the definition to retain that word.

Jf: raise the notion of polygon last week,
... possibility of polygon at the design level.
... may add clarity to add polygon.

<Zakim> Chuck, you wanted to support 'polygon'

Chuck: reservations on using polygon. But did research and may not be harmful.

<Ben_> Is it possible for Chuck/JF to link to defintions within the W3C of "polygon"?

gv: May not need an A and a B.

<Zakim> alastairc, you wanted to reply about polygon

<GN015> As I still vote for circles, I suggest (basing on Mike's suggestion): "continuous line forming the boundary of a shape not including shared pixels, or the <a>minimum surrounding shape</a>, whichever is shortest. For example, the perimeter calculation for a rectangle is 2h+2w -4, where h is the height and w is the width and the corners are not counted twice. The calculation is the same for a bounding box. The perim[CUT]

Ac: polygon does not account for curves.

<GN015> Sorry, I have to step out an can't speak to my suggestion.

Ac: want to simplify the definition.
... Different shapes have different surface areas.
... want to simply.

Gn: would like to have circles.

ac: nothing here prevents circles.

<GreggVan> or oval

scribe change?

<GreggVan> good to include that as an example then

Gn: I read it in a different way.

<Zakim> Chuck, you wanted to ask for a scribe change

<GN015> I feel the current requirement says to measure around the UI element shape, not the actual focus indicator shape. The first one would exclude a circle focus indicator around a star UI element, to my understanding.

<GN015> Bye

<Chuck> scribe: Chuck

AWK: Alastair represented well. I felt that this was adding confusion to say "complex".
... Reading Gundula's comment in IRC, sounds like her concern is she wants to put a circle around a complex shape, rather than a same thickness as a rectangle.
... She's right, that would be a difference between the too. But that circle could be thicker to make up the difference between area and square.
... Or other options for that. I want to emphasize that we get so many comments about very fine grain language, this seems an obvious choice.
... Either the perimeter is around the box, or...

<Zakim> GreggVan, you wanted to say a good way to remove ambiguity with regard to circles or ovals as highlight would be to just include them in an example

GreggVan: To what Andrew said, Alastair has the language, we just need to allow the circle idea. If you make the circle bigger, the perimeter will increase.
... You could, but makes more complicated, that both sentences are simple sentences. If we get a chance to make something simple, we need to do that.
... By bounding or a simple shape instead of rectangle, that would allow rectangles or ovals. That to me raises the question of what a simple shape is, and harder to read.
... Maybe an example using a circle or oval.

Alastair: From Gundula's comment, we need to be careful which we are talking about. Component could be a star or rectangle, or focus indicator matches the underlying shape or a different shape. We don't restrict either.
... This definition is about calculating how big the focus indicator should be. If you've got a star, that could be quite complex to work out the perimeter.
... The perimeter is bigger than the rectangle, but that doesn't stop you from putting a circle around the star. Do you want to make the star thick enough? You can still use a circle.

<AWK> +1 to Alastair

Rachael: Proposing resolution.

<GreggVan> perfect

<Rachael> proposed RESOLUTION: Accept revised wording and circular focus examples

<GreggVan> capture that and put it into Understanding doc

<Rachael> proposed RESOLUTION: Accept revised wording and add circular focus examples to understand doc

<AWK> Can we see Alastair's change again?

Alastair: The example would go into the understanding doc, not in the defintion.

<alastairc> "continuous line forming the boundary of a shape not including shared pixels, or the minimum bounding box, whichever is shortest."

<AWK> great, thanks.

Alastair: AWK is looking for revision...

Rachael: Pasted in.

<Ben_> +1

<mbgower> +1

<AWK> +1

<Ryladog> +1

<JF> +1

<laura> +1

<ShawnT> +1

<GreggVan> +1

<alastairc> https://github.com/w3c/wcag/pull/2051/files#diff-fa113f642f74d4e98c8ff890a7008777b417db8c5b7a4eb222349c58538bc326

<MarcJohlic> +1

<Wilco__> +1

<Rachael> +1

<OliKei> +1

<Francis_Storr> +1

<bbailey> +1

RESOLUTION: Accept revised wording and add circular focus examples to understand doc

Focus indicators for large editing areas #2017

Rachael: Next topic.

<Rachael> : https://github.com/w3c/wcag/issues/2017#issuecomment-926004402 saying no

Rachael: Should large editing areas have an exception? Draft response says "no"

<bbailey> sorry, grammer: whichever is shortEST or whichever is shortER

Rachael: Question to start... 8 people agree, 2 agree with adjustments, 1 wants something else.
... Gundula agrees and wants to keep requirements. MG wants to keep text areas, agrees response.
... <reads Oliver's response> Keep requirements for focus consistent...

Oliver: That's my opinion.
... Focus ring around large object allows to orient where focus resides. This would help provide reasonable focus indication for position.

Rachael: Should we add to understanding, or elsewhere?

Oliver: Yes, good enough.

<Rachael> https://github.com/w3c/wcag/pull/2081

Rachael: Alastair, you agreed with some adjustment, created a PR. Can you speak to yours?

<alastairc> Some components may be very large, such as editing areas in a Content Management System or code-editor that fill the screen. There maybe some circumstances where a large editing area may not be as useful, however, it may still be beneficial to some. There is no exception for this scenario.

Alastair: I added a paragraph to understanding.
... Just documenting this decision.

Rachael: Wilco you had something else.

Wilco: I'm not following why we wouldn't consider this. It seems a legitimate use case here. If editing area is entire screen, where do you expect to see the focus indicator?

Rachael: Did I miss anyone's response in the survey?
... I see 2 topics. One is discussion is if its valid, and 2nd was the addition to the understanding of both paragraph from Alastair and a comment about carret.
... Did I miss a topic?
... Starting first topic.

<Zakim> mbgower, you wanted to say that user agent defaults show a focus around text areas in every browser i tested. So I don't think it needs any kind of exception

MG: I investigated, every text area I tried, every browser I tried put a focus indicator around it. It's already passing in the wild, we need not make an exception.

JF: I noticed in the issue list Bruce raised this, a large text area takes this, don't I get a flashing cursor in the control?

Rachael: That's our 2nd topic.

Alastair: I do think to John's comment it goes to validity. Around text inputs, where focus indicator, if you just have a blinking cursor we wanted to capture that.
... That's different from a viewport editing area. Your focus point is within the component. The letter of the SC is that the entire editing area would have a focus indicator.

<Zakim> JF, you wanted to note that asking today for more than native user-agents deliver is problematic

Alastair: It's whether or not we required that.

JF: I don't disagree, I'm concerned today, is that the native behavior today in browsers? If we ask for something that isn't there by default we may have an issue.

Alastair: MG said by default text areas will provide outline. The circumstances is very custom apps like code editors, document editors.

<AWK> Google docs also?

<JF> +1 to Wilco

Wilco: There is a native component that isn't fine. Content-editable, gives you a cursor.

<Zakim> mbgower, you wanted to say it is not dissimilar to the target size issue

<alastairc> I'd put contentEditable in that 'custom' category, you really have to code everything up from scratch in that case.

MG: I opened this before, similar to target size. Thinking about situations where you are trying to pick up color, and you get a massive area. Every part is a target.
... Same thing is happening here with a text editor. Anything that makes the entire UI the thing that has focus. Maybe we can use similar language from target size.

Alastair: I don't think John's here, he had a robust reaction "please don't put in an exception".
... I wanted to say that it came up on the thread, and I wanted to represent it.

Rachael: We have strong majority in survey to say "no".

Wilco: Willing to go with majority.

MG: Note, for something like full page editors, they would have to focus around the entire sheet. The actual implementation would put a focus indicator would be around the entire page.

AWK: That's what I was thinking. For any document creation software, web editor, code editor, document editor, we run into situations like with...

<bbailey> https://github.com/w3c/wcag/issues/2017#issuecomment-920891794

AWK: If you are using an editor that allows you to add text and other objects. Text, text area, image. You can focus on any of those. I worry that its more complex.
... Code editor is probably easiest situation. One block of text. If you've got a web app or page whos primary focus is the gigantic area, that may create distraction for people. Exception may be waranted.

Rachael: When I interact with a full page doc editor, I do get a focus indicator around the large area. Is the blinking focus where we are typing meeting this criteria where it is?
... Focus is where user is typing at that point. It's meeting it, just not a traditional focus indicator.
... Put focus at top, and then tab, I get a focus indicator around the entire "thing". Including toolbar. Finally focus falls in the typing zone.

<Zakim> bbailey, you wanted to aske if this is Jon's comment

Rachael: At that point focus is in text area. Is this really an exception?

Bruce: I want to double check about Jon Avila's comment. I do worry about having a requirement that is "silly". A full screen app, should have an exception.

Alastair: that's one of Jon's comments. It still helps essentially. Rain says helps to have a focus indicator. I think it was reasonable support for it as a benefit.
... Trickier question is what is a control in this context? The entire page could be considered the control, and content within the control can be rather small.

AWK: To add to that... responding to Rain, sure, it might be helpful to have a focus indicator. In a complex document, you definitely want a focus indicator if you put focus on image. Does focus need to go back to entire doc if not on an object in the document?

<alastairc> Um, I'd find it helpful to know when the canvas is focused :-)

AWK: In ppt slide, tabbing between 6 or 50 things in it, you are always on something. Each text has it's own little frame. You never need to focus the slide. In a word document that is not necessarily true.
... Web based editor, or photoshop, image editing tool on web, you may have 100s of items. You may be jumping between frames and objects a lot. This may create more confusion.

<bbailey> i agree that being able to know if the canvas has focus or not is important

Wilco: Last comment... I wonder if we need to be more explicit between focus and cursor. Seems to be that where the caret is, that's not necessarily where focus area. Focus is text area, cursor is within that component.
... That seems to be the focus indicator. Seems a thing we should work on.

Rachael: To respond or clarify, when I tab through, my focus lands on the overall area, and my next tab stop is within the area. Cursor is different in the landing point. It seems odd if the outline on the outer shell, and next tab stop is within the field.
... Repeating seems odd.

MG: When I open this issue, I wonder if we can get leverage if we discuss what a user interface component is. Is there an idea where a canvas ceases to be a component and becomes a container?

<Zakim> Chuck, you wanted to suggest trying a scribe change again, briefly.

<KarenHerr> scribe: KarenHerr

rachel: back to defining a UI component

Alastair: similar to discussion on target size. sliders, color pickers, editable areas

<mbgower> editable areas that are not UIC components

alastairc: correction -not AWK - alastair

mbgower: editable areas that are not ui components - a part of the content that is perceived by a user a s a single control

<AWK> +1 to Mike - that works. Could add that clarification to U doc

<bbailey> +1 to MG suggestion

<Chuck> +1 to MG

alastairc: once it is a canvas with multiple functions, then it wouldn't be a user interface control

<alastairc> https://w3c.github.io/wcag/guidelines/22/#dfn-user-interface-components

Rachael: seeing general support - do we need a survey?

alastairc: we'll have to bring some text back

<Chuck> proposed RESOLUTION: We don't consider this an issue, and we will bring some text back

<Rachael> proposed Resolution: Agree that we don't think this is an issue but need additional text around defining UI component

<ShawnT> +1

Rachael: proposed resolution - agree need additional text defining ui components

<Chuck> +1

<alastairc> +1

<Rachael> +1

<bbailey> +1

<OliKei> +1

<Aimee_U> +1

<GreggVan> +1

<AWK> +1

<mbgower> 0 fine, just not the wording i would have used :)

<JF> +1

Rachael: we will come back with more text

RESOLUTION: Agree that we don't think this is an issue but need additional text around defining UI component

Focus appearance should be in Perceivable

Rachael: 2037 raised by jake
... options: keep focus under operable, move to perceivable (distinguishable)
... 7 who are for moving, 2 are not for

bbailey: i change my vote - this is about operable, not perceivable

alastairc: it was placed in operable just because of where 2.4.7 was.

GreggVan: everything under perceivable has to do with operation. you need to perceive in order to operate. still seems to be perceivable

mbgower: overall problem. if you cannot see it, you cannot operate it. impossible to separate for keyboard user

<Rachael> strawpoll: Option 1) Keep focus-appearance in Operable Option 2) Move focus-appearance to Perceivable > Distinguishable

Rachael: strawpoll

<mbgower> 1

<MelanieP> 1

<Chuck> Option 1

<sarahhorton_> 1

<ShawnT> 1

<bbailey> 1

<Rachael> 1

<Francis_Storr_> 1

<GreggVan> 1

<JF> 1 - Operable

<Ben_> 1

<OliKei> 1

<Aimee_U> 0

<Chuck> Mine is not strong either.

<Chuck> prefer 1

<GreggVan> I changed to 1 - because that is where keyboard operators will look for it

<Chuck> KarenHerr: I am ok with keeping it.

<GreggVan> prefer X but can live with Y

Karen: I won't object to 1

RESOLUTION: Leave focus appearnance operable

RESOLUTION: Leave focus appearance in operable

<JF> +1

<Chuck> No objection

RESOLUTION: Leave focus appearance in operable

Need more info on adjacent contrast #1929

<GreggVan> "any objection to unanimous consent "

<Rachael> https://github.com/w3c/wcag/issues/1929

<Rachael> https://github.com/w3c/wcag/pull/2060/files

alastairc: results were fairly in agreement

<Rachael> https://github.com/w3c/wcag/pull/2097

Rachael: we have 8 people who agree with the change.
... one pull request with an update from mbgower
... have i missed anyone's comment?

alastairc: reason for update bring focus appearance understanding document into line with non-text contrast

GreggVan: 2060
... line 290 visual focus indicator must have sufficient contrast to adjacent colors
... contrast of thing being focused and background

alastairc: focus indicator must have sufficient contrast against adjacent colors

GreggVan: means it need to have sufficient contrast inside and outside of focus indicator? (inner and outer edges) correct?

alastairc: that would be too simple an explanation of it
... what's in the non-text contrast. here - brief summary of what non-text contrast is how focus appearance relates to non-text contrast
... initial para should be we do have non-text contrast and focus visible and how it relates
... because of lack of size requirement in non-text, we do have many situations

Rachael: outside of meeting, review the para on non-text contrast and we will talk about it outside this set of changes

<alastairc> This is where we talk focus indicators through in non-text contrast: https://w3c.github.io/wcag/understanding/non-text-contrast.html#figure-two-star-ratings-failing

mbgower: still in development. does this improve existing one?

<Rachael> proposed RESOLUTION: Accept the updates in PR2060 and 2097

bbailey: next question - look at survey for next week.

<GreggVan> +1

<Chuck> +1

RESOLUTION: Accept the updates in PR2060 and 2097

<ShawnT> +1

<GreggVan> +1

<Ben_> +1

<bbailey> +1

<Rachael> +1

<OliKei> +1

<alastairc> +1

<JF> +1

<mbgower> +1 and patrick's suggested modification is fine with me too

<bbailey> https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq23

<bbailey> only 3 replies !

<alastairc> Good link to bookmark: https://www.w3.org/2002/09/wbs/35422/

Rachael: last thing. not enough thing to start another issue. new method if queueing - read surveys in advance of meeting and add comments

<ShawnT> Thank you

<Zakim> bbailey, you wanted to ask people to look at NEW question 5 in this survey

<Chuck> I have to leave promptly and cannot linger in the call today.

<Rachael> me thank you Chuck, have a good day

<Detlev> presnt+

- DRAFT -

AGWG Teleconference

19 Oct 2021

Attendees

Contents

new members and topics

TPAC registration

Queue management

WCAG 2.x design update roll-out

WCAG 3 - Schedule (40 min)

WCAG 2.x design update roll-out

WCAG 3 - Adding placeholder guidelines

WCAG 3 - Schedule (40 min)

WCAG 2.2 Focus appearance (1 new question added) https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

What is a complex shape? #2050

Focus indicators for large editing areas #2017

Focus appearance should be in Perceivable

Need more info on adjacent contrast #1929

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output