Advertisement
Guest User

Untitled

a guest
Sep 21st, 2016
1,150
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 19.22 KB | None | 0 0
  1.  
  2. yoav: So if anyone has questions about current process, or should I start by describing things?
  3.  
  4. rbyers: What are the goals?
  5.  
  6. yoav: Get better visibility and better feedback into early-stage spec proposals, so we get more participation from the larger webdev
  7. community, and more participation from browser vendors/etc.
  8.  
  9. cwilso: A few goals, got a litle confused at CSS yesterday.
  10.  
  11. cwilso: The goal for us Googlers, how we do incubation, is a little separate from the goasl o fthe WICG.
  12.  
  13. cwilso: WICG is an easy way to jump on ideas and get people to participate and discuss.
  14.  
  15. cwilso: All we do is watch repos and help people do the transition to a real WG when it's time for that.
  16.  
  17. cwilso: WICG isn't intended to be heavy process. We make sure people are respectful, that's abou tit.
  18. ChrisL has joined (clilley@public.cloak)
  19.  
  20. yoav: And resolving IPR commitments whent he bots get mad.
  21.  
  22. cwilso: Yeah. When you join, you sign some IP commitments, and that gets transitioned into a WG for a real spec.
  23.  
  24. mikeChampion: Whiat's the success criteria?
  25. jcraig has joined (~jcraig@public.cloak)
  26.  
  27. cwilso: For me the most important thing is the ability to fail gracefully.
  28.  
  29. cwilso: Incubations may not go anywhere. May not be interesting enough, or have neough momentum or people driving it forward, so they'll
  30. just sit there.
  31.  
  32. cwilso: Haven't gotten to the point of cleaning those out yet, but will need to.
  33.  
  34. cwilso: Real success is success on proposals, real engagement. Not just "where Google does work".
  35.  
  36. cwilso: And they transition to WGs to be real standards eventually.
  37.  
  38. cwilso: I'm okay with that taking time; want it to be stable.
  39.  
  40. astearns: Follow up.
  41.  
  42. astearns: You had a number of successes from the WICG, things tha tmoved to the Rec track.
  43.  
  44. astearns: I'ma ssuming we should be measuring whether those incubations got the participation you wer elooking for.
  45.  
  46. astearns: Both the amount we get on particular proposals, and the breadth of partic between companies and web develoepers, and track what
  47. we're doing.
  48.  
  49. astearns: And if we're not doing great, we should change how we run them.
  50.  
  51. yoav: Enough people as in external to th eprocess? If so, I agree, it shoudl be one of the goals.
  52.  
  53. yoav: Feedback from outside our echo chamber i sdefinitely one of my goals.
  54.  
  55. cwilso_: I'ts important to understand the WICG isn't a room of people standing around waiting for you to have an idea, so we can jump on
  56. it.
  57.  
  58. cwilso_: I tell Google engineers all the time, you're still responsible for drumming up interest, for getting participation.
  59.  
  60. cwilso_: There are some people who religiously watch the proposals, plenty that don't.
  61.  
  62. cwilso_: So if you want interest, you have to go ping those parties.
  63.  
  64. astearns: Have youd one any measurement of what has gone thru yet, to see how it's going?
  65.  
  66. cwilso_: Good point; I don't have non-anecdotal yet. We can get that, it's tracked in GitHub.
  67.  
  68. cwilso_: My data is just that I don't move a repo into WICG space unless there are multiple interested parties.
  69.  
  70. glazou: Yesterday at CSS one of the mentioned goals was to get the right size of contributors, the right people, right expertise, rather
  71. than the whole WG discussing everything.
  72. chongz has joined (~chongz@public.cloak)
  73.  
  74. glazou: It's already the way the CSSWG works; we host issues on GH, and only the people really contributing are there for each spec.
  75.  
  76. glazou: It's also about attracting webdev attention, but we have www-style, GH is open, etc.
  77.  
  78. glazou: Is the real difference only the fact that to add something new to the WG is a rechartering, and this bypasses that?
  79.  
  80. glazou: I'm not saying that's bad.
  81.  
  82. cwilso_: Second point first.
  83.  
  84. cwilso_: One challenge is that groups with a large scope can jump around based on what people are interested in.
  85.  
  86. cwilso_: ONe goal of incubation is to make sure we're rationalizing, for ourselves...
  87.  
  88. cwilso_: We want to make sure there's actual interest in a problem and it's scoped properly before we get a solution together.
  89.  
  90. cwilso_: Challeng with owning a large scope like CSSWG is you get a group of people that have a particular way fo looking at problems.
  91.  
  92. cwilso_: AT the time we didn't have designers and devs on the WG.
  93.  
  94. cwilso_: Opening up for other perspectives is good.
  95. cwilso_
  96. tabatkins: the point about large scope enabling jumping around - this is exactly the issue I run into as CSS WG rep
  97. tabatkins: it can be difficult socially to tell someone "that's not interesting" - running things through incubation instead, which requires
  98. positiive interest not lack of negative interest expressed, helps choose the right things
  99.  
  100. rbyers: ON the point that CSS is already working that way...
  101.  
  102. rbyers: When I hire new people, it's daunting to work in CSS. People are afriad to work on www-style.
  103.  
  104. rbyers: These are junior engineers, get to have lunch with people on the WG.
  105.  
  106. rbyers: But they only feel like they'll get interest with people flying and sitting in the room.
  107.  
  108. rbyers: Even I am active here, but I feel like I don't get progress without being here myself.
  109.  
  110. rbyers: And if that's how I feel, a Google engineer with experience, how does that feel to people from FAcebook, or another webdev?
  111.  
  112. rbyers: It's easy to get the feel that something is open from the inside.
  113.  
  114. rbyers: Like, how many actual proposals came from outside the group?
  115.  
  116. glazou: Quite a bit.
  117.  
  118. glazou: Championing by an editor, or sending ideas in, or...
  119.  
  120. cwilso_: Excelelnt to hear.
  121.  
  122. cwilso_: And something I mentioned before, this isn't an end-run around a WG. It has to go back to a group
  123.  
  124. cwilso_: You can't incubate a style feature for a while, and never have CSS look at it.
  125.  
  126. cwilso_: So that when it actually gets to the "real spec" transition, it woul be crazy.
  127. jcraig: q+ to talk about my discouraging experience proposing (:flow()) to CSS in 2003? and again in 2006? (more or less ::nth-fragment)...
  128. Incubation would path have been great
  129.  
  130. cwilso_: Part of the process is to include people relevant to the topic.
  131.  
  132. cwilso_: We do hear crazy ideas, of course. But those get filtered, in the incubation stage and the rec stage.
  133.  
  134. yoav: It's great CSSWG ahs moved to GH, makes things simpler. But if you want to keep track of waht's happening, it's a flood of emails that
  135. nobody should submit themselves to.
  136. jcraig q+ to also mention why 4 vendors were interesting in channeling AOM through WICG
  137.  
  138. yoav: For people external, it's a big barrier. Having a different group for a wider audience mamkes a difference.
  139.  
  140. astearns: I expect we'll want to move on, but...
  141. astearns: You mentioned incubation si the point, the goal.
  142. astearns: NOt necessarily having it happen in the WICG.
  143. astearns: People are happy with incubation happening in the meeting, for example.
  144. astearns: I'm not entirely clear on what that means, tho.
  145. astearns: How is the working mode of the WICG and Houdini sufficiently similar, such that the both fit the incubation model.
  146. astearns: How coudl other groups fit that model if they dont' want to move to the WICG?
  147.  
  148. cwilso_: I want to be clear tha tmoving to the WICG shouldn't be a big deal, no charter or anything.
  149. cwilso_: It's just a CG. You can do incubation in any CG.
  150.  
  151. astearns: What would you consider "incubation", specifically?
  152. astearns: No need for details here, just have them outlined somewhere. So we can measure against intent.
  153.  
  154. cwilso_: Goals are: things I think are importoant about incubation as a concept.
  155.  
  156. cwilso_: Two parts.
  157.  
  158. cwilso_: One is the ability to fail gracefully. To explore ideas and not get on a slippery slope to shipping just because you started.
  159.  
  160. cwilso_: Another is making sure it's an open process tha tcan include a lot of people.
  161.  
  162. cwilso_: Particularly with our supergroups, it's daunting to say "I want to join WebPlatform, and became an expert on everything, so it's
  163. not crazy to make a proposal there". Not many people can do that.
  164.  
  165. cwilso_: I think making this possible is important.
  166.  
  167. cwilso_: So graceful failure,a nd open outside the scope of a known charter.
  168.  
  169. yoav: One of the advantages of usign the discourse instance is you're getting interested people already subscribed to that, which help
  170. propagate that content.
  171.  
  172. yoav: They can help you get that message out there.
  173.  
  174. yoav: I'm not sure how that would look like if incubation were to happen elsewhere.
  175.  
  176. yoav: Or we could say it could happen elsewhere from an org perspective, but should be announced on some discourse instance or elsewhere.
  177.  
  178. astearns: I like that discourse, but it has problems. It's a firehose, too.
  179.  
  180. bkardell_: Can be, depending on how yous ign up for updates.
  181.  
  182. astearns: And there is a problem getting the experts in the topics that you need to participate.
  183.  
  184. astearns: I think you need more CSS people looking at things there. But also a11y, etc.
  185.  
  186. astearns: It's easy to say "when we need it, we can draw these in", but a lot of times people won't know they need this expertise.
  187.  
  188. cwilso_: Right. Discourse is the firehose of ideas, but not the discussion of those ideas.
  189.  
  190. cwilso_: Maybe the solution is tagging and filtering, and sending a regular report to the WGs to pull interest from those areas.
  191.  
  192. cwilso_: So if something might need CSS attention, send email to CSS about it.
  193.  
  194. astearns: Good idea.
  195.  
  196. gregwhitworth: I think what you just said is a graeat idea, we have that internally.
  197.  
  198. gregwhitworth: Often they're things that already exist and the proposer wasn't aware.
  199.  
  200. gregwhitworth: Second, I don't want us to discount the Brand© of what the WICG can become.
  201.  
  202. gregwhitworth: It's a low-barrier place.
  203.  
  204. gregwhitworth: If it's the one place to go to find information, our Google - they're popular because it's easy to start.
  205.  
  206. gregwhitworth: If people think "I want something in the standard, I should use WICG", that's powerful.
  207.  
  208. jcraig: Yesterday's brief discussion in the CSSWG was as heated as I'd ever seen it.
  209.  
  210. jcraig: I thought Alex's intro was speaking to me from 10 years ago.
  211.  
  212. jcraig: Even in the ocntext of CSS, I proposed :flow() in 2003, and later in 2006.
  213.  
  214. jcraig: 2006 was almost identical to what eventually became :nth-fragment().
  215.  
  216. jcraig: But it got almost no feedback, and that was discouraging.
  217.  
  218. jcraig: It may have been too early at that time, and that's fine.
  219.  
  220. jcraig: I encouraged at least th epotential of incubation for anyone.
  221.  
  222. jcraig: Other topic is we're working on an a11y OM, got people from Apple, Google, Moz...
  223.  
  224. jcraig: We're interested in bringing it - we sent it as a contribution to WICG yesterday, befor eour breakout this morning.
  225.  
  226. jcraig: Goal is that we'd all attempted to solve the same problem before, as separate work.
  227.  
  228. jcraig: Proposals from several, G has an extension for a11y.
  229.  
  230. jcraig: So we decided to work together, avoid the bureaucracy of a full WG, and do it fast an lightweight, because we dont' even know what
  231. we want to do yet.
  232.  
  233. jcraig: So my +1 to incubation.
  234.  
  235. mikeChampion: Boring process reason for working in WICG. If you make a contribution there, you're making a non-revocable patent commitment.
  236. In a WG it doesn't really trigger until it's a Rec.
  237.  
  238. mchampion: We're all friends, but the larger we get, th emore traditional companies get in, the more important this things is.
  239.  
  240. frremy: I want to comment onw hat Rick and James said.
  241.  
  242. frremy: It's definitely hard to propose and get forward in a group.
  243.  
  244. frremy: You don't know who to contact, or the group's priorities.
  245.  
  246. frremy: But an issue is, the people with expertise, it doesn't make diff which group we're in.
  247. astearns
  248. idly wondering whether we can harness the 'greater participation' of incubation to jump-start test suites for proposals before they move out
  249. of incubation
  250.  
  251. frremy: The chapmions already have a lot of things to do. So I"m not sure changing the venue will change much about this.
  252.  
  253. frremy: So if we change the community involvment, how do we make sure there's sufficient # of experts to keep it going.
  254.  
  255. yoav: You're right, it's in a way an unsolveable problem. But at the same time, people have to start somewhere.
  256.  
  257. yoav: You lower the barrier, they can go from proposal to being an expert on the subject a few years later.
  258.  
  259. rbyers: Having seperable convos - I can't subscribe to CSSWG repo, I can't keep up - but I can subscribe to a few WICG repos.
  260.  
  261. rbyers: It's silly, sure, but I think there are lots of experts that don't pay attention to the firehose.
  262.  
  263. rbyers: I'm an expert at some parts of CSS, but I don't pay attention. I assume people will point me to it.
  264.  
  265. rbyers: I'll say we learned this from WHATWG - it's easier to get random Moz engineers involved in one small issue or discussion, where you
  266. couldn't get them engaged in a larger W3C group.
  267.  
  268. leaverou: That sounds liek something to be solved by better tooling, not more WGs.
  269.  
  270. slightlyoff: My mental model is everyone is playiing a momentum game. Every new feature starts at 0, gains momentum.
  271.  
  272. slightlyoff: You can start in a big group with 0 momentum and try to push it thru, which is hard, or you can grow a community, bit by bit,
  273. and have it arrive with good momentum.
  274.  
  275. slightlyoff: You'll have to grow each feature as a separate effort.
  276.  
  277. slightlyoff: I haven't seen people take "small featues" to a big group and succeed; they get ripped apart.
  278.  
  279. slightlyoff: So having that momentum build is very valuable.
  280.  
  281. cwilso_: Tooling is part of the problem. It can be solved within the WG easily.
  282.  
  283. cwilso_: The challenge is, if the expectation is that to incubate in one area, you have to be an expert on everything, it's ver hard.
  284.  
  285. cwilso_: Back in my IE days, I was the guy who sat in the group. They'd tell me what they wanted, and I'd take the idea to the group and
  286. communicate it.
  287.  
  288. cwilso_: The engineers wouldn't jump in and participate.
  289.  
  290. cwilso_: So our goal is help encourage that.
  291.  
  292. TabAtkins: A side point - it's worthwhile to find the lowest-friction way to do some tech, without having to layer extra tooling. Separate
  293. repos do this well. They have their own problems (hard to move issues between repos), but for the goals we're trying to achieve (less
  294. firehose, les sintimidation), I think separate repos put us in the friendliest
  295.  
  296. *starting point* for what we want.
  297.  
  298. astearns: I think there's a trap we should strive to avoid, where wahat we do in incubation is done over here, then the proposals graduate
  299. to specs and we do the Rec track nonsense over here.
  300.  
  301. astearns: The line between those two things is ufzzy, and we'll make mistakes about what we graduated from incubation, and find it needs moe
  302. work after "graduating".
  303.  
  304. astearns: So we should ensure that the boundary *is* fuzzy, that people are contributing on both sides of th efence, make it a very low
  305. fence.
  306.  
  307. astearns: So an incubating proposal that is really close to being done, but can get more work by incubating, or we have a spec tha tmoved
  308. too quick and needs to bake more now, let's not throw it back and forth.
  309.  
  310. yoav: For webperf, we moved some specs that didn't get enough traction, they got moved to WICG for further incubation.
  311.  
  312. astearns: CSS is planning to do that too.
  313.  
  314. cwilso_: And web payments probably graduated a bit too early.
  315.  
  316. cwilso_: But yeah, I don't think the barrier should be high to move between them.
  317.  
  318. cwilso_: We're still socializng the meaning of incubation.
  319.  
  320. cwilso_: Some peole think it's awesome, this is much easier now.
  321.  
  322. cwilso_: Others think, "why are you demoting my stadnards works" and that's not what we want at all.
  323.  
  324. iank_: A lot of people have thought of incubation as either/or; if it's being incubated we can't talk about it as a WG.
  325.  
  326. iank_: But that's def wrong - if it needs debate...
  327.  
  328. iank_: Say we have a CSS spec in the CG, we can give status update, describe problems, maybe spend time talking about it, have a breakout
  329. session.
  330.  
  331. astearns: Def, bringing incubation topics to the WG to socialize them has to be part of the process.
  332.  
  333. rbyers: There's a related osurce of tensions I haven't heard yet - when does a design become stable enought o ship it?
  334.  
  335. rbyers: I think we generally concensus that "don't ship until Rec" is too slow.
  336.  
  337. rbyers: We try to balance evolving web efficiently, while not making too many mistakes.
  338.  
  339. rbyers: We want things to be usccessful, interoperable.
  340.  
  341. rbyers: We definitly invite feedback and concerns about how we're doing it in Blink, and I know the other vendors are as well.
  342. rbyers
  343. s/usccessful/successful/
  344.  
  345. mchampion: Dunno how many of you are in the AC, there's some angst about incubation.
  346. rbyers
  347. s/I haven't heard/that hasn't been discussed here/
  348.  
  349. mchampion: Soem member who aren't browser implementors or in the ecosystem, feel this is an in-group, a club of peole that they aren't a
  350. member of.
  351.  
  352. mchampion: They'd like devs and smaller players to have more of a voice, that they have in the WG process - you need signoff from a11y,
  353. security, etc - they see incubation as a way for the big gorillas to ram things thru.
  354.  
  355. mchamption: So looking for a way to persuade them WICG is an open community and a model everyone should use.
  356.  
  357. yoav: Is there anything that preventes them from participating?
  358. astearns
  359. success criteria for wicg - demonstrated, measured indications of the inclusivity mchampion is talking about
  360. tantek has joined (~tantek@public.cloak)
  361.  
  362. mchampion: Paymetns is an example, they thought they were incubating a spec to their satisfaction, but didn't get browsers involved.
  363.  
  364. cwilso_: I think they started an incubation, there were two incubations involved there. Why I thought it was graduated early.
  365.  
  366. cwilso_: I think this will dispel fears that smaller players have less interest in the process - this was designed to *increase* that.
  367.  
  368. cwilso_: Why I agreed to cochair is, when I was participating in SW discussions, that was an in-club.
  369.  
  370. cwilso_: Some people fixing appcache, then went semi-private - it wsn't intended to be, it was just scoping the discussion down.
  371.  
  372. cwilso_: So how to have scoped discussions, but in the open, and with smart IP policy, that feeds into the WG, without having to say "start
  373. a WG", because we weren't there yet.
  374.  
  375. cwilso_: So I think this helps. But ultimately nothing solves the problem that shipping code is impactful.
  376.  
  377. bkardell_: I think it helps the smaller vendors - it gets their voice more involved. That's a really important constituency.
  378.  
  379. astearns: I think it has the *potential* to do those, we have to make sure it happens that way.
  380.  
  381. mchampion: I have heard complaints from people who are non-members, where people in Discourse didn't get what they thought was a respectful
  382. hearing.
  383. n8s has left IRC ("My Mac has gone to sleep. ZZZzzz…")
  384.  
  385. mchampion: So even if an idea seems a little random, there's a palce to help them find a place, or gently disabuse them of that notion.
  386.  
  387. mchamption: Hasn't happened a lot, but there have been enough examples.
  388.  
  389. yoav: ONe thing to improve is that some people think it's "come up with your proposal, and bored spec authors/implements will run over and
  390. do something with it", and that's not how it works. ^_^
  391.  
  392. yoav: I agree that we need to make that clearer - you have to chamption your proposal, push it thru, help turn it into a spec.
  393.  
  394. cwilso_: And to udnerscore, we do have a respectful interaction policy. If you see people being disrespectful, please contact the chairs.
  395.  
  396. cwilso_: I've followed up on one or two issues, but it's a constant vigilance thing.
  397.  
  398. cwilso_: And the audience constantly expands, there will alway sbe people who jump in rudely.
  399.  
  400. cwilso_: Wrap-up!
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement