[rfc-i] RSE models
ted.ietf at gmail.com
Mon Nov 29 11:20:31 PST 2010
My apologies for the delay in replying; some discussion below.
On Sat, Nov 27, 2010 at 11:31 PM, Dave CROCKER <dhc2 at dcrocker.net> wrote:
> On 11/27/2010 11:09 PM, Ted Hardie wrote:
>> My advice to the IAB is to treat this job as*at minimum* 80% about
>> the documents, and to treat all the other work not driven by the needs
>> of the documents as overhead work.
> Can you elaborate, in practical terms, what the last sentence translates
> What do you specifically "about the documents" to refer to?
> What do you consider "overhead" to cover in terms of actual activity.
> Each person's list for these can be quite different. What are your?
I agree with you that each person's list for these can be quite different,
and I suspect no rigid classification would work for everyone. My
own thinking on this was partly a reaction to this text in 4.2, listing
the responsibilities of the RSE:
o overall, ongoing operation of the RFC Editor,
o refinement and development of RFC Editor processes and services,
o maintenance of quality and advancement of the Series,
o representation of the Series to the community, and
o representation of the Series to the rest of the world.
Reading that, I was struck by how much of this was focused on
management, process, and outreach. The first is operations-focused,
the second process-focused, the fourth and fifth are outreach. But
to me, the meat of the job is in "maintenance of quality and advancement
of the Series", which I assume from other discussions means
"quality" outside the content.
To me, that task includes things like developing and
maintaining the style manual, trying to make sure that the meta-data used for
archiving and publication work for the communities of interest,
like whether assigning SICIs to RFCs with the ISSNs assigned to the RFC series
make sense, surveying the available alternative formats which might
be supported for accessibility (or portability), identifying places
translation might assist the consistency and speed the availability of
RFCs. I would also believe that working with stream approvers and the
publication center when there are difficult documents or clusters
would fall under
this rubric, but I can see others as seeing that under the "processes" tab.
I also personally see filling in the ratholes around internationalizing
contributor names or allowing complex figures in RFCs as being
"about the documents", but I also understand that those involve long community
processes of both education and consensus-building. That might fall into
"represent the Series to the community", I suppose, thought it is hard for
me personally to read the current document that way.
On the "overhead" side, I would put both the team-building points in 4.2.4
and the outreach in 4.2.5; they may be useful or valuable, but the primary
goal of the job isn't there. I'm also a bit concerned by the internal process
improvement discussion in "Internal process and service development",
because of the way things are currently split. If a suggested process
improvement by the RSE touches on the work of the Publication Center,
the contract actually governs whether it must be accepted or is simply
input (either to the current incumbent or to the next RFP).
Again, I doubt this specific list matches perfectly anyone elses, and I'm
not overly happy with the formulation that gave rise to it. But I hope
this additional explanation at least elucidates a bit what I was thinking.
> Dave Crocker
> Brandenburg InternetWorking
More information about the rfc-interest