[rfc-i] draft-kowack-rfc-editor-model-v2-motivations-00.txt

Glenn Kowack glenn at riveronce.com
Wed Dec 22 20:32:50 PST 2010

On Dec 21, 2010, at 2:53 PM, Ted Hardie wrote:

    in your mail below, you suggest two alternatives, a relatively strong
'Publisher' (your label for my recommendations) vs a "Lead Editor",
(your proposed solution). In brief, your Publisher approach describes
an RSE that is much stronger than, and goes far beyond, my
recommendations.  Further, my experience this year doesn't
show any need for the sort of "Lead Editor" you suggest.

Net, I do not believe your suggested terms are an appropriate basis
for moving toward a consensus.  Rather than either of those, the
model I am recommending, and what 5620 introduced, is an
executive-level manager.

However, if I understand your mail correctly, we agree on a vital point:
the scope of the RSE should include management across the entire
RFC Editor. This is an important alignment, and we may be able to
develop further points of agreement from there.

I address your specific points below.

> In the newspaper world "don't bury the lead" is said to be one of the
> most repeated maxims.  I think this draft buries its lead pretty seriously,
> because it comes for me on page 33, 6 paragraphs before the
> IANA considerations.  There Glenn notes:
> " the RFC Series Editor is actually the head of a publications department"

As we keep seeing, different people interpret terms differently.  I
deliberately avoided leading with specific terms.  There are so many
undecided elements that, for now, I recommend that we focus on
responsibilities, authorities and tasks.  After we've got a better
sense of collective impressions of the elements, we can move to
broader labels.

> in this context:
>  However, the incoming RSE must understand that their job is to
>  lead the community in discovering, defining, prioritizing, and
>  agreeing on changes, improvements and innovations, and then
>  implementing them.  (This, in spite of the confusing terminology
>  of the Editor: the RFC Editor is actually a publisher, the RFC
>  Publisher is actually an archive and access server, and the RFC
>  Series Editor is actually the head of a publications department in
>  which there are four 'editors' not appointed by the Series Editor
>  -- the four stream approvers.)
> For me, this clarifies the model difference which we've discussed in
> several different ways.  Glenn's experience and consultations have
> led him to see the RSE job as that of a managing Publisher working with editors.
> More, it has led him toward a relatively strong Publisher model in which the
> Publisher is not simply responsible for putting out the titles but for
> identifying their markets, establishing their audiences, and leading their
> evolution.  To use a  hyperbolic example, he's looking for someone
> to act as our Henry Luce, with a set  of RFC streams standing in for
> Time, Life, Fortune, and Sports Illustrated.

The term 'publisher' as you define it, already implies more than I
recommend, let alone a 'strong' one.  For example, the RSE will not, per se
identify markets and establish their audiences. Yes, he will help discover
groups who are already reading RFCs and then bring that information back
to the community and the streams for further discussion, and maybe suggest
some improvements to access if useful.  But the RSE as proposed in Version 2
won't have anywhere near the level of control afforded a publisher, and the
Henry Luce metaphor is too strong: Luce created publications, hired and fired
editors, and even created markets that he then went after with a vengeance.
Our working environment as style of business are very, very different, and I do
not recommend Luce's level of autonomy or authority for the RSE.

> I think the model expressed by RFC 5620 is actually for a weak publisher,
> but a strong Executive Editor (also known as Editor-in-Chief).
> Anyone familiar with that role in the newspaper world would not use
> the phrase "merely a
> senior editor", as they are responsible for ensuring that each individual
> section--metro news, foreign desks, style, finance, editorial--contributes
> to a coherent whole.  They  make sure that the paper itself has an identifiable
> voice and place in the world.
> To follow my first hyperbolic example,
> I think the strong Executive Editor leads us to look for our own
> Benjamin Bradlee: someone
> who will make sure the RFC Series as whole "says something" whatever comes.

The Ben Bradlee metaphor also goes beyond any of my recommendations.
This moves the RSE dangerously close to managing content, which should 
remain out of scope.  Also, "Executive Editor" sounds like the work is  primarily
day-to-day production-oriented.  This is actually a minor part of what the RSE
does, and is largely comprised of managing exception  cases.  The RSE is far
more involved in guiding editorial policy, and development of the overall series,
per my recommendations and your example, above.

> The line between an Executive Editor and a managing Publisher is pretty fluid,
> and there are no doubt cases in which each one of the individual duties
> we've specified has been done by someone holding either title.  But
> the orientation of the roles is different, and I think we need to be
> very clear here which one we're really looking for, especially because
> the content of the streams and the identities of the stream approvers
> (the sub-editors, if you will) will never be determined by the RSE.

I think this pair of choices is the wrong starting point.  Your proposed choice 
may correctly represent how the historical choices were viewed, but I can't
square  them with my observations during this year as RSE. So, in sum,
both of your alternatives give the RSE authority that he should not have,
and neither represents my recommendations.

> My own take is that we need to hire an Executive Editor, rather than
> a managing Publisher.

> This is partly because any Publisher hired would not
> be able to start new streams or change the audience reached
> by changing content.

Again, the power to start new streams, or change content, are outside
of my recommendations.

> This eliminates a great deal of the pre-editorial
> work done by a Publisher.  While marketing and distribution could
> be changed, these changes are strongly constrained by the needs
> of the individual streams.  Changes are also strongly constrained by the
> need to keep the series a single, coherent whole, despite the current
> division of responsibilities.
> More importantly, I feel that the Executive Editor side of the line fits
> with what has worked in our history much more.  Jon and Joyce were
> editors who worked both at copy editing and at maintaining the
> series as a single conversation.   They were authors, line editors, and
> executive editors.  They covered the ground from style guide to
> ensuring that the loyal opposition had an outlet for its views.  Even
> with the splitting out  of the ISE as a separate role, retaining as much as
> possible of that model strikes me as important.  The working editors have
> developed, over time, a serious amount of throw-weight within our system.

Can you say more about "throw weight"?  If it goes beyond edits for clarity and
formal correctness - that don't touch specific content - it's already gone too far.

> I think that's in part because they took both a document-level view and
> a global view.
> That gives a kind of insight that the closer-to-pure management role of
> managing Publisher does not have.  I think that will be valued by our community
> and that it can work again. To me, that means hiring on the Editorial side of
> that fluid line.

5620 and my recommendations don't preclude the RSE from occasionally
editing a document to be sure he is aware of processes, issues, quality
requirements, and so on.  However, there is nothing in either than has them
doing any regular document production (editing). I believe this is exactly the
right fit and don't think it's useful to expand that to return to the historical
production roles of past Editors (Joyce, Josn, etc). Time has simply moved
on, and 2010 experience demonstrates that the current division of labor
between the RSE and RPC works well.

Which brings me to the "closer-to-pure management role" you mention
above.  I think that'ss a pretty fair characterization of my recommendations,
minus a day-to-day direct production role by the RSE.

> If others agree that this is the critical model difference, we can have
> the conversation around  this question in a couple of different ways.
> One is by pushing and pulling at the desirable aspects of the two
> different slants, then seeing if we come to consensus.  The other is
> by using a completely invented term for the role (the IESG once used "fleen",
> and I've used "glick" and "fnork" before), laying out what we want done
> with no reference to the two loaded terms.  Once we have consensus
> on what we want done, we have a go at picking at term either in-house
> or with the help of a search firm.  Based on the conversations I had
> with Dave, I don't think we're that far off consensus on what we want
> done.  My fear is really that we will end up squarely astraddle that
> Editor/Publisher line when we end, and so we will need to go through
> the first exercise in any case.

Using distinguishing labels is certainly a reasonable approach, but only
after we've discussed the 'parts' extensively. And the publisher-editor
distinction you present does not yet appear to be the right starting point.

> In either case, we need to make sure that the final terminology matches
> reality.  If we're hiring a managing Publisher at the end of the day,
> we need to say
> so.  We'll get closer matches in our job search with that clarity, on whichever
> side of the line we fall.

Once again, my reading of all your points above, is that you think the
authority of the RSE should be across the entire RFC Editor, including
oversight of the RPC.  This is an important point of agreement and one
that I hope we can build upon.


> regards,
> Ted Hardie

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20101222/64b0d09f/attachment-0001.htm>

More information about the rfc-interest mailing list