Re: Call for editors

> [1] http://lists.w3.org/Archives/Member/chairs/1999JanMar/0056

This archived message is member-only, but need not be so.  The text
follows (with permission from the author).

    -- sandro

================================================================

Subject: what does an editor do?
From: C M Sperberg-McQueen <cmsmcq@acm.org>
Date: Fri, 19 Mar 1999 18:50:06 -0600
Message-Id: <199903200050.SAA160078@tigger.cc.uic.edu>
To: chairs@w3.org
CC: cmsmcq@acm.org 

A prospective editor in the XML Schema WG recently asked me, as
co-chair of the WG, what the responsibilities and role of the editor
are.  I replied, and Dan Connolly suggested that the question and my
reply might be of interest to this forum, since we all have to face,
sooner or later, the task of communicating to editors and prospective
editors what we want and expect from them.

I've taken the opportunity to edit the question and my response
slightly.

-Michael Sperberg-McQueen

--------
Q. Am I correct that the role of the editor is not that of author, but
merely the person(s) who maintain the text of a current draft that the
group has agreed to and possibly to suggest concrete wording when none
is forthcoming from the group?

A.  Perceptions of the editor's role vary, and I suspect practice
varies a lot, too.  So there's no hard and fast answer.

For what it's worth, my own expectation (and experience) is that the
editor should expect to have all the responsibilities of the author
but none of the rights.  That is, the editors should definitely expect
to draft the specification without relying on wording from others in
the WG, but not to have the kind of intellectual ownership that comes
from being the ones who determine what should and should not be in the
spec.  The intellectual responsibility for the spec should remain with
the WG, and the editors need to be willing to write into the spec
whatever the WG decides, even if they personally would prefer
something else.  Ideally, editors need to practice egoless writing and
draftsmanship in much the same way that some programming disciplines
encourage egoless programming.  Of course, in practice the editors
will tend to have some leeway in matters which the WG does not
explicitly decide, and it would be a very unusual editor who is not
ipso facto an influential voice in WG deliberations, so I have known
some good editors who were not noticeably egoless.

There are at least two ways to deal with the initial creation of a
working draft for a spec or other document, which may be worth
distinguishing.  One requires (or at least expects) that design
decisions will be made *before* drafting the relevant sections of a
spec; the other regards design decisions as best made in the form of
revision, replacement, or approval of some existing spec, and thus
requires (or at least expects) that a draft text will be created
*before* design decisions are made.  The one approach places more
emphasis on design discussions *before* drafting, and requires more
editorial deference to the WG.  The other places more responsibility
and power in the editors' hands and insists less on editorial
deference.

During the development of XML, for example, Tim Bray and I declined to
write sections of the draft dealing with topics on which the WG had
not yet made decisions.  (Well, actually we did draft them, but we did
not publish them to the WG or the public until the WG had made
decisions and we had adjusted the text to agree with the decisions.)

If I have understood Dan Connolly correctly in our various discussions
on the subject, I think Dan's instinct in such cases is for the
editors to draft something, and publish it, so as to have a complete
spec, and for the WG to decide, at the appropriate point, whether they
like it or not.  To borrow another programming analogy, Tim and I
worked on a basis like Dijkstra's stepwise refinement, leaving whole
sections of the spec empty until they got worked out in full, and Dan
prefers development by successive approximation, in which each
iteration of the draft is complete, and successive iterations come
progressively closer to meeting all the requirements.  (Good example
of this last approach is the extended example in chapter 8 of
Kernighan and Pike's book on The Unix Programming Environment.)

Note that once a working draft is complete, the two approaches tend to
converge, though views may differ over whether it's essential, or only
desirable, to provide specific replacement wording for any proposed
change to a draft, before the proposed change is discussed.

I hope this helps.

Michael

================================================================

Received on Tuesday, 29 November 2005 16:37:38 UTC