<gowerm> scribe: gowerm
<MichaelC> 90 km / hr is below highway speed
<AWK__> +AWK
<Rachael> Mike: We constrained the SC to get clear agreement. Its a subset of the original change of content focusing only on status messages.
<Rachael> The description of status messages is a glossary term to keep it contained. We have changed language to address concerns from the last time we talked.
<Rachael> status messages are programatically determed through role or attributes (properties?) so they can be presented to users or assistive technology without receiving focus.
Status messages are programmatically determined through role or attributes such that they can be presented to the user by assistive technologies without receiving focus.
Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, notification of change in content or similar notifications.
<Rachael> status message definition above.
<Rachael> I think we said "roles or propeties" not "roles or attributes"
<Rachael> Also notifications of content was removed from the definitions.
<Rachael> Lisa: What if you want the status message to have a change in focus. As written this looks like it requires a change in focus.
<Rachael> gowerm: We can add a change to the defintion to make that explicit if folks are concerned about that. Do people share concern that as written this prevents people from moving focus?
<Rachael> AWK: Lisa, would you want to move the focus?
<Rachael> Lisa: Yes, if I get a warning , I may want it as a modal where the focus lands on it and then I hit the OK button. Sometimes I want to move the focus.
Changes in content that are not changes in context
<Rachael> gowerm: Change the defintion "changes in content that are not changes in context" because there is a definition of changes in context.
<Rachael> So status messages would be come messages that do not get focus.
<Greg> ...latter is confused with the content being programmatically generated.
<Rachael> A message that does not change context is what we are addressing.
<AWK__> http://rawgit.com/w3c/wcag21/status-changes/guidelines/index.html#status-changes
<Rachael> AWK: Current language does not preclude assistive technology providing focus. Link above is rawgit version.
<Rachael> Greg: Slight rewording was fixed. I am concerned about the so that clause.
<Rachael> We always avoided saying why you do something because it implied a whole lot going on beyond scope of content author. This would be the only SC that includes a So that.
<Rachael> includes an explanatory clause. It introduces risk.
<Rachael> Greg: It may not be a blocking issue. We were just careful in other standards to avoid doing that.
<Rachael> Steve(?): I am OK removing it but it was meant to imply that you had to do it to define a role.
<Rachael> AWK: I think it is the presented to a user part that is the issue.
<Rachael> Greg: It is the such that clause. It also includes the same issue I pointed out in email.
<Rachael> AWK: What should it say?
<Rachael> Greg: We would cut out everythign after such that.
<AWK__> https://www.w3.org/2017/08/telecon-info_ag2
<Rachael> gowerm: The author could set it up to meet this SC but not allow the AT to access the information.
<AWK__> Status messages which do not receive focus can be programmatically determined through role or properties.
<Rachael> Assign role of status and aria-live off and it won't communicate it to AT. There is no other AC that requires making the information available to AT.
<Rachael> AWK: Status messages which do not receive focus can be programmatically determined through role or properties.
<Zakim> Greg, you wanted to say in the past we explicitly avoided "so that" clauses as it implies other, unrelated things AT wants to do (present content without focus changing) beyond the
<Rachael> gowerm: James had concerns about the "Which do not receive focus" which is why we wrote the defintion the way we did
<Zakim> Bruce_Bailey, you wanted to ask if "or similar notifications" makes pass/fail hard to test
<Rachael> If you don't include the requirement about not moving focus, anyone can makethe argument that the user can move the focus to the text and meet this SC.
<Rachael> Bruce: I'm OK with the language of the SC. I'm concerned with the definiton of status message. It ends with "or similar notifications" which is unbounded. What is in and what is out? The second point is the grammar seems messed up.
<Rachael> Steve: The last phrase shouldn't be in there. Let me paste in a clean version.
<Zakim> gowerm, you wanted to say that the role has to be appropriate to provide the presenation to AT
<Rachael> gowerm: Definition was not the latest.
Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, or similar notifications.
<Rachael> Bruce: Can we strip out "or similar notifications?"
Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors.
<Rachael> Agreement it can be removed.
Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process or the existence of errors.
Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, the existence of errors, or similar notifications.
<Rachael> AWK: What is the current SC text right now?
<Bruce_Bailey> add the oxford comma please
<steverep> epresent+SteveRepsher
Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process or the existence of errors.
<Bruce_Bailey> Changes in content that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors.
<Rachael> Is this only the result of an action?
<Zakim> steverep, you wanted to ask if folks think chat logs are included in the definition
<Bruce_Bailey> With Oxford comma: Changes in content that are not changes in context, that provide information to the user on the success or results of an action, the waiting state of an application, the progress of a process, or the existence of errors.
<Rachael> steve: The three roles we want are the role of status (polite announcement announced atomically), alert role (assertive announcement), log role (chat logs, only new thing), and progress bars (all screen readers know how to deal with).
<AWK__> Ah, I was reading your earlier one. Don't worry, I'll make sure that the comma is in
<Rachael> Other things like a stock quote are meant for the marqui role. Timer, and others are not supported by screen readers.
<Rachael> Aria defaults are to ot announce those.
<AWK__> 10 minutes more on this to keep on track
<Rachael> ?: I want to make sure this is not just related to a user action.
<Rachael> No it's not.
<Kathy> I can
<Kathy> scribe: Kathy
<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of an action, or the waiting state of an application, or the progress of a process, or the existence of errors.
Katie - needs to be result of the user action
<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of an action, on the waiting state of an application, on the progress of a process, or on the existence of errors.
<Ryladog> Katie wants to be sure that this is NOT misunderstood to think it is only allpicable to the result of user actions
Alex - quick question, what about gaming
MG - let's read the definition
success or results of an action, or the waiting state of an application, or the progress of a process, or the existence of errors
Alex - so this doesn't cover what other users are doing
Alex - there are a lot of things happening and many players and computers
MG - gaming has a lot more issues than just this
Alex - since this is A and AA it does have a legal implication
MG - can be tackled by "the user action"
<AWK__> +1 to that
Alex - is there anything else essential
Brooks - what about other status updates and alerts
MG - there are some other SCs - pause stop and hid
<Bruce_Bailey> Seem pretty balanced to me
<gowerm> Changes in content that are not changes in context, that provide information to the user on the success or results of the user's action, on the waiting state of an application, on the progress of a process, or on the existence of errors.
<alastairc> An exception for 'time-based media'?
MG - does this address multi-user environments
Alex - hard to define user action since there is many thing happening
AWK - with 4 items that we need to get to, we need to decide if we can live with this or if it is not ready
scribe: anyone who cannot live with it
<alastairc> Is it missing a second part? I'm just catching up and looking at Mike's version above.
JF - can we see the final text
<AWK__> http://rawgit.com/w3c/wcag21/status-changes/guidelines/index.html#status-changes
<AWK__> Changes in content that are not changes in context, that provide information to the user on the success or results of the user's action, on the waiting state of an application, on the progress of a process, or on the existence of errors.
AWK - two options - discuss now or we have an understanding that we need to discuss on the list
scribe: we have until noon tomorrow
<Zakim> steverep, you wanted to suggest change in content which contains information about success, error, progress, or updates to a log and to
<JF> +1 to taking this to the list, as it seems to be down to edge and corner cases (and a bit of wordsmithing)
<lisa__> add a note that an exseption will be added
Steve - we can solidify the definition but gaming has more issues
AWK - alex is suggesting a note which is non normative
AWK - any objections
<lisa__> presnt +
RESOLUTION - leave open for final details on the list
<gowerm> scribe: gowerm
<Kathy> 2.5.2
Steve: There are four bullets now [Reads them out]
<alastairc> Wondering if the uses of 'function' might be better as 'action'? Function just seems quite wide for this context.
Steve: the poll request makes an editorial change. "Single pointers" removed "activation
AWK: There are definitions for down and up events.
MikeG: should abort and undo be separate?
<scribe> Unknown person: I dont' want to make it an exclusive "or" in abort or undo
Alastair: Is the use of "function" appropriate?
Steve: I'm referring to the functionality
Greg: When someone said "add in either", I wanted to make sure we don't say it has to be one or the other, not both
AWK: Do you think adding "either" makes that the case?
Greg: i think 'either' suggests Or not and/or
<AWK__> Completion of the function is on the up-event, and a mechanism is available to @@either@@ abort the function before completion or undo the function after completion;
Mike: I can live with it
AWK: Does anyone have additional concerns or comments?
<Greg> That is, "either ... or" suggests an exclusive or, which is not the intent here. (Personally I use "and/or" in my own work to be totally unambiguous.)
RESOLUTION: Accepted for CFC as proposed in pull request 595
<AWK__> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-1
<jallan> what happened to hover
AWK: the latest one is in the github draft
<JF> +1 to Jim's question - seems we skipped over Hover or Focus...
<AWK__> Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, unless the motion is essential for the function and doing so would invalidate the activity.
<Kathy> All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.
<AWK__> https://www.w3.org/WAI/GL/wiki/Comment_Summary_1-4-14
<AWK__> When pointer hover or keyboard focus triggers additional content to become visible, the following are true: Dismissable: The user can dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure other content; Hoverable: If pointer hover can trigger the additional content, then the pointer can be moved to hover the additional content; Persistent: The additional content r
AWK: The text that we have is the text in the wiki page
<AWK__> Persistent: The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.
<AWK__> Exception: The visual presentation of the additional content is controlled by the user agent and is not modified by the author.
Steve: Last time we discussed, there was general agreement to remove "obscures"
Here is the link to the new version
<steverep> http://rawgit.com/w3c/wcag21/hoverable-and-persistent/guidelines/#content-on-hover-or-focus
Steve: I think there was confusion on the user experience that I tried to clarify. The only people who will notice these changes in experience are low vision users
<jallan> scribe: jallan
<gowerm> Alex: For devices not connected to a keyboard, what are the mechanisms to dismiss?
al: what are other mechanisms to
dismiss
... without moving the pointer
<alastairc> ERr, how do you get hover on touch?
sr: hover is not done by touch. should not enter into scenario
<gowerm> Gowerm: Hover is not covered in a touch modality
al: if only applies to having a
keyboard. then initial statement sounds like you want
implementation on everything.
... need more clarity. not implementable
awk: can we cover this in understanding
<gowerm> Alex: But if I have a pointing device, the only way to satisfy dismissable is to move the pointer. it's saying I cannot move it
al: dismissable - not implementable if not keyboard
sr: if ua cant make it appear SC is not applicable
al: if I have a pen and no keyboard, or a mouse only computer and no keyboard... then I fail
<alastairc> You hover away from the trigger+content.
al: have mouse attached but no keyboard, do I fail dismissable.
author could cause right click to cancel hover
ac: moving away from content is a method to dismiss
awk: perhaps don't move focus
sr: how does 2.1.1 pass if you don't have keyboard. this is the same issue. splitting hairs
<lisa__> +1 rto steve. it is up to the user to plug in the keyboard
awk: if content you creates
supports you are ok. author has no control of device.
... this scenario is not likely
<Greg> It would prevent an author from claiming conformance on certain closed systems.
al: many usecases. but closed
product environment
... no a major problem. if closed environ. close out
sr: few mechanisems, on touch have gesture, or have triple click. ESC is usual mechanism
mg: or click on hover element, not impossible. if no keyboard there would need to be a mouse mechanism to do it.
al: still thinking?
awk: any other concerns?
mg: SC about fixing bad user experience
<steverep> +1 to accept
awk: any objections to accepting as in pull request?
+1 to accept
<lisa__> +1
RESOLUTION: accept for CFC based on pull request #569
close item 3
open item 6
awk: tomorrow at noon, will have CFC for items in working draft.
<alex> alastair, not much, probably seen in the browsers mostly
awk: have somethings not in a
state to have in draft (addressed comments, etc.)
... purposes of controls, change of content, device sensors,
some AAA items
... some items not decided.
... weeks ago, we decided to a) leave out, or b) use old lang
and resolve any new comments. then these SC will go into
Candidate review as AT RISK
... easy thing to do is see what can happen by tomorrow, and 6
don't make it.
... some will not get done by tomorrow
... contextual info, animation, timeouts -possible,
interuptions minimum no cfc, purpose of controls no cfc, change
of content -no cfc
... no one wants to give up on any of them.
ls: label them At RISK not remove.
awk: they will not be lost .... silver or 2.2
ls: make a survey that acts as cfc, if AT RISK or remove, understanding that no time for discussion
awk: happy to send out 6 CFC, to
take out or AT RISK (leave as is)
... if we don't have concensus, goes in with last good wording.
if we can get concensus wording by tomorrow then ok.
ls: contextual information has not been discussed. CFC for wording with no discussion.
awk: do we have concensus on wording, yes -- ok, no -- put in AT RISK?
<lisa__> can we first run a cfc if people can live with the current wording
<Zakim> gowerm, you wanted to say which one is being discussed specifically?
awk: not trying to change process
mg: sounds like Lisa trying to change process
awk: contextual info. chairs need to decide on proposed language after review of issues and emails. then CFC. and put out for concerns. need lots of comments.
ls: that's why suggested survey.
awk: don't have time
ls: a CFC survey
awk: that would be different from
all other CFCs.
... as a straw poll
<Ryladog> +1
<lisa__> +1
<Kathy> +1
<alex> -1
awk: +1 to include old versions of non-concensus SC, -1 to remove non concensus ones
<laura> +1
<alastairc> +1, I'm assuming that negative comments knock them out unless we find time to discuss & get consensus.
<Bruce_Bailey> -1 inclined to omit
<Kathy> but mark at risk
<Brooks> -1
<steverep> 0, my answer is going to depend on the particular SC
<gowerm> -1 It really depends on the Scs
awk: AT RISK happens at CR not WD
<marcjohlic> +1 for awareness
<Greg> +1
<JF> 0
awk: slight weighting for includeing old lang.
<JF> yep... +0.4
awk: will review, send CFCs as
necessary tomorrow
... also, 2 CFC for change of content. if new wording fails,
then what happens - additional CFC
<Ryladog> +1 to new lang
kw: old lang is so different from new language. rather use new lang with a note rather than revert.
awk: add note with pointer to EDitor draft, review the new lang. but include the old language
ls: would be better to mark at risk but include new language. pointers etc will confuse reviewers as to what to review
awk: will think and do what we can.
<Bruce_Bailey> * is okay to hang out
awk: end of call. stay on to
review other SC.
... 10 min on purpose of controls
close item 6
open item 5
<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes2/guidelines/index.html#identify-purpose
<AWK__> In content implemented using markup languages, user interface components that serve purposes identified in the Identified Common Purposes for User Interface Components section can be programmatically determined.
<lisa__> +1 nicer
<JF> +1 to User Interface Controls
awk: make it only talk about UI components. need to change the handle
<lisa__> Iether ideify pourpose
<gowerm> I think if you make the title Common... then there is only one occurrence of "identified"
<lisa__> i like identify purpose
<laura> I like “Identify Purpose” too.
awk: in list of controls, there are definitions. some are marked at risk per yesterday call.
<lisa__> I think we should go with current list
<lisa__> would like to add mode back in ut i doubt there is time
awk: comment input controls
consolidated terms. some also at risk
... questions... comment input controls - focus on user. not
just any name.
<Zakim> JF, you wanted to suggest "Identify Common Purposes" (based upon the SC text that references Identified Common Purposes)
jf: user name vs other name as in airline reservation
<lisa__> +1
<gowerm> +1 makes sense
<lisa__> to iether name
jf: handle - id purpose
<Greg> +1 I like the proposal to rewrite the purpose list to clarify user, site owners, etc. Also "Identify Common Purposes" is also good.
js: metadata for form inputs,
must be very clear
... technique use the autofill info available in browser
<Makoto> +1 to "Identify Common Purposes"
awk: please comment on things you can't live with
mg: close to SC language
<JF> +1 to the minmor editorial change (remove Identified from the body text)
<AWK__> In content implemented using markup languages, user interface components that serve purposes identified in the Common Purposes for User Interface Components section can be programmatically determined.
<gowerm> +1
<JF> +1
paste in wording
<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#identify-purpose
In content implemented using markup languages, for each user interface component that serves a purpose identified in the Identified Common Purposes for User Interface Components section, that purpose can be programmatically determined.
<AWK__> In content implemented using markup languages, for each user interface component that serves a purpose identified in the Common Purposes for User Interface Components section, that purpose can be programmatically determined.
ls: prefer without "common" in handle. too hard to understand
mg: common is important, focus on specific list not free form
<gowerm> Yes, controlled taxonomy idea is critical
awk: if can live, we are ok
<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#commonpurposes
gl: what is change from previous draft
<lisa__> +1
<lisa__> In content implemented using markup languages, for each user interface component that serves a purpose identified in the Identified Common Purposes for User Interface Components section, that purpose can be programmatically determined.\
ls: purpose can be determined
gl: seems to look identical to original. but can live with it
awk: one difference from changes2
- removed all of the atRisk items
... comment - may be covered by compose, is it start comment or
submit comment
<Zakim> gowerm, you wanted to say I'm worried we're studing this list, but we haven't actually scrutinized the larger question. For example, there is no "confirm" which I just don't get
mg: worried about list, why no 'confirm' on every dialog
awk: specialize form of submit.
mg: like 'ok' button, confirming dialog box
<Greg> Lots of missing things, e.g. has First and Previous but not First and Last.
ls: many terms for submit....all merged
awk: be sure we won't have
everything. but have important things
... can we live with current list.
... go with atRisk items or no atRisk
<lisa__> include the onses marked at risk
ls: keep them tin
mg: wyy different version of help, its all help
jf: chat help, faq help - different
gl: page with links for different help - chat or faq
mg: contact us page. how many are
actions by mechanism.
... gethelp clarifies action.
... phone number generally not a link, not actionable
<lisa__> +1 with the at risks
mg: note should come out.
gl: leave in atrisk, favor granularity
<AWK__> If people want to put the AT RISK's in, +1, if not, -1
<laura> Leave them in. We can cut later if needed.
jf: can we add new items in January.
<lisa__> +1
<Greg> +1
<laura> +1
<gowerm> +1
<JF> +1
<Makoto> +1
<marcjohlic> +1
<Bruce_Bailey> +1
<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes2/guidelines/index.html#commonpurposes
<AWK__> http://rawgit.com/w3c/wcag21/purpose_of_controls_changes3/guidelines/index.html#commonpurposes
<AWK__> 2 has AT RISK items in, 3 doesn't
<Greg> Is there any major reason not to add OK/Accept?
awk: anyone want atrisk out
mg: remove not marked atrisk, how is remove different from delete. inclined to mark as atrisk
ls: ok with that
gl: have remove but no add
<alex> hard stop in 3mins
<JF> +1 to wordsmithing OnList
awk; micro managing. have other topics
awk: can we live with this at this time. can edit later per comments
gl: can we add items in Jan.
<lisa__> +1
awk: if things must be added, do it through the list.
<lisa__> +1
<Greg> +1 to add Add
awk: things without consensus will not be included as part of CFC
<JF> +1 to "Add"
<gowerm> +1
<laura> +1
<marcjohlic> +1
<JF> (+1 to "Confirm" too)
<Makoto> +1 to Add
awk: is this all about USER INFORMATION
<lisa__> +1
awk: anyone not agree user information
no objections
awk: several at risk
<lisa__> (of the user)
<lisa__> email -email address (of the user)
awk: what is topic?
ls: we can take it out
awk: comment?
<JF> Topic is for email, or occasionally commenting (think Disqus)
ls: that;s were you add your comment
awk: neither is in autofill
... very different. not related to user
jf: these seem to be unique, topic of email, feels obvious to me.
<lisa__> (+1 to "Confirm" too)
ls: overlay for developer.
awk: comment is out, topic is
out
... will edit branch and delete other branches.
... any comments to 7.1 list by 1130 tomorrow.
... 7.2 list came from autofill
<lisa__> org -the user’s company or organization
RESOLUTION: leave open pending comments to list by 1130 tomorrow
mg: much rather say - UserName, etc.
awk: use the list.
<Greg> Agreed, changing names to "User Name" etc. it would help clarify.
<AWK__> TPAC version? All functionality of the content can be operated without requiring specific device sensor information, unless the device sensor is essential for the function and not using it would invalidate the activity.
kw: tpac changes. two verison SR with minor changes, or tpac version
<Kathy> https://www.w3.org/2002/09/wbs/35422/resolving_device_sensors/results
sr: discussed a few days ago.
motion actuation by AT in the note.
... other version with bullets
discussion of version history
<Kathy> https://www.w3.org/WAI/GL/wiki/Comment_Summary_2-6-1
<AWK__> <p><a>Functionality</a> which can be operated by device or user motion can also be operated by <a>user interface components</a> and can be disabled to prevent accidental actuation, unless the motion is <a>essential</a> for the function and doing so would invalidate the activity.</p>
https://github.com/w3c/wcag21/pull/378
<AWK__> <p class="note">This criterion concerns input through sensors which respond directly to motions such as tilting, shaking, or panning. It is not intended to cover indirect motion associated with operating a keyboard, pointer, or assistive technology.</p>
sr: from call a few days ago,
wording changed to keyboard pointer.
... can live with any of these versions, as long as not the
version in current draft
<AWK__> Functionality which can be operated by device or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology
awk: moved note information
(nonNorm) in to a bullet (normative)
... any concerns?
sr: none, I have none
gl: have a few
kw: no open issues
gl: editorial. 'can be operated by device or user motion'
mg: device motion would be good to clarify
<AWK__> Functionality which can be operated by device motion or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology
sr: can't loose user motion
gl: moving anything is user motion. haptic feedback.
mg: use note to define User Motion
awk: when is a user motion a
failure?
... if you remove pointer and keyboard motion, what is not
covered
gl: no example
<gowerm> +1
awk; can we live with this language?
Functionality which can be operated by device motion or user motion can also be operated by user interface components and can be disabled to prevent accidental actuation, except when: • the motion is essential for the functionality and doing so would invalidate the activity. • the motion is used to operate a keyboard, pointer, or assistive technology
sr: or other accessibily supported device
<gowerm> yes
awk: ok with language?
... send out for CFC
<gowerm> +1 to cfc
<laura> +1
<JF> +1 to CfC
<Makoto> +1
RESOLUTION: accepted as amended above for Device Sensor
SR will update pull request
<Kathy> thank you
<AWK__> (see pull request 578)
https://github.com/w3c/wcag21/pull/378
sr: any change to handle
<Joshue108> thanks all :-)
awk: major scrubbing to happen.
<AWK__> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 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/.me wasn't you JF// Succeeded: s/eithe'/either'/ Succeeded: s/snese/sense/ Default Present: MikeGower, JF, Joshue108, alex, MichaelC, Rachael, Bruce_Bailey, Greg_Lowney, Makoto, Brooks, AWK, marcjohlic, Laura, Katie_Haritos-Shea, Kathy, SteveRepsher, alastairc, Lisa Present: MikeGower JF Joshue108 alex MichaelC Rachael Bruce_Bailey Greg_Lowney Makoto Brooks AWK marcjohlic Laura Katie_Haritos-Shea Kathy SteveRepsher alastairc Lisa Regrets: David Found Scribe: gowerm Inferring ScribeNick: gowerm Found Scribe: Kathy Inferring ScribeNick: Kathy Found Scribe: gowerm Inferring ScribeNick: gowerm Found Scribe: jallan Inferring ScribeNick: jallan Scribes: gowerm, Kathy, jallan ScribeNicks: gowerm, Kathy, jallan WARNING: No meeting title found! You should specify the meeting title like this: <dbooth> Meeting: Weekly Baking Club Meeting 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]