Re: WebPlatform 2nd Open Telcon

Hi folks,

Thanks for a productive meeting!

ACTION: Janet to propose a page where people keep track of what they're
currently working on
ACTION: jkomoros to explain use of merge candidate flag on the page.
ACTION: Garbee to write up proposal for tracking of TODOs on site and send
for comment.
ACTION: jkomoros to implement the above stuff about attributes
ACTION: Janet to propose a page where people keep track of what they're
currently working on
ACTION: jkomoros to explain use of merge candidate flag on the page.
ACTION: Garbee to write up proposal for tracking of TODOs on site and send
for comment.
ACTION: jkomoros to implement the above stuff about attributes
ACTION: Paul to talk to Alexis about CanIUse data license and use on WPD.
ACTION: Paul to re-open markdown syntax ticket and restart discussion

And here are the raw notes (does anyone know if there's a better way of
doing this than just copy pasting from my IRC log?):

jkomoros: scribe: komoroske
[09:08am] jkomoros: julee: Don't forget about the Adobe WPD doc sprint this
Saturday in San Francisco
[09:08am] jkomoros:  92 people are already registered.
[09:09am] jkomoros:  Actually, it's all filled up!
[09:09am] qdotu joined the chat room.
[09:09am] jkomoros: topic: Reviewing last week's action items
[09:10am] jkomoros: komoroske: jswisher to create a page to track who's
working on what
[09:10am] jkomoros: jswisher: Not yet done. I was going to send an e-mail
to the list about this topic to get feedback from others. The reasoning
behind it was that it's not alway easy to tell what's going on. People
bring up issues on the mailing list, but often it's hard to tell who's
working on what.
[09:11am] jkomoros:  the idea was to have a page where people can just
take note of the big projects they're working on.
[09:11am] jkomoros:  there's risk that will get out of date, but people
could put the date next to their updates.
[09:11am] jkomoros: ACTION: Janet to propose a page where people keep track
of what they're currently working on
[09:11am] julee:
[09:12am] jkomoros: Open question: Who decides when to merge?
[09:12am] jkomoros: jkomoros: I've run into cases where deletion is a
[09:12am] jkomoros:  I'm going to create a page about gotchas for deletion
[09:13am] mike5w3c joined the chat room.
[09:13am] jkomoros: jswisher: Debenoits brought it up last week, but it was
unclear what the next steps were.
[09:13am] Garbee: I'm good with that.
[09:14am] jkomoros: jkomoros: My thinking was that in that case anyone can
do the work to do the merge. It's more of a "work in progress" indicator to
reduce redudancy.
[09:14am] jkomoros: ACTION: jkomoros to explain use of merge candidate flag
on the page.
[09:14am] jkomoros:
[09:15am] Garbee:
[09:15am] jkomoros:
[09:15am] jkomoros:
[09:16am] paul_irish: ^ ^
[09:17am] jkomoros: jkomoros: Want to make sure this doesn't become a place
for bugs to go to die
[09:17am] jkomoros:  we could scrub that list at the Adobe doc sprint.
[09:17am] jkomoros: peterlubbers: I'll add this to the doc sprint list of
work items
[09:18am] jkomoros: jkomoros: Going forward, we can review the top/new bugs
each week and periodically review all of them
[09:18am] jkomoros: Topic: Translations
[09:19am] jkomoros: jkomoros: Chris and Doug know most about this, maybe we
should defer?
[09:19am] jkomoros: jswisher: I remember that we decided on a URL strategy
where for any given page the translations would be sub-pages of it.
[09:19am] jkomoros:  but we needed additional tooling.
[09:20am] jkomoros: jkomoros: We'll talk about it again next week and make
sure we'll tracking progress.
[09:20am] jkomoros: Topic: Handling TODOs
[09:20am] jkomoros: jkomoros: We have 6 ways to handle TODOs today (!!)
[09:21am] jkomoros:  and different types of TODOs are mixed in different
[09:21am] jkomoros: Garbee: I think most of the stuff we should be able to
handle with our own bug tracker on the site, hopefully with SSO.
[09:21am] jkomoros:  That would replace comments/discussion pages.
[09:21am] jkomoros:  Ideally flags on the site could automatically create
bugs as well
[09:22am] jkomoros: paul_irish: And then there could be a nice UI for when
there are tickets on a given page.
[09:22am] jkomoros:  I think that they're all serving different purposes,
but volume is low.
[09:22am] jkomoros:  on MDN I've never seen much use of discussion pages
(although I have seen use of user pages).
[09:22am] jkomoros:  I'd be comfortable with not having discussion pages
or inline comment system.
[09:22am] jkomoros:  and restricting comms to other channels
[09:23am] paul_irish: jkomoros: i agree. we have tons of ways of handling
this right now.. e.g. during last weeks' mini doc sprint.. the more places
there were to put work items, the greater the chance to see them get ignored
[09:23am] paul_irish: ... the less places for this to exist, the better
[09:24am] paul_irish: ... Garbee, do you want to write up a small proposal
on how this works?
[09:24am] paul_irish: Garbee: yeah i'll tackle this week
[09:24am] jkomoros: ACTION: Garbee to write up proposal for tracking of
TODOs on site and send for comment.
[09:24am] paul_irish: topic: How best to represent attributes/properties of
DOM objects?
[09:25am] paul_irish: jkomoros: last week phistuck wrote some epic emails
on the topic. (he's an enormous contributor to the chromium projects). he
had a lot of good points... one was how to structure attrs/props of DOM
[09:25am] David_Bradbury joined the chat room.
[09:26am] paul_irish: ... this is a little low level.. but the way I set up
the IA.. attributes are almost always properties. but not vice versa. we
don't want to duplicate content but we do want to make this clear
[09:26am] paul_irish: ... and we want to identify what attributes belong to
what elements
[09:27am] paul_irish: ... we also ahve html markup elements and their DOM
[09:27am] paul_irish: ... so the way you specify attributes is to point to
the DOM interface. And we should be able to ..
[09:28am] jkomoros: paul_irish: My thought is that the distinction between
properties and attributes is so esoteric and only bites you in like five
[09:28am] jkomoros:  query, as an example tried to split the use of both
of them a year ago and it didn't really work out. For 99% of cases,
distinction isn't important. I'd love to see them share a documentation
page, with any differences highlighted on that page.
[09:28am] jkomoros:  similarly I feel the same way about the markup
element and DOM interface.
[09:29am] jkomoros:  a Video element in HTML can have a src tag nested
inside, and in DOM it has play and stop methods.
[09:29am] jkomoros:  All of this information belongs together. I'd like to
see this content merge together so I'm not chasing between four different
[09:30am] paul_irish: jkomoros: i think that's right .. and i think we
could pull in information from the DOM interface to the markup element.
[09:30am] jkomoros: paul_irish: I don't think the video element page should
even talk about access key
[09:31am] paul_irish: jkomoros: another thing we've done in the DOM
interfaces... it only pulls in the most specific interfaces methods/props
that belong to that element.. we could actually specify the interfaces up
the chain that should be documented there.
[09:31am] paul_irish: paul_irish: that's cool
[09:32am] jkomoros: julee: I think it's a good idea to have them on the
same page. What I was going to suggest is maybe there could be, someone
could explain the way things are organized in the page.
[09:32am] jkomoros:  I mean explaining within the article about how the
interfaces and elements relate
[09:33am] jkomoros: ACTION: jkomoros to implement the above stuff about
[09:33am] jkomoros: Topic: Source of compatibility information
[09:33am] paul_irish: jkomoros: to recap, we have structured forms to allow
compat info for various pages
[09:34am] paul_irish: ... some people have asked, why not pull in
information automatically from caniuse?
[09:34am] paul_irish: ... i think garbee has been involved in this on IRC
[09:34am] paul_irish: Garbee: yeah
[09:34am] paul_irish: jkomoros: so right now we dont have great coverage on
compat table info.. caniuse has solid curated info
[09:34am] paul_irish: so by pulling in that, we could have better info
[09:34am] paul_irish: ... in the future we all want to get to a point where
there is canonical browser compat info
[09:35am] paul_irish: ... so caniuse is already well tracked and the data
is well structured.
[09:35am] paul_irish: ... for the record: i LOVE caniuse. <3 <3
[09:35am] paul_irish: ... I'm putting on my longterm view. caniuse has good
summary information. It's worthwhile to look at more low level structure
[09:36am] paul_irish: ... in my perfect world, if we had infinite
resources.. WPD (or something like it) assembles all low level compat info.
provides and API. and you'd use that to create these summary rollups. like
CSS tranform report.
[09:36am] paul_irish: ... hopefully caniuse data could use that. i'm not
sure if caniuse's owner would be into that.
[09:37am] Garbee:  --A
example of what we need some more of.
[09:37am] paul_irish: ... if we continue to accumulate information, it's in
a structured format now.
[09:37am] Garbee: An*
[09:37am] David_Bradbury: Not sure if it is relevant, but caniuse is CC
BY-NC 3.0 instead of CC BY - Will that be an issue?
[09:37am] paul_irish: ... and we could use this and port it to something in
the future;.
[09:37am] paul_irish: David_Bradbury++
[09:38am] David_Bradbury:
[09:38am] jkomoros: paul_irish: I agree that the long term goal is that WPD
is the canonical source. But there is an ambiguous road to that goal.
[09:38am] jkomoros:  we want to be able to put trust and authority into
the browser compat story.
[09:38am] jkomoros:  CanIUse has fairly comprehensive high level
summaries, but its low level detail is not as strong
[09:39am] jkomoros:  the best low level detail comes from QuirksMode and
[09:39am] jkomoros:  the ideal picture for me right now is that WPD's
compat information is a combo of the data from caniuse, quirks mode, and
[09:39am] You left the chat by being disconnected from the server.
[09:40am] You reconnected to the server.
[09:40am] You rejoined the room.
[09:40am] jkomoros:  and I'd be very happy if that was done today. The
conversation we had in Tokyo is, is there a risk of pulling in a snapshot
of that information? And we don't want to pull in info that's stale.
[09:40am] jkomoros: *that is, pull in data and have it BECOME stale.
[09:40am] David_Bradbury: caniuse raw information can be found here: | He says you can contact him here: - We might be able to ask him about changing
the license for Web Platform
[09:41am] paul_irish: jkomoros: there is a critical mass point where people
rely on the browser compat facts
[09:41am] paul_irish: paul_irish: should we set a goalpoint that is that
critical mass point? it happens before the canonical source goal
[09:42am] jkomoros: jkomoros: One thing is that browser compat is very easy
for new editors to get started with
[09:42am] jkomoros: paul_irish: We can pull in this information in a
non-automatic fashion, in a manual fashion and get an edit-conflict diff
report so we can resolve things manually if we need to.
[09:43am] jkomoros:  that way people can update WPD as the source of
truth, but we can still see where it's getting stale.
[09:43am] jkomoros:  complicated from an implementation standpoint. But
from a truth standpoint it seems best.
[09:43am] jkomoros: Garbee: My main thing with compat is that on a few
pages, like <li>, there are a few different compat tables just on there.
[09:44am] jkomoros:  So should we be maintaing all of them.
[09:44am] David_Bradbury: Can we split the compatibility tables into
[09:44am] paul_irish: jkomoros: the solution to this is having one
canonical source.. live on the most specific leaf node article. guides and
concepts and tutorials should be able to transclude them
[09:44am] Garbee: i.e. would hold the P
compat table and then HTML Text guide would pull that
table in.
[09:45am] jswisher: that's also good for translation
[09:45am] jkomoros: julee: The CanIUse guy works at Adobe so I can talk to
him about licensing
[09:45am] jkomoros:  (Alexis)
[09:45am] Garbee: I'm good with your solution on Compatability tables.
 Using external resources as a supplement of sorts but keep the main tables
manually compiled for now.
[09:46am] jkomoros: ACTION: Paul to talk to Alexis about CanIUse data
license and use on WPD.
[09:46am] jkomoros: Topic: Markdown
[09:47am] jkomoros: paul_irish: It came up yesterday on the list. I care
about it because it came up in the mini doc sprint in Tokyo last week.
[09:47am] jkomoros:  when Chrome dev rel guys saw syntax for wiki, they
got upset.
[09:47am] jkomoros:  for most web developers, markdown is a second
language due to its heavy use on GitHub and other sites.
[09:47am] jkomoros:  so there are a lot of usability benefits.
[09:48am] Garbee:
[09:48am] jkomoros:  There's a way to support markdown as an authoring
language that still gives first class support for wiki syntax.
[09:48am] jkomoros:  I'd like to re-open that ticket and provide a
proposal for how we can support that.
[09:48am] jkomoros:  it will unlock more contributions
[09:48am] jkomoros: ACTION: Paul to re-open markdown syntax ticket and
restart discussion
[09:48am] Garbee: I reponed the ticket just now.
[09:49am] jkomoros: paul_irish: I think we don't need to use that
extension; we could a lot of the work client side so the real syntax is
always true wiki syntax in the site.
[09:49am] jkomoros: paul_irish: Garbee, you rock
[09:49am] paul_irish: ++
[09:49am] jkomoros: jkomoros: ++

On Tue, Oct 30, 2012 at 6:48 AM, Alex Komoroske <>wrote:

> Hi folks,
> Quick reminder that this is happening tomorrow (10/30) at 16:00 UTC /
> 12:00 ET / 9:00 PT.
> I'm looking forward to it!
> --Alex
> On Fri, Oct 26, 2012 at 6:51 PM, Alex Komoroske <>wrote:
>> Hi all,
>> I wanted to give everyone a heads up that we'll be holding an additional
>> telcon this coming Tuesday (10/30) at 16:00 UTC / 12:00 ET / 9:00 PT. In
>> the long run we'll likely be having these every two weeks, but at this
>> early stage we may have them more often. You can find tactical details
>> about the meeting at**wiki/WPD:Meetings<>
>> This coming week Doug (and many others) will be at TPAC [1], and so I
>> will be filling in as chair.
>> Agenda:
>> * Welcome
>> * Review of last week's action items
>> * Triage of new bugs
>> * Discussion topics (we'll see how many we have time for):
>>     * Handling translations
>>     * How to track TODOs (bugzilla/flags/editorial
>> notes/comments/mailing list)
>>     * How best to represent Attributes and Properties of DOM objects
>>     * Compatibility table information
>> Please feel free to suggest more agenda topics that you'd like to discuss.
>> As a reminder, these meetings are open to anyone, although we especially
>> value the participation of active community members.
>> --Alex
>> [1]

Received on Tuesday, 30 October 2012 16:57:29 UTC