[rfc-i] RSE role

[Glenn Kowack]

Ted,
   +1.

-Glenn
___

On Jan 19, 2011, at 2:54 PM, Ted Hardie wrote:

> Some comments in-line.
> 
> On Wed, Jan 19, 2011 at 6:28 AM, Russ Housley <housley at vigilsec.com> wrote:
>> Glenn:
>> 
>>> 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
> the mainstream.
> 
> 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.
> 
> best regards,
> 
> Ted Hardie
> 
> 
> 
>> 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.
>> 
>> Russ
>> 
>> _______________________________________________
>> rfc-interest mailing list
>> rfc-interest at rfc-editor.org
>> https://www.rfc-editor.org/mailman/listinfo/rfc-interest
>>