[rfc-i] RSE models

Dave CROCKER dhc at dcrocker.net
Wed Dec 1 09:49:52 PST 2010


Ted,

meaty response.  thanks.  comments inline.


On 11/29/2010 11:20 AM, Ted Hardie wrote:
>> Can you elaborate, in practical terms, what the last sentence translates
>> into?
>>
>> What do you specifically "about the documents" to refer to? What do you
>> consider "overhead" to cover in terms of actual activity.
...
> My own thinking on this was partly a reaction to this text in 4.2, listing
> the responsibilities of the RSE:
...
> 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.

The presumption in your use of "but" is that management, process and outreach
have nothing to do with maintenance or advancement, or at least not much.


> To me, that task includes things like developing and maintaining the style
> manual,

Work on various documentation is already in the description, yes?


 > trying to make sure that the meta-data used for archiving and
> publication work for the communities of interest,

Your list of example questions looks pretty reasonable.  However how can "work 
for the communities of interest" be determined without talking to communities of 
interest?  Outreach means talking to the consumer side.


>   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 am not exactly sure how you distinguish "management" from "process".

The RSE is not the person who performs the daily, essential grind of processing 
documents or handling online services.  That's what the Production and Publisher 
staff do, of course.

The handling of difficult situations -- ie, escalations -- is a common 
management function, absent the more formal problem-resolution escalation 
department present in larger organizations.  Even then, management is part of 
the escalation sequence.


>  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.

Me too.

I am beginning to suspect that apparent disagreements, here, might have more to 
do with how that work is labeled than what it actually is...


> 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.

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.


>   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).

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.  Of course, neither premise is correct, and I'll bet that even if you 
meant something like this you did not mean it in as extreme a form as I've stated.

Any sort of supervision comes with constraints.  Supervision of contractors has 
some of its own kinds of constraints and anyone doing the supervision needs to 
be cognizant of them.  But constraints do not mean that supervision is not possible.

So, yes, the details of contracts matter.  Anyone attempting to do supervision 
without attending to the constraints of contracts gets laughed at.  Or, rather, 
they get a response of "here's what the change to the contract will cost."  (But 
then, the latter is the response they get when they /are/ attending to the 
constraints, too...)

So the concern that makes sense, here, is whether a candidate has an 
appreciation of managing contractors.  Do you have concerns other than that?


d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list