<Chuck_> meeting: AGWG-2021-04-13
<laura_> Scribe: Laura
<AWK> +AWK
<laura_> Chuck: Anyone new?
<laura_> chuck: we will spend 30 minutes on silver issues.
<laura_> … wcag 3 would like to learn how ag operates.
<laura_> … silver team has just had some training from AC.
<Chuck_> https://github.com/w3c/silver/issues/
<laura_> chuck: link to all of the silver issues
<jeanne> Weekly report https://www.w3.org/WAI/GL/task-forces/silver/wiki/Issue_Processing_Report
<laura_> chuck: link to report https://www.w3.org/WAI/GL/task-forces/silver/wiki/Issue_Processing_Report
<laura_> … issue raised by ITI
<laura_> … process > draft response. survey.
<laura_> … I have put together a draft response.
<laura_> … … today we are skipping the survey
<laura_> … I have put together a draft response.
<Rachael> Thank you for your comment. This terminology is intended to express concepts that have yet to be fully explored. The working group will maintain a list of different possible terms for these concepts, which will guide us as we explore these concepts in greater detail.
<laura_> … “Thank you for your comment. This terminology is intended to express concepts that have yet to be fully explored. The working group will maintain a list of different possible terms for these concepts, which will guide us as we explore these concepts in greater detail.”
<Rain> +1 to Jeanne's question: can we start that list and link to it?
<laura_> AC: group will take into account your suggestion.
<laura_> js: maybe have a list of candidate terms.
<laura_> ac: if we have a list we could link to it if we had it.
<laura_> chuck: positive input. I will adjust the proposed response.
<jeanne> To AWK, "status: schedule future draft"
<Zakim> AWK, you wanted to propose label for issues closed but that should be followed up on later
<laura_> awk: this response “yup noted” but this will happen again.
<laura_> … have a set of labels in case anyone else comments on it so it doesn’t get forgotten.
<laura_> jeanne: we had a label we could revisit the label name for it.
<laura_> rm: think there is a difference in labels.
<Zakim> sajkaj, you wanted to suggest this is a milestone meaning
<laura_> awk: make sure we address comment.
<laura_> js: you can set milestones.
<alastairc> I think it's the other way around, issues need to be closed before a milestone.
<laura_> rm: could make sense to close and then set a milestone to check.
<Rachael> I agree that is how it usually works alastair
<laura_> chuck: question on kiosks.
<Chuck_> https://github.com/w3c/silver/issues/225
<laura_> … “Can content accessibility guidelines explicitly apply to user interfaces of closed systems and kiosks?”
<laura_> … question on scope.
<laura_> … scope could be viewed in not so limited a fashion.
<laura_> … best for ict or WCAG3?
<jeanne> Scope section of the AGWG Charter of 2019 <- https://www.w3.org/2019/12/ag-charter#scope
<laura_> js: in spirit to expanding - it is basically just another interface.
<laura_> …think it would be compelling.
<laura_> rm: can be web interface but there are others.
<laura_> js: is in challenges doc.
<laura_> chuck: hoping someone will assign themself to this issue and craft a draft response.
<Rachael> But for those that have web interfaces, I think WCAG should definitely apply. For the other approaches, it should depend on how we handle mobile, desktop, etc.
<laura_> mg: some challenges with this one.
<laura_> … would be good to delineate what silver will cover and what it won’t cover.
<jon_avila> EN 301549 does better than 508 about applying WCAG to closed functionality but doesn't really specify or interpret enough to fully address accessibility of these systems.
<laura_> awk: short answer is no. WCAG focusing on APIs and AT. That is the problem of closed systems.
<jon_avila> closed functionality is defined that you can't bring your own assistive technology - keyboard interface is different in my opinion.
<laura_> … if it is really closed would be beyond the scope of WCAG3.
<Fazio_> There were discussions aaabout having multiple versions to address different systems
<laura_> … happy to draft the word no.
<laura_> … happy to help.
<johnkirkwood> is this aldo non standard language beyond HTML
<laura_> sl: one of the projects I worked on was ATM.
<laura_> … all sorts of proprietary ,
<jon_avila> This isn't limited to just kiosks but to connected devices like smart TVs, etc.
<laura_> dm: can’t bring your AT to closed systems.
<laura_> … big concern would be delays and lack of expertise.
<laura_> ac: base response on the charter and mention closed systems.
<jeanne> +1 Alastair
<Rachael> +1 to Alastair's approach
<laura_> mg: I volunteer to draft a response.
<Chuck_> https://github.com/w3c/silver/issues/286
<laura_> chuck: other issues:
<laura_> … looking for volunteers.
<laura_> … have over 200 issues.
<laura_> awk: ARIA WG has also gotten this 286 comment regarding "disabled" used in the ARIA and HTML attributes.
<laura_> … may want to link some issues together.
<laura_> chuck: still need to address the comment.
<Chuck_> https://github.com/w3c/silver/issues/286
<laura_> awk: I will bring it to james.
<laura_> chuck: hoping to make this a regular event.
<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results
<laura_> chuck: Alter note for Redundant Entry #1660
<laura_> … Michael Gower opened Issue 1660 to suggest the note is adjusted to be more specific to repeating passwords.
<laura_> … There is an updated PR 1659 was created to implement that, which: Removes the note entirely. and Expands the explanation in the understanding document.
<Chuck_> https://www.w3.org/2002/09/wbs/35422/wcag22-redundant-entry-updates/results
<laura_> … Rain agreed with the update with adjustment
<laura_> rain: worried about passwords.
<laura_> … Guidance on what constitutes a secure password changes over time, so I would recommend removing "non-dictionary string." This could be replaced with other wording if needed (though I don't think it is since describing good password practice is not the intent of this document). Example replacement wording: "unique, containing a large variety of character types and/or random words"
<Fazio_> Where is this paassword verbiage?
<JF> +1 to DAvid
<laura_> df: where did all this password stuff come from?
<laura_> …sounds like accessible authentication
<laura_> mg: I took away the note.
<laura_> … some good feedback that I think I can incorporate.
<laura_> chuck: a lot of support for rain’s text.
<laura_> df: like what mike said.
<Fazio_> +1 JF
<Fazio_> +1 again JF
<laura_> jf: should not be talking about authentication. It is not our job.
<Fazio_> It's not the essence of redundant entry
<laura_> … outside of our scope.
<laura_> ac: talking about redundant entry.
<Rain> +1 to JF and Mike, my concern is more about becoming dated in guidance, and removing would resolve the concern
<Fazio_> If it's essentia;
<Fazio_> essential
<laura_> … repeated password is a very common use case.
<Fazio_> I guess I missed the convo
<laura_> … mg made an update.
<laura_> … need to explain it somewhere.
<Fazio_> It's not always ok
<Fazio_> It can be burdensome
<laura_> … why it is okay to have a repeated pass work. - can’t copy paste.
<Zakim> JF, you wanted to note that 'password' is one of the form inputs covered by SC 1.3.5 and @autocomplete
<laura_> … take out from SC and add to understanding doc.
<Fazio_> well redundant entry isnt creating new passwords but reentering
<Fazio_> +1 Rain
<Fazio_> accessible authentication!
<michael> Yep, I will incorporate
<Fazio_> biometrics
<alastairc> Fazio - as written it applies to all unless we consider it essential
<laura_> rain: feel more comfortable with the word “may”
<laura_> … may be essential.
<johnkirkwood> +1
<laura_> df: not about creating new password.
<laura_> … maybe dovetail with accessible authentication.
<Fazio_> yes
<johnkirkwood> reduntant entry can also prevent keying errors.
<laura_> awk: we have other SCs. hard time with out definition of essential. Don’t thing it really fits here.
<laura_> … change the exception.
<Wilco> +1
<michael> Yep
<johnkirkwood> +1
<johnkirkwood> validation
<laura_> rm: started talking about security. but the redundant entry is what we are talking about.
<Fazio_> I'm on the fence
<laura_> awk: this is splitting a hair.
<Fazio_> I'm concerned about excessive password reentry
<laura_> … make the exception include security.
<alastairc> Fazio - that shouldn't be an issue given accessible auth.
<laura_> mg: I’ll rewrite it. This is not about security.
<Fazio_> no wrgument there
<Rachael> +1 to mbgower
<jon_avila> I agree with Mike and Andrew - this is about functionality and not security.
<johnkirkwood> +1 to MG it is not about security
<Zakim> alastairc, you wanted to say that as Rain mentioned there are other methods
<laura_> … can’t copy a password. Security is confusing the SC.
<Fazio_> moodle allows that
<laura_> ac: other methods than repeating a password.
<laura_> … can’t be essential. agree with awk expand exception.
<Rain> e.g., not requiring password repeat but creating a smooth way to recover with email validation or other methods
<laura_> df: coga folks tend to reuse passwords.
<laura_> … concern with having people locked out.
<alastairc> That's a different issue... this is repeating the password as part of the same process, I haven't come across that.
<laura_> … having to reenter password is a problem.
<laura_> chuck: heard that reentry is a problem and that there are mechanisms.
<Rain> My concern, to be specific, is using the word "is" vs. "may be" (implying that this is the only way)
<Zakim> alastairc, you wanted to check what we can live with.
<Fazio_> Only for confirmation purposes
<laura_> … not sure which way the group is leaning.
<johnkirkwood> password reentry for validation shoud be an exception
<laura_> ac: essential doesn’t really cover it.
<laura_> … make sure the exception covers it.
<jon_avila> When re-entry is essential to validation of the information this is considered essential
<Zakim> Rachael, you wanted to ask if we can qualify that its data validation when correction is not possible
<laura_> gn: when entering a password I have seen it have the ability to make it visible.
<Fazio_> can't we say exception when confirming a new password is correctly entered
<Fazio_> or some variation
<alastairc> but without allowing everything to be 'validated'...
<laura_> rm: need to clarify the exception.
<laura_> mg: email can rely on auto complete.
<GN015> +1
<laura_> … if people think it is not an exception I’ll take it out.
<laura_> jk: it is about of data validation. people may not be on their own machine.
<laura_> ja: we should not limit to passwords.
<alastairc> anything for authentication?
<laura_> .. finanial and leagle use cases too.
<bruce_bailey> scribe: bruce_bailey
<johnkirkwood> I trust MG.
<johnkirkwood> ;)
<Jennie> Employee ID number is another one.
chuck: summarizing, think that we
hear that validation is a reasonable use case
... we do not have consensus on language
DavidF: yes, could be generalized to cover situation on SSA
<Fazio_> validation of only something just created
Chuck: we do have consensus on
point to be moving to
... Mike G has offered to take another cut at drafting
<jon_avila> I agree with David on immediate validation.
Chuck: action item is for Mike G to keep working and bring back to group
<johnkirkwood> David said validation should be immediate. Agreed.
<alastairc> mbgower - branch https://github.com/w3c/wcag/tree/wcag22-redundent-entry-security-note
DavidF: one requirement is for validation to be immediate
DavidF: if it is on a different screen, that is very confusing
<Fazio_> validation of data entry must be immediately
JohnF: what if the user is warned ahead of time they will need to reenter PW or whatever ?
DavidF: No, since the prompt might not immediate enough
(John and David discuss)
Chuck reads question.
Changes of context definition
https://github.com/w3c/wcag/issues/737
https://github.com/w3c/wcag/pull/1026/files
User perceive context changes as setting the focus to other locations, based on change of
Oliver Keim responds to his survey entry.
OK: Not sure if viewport used in this context is clear
Gundula: redraft is not much
clearer than previous version
... subclauses are not as easy to follow
... complete subclauses beter than interrupted subclauses
... disagree with update
MikeG: easy fix would be just to
remove "changes of content"
... redraft does not change any meaning
<Chuck_> +1 mgower
MikeG: taking "change of context"
is opening a can of worms since it impacts other SC
... point of view is a big issue though, so simple removal is
was to avoid that problem
<alastairc> Jake - did you agree with Mike's suggestion?
Sarah Horton: don't think edit address the main problem
scribe: i am in favor of keeping work on this and related definitions
AWK: i am seeing to much
redundancy between opening and middle
... more importanly, we should only change Understanding
<laura> s/focusing on APIs ans /focusing on APIs and /
AWK: if we are changing Normative
text, it should be done as Errata
... i strongly recommend against this.
<johnkirkwood> +1 to AWK
<alastairc> It is 3, one is "changeS of context"
Wilco: Agree with Andrew. There
are two SC where this definition is used, so it is very
problematic
... not worth the risk for such a small edit. Agree with AWK
that Errata is the way to make this change, if that is what we
want to do.
Chuck: I agree that there are pretty serious ramification for relatively small edit.
<mbgower> "Major changes to the web page that, if made without user awareness..."
Alastair: This could be a small erratta that doesn't effect implimentation.
<mbgower> agreed
Chuck: Issue was raised by Jake,
and we have a PR (JawsTest) to address, and we do not have
consensus for this PR.
... There may be another way to address this.
Alastair: Errata would be formal change.
<Rachael> draft RESOLUTION: Reject this PR and explore other solutions, perhaps an errata
<mbgower> +1
<sarahhorton> +1
<AWK> +1
<JustineP> +1
Chuck: Either way, THIS pull request is not the fix.
<Wilco> 0, would rather not explore
<laura> +1
<johnkirkwood> +1
<mbgower> I'd like to hear Jake's response to my suggestion
(vote on draft resolution)
<GN015> +1
<mbgower> I'll put it in his issue
<Ryladog> +1
RESOLUTION: Reject this PR and explore other solutions, perhaps an errata
<Fazio_> 0
RESOLUTION: Reject this PR and explore other solutions, perhaps an errata
<Rain> +1
<JF> +1
https://github.com/w3c/wcag/issues/796
https://github.com/w3c/wcag/pull/806/files
awk ask bruce to clarify
<Chuck_> bruce: Missed the survey, haven't refreshed my mind.
<Chuck_> bruce: This is an inconsistency that lead to a lot of thrashing at one point.
<Chuck_> bruce: Not sure if that answers the question.
<Chuck_> AWK: Who was thrashing?
<Chuck_> Alastair: Me!
<Chuck_> Alastair: When we were doing 2.1, and testing including our own site, there was a thing about sync'd media, whether it needed audio description.
<Chuck_> Alastair: Because the exception is in ...
Alastair: it was confusing people, even me
AWK: so no error, just an opportunity for confusion
<Wilco> +10
AWK: recommend addressing in Understanding or as Errata
<JF> +1 to AWK
Alastair: okay with errata
... same idea, text change not in 2.1, could be in 2.2
maybe
Chuck: am I correct to understand that your strong prefference is to avoid normative text changes unless through erratta?
AWK: Yes. There is so much tools and resources, and small edit to normative text, especially for something that changes understanding, is going to draw too much attention.
<Zakim> JF, you wanted to discuss errata versus updating Understanding doc - one is a normative change, the other isn't
<alastairc> We have changed a level in 2.2, and the titles of a couple of SC
Chuck: So we have not had to make normative SC changes yet, and this also does not seem like something worth doing except as an erratta
JohnF: Agreed, we should not be making normative changes.
AWK: I see 3 situations: 1:
Understanding has changed, we need to update SC.
... situation 2 is that normative, but not changing
understanding. Spelling errors, hyper links
... situation 3 is addressing by Understanding.
<Wilco> Also added "color" to 1.3.3. Which created a mess in the WCAG translations
Alastair: This strikes me as situation 2, because it has caused difficulty with people not realizing exception is hidden (one place) in the definition (but not another)
AWK: This one probably didn't come up before because just not that much experience, even ten years later, with Audio Description.
MikeGower: I think we are are
actually missing a definition
... media alternative to media -- see my comment in
survey
... someone could come away with impression that you need to
caption your audio description
... could be something for Silver
<alastairc> I had to ask on the list to get confirmation, as a client (who had read into it extensively) was not sure: https://lists.w3.org/Archives/Public/w3c-wai-gl/2020JulSep/0184.html
MikeGower: Weird situation wehre
you can pass AAA but fail AA
... the transition from AA to AAA are not strictly additive
JohnF: I want to understand about
the difference between Erratt and normative change to SC
text
... I understand that we would not be changin the fundamental
understanding of the requirements.
Alastair: Yes, my first hand
experience with this was working with a client very interested
in audio description
... and phrasing of SC being so inconsistent really tripped us
up.
<alastairc> https://github.com/w3c/wcag/pull/806/files
Alastair: There is no change in the requirement, merely moves a bit of text from definition to SC
Wilco: Sychronized definition
used elsewhere
... can't just pull it out and put in one SC
... this is a normative change
JohnF: prose in Understanding could also achieve the same thing.
Chuck proposes resolution
<JF> +1 to updating Understanding
<Wilco> +1
<johnkirkwood> +1
<laura> +1
<AWK> +1
<mbgower> 0
<alastairc> -1, but will build a better case
<Chuck_> 0
<Rain> 0
<JustineP> 0
<Ryladog> 0
no consensus
Sarah Horton: I am hearing an underlying question about what things rise to the level of being normative or not, and how to address
scribe: we have not really had a
conversation about what things we might change and what things
we cannot change
... i would vote +0 because it might be worth the conversation
to decide what should be worth the attention and
conversation
Chuck: Comment was that we should
build a better case.
... Sarah you suggested that if we have a definition, that my
guide us to decide when we can make normative changes
Sarah: It would be helpful to have better articulation as to what we are willing to look at, and what not.
<laura> s/financial and legal /financial and legal /
Alastair: Agree that it might be
worth writting out more, but ultimate the group can change its
mind
... There is a great deal of resistance to normative
changes
... there has been been some, like SC titles
... I am voluteering to do more throurogh analysis, and bring
something back to the group.
<alastairc> I had a look through those - it didn't apply
Chuck: Okay we will not be deciding on the call today.
DavidMcDonald: In the 2.0 drafting, there were many discussion about having definitions in the SC
DavidMcDonald: the definition is pretty long, longer than some SC, so it makes it difficult to read.
Chuck: Seeing no further comments, we will table for now.
https://www.w3.org/2002/09/wbs/35422/ag-decision-policy-update3/results
(Chuck reads)
https://github.com/w3c/wcag/compare/wai-site...wai-site-decision-policy-update
Chuck: Gundala asks for a full week
<alastairc> Currently 2 days
Gundala we have had surveys with only 3 or 4 days.
Chuck: W3C policy formally only requires 2 days
<alastairc> https://github.com/w3c/wcag/compare/wai-site...wai-site-decision-policy-update
Chuck: Gundala, we don't have place for that in this policy though.
Wilco and Sarah discuss miss-placed list.
Chuck: AWK asked for some adjustments
AWK: Would like to know the
problem that is trying to be solved by concerns raised
previously rather than raised during CFC
... seems like good concerns are good concerns
Chuck: Agreed, we are trying to give chairs another tool to move forward
Alastair: goes to trying to get
suggestions and dialog sooner than later
... mostly an attempt to get people involved sooner
<JustineP> +1 to Andrew's point given that a consideration might only be realized by a participant later in the process, though I understand the rationale behind the change in language
<JF> +1 to Wilco
Wilco: seems like that sort of thing should be addressed one-on-one
Alastair: it is natural that
issues raised sooner and discussed more are naturally going to
have more weight and more consideration
... it makes management easier for the chairs
<JF> FWIW... https://www.w3.org/2020/Process-20200915/
<alastairc> JF - doesn't really speak to this problem.
AWK: I have some empathy about
making life for chairs easier!
... It seems like there are other channel for the chairs if
someone seems to be delaying or sabotaging (sp) with late
comments
<Wilco> +1
AWK: Language as is seems unnecessarily harsh. Need to encourage participation does not seem like it needs to be in this policy doc.
Chuck: Understand your concern. We had a request to address this point. It might be that this doc is not the right place for the idea.
JohnF: Notes that W3C policy document is consistent with chairs descretion.
Wilco: Not going to vote against this, but I disagree with this addition.
Alastair: Thinking/talking outloud, might instead mention individual who is trying to manipulate CFC process to delay things.
<AWK> https://www.w3.org/2020/Process-20200915/#WGChairReopen speaks to W3C process to reopen decisions, and that is even after a CFC
<Rachael> Draft proposal: Remove "Objections from people who raised their concerns to the group during discussions may be weighted more than objections from people who had opportunity and chose to not participate in those discussions." and approve the other changes
<JustineP> +1 to JF and Wilco
JohnF: Seems like scenerio you describe is already addressed by policy and precedent. ad hoc solutions have been suffient in the past
<Wilco> +1
<Rain> +1
<Rachael> WE woudl also remove the related line "If the substance of the objections was raised during discussion leading to the CfC, the chairs may weight the objection more than objections which were not raised during the discussion leading to the CfC, and reasonably could have been."
Chuck: I agree with Rachael has proposed. straw poll
<AWK> +1
<JustineP> +1
<JF> +1
<morr4> +1
<Rachael> +1
<Ryladog> +1
Chairs discuss if this needs to be CFC.
<Rachael> DRAFT REsolution: Move Decision Policy to CFC with proposed removals
Chuck: any objections?
RESOLUTION: Move Decision Policy to CFC with proposed removals
<alastairc> PR for CFC: https://github.com/w3c/wcag/pull/1737/files
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/ spipping/ skipping/ Succeeded: s/valication/validation/ Succeeded: s/reponse. /response. / Succeeded: s/togeter /together / Succeeded: s/servey/survey/ Succeeded: s/propsed /proposed / Succeeded: s/lables /labels / Succeeded: s/lable /label / Succeeded: s/a differnce in lables/a difference in labels/ Succeeded: s/Cancontent /Can content / Succeeded: s/bacically /basically / Succeeded: s/yes thain you.// Succeeded: s/respons./response./ Succeeded: s/thnk /think / Succeeded: s/delinate /delineate / FAILED: s/focusing on APIs ans /focusing on APIs and / Succeeded: s/beyonf /beyond / Succeeded: s/bout havaing /about having / Succeeded: s/sysrtems/systems/ Succeeded: s/ariawg /ARIA WG / Succeeded: s/286 comment/286 comment regarding "disabled" used in the ARIA and HTML attributes./ Succeeded: s/coment/comment/ Succeeded: s/Agree with the update with adjustement/agreed with the update with adjustment/ Succeeded: s/accessibile /accessible / Succeeded: s/I thing /I think / Succeeded: s/soem /some / Succeeded: s/alot /a lot / Succeeded: s/tauli=ng /talking/ Succeeded: s/comforatble/comfortable/ Succeeded: s/acessibile /accessible / Succeeded: s/definatition /definition / Succeeded: s/redundent /redundant / Succeeded: s/leansn/is leaning/ Succeeded: s/doen’t/doesn’t/ Succeeded: s/propriitory /proprietary / Succeeded: s/talkingabout /talking about / Succeeded: s/not our /It is not our / Succeeded: s/Errata// Succeeded: s/to having /with having / Succeeded: s/errata// Succeeded: s/calify /clarify / Succeeded: s/thier /their / Succeeded: s/ti is /it is / FAILED: s/finanial and leagle /financial and legal / Succeeded: s/concensus /consensus / Succeeded: s/a nother /another / Succeeded: s/ans AT/and AT/ Succeeded: s/finanial /financial / Succeeded: s/leagle /legal / Succeeded: s/missplace list/miss-placed list/ Succeeded: s/concensus /consensus / Succeeded: s/concerns raised rather than raised during CFC/concerns raised previously rather than raised during CFC/ Succeeded: s/involved soon/involved sooner/ Succeeded: s/straw pool/straw poll/ Default Present: sajkaj, JF, Laura_Carlson, AWK, alastairc, Makoto, Rain, julitte_alexandria, mbgower, JustineP, MelanieP, Fazio_, jeanne, sarahhorton, KarenHerr, johnkirkwood, Jennie, stevelee, Katie_Haritos-Shea, Rachael, jon_avila, bruce_bailey, Wilco, StefanS, GN, Francis_Storr, morr Present: sajkaj, JF, Laura_Carlson, AWK, alastairc, Makoto, Rain, julitte_alexandria, mbgower, JustineP, MelanieP, Fazio_, jeanne, sarahhorton, KarenHerr, johnkirkwood, Jennie, stevelee, Katie_Haritos-Shea, Rachael, jon_avila, bruce_bailey, Wilco, StefanS, GN, Francis_Storr, morr, GN015, morr4 Regrets: Rafel Charlampowicz, Charles Hall, Nicaise Dogbo, Chris Loiselle Found Scribe: Laura Found Scribe: bruce_bailey Inferring ScribeNick: bruce_bailey Scribes: Laura, bruce_bailey 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.)[End of scribe.perl diagnostic output]