- From: Stephen Zilles <szilles@adobe.com>
- Date: Fri, 12 Sep 2014 22:43:49 +0000
- To: "David (Standards) Singer" <singer@apple.com>
- CC: Chris Wilson <cwilso@google.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, public-w3process <public-w3process@w3.org>
David, Comment inline Steve Z > -----Original Message----- > From: David (Standards) Singer [mailto:singer@apple.com] > Sent: Friday, September 12, 2014 7:49 AM > To: Stephen Zilles > Cc: Chris Wilson; Daniel Glazman; public-w3process > Subject: Re: w3process-ISSUE-126 (autoWDpublish): Automatic WD publishing > tool may change the W3C center of gravity around WGs [Process Document] > > > On Sep 12, 2014, at 2:51 , Stephen Zilles <szilles@adobe.com> wrote: > > > Note that feel strongly that there is a responsibility that an Editor takes on, > and as a spec goes to Last Call and beyond the consensus from the group > should be stronger and stronger; but roadblocks we put in the way of > improving the timeliness of /TR/ are not helpful. > > >> [SZ] This was exactly the point some of the CSS Editors were making. There > was a concern, however, that this means that it is difficult for a reader of TRs to > tell whether a given version of the TR is an updated Editor's Draft or an > approved WG Draft. One suggestion, which may require a Process Change, was > to have two levels of TR: WDs which would be approved by the WG as they are > now and (for lack of a better name) Provisional WDs which would be more > frequently updated by the Editor without requiring a formal WG action. (It was > noted that we should be able to expect that Editors would be responsible and > only make updates that would be unlikely to upset the WG without prior WG > action.) It was suggested that these two kinds of TR would have different > styling and status information, that Changes since last document would only > apply to WDs, and that there would be two last version pointers in the header, > one to the last Provisional WD and one to the last WD. This approach should > work for both the audience (e.g. implementers) that needs up-to-date > information and the audience that only want to review significant changes. The > former uses both WDs and provisional WDs and the latter would just use WDs. > This seems to be an approach that satisfies both the concerns of Editors and > the concern that Danial Glazman raised. > >> > > > I think we only need two classes of document here: editor's drafts (which > represent the editors' best efforts) and WG working drafts (which represent the > WG's consensus on where they are). > > If a WG wants to do a cursory periodic look and approve pushes to WD, or even > at certain (e.g. early) stages in the process allow an editor to push > unsupervised, that's up to them. [SZ] I used to think the same as you. The Editors, however, think differently. They (and I too, now) want the documents that Search Engines find to be the most up-to-date documents that make sense. These are often editors drafts and it does not always make sense to go thru the process of obtaining WG approval to post them on TR, even if you visualize a 24 hour CfC ballot to achieve approval. At various times, the edits come on a daily basis, but these are most often implementing a changes that have been approved, in principle, if not in detail, by the WG. With good editors, these changes are likely to get either approval or comments almost immediately. It was having the TR pages have documents that are most correct that caused me to suggest two kinds of TR document. > > > David Singer > Manager, Software Standards, Apple Inc.
Received on Friday, 12 September 2014 22:44:22 UTC