Re: RFC Series Editor (RSE) Statement of Work

[John C Klensin <[e-mail]>]

--On Tuesday, July 16, 2019 16:53 +1200 Nevil Brownlee
<[e-mail]> wrote:

> +1 about Heather not having RFC writing experience before
> taking on the RSE position.
> 
> Actually, the former RSOC's search committee (yes, I was on
> it), made sure applicants had lots of experience of publishing
> technical material, as well as considerable experience with
> networking and computer technology.  We narrowed down the
> field to three likely applicants, and brought them all to the
> Beijing IETF meeting so that they could see for themselves how
> the IETF worked.

Hi.

I don't know whether to respond on this thread or the "RSE Bid
Process" one - this may be a bit of both.   

First, I want to confirm what Nevil says above (I am fairly sure
I was on that committee too; I was certainly on the RSOC). 

Unless "we" are trying to make changes in how the RFC Editor
Function works that go far beyond what is (or is not) in what is
in the draft SOW, there have been several misconceptions in this
thread and the related ones.    First and foremost, let me
reinforce something several others have said: This is not a
copy-editing role.  it is not even a technical editing role.
I'd be concerned about a candidate who did not have technical
editing experience but I'm not sure that is a showstopper (i.e.,
"required").  I'd like to hear from Heather and Ole (and anyone
else with in-depth experience and not just opinions) about that.
I'd be much less concerned if a candidate did not have
copy-editing experience, but I believe all of the good technical
editors I've known and worked with have had that experience.  If
that generalizes, copy-editing experience is a non-issue if we
more or less insist on technical editing experience.   Someone
who sees the RSE job as editing documents would be an
inappropriate choice for it.

As far as experience writing RFCs is concerned, maybe it would
be helpful, but  the perspective gaining from experience running
and splicing fiber optic cable in production environments might
be helpful in designing network-level protocols.. .but not very
much.   It is essential that someone selected for the role be
(or be able to rapidly become) comfortable working with the
community, but we should remember --as some recent threads have
illustrated -- that the culture is changing rapidly.  I'm not
entirely sure that Jon Postel would have been comfortable
working in today's culture.for themselve
   
Instead, this is a strategic leadership and management role.  In
retrospect, maybe we would have less confusion about, e.g., copy
editing, if we had called the position "RFC Series Publisher"
when we made up the "RSE" title, but, given how few people seem
to understand what a publisher actually does, maybe it would
have made no difference.  However, the old adage about really
smart managers and executives choosing staff and looking for
colleagues who know more than they do would apply here: nothing
in the job description the IAB has proposed for themselves for
the nomcom says "understands issues in technical publishing well
enough to do a senior-level job in that area".  I'm not even
sure that is a requirement for the RSOC (and don't know how many
current RSOC members would qualify if it were)..

If the RSOC and IAB are looking for someone who will quietly do
the job, follow their lead about strategy directions, and not
try to educate (and, if necessary, push back based on greater
specialist expertise, then they are making a really fundamental
change in the role.    If 6635 appears to say anything about
that sort of focus of authority and restrictions on the role,
rather than the strategic leadership one, then it is broken and
needs to be fixed rather than slavishly followed... but I don't
believe there is any language in it to that effect.

So, as Nevil pointed out, what we looked for was lots of
experience of publishing technical material, as well as
considerable experience with
networking and computer technology.  I think that is still what
we need to look for, noting the priority of the "publishing
technical material" criterion.  I would have added "experience
in preparing technical standards for publication" as at least
highly desirable.  My recollection is that we considered that
too and considered it quite a bit.

Something Nevil didn't mention was that plausible candidates
were not easy to find, even with no incumbent to compete
against.  We did considerable beating of the proverbial bushes,
reaching out via personal contacts at publishers of relevant
technical journals, at professional societies who publish
journals of record, present and former editorial staff for other
standards bodies, and so on rather than confining ourselves to
anything that would correspond to the IETF LLC (or IAOC) issuing
an RFP, announcing it to the community, and seeing who shows up
to "bid".  For a position like this, even describing the
position search a and process as a "bid" is offensive and likely
to convince some people we would like to have as candidates to
say "they either don't understand what they are doing or are not
interested in anyone like me" and then move on.   This is not
like, e.g., getting someone to build a software package to a
complete set of specifications.  It is lots more like recruiting
someone to design a system and then oversee its implementation.
Unless we are making significant changes to the role, the RSE
should probably be seen as less even responsible to the IAB and
RSOC on day to day details than the IETF LLC Executive Director
is to the LLC Board.

Finally, for those who think an "acting" or "interim"
appointment while we reconsider the position is the right thing
to do... maybe you are right.  We have gotten ourselves into
such a horrible position that I have trouble thinking about
optimal solutions.  However, please be very careful about
analogies and assumptions about how Olaf's term as Acting RSE
worked out.  Olaf obviously had a great deal of IETF experience,
both as a recognized leader in the community and as an RFC
author.  That made it easier for him to function in a
placeholder role without alienating the community, which was
undoubtedly important.  However, he did not (at least as far as
I recall) have the depth of technical and standards publishing,
and publishing strategy, experience discussed above and that
others have been trying to get at.   I think it was very
important (his comments would be welcome) that he did have an
RSOC that contained multiple people with at least significant
pieces of those types of experience.   That RSOC saw its mission
much more in terms of supporting him and helping him succeed in
the role -- including giving advise on the strategic publication
issues to which he was happy to listen-- than as "oversight" or
supervision or evaluation of contractual compliance.    That
seems to have changed and, unless we can get back there, an
Acting RSE with only IETF experience might be at a significant
disadvantage relative to keeping the Series going in a stable
and efficient way.

Mote generally, putting someone into the RSE role --either
"acting" or semi-permanently -- who has good community
experience and relationships, little or no strategic publication
leadership perspective and experience, and without the support
of in-depth expertise in the RSOC (or some other arrangement to
which a supportive RSOC is prepared to defer in matters of
expertise) is a recipe for disaster... or at least major changes
in the character of the Series whether intentional or not and
whether reflecting community consensus or not.

Finally, we have to keep in mind that whomever takes the
position next is, at least IMO, going to be facing a much more
difficult situation than Heather did when she came on Board.
First, the community appears to be much more divided about the
role of the RSE and the Series more generally.  For example,
there were no loud voices for radical changes around such as
those that manifested themselves in the RFC++ effort a year ago.
In particular, whether it is the case or not, recent discussion
on the IETF list has made it clear that there are are suspicions
in part of community that at least parts of the present
situation are the result of efforts to accomplish goals that
could not be accomplished by community consensus.  Again
independent of the validity of that concern, its existence has a
corrosive effect that will make the role of the appointee harder
and that may make recruiting of highly-qualified candidates
harder.  In addition, we are in the midst of a very significant
change to how RFCs are published and made available -- probably
the most significant change since sometimes in the 1980s.  Some
recent events have convinced me that, as we discover where what
we wanted leads, we are likely to have to debug and reconsider
parts of the design as well as the particular tools that
implement it.  Unless we change the job so that some appointed
volunteer body [micro]manages the decisions that will be needed,
the new RSE, acting or not and with Heather's help or not, is
going to be the critical decision-maker about what will
certainly turn to be complex tradeoffs.  

That, too, is likely to be a recruiting issue because it is
likely that anyone who is really qualified for the job is going
to ask many focused questions about what they would be getting
into.   If someone who asks and gets accurate answers says to
themselves "especially in the light of a divided community, do I
really want that stress and risk of failure because of decisions
made before I came on board and things I won't be able to
control?" that is one less possible qualified candidate for the
RSOC to consider.

It is more than a little scary.  If I has a plan about an easy
path to navigate the situation and do so easily, I'd say do, but
I don't.  However, I do believe that it is unlikely that we are
going to make significant progress as long as some members of
the community are behaving in a way that --justly or not-- cause
others to be concerned about whether information is being hidden
from the community or that there os a hidden agenda about using
the change of RSE to radically change the RFC Editor Function.

best,
   john