[rfc-i] RSE role
ted.ietf at gmail.com
Wed Jan 19 11:54:55 PST 2011
Some comments in-line.
On Wed, Jan 19, 2011 at 6:28 AM, Russ Housley <housley at vigilsec.com> wrote:
>> there are many, many aspects of RFC Editor and RSE work that depend upon expertise in editorial and publications techniques
> You keep saying this, and I remain unconvinced.
> I have said this to you in less public places, and I am now repeating it in this very public place. From my perspective, the most important role of the RSE is cross-stream coordination and policy. The policy portion involves leading discussions with the whole community, and this can best be done by a respected member of the community.
So, I think the key point here is that cross-stream coordination role
that the RSE has is specific to editorial and publications points,
since content has been explicitly ruled out. Leading discussions on
those points actually requires pretty significant expertise with them,
or the policy that's returned may be unimplementable and/or way out of
Ideal from at least my perspective is someone who has both that
experience and IETF experience, but that's a pretty limited set and
the number of hours/pay may well make it the null set. So we're left
with the question: is it easier to grow a member of the community in
this domain, or easier to get someone with this domain knowledge to
build a reputation inside the community? As long as we're clear that
we want the intersection at the end of the day, I think we can reach
this point, but it will take time either way.
My personal take is that absent the ideal case, it will be better to
hire someone with publication experience and grow their knowledge of
the community they will serve. The risk in the other direction is
that we will have a respected member of the community who becomes
increasingly familiar with the way we already do publication, with
little to know exposure to how others do it. That might limit our
ability to evolve the series to meet new needs.
To take a small example: I've suggested in the past that we provide
translations of the boilerplate in the RFCs to eliminate a hurdle to
providing translated specs (something we permit and might choose to
encourage). Having limited outside experience in this, I have no clue
whether this is common or perceived as a good idea by other technical
publications. There are some obvious policy issues (does the legal
boilerplate need review by international lawyers as well as
translators?), but there are also some production issues: if we
provide it in plain text files is that enough? Do we need to provide
templates or tools for this to be useful? What are the costs to
maintain these as we update our boilerplate etc? (If the answer is we
need to provide CSS and HTML snippets because everyone else uses that,
we have one cost; if everyone who wants to provide this uses a
different tool, the cost will be higher).
I don't want to rathole on the proposal, but to highlight that there
are elements even in that relatively simple piece where
editing/publishing experience in a reasonably comparable series would
be useful. Harald used to say "A pair of data beats a full house of
supposition", and I think experience does the same--and the relevant
experience hear covers both the policy question and the actual
production. The editor/publisher experience is a demonstration that
they know how policy matches to implementation, and implementation
remains a pretty important point to all our work.
> To me, expertise and experience with editing an publications is _much_ less important. So much less that it does not even make the radar screen in comparison.
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest