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.
The specification editor have all the responsibilities of the author but none of the rights:
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.
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.
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.
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:
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.
Feedback is to @w3c/guidebook and is welcome on GitHub