-> previous 02-Dec

12-Dec Editors' Draft

-> New chapter 7 draft [Chaals 12-Dec]

Fantasai: I note that this organization talks about Working Draft before we know what a Recommendation is

SteveZ: I would like a one-paragraph overview of the Process in the front

Mike: that's where we'd summarize the steps to Recommendation

Fantasai: it's important to know what it is and why it's important before the details
... the goal of the Process is to encourage ...
... important to have this up front

SteveZ: I'd like a call out to the definitions up front
... in CSS we tended to put definitions up front

Fantasai: we did a variety of things; if a concept is global to the entire document, we put it up front

<fantasai> if local, we kept it local

SteveZ: so we need an introduction that talks about what a Recommendation is and what a Note is

Mike: good summary

Fantasai: I think "Classes of Changes to a Recommendation" should be merged with "Substantive Change"

SteveZ: there's history, though I'm not going to disagree
... Chaals tried to do this merge but Ian objected
... Changes to a Recommendation were for revising Recommendations
... Substantive Change had to do with the Patent Policy; it opens a patent exclusion period

Fantasai: we don't have to fold down the classes, just @@

SteveZ: Ian didn't want such a distinction recorded at the Process level
... recognizing that "bugs are in the eye of the beholder"; one person's "bug" is another person's "substantive change"
... I can ping Ian again and find out what he could live with

ACTION: SteveZ ping Ian on "substantive change change" [recorded in http://www.w3.org/2013/12/16-w3process-minutes.html#action01]

<trackbot> Created ACTION-25 - Ping ian on "substantive change change" [on Steve Zilles - due 2013-12-23].

Fantasai: the section "Ending work on a Technical Report" disappeared
... it was nice to see that there were two options; Rescind and Note
... though it's implied in 7.7 and 7.8
... I think it was better to have it be explicit

SteveZ: there's another discussion on how to end the Process short of Recommendation
... e.g. if the Working Group has ceased to exist, what notice should the Team attach to a Working Draft?

Ralph: I am uncomfortable leaving a WD or CR with a comment that says "The Working Group is no longer working on this"

Fantasai: it would make a difference if the WG stopped working on a spec because it thought it was a bad idea, or something else
... it would be good for the WG to state its reasons for stopping work

SteveZ: republishing as a Note could happen with such a statement
... if there was a concerted effort in moving it back to the Rec-track, that could be done

Fantasai: seems this could be part of the summary of the Process
... e.g. if the WG gives up because it ran out of time, publish a Note saying that
... or if it decides something is a bad idea, publish the Note saying it's a bad idea
... or if it ran out of funding

SteveZ: yea, documenting ..
... Chaals said it was important to indicate the expected next step at the beginning of each document
... so that people who pick up a W3C spec are told whether it is "real" or not
... I think moving something off of /TR would be important in that context
... we shouldn't assume everyone is as tuned-in as [the Working Group]
... so we should ask Chaals to add back a section such as Fantasai requested

Issue-39

<trackbot> issue-39 -- Managing the transition to a new TR cycle -- open

<trackbot> http://www.w3.org/community/w3process/track/issues/39

-> 02-Dec draft

Ralph: [summarizes the notes in the email]

Mike: I didn't detect a lot of enthusiasm for these changes during the AC meeting
... with my Microsoft hat I'm reluctant to force WGs to change

Ralph: this was addressed by removing MUST deadlines

Fantasai: so the deadline is now a "should"
... 24 months
... and there has to be justification for exceptions

Mike: that makes sense
... Last Call is helpful in managing some WGs
... making little steps to satisfy requirements one at a time
... sometimes a tangible push is needed to get to a Process state
... the other question on signalling need for wide review

<fantasai> http://lists.w3.org/Archives/Public/public-w3process/2013Dec/0012.html

Mike: some groups, e.g. Accessibility, have broad scope and tend to schedule review time at major steps
... ideally the horizontal reviewers would be more engaged in the group's progress
... in the special case of broad Working Groups where it's difficult for horizontal reviewers to know when to jump in, having an optional Last Call step where the chairs say "this really is your last opportunity and you'll get a fair hearing if you respond by the deadline" is an important tool to chairs
... we can accommodate this but it does create resistance
... until we have a clear story on how to create the moral equivalent of Last Call

Fantasai: Last Call is usually much later in the process than you really want feedback
... e.g. in the design phase the WG will take comments on just about anything
... once the design is solid it's a great time for people to comment on the design
... the WG's next step is to fill in the details of the design
... eventually the WG should say "we're done with all the details" and then it's too late to hear comments on the overall design
... ideally we want reviewers to have completed detailed review well before "Last Call"
... Last Call should not last long and should not be generating lots of comments
... a group who says "we want you to send in your comments now" at Last Call will find itself doing several "Last Calls"
... they're using a Process Hammer at the wrong time
... better to communicate the need for wide review and the type of review you're looking for section-by-section or phase-by-phase
... so by the time you're ready to transition to CR you have most of the comments
... the problem with the way Last Call has been used is that people interpret it as "now I can send my feedback"

Mike: the new proposal is optimized to modern style of WGs; the significant stakeholders are represented in the WG
... the problem is that, e.g., Accessibility review needs some stronger signal
... when there's not a high-bandwidth conversation between the stakeholders you need a bigger hammer
... when we talked with Tantek about this a while back we noted the problem that the Process doesn't accommodate section-by-section review

SteveZ: two issues: I heard consensus on "SHOULD adopt the new process within 24 months"
... the second question on how to accommodate groups who need more time for wide review; in such cases the groups' charters could have additional language
... there are different audiences who need different signals at different times
... so we want to experiment with allowing WGs to find ways to get wide review
... I understand why some WG chairs might want to keep the bigger hammer
... a group can set up additional criteria

Mike: I like that a WG charter could state "we intend to do a Last Call"

next meeting

SteveZ: no meeting on 23 or 30 Dec
... can we meet 6 Jan?

Ralph: ok

Fantasai: ok

Mike: ok

SteveZ: perhaps Fantasai could draft some text on 'signalling'?

Fantasai: OK

SteveZ: Art said that the only critical change was dropping PR and all the other things could be done under the current Process
... some groups would like to use this new Process and help debug it and that would meet Art's criteria

Mike: interesting that the chairs of two of our largest groups are unenthusiastic about how it applies to their Groups

<chaals> trackbot, start conference

<trackbot> Meeting: Revising W3C Process Community Group Teleconference

<trackbot> Date: 16 December 2013