TPAC Breakout: Revisiting How W3C creates standards -- 02 Nov 2011

<scribe> scribe: Chaals

Experimental Process

KS: Marcos wanted to address specific proposals, I wanted to talk about experimental process.
... idea is to discuss and work out ideas.
... Would like to come away with suggestions for W3C about changes we should look at making.

SZ: As AB, ideas of what things need to be fixed even if you don't know how would be good.

KS: Right. start by identifying problems we have.
... would like to throw up points, without discussion.

MC: questions - how do we go from idea to FPWD, how quickly, what are the implications?

EE: In CSS people toss ideas on mailing list and come up with a public draft. Discussed in WG. If we want to tackle it, we take it on by resolution, and then go through our spec process.

DG: More complex, because a new idea may not fit into charter.

<inserted> [ http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards ]

<Josh_Soref> i|address specific goals|[ http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards ]|

DG: Not a theoretical list, it goes to lawyers for patent review.

<fantasai> more details on the csswg process - http://fantasai.inkedblade.net/weblog/2011/inside-csswg/

MC: what are negatives?
... rechartering is slow.

<fantasai> chaals: How do you get the people who are interested in/ should be working on an idea into the group?

CMN: Finding and gathering interested parties.

BS: How to get input of those who aren't all that interested.

CMN: agree

OT: Corrollary - charters include deliverables. That can be a constraint on what you *aim* to do.

<fantasai> OT talks about having a goal, deciding to change approach partway is incompat w/ charter

SZ: Broad scope can also inhibit participation by introducing collateral IPR commitment

MC: Are there examples?

CMN: Geolocation

MC: Web Notification.
... There are community groups that can sidestep that issue.
... In spec development, how are drafts produced, how often do specs get published.
... This is data that could be useful.

[publish as in "on TR"]

scribe: How does this compare to the "live specification" model?
... There is review fatigue as a problem, and people latching on to dated versions that causes problems in the market by introducing legacy issues.
... Published snapshots are out of date.

PC: Old folks remember that the reason we pubished early, published often was because groups were member only. That showed the public what was going on. Now nearly all groups are public, so think about TR page in context

EE: At that point, periodic snapshot approach was appropriate now perhaps, TR page is maybe not so appropriate.

IJ: There are several reasons. To have a centralised index where you can find what W3Cis doing. Another is heartbeat. Another was pressure to make progress

BS: Living document - size of spec has an impact on whether it ever finishes development.
... We could have one entire W3C spec, but to ship we have to break things up.

MC: What is the motivation of a last call, given that there are lots.

SZ: My memory is that the term was copied from IETF.
... for people who were not so interested, was the notification that they had to review now or lose their chance.

AvK: Process says group has addressed its own concerns and other concerns already raised.

PC: That is not true - that is CR.
... chairs should ensure that the timeframe and length of LC is acceptable to identified liaisons

SZ: Part of it was to keep a lid on further discussion within the WG.

DG: Process mentions mandatory liaisons, for those include in charter.

<mbodell> From the process document: Purpose: A Working Group's Last Call announcement is a signal that:... the Working Group believes that it has satisfied significant dependencies with other groups;

DG: Issues don't have to be resolved, but you have to make the contact.
... Not always the case.

<ArtB> http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Point #3 says "Indicate which dependencies with other groups the Working Group believes it has satisfied, and report which dependencies have not been satisfied." as an Entrance criteria

<dom> http://xkcd.com/386/

SZ: Last call is too big a sledgehammer - too late in the process to get the inputs that need to happen earlier.
... It's often not last.

MC: IPR exclusions is also an issue for last call.

[reading the process document]

AB: You need a last call to get to last call.

PC: Way that is done is a message to chair's list, saying they are ready to go to last call, and checking if that's OK.

MC: We agree that IPR milestones are important?

AvK: IPR is a problem - decade-old non recs are not covered by IPR

FH: We are conflating things. publication of WD is seperate from how to inform people of where you are up to.
... Understand concern that the editors' draft is really the latest one, and TR brings confusion. If you publish often enough does that help?

MC: What if we are always in last call.

EE: LC is overloaded. It is a communication with other WGs asking for feedback. It functions as a last call for comments before CR. It is also proposed edited CR.

DB: Regarding communication to other working groups. Asking for comments, they come and comment, tends to lead to excess controversy. different sets of people converging on different opinions have to be reconciled, which doesn't work out well.
... You are better off with early comments and integrating them.

MC: Who are we writing the specs for?
... where are the implementors in the process.

SH: Hopefully in the WG

EE: or on the mailing list.

MC: Does this work in the way they work?

<fjh> isn't there an informal process as well as the formal process?

MB: Last call is a specific case. there is a lot of value, but a lot of time and effort in getting to recommendation. There is confusion in people implementing some editors' draft, and not understanding the entire process.
... some users don't care about interop or testing, they just want to use a new feature they see.

AvK: Main benefit of standards is patent protection. We're not getting that because spec doesn't get to Rec. We're implementing working drafts and editors' drafts.
... Getting protection while drafts are not rec would be good. Community group has an approach to this, which could be helpful for WGs.
... main value would be getting patent protection but we don't except in CGs.

KS: we wanted to get a list of process problems. Should we keep going as we are?

<jeff> since the q is closed, I suggest to Anne's point (>10years) people should come to the schedule delay breakout

<Zakim> chaals, you wanted to talk about where CR came from and how LC maybe clashes

<dbaron> http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process may be of interest

<rigo> chaals talking about goals: shut the discussion off and move on

CMN: CR came later to the process. It opens a new review phase which breaks the assumption that last call closes off discusision

DS: We have a process for "design, spec, implement, done" but what we are actually doing is more developing continuously and implementing in evolution.
... There is a tension because the process doesn't match the development model we have.

MC: So let's pretend we have a living standard in HTML5. What does that mean?
... what are the issues with a living standard

RW: Disadvantages of living standard was meant to be addressed by last call. In an argumentation, if you have a moving target it is hard to comment...

KS: Would like to pick out problems in current process first.

SH: We need to evolve. When we began, there were de jure organisations. Now there are a lot of ad hoc spec development organisations. Our product dev cycles have changed, and stuff is updated live.
... people are throwing in incremental implementation of stuff. Standards are being developed in a whole new way.
... We need to modernise - community groups fits that pattern, where your IPR commitment gets ratcheted up as you go.
... to give incremental protection matching the implementation. But only from the contributor.

<scribe> ... New groups should start as community groups and then feed things into Rec track.

AvK: If I spec something that someone else started, doesn't that mean there is no protection? Whose contribution is it?

Screw Threads and Ink Blots

JJ: Ink blots reflects what happens. Big problem is that some of our stakeholders need screw-threads - old fashioned stable specs.
... problem is it can take a long time - we need to figure out how to get those things done faster.
... we have to be agile, but there is a concept of a release still.
... Linux kernel moves in versions - an inkblot environment but there are stakeholders there who need a degree of regularity.

MC: They are putting the responsibilityon us. They haveto be part of the stabilisation process.

AvK: Why do we adapt to them, rather than vice versa

JJ: They are all us.

<Josh_Soref> chaals: I was going to slightly contradict anne

<dbaron> chaals: I'll slightly contradict Anne and follow up on Jeff.

<Josh_Soref> ... and slightly support jeff

<Josh_Soref> .. and to a certain extent, we want to make a contract

<Josh_Soref> ... without an open ended ability to change things at will

<Josh_Soref> ... but we want to be able to make the web work

<Josh_Soref> ... we want to reserve the right to fix things

<rigo> chaals: in development the inkblot dev is what we want. We get paid by customers for fixed term stuff. We do not want to make an open ended commitment on changes at will

<Josh_Soref> ... but we don't want to let you add new requirements

<Josh_Soref> ... How do we do business between these two groups

<Josh_Soref> ... our customer's perception of how the web works

<Josh_Soref> ... and how to integrate things into a very slow changing step wise system

<Josh_Soref> ... There's a tension between what customers want

<Josh_Soref> ... and wanting to work across that divide

<Josh_Soref> ... it's difficult to integrate a continuous development process

<Josh_Soref> ... with a stepwise marketplace

<bryan> specs that do not stabilize (are too large, or partially implemented, or never fully supported) are a bane to interoperability and complicate attempts to move to the "next gen" of the feature (there is only one generation). As Jeff said in the plenary, we need clean/small/orthogonal specs.

ABate: Agree with chaals.
... Jeff said majority of people ship with some degree of regularity - cycle speed is different. Nobody ships random nightlies - not all checkins are equal.

<Josh_Soref> [ laughter from a former employee of some other company ]

ABate: Three types of changes happen to specs. We can't tell which is which in advance. There are errata. There are big fixes where the design needs to be changed - that we can look at before we do it. And there are new features.
... Confusion is that people can't tell in a changing document which changes are of which kind.

<Zakim> szilles, you wanted to talk about messurement based stability indicators

SZ: Wanted to talk about stability. A key outcome of discussion about defining stability. Formal labels don't match stability, or what actually happens. Talking about a metric-based key to stability.
... when you are making a ship decision you look at rate of bug insertion.

[chaals thinks that opens too quickly to gaming, in a competitive environment]

scribe: Think we need to find better measures to indicate the stability of something.

PC: We confuse purpose of spec with anne's point about getting pieces to recommendation.

<tpod> Time check: 5 minutes

PC: we want to deliver something developers can use - the large integrated spec view.
... but that makes it hard to finish, because some parts are stable, others are not.
... We really want HTML5 as a monolith, *and* as a broken up set of small specs.
... Give patent protection on the 17 pieces that are done, show some more things coming, and also "here is how it all hangs together".

<dom> (this sounds like the Banach–Tarski paradox http://en.wikipedia.org/wiki/Banach%E2%80%93Tarski_paradox)

PC: Think we need to figure out how to make that hang together.
... A single large document is not the only thing we should progress.

AvK: Similar points. We have had problems with WHATWG standard knowing what changes happen and why. Most changes link to bug report explaining the change.
... Spec has annotation about where it is up to in implementation.

MC: Good stability point, shows who passed tests.

AvK: Not perfect, is good proof of concept.

Tantek: TIME.

MC: How do we continue?

SZ: Proposal from AB is to create a community group specifically on process.
... sounds like a good idea to pursue that.

<Zakim> Josh_Soref, you wanted to note that i need to know when i should give feedback, and roughly a priority order of potentially all specs that might interest me

<Josh_Soref> I need to know when i should give feedback, and roughly a priority order of potentially all specs that might interest me

- DRAFT -

TPAC Breakout: Revisiting How W3C creates standards

02 Nov 2011

Attendees

Contents

Experimental Process

Screw Threads and Ink Blots

Summary of Action Items

Scribe.perl diagnostic output