IndieUI Task Force telecon -- 13 Jun 2012

<ArtB> Scribe: Art

<ArtB> ScribeNick: ArtB

Source code repository

Date: 13 June 2012

<scribe> Chair: Janina

Janina: source code repository

… what are the issues?

… that we need to discuss

MC: I want guidance on structure of the repo

… I asked James a question

… could have a folder per deliverable

… and other that could have other subfolders and files

… James indicated version-specific dirs may not be needed because Hg can handle branches

JS: is the proposed structure documented?

MC: I can mail a proposal to the list

<MichaelC> events

<MichaelC> + 1.0

<MichaelC> + spec

<MichaelC> + indie-ui-events.html

<MichaelC> + {supporting files if any}

<MichaelC> + tests

<MichaelC> context

<MichaelC> + 1.0

<MichaelC> + spec

<MichaelC> + indie-ui-context.html

JS: can also use tags

<MichaelC> + {supporting files if any}

<MichaelC> + tests

AB: my recommendation is that we move this discussion to list after we see Michael's proposal

DS: agree, let's take this to the list

Task Force Work Statement http://www.w3.org/WAI/IndieUI/IUITF

Janina: we discussed this a bit last time

MC: I have some outstanding input from Art

… #9 he had a comment

… he was wondering if need subteams

Janina: we may need them

… they have been useful in A11Y TF (HTML WG)

AB: I am OK with the wording on point #9; agree subteams may be useful

MC: main part is Participation section

[ Michael reads the data … ]

… Art thought Regrets was overkill

Janina: regrets set expectation that there are participation requirements

DS: that is a different pattern than the one Art and I use in other groups

… we talked about this in yesterday's WebEvents call

… some people didn't want to join the TF it it meant they *must* attend every call

Janina: we can have "standing regrets"

DS: think we will get more browser vendor participation if we don't have firm standing requirements

JS: how about recommending but not requiring

DS: that would be fine

Janina: that would be OK

MC: if attendance isn't required, it can complicate decision making

DS: using email can help bring clarity because people can be more careful on their comments

… want to make participation as inviting as possible

… I would drop that section

Janina: I want to at least recommend participation
... there can also be misunderstanding with email

… and voice confs can help bring clarity

… I realize we can never pick a time that will work well for everyone

… Both channels are valuable

AB: I would prefer "highly encourage" in terms of telcon meetings

… and I am OK with asking all Editors to send Regrets

Janina: think we should take this offline

DS: if there is a problem on the list, it may be a misunderstanding by someone that is not in the TF

… but if the misunderstanding is among TF members, it makes sense to use telecon time to help clarify the misunderstanding

Janina: I agree Doug

MC: I'll take this offline

… any other issues about the Work Statement?

[ None ]

Janina: ok, hearing no objections we will move on

Recruiting

Janina: would like to get browser vendors

… we of course want broad implementation

… need someone from Mozilla

… would be good to get IE people

… we have at least one Webkit (Apple)

Janina: what about Web Events

<MichaelC> scribeNick: McihaelC

<MichaelC> scribeNick: MichaelC

ArtB: Rick Byers working on Chrome tablet, needs to learn first Touch events

Opera wants to follow, but Web Events candidate based in Tokyo, difficult for telecon

Mozilla interested, probably will have someone but not identified who yet

would help to have concrete specs for recruiting process

Janina: we have starter draft from Apple that has gone through a couple revisions

mc: have a version ready to post, pending resolution on repository structure

there are old versions around, but they don't have standing and reluctant to reference

Janina: think we're about a week away from having sharable stuff

<ArtB> ScribeNick: ArtB

<MichaelC> and next week's call is a good time to invite people to look in

Janina: what do we do before we have a doc in Hg?

DS: I think Art was also asking when is there going to be a Call for Proposals?

… I think we should put out a CfPs

MC: Apple's proposal is all we have now

… my inclination is that we put out a first doc and then put out a CfP

Janina: we could put out Apple's spec and then make a Call for Counter Proposals

AH: that could be a conflict

DS: Art and I were asking for a CfP and Apple's could be one such proposal

MC: I think Apple's proposal can be used to help recruiting

… if we don't have something concrete, the CfP may not be that useful

DS: since we are just starting, perhaps not having something too specific would be good

… if we have Apple's proposal on the table, it could limit inputs

Janina: so the priority is to start the CfP?

DS: yes

Janina: any objections to doing that now?

DS: no

Rich: what about UCs?

DS: we could collect them at the same time

Janina: what about a deadline?

DS: perhaps two weeks

Rich: I think we can expect inputs from IBM

Janina: I will work with Michael, Doug and Art on the CfP

… and do so by next week

… How does that sound?

Rich: sounds OK

… as long as names aren't fixed yet

… we need other inputs

Janina: I would be thrilled to have multiple proposals

AB: I think your plan is a good one Janina

Rich: do we have a wiki for UCs?

Janina: we can talk about UCs today

… agree we start talking about them

JS: there was a Gnome a11y meeting last week

… I mentioned this WG

… there was some interest

… and someone may apply as an Invited Expert

<janina> Joanmarie

JS: Joanmarie works on Orca screen reader

… there will be another meeting tomorrow

… and I'll mention our status

use cases

<shepazu> http://www.w3.org/2011/audio/wiki/Use_Cases_and_Requirements

DS: I am working on the UCs wiki

… based on the Audio WG's UCs work

Rich: I like the priorities

… who sets them?

DS: the Audio WG decides, on calls

… about the priorities over discussion related to versions

… and this helps us identify the highest priority for v1

… v1 is aimed at something that can be broadly implemented ASAP

… This WG may choose to do something else

<shepazu> http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

AB: UCs work with Touch Events spec was very useful

… for capturing priorities

… and to have a place to log UC and Reqs for v.next

DS: http://www.w3.org/WAI/IndieUI/wiki/Use_Cases_and_Requirements

… Let me talk about Audio WG's UC work

… We give each UC an ID

… and then describe a story

… For each UC we include some Notes as well as a Priority

… For each UC we also document the related Requirements

<andy> can't get back in

<andy> The conference is restricted at this time

… A UC's Notes can include some points of the group's consensus on the UC

<andy> ok - I'll watch IRC then

DS: we have noticed that some requirements can span more than one UC

Rich: I like this

Janina: I agree; this is awesome

DS: Rich, can your UCs map to this structure?

Rich: yes; thanks very much

DS: well, it's the Audio WG that we need to thank ;-)

Janina: yes, I like this a lot

DS: I will try to fill out at least one UC and some Reqs before the next call

… and include "real" data

Janina: ok; great please do that

… and Michael will continue to do the Hg work

… I will try to get a draft CfP to Doug, Mike and Art by end of this week

… Thanks all for a productive meeting!

- DRAFT -

IndieUI Task Force telecon

13 Jun 2012

Attendees

Contents

Source code repository

Task Force Work Statement http://www.w3.org/WAI/IndieUI/IUITF

Recruiting

use cases

Summary of Action Items

Scribe.perl diagnostic output