W3C Specification Editor

The role of the editor is not that of author. They 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.

Specification editors are appointed by the Group Chair.

Role of the editor

The specification editor have all the responsibilities of the author but none of the rights:

  • Must maintain the draft on behalf of the Group, since the intellectual responsibility for the specification should remain with the Group
  • Need to be willing to write into the draft whatever the group decides, even if they personally would prefer something else.

In practice, a specification editor will tend to have some leeway in matters which the Group does not explicitly decide, and it would be a very unusual editor who is not ipso facto an influential voice in Group deliberations. Editors need to practice egoless writing and draftsmanship in much the same way that some programming disciplines encourage egoless programming.

Workmode

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.

Text follows design decisions
This approachs requires (or at least expects) that design decisions will be made before drafting the relevant sections of a spec.

It places more emphasis on design discussions before drafting, and requires more editorial deference to the Group.

Text precedes design decisions
This approach regards design decisions as best made in the form of revision, replacement, or approval of some existing text, and thus requires (or at least expects) that a draft text will be created before design decisions are made.

It places more responsibility and power in the editors’ hands and insists less on editorial deference.

A specification editor may have proposed text for the draft:

  • in a separate space (such as a pull request) and incorporate the text once a Group decision has been made;
  • or, in the specification draft itself and request Group decision to validate it.

Note that once a 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.

This document lives in GitHub, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use GitHub issues.