See also: IRC log
<scribe> scribe: Chaals
KS: Marcos wanted to address
specific proposals, I wanted to talk about experimental
... 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.
<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.
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?
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
... 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
... 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
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
... 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
... 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'
... 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
... 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?
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
... 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
... 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
... 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.
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
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) FAILED: i|address specific goals|[ http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards ] Succeeded: s/q_ olivier// Succeeded: i|address specific|[ http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards ] Succeeded: s/At this/At that point, periodic snapshot approach was appropriate/ Succeeded: s/not so/maybe not so/ Succeeded: s/point/now perhaps/ Succeeded: s/taht/that/ WARNING: Bad s/// command: s/itw//its/ Succeeded: s|//|/| Succeeded: s|s/itw/its/|| Succeeded: s/itw/its/ Succeeded: i|experimental process|Topic: Experimental Process Succeeded: s/lets/let's/ Succeeded: s/anna/anne/ Succeeded: s/ot/to/ Found Scribe: Chaals Inferring ScribeNick: chaals Present: Bryan_Sullivan chaals WARNING: Fewer than 3 people found for Present list! Agenda: http://www.w3.org/wiki/TPAC2011/Revisiting_how_W3C_creates_standards Got date from IRC log name: 02 Nov 2011 Guessing minutes URL: http://www.w3.org/2011/11/02-process-minutes.html People with action items:[End of scribe.perl diagnostic output]