[rfc-i] RSE models
dhc at dcrocker.net
Fri Dec 3 12:26:04 PST 2010
On 12/1/2010 11:57 AM, Ted Hardie wrote:
> I think we have an opportuity to hire someone with critical expertise in a
> suite of related areas (archival continuity, metadata and searchability,
> formatting and usability, and translation); getting that expertise in house
> is more important to me than whether the RSE acts as the contract manager
> for the IAOC-signed contracts with the production or publication side. I
> think that a senior expert with that skillset is also likely to have some
> management capability and I don't have a serious issue with management
> responsibilities or even arbitration roles. But I don't think this should
> consume the bulk of the time of someone in this role.
And here's where we do seem to differ quite a bit. I read the above as
primarily wanting an publishing technician -- one with a focus on document and
library representational theory and practice -- while showing a remarkably
casual concern for management skills. "Also likely to have" is not an
encouraging phrase if management is at all important.
Management is always important for senior positions. Having management when you
don't need it is terrible, as is not having it when you do.
Is someone who has overall responsibility for ongoing operation and enhancement
of an important document series primarily a "manager" or are they primarily a
I hope the former, because that's the sort of person who
worries whether all of the right pieces exist, whether they
fit together properly, whether they are operating properly
and how they could be made to be better.
The term "technical manager" is more apt, since it means a manager with serious
skills at running technical activities. The amount to which this requires that
the manager directly have deep technical skills varies quite a bit. (There is
also the matter of /which/ technologies to have skills in. On that, you and I
probably agree that the focus needs to be on publishing rather than networking,
given your above list.)
> On the second point, I was struck by your inclusion of this text in the RSE
> job description you posted:
> "In the case of cross-stream disagreements, the RSE arbitrates the
> first-level of resolution effort. The RSE's decisions may be appealed to the
> I agree with the text, but is it really likely to occur often enough that we
> should focus on it in a job description?
It was enough of a concern to recently prompt the IESG to press quite strongly
to have the IAB formally declared able to reverse the RSE. (RFC 5742)
I merely documented that existing, formal reality. A job description should
indicate scope of authority. So it is only reasonable to help a new RSE
understand a basic limitation to their authority.
> To put this another way, I think the effort to stress the community
> leadership aspects of this role have actually focused the discussion on job
> elements that are relatively small parts of the job.
Enhancing the RFC Series services to better support a broader consumer audience
has not been a priority, possibly at any time, but certainly recently. To the
extent that anyone cares about providing better service such as alternative
language forms for RFCs or better online access tools or... That requires
outreach to be a real task, not just a casual matter of rare social networking.
And, of course, that's not to make less of the more internally oriented tasks
that you've emphasized.
>> However how can "work for the communities of interest" be determined
>> without talking to communities of interest? Outreach means talking to the
>> consumer side.
> Some of it will no doubt involve talking to the consumer side; some other
> aspects will be surfaced by the streams' editors or approvers (one community
> of interest being the producers, rather than the consumers).
Some, sure. But there seems to be tendency to believe that these internally
oriented interactions are sufficient for providing the major insights about the
outer community. They aren't.
What that sort of internally-focused model always does is ensure operational
incest. A group that feeds only on itself quickly becomes seriously undernourished.
>> I am not exactly sure how you distinguish "management" from "process".
>> The handling of difficult situations -- ie, escalations -- is a common
>> management function,
> I think of it in slightly different ways. When someone is coding and they
> turn to someone with more experience or an architectural role in the project
> for assistance, this isn't escalation in the usual management sense.
Correct. And that's why it's not the situation I was describing.
When you call a company's support service and do not get a satisfactory response
and ask to talk with the supervisor, you are not looking for the support agent
to make a friendly consultation with a colleague. You are escalating up the
authority (and, yes, skill) chain.
The nature of escalations for the RFC Editor are for handling problems that go
beyond the expected skill and authority of the diligent folk who handle
'typical' issues. These require someone with responsibility for the overall
conduct of the RFC Editor, not just the conduct of a specific function.
>> Classifying any sort of outreach as "overhead" is pretty unusual, as job
>> descriptions go. It is normally classed under such categories as
>> marketing or customer service and neither of those is typically viewed as
>> overhead. The former is in the realm of getting or keeping customers and
>> the latter is in the realm of keeping customers. That ain't overhead.
> Okay, but is it a key role for this job? Shouldn't the IETF leadership be
> marketing/doing customer service for the standards track?
Yes, there is a difference between doing outreach for the IETF, for IETF
standards, or for the RFC Series. The RFC Editor does not have promotion of the
IETF or IETF standards within their scope, although RFC Editor outreach might
have benefits to the IETF. However their scope /should/ include ensuring that
the Series has the broadest reasonable utility, which means understanding new
and potential consumer bases, as well as ensuring that the form, style and
access to the Series are adapted to those groups..
> Is the key marketing here for the series as a coherent conversation spanning
> tracks, or as individual tracks? If the former, how much of the time for the
> RSE gets put into this?
I was not aware that the public discussion sought to specify the percentage
of time the RSE will spend on particular topics.
>> <snip> Perhaps it's not what you meant, but it sounds as if your premise is
>> that people who are under contract cannot be managed or that changes to
>> their work cannot be made.
>> But constraints do not mean that supervision is not possible.
> As the task requester on the contract, that civil servant gave new jobs
> under the general contract... The overarching theory was that the contractor
> had control over how the task was accomplished,
> if you used this mental model, given the supervisory role for the RSE, would
> the RSE be a task requester or contract manager?
Indeed, there are many different way to write and manage contractor relationships.
My own focus is on the RFC Editor work, not on the supporting contracts
administration effort that might be required to support getting the work done.
(Contracts administration is, of course, relevant for contractor relationships,
but the extent to which it is a factor depends on the contract and on the
relationship with the contractor.)
More information about the rfc-interest