See also: IRC log
<scribe> scribe: MichaelC
<scribe> chair: Jeff_Jaffe
jj: Goal to figure out why Recs come in behind schedule
will brainstorm some of the ways to fix, starters on screen
then use voting process to sort out the top 5
krisk: start testing earlier
developers look for tests much earlier than we tend to have them ready
maybe should require availability of test suite to enter CR
paulc: it's backwards to scope first, then set schedule
think we need to be schedule driven
and set scope to match
consider that any shipping product has a window of opportunity
seldom see an appropriate prioritization of time in charters, from Team
mbodell: more tooling around assertions and testings to help groups with process
also more realistic in setting dates
schedules are patently over-optimistic, so not taken seriously
artb: earlier testing sounds good though in practice, starting testing earlier could be a lot of make-work
has been an issue that charters were fixed to 2-years spans
don't know if that's still a rule
have seen some ridiculous charters go out
AC should review more critically
bob: WG had a bunch of specs moving along
but didn't finish one till finished all
work was progressing but at its own pace
started doing implementations before Last Call, getting such feedback during the LC period
re above, piling a bunch of not tightly inter-related specs in a charter is difficult
roger: most agonizing delays have been due to scope creep
there aren't many adverse consequences to missing schedules, aside from having to admit it
there should be a process that management reduces scope of a WG if it starts missing milestones
<Bob> From my point of view most schedule creep is due to issues. ;-)
<Zakim> dbaron, you wanted to respond on testing and phases
krisk: In software the experience is clear. If you are missing schedule, to get on it you either reduce scope or accept lower quality.
dbaron: priorities change over time in response to feedback
so setting a schedule doesn't fully make sense
jj: otoh, setting a schedule that's over-optimistic when you reasonably know it is, also doesn't make sense
dbaron: cycling charter through AC is costly, don't want to do that too often
jj: why don't we just charter for what we believe to be reasonable time frame?
dbaron: not sure how to pick another time frame
annevk: one value of limited duration of charter is checking in on priorities
I've given up on schedule
not valuable use of time to try to get through the various steps
more valuable to stay on top of what implementers doing, what user needs are
to advance a feature, you often have to write test suite yourself
i.e., bottlenecks on a single person
jj: maybe not one size fits all
annevk: there's no end point to some of the work, it's incremental
<dbaron> the beginning of what I said about 8 minutes ago was that there's a difference between building the first version of a piece of technology and building additions to it to meet the evolving requirements of its users (where priorities may shift based on feedback)
kelly: sometimes groups don't realize the fullness of the scope they're taking on
jj: historically, if a spec took 5 years, probably meant WG was extended (w/ AC approval) at least twice
get given a whole bunch of reasons for while the milestones missed
jan: question of WG members are interested in schedule
should get implementer commitment earlier
there should be implementers to make a WG
so need to take this down to ownership of the schedule
paulc: some features could be in a version 2, or a longer-timeframe version 1
different orgs will have different hopes for which way a given feature goes
I am a big fan of modularization
<ArtB> +1 on getting implementer committment earlier -> perhaps no deliverable is included in a charter unless there are >2 implementation committments
that could help reduce version 2 pressure, because you'd see the version one actually getting done
set up self-reinforcing "getting it done" loop
separate editors from test development erases a key bottleneck
<dbaron> I think if the specs are small enough it's not a bottleneck.
szilles: I'm a big fan of modularization
one thing you don't know at the start is which features will get traction when
CSS WG finds things shake out, some gets well spec'd and implemented and some doesn't
with modules you can advance the modules that are active
this implies a continuous group model
so should look at a progress measure of WG behavior
<Zakim> chaals, you wanted to say work more with chairs.
chaals: W3C should work with chairs more
also think certain groups need to be continuous groups, e.g., HTML, CSS
some things always need ongoing development
with modules, should a be a reasonable process to add a deliverable to such a group
get the lawyer review, etc. but without costing the group a lot of time
jfa: 80 % of effort in 20 % of features, always a shock
companies need to do resourcing
but W3C doesn't control that
also can be difficult to build consensus
may have to live with longer schedule, between feature, quality, and time, sacrifice time
but have a "dashboard" to monitor status, progress, revised projections
responsibility of chair
sometimes you have to make the hard decisions, but start with the dashboard to see the trends
then question of who makes the decision
jj: AC ultimately
r12a: W3C has already had issue that incrementalism is not seen as right way to do things
W3C has to be seen to have continuous activity
but I suggest that needs to be continuous *production*
and break fear that things don't have to be crammed in one release, because reasonably expect next release
don't think modularization is solution, the solution is project management
instead, have faster-developed smaller charters
we are not trained as product managers
mbodell: create a test editor role for a spec
and be sure to fill that role
early in spec development, request tests accompany change requests
<chaals> [chaals notes that webapps decided to have a named test manager, starting this week]
ArtB: don't add deliverables to charters unless at least two orgs committed to implement
<chaals> [and thinks watching the experiment for a few months might be worthwhile]
and at least two individuals to work on test suites
annevk: not in favor of modules
cross reference, inter-dependency problems
with multi levels, have synchronization problems
leads to not good use of editor time
editor time is a precious resource to use well or find funds to pay more
jj: vote for top 5
<ArtB> ArtB's top 4: 4, 11, 17 and 21
Start testing earlier: 5
Become Time-based urgency/scheduling: 5
Tooling for testing assertion: 3
Realistic in setting dates: 3
More modular / modularize: 4
Implementations due by LC: 3
Proactively chop scope if you miss schedule: 1
Put discipline behind scope of work: 2
Implementer commitment early: 7
Prevent v2 from infecting v1: 3
Some groups are living groups: 8
Make it easy to add module to charter: 5
Live with schedule but create a dashboard and have conversation with chair: 3
More releases of standards: 7
Project management training: 5
Create test editor role: 9
Accompany change requests with test cases: 2
Use editor time wisely: 2
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/reasons/ways to fix/ Succeeded: s/<missed>/In software the experience is clear. If you are missing schedule, to get on it you either reduce scope or accept lower quality./ Succeeded: s/earlier: 4/earlier: 5/ Found Scribe: MichaelC Inferring ScribeNick: MichaelC WARNING: No "Topic:" lines found. Present: Jeff Roger SteveZ MichaelCooper Anne Shawn Kris ArtB JFA PaulC Chaals R12A DavidB MichaelBodell Got date from IRC log name: 02 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/02-schedule-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. 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]