20:37:38 <RRSAgent> RRSAgent has joined #agile
20:37:38 <RRSAgent> logging to http://www.w3.org/2011/11/02-agile-irc
20:37:45 <bryan> present+ Bryan_Sullivan
20:37:56 <dom> ScribeNick: chaals
20:37:58 <dom> ScribeNick: chaals
20:38:26 <tobie> tobie has joined #agile
20:38:33 <chaals> SZ: CSS has learned some lessons about making things in a more agile way (by doing it the other way)...
20:38:49 <Josh_Soref> present+ Josh_Soref 
20:39:10 <chaals> TA: We're talking about what we learned since doing CSS2 10 year ago.
20:39:19 <dom> Present+ Dominique_Hazael-Massieux
20:39:29 <chaals> ... a lesson in how to make modularisation work (or not). Mostly in line with W3C...
20:39:46 <chaals> ... but what that means. Who has authority.
20:39:55 <hoashi> hoashi has joined #agile
20:40:15 <dom> Re CSS3 module dependencies hell, see http://people.w3.org/~dom/archives/2005/03/css-3-modules-dependencies-visualized/ (back in 2005)
20:40:16 <chaals> EE: CSS1 was little enough to be a whole spec
20:40:34 <chaals> ... CSS2 was big so got split into chapters but they weren't coordinated.
20:40:53 <dom> and more specifically http://www.w3.org/2005/03/css-dep/css3deps.png
20:41:03 <chaals> ... CSS3 was even bigger, so got broken into modules that were going to develop independently and the interactions and divisions would be clear.
20:41:23 <chaals> ... Not much progress could be made because dependencies blocked forward motion.
20:41:46 <rvaneijk> rvaneijk has joined #agile
20:41:48 <chaals> ... We broke up dependencies and said "depend on CSS 2.1 which is further ahead in process so doesn't block progress"
20:41:53 <MichaelC> MichaelC has joined #agile
20:42:09 <chaals> ... Rebased dependencies to move forwards.
20:42:26 <dbaron> dbaron has joined #agile
20:42:28 <chaals> ... Ended up with policy of replacing 2.1 module by module independently.
20:43:00 <chaals> ... So no complete CSS3, just pieces of stuff that were at level 3 going to level 4 while other stuff wasn't yet at level 2.
20:43:07 <chaals> ... Could grow following teh market
20:43:31 <chaals> SZ: Another reason to split modules is because some features get traction faster. We don't always know that a priori.
20:43:46 <darobin> darobin has joined #agile
20:44:19 <chaals> EE: We could find stable stuff in a module, cut it out and let it progress while the rest of it moved at whatever pace it had.
20:44:38 <chaals> TA: Lesson. Really need to manage dependencies in anything bigger than a single page.
20:45:02 <chaals> ... Identifying the bedrock things you need and doing them fast is valuable.
20:45:15 <chaals> EE: Keep the bedrock as small as you can - adding to it slows it down.
20:45:29 <szilles> szilles has joined #agile
20:45:42 <chaals> TA: We wouldn't use CSS 2.1 as a base again, we'd focus on syntax, values, cascade.
20:45:51 <chaals> ... The rest would be independent modules.
20:46:23 <chaals> JS: How do you handle glossary dependencies?
20:46:36 <chaals> TA: When possible limit the things everyone refers to.
20:46:50 <chaals> ... If you need to change the bedrock, do so.
20:47:19 <chaals> ... The spec will probably have some error or other forever, somewhere.
20:47:34 <myakura> myakura has joined #agile
20:47:58 <chaals> EE: CSS1 had list of display types that could be affected. Adding a new display type meant you had to change stuff all over the place to match. So we created a definition for types of interactions.
20:48:39 <chaals> ... e.g. a "block container" was an abstracted definition that let us work against a single reference.
20:49:37 <chaals> ... We have datatypes defined, and new modules refer to a datatype from 2.1. Then we add a module that redefines values and units.
20:49:54 <MoZ> MoZ has joined #agile
20:50:20 <chaals> TA: Nice part is that dependency is not explicitly required. You can implement backgrounds and borders using either level of the values and units specification.
20:50:46 <chaals> EE: You can hook into a definition, or you can add to a definition.
20:51:08 <chaals> SZ: Think anyone in CSS WG wouldl be happy to talk about what we do (there are lots here, and some elsewhere)
20:51:26 <chaals> TA: W3C spec stages as defined.
20:51:58 <chaals> ... we act as if the ones that matter are WD (we do design), CR (testing), and REC (maintenance).
20:52:13 <chaals> ... Editors' draft is constantly revised, and transient.
20:52:23 <chaals> RB: How do you decide to go to Next Public Draft.
20:52:35 <stearns> stearns has joined #agile
20:52:59 <stearns> http://www.xanthir.com/talks/2011-11-02/
20:53:13 <chaals> EE: "exploring, revising, stabilizing" match to spec stages, roughly.
20:53:56 <chaals> ... Decision for FPWD is made when we look at a draft and agree we want to deal with these problems.
20:54:10 <chaals> BS: How does this help us understand agility in the process.
20:54:25 <chaals> s/process./process?/
20:54:43 <chaals> TA: In revising phase, we cut things if we don't care about them still.
20:55:15 <chaals> EE: We publish a "pre-last-call" draft. That helps avoid multiple last calls.
20:56:06 <chaals> ... Can't get beyond CR without implementations.
20:56:26 <chaals> BS: Elsewhere we noted that you can do well with early implementation.
20:56:41 <chaals> SZ: Process says CR is last point to get implmentation - you can have it as early as you want.
20:56:50 <chaals> BS: How does that help agility?
20:57:04 <chaals> TA: Sometimes we have implementation experience driving development of spec.
20:57:18 <chaals> EE: About half - the other half can get to CR without implementation.
20:57:45 <chaals> ... point of CR isn't stability of spec, it is about really testing the spec against implmentations. Can be changed if we need to.
20:58:18 <chaals> ... Try to avoid going back to working draft, if it isn't clear how to implement we try to get early implmentation but that doesn't hold us back from going to CR.
20:58:20 <fantasai> s/against/using/
20:58:44 <chaals> SZ: Recently various organisations have brought in a proof of concept, that they are willing to change as teh spec develops.
20:59:01 <chaals> ... "Take it or leave it" implementation is *not* helpful.
20:59:02 <bryan> we need to prototype earlier in the process, remove features that can't be prototyped earlier
20:59:08 <chaals> ... to the process.
21:00:19 <chaals> TA: CSS is very strict about vendor-prfixing. Late CR is where we are OK with dropping prefixes, when they've run against the test suite and know how to get it right.
21:00:37 <chaals> EE: Idea is we have enough implementation experience to be pretty sure of the spec.
21:00:49 <chaals> KK: Is it super-agile to start writing tests in CR?
21:00:53 <bryan> The "bedrock" should not include features that can't be implemented early. Risk of handing in CR is increased by presence of features that are not widely supported by implementers who are actively working to prototype early.
21:01:07 <chaals> EE: You can start any time. CR is where you have to do that.
21:01:20 <chaals> KK: You can't leave CR  without a test suite?
21:01:37 <chaals> TA: W3C requirement. You can't drop prefixes until then is a CSS WG requirement.
21:01:55 <chaals> ABate: How much friction is there from people having early implmentations they don't want to change.
21:01:56 <Frankie> Frankie has joined #agile
21:02:18 <chaals> EE: Not much. It is made clear to members, and we've been there working under that process and understand it.
21:02:56 <chaals> BS: If they do that they shouldn't launch the product because they load developers with the legacy.
21:03:05 <chaals> ABate: Do you think the web community in general understand?
21:03:14 <chaals> TA: No. When they see vendor prefix they use it.
21:03:28 <chaals> ABate: They are learning from the pain of having it changed under them?
21:03:34 <chaals> TA: Yep.
21:03:45 <chaals> ABate: Is there a way to fix it other than hurting them until they learn?
21:04:20 <chaals> TA: Not a lot. Being strict about cutting features and finishing what works is helpful. You should focus on getting the popular stuff done as fast as possible, to reduce the time this problem grows.
21:04:51 <bryan> Launch of too-early implementations results in interoperability-affecting baggage. Vendors should be encouraged to prototype their unique ideas but not release them until they are really stable in the specs, and supported (in principle, and plans for implementation) more widely.
21:05:16 <chaals> FR: Also up to user agents. For a spec that doesn't match first prefixed implementation, you can add a second different prefixed implementation and keep going.
21:05:28 <chaals> EE: We don't want people depending on vendor-specific stuff.
21:05:52 <chaals> ... So prefixing method plus getting something finished faster helps clarify that
21:06:14 <chaals> ??: Another approach is don't ship. But then WG doesn't get the broad feedback that helps improve the spec.
21:06:44 <stearns> s/??/stearns/
21:06:52 <chaals> TA: There are other approaches. We've been playing with shipping experimental stuff in alphas but turning them off in release builds.
21:07:25 <chaals> ... for now we leave that as a problem for implementors and try to keep the time down.
21:07:49 <chaals> EE: Editor / WG responsibility split.
21:09:36 <chaals> ... Don't have a formal process for escalation, we describe how it should be, and it seems to happen like that.
21:10:01 <chaals> SZ: Since discussion is in public, anyone can comment and people can see what is or isn't done.
21:11:04 <chaals> ABate: Is it clear to people which of your stages specs are at (from inside, from outside)?
21:11:37 <chaals> EE: It is a gradual change with fuzzy boundaries. Nothing the outside world can use to distinguish.
21:11:47 <chaals> TA: That is something we should think about doing.
21:12:30 <Josh_Soref> Scribe: Josh_Soref 
21:12:36 <Josh_Soref> TA: the nice thing about this
21:12:46 <Josh_Soref> ... is because we seek wg approval early on
21:13:02 <adrianba> adrianba has joined #agile
21:13:05 <Josh_Soref> ... early on you establish a strong voice early on
21:13:32 <Josh_Soref> EE: you get flexibility early on
21:13:32 <Josh_Soref> ... and you aren't hampered by the process
21:13:37 <Josh_Soref> ... later on, we're keeping a close eye on the changes
21:13:44 <Josh_Soref> ... avoiding pitfalls, regressions,
21:13:48 <Josh_Soref> ... ensuring compatibility
21:14:02 <Josh_Soref> ... by ensuring everyone in the WG is aware of what's going on
21:14:09 <dbaron> s/Scribe:/ScribeNick:/
21:14:13 <Josh_Soref> ... that gives us the best of both worlds
21:14:36 <Josh_Soref> bryan: where in this process
21:14:43 <Josh_Soref> ... muse early stages
21:14:47 <Josh_Soref> ... not designed by committee
21:14:56 <Josh_Soref> ... at some point, you want to be sure they're on board
21:15:00 <Josh_Soref> ... good signs
21:15:05 <Josh_Soref> ... where does that begin to really happen?
21:15:11 <Josh_Soref> EE: all of them
21:15:15 <Josh_Soref> ... the exploring phase
21:15:22 <Josh_Soref> ... the editor gives a draft early on
21:15:25 <Josh_Soref> ... seeks feedback
21:15:35 <Josh_Soref> TA: later, the WG itself is the proxy for the browsers that are implementing it
21:15:49 <Josh_Soref> ... all of the browsers should be involved in the spec as it reaches higher level of maturity levels
21:15:50 <adrianba> rrsagent, pointer
21:15:50 <RRSAgent> See http://www.w3.org/2011/11/02-agile-irc#T21-15-50
21:15:55 <Josh_Soref> ... whenever you have an excluded vendor
21:16:00 <Josh_Soref> ... you have problems
21:16:06 <Josh_Soref> ... it turns out "oh, we hate this"
21:16:25 <Josh_Soref> bryan: so you need to be sure everyone's paying attention
21:16:39 <Josh_Soref> EE: that's why the editors proactively bring to attention of the WG
21:16:47 <Josh_Soref> ... and people pay more attention later on
21:16:59 <Josh_Soref> AS: Alan Sterns
21:17:10 <Josh_Soref> ... in this WG, it seems you have a rep from each UA
21:17:20 <chaals> chaals has joined #agile
21:17:22 <Josh_Soref> TA: we're lucky that we have multiple reps from each UA
21:17:40 <Josh_Soref> SZ: for your WG, it's whomever will be your implementers
21:17:55 <Josh_Soref> TA: for smaller WGs
21:17:59 <Josh_Soref> ... assume web facing
21:18:04 <Rossen> Rossen has joined #agile
21:18:07 <Josh_Soref> ... you should have ideally one rep from each browser
21:18:12 <Josh_Soref> ... at least paying attention
21:18:15 <Josh_Soref> ... and providing comments
21:18:27 <Josh_Soref> ... at the bare minimum, if there's no rep from a browser in the WG
21:18:36 <Josh_Soref> ... actively talk to them outside the WG
21:18:44 <Josh_Soref> ... it makes them pseudo members, but good enough
21:18:55 <Josh_Soref> TA: there's a somewhat persistent argument about what should be a driver for a spec
21:19:00 <Josh_Soref> ... 1. standards body's
21:19:10 <Josh_Soref> ... 2. implementations and specs follow
21:19:14 <Josh_Soref> ... 3. web devs drive
21:19:19 <Josh_Soref> TA: none of these are true
21:19:22 <rvaneijk> rvaneijk has left #agile
21:19:30 <Josh_Soref> ... if you design a spec preferring one or the other
21:19:35 <Josh_Soref> ... you'll get it wrong
21:19:42 <Josh_Soref> ... it could be bug-ridden
21:19:45 <Josh_Soref> ... or doesn't port
21:19:55 <Josh_Soref> AS: and tool developers
21:19:58 <Josh_Soref> TA: sure
21:20:00 <fantasai> or just realy bad API design :)
21:20:04 <bryan> The participation of the major browser vendors (and reasonable expectations of consensus on the specs) needs to be verified early in the process, so divergence and features at risk can be determined early. If a browser vendor is not participating in the group, there should be some form of attempt to get feedback, and they should be open to that.
21:20:14 <Josh_Soref> JS: where do you fit in other stakeholders?
21:20:17 <Josh_Soref> ... I work in WAIT
21:20:20 <Josh_Soref> s/WAIT/WAI/
21:20:26 <Josh_Soref> ... with so many specs, so many modules
21:20:34 <Josh_Soref> ... it's difficult for other groups to review so many modules
21:20:39 <Josh_Soref> ... I'm on the UAAGs
21:20:46 <Josh_Soref> ... there's a lot of potential for a lot of problems
21:20:50 <Josh_Soref> ... and i'm very constrained
21:21:00 <Josh_Soref> ... I have a lot of stakeholders in disability organizations
21:21:16 <Josh_Soref> ... that have to be integrated
21:21:24 <Josh_Soref> ... where do you integrate their feedback in the process
21:21:38 <Josh_Soref> TC: follow question
21:21:48 <Josh_Soref> ... how many RFCs has the accessibility community been tracking
21:21:55 <Josh_Soref> ... there's CSS modules, a subset of W3 specs
21:22:03 <Josh_Soref> ... which is a subset of Web Standards
21:22:11 <Josh_Soref> .. another subset of Web Standards is IETF specs
21:22:17 <Josh_Soref> JS: in WAI, we do a lot
21:22:28 <Josh_Soref> TC: my point is that the problem of too many specs, isn't specific to this WG
21:22:34 <Josh_Soref> ... or even W3
21:22:51 <tantek> tantek has joined #agile
21:22:51 <Josh_Soref> SZ: we need to be clear about the levels we're talking about
21:23:00 <Josh_Soref> ... we'd want WAI to look at a spec when it reaches STABLE
21:23:11 <Josh_Soref> ... and we need to be clear to everyone not in the WG, not just WAI
21:23:17 <Josh_Soref> ... doing a better job of indicating stability
21:23:27 <Josh_Soref> JS: so you're suggesting I ask stakeholders at STABLE
21:23:31 <Josh_Soref> EE: depends on feedback
21:23:38 <Josh_Soref> ... Requirements at Design
21:23:48 <Josh_Soref> ... And we need to be good at indicating phases
21:23:55 <Josh_Soref> florian: in that respect, the number of specs isn't the problem
21:24:01 <Josh_Soref> .. it's the number of things being speced
21:24:06 <Josh_Soref> ... it's the size of the scope
21:24:06 <bryan> Use case review is where stakeholder input needs to be sought, e.g. in WAI or outside W3C.
21:24:22 <Josh_Soref> KK: I think the accessibility ones
21:24:28 <tantek> (Thanks to Josh_Soref for minuting)
21:24:33 <Josh_Soref> ... that's going to be a potentially substantial changes to the spec
21:24:49 <Josh_Soref> EE: in my experience responding to Accessibility is adding Informative
21:24:56 <Josh_Soref> KK: i'd suggest give your feedback much earlier
21:25:05 <Josh_Soref> ... -> JS
21:25:11 <Josh_Soref> EE: it depends on the kind of feedback
21:25:15 <Josh_Soref> SZ: it's now 2:25p
21:25:20 <Josh_Soref> ... a good point to wrap up
21:25:31 <Josh_Soref> ... the main thing, TA, please put your 4 points back up
21:25:38 <Josh_Soref> [ Agile Standardization in CSS ]
21:25:47 <Josh_Soref> SZ: managable
21:25:51 <Josh_Soref> EE: scope your features
21:26:02 <Josh_Soref> SZ: modularization has helped us have parallel activity
21:26:12 <Josh_Soref> ... as florian pointed out, it makes for more managable chunks
21:26:17 <Josh_Soref> ... mostly between 5 and 15 pages
21:26:22 <Josh_Soref> ... fairly manageable from a review process
21:26:27 <fantasai> s/chunks/chunks to review/
21:26:42 <Josh_Soref> SZ: adjust the editor responsibility during the process
21:26:49 <Josh_Soref> ... look at things together
21:26:57 <Josh_Soref> dom: we need someone to summarize the discussion
21:27:00 <adrianba> adrianba has left #agile
21:27:05 <Josh_Soref> SZ: yes, we'll work it out (SZ, EE, TA)
21:27:10 <Josh_Soref> SZ: thank you all for attending
21:27:23 <Josh_Soref> ... there's another session on processes in CB#1
21:27:23 <holstege_lt> holstege_lt has left #agile
21:27:44 <Josh_Soref> ... if you'd like more details on the CSS WG process, there's a link from the CSS wiki page
21:27:54 <Josh_Soref> [ Applause ]
21:28:09 <Josh_Soref> RRSAgent, make minutes
21:28:09 <RRSAgent> I have made the request to generate http://www.w3.org/2011/11/02-agile-minutes.html Josh_Soref
21:33:20 <tobie> tobie has joined #agile
21:33:58 <krisk> krisk has joined #agile
21:34:22 <szilles> szilles has joined #agile
21:35:02 <krisk> krisk has left #agile
21:35:42 <dom> dom has left #agile
21:35:54 <darobin> darobin has joined #agile
21:37:43 <MoZ> MoZ has joined #agile
21:38:06 <plinss> plinss has joined #agile
21:38:41 <arronei> arronei has joined #agile
21:39:30 <matt> matt has left #agile
21:41:32 <plinss> plinss has joined #agile
21:43:01 <plinss> plinss has joined #agile
21:44:29 <myakura> Agile Standardization within the W3C Process
21:44:52 <myakura> Meeting: Agile Standardization within the W3C Process
21:46:12 <myakura> Chair: Steve Zilles
21:46:16 <tpod> tpod has joined #agile
21:46:27 <myakura> Agenda: http://www.w3.org/wiki/TPAC2011/Agile_Standardization
21:46:52 <myakura> RRSAgent, make minutes
21:46:52 <RRSAgent> I have made the request to generate http://www.w3.org/2011/11/02-agile-minutes.html myakura
21:49:17 <Josh_Soref> Josh_Soref has left #agile
21:55:59 <szilles> szilles has joined #agile
22:15:37 <tobie> tobie has joined #agile
22:22:01 <tpod> tpod has joined #agile
22:33:07 <TabAtkins_> TabAtkins_ has joined #agile
22:36:08 <Frankie> Frankie has joined #agile
22:36:54 <plinss> plinss has joined #agile
22:38:50 <arronei> arronei has joined #agile
22:39:05 <TabAtkins_> TabAtkins_ has joined #agile
22:43:15 <jeanne> jeanne has joined #agile
22:46:47 <myakura> myakura has joined #agile
22:49:21 <szilles> szilles has joined #agile
23:30:40 <szilles> szilles has joined #agile
23:31:45 <myakura> myakura has left #agile
23:32:01 <jeanne> jeanne has joined #agile
23:43:37 <arronei> arronei has joined #agile
23:45:11 <TabAtkins_> TabAtkins_ has joined #agile
23:49:30 <tantek> tantek has joined #agile
23:57:48 <darobin> darobin has joined #agile