The draft minutes from the February 15 voice conference are available at
the following and copied below:
http://www.w3.org/2011/02/15-webevents-minutes.html
WG Members - if you have any comments, corrections, etc., please send
them to the public-webevents mail list before February 22 (the next
voice conference); otherwise these minutes will be considered Approved
as is.
-Art Barstow
[1]W3C
[1] http://www.w3.org/
- DRAFT -
Web Events WG Voice Conference
15 Feb 2011
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0048.html
See also: [3]IRC log
[3] http://www.w3.org/2011/02/15-webevents-irc
Attendees
Present
Art_Barstow, Matt_Brubeck, Doug_Schepers, Olli_Pettay,
Josh_Soref, Dzung_Tran, Cathy_Chan
Regrets
Sangwhan_Moon
Chair
Art
Scribe
timeless, Art, Josh
Contents
* [4]Topics
1. [5]1. Brainstorm for agenda topics ...
2. [6]Mercurial workflow
3. [7]Tracker
4. [8]Technical Discussion
5. [9]AOB
* [10]Summary of Action Items
_________________________________________________________
<timeless> Scribe: timeless
<ArtB> ScribeNick: ArtB
<scribe> Scribe: Art
Date: 15 February 2011
<scribe> Scribe: Josh
<scribe> ScribeNick: timeless
1. Brainstorm for agenda topics ...
MB: We want to talk about Mercurial workflow
DS: yep
... We had talked about talking about Tracker
<mbrubeck> In the last telcon, we also talked about test suite code
hosting and public forking/contributions.
Mercurial workflow
MB: Quick summary ...
<Dzung_Tran> I have a conflict, so I was just going to follow on IRC
MB: for SW, DS, myself -- editors, we need to decide how we are
going to merge eachother's changes
... there are many things we could do
... two of the simple ones are ...
... using the CVS model where we each push/pull from a single
centralized repo
... or we could each have our own repos, push our changes to our
individual clones
... and once changes have been discussed, we could push to the
official repo
DS: What are the advantages of each approach?
MB: The centralized approach is easier for people to follow
... The advantage of people publishing changes before they're
integrated is that it provides a way for people to review proposals
before they're made
DS: So this touches on Review then Commit or Commit then Review
model
... traditionally @W3C we follow a Review then Commit
... At HTML/SVG
... WebApps, CSS(?), all use Commit then Review
... In the newer browser centric groups, we typically do Commit then
Review
... it tends to be faster and provides context for review
MB: In distributed you can do Commit, then Review, then Merge
(=Accept)
DS: I think that's OK
MB: We could do any of these
... If the editors want to use a central repo
... And other people especially people without write access could
use clones
DS: I tend to favor for non controversial changes, in order to make
it easy for people to understand what's going on with the group
... using the central repository for the three editors
... But if we have controversial things, we could do something else
MB: I think that's OK, since there aren't many editors
DS: I'm very intrigued by the prospect of having distributed
changeset.
... people sending in patches on a mailing list
... I like the idea of multiple editors getting their ideas out
there
... and letting people decide which works best
MB: And we'll probably see some of that
... we've already seen some of that w/ SW
DS: And i'll see some of that with Hg
MB: Using central you'll have simple pull merge cycle
... but it won't feel much different from CVS
JS: Another way to do things is to use Branches
... but I'm not at all in favor of it. Merely noting it's possible
AB: So it sounds like we're in favor of using a central repo
... does that seem like a fair characterization?
... Anyone else have feedback/input?
RESOLUTION: Stick with central repo
DS: So, we covered what + how
... but we haven't talked about The Who
... Do we want to have MB/SW make some changes?
MB: I think I can do some simple changes
DS: You can make some changes and cause me to need to do a merge.
... It will be good practice for you (editing) and for me (merging)
... MB: have you ever been an editor before?
MB: no
AB: So we also agreed to a Commit then Review model
RESOLUTION: We will follow the Commit then Review model
AB: ... this will align us with the other groups DS mentioned
DS: I'd also like to use this group to do some experimenting
... but for starters, I think this is fine
... so MB, for next week, you'll make some small changes?
MB: Yes, I'll look through the issues on the mailinglist and see
which ones I can address
DS: I think that leads us to our next topic
Tracker
DS: So, Tracker is our issue tracker
<ArtB> tracker: [11]http://www.w3.org/2010/webevents/track/
[11] http://www.w3.org/2010/webevents/track/
DS: Let's walk through creating an issue and creating an action
... MB: have you used Tracker before?
MB: No, I haven't
DS: It's rather simple
<shepazu> ACTION: matt to update touch events spec for next week
[recorded in
[12]http://www.w3.org/2011/02/15-webevents-minutes.html#action01]
<trackbot> Created ACTION-11 - Update touch events spec for next
week [on Matt Brubeck - due 2011-02-22].
<ArtB> Scribe+ Art
<ArtB> ScribeNick: ArtB
<mbrubeck> and then I can see
[13]http://www.w3.org/2010/webevents/track/actions/11
[13] http://www.w3.org/2010/webevents/track/actions/11
DS: can create Actions via IRC interface
... and can create Issues via IRC as well
<shepazu> issue: resolve touch area re. radius and angle
<trackbot> Created ISSUE-1 - Resolve touch area re. radius and angle
; please complete additional details at
[14]http://www.w3.org/2010/webevents/track/issues/1/edit .
[14] http://www.w3.org/2010/webevents/track/issues/1/edit
DS: (provided trackbot is running ...)
<shepazu> issue-1?
<trackbot> ISSUE-1 -- Resolve touch area re. radius and angle --
raised
<trackbot> [15]http://www.w3.org/2010/webevents/track/issues/1
[15] http://www.w3.org/2010/webevents/track/issues/1
DS: then in IRC, can say "ISSSUE-n?" where n is an issue number
... and trackbot will dump out the issue
... same thing works with "ACTION-n?"
... don't forget the "?" at the end
... Raised state means raised
... Open means WG agreees it is an issue
<scribe> ... Pending state means we are awaiting feedback
<scribe> ... Postponed state means the Issue will not be released in
the current spec (postponed to v2)
UNKNOWN_SPEAKER: Can also select the issue/action's "product"
... currently we just have the one Touch Event product
<shepazu> [16]http://www.w3.org/mid/4D470F74.9020208@canonical.com
[16] http://www.w3.org/mid/4D470F74.9020208@canonical.com
DS: after an Issue is created, an email will be sent to
public-webevents
... if an email includes a {ACTION,ISSUE}-n tag, that email's
archive link will be added to the issue or action
<shepazu> issue-1?
<trackbot> ISSUE-1 -- Resolve touch area re. radius and angle --
raised
<trackbot> [17]http://www.w3.org/2010/webevents/track/issues/1
[17] http://www.w3.org/2010/webevents/track/issues/1
DS: f.ex. if you look at the issue I just raised:
[18]http://www.w3.org/2010/webevents/track/issues/1
... you will see the email trail
... can also define a "short name" for Issues
... which can be convenient way to identify an Issue
[18] http://www.w3.org/2010/webevents/track/issues/1
<shepazu> action-1?
<trackbot> ACTION-1 -- Arthur Barstow to work with Doug on a voice
conference time of day that works for most people -- due 2010-12-15
-- CLOSED
<trackbot> [19]http://www.w3.org/2010/webevents/track/actions/1
[19] http://www.w3.org/2010/webevents/track/actions/1
<shepazu> action-11?
<trackbot> ACTION-11 -- Matt Brubeck to update touch events spec for
next week -- due 2011-02-22 -- OPEN
<trackbot> [20]http://www.w3.org/2010/webevents/track/actions/11
[20] http://www.w3.org/2010/webevents/track/actions/11
DS: Issues and Actions created in IRC are "bare bones"
... Need to use Tracker's Web interface for more advanced management
tasks
... f.ex. can change due date (which defaults to 7 days from
creation date)
... tracker scans all emails on public-webevents
... for {Action,Issue}-n tags
... and adds a link to the emails archive to the Action or Issue
MB: does Tracker track mercurial changes?
DS: no, I don't think so
... but we may be able to make something like that work
... there is an option to do that for CVS
... but sure about Mercurial
... I'll need to talk to sysadmin team at W3C
... we may also be able to connect commits to twitter
AB: I've been using Tracker for years
... it's easy to use and that's good
... may be missing some features Bugzilla has
... but overall, it's a good tool
DS: a disadvantage to Bugzilla is all of the comment treads are kept
in Bugzilla, whereas with Tracker, email is used for comment threads
AB: anything else on Tracker for today?
DS: I just logged one issue based on comments from two different
people
<mbrubeck> ACTION: Matt Brubeck to raise issues on Tracker for
previous mailing list discussions. [recorded in
[21]http://www.w3.org/2011/02/15-webevents-minutes.html#action02]
<trackbot> Created ACTION-12 - Brubeck to raise issues on Tracker
for previous mailing list discussions. [on Matt Brubeck - due
2011-02-22].
DS: it may be good for Matt (and others) to create Issues based on
comment from the list
JS: how does one get support for Tracker?
DS: everything is handled by W3C sysadmin team
... and I can be your conduit to that team
AB: yes, please notify Doug and I if you have any Tracker issues and
we will follow up
DS: I would like to walk thru a merge
MB: let's do that after the call
DS: OK
Technical Discussion
AB: I have some open action; I'll get to them RSN
DS: we didn't get much response about UCs and Reqs
... but could defer them until next week
... re Andrew Grieve's email ...
... we may want to create some issues
<shepazu>
[22]http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/
0043.html
[22] http://lists.w3.org/Archives/Public/public-webevents/2011JanMar/0043.html
DS: re what should happen if touch is dragged off the screen ....
... I think that is already addressed in the spec -> touch cancel
... I significantly changed touch cancel
... oh, Matt, we should talk about "ReSpec" which is used by the
Touch Events spec
<mbrubeck> issue-2?
<trackbot> ISSUE-2 -- What should happen when a touch is dragged off
the screen -- raised
<trackbot> [23]http://www.w3.org/2010/webevents/track/issues/2
[23] http://www.w3.org/2010/webevents/track/issues/2
AB: I don't think anyone has responded to the email
DS: I will respond to Andrew's email
... will need to tighten up the spec re what happens when touch is
moved offscreen
... Matt, can you look at that?
MB: yes
DS: re 2nd issue ...
OP: I think this is closer to a mouse use case
<mbrubeck> re issue-2, different hardware devices may or may not be
able to detect whether a touch was dragged off the screen or
released normally.
OP: need to check this on an Android or iPhone
DS: I could test this
<mbrubeck> issue-3?
<trackbot> ISSUE-3 -- Click event target after DOM mutation during
touchstart -- raised
<trackbot> [24]http://www.w3.org/2010/webevents/track/issues/3
[24] http://www.w3.org/2010/webevents/track/issues/3
DS: would be good if someone would write a test though
... any volunteers for that?
[Silence]
DS: ok, I'll write it
<mbrubeck> issue-4?
<trackbot> ISSUE-4 -- Does preventDefault on touchmove cause a
dragging motion to fire a click event? -- raised
<trackbot> [25]http://www.w3.org/2010/webevents/track/issues/4
[25] http://www.w3.org/2010/webevents/track/issues/4
<scribe> ACTION: doug create a test for ISSUE-4 [recorded in
[26]http://www.w3.org/2011/02/15-webevents-minutes.html#action03]
<trackbot> Created ACTION-13 - Create a test for ISSUE-4 [on Doug
Schepers - due 2011-02-22].
OP: remember to test mouse up and mouse down
MB: iPhone synthesize mouse up/down
... mouse up, mouse move, click
... needed for compatibility of apps that know about mouse events
but not touch
DS: what are we doing about preventDefualt in general?
MB: will be impl-specific
... e.g. safari pans with touch move
DS: we don't define all default actions the UA can take
... but we can define what preventDefault does
... There could be some issues around timing
... that we may need to define
<mbrubeck> MB: In mobile Firefox, for performance reasons, we also
might want preventDefault on touchstart to affect which other touch
events are fired. For example, if you don't preventDefault on
touchstart, then no touchmove/touchend events will be dispatched.
DS: other than "don't do that"
... that's good info
... perhaps you should put that in the spec
MB: let me bring it up on the list first
DS: sounds good
AOB
AB: let's continue discussion on the lsit
... and meet again next week
<mbrubeck> shepazu: Want to try a merge?
AB: Meeting adjourned
<mbrubeck> We can remove the "test" and "test2" files
<shepazu> mbrubeck: yes, give me 15 minutes
<mbrubeck> ok
Summary of Action Items
[NEW] ACTION: doug create a test for ISSUE-4 [recorded in
[27]http://www.w3.org/2011/02/15-webevents-minutes.html#action03]
[NEW] ACTION: Matt Brubeck to raise issues on Tracker for previous
mailing list discussions. [recorded in
[28]http://www.w3.org/2011/02/15-webevents-minutes.html#action02]
[NEW] ACTION: matt to update touch events spec for next week
[recorded in
[29]http://www.w3.org/2011/02/15-webevents-minutes.html#action01]
[End of minutes]