[rfc-i] Fwd: Alternate Proposal for RFC series management

Paul Hoffman paul.hoffman at vpnc.org
Mon Jan 10 18:56:07 PST 2011


On 1/10/11 8:09 AM, Glenn Kowack wrote:
> Paul, (et al),
>   Thanks for putting this together.  It's a good vehicle for revealing design choices.
> In that spirit, I have tried to link all my comments to well-understood principles or
> input heard from the community.  In your replies, it would be helpful if you could
> similarly reveal the bases for your positions.

I have done so where we disagree. You'll see that in many places you 
make it sound like we disagree where we don't.

 > I start with the primary concerns
> about your alternative proposal:
>
> 1) A major reason for having an oversight committee (with an "advised and consent
> model") was to support the RSE without suffering the problem of having a committee
> attempt daily, hands-on, direct management of a critical service.

We fully agree here.

> By making the
> REOC (your RSOC) a management committee, you re-introduce this problem. (See
> Joel Halpern's recent comment on committee think.)  And, a small detail, but another
> source of confusion: the name RSOC is fundamentally misleading; you describe a
> management committee, not an oversight committee.

And we fully disagree here. This is the core of our disagreement. The 
manager, whether it is a committee or an individual, does not need 
"attempt daily, hands-on, direct management of a critical service". The 
manager needs to be able to respond to exceptional problems that are 
brought to the manager's attention, and needs to watch for such problems 
through day-to-day observations. That can either be done by a hands-on 
individual such as is your proposal, or by a group of motivated 
participants who delegates the watching such as in my proposal. The 
basis of this proposition, then, is that there is a viable alternative 
to your (IMO) limited view of management.

It is not "misleading" to say what I describe is an oversight committee. 
The proposed tenor is management by oversight and delegation, instead of 
management by sharing responsibility between the committee and the 
individual. That is, the name is an important difference between our 
models, and I think that your model is better described as "shared 
management". (More below about your distrust of work done by groups.)

> 2) Under the Recommendations, the RSE is the one person responsible for making
> sense of the Editor and the Series as a whole and has no other conflicting interests.
> This makes it clear to the community who they can unambiguously point to (the RSE)
> if the RFC Editor or Series are going in the wrong direction.  You undo that.

This is a frustrating reflection of the process so far. The model 
document doesn't discuss an REOC at all; the overview document says "The 
Series Editor reports to the REOC"; the motivations document says that 
the REOC has "real authority"; in our offline conversation, you talked 
about shared responsibility. Both your proposal and mine leave the IAB 
responsible for the series as a whole. Thus, I think neither you nor I 
give the community someone to unambiguously point to, and nor should we.

> 3) The IAB's chartered responsibilities include the approval of the appointment of the
> RFC editor and approval of the general policies to be followed by the RFC Editor.
> "providing direction" to the RSE, or to the RSOC as you suggest, would be a
> significant increase in the work load on the IAB.

We agree, which is exactly why I didn't say that. I said that the RSOC 
"Takes input from the IAB on overall direction of RFC series", and that 
the RSA doesn't. I'm not sure how you got the direct quote so wrong, but 
your proposal and mine are in agreement on not increasing the work load 
on the IAB.

> One of the important goals of the
> proposal on the table is to reduce the work load this function places on the IAB, not
> increase it. It is also worth noting that if the IAB were responsible for providing such
> direction, the IAB would have to be the party responsible for judging gathering and
> judging community input about the RFC Series. While the IAB is ultimately
> responsible for that, avoiding needing them to directly do that seems a good thing.

This is a pure strawman. Nothing in my proposal says that "the IAB would 
have to be the party responsible for judging gathering and judging 
community input about the RFC Series": you just said that. My proposal 
keeps them out of it. So, again we agree although you say that we don't.

> 4) The TRSE Recommendations continue 5620's division of work between the
> Production Center and the RSE, under which the RSE does not perform regular
> editorial work.  When you overlap responsibilities you create confusion.  It would be
> redundant and confusing for the RSE to be a technical editor, and would destroy
> today's clear division of responsibilities and direction. You reverse that.

That's complete nonsense. Nothing in my proposal has the RSE performing 
any "regular editing work". As you indicate further down, "edits" here 
means "revises existing documents that relate to the RFC series". This 
is identical to one of the tasks in your proposal (although, oddly, you 
say below that is not what you propose).

> I earlier
> stated that I have seen no need for the RSE to be involved in regular production.
>   They might edit a document now and then for quality-monitoring purposes, but
> that's all.

And here we strongly disagree. The RSE should *never* "edit a document 
now and then for quality-monitoring purposes". In my model, the RSE  now 
and then reviews how the PC edits documents; this is done as a sanity 
check on the process to get early warnings about likely problems.

The basis for my proposal that the RSE never edits RFCs is that an 
author would have no idea whether his/her RFC is going to be edited by 
the professional staff or the RSE. I suspect that wiser RFC authors 
would demand a re-edit if they found out they were in the "now and then" 
group.

> 5) In one of your alternatives, you would have the REOC select winners of bids. On
> first principles, this is a bad idea.

We fully agree here. I included it because it had come up in the 
community discussion.

> The RSE and REOC should limit themselves to
> their specific 'technical' expertise as it relates to editing, publishing, etc.  They
> should, for example, lead the discussion with the community in putting together
> SOWs for new bids, while the IAOC should continue they authority for contracts,
> legal, and financial matters.  Your proposed alternative interferes unnecessarily and
> inappropriately with the IAOCs responsibilities as defined in BCP 101.

Yes, but the fact that we agree on that doesn't mean that it should not 
be listed as an alternative in a discussion document. Further, note that 
your current proposal has the RSE as one of the two parties that 
recommends the contractors. That recommendation disagrees with your text 
above.

>> New body: RFC Series Oversight Committee (RSOC)
>> Responsible for overall series management and stability
>> Creates policy for the RFC series
>
> There is long-held understanding that committees are ineffective at leadership (see
> Joel Halpern's response) but are excellent at oversight.

We fundamentally disagree. You formed your committee one way, while I 
formed mine in a wholly different way. The basis for this belief is that 
RSOC can be effective at leadership of the RFC series if it has a strong 
stake in the outcome; having the majority (or entirety) of the RSOC be 
stream representatives brings that stake to the fore. The RSOC as you 
have constructed it (people assigned by the IAB) might have much less 
stake than the one I suggested, but that doesn't mean that all 
committees are inherently ineffective at leadership.

> It also makes the position
> less attractive to the calibre of person required to do the job well.

On what basis can you make that claim? You have not done a job search 
for people either in your model nor mine.

>> Six members
>> One representative from each stream
>> Two selected by Nomcom with staggered terms
>
> I believe we can leave these details up to the IAB.

We can, or we can help them by proposing an RSOC who has the strongest 
stake in making the RFC series the best possible. I chose the latter. 
(I'll pull out this decision in a separate thread.)

> Furthermore, others have
> pointed out that adding to the load of the already overburdened Nomcom is
> problematic.

That could indeed be true, and having just the four stream 
representatives might be sufficient. My proposal was based on the idea 
that some might think that "just the streams" is not representative 
enough of the RFC-using community; I don't have a strong opinion either 
way. Note that the Nomcom meets all year, and these appointments don't 
have to happen at the same time as the IESG/IAB appointments. But I 
think my proposed model, even without Nomcom additions, still leads to a 
more motivated RSOC than the one you have put forward.

>> Gives significant input to IAOC on selection of RFC series contractors
>
> This is ambiguous, but otherwise not bad.  See my point above re SOW preparation.

Hrm. This proposal seems less ambiguous than "with the IAOC" in your 
proposal, as I said earlier on the rfc-interest mailing list. We may 
just differ here on what is clear.

>> Appeals of RSOC decisions go to the IAB
>
> This is consistent with the IAB maintaining its chartered responsibility.
>
>> Takes input from the IAB on overall direction of RFC series
>
> I understand the IAB wishes to and should morse properly be in a position of
> ensuring proper processes rather than providing direction.  This also flies in the face
> of the RSE and REOC (or RSOC) working with the community to determine policy
> (hence direction). It also threatens confounding the RSE reporting to the REOC.

As always, the IAB gets to decide how much input to give to anyone. This 
proposal does not change that, regardless of how often you say it does. 
There is no face-flying on policy: the IAB takes input from wherever 
they want. In other words, I have no idea what you are saying here.

>> New person: RFC Series Administrator (RSA)
>> Replaces the RFC 5620 "RSE"
>> Contractor who reports to RSOC
>> Takes direction from RSOC on new initiatives
>
> Ditto above: this loses the power of the RSOC's "advise and consent" model (per
> Brian Carpenter)

Completely agree: this is the core of where our proposals differ.

>
>> Primary jobs of the RSA:
>> Acts as public face on RFC series
>> Leads discussions of proposed policy changes
>>    Reports results to RSOC for decision
>> Edits RFC series documents
>>    Style guide and production process guide
>>    Explanations of the RFC series (new)
>
> "Edits RFC Series Documents" is problematic, per above.  I have not observed a
> requirement for this activity, and it could create unnecessary confusion, and
> interference with RPC Staff.

My proposal reflects what is in RFC 5620: the RSE develops, maintains, 
and publishes the style manual (Section 3.1, bullet point 5). I don't 
see this as problematic; in fact, I think the RFC 5620 way has many 
advantages over having the Production Center do it. In fact, your 
current proposal has the same thing.

>> Makes rfc-editor.org web site more useful to different audiences
>> Handles errata system
>> Creates monthly public reports on Production Center and Publisher
>
> This appears to get in the way of already successfully delegated functions provided
> by the RPC. The RSE should own the requirements and have the RPC do the vast
> majority of specified reporting.

We disagree here. It is a small task, and it should be done by the 
person overseeing the activity, not by the party doing the activity. 
FWIW, RFC 5620 is silent on this.

>> Performs sampled reviews of Production Center processing of drafts
>> Mediates disputes between streams
>>    Reports on dispute and results to RSOC and public
>> Mediates disputes between authors and Production Center
>>    Reports on dispute and results to RSOC and public
>> Expected workload is 15 hours/week
>
> Probably just a bit short; 20 hrs/wk (50% FTE) is minimum.

Fodder for a different thread. FWIW, I think your number of hours is 
also fine, but probably more than is needed after the first year or two.

>> RSAG becomes advisors to both RSOC and RSA
>
> This takes away the RSE's unique stable of advisors, which he will need and create
> anyway.

This was discussed at length earlier on rfc-interest: everyone can 
create their own committees. I suspect that the RSOC will need advisors 
as well.

>> Alternative: RSOC does bidding and selection of RFC series contractors
>> Would first require buy-in from ISOC
>> Would then also require change to BCP 101
>
> Per above, this provision is neither necessary nor wise, and goes far beyond the
> TRSE recommendations.  The RSE should focus on SOW content and evaluation of
> technical (as in tech writing) competence of applicants while the IAOC continues its
> responsibilities for contractual, legal, and financial.

Yep, that's why it was listed as an alternative. If only a very small 
number of people want it, it should be dismissed.

As mentioned above, I will start separate threads on naming, on 
composition of the REOC, and on expected hours for the RSE.


More information about the rfc-interest mailing list