Agile Standardization within the W3C Process -- 02 Nov 2011

<dom> ScribeNick: chaals

SZ: CSS has learned some lessons about making things in a more agile way (by doing it the other way)...

TA: We're talking about what we learned since doing CSS2 10 year ago.
... a lesson in how to make modularisation work (or not). Mostly in line with W3C...
... but what that means. Who has authority.

<dom> Re CSS3 module dependencies hell, see http://people.w3.org/~dom/archives/2005/03/css-3-modules-dependencies-visualized/ (back in 2005)

EE: CSS1 was little enough to be a whole spec
... CSS2 was big so got split into chapters but they weren't coordinated.

<dom> and more specifically http://www.w3.org/2005/03/css-dep/css3deps.png

EE: CSS3 was even bigger, so got broken into modules that were going to develop independently and the interactions and divisions would be clear.
... Not much progress could be made because dependencies blocked forward motion.
... We broke up dependencies and said "depend on CSS 2.1 which is further ahead in process so doesn't block progress"
... Rebased dependencies to move forwards.
... Ended up with policy of replacing 2.1 module by module independently.
... 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.
... Could grow following teh market

SZ: Another reason to split modules is because some features get traction faster. We don't always know that a priori.

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.

TA: Lesson. Really need to manage dependencies in anything bigger than a single page.
... Identifying the bedrock things you need and doing them fast is valuable.

EE: Keep the bedrock as small as you can - adding to it slows it down.

TA: We wouldn't use CSS 2.1 as a base again, we'd focus on syntax, values, cascade.
... The rest would be independent modules.

JS: How do you handle glossary dependencies?

TA: When possible limit the things everyone refers to.
... If you need to change the bedrock, do so.
... The spec will probably have some error or other forever, somewhere.

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.
... e.g. a "block container" was an abstracted definition that let us work against a single reference.
... We have datatypes defined, and new modules refer to a datatype from 2.1. Then we add a module that redefines values and units.

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.

EE: You can hook into a definition, or you can add to a definition.

SZ: Think anyone in CSS WG wouldl be happy to talk about what we do (there are lots here, and some elsewhere)

TA: W3C spec stages as defined.
... we act as if the ones that matter are WD (we do design), CR (testing), and REC (maintenance).
... Editors' draft is constantly revised, and transient.

RB: How do you decide to go to Next Public Draft.

<stearns> http://www.xanthir.com/talks/2011-11-02/

EE: "exploring, revising, stabilizing" match to spec stages, roughly.
... Decision for FPWD is made when we look at a draft and agree we want to deal with these problems.

BS: How does this help us understand agility in the process?

TA: In revising phase, we cut things if we don't care about them still.

EE: We publish a "pre-last-call" draft. That helps avoid multiple last calls.
... Can't get beyond CR without implementations.

BS: Elsewhere we noted that you can do well with early implementation.

SZ: Process says CR is last point to get implmentation - you can have it as early as you want.

BS: How does that help agility?

TA: Sometimes we have implementation experience driving development of spec.

EE: About half - the other half can get to CR without implementation.
... point of CR isn't stability of spec, it is about really testing the spec using implmentations. Can be changed if we need to.
... 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.

SZ: Recently various organisations have brought in a proof of concept, that they are willing to change as teh spec develops.
... "Take it or leave it" implementation is *not* helpful.

<bryan> we need to prototype earlier in the process, remove features that can't be prototyped earlier

SZ: to the process.

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.

EE: Idea is we have enough implementation experience to be pretty sure of the spec.

KK: Is it super-agile to start writing tests in CR?

<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.

EE: You can start any time. CR is where you have to do that.

KK: You can't leave CR without a test suite?

TA: W3C requirement. You can't drop prefixes until then is a CSS WG requirement.

ABate: How much friction is there from people having early implmentations they don't want to change.

EE: Not much. It is made clear to members, and we've been there working under that process and understand it.

BS: If they do that they shouldn't launch the product because they load developers with the legacy.

ABate: Do you think the web community in general understand?

TA: No. When they see vendor prefix they use it.

ABate: They are learning from the pain of having it changed under them?

TA: Yep.

ABate: Is there a way to fix it other than hurting them until they learn?

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.

<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.

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.

EE: We don't want people depending on vendor-specific stuff.
... So prefixing method plus getting something finished faster helps clarify that

stearns: Another approach is don't ship. But then WG doesn't get the broad feedback that helps improve the spec.

TA: There are other approaches. We've been playing with shipping experimental stuff in alphas but turning them off in release builds.
... for now we leave that as a problem for implementors and try to keep the time down.

EE: Editor / WG responsibility split.
... Don't have a formal process for escalation, we describe how it should be, and it seems to happen like that.

SZ: Since discussion is in public, anyone can comment and people can see what is or isn't done.

ABate: Is it clear to people which of your stages specs are at (from inside, from outside)?

EE: It is a gradual change with fuzzy boundaries. Nothing the outside world can use to distinguish.

TA: That is something we should think about doing.

<Josh_Soref> ScribeNick: Josh_Soref

TA: the nice thing about this
... is because we seek wg approval early on
... early on you establish a strong voice early on

EE: you get flexibility early on
... and you aren't hampered by the process
... later on, we're keeping a close eye on the changes
... avoiding pitfalls, regressions,
... ensuring compatibility
... by ensuring everyone in the WG is aware of what's going on
... that gives us the best of both worlds

bryan: where in this process
... muse early stages
... not designed by committee
... at some point, you want to be sure they're on board
... good signs
... where does that begin to really happen?

EE: all of them
... the exploring phase
... the editor gives a draft early on
... seeks feedback

TA: later, the WG itself is the proxy for the browsers that are implementing it
... all of the browsers should be involved in the spec as it reaches higher level of maturity levels
... whenever you have an excluded vendor
... you have problems
... it turns out "oh, we hate this"

bryan: so you need to be sure everyone's paying attention

EE: that's why the editors proactively bring to attention of the WG
... and people pay more attention later on

AS: Alan Sterns
... in this WG, it seems you have a rep from each UA

TA: we're lucky that we have multiple reps from each UA

SZ: for your WG, it's whomever will be your implementers

TA: for smaller WGs
... assume web facing
... you should have ideally one rep from each browser
... at least paying attention
... and providing comments
... at the bare minimum, if there's no rep from a browser in the WG
... actively talk to them outside the WG
... it makes them pseudo members, but good enough
... there's a somewhat persistent argument about what should be a driver for a spec
... 1. standards body's
... 2. implementations and specs follow
... 3. web devs drive
... none of these are true
... if you design a spec preferring one or the other
... you'll get it wrong
... it could be bug-ridden
... or doesn't port

AS: and tool developers

TA: sure

<fantasai> or just realy bad API design :)

<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.

JS: where do you fit in other stakeholders?
... I work in WAI
... with so many specs, so many modules
... it's difficult for other groups to review so many modules
... I'm on the UAAGs
... there's a lot of potential for a lot of problems
... and i'm very constrained
... I have a lot of stakeholders in disability organizations
... that have to be integrated
... where do you integrate their feedback in the process

TC: follow question
... how many RFCs has the accessibility community been tracking
... there's CSS modules, a subset of W3 specs
... which is a subset of Web Standards
... another subset of Web Standards is IETF specs

JS: in WAI, we do a lot

TC: my point is that the problem of too many specs, isn't specific to this WG
... or even W3

SZ: we need to be clear about the levels we're talking about
... we'd want WAI to look at a spec when it reaches STABLE
... and we need to be clear to everyone not in the WG, not just WAI
... doing a better job of indicating stability

JS: so you're suggesting I ask stakeholders at STABLE

EE: depends on feedback
... Requirements at Design
... And we need to be good at indicating phases

florian: in that respect, the number of specs isn't the problem
... it's the number of things being speced
... it's the size of the scope

<bryan> Use case review is where stakeholder input needs to be sought, e.g. in WAI or outside W3C.

KK: I think the accessibility ones

<tantek> (Thanks to Josh_Soref for minuting)

KK: that's going to be a potentially substantial changes to the spec

EE: in my experience responding to Accessibility is adding Informative

KK: i'd suggest give your feedback much earlier
... -> JS

EE: it depends on the kind of feedback

SZ: it's now 2:25p
... a good point to wrap up
... the main thing, TA, please put your 4 points back up

[ Agile Standardization in CSS ]

SZ: managable

EE: scope your features

SZ: modularization has helped us have parallel activity
... as florian pointed out, it makes for more managable chunks to review
... mostly between 5 and 15 pages
... fairly manageable from a review process
... adjust the editor responsibility during the process
... look at things together

dom: we need someone to summarize the discussion

SZ: yes, we'll work it out (SZ, EE, TA)
... thank you all for attending
... there's another session on processes in CB#1
... if you'd like more details on the CSS WG process, there's a link from the CSS wiki page

[ Applause ]

<myakura> Agile Standardization within the W3C Process

- DRAFT -

Agile Standardization within the W3C Process

02 Nov 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output