Re: w3process-ISSUE-126 (autoWDpublish): Automatic WD publishing tool may change the W3C center of gravity around WGs [Process Document]

On 13/09/2014 03:28, Sam Ruby wrote:

> +1
> I do think it is worth exploring the notion that Marcos is describing of
> eliminating the concept (or at least the primacy) of the notion of an
> "editor".
> Effectively, any fork (on github or elsewhere) is a branch, and can be
> produced by literally anybody, either as an individual or in groups.
> There should be a way to easily produce documents for such feature
> branches.
> It is also worth mentioning that github makes it very easy to revert a
> commit so if a change that is pulled in to the WG's WD later turns out
> to be controversial, it can be quickly removed - perhaps permanently or
> until the discussions are complete.

I think this discussion now goes far beyond the original issue and I
suggest a different thread for GH.

Chris Wilson said:

> There is no such "permanent right", as the WG (or the chair, or the team contact) could quickly remove an editor's assignment to that role (and their authorization to make such edits).
> Sure, it is possible in this arrangement for an editor to publish changes that are not approved by the WG.  I would expect that editors to manage this appropriately; however, continuing with the system we have today has simply moved the bulk of specs I deal with to a system where the editor's draft is the place to go, because publishing /TR/ docs is needless paperwork.  (aka "Do I really care enough if my spec lives in /TR/ to jump through the same set of hoops regularly?")

During the discussions with Tab during the CSS ftf, I mentioned the
fact that everything non-editorial that goes from a ED to a WD
should get a resolution/consensus from the WG, including made
outside of confcalls. This is already a major bonus compared to
the current situation, reducing the publishing delay from 2 weeks
to 1 or 2 days. We introduced email-based CfCs also for that.
My concern is that Tab _seems_ to think this is still too much and I
disagree with that because allowing faster process and increased
authority on WD from the editors would mean our WDs are now really

I understand perfectly all the answers I got saying "we count on
editors" and "WGs can still cancel an editor's right to publish" but
I don't find them very satisfactory. I am a too old monkey here to
forget that any abusable system WILL be abused, it's not a matter of
if but only a matter of when, including in our very reasonable and
trustable world of geeks.

Just for the record, I raised this issue as an AC-Rep, not as a

Steve Zilles said:

>  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

Yes, that was a proposal. And I really don't like it. It took
us years to get rid of one single REC-track step in the new
Process and that suggestion now adds a new one. Tell me about

Mike Champion said:

> I think Chairs have the tools they need to handle this situation

I don't think they do, sorry. Oh sure the WG can cancel an editor's
role but honestly, I do not think this is going to happen with key
editors and contributors. It's possible but it's practically not
feasible. "A posteriori" control of what goes into a WD is also a
very special of standardizing a spec I think...

Dave Singer:

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

That is in line with the compromise I suggested above and during
the CSS WG ftf: editors can move to WD everything non-editorial
that has resolution or consensus of any kind from WG, and are
free to commit editorial changes whenever they want.


Received on Saturday, 13 September 2014 07:45:02 UTC