Fixing schedule delays -- 02 Nov 2011

<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

- DRAFT -

Fixing schedule delays

02 Nov 2011

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output