W3 Process revision - TPAC -- 13 Nov 2013

<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.

<Ralph> Recommendation Track Process, "Last Call" draft proposal

<scribe> ScribeNick: fantasai

chaals: Things I wanted to put on the agenda
... 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 PSIG
... 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

Getting wide 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 spec
... 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

http://fantasai.inkedblade.net/weblog/2011/inside-csswg/process

<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 matters
... 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)

<SteveZ> Neither

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 wider review
... 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 chaals said
... 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 item 5
... Assuming we make a transition, what will it be like?

Transition (ISSUE-39)

SteveZ: fantasai sent out the last word on this
... Maybe start there

http://lists.w3.org/Archives/Public/public-w3process/2013Oct/0104.html

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

substantive/editorial edits]

- move back to WD, if it needs substantially more work

mchampion: Should there be only one process?
... 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

various+1

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
... 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
... fine
... 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

<Ralph> fantasai++

- DRAFT -

W3 Process revision - TPAC

13 Nov 2013

Attendees

Contents

Getting wide review

Transition (ISSUE-39)

Summary of Action Items

Scribe.perl diagnostic output