See also: IRC log
<dom> ScribeNick: chaals
<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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/process./process?/ Succeeded: s/against/using/ Succeeded: s/??/stearns/ Succeeded: s/Scribe:/ScribeNick:/ Succeeded: s/WAIT/WAI/ Succeeded: s/chunks/chunks to review/ Found ScribeNick: chaals Found ScribeNick: chaals Found ScribeNick: Josh_Soref Inferring Scribes: chaals, Josh_Soref Scribes: chaals, Josh_Soref ScribeNicks: chaals, Josh_Soref WARNING: No "Topic:" lines found. Present: Bryan_Sullivan Josh_Soref Dominique_Hazael-Massieux Agenda: http://www.w3.org/wiki/TPAC2011/Agile_Standardization Got date from IRC log name: 02 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/02-agile-minutes.html People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report[End of scribe.perl diagnostic output]