Minutes IndieUI 29 May 2013

Minutes of the 29 May 2013 IndieUI teleconference are posted to
http://www.w3.org/2013/05/29-indie-ui-minutes.html and copied below.


  Independent User Interface Task Force Teleconference


    29 May 2013

Agenda
<http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0026.html>

See also: IRC log <http://www.w3.org/2013/05/29-indie-ui-irc>


    Attendees

Present
    Cooper, jasonjgw, Janina_Sajka, Rich_Simpson, Andy_Heath, jcraig,
    [Apple], hober
Regrets
Chair
    Janina_Sajka
Scribe
    jcraig


    Contents

    * Topics <http://www.w3.org/2013/05/29-indie-ui-minutes.html#agenda>
         1. Editor's Update
            <http://www.w3.org/2013/05/29-indie-ui-minutes.html#item01>
         2. User Module FPWD Strategy Discussion
            http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0025.html
            <http://www.w3.org/2013/05/29-indie-ui-minutes.html#item02>
    * Summary of Action Items
      <http://www.w3.org/2013/05/29-indie-ui-minutes.html#ActionSummary>

------------------------------------------------------------------------

<trackbot> Date: 29 May 2013

<janina> Meeting: IndieUI Task Force Teleconference

<scribe> scribe: jcraig

take up item 11

<MichaelC> drop item 5

<MichaelC> drop item 6

<MichaelC> drop item 7

<MichaelC> drop item 8

<MichaelC> drop item 9

<MichaelC> drop item 10

JS: TPAC, who's going? TPAC webpage needs updating still (no hotel, etc).
... TPAC is November 11-15 in Shenzhen China


      Editor's Update

JC: Updates from last call directional events and linear events should
use same names as CSS and SVG

they do now

UIRequestEventUI

<jasonjgw> Comments from Rich that directional and linear events should
use the same syntax as CSS and SVG were incorporated into revisions.

UIRequestEventInit

<jasonjgw> Questions have been raised about UI request event
initializers and the need for an initialization dictionary.

https://dvcs.w3.org/hg/IndieUI/raw-file/default/src/indie-ui-events.html#UIRequestEvent

<jasonjgw> See section 3.1.2 of the Events draft.

<jasonjgw> James proposes to contact potential implementors about this
issue.


      User Module FPWD Strategy Discussion
      http://lists.w3.org/Archives/Public/public-indie-ui/2013May/0025.html

<jasonjgw> James clarifies in response to a suggestion from Michael that
it isn't clear that WebIDL has been limiting so far, but Respec has been
(issues raised on specprod list).

JW: been thinking about this for a while now
... questions regarding User Context draft, privacy implications
... Trying to get to the bottom of what issues/actions need to be
addressed prior to FPWD of User Context spec
... May need to publish with notes as to which issues are controversial
or incomplete; also which are prereqs to publishing

MC: Don't believe we have all the requirements yet
... I'm attempting to eliminate the dupe reqs
... Would we want to sort reqs prior to publishing FPWD or not?
... Could do either; pros/cons to each. Sorting first would delay draft,
but also enlighten the first draft.
... No FPWD is complete, but would be good to publish as a complete
outline of planned final document.

<Zakim> MichaelC, you wanted to say we still haven´t sorted
requirements; do we want to before FPWD (ok either way but let´s examine
question) and to talk about general outline

JW: could simultaneously publish requirements and FPWD. Would have the
benefit of drawing attention to incompleteness of requirements.

<Zakim> MichaelC, you wanted to talk about where requirements live

JW: other option would be to write full reqs document prior to FPWD

MC: reqs are currently are in a wiki. There was no plan to publish reqs
to the TR status pages.
... our charter allows us to co-publish additional "supporting" documents.

JW: Some other WGs publish reqs docs
... just pointing out options we have.
... Want to use requirements to inform the spec, and vice versa.

MC: I do believe documenting requirements will help us proceed towards
spec publishing; some delay due to differing views of what those
requirements are.

JS: WAI coord group expressed surprise that we have not solicited
requirements from outside the WG.

MC: Could appeal to public to look at the wiki; other option to publish
FPWD and wait for feedback.

JW: I'd like to see requirements settled before FPWD
... Or at least defined enough to have the spec refer back to the wiki.
... I don't think all controversies have to be worked out prior to
publishing

<MichaelC> action-42?

<trackbot> ACTION-42 -- Michael Cooper to consolidate use cases -- due
2013-03-13 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/42

<MichaelC> action-41?

<trackbot> ACTION-41 -- Michael Cooper to create IndieUI Roadmap for
both spec: which feature sets should go into 1.0 versions. -- due
2013-03-02 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/41

JW: group action to solidify use cases?

MC: may need to prompt individuals instead of by group

<Zakim> MichaelC, you wanted to say requirements haven´t been difficult
to define, as much as scope for which requirements make v.1 and to say
incomplete doesn´t have to block FPWD; an

MC: one of the hard issues is to decide not just what should go into
each version of the draft; some features won't make it into version 1.0
... legitimate to publish FPWD with privacy section listed as TBD

AH: agree with Michael that we need to solidify and agree on requirements

JS: Wondering recently what the core requirements should be; but with
extensibility
... GPII has a very specific need that most clients would not need

AH: working on a crosswalk? of multiple groups needs and requirements:
GPII, Schema.org

JW: existing precedent for core reqs and modules as a structure
... also mechanism is not defining the vocabulary
... in order to resolve the scope, it may be to be speced as 1.0, 2.0,
or to sub-modularize the spec
... Step 1: collect all requirements in one place, and Step 2: separate
the scope after we document the entire list

<jasonjgw> James notes that there is already some provision for
extensibility but there are disagreements about what should be included
in core. The general core/extension approach seems non-controversial as
is the technical mechanism (key/value pairs discussion).

<jasonjgw> He suggests gathering all requirements HHHHe suggests HHHHe
concurs with the idea of gathering all potential requirements first and
then dividing them into levels of importance or otherwise classifying in
order to resolve the scope question.

<Zakim> MichaelC, you wanted to say the question of core / modules or
syntax / vocabularies could be something we ask for input on in the FPWD

MC: we could ask the public some questions about core needs versus
extensible taxonomies; whether they think these will delay implementations

AH: agree with prior comments; controversial bits are just about what
makes it into the core vocabulary

MC: action items? email to list? volunteers?

JW: solicit requirements, consolidate complete list, delete duplicates
and overlap, and verify cleanliness of data

JC: I nominate Jason

<MichaelC> JW: willing to send email to list and help with regularizing
the requirements that are submitted

<MichaelC> after a reasonable time frame

<MichaelC> and can help back-track to use cases

<MichaelC> JC: some stuff already represented in spec

<MichaelC> and the existing proposals for requirements

<MichaelC> though some refactoring may be needed

<scribe> *ACTION:* Jason to email group to resoliciting uses cases for
User Context requirements; [recorded in
http://www.w3.org/2013/05/29-indie-ui-minutes.html#action01]

<trackbot> Created ACTION-54 - Email group to resoliciting uses cases
for User Context requirements; [on Jason White - due 2013-06-05].

<MichaelC> e.g., ¨simplified¨ needs more precise definition

AH: why ask the community about requirements yet
... be sure not to disregard proposals in this initial gathering phase;
we can determine order later

JC: re: external comments, need to approach this carefully; could result
in FUD from non-technical members of the community that could
misunderstand some of the reasons for the need for User Context

<Zakim> MichaelC, you wanted to say we can ask for requirements of
anybody whom we like, or not do so; but in a FPWD anybody who wants to
comment may, and calling out requirements as a

JW: would be fine with having the FPWD point to list of requirements.
That should be enough; don't need to make specific requests outside the
technical spec reviewers.

MC: can triage the feedback and those comments as we see fit.
... Need to behave in a manner befitting that, but don't need to let the
world's comments drag us down and prevent progress.

AH: I can help with the reqs gathering and email that is Jason's initial
action item

MC: additional action items will be needed after Jason's is complete

ACTION-54?

<trackbot> ACTION-54 -- Jason White to email group to resoliciting uses
cases for User Context requirements; -- due 2013-06-05 -- OPEN

<trackbot> http://www.w3.org/WAI/IndieUI/track/actions/54


    Summary of Action Items

*[NEW]* *ACTION:* Jason to email group to resoliciting uses cases for
User Context requirements; [recorded in
http://www.w3.org/2013/05/29-indie-ui-minutes.html#action01]
 
[End of minutes]
------------------------------------------------------------------------
Minutes formatted by David Booth's scribe.perl
<http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm>
version 1.138 (CVS log <http://dev.w3.org/cvsweb/2002/scribe/>)
$Date: 2013-05-29 22:09:20 $


-- 

Michael Cooper
Web Accessibility Specialist
World Wide Web Consortium, Web Accessibility Initiative
E-mail cooper@w3.org <mailto:cooper@w3.org>
Information Page <http://www.w3.org/People/cooper/>