- From: Alex Komoroske <komoroske@google.com>
- Date: Wed, 31 Oct 2012 01:56:35 +0900
- To: public-webplatform@w3.org
- Message-ID: <CAPwaZpU2aRFhMrjGA=RxPCbxH8E33_+VDpBE3fBMf_dgYNq6oA@mail.gmail.com>
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: https://webplatformdocsprint.eventbrite.com [09:12am] jkomoros: Open question: Who decides when to merge? [09:12am] jkomoros: jkomoros: I've run into cases where deletion is a problem [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: https://www.w3.org/Bugs/Public/buglist.cgi?cmdtype=runnamed&namedcmd=wpd-bugs&list_id=1364 [09:15am] Garbee: https://www.w3.org/Bugs/Public/describecomponents.cgi?product=webplatform.org [09:15am] jkomoros: https://www.w3.org/Bugs/Public/buglist.cgi?cmdtype=runnamed&namedcmd=wpd-bugs&list_id=1364 [09:15am] jkomoros: https://www.w3.org/Bugs/Public/buglist.cgi?bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&columnlist=bug_severity%2Cpriority%2Cop_sys%2Cassigned_to%2Cbug_status%2Cresolution%2Cshort_desc%2Copendate%2Cchangeddate&component=Comments%20Extension&component=content&component=default&component=info%20architecture&component=infrastructure&component=skin&list_id=1362&product=webplatform.org&query_format=advanced&order=priority%2Copendate%2Cbug_status%2Cassigned_to%2Cbug_id&query_based_on= [09:16am] paul_irish: http://goo.gl/GJ4a3 ^ ^ [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 places [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 objects.. [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 objects [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 cases [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 pages. [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 attributes [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 notes [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: http://docs.webplatform.org/wiki/html/elements/p#Compatibility_Notes --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 MDN. [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 MDN. [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: https://github.com/fyrd/caniuse | He says you can contact him here: http://a.deveria.com/contact - 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 templates? [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. http://docs.webplatform.org/wiki/html/elements/p 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: http://www.mediawiki.org/wiki/Extension:MarkdownSyntax [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. https://www.w3.org/Bugs/Public/show_bug.cgi?id=19692 [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 <komoroske@google.com>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 <komoroske@google.com>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 http://docs.webplatform.org/**wiki/WPD:Meetings<http://docs.webplatform.org/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] http://www.w3.org/2012/10/TPAC/ >> > >
Received on Tuesday, 30 October 2012 16:57:29 UTC