<Chuck> agena?

New members and topics

<Detlev> I can scribe

<Jaunita_George> I can scribe the second hour

<Detlev> scribe: Detlev

Announcements and Reminders

<Jen_G> Apologies, I am still working on accessibility issues for scribing. I know other blind people do it, so I just have to get it sorted out.

<Chuck> jen_g, you are certainly welcome to pitch in if you want to, but please don't feel obligated.

Rachael: surveys move towards agreement, higher quality comments

<AWK> +AWK

Rachael: github issue led to personal attacks - that's now handled by chairs. Don't do it, there are consequences

<Rachael> https://www.w3.org/Consortium/cepc/

Read the policy

<Rachael> [email protected]

scribe: if subgroubs wagt to present results mail ag-plan so that can be scheduled

Retrospective - Chaos has managed that process

Chaals!

Some people have have commented - please give feedback

Read the Google doc (link above)

Ch: are you familiar with the doc? (Ch asking individuals)

(My Mac always turns C h a a l s into chaos)

To question of ch: Mixed results some have read it, some not yet

Janina: Have issues accessing Google docs

Some people read it earlier need to catch up on the comments

<chaals> https://docs.google.com/document/d/1O5kkM1LU9Qokt3GnbQrvUA7Hr8v-GGDAIfhoNg3zEDI/edit#

Ch: still asking individual participants of the call if they read the doc
... most have seen the doc, some have nt yet read comments
... have 2 questions: 1. Are things getting better? There have been several meetings since this was raised?
... are people feeling that there are outstanding problems we need to focus on explicitly

Janina: Recalling last week'S call, realizing that the process is far away from getting to a CR - we are too much concerned with details

<Zakim> chaals, you wanted to make explicit Juanita's comments

Janina: too many comments to go through, not enough time

<Judy> [Judy: Side comment -- we have a good contact and responsiveness from Google Doc team now to address accessibility problems. Would like side input from the people who have mentioned issues (Janina, ShawnT, Leonie), and anyone else.

<Ryladog> +1 to Janina's comment

Ch: Comment Juanita about num of meetings, how to catch up
... find meetings hard work, avoid if possible - followed the minutes, talked to people, not the same perception always
... discussions need to be thoughtful, respectful, need to get through the workload
... the group seems to agree, that's a good thing
... people make an effort to make that thoughtfully, moves in the right direction

<david-macdonald_> prestn+

Ch: stimm question how do we move thingsforward
... different people see issues differently - I drafted some solutions

<GreggVan> sorry for being late

Ch: one observation: there are 2 different pieces of work going on at the same time: WCAG 2.X and early stage WCAG 3
... important to see if the same working process is applied to both - hunch is, probably not
... lets look at proposed solutions
... workflow process: be respectful, polite, careful, avoid repeating things
... second one about making meetings more efficient
... third one: chairs should make sure that discussions of issues go ahead while comments on individuals are separated out
... See that process gets broader review, go over things that are proposed
... Jenny has fifth proposal
... being able to review discussions and decisions later if you could not attend meetings

Jenny: Some people especially in COGA have difficulties tracking discussions in different media

in Coga nt Yoga!

<bruce_bailey> @sarahorton -- https://docs.google.com/document/d/1O5kkM1LU9Qokt3GnbQrvUA7Hr8v-GGDAIfhoNg3zEDI

CH: agrees had that issue too
... choosing Google doc turned out a problematic medium for some in the group
... when talking to chairs we decided to avoid discussions on tooling
... more on process of work
... these discussions have to be repeated - tooling changes, is it still working for people - there is pain and cost of changing tools with potential benefits

<Zakim> JF, you wanted to ask about tooling - what if that is part of the larger problem?

Katie: Earlier on, transcripts were not included, not sure if they are safe; minutes tend to be poor when you want to follow

<kirkwood> +1 to transcripts

JF: appreciate not talking about tooling, but it may be one of the root causes of the disconnects - we cannot make any call, but if info is scattered across git, mail, google docs it is hard to follow

<chaals> ach ra

<Zakim> Rachael, you wanted to ask if there are any accessibility concerns with the wiki?

Rachael: Are there known a11y issues with the Wiki?

JF: Some people struggle with authoring content in the Wiki

ch: heard the same

<kirkwood> authoring not reading/viewing

<bruce_bailey> +1 to stories that wiki text is too technical

<chaals> [+1 we're trying to do difficult things. Actually, IMHO several difficult things in parallel… which multiplies the issues]

DMD: Giving some context - difficult what we are doing, troubles unsurprising - we had more time earlier on. With WCAG 3 its getting more difficult. Uptake so far has been good, but there is criticism, often justifed

<jeanne> +1 to DMD

DMD: we are in the storming phase. A passionate WCAG 3 team, and a stable 'old' team - both come together which makes it difficult
... some friction down to experience of working on WCAG 2 - some of the 3 Team were surprised by the criticism that came forward, they may not have been used to it
... we should welcome new ideas and make the new Wcag team feel welcome - have a lot of confidence in the process, it will come together if you tacke it with a positive attitude

<Rachael> +1

<laura> +1 to David

Ch: Agree wit ha lot of what DMD said

<mbgower> +1 to much of what David said

Ch: important to define what we want to achieve
... Want to look at the workflow proposal, role of sandbox
... do we allow the WCAG 3 group to produce a public doc before review by main group, or not?

<Zakim> Rachael, you wanted to answer

Rachael: Short answer, before full doc there are review checklists, each point needs to be reviewed by the group

<jeanne> qq+

<Zakim> JF, you wanted to answer

<Zakim> jeanne, you wanted to react to Rachael

<Zakim> Judy, you wanted to say ditto wrt authoring content, particularly structuring content, in the Wiki

Jeanne: Give an example there was work that could not go into editor's draft because people wanted outside comments first, but because there was no draft, people outside could not comment - catch 22

Judy: Feedback about a11y of wikis, we collect feedback to make better decisions - send comments to Michael Cooper and Judy

<bruce_bailey> wrt wiki -- my own experience is that markdown seems easier for people than wikitext -- which seems odd to me, because they are so similar

AWK: to answer whether WCAG 3 subgroup should publish: The idea was not to have it as subgroup but merge it with the main group

<Ryladog> +1 to Andrew's recall

<JF> +1 to AWK

<Judy> +10 to AWK

<laura> +1 to awk

AWK: we were not expecting anything going out as main draft without consent of AGWG - it should not be a separate process

CH: Is that how it is happening? How can we make it work?
... was struck by the process proposal that WCAG 3 is a separate subgroup but the 2 group has to approve result
... what I am used to is that a group can produce results in editor's draft that can be anything the group deems appropriate
... you can earmark things as experimental to make it clear it its work in process

<Zakim> alastairc, you wanted to say that after groups combined, we'll still have a lot of sub-groups.

<Zakim> chaals, you wanted to talk about processes for publishing... and to suggest that getting stuff out early is important especially in early stage...

Alastair: Combined group aspect: While the main focus is WCAG 3, there is a huge amount of work for 2.X so we still have that problem that things need to be reviewed by the larger group. Hence the diagram
... we are also trying to label stuf, e.g. as exploatory

<Rachael> example of labeling (still in draft and thanks to Wilco for this work): https://rawgit.com/w3c/silver/status-indicators-new/guidelines/index.html

Alastair: what has been a problem that people race ahead to use new things like the new contrast algorithm

<Zakim> Rachael, you wanted to clarify the workflow process

<Zakim> JF, you wanted to comment on the "new" color contrast effort and ongoing confusion about that

Rachael: In the diagram, the subgroup indicator does not equal Silver, there are others

<Rachael> Text version of the workflow document: https://www.w3.org/WAI/GL/wiki/AG_process#Process_Overview_for_Content_going_into_the_TR_Document

JF: People don't read labels, they look for solutions - hence reluctance to publish too early
... some time it is only a few people proposing thinking they got it 90% right but when it goes to wider group, this is not the case, causing frustration

<Zakim> mbgower, you wanted to say that for 2.1 the 3 task forces produced material that was then scrutinized by the whole AGWG, and heavily altered before making it to the FPWD.

<laura> +1 to JF

Mike G: Experience with 2.X was that stuff was often significantly changed, sometimes frustrating - in the exploratory phase it is good to have feedback before you are too far down the track

<alastairc> Also, any sub-group (or group-member) can create a branch in github and create content. The workflow is about what goes into the editor's draft.

Juanita: We might be taking on too large a task for the amount for people we have - may be good to involve outside groups 'closer to the ground' to provide guidance that future standard is more likely to be adopted in laws/regulations

<Zakim> chaals, you wanted to note that experimental implementation is valuable, and there are costs to not doing things as well as doing things wrong

Ch: is this group taking on too much work? maybe not - it is a large group - others also participating
... a small number of people doing the core research & development - this is valuable - success for this group is more content on the web which is more accessible, devs follow that cycle continues. Guidelines is not the ultimate goal, thatÄs end result out there

<Regina> ............

Ch: when people pick up experimental work - they don't read carefully, that's normal. - bu that creates valuable real-world implementations that helps updating requirements
... org wanted to see if stuff conforms to 2.0 - replied you should look at 2.1
... it is important to publish the stuff you have got: reduces frustration if it is being looked at, progress is visible, validates the effort - that's very important. When you publish stuff that is nit good enough is also a problem, so feedback from the wider group is also valuable, to move to from exploratory ultimately to Rechnung stage
... a big part of the process is to encourage people t do th fundamental work everything depends on - and experimentation is an important part of that. Most new areas have significant a1y problems so experimentation should not concern us too much.
... what wants me make to contribute? is important q to ask.

DMD: Speak historically - WCAG has been more a monitoring org that looks at what is bubbling up in Unis in research, in disability orgs and evaluate that, put together innovations, give it shape

<Chuck> mid meeting regrets, I have a priority issue that is taking my attention.

DMD: most of the innovation was outside the group, sometimes members of the group git involved in developing things like CCA tool - but now it is not just vetting but more innovation

<Jaunita_George> +1 to David

<Jaunita_George> Scribe: Jaunita_George

<Detlev> … So many laws and litigation - there are a lot of orgs that look at WCAG work and see that it will turn to

jeanne: I like most of what David said. Though I believe that we're more research-focused.

<Zakim> chaals, you wanted to talk about next steps (and move on to the rest of today's agenda)

<Zakim> jeanne, you wanted to say that we are not looking at being an innovation organization -- in fact, we have put in our requirements that we want to be more research driven.

<bruce_bailey> +1 to what David MacDonald is saying about WCAG 1 / 2 documenting established best practices , not so much pushing the envelope

<bruce_bailey> +1 to Jeanne comment that wcag3 being more research based also lets wcag3 push forward

chaals: I'm not convinced that jurisdictions are looking at the latest draft and holding folks accountable
... Majority is still using an old standard
... I would like to look at the next steps

Detlev: I want to add in the EU, the situation is different. EN301-549 is closer to new versions of WCAG

chaals: There are some that are going further ahead.

<ShawnT> In Canada, I just found out, we can't go to WCAG 2.1 until it's available in French (Spring 2022)

chaals: it's important the group consider a few questions. How do we manage the parallel work we have, on both WCAG 2.x and WCAG 3, to achieve our big goal of helping the world make the Web more accessible? How is the process working and is it improving the situation? It's important to listen to people.
... Should we have another meeting on this topic?
... wait at least a month before the next meeting on this maybe?

<Zakim> Rachael, you wanted to suggest we circle back in 3 or 6 months

Rachael: We've made a lot of changes. We should circle back in 3-6 months and see if those changes were effective

<bruce_bailey> +1 to circle back in few months

<Wilco> 3 months

<AWK> 3

<mbgower> 3 sounds good.

<JF> 3 months

<ToddL> 3

<alastairc> 3 months

Rachael: Need your feedback

<Jennie> 3 months

<Rachael> Straw Poll: sooner, 3 months, 6 months, never

<JakeAbma> 3

<bruce_bailey> +1 3 months min, 6 max

<Jemma> 3month

3 months sounds good.

<Detlev> 3 sound alright

<laura> 3

<sarahhorton> 3 months

<kirkwood> 3

<Lauriat> +1 to 3-6 months

<Ryladog> 3 months

<jeanne> sooner than 3 months

<KimD_> More conversation is needed. No longer than 3 months

<GreggVan> 3

<bruce_bailey> +1 sooner, 3 or 4 months

<ShawnT> 3 months

<MelanieP> 3 months

<Raf> 3

JF: In 3 months time, 2.2 will have launched and will be a good marker for the team

<janina> Please define "launched"

<Lauriat> +1 to JF, I like the milestone-ness of that

<MelanieP> +1 to JohnF

+1 to JF

<chaals> [As many months as it takes for the group to say "we need to be talkinng about this some more". Which is ideally never, but perhaps 3-6 months…]

<Jemma> +1 jf

<GreggVan> +1 to JF

<ToddL> +1 to JF

<chaals> +1 to "on release of WCAG 2.2

janina: I'm concerned with the word "launched." Does that mean publishing the CR? There's a long path from CR to PR.

<KimD_> +1 to Janina's point

Rachael: I would suggest moving into the CR process

JF: That's what I was thinking

Rachael: Are you comfortable with waiting for 3 months?

<jeanne> I can wait for CR or 3 months

<JF> CR or 3 months which ever comes first

<KimD_> My concern on waiting longer than 3 months is the Silver won't have a way to move forward

janina: The CR does keep slipping.

<bruce_bailey> i like 3/4 month iff we have have not hit CR

Rachael: Is 3 months okay?

janina: I can live with that

Rachael: Any objections?

RESOLUTION: revisit this when we move into CR or 3 months, whichever comes first

<Wilco> +1

<Lauriat> +1

<JF> +1

<mbgower> +1

<bruce_bailey> +1

<laura> +1

<jeanne> +1

<Jemma> +1

<ToddL> +1

<Jennie> +1

<MarcJohlic> +1

+1

<ShawnT> +1

<AWK> +1

<sarahhorton> +1

<Ryladog> +1

<MelanieP> +1

<janina> +1

<alastairc> +1 (and noting it is not draft, that's now the resolution :-)

<kirkwood> +1

<KimD_> +0

RESOLUTION: revisit this when we move into CR or 3 months, whichever comes first

WCAG 2.2 Focus appearance https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/

Using target-area as the basis for size metrics

Rachael: *Reviewing item 4

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

<Zakim> alastairc, you wanted to provide overview

<Rachael> results at: https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results

alastairc: *provided overview of issue

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

alastairc: most of the comments we've been through

Wilco: This is complicated. Current language doesn't mention component area.
... We've been using the border box, but it's not technology agnostic and doesn't always work

Rachael: Anyone we miss?

<Zakim> AWK, you wanted to say that this change will put conformance with the SC at odds with wanting to make the clickable target area larger for some users.

AWK: This change will put conformance with the Success Criteria at odds with wanting to make the clickable target area larger for some users.

<alastairc> The checkbox+label was a key case for that

<AWK> yes, @alastair, thanks for that reminder

Katie: Seems to me that appearance has to do with visual and people will need to see the border.

<alastairc> Unfortunately both can vary from the visual

Wilco: Not sure if it's either/or. We don't know how to define the area. Whatever solution we create needs to be technology agnostic and account for edge cases as much as possible.

<AWK> Also, for users who zoom in to a high degree will have the zoomed in viewport oriented based on the location of the programmatic focus, so the more precise that is the better.

<Zakim> alastairc, you wanted to talk to technology agnostic

alastairc: Compared to the size of the component, we don't define the size. Is it best to leave it there to keep it technology agnostic?

mbgower: One of my perceptions on the SC is that it's more design-focused

<Jemma> Does anyone know where we can find example doc?

alastairc: About examples: I don't think you'll find many differences between sites. The niche cases I see are when people expand target size
... other aspects are checkboxes

<Zakim> Wilco, you wanted to respond to both cases

<Jemma> https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#focus-indicator-strong

Wilco: To respond to both: if you have a link in a card, the link is the component. To the example of the label and checkbox, the only way it could be a failure is if you have a bunch close together.

<mbgower> Can you clarify that?

<alastairc> JakeAbma: do you remember the odd cases you brought up?

<AWK> +1 alastair

<Jemma> https://www.w3.org/WAI/WCAG22/Understanding/focus-appearance-minimum.html#dfn-user-interface-component

<Ryladog> +1 to Alastair

<Jemma> "NOTE

<Jemma> Multiple user interface components may be implemented as a single programmatic element. "Components" here is not tied to programming techniques, but rather to what the user perceives as separate controls."

<bruce_bailey> i am hoping @alstairc and @wilco can agree about "component"

AWK: I think it's a hard argument for us to make that if you click on the label and it activates the control, that the label is not part of the control.

<alastairc> component: "a part of the content that is perceived by users as a single control for a distinct function"

<Rachael> suggested straw poll: Option 1) Change to using target size as the basis for measuring components Option 2) Update the note in some way Option 3) Something else

<kirkwood> can we remove the term component?

<Rachael> straw poll: Option 1) Use target size as is Option 2) Work out exceptions on target sizes

<Detlev> I think Alastair had a good argument for keeping it more general

<Rachael> straw poll: Option 1) Use target size as is Option 2) Work out exceptions on target sizes Option 3) Update the note (don't use target size) Option 4) something else

<Ryladog> 3

<AWK> 3

<alastairc> 3

<JakeAbma> 3

<GN015> 3

3

<Wilco> 1 or 2

<Detlev> 3

<mbgower> I'm happy to explore this more. Without more data, hard to vote for any one. :)

<JF> 3

<kirkwood> 3

<laura> 3

<ShawnT> 3

<bruce_bailey> 3

<ToddL> 3

<Jemma> hard to vote +1 mbgower

<Rachael> 0 abstaining

<MelanieP> 0 need more examples of consequences of each

<bruce_bailey> is option 3 closest to using component concept ?

<GreggVan> 3

<Jemma> 3 if option 3 is closest to using component

<Zakim> alastairc, you wanted to say neither metric is perfect, need to work on scoping for either

Wilco: I do not agree

alastairc: I think we need to narrow down when that would be a problem then.

<Ryladog> I think it is th measurability for automatable testing

<bruce_bailey> @Wilco might note say something about html element as distinct from wcag component ?

Rachael: I would suggest Wilco and alastairc meet this Friday to come to a consensus

Wilco: I'm not sure how we'll move forward

Rachael: I'm hesitant to move it forward without addressing that technical need

alastairc: Wilco and I have spoken about this before and we can collaborate on a 1-pager that we can present to the larger group

Wilco: Ok

<mbgower> target region of the display that will accept a pointer action, such as the interactive area of a user interface component

mbgower: I just pasted in our definition for target. We already have this idea that the UI component is different than target area

<Ryladog> Good point Mike

<kirkwood> I share that concern

Rachael: Should we skip this one?
... let's skip this one until next time

Focus Appearance complexity #1842

<bruce_bailey> +1 to Racheal observation about discussion changing peoples view from survey -- i was one of those

alastairc: *provided background

<Jemma> https://github.com/w3c/wcag/issues/1842

<Jemma> "Proposed response:

<Jemma> As referenced in previous comments, there are multiple factors which affect the visibility of a focus indicator, removing any of which would render the requirement useless.

<Jemma> There is always a balance between complexity, understandability, and design options. Despite multiple attempts no one has been able to suggest a simpler version which meets the requirements.

<Jemma> Keeping the design options open does make it more complex, otherwise we could just use the text from the AAA version. However, that was thought to be too restrictive.

<Jemma> What is relatively easy to convey is how to pass and since your comment we've added another figure at the top of the understanding document to highlight 3 easy ways of creating a passing focus indicator."

<Rachael> results are at https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq27

<Rachael> scribe: Jemma

<scribe> scribe: Jemma

<Chuck> I was talking on mute! I can scribe Jemma.

rachael: going over survey results https://www.w3.org/2002/09/wbs/35422/wcag22-focus-appearance-enhanced2/results#xq27

<Chuck> I'll back Jemma up

awk; agreeing with adjustment and also agreeing with that this SC is complex

scribe: particularly adjacent contrast part is complex
... that is why I proposing simplification in my comments
... down to two points

adjacent contrast was changed with different wording.

"pixels must touch" was clarified.

scribe: other point after pixel must touch will be taken care of by other sc

mbgower: awk comment looks fine and it needs to be linked to understanding doc.
... awk's rewrite is fine to me. I see that we still need final bullet points becase user cannot see it when author content is hiding it.

alastairc: three points
... 1) it seems everyone agree with my response.

<bruce_bailey> +1 what @mbgower describes -- 'stickies' that float over content

2) andrew's update - one of my concern - area aspect need to meet both contrast criteria

3) decide that floating content are not covered by sc

<Zakim> Rachael, you wanted to suggest we use the current response with an addition that we will continue to work on simplifying, then survey AWKs suggestion

<Chuck> +1

gv: I think we should keep the last bullet point for floating content like MBgower addressed.

<AWK> +1

<bruce_bailey> +1 for more time and one more pass

<kirkwood> +1

<GreggVan> +1

<Ryladog> +1

<AWK> (To clarify on Gregg's comment, the "last bullet" isn't actually a bullet)

<AWK> +1

<Rachael> suggested strawpoll: 1) accept response with note that we will continue working and survey AWK's suggestion next week 2) Accept response 3) Accept AWK's suggstion 4) Something

<alastairc> Slightly updated response: https://github.com/w3c/wcag/issues/1842#issuecomment-982735626

<mbgower> 1

<ShawnT> 1

<AWK> 1

<ToddL> 1

<JakeAbma> 1

<Detlev> 1

<Chuck> 1

<Ryladog> 1

<alastairc> 1

<GreggVan> +1 but keep last bullet

<MarcJohlic> 1

<Rachael> 1

<david-macdonald_> 1

<laura> 1

<JF> 1

1

<Francis_Storr> 1

<bruce_bailey> 1

<Raf> 1

<Rachael> draft RESOLUTION: Accept note as ammende and survey AWK's suggestion with last bullet back in next week

for scribing purpose, copy and past from Andrew's comment -

"I agree that this SC is useful and should stay, but I suggested some changes in the wording earlier that I think might help make it more easily comprehended:

@alastaiir - I think I was. Here's my updated suggestion:

When user interface components receive keyboard focus, the focus indicator meets the following:

• Contrasting area: The focus indicator has an area with a contrast ratio of at least 3:1 between the colors in the focused and unfocused states, and that area is at least as large as either:

o the area of a 1 CSS pixel thick perimeter of the unfocused component, or

<Rachael> draft RESOLUTION: Accept note as amended and survey AWK's suggestion with last bullet back in next week

o the area of a 4 CSS pixel thick line along the shortest side of a minimum bounding box of the unfocused component, and no part of the area is thinner than 2 CSS pixels.

• Adjacent contrast:

o When the focus indicator is shown by changing the appearance of pixels which are immediately adjacent to the user interface component, the focus indicator must have a contrast ratio of at least 3:1 against the component or a thickness of at least 2 CSS pixels.

Additionally, the item with focus is not entirely hidden by author-created content. (– not needed due to 2.4.7)"

<Rachael> draft RESOLUTION: Accept note as amended and survey AWK's suggestion with last line relating to 2.4.7 back in next week

<kirkwood> +1

<Chuck> +1

<AWK> +1

<GreggVan> +1

<JF> +1

awk: explaining his comment - "Additionally, the item with focus is not entirely hidden by author-created content. (– not needed due to 2.4.7)""

<bruce_bailey> +1

<ToddL> +1

<alastairc> no objection

RESOLUTION: Accept note as ammende and survey AWK's suggestion with last bullet back in next week

<laura> bye

This is scribe.perl Revision VERSION of 2020-12-31
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/C<R/CR/
Succeeded: s/especially in Yoga/especially in COGA/
Succeeded: s/ach ra//
Succeeded: s/o publish/to publish/
Succeeded: s/earlie/early/
Succeeded: s/So many/… So many/
Succeeded: s/a month/at least a month/
Succeeded: s/important is it that we continue with WCAG 2.x/do we manage the parallel work we have, on both WCAG 2.x and WCAG 3, to achieve our big goal of helping the world make the Web more accessible/
Succeeded: s/objectives/objections/
Succeeded: s/examples/example doc/
Succeeded: s/see it/see it when/

WARNING: Replacing list of attendees.
Old list: Chuck, Rachael, kirkwood, Jen_G, bruce_bailey, ShawnT, MelanieP, shadi, GN, Katie_Haritos-Shea, Jemma, AWK, GreggVan, Detlev, jon_avila, Jennie, Lauriat, JakeAbma, ToddL, jeanne, Léonie, (tink), alastairc, JF, Nicaise, LisaSeemanKest, Laura, Francis_Storr, janina, Jaunita_George, mbgower, Laura_Carlson, Raf
New list: Chuck, Rachael, jeanne, alastairc, Jennie, Lauriat, chaals, JakeAbma, MichaelC, kirkwood, Jaunita_George, Jen_G, ShawnT, Raf, JF, Wilco, janina, Rain, AWK, sarahhorton_, MelanieP, Detlev, Laura_Carlson, mbgower, Katie_Haritos-Shea, caryn, shadi, KimD_, Jemma, david-macdonald_, bruce_bailey, GreggVan, ToddL, Francis_Storr, Judy_firsthalf, MarcJohlic

Default Present: Chuck, Rachael, jeanne, alastairc, Jennie, Lauriat, chaals, JakeAbma, MichaelC, kirkwood, Jaunita_George, Jen_G, ShawnT, Raf, JF, Wilco, janina, Rain, AWK, sarahhorton_, MelanieP, Detlev, Laura_Carlson, mbgower, Katie_Haritos-Shea, caryn, shadi, KimD_, Jemma, david-macdonald_, bruce_bailey, GreggVan, ToddL, Francis_Storr, Judy_firsthalf, MarcJohlic
Present: Chuck, Rachael, jeanne, alastairc, Jennie, Lauriat, chaals, JakeAbma, MichaelC, kirkwood, Jaunita_George, Jen_G, ShawnT, Raf, JF, Wilco, janina, Rain, AWK, sarahhorton_, MelanieP, Detlev, Laura_Carlson, mbgower, Katie_Haritos-Shea, caryn, shadi, KimD_, Jemma, david-macdonald_, bruce_bailey, GreggVan, ToddL, Francis_Storr, Judy_firsthalf, MarcJohlic
Found Scribe: Detlev
Inferring ScribeNick: Detlev
Found Scribe: Jaunita_George
Inferring ScribeNick: Jaunita_George
Found Scribe: Jemma
Inferring ScribeNick: Jemma
Found Scribe: Jemma
Inferring ScribeNick: Jemma
Scribes: Detlev, Jaunita_George, Jemma
ScribeNicks: Detlev, Jaunita_George, Jemma

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth


WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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.)