See also: IRC log
<dsinger> trackbot, please follow this process
<trackbot> Sorry, dsinger, I don't understand 'trackbot, please follow this process'. Please refer to <http://www.w3.org/2005/06/tracker/irc> for help.
<scribe> ScribeNick: fantasai
chaals: Things I wanted to put on
... Transition process -- assuming we adopt this proces,s how do we implement that?
... Issue of getting review, in practice
... Are there other issues?
... various bikeshedding issues
fantasai: I would like to get clarifications on re-entry into LCCR
dsinger: Thinking about onion rings of process
<dsinger> I would like to explore the onion-ring of interests: how well it works for people (a) inside the WG (b) outside the WG but inside the W3C (c) in standards but outside the W3C and (d) rest of world.
paul: Old status section was,
don't hold your implementation over our head
... But people are doing that right now
... Your changes are encouraging early implementation, early testing
... Having that text appear in the status section seems antithetical to that approach
szilles: Would like to do a quick straw poll on bikeshedding, to see wrt bikeshedding ...
mchampion: Why do Chinese people find w3c hard to work in? One was weird jargon
szilles: current suggestion was
to call LCCR "Candidate Recommendation"
... separate issue wrt Recommendation -> Standard
<dsinger> bikeshed: Working Draft (internal, public), Draft Specification, Specification?
chaals: If we change Rec to
Standard, then of course CR would not be great
... Do people think we should change REC to something else
<dsinger> or WD, Draft Standard, Standard
sgalineau: I spend way too much time explaining to people that a Recommendation is a standard
paulc: We use the term "recommendation" everywhere
various people in favor, others are opposed
paulc: Anyone know why they're
REC not Standard?
... W3C wanted to recommend their standards, not to force anyone
chaals: I suggest we note that
there is opposition to changing the name
... Are people of in favor of / opposed to / don't care using CR for LCCR
Ralph: I think it needs a better name than LCCR, but not sure CR is the best
fantasai: The idea was to
collapse LC, CR, and PR
... In the CSSWG we pretty much view LC and PR as transitional phases, that aren't really phases that a specification doesn't actually sit in
... The phases for us as a WG are WD, which is a design phase
... CR, which is a testing phase
... and REC, which is a we're done but we're maintaining it phase
... So the name CR provides the least disruption from the current process names
... It basically makes this change to the process eliminate the transitional phases
mchampion: My only concern is the
link to the patent policy
... I'm personally comfortable if we have a mapping to the patent policy
chaals: I took that issue to
... asked if there's any problem with LCCR, and the initial opinion was "no problem"
... I will be going back and asking them again and make sure they read/thought about it
... But my belief is that this is not a problem
mchampion: First time PSIG was unanimous on anything, so skeptical :)
chaals: straw poll showed a large
number of ppl in favor of the name, a few people couldn't care
less, and no one was opposed
... But ralph suggested another name might be better
... So I suggest we close this item
... Issue raised by several people which is worth considering
... Issue of getting review
paulc: Original process was WD /
LC / PR / REC
... then added CR
... hearing that people want to collapse LC and CR together
... I have a lot of experience with really big drafts
<Ralph> [/me thinks Chaals meant "[the straw poll showed a] large number of ppl in favor of the name "Candidate Rec", a few ..."]
paulc: My concern is that changes
here are optimized for small agile drafts
... and that it's going to do damage to particularly large drafts
... It's often hard to get review until you can say "it's in this stable state"
... That's one of the characteristics of LC
<Zakim> mchampion, you wanted to say the AB got a lot of feedback saying LC is meaningless
mchampion: When AB first started
discussing this got feedback that LC was very confusing,
because Last didn't mean Last
... It was just a way of telling people that this ia a draft they needed to take seriously
... Having some other mechanism for "this is a draft you need to take seriously"
... Let's make that clear
<Zakim> chaals, you wanted to say that getting review of changed pieces when they are being changed is helpful.
chaals: Yes, you have pre-LC
drafts at the moment
... dsinger asked "why not have a name for the thing before CR"
... I have seen pre-pre-LC drafts
... Extra names are confusing
... Working Groups describe where they're at
... It's possible that a standardized name for where you're at is useful
... It's standard practice to just announce that you're almost done
... at the same time, I think it is a goal for bits of specs to be reviewd
... when they're being worked on and changed
... It's an explicit goal, should requirement, that when a spec has a piece of change that would benefit from review
... there should be a WD published
... Idea is to get review when the changes are being made
fantasai: I don't really know how
to translate this into humongous drafts like the HTML
... but in the course of my CSS work, I've identified several phases of WD development
... Because the CSS modules are small enough, our current-work page just groups modules under each of those statuses
... and I've wrote aobut this, whci hI'll link later
... We have 3 phases with thie WD phas
... First one iis "exploring"
<Ralph> fantasai: exploring is 'brainstorming'
<Ralph> ... nothing is stable
fantasai: lots of ideas trown around, nothing really stable at all
<Ralph> fantasai: the second phase is 'revising'
<Ralph> ... we have an idea of the functionality and the scope
<Ralph> ... but it's still quite malleable
<Ralph> ... the third stage is 'refining'
<Ralph> ... the features are all spec'd out
<Ralph> ... but various details of how they work aren't locked down
<Ralph> ... the exploring phase is editor's draft, FPWD, and maybe several subsequent WDs
<Ralph> ... the 'revising' phase lasts for several more WDs
<Ralph> ... refining may take several more WDs but the changes are small
<Ralph> ... we describe these in our WG page
<Ralph> ... may be good to have SoTD lines to describe
<Ralph> ... but SoTD is full of junk
<Ralph> ... for Last Call, we believe all the issues are settled and this really is the last opportunity to ask us to change something
<Ralph> SteveZ: I don't think we should resuse LC as it's always caused confusion
<Ralph> ... 'refining' is way to late to make significant changes
SteveZ: Would love to see us
encourage a culture of review of what's changed when its
... But getting a lot of feedback that there's a class of people that can't work that way
... That it's useful to have a signal that "here's your last chance to look at it"
... Would call that signal "functionally complete" -- can read whole document and probably hang together
... Flag to say we got somewhere, probably the "refining" stage in fantasai's terminology
Ralph: Appears to me the problem
is the word itself: "last"
... The WG believes it's solved the issues to best of its ability and if you don't speak up now we're forging ahead
... But if someone finds major issue, WG will solve that and there will be another chance to comment
... Strict interpretation of "last" is throwing some people off
... Maybe need a different signal for "we really think we're done"
... But difference between providing that signal, and signals along the way
... But WGs are historically not really explaining what parts need review
<Zakim> dsinger, you wanted to offer names for WDs
Ralph: I don't think we can live with that tension of doing neither a "we're done" signal nor clearly saying in a Status what should be reviewed
dsinger: Listening to what you say, thinking , how do we solve this?
<SteveZ> +1 to Ralph's point that we should not do
<dsinger> public working draft: there are at least some sections of this, described in the SOTD, which can (should, even) be reviewed by non-WG members; a good practice is to ask for wider review and get that request in the W3C announcements, liaisons, etc., on a reasonable number of public WDs; particularly, the technical details of what is taken to LCCR should have had explicit public review requested (a 'functionally complete' public WD)
dsinger: WGs have stage where
it's kinda internal, they're not really ready for people to
look at things
... But need a signal to say "this is pretty good to review, come take a look at it"
... When publish, can say "WG expects to take this to LCCR unless issues come up"
<Zakim> mchampion, you wanted to say that another complaint about LC is that is is global to a spec, when a useful "this is stable
fantasai: I think cleaning out the Status section would help with that a lot
mchampion: The LC was at the
granularity of the document, but the actual stability is at at
much finer granularity
... Putting that kind of status flags either in the Status section, or in the text of the document, is how WHATWG does it
... Let's force people to make reasonable status section
chaals: I suggest we do add a name for "the WG thinks it's done and is about to request LCCR", but that we reinforce the suggestion that public WDs are review drafts and should clarify which bits should be reviewed in each given draft
astearns: The Process proposal,
as I recall, requires that the WG demonstrate that they got
... Paul's point that larger drafts have possibly different requirements than more agie drafts makes me think the Process document should stay the way it is, and not say how you get review or call it a particular name
... but have some bars to demonstrate, this is how you demonstrate
... Could take the form of any of the things we've discussed: labelling the draft, having status section listing sections, a WG keeping track of the feeback they get from groups they're concerned about on a section by section basis
... Just some example so fhow you demonstrate that, and leave it up to each WG to have process of their own for collecting that feedback
<Zakim> Ralph, you wanted to ask what's really polluting SoTD
Ralph: I'm having a little
trouble understanding what goes on
... You're not saying WG publishes one section and asks for review?
... Need context of document
... Good to point at changed section to ask for review
... I think that's good practice
... Curious to know, maybe what's polluting the status of the document so much that prevents people from explaining things in it?
... But going back to Chaals suggestion of new name for something that's LC but not quite, then lots of names for lots of steps
<dsinger> example: WD1 has section 4 ready, they get signification comment; WD2 says "section 4 is under major revision, but section 5 is ready now", WD3 says "section 4 is now fixed, and section 6 is ready; section 5 needs to be made consistent with section 4", and so on, until they finally have review on all sections. that would be OK by me
<Ralph> Fantasai: for the purpose of helping people track our documents better
fantasai: I don't think we should complicate the formal W3C Process too much, but for the purpose of having ppl track our documents better, even thoughs that aren't following closely
<Ralph> ... I would suggest for now we leave tools open for WGs to communicate status as they see it
<Ralph> ... and see what communications methods emerge
<Ralph> ... allow the WG to create its own labels for status
<Ralph> ... and to clean up the SoTD
<Ralph> ... some WG may choose to label a WD as "Last Call WD" without it being a formal step in the process
<Ralph> ... I might label something "Exploratory WD"
<Ralph> ... allow us to insert labels up front
<dsinger> I am perfectly happy with the process having WD->LCCR (or new name)->rec (or new name), with merely suggested common names for internal WDs and public WDs; the only thing I think a 'public WD' should be required to have is a status section
<Ralph> ... allow experimentation with such labels
<Ralph> ... see what patterns emerge
<Zakim> chaals, you wanted to respond to alan's suggestion
<Ralph> ... may take 3-4 years
chaals: right now, review stuff
says "just publishing a draft that says 'please review'"
doesn't qualify as getting wide review
... Have to show that you got people responding
... I'm comfortable with WGs saying "this is the bit that needs review now"
... I thin what I'm going to do is try and strengthen how the document encourage this behavior
... Rather than picking a particular name, inclined to go with fantasai's proposal
... With that, I pass to Steve
<Zakim> SteveZ, you wanted to say developing the review community is also necessary
SteveZ: Will expand on what
... Part of what is important in this whole process is developing a reviewer community
... Part of that happens during chartering,
... But also outside of that figure out which groups you need to send mail to about what's goin gon etc.
<dsinger> notes that common names for common concepts really help the people outside the WG, who need to work with multiple WGs
mchampion: e.g. Judy wanted a heads up a few weeks ahead of time that xyz will happen so they can schedule time
SteveZ: Someone should appoint a liaison to coordinate with those groups
<dsinger> we have enough trouble with people outside follow the W3C process; it can't be that they have to follow the CSS process, the HTML process, and so on...!
chaals: Suggest we take up agenda
... Assuming we make a transition, what will it be like?
SteveZ: fantasai sent out the
last word on this
... Maybe start there
1. Any spec in WD or REC is automatically transitioned into the
<scribe> new rules for WD/REC, without any WG action. The next publication
(whatever phase that may be) will thus follow the new process.
2. Any spec in a transitional phase (LC/PR/PER) follows the current
process until it gets to its next stable phase (WD/CR/REC),
and from then on follows the new rules for WD/CR/REC.
3. Any spec in CR has three transitions available:
- move to PR, if it is ready, and complete from there
- republish as CR under the new rules
[this combines the old LC/CR options for handling
- move back to WD, if it needs substantially more work
mchampion: Should there be only
... Can different groups have different processes
fantasai: I think for the clarity of the people in and around W3C, we should not have multiple processes
szilles: small WGs might have trouble switching
dsinger: Tracking protection WG has as its goal to be in LC, will disrupt them
szilles: One choice is WG chooses which process
Ralph: Because of wide spectrum
between Tracking Protection which struggles with one process,
vs other groups
... Don't think one schedule works for everyone, unles broad timeline with lots of options
... Don't recommend different documents under different processes
... but could choose to do that
... confusion within wg vs confusion of public?
... I thikn the confusion we ought to be worried about is confusion ofpublic, not confusion of WG
... Though sensitive to sensitive groups like Tracking protection
paulc: This transition breaks
... Plan 2014 assumes same process for HTMl5 and extension specs
dsinger: Need a transitional phase, can't do a big bang switch
chaals: my suggestion would be
that we enable the process
... Allow WGs to switch to it pretty much at will
... But require them to switch certainly on rechartering
... and after N, e.g. 1-2 years, force you to switch
... I see that it would "break Plan 2014", but don't see what the actual damage would do
... Certainly groups that will cry and scream
... Ralphs point wrt 2 processes
... But if some groups produce LCs and CRs and some groups produce CRs
... The confusing difference is for the patent lawyers
... Who need to know whether they're required to do review. How terrible
SteveZ: I would make point that
dsigner just made, they probably don't know process anyway,
just watch Call for Exclusions
... I think the public probably doesn't understand the maturity steps
... Particularly if we call LCCR CR, in which case they'll hardly notice
... I don't see a need to set a shift on rechartering, as long as you have a time limit
... Let's us deal with other things
... Other thing that Ralph made is, new groups always start under the new plan
... But allowing groups to shift when they can, syaing you got to shift within 2 years, that will get there eventually
... Get there fast and won't gore the ox of ppl getting done
... If DNT isn't done in 2 years, may never be done
paulc: I'm becoming more
convinced that just making LC optional just makes a lot of
problems go away
... If a working group like CSS wants to skip LC because they've had sufficient reviw during WD stage, go directly to CR
... Instead of making CR optional, make CR mandatory and LC optional
fantasai: I think that that makes a lot of sense
paulc: exclusion opportunity
starts no later than LC or CR, whicever you get to first
... Then you get all benefits of both pieces of process
... Do want to recognize point wrt confusion of outside
... I was describing my experience as chair
chaals: We don't optimize for
chairs, we optimize our chairs
... We're closed, thanks everyone
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/they/Chinese people/ Succeeded: s/Large number of/straw poll showed a large number of/ Succeeded: s/i fyou/if you/ Succeeded: s/Trict/Strict/ Succeeded: s/with that tension/with that tension of doing neither a "we're done" signal nor clearly saying in a Status what should be reviewed/ Succeeded: s/eithe rin/either in/ Succeeded: s/rquires/requires/ Succeeded: s/thin/think/ Succeeded: s/chaasls/chaals/ Succeeded: s/++/+1/ Succeeded: s/anywya/anyway/ Found ScribeNick: fantasai Inferring Scribes: fantasai Present: Sylvain DaveC Fantasai DavidSinger SteveZ AlanStearns Ralph Chaals PaulCotton MikeChampion Got date from IRC log name: 13 Nov 2013 Guessing minutes URL: http://www.w3.org/2013/11/13-w3process-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]