I've dropped TimBL's photo of my lunch discussion notes into the Web,
alongside a decryption of my handwriting and a few other things I
remembered but didn't write down.
It's on Flickr at http://www.flickr.com/photos/danbri/2968502369/
I also attach the photo here and append my notes below; copying the
public www-archive list.
Thanks to Murray for getting this started. I didn't have everyones
names/addresses handy, please pass it along to others. I've added a few
folk to the To: list where I've had recent related discussions.
cheers,
Dan
---------------
(Lunch discussions from W3C TPAC 2008, fri oct 24)
Murray Maloney hosted a lunch BOF around the theme of W3C's HTML5 work,
tooling and community. These are my notes from the discussion when I
asked Ian Hickson what would help make his HTML5-editing life easier;
photo by TimBL.
Corrections, clarifications from participants are welcomed via Flickr
comments or email to danbri@danbri.org (ideally cc:'ing the public
www-archive@w3.org archiving list).
Transcribing and slightly augmenting my notes from TimBL's photo of my
lunch scribbles:
[[
Editors, more of them.
(there is a list of desired talents somewhere, from Ian).
Testing, QA infrastructure
(discussion of when this becomes most useful/urgent)
Tooling:
track every email, figure out its category, section, related posts,
issues, links, ... feedback, ...
Volunteers to help at checkin point, ... documenting rational, links
to wiki and issue tracker(s), when the document goes in. Or even when a
change was
*not* made (and why).
(TimBL talked about issue/release tracking in Tabulator)
Mailing list discussion: Ian noted that things are split fairly evenly
between the W3C HTML list and the WHATWG list. Ian tracks both without
preference. There are slightly different cultures and expectations
across each. The core HTML5 people tend to now initiate things on the
W3C list.
'tool for +1-ing?' --dbaron
Ian: WHATWG has voting on whatwg / issues
Ian: also I'd like a more flexible license on the doc; people want (a) to be
able to copy from the spec into code (b) allow risk of a fork. The
possibility
of this happening keeps people focussed. Re license, DanC has action to
follow this up, and expressed some optimism.
]]
