See also: IRC log
<jo> ACTION-837?
<trackbot> ACTION-837 -- Kai Scheppe to provide explanatory text for the addendum which will put the document (mobileOK Pro Tests 1) in the correct context and explain to the audience that it is intended to aid content authors in creating still better content. -- due 2008-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/837
http://lists.w3.org/Archives/Public/public-bpwg/2008Sep/0015.html
<jo> ISSUE-272?
<trackbot> ISSUE-272 -- What is the new name of document, currently called "mobileOK Pro Tests Version 1", which is supposed to be an addendum to the Best Practices document, to be? -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/272
DKA: Have people been able to read this text
<scribe> Scribe: Bryan
Dka: what is current status for text posted by Kai
Kai: working thru ideas for restructuring possibly into new version of BP, it's still open to some degree
Jo: An addendum could clarify
where extra information may be helpful re te tests of BP1. The
info could be put into the BP without reference to the
DDC.
... Including the text with guidance on parameterizing the test
info could improve the testability of the human testable
ascpects and comment on the machine testable aspects.
dka: So the approach is splitting off the explanations into one section and the test details into another, but we need to decide what to do with the 3rd i.e. the erratta to mobile OK basic.
<jo> Three possible purposes in respect of clarifying the BPs: a) expand upon any BP text that is not clear, b) clarify and add to the human testing bits and 3) expand upon the machine testable bits and additionally to comment on parameterization of the DDC related tests there (e.g. that the values in mobileOK basic are specific to the DDC and using those values on non DDC devices is not...
<jo> ...necessarily appropriate)
kai: No sure what we are trying to achieve with splitting off the errata type info; with the current focus on human testable aspects it may get confused if we split it up and reapply it to the BP
dka: concerned about extra work without a lot of gain
kai: we need to focus on the document user, having the info as an combined addendum is OK for document use; we also need to make the focus on the DDC explicit
dka: the extra work should be minimal
kai: still there are open points in the addendum, not sure whether it belongs there
dka: this needs to be ironed out before publication
kai: there is value in the open notes, as guide on what needs to be thought about; there is a lot of information there if we are interested in keeping it
jo: agree that there are many
ways forward; grouping under the BP's makes sense; not too
happy with the idea of this as a self-certification test
... we should either follow the approach in the BP or in mobile
OK basic, and not fall in the middle; recommend putting into
the form of the BP's including removing the pass/fail
verbage
kai: would be OK if we gave "have you considered" guidance in the context of each BP?
jo: that chatting approach is consistent with the BP's
kai: that would be fairly easy to
do
... can come up wth an example of the approach before jumping
in wholly
... it will take a couple of weeks
<DKA> ISSUE-272
kai: there is the name issue to consider
dka: we have suggestions from kai and others on the list; we should take a resolution on this
<Kai> PROPOSED RESOLUTION: The group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format
dka: needs to be crispier
<Kai> PROPOSED RESOLUTION: The group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage
<DKA> PROPOSED RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage.
<DKA> PROPOSED RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage. Document also to be flattened by merging information into fewer subsections.
jo: suggests that the commentary sections be reworded into less test-like terms, and call out where needed where this relates to non-DDC
kai: the assumption of the doc is the DDC, there are some "use various devices" type guidance, but it would help to clarify that this is based on the same assumption as BP1
<DKA> PROPOSED RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage.
<jeffs> +1 to try this and see how it looks before finalizing
<jeffs> +1 on explicit DDC statement
kai: is there argreement that we need to explicitly state the DDC is the focus of the tests?
dka: we need to watch out; there is pushback on the DDC; we may need to soft-pedal the dependency; the link to BP1 already provides that
kai: we need to be explicit about the DDC since there are many tests that are based upon this assumption
dka: wouldn't there be an issue if we reinforce the DDC?
<jeffs> if there are tests which depend upon the device context, then we need to be explicit about that
<Zakim> dom, you wanted to make a proposal
jo: the DDC has served its purpose, but the example kai gives is one that we should clarify; there may be flexibility we could mention to include more capable devices in the test
dom: DDC is one of the delivery context properties; for each test we should identify the context properties that are relevant, in general
kai: we should explain this for each test?
dom: for specific tests, we should clarify dependencies on the properties of the test device where important
kai: a good point, but it may change direction of the document, toward adapting content to various device types rather than the DDC
dom: assume that there would be a few properties that are relevant
kai: we could mention the few relevant to each test, but that again takes the text in a new direction
dka: that doesn't keep it simple; would error on the keep it simpler side; can we do what Dom suggests easily?
kai: we can remove pass/fail to make it easier; I can focus on the delivery context and see where some further details can be added
<Kai> PROPOSED RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage.
<jeffs> +1
dka: we need to close off this issue and the new name as well
<DKA> PROPOSED RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage.
RESOLUTION: Regarding BP1.5 - the group will accept the document "addendum" as long as the wording is toned done from a testlike format to a more casual format, by removing the PASS/FAIL verbage.
<Kai> ACTION: Kai to change the Addendum according to the resolution about toning down the test character of the document [recorded in http://www.w3.org/2008/09/18-bpwg-minutes.html#action01]
<trackbot> Created ACTION-847 - Change the Addendum according to the resolution about toning down the test character of the document [on Kai Scheppe - due 2008-09-25].
dka: we need to schedule an editorial meeting 3-4 hours e.g. next week
<Kai> ACTION: Kai to sprinkle in delivery context information (DDC and others) where appropriate [recorded in http://www.w3.org/2008/09/18-bpwg-minutes.html#action02]
<trackbot> Created ACTION-848 - Sprinkle in delivery context information (DDC and others) where appropriate [on Kai Scheppe - due 2008-09-25].
dka: Friday 26th from 14:00-17:00 OK time
adam: have made resolutions for
some of Bryan's comments and prepared some draft text, we can
continue next week
... issues, not resolutions
dom: there were some that didn't make it by the deadline; they can re-signup
<dom> ACTION: Dom to check about missing Korean participants [recorded in http://www.w3.org/2008/09/18-bpwg-minutes.html#action03]
<trackbot> Created ACTION-849 - Check about missing Korean participants [on Dominique Hazaël-Massieux - due 2008-09-25].
dka: there was some issue with the Korean TF members perhaps a communication issue; we could reach out to help them as needed
jo: working thru the LC comments; steady progress
alan: sent a message about the page re how to do BP and WCAG at the same time; needs text
dka: since this isn't a standalone document, we could make this an overview section
alan: will review this in
upcoming meetings
... WCAG 2.1 won't be final for some months; WCAG has been
liasing with other groups on review against their guidelines,
but they haven't started that yet
jeffs: any group issue with the email proposal on practical code examples? starting to get some interest from experts on accessibility, but don't want to get in the way
alan: had not planned to include code examples
jo: unsure about this, not sure whether we need to continue in this direction, we should discuss the direction off the call
dka: looking at Dom's list of proposed issues to close
<dom> ISSUE-134?
<trackbot> ISSUE-134 -- COLOR CONTRAST -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/134
<DKA> PROPOSED RESOLUTION: Close ISSUE-134
RESOLUTION: Close ISSUE-134
dom: issue 134 (color contrast), we should close unless further discussion
<dom> ISSUE-185?
<trackbot> ISSUE-185 -- What are the mobileOK Full deliverables? -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/185
<jeffs> +1
<DKA> PROPOSED RESOLUTION: Close ISSUE-185
RESOLUTION: Close ISSUE-185
<dom> ISSUE-236?
<trackbot> ISSUE-236 -- Does the mobileOK TF need to create device which emulates the DDC for testing? -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/236
<DKA> PROPOSED RESOLUTION: Close ISSUE-236
RESOLUTION: Close ISSUE-236
<dom> ISSUE-189?
<trackbot> ISSUE-189 -- Allow more than numeric accesskeys in mobileOK -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/189
<DKA> PROPOSED RESOLUTION: Close ISSUE-189
RESOLUTION: Close ISSUE-189
<dom> ISSUE-254?
<trackbot> ISSUE-254 -- Revision of DDC and Retroactive Effect on BP1 -- OPEN
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/issues/254
<jeffs> +1
<DKA> PROPOSED RESOLUTION: Close ISSUE-254
<DKA> PROPOSED RESOLUTION: Close ISSUE-254
RESOLUTION: Close ISSUE-254
<dom> DKA, please a 15 min slot on MW4D to the F2F agenda
<DKA> http://docs.google.com/Doc?docid=dd3jk8v_128gb3xp5hq&hl=en
<dom> ACTION-835?
<trackbot> ACTION-835 -- Dominique Hazaël-Massieux to contact Stéphane to see if he is interested in presenting MW4D to BPWG at TPAC -- due 2008-09-11 -- PENDINGREVIEW
<trackbot> http://www.w3.org/2005/MWI/BPWG/Group/track/actions/835
<dom> close ACTION-835
<trackbot> ACTION-835 Contact Stéphane to see if he is interested in presenting MW4D to BPWG at TPAC closed
<dom> [we need to give an answer on the polycom before Sep 21]
bryan: suggests to add a discussion on the DDWG, UWA, DCO, DCCI, etc state of the overall delivery context work as an important issue for the MWI
<dom> [ok]
dka: suggest to have a conf phone so that Bryan can join the meeting; or try it over skype