See also: IRC log
<wilhelm> (We're waiting for the last laggards, starting a little later than planned.)
<scribe> scribe: simonstewart
<wilhelm> Scribe: simonstewart
MikeSmith asks if there's anyone new
garykac Gary Kacmarcik
garykac from Google
<garykac> s/Kacmarik/Kacmarcik/ ^_^
Alois Reitbauer - interest in console api
MikeSmith: no-one's working on the console api right now, but if we had an editor
More introductions (same as yesterday)
wilhelm, MikeSmith, MarcFisher
wilhelm looks up meeting agenda
First topic: interactions
garykac: the components that the DOM spec needs.
Mouse is pretty simple: just need mouse move, over, etc. Seems straight forward
Keyboard events: want to be able to test US ASCII, but also international keybaord. Want to test "given a layout, what events are generated"
Being able to automatically change layout is desirable.
Also generate dead keys
Also creating IME composition events
Those are the big things. Undoubtedly need more
<wilhelm> Scribe: wilhelm
simonstewart: Mouse is pretty
... There's a limited range of APIs that we're expecting to generate.
... click, dbclick, contextclick, mousedown, mousedown.
... These events are on the other side of the glass.
... How does the browser process all these things?
... We discussed yesterday scroll wheel.
garykac: Would that include ticks? There's pixels and ticks.
... Keyboard: presskey, releasekey, send a string of characters
... Just a charsequence.
... With webelement.sendkeys, we allow people to send internationalized text
garykac: For Japanese, I don't want to send the full string.
simonstewart: The commands on
webelement are do-as-I-mean.
... The advanced actions are do-as-I-say.
... Initial implementation just blasted the value in.
... To do the second case, there is the ability to have a IME engine in the open source web driver.
MarcFisher: There are functions to call, but they are not neccessarily working.
... Will list the available engines.
... Your test will be very brittle, as it relies on a specific IME engine.
garykac: Scan code?
simonstewart: Initial implementation does some calculation to figure out the scan code. Specify A, queries the OS.
garykac: This needs to be
controlled in the tests.
... I want to test A on a French keyboard...
simonstewart: We're not an OS
level automation API, but browser. We'll take advantage of the
... For testing multiple keyboards, you may need multiple VMs.
garykac: That will not work.
simonstewart: I'm not aware of any cross-platform IME...
garykac: I thought we'd have OS specific components.
simonstewart: And we attempt to
... ChromeDriver, Marionette inject events right into the event queue.
... Looks like it comes from the OS.
... FFdriver and IE on Win uses Win32 APIs.
... The OS makes some assumptions about focus of windows.
... For accurate emulation, you need to go through the Win32 APIs.
... These tests take a long time to run.
... Must be able to run without focus, for parallell processing.
... spec has three audiences: People writing tests for their web apps.
... Browser vendors.
... Spec editors.
... Low-level, cross-platform method is incredibly challenging.
... TBH, we don't ahve the expertise around this table.
... Maybe you.
garykac: Injecting keyboard events into @@ is something that we do.
simonstewart: Unfocused windows?
garykac: Win yes, Mac no.
simonstewart: Mac has a mouse window and keyboard window.
garykac: I have less concern
about the machine doing something else.
... Interop between browser vendors. Difficult to run tests will not be run.
... You inject cooked browser events?
simonstewart: Depends on the
... IE: three methods. Synthetitc JS events.
... A library I wrote.
... Attempts to put raw events into the Windows message queue.
... Scan codes, et.
...3: Use something like sendkeys.
garykac: Concern: Translation
from OS events...
... Given this sequence on Windows, all browsers should get the same.
simonstewart: Out of scope?
dburns: In the way we insert
trusted events into the browser, we depend on library in
... Mobile, desktop.
simonstewart: Mobile is maybe the
... Uses accessibility API.
... Good emulation by accident.
... Suggestions on how this can be done?
... We don't want to give the browser window OS focus.
garykac: There's parts of it that
can be used.
... Mouse will be useful.
... If we're not generating the keys on the OS level, that might not fit.
simonstewart: Huge problem.
garykac: Huge because it's lots of small things.
simonstewart: And you've got at
least two axes. OS, browser.
... IME, third axis.
garykac: Different keyboard layouts.
simonstewart: French dvorak...
garykac: SOme keys are not
... Writing OS specific tests must happen for this
simonstewart: Does Win32 sendkeys do what you need?
garykac: We sometimes want to know what the physical key is. Need more information.
simonstewart: The IME
implementation we had worked on Windows and Linux.
... You could take these from the project.
simonstewart: *explains code just
... *explains relationship between Selenium / WEbDriver*
... You can use WebDriver to get the browser to a specific palce.
garykac: Can it check the OS state?
... *proposes a mixture of WebDriver + native OS code*
... If this was easy, we'd have done it.
garykac: I want to reuse as much
as I can.
... Where are the live, valid sets of tests?
simonstewart: If you have
suggestions for teh API, given our constraints.
... *lists currrent API*
garykac: Everything else comes from that.
simonstewart: Using PUA from
Unicode to specifiy other characters.
... Return key, etc.
... Based on meaning.
garykac: DOM3 har those based on
... UI events has keynames based on the physical key.
... This key, Q, on English keyboard, is the same no matter which keyboard layout you have.
garykac: If you have to give the name to a physical key, use UI events.
simonstewart: *refers to the key list from the implementation*
<garykac> UI Events: http://www.w3.org/TR/uievents/
garykac: Is this all?
garykac: No location field to indicate it's from the keypad?
MarcFisher: Just a string.
garykac: *ask about specific keys in the list*
MarcFisher: suggestions for improving the API are welcome.
garykac: We've worked on speccing the list of keys in DOM3.
<garykac> DOM3 Events: http://www.w3.org/TR/DOM-Level-3-Events/
<garykac> Section 6.3
garykac: Section 6.3
... I'm going to be merging the UI events stuff into this.
... SO that there is one canonical document.
... UI events provides more info on how awful keyboards are...
... This maps to Windows virtual keys.
... Assumes we have a location field.
... This is only the non-printable.
... This also includes old keys.
... Media keys.
... You may want to refer to this and say "this is where we get our values from".
... You may need location fields.
... This completely ignores Android + FirefoxOS, which we also need.
simonstewart: So far we haven't needed most of these keys...
garykac: Thank you for the information!
simonstewart: I've learned a lot
about the horror that is keyboards.
... Reviews of our sections on this would be very helpful.
<scribe> ACTION: Add scrollwheel support [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action01]
Michael Cooper, staff contact
@@, with IBM
MichaelC: A number of us were
here at TTWF. Some of this may be familiar.
... We want to sync the accessibility testing with other testing.
... THis is an iteration of these efforts.
... IN the past few days we've got a better understanding.
... Suggested agenda items:
... Developing accessbility tests from the point of view of a developer who wants to ensure accessibility in the UA.
... We test tools, content.
... We talked about how WebDriver can be used to test web pages in UA to see if accessibility features work as intended.
... May depend on things from WebDriver.
... How can we use WD to test accessibility tests?
... We develop ARIA, which could be tested that way.
... Considering accessibility tests that can be done like the testharness.js, reftests...
... If we wish to add tests?
wilhelm: tobie's department.
MichaelC: Mapping accessibility
APIs to testing...
... Accessibility vs DOM.
Janina: The best defined are the
UA interfaces to accessibility API.
... On their way to Rec.
... We're looking at that approach for basis for furhter work.
MichaelC: What level of shared knowledge do we have?
simonstewart: *describes the purpose and functionality of WebDriver*
@@: JS in the browser?
@@: Are you using Windows automation?
simonstewart: It depends.
... We need to be able to test browsers without window having focus.
... We should be able to background the window.
... (Describes the three types of events and their implementations.)
Cynthia: Assisstive technologies
use OS accessibility layers to interact with f.x. UA.
... Old MS API, IBM API, newer MS Windows automation...
... Windows UI automation was designed with a couple of ideas that are different.
... To be used as a test driver in addition to accessibility.
... Combine patterns. Invoke, selection.
... "This is an invokable thing, not just a button"
... You can combine patterns.
MichaelC: The accessibility APIs do similar things, but vary between OSes.
Janina: Linux accessibility layer used for testing Linux desktop.
<simonstewart> What was the name of the linux project that uses accessibility testing?
Cynthia: You're doing platform-specific work.
simonstewart: Yes, but hidden behind the APIs.
Cynthia: We look at the markup in ARIA or HTML and our document, "this document should have these properties".
simonstewart: Forms of
accessibiltiy testig already done with WD include: test
... We also had element-by-ARIA.
... Could be used via XPath.
Janina: Would have been useful.
simonstewart: We disucussed the
equivalent of a DOM in accessibility.
... Maps to DOM.
Cynthia: This exists, but outside the browser.
Jason: Some UAs already have
OS-level accessibility integration. Unifying would be
... Interested in interaction between this approach of testing with WebDriver and Indie UI.
MichaelC: They are do what I mean-events.
simonstewart: *describes the
three audiences of WebDriver*
... It sounds like you're interested in the first audience, third audience.
MichaelC: Third audience.
<simonstewart> (spec authors)
Cynthia: Adding accessibility
tests to web application tests...
... WCAG has techiniques for testing. Automation? Done manually now.
Janina: Can you tab to the submit button?
simonstewart: You may be able to
do a lot of it already.
... Tabbing stuff should be easy.
... WebDriver has findElementByTagName.
... Tab, find the active element.
Cynthia: img.onclick, etc. are tricky. Buttons are not.
simonstewart: Finding elements with a click handler is more difficult.
MarcFisher: But possible with JS.
MichaelC: Challenge with accessibility spec testing: we have to test how the spec shows up in different accessibility APIs.
Cynthia: You are using some of those APIs for driving?
simonstewart: Chrome and Firefox
inject blessed events into their event queues.
... Nowhere near OS.
... We're trying to avoid the OS-level stuff, because the requirement of not having window focus is important.
... QAs often don't ahve more than one machine. Must be able to test while doing other work.
<scribe> ACTION: Cynthia to find the right people at MS to talk about UI automation [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action02]
MichaelC: I want to get to a next-steps-hase.
Janina: We're closing on ARIA
... 1.1 is interesting. Sovling new problems.
simonstewart: How would you like ARIA 1.0 to be exposed?
Cynthia: You're always going to
be looking at the role.
... Actual attributes.
MichaelC: We're looking at the accessibility API...
Cynthia: COmpare expected results
with outout from OS-level API.
... Testing that the markup was mapped correctly to the API.
... Manually, using inspector.
... SOme of these tools are automatable.
simonstewart: Focus of WD is
automating the browser. Already a massive challenge.
... If there was some common accessibility DOM in the OS, that can be integrated with WebDriver.
<simonstewart> Not OS: browser
<simonstewart> /accessibility DOM in the OS/accessibility DOM in the browser,/
MichaelC: It sounds to me that
WebDriver would help us do some testing of the accessibility
... BUt not a lot.
... We've mostly been avoiding those, as they are all manual.
... We can improve our test suite with automation.
simonstewart: WD is a library you can use to poke the browser. You could use another library to poke the OS accessibility layer.
MichaelC: More potential for accessibility testing re: WCAG.
simonstewart: If there's something we can do to facilitate testing of accessibility in web applications.
Cynthia: Something that comes up as a button in the accessibility API can be any element with role=button.
simonstewart: It would be interesting to track progress on Accessibility DOM.
<scribe> ACTION: Our group to take a look at WCAG hard fails and understand them [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action03]
<MichaelC> WCAG 2.0 Techniques
<simonstewart> That's a huge amount of work
MichaelC: *explains how WCAG techniques are described*
Cynthia: These are the most common failures.
MichaelC: We should keep in touch.
dburns: Probably F2F in Q1 in California.
MichaelC: By then, we could have a proper agenda. This is more of an exploratory meeting.
We resume at 11:30.
<gitbot> [13web-platform-tests] 15zcorpan closed pull request #431: Update the VTTCue test names (06master...06vttcue-title) 02https://github.com/w3c/web-platform-tests/pull/431
<simonstewart> MichaelC: thank you!
MikeSmith: Our charter expires at
the end of the year.
... dburns has already posted on the list about this.
dburns: What we're proposed is LC around March next year.
Q1 vs Q2?
simonstewart: MY suggestion was
aim for Q2, with a checkpoint at the end of Q1.
... If we give us a too tight deadline and fail to meet that, rechartering will be a pain.
<simonstewart> wilhelm: we keep on setting dates in the calendar, but first of all we need to figure out what needs to be done to get the spec and test suite to where it needs to be
<simonstewart> scribe simonstewart
<simonstewart> wilhelm: we keep on setting dates in the calendar, but first of all we need to figure out what needs to be done to get the spec and test suite to where it needs to be
<simonstewart> ... does that make sense
<dom> scribenick: simonstewart
MikeSmith: I don't think it makes
that much difference on what we decide. We do need to
demonstrate progress and milestones to aim for
... as long as we have that, we're ok
plh: can go to management and say
that things are moving forward, though not at LC yet
... just a mattter of convincing colleagues. Not currently getting pressure to actually getting it finished.
AutomatedTester: Another nice thing is that we're further along in the implementations than we are in the spec.
plh: only thing I'm worried about is people who aren't sponsored by a company being able to make meetings
wilhelm: one other thing that we've discussed is scope creep. Solution proposed earlier is to move unstable pieces to a separate document
plh: that's a common solution
AutomatedTester and simonstewart: both happy to edit two documents
MikeSmith: other thing I want to ask about is extension duration. Is there an outside limit?
plh: two years is a limit, but as a checkpoint
MikeSmith: not planning on making any changes to the charter itself.
plh: try to be realistic
simonstewart: so, milestones. Work items first
MikeSmith: testing and spec work are the two pieces.
simonstewart: going through the spec and identifying things to pull out into 1.1 and fill out placeholders
wilhelm: also need to look at the
OSS test suite for things that need to be specified
... suggests going through the OSS test and adding official tests and placeholders for the spec
... added a wiki page (webdriver/testsuite) started listing tests we don't have but should
simonstewart: do we want to go through that suite now?
wilhelm: split up and do in
... maybe that's a day's work per chapter?
MikeSmith: set some milestones
wilhelm: should probably base those on labour
simonstewart suggests writing up possible milestones. MikeSmith starts writing
<scribe> ACTION: Milestone 1: go through OSS test suite and identify tests to copy to official test suite. [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action04]
<scribe> ACTION: Milestone 2: add placeholders for areas not already specified [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action05]
<scribe> ACTION: identify sections in existing spec to move to 1.1 [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action06]
simonstewart: shall we try and identify the areas to remove now?
<AutomatedTester> scribe: AutomatedTester
simonstewart: 7,4 to be removed
MikeSmith: are we dropping or moving?
simonstewart: moving to 1.1
... 11.4 reporting errors on JS errors to be moved to 1.1
MarcFisher: and its completely empty so thats fine
<scribe> ACTION: David Burns, completing 17.2 [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action07]
simonstewart: move 17.3 to
... this is all based on the working published versions
<scribe> ACTION: David Burns upstream element screenshotting [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action08]
simonstewart: missing the HTTP normalisation which is important for 1.0 and we need to put that in
<scribe> ACTION: simonstewart to add HTTP normalisation for the JSON Wire Protocol [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action09]
MarcFisher: logging is missing
simonstewart: I have that half written already
wilhelm: IME? lets move that to
... its currently unstable in all implementations
simonstewart: DOM events, UI events... do we want to work with that in 1.0 or 1.1?
wilhelm: is that important for now?
simonstewart: our keyboard
mappings are how we encode them for sending them over the
... our commands are simple
Mfisher: we may need to tweak
simonstewart: at a later version we may need to add to handle more DOM Events
mfisher: keyup and keydown is missing?
simonstewart: its implemented in the OSS project for all browsers
mfisher: the Dart implementation may not have this information
simonstewart: are there other
ommissions that we need to put in
... we will move authentication to 1.1
... (explaining how authentication may work in the future)
... Basic auth is important bug on the OSS project
(all discussing connecting to a running browser)
simonstewart: HTML5 offline technology, do we care ?
MikeSmith: lets no worry about
the offline tech
... Geo location?
wilhelm: should we move it to 1.1 or hold up 1.0 for it?
automatedtester: lets move geolocation to 1.1
wilhelm: how many unique tests in that repo?
... checking its actually over 1000 tests
<simonstewart> The highly scientific mechanism for getting this number: grep -r "@Test" java/client/test/org/openqa/selenium/ | grep -v html5 | grep -v firefox | grep -v htmlunit | grep -v support| wc -l
<simonstewart> (in the root of the OSS project)
wilhelm: based on this data we
can start to make realistic estimates
... I used to do 30minutes to 1h so that is a lot of time on that alone
simonstewart: do we have proxy
configuration in the spec?
... we dont appear to have that
MarcFisher: that is a lot of tests and 30 is very conservative. We could automate this
AutomatedTester: we need to do manual checks agains the spec when converting so we can't automate it
MarcFisher: it could still be ~300 hours
wilhelm: lower than 10 minutes per test is day dreaming
simonstewart: do we have implicit and explicit timeouts
MarcFisher: we already have timeouts
<simonstewart> grep -r "@Test" java/client/test/org/openqa/selenium | grep -v html5 | grep -v firefox | grep -v htmlunit | grep -v support | grep -v v1 | grep -v safari | grep -v browserlaunchers | grep -v "/rc/" | grep -v remote | grep -v IgnoreComparitorUnitTest.java | grep -v "/io/" | grep -v "/os/" | grep -v "ArchitectureTest.java" | wc -l
<simonstewart> 878 tests. Ish. To port.
simonstewart: we have 878 tests according to my command line tool
MikeSmith: who is going to review those?
simonstewart: David and
... tests are easy to move
AutomatedTester: Andreas Tolfsen has been reviewing too
MikeSmith: we own that section and dont need others for review?
simonstewart: no we can do that
wilhelm: how much effort to do the prose in the spec?
simonstewart: we need to visit 10.1 again and clean that up
MarcFisher: 14 needs to be
... section 6 needs more prose
simonstewart: we can move 6.6 to
... we need to get someone to look at the webidl
AutomatedTester: Dictionary wasnt useful and there is an outstanding bug. I have looked at the alternatives but the don't know what is useful
<scribe> ACTION: David Burns to speak to heycam or bz about WebIDLs needed [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action10]
(discussion about thread safety)
simonstewart: for fleshing out
the text would be 2-3 weeks
... does logging and http
... David Burns can do user inputs
... and others can help too
... and then a few editing passes are required
we need to fix the WebIDL output
MikeSmith: we are going to be
doing snapshots regularly but we are getting away from that in
... we are going to be removing TR from robots.txt
... to make sure implementors always find the editors draft
wilhelm: we could do this regularly
MikeSmith: to get to TR we need
to pubrules within W3C
... lets worry about editors drafts for now
wilhelm: can we tell people to use the editors draft
<scribe> ACTION: MikeSmith to put a note on the TR to tell people to use the editors draft [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action11]
MikeSmith: based on this and we need to think about when we will hit LC
wilhelm: we are looking at 600hrs worth of work
simonstewart: I am freeing up 1/2 a day a week
automatedtester: I am getting more free time
MarcFisher: I should be able to do 1/2 day a week too
AutomatedTester this is roughly 75 work days (600/8)
ShuotaoGao: I can do that too
MarcFisher: we can do 3/4 days a week by the sounds which is ~36 weeks
simonstewart: maybe we do a writing week on this
(discussing F2F next year to get people to work on spec)
<wilhelm> We reconvene at 14:00.
<jgraham> So, if anyone at TPAC cares, I am about to talk about test code review and demo review tools including critic in WebApps
<jgraham> There are plenty of spaces
<darobin> ah shit, I'm in another meeting
<ArtB> (Shenzhen meeting room)
<ArtB> if you hurry, we can try to find an empty seat for you ;)
MikeSmith: hey, do you need help from a Bugzilla dev?
<simonstewart> scribe: simonstewart
AutomatedTester: Before lunch we were talking about 36 weeks to get everything done.
wilhelm: that takes us to the 22nd July
MarcFisher: we could drop that down if we did more work per week
AutomatedTester: That plus one week contingency. Suggests 1st August 2014 as the LC date
wilhelm: suggests a full year extension to the charter
AutomatedTester: Not sure how long between LC and CR, and then REC
MikeSmith: LC comments period is
a minimum of three weeks
... commonly extends to six weeks
... most people wait until the end of the LC comment period before submitting comments
... takes a week or so until after comments close before you normally publish another draft
... need to write up a Disposition of Comments documnet
... minimum of a month from LC to CR.
... One thing to mention: we could skip CR so long as we were confident that we would meet our CR exit criteria (normally 2 interoperable implementations)
<scribe> ... (done by each statement in the spec that gives a conformance requirement)
UNKNOWN_SPEAKER: Can do this if you say upfront in the LC draft to transition directly to PR
simonstewart: would we need to recharter to handle 1.1?
MikeSmith: the charter doesn't limit us to only one document
wilhelm: should we charter for two more years so that we can move to 1.1 after 1.0?
MikeSmith: we don't need to come
up with a new charter if there's a new deliverable after
... suggests chartering for two years
... within two years we may want to recharter. Or we could declare victory and finish
... Though I think we should keep the group open, since people will start reporting issues once they start using the spec.
... * the story of XSLT 1.0 in browsers *
wilhelm: suggests describing 1.0 as a feature set, rather than "being complete", to allow for changes
MikeSmith: this gets to the
difference between a living standard, or having separate
... within the W3C model, levels seems like the way to go.
... So for now aim for LC in August? Build into the schedule a CR period, but can consider in August if we need to
simonstewart: Everyone agree?
* everyone agrees *
<scribe> ACTION: MikeSmith: write up schedule ASAP for getting us the extension from plh. [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action12]
wilhelm: shall we set some tentative dates for the next f2f?
MarkFisher: some time in Q1
AutomatedTester: suggests last two weeks of February.
simonstewart: Last week of Feb
wilhelm: week of Mon 25th Feb
AutomatedTester: mozilla to host
<scribe> ACTION: AutomatedTester get agreement for Mozilla to host [recorded in http://www.w3.org/2013/11/12-testing-minutes.html#action13]
AutomatedTester: Need to confirm dates with MS
MikeSmith: since it's a week, see if there are other people who want to meet up (webapps? components?)
AutomatedTester: accessibility meeting up in that time?
wilhelm: do we need a meet up in London?
AutomatedTester: not a formal one, but we will meet up
simonstewart: Looks like we're done for now.
RRSAgent draft minutes
RRSAgent: draft minutes
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Kackmarcik/Kacmarik/ Succeeded: s/Kacmarik/Kacmarcik/ WARNING: Bad s/// command: s/Kacmarik/Kacmarcik/ ^_^ Succeeded: i/Introductions/Topic: Introductions Succeeded: s/@@/Alois Reitbauer -/ Succeeded: s/_win 27// Succeeded: s/MikeSmith/MikeSmith, Chris Gao/ Succeeded: s/feels/fields/ Succeeded: s/Topic/Topic: PFWG/ Found Scribe: simonstewart Found Scribe: simonstewart Inferring ScribeNick: simonstewart Found Scribe: wilhelm Inferring ScribeNick: wilhelm Found ScribeNick: simonstewart Found Scribe: AutomatedTester Inferring ScribeNick: AutomatedTester Found Scribe: simonstewart Inferring ScribeNick: simonstewart Scribes: simonstewart, wilhelm, AutomatedTester ScribeNicks: simonstewart, wilhelm, AutomatedTester WARNING: No "Present: ... " found! Possibly Present: Alois ArtB Cynthia ISL Janina Jason MarcFisher MarkFisher Mfisher MichaelC MikeSmith ShuotaoGao TieSun a12u abarsto automatedtester cwdoh darobin dburns denis dom edoyle garykac gitbot glenn glenn_ https ijongcheol inserted jgraham kawada ken kennyluck kimwoonyoung masahiro miao-cesi minami mizuman mizuman_ myakura myakura_ plh rhauck rhauck1 rhauck2 scribenick shepazu sho simonste_ simonstewart taocai tobie wilhelm yuanyan zcorpan zcorpan_ zqzhang_ zqzhang__ You can indicate people for the Present list like this: <dbooth> Present: dbooth jonathan mary <dbooth> Present+ amy Got date from IRC log name: 12 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/12-testing-minutes.html People with action items: 1 add agreement automatedtester burns cynthia david for get go group identify mikesmith milestone mozilla oss our simonstewart suite test tests through[End of scribe.perl diagnostic output]