[rfc-i] Some questions about the RFC Editor restructuring plan
hgs at cs.columbia.edu
Thu Aug 7 05:33:34 PDT 2008
It is not clear whether the discussion is based on experience in the
technical and scientific publishing world, or if the rough
correspondence is an accident. I sit on the steering committee of the
IEEE/ACM Transactions on Networking, and their model, which is very
similar to most journals I know of, is as follows:
- The steering committee selects an editor-in-chief, for a finite, non-
renewable term. That position is a volunteer position. The EiC sets
general policy (usually in discussions with the steering committee),
gets involved in editorial disputes, nominates new associate editors
and observes the work flow. In particular, the EiC is generally held
responsible if the time-to-publish starts increasing. The position is
assumed to be part-time for the person holding it. The EiC is not
expected to read every paper that is published and does not generally
make accept/reject decisions, but may get involved in process-level
issues, such as perceived unfairness or incompetence by an associate
(Some compsci journals have long-term EiCs; IEEE and ACM seem to have
- The EiC is supported by an assistant, paid by the technical society,
to manage the day-to-day affairs of the journal, such as hounding
tardy associate editors or answering author questions.
- Copy editing and production are handled by a separate entity,
typically the society and its contractors, on a timescale that is
measured in decades, i.e., independent of the term of the EiC.
- Some magazines (say, IEEE Network Magazine) have special editors for
There are obvious similarities to the proposal and, in some aspects,
the RFC series has strong similarities to journal publishing. (It is
no accident that RFCs got an ISSN, after all.) Thus, it may be useful
to see if there are lessons and terminology that can be adopted.
On Aug 7, 2008, at 6:20 AM, Olaf Kolkman wrote:
> First a few answers to your questions, then a few words on what I
> picked up in the hallways.
> On Jul 31, 2008, at 4:44 PM, Bob Braden wrote:
>> * Please give a concise summary of how this restructuring model
>> from the current model. Note that the proposed model is so general
>> that it includes as
>> one case the current ISOC contract with ISI for RFC Editor services.
> This is the _first_ model of the RFC editor function. Under the
> current contract ISI performs almost all of the functions indicated
> in the diagram. The notable exception is that some early copy
> editing is done under direct contract under contract with ISOC,
> managed by the IAOC .
>> * What will be the lengths of tenure of the independent submissions
>> supervisor and of the RFC Editor? Also, what length of time will
>> the contract with
>> the Production House cover? This is relevant to stability,
>> continuity, and staff
>> morale under the restructured organization.
> Currently the contracts that the IETF maintains with its vendors
> (ISI and AMS) are for 2 years with a possible extension of 1 year.
> My personal view on this is that the choice for contract terms is an
> IAOC matter. The trade-offs include stability, continuity and morale
> during the time that contracts are up for re-bid, the costs for the
> IETF (not only monetary) to have to change vendor, and allowing for
> a competitive proposition.
>> * Clearly indicate whether the positions described will be funded
>> by ISOC, or will get only travel and similar "administrative"
>> expenses reimbursed.
> Actually, this is one of the open questions in the model. There are
> two alternatives for the selection of the persons/institutions
> filling the role of Independent Stream Approver and the RFC Editor
> functions: Through a nomcom like process or trhough RFP-ing. Also
> the funding of those roles are subject to guidance from the
> community. Clearly, the selection and payment are tightly bound.
>> * The (new) RFC Editor position is implied to be a manager and have
>> responsibilities, yet this position has no authority.
>> without authority is a well-known "bog".
> I realize that there is a risk that my answer will start a debate
> about semantics.
> Within the IETF community there are a number of positions (ADs, WG-
> chairs, IAB membership, Nomcom membership) where by taking
> responsibility folk are being granted authority. And although folk
> in those positions have a small toolkit if it comes to the available
> carrots and sticks this all seems to work to some extend.
> It is up to the parties involved in the model, including the IAB and
> IAOC, to grant the authority to the RFC editor. I hear you pointing
> out that there are risks that that may fail.
> Some feedback I got in the hallway. Paraphrasing various folk,
> without giving attribution. Mainly because I forgot who said what
> and I may actually misquote them.
> 1. The Independent Stream Approver job title
> The Independent Stream Approver is an unattractive name for the
> function. It sounds like an accountant/auditing function not as the
> "Chief Editor" of a important and relevant publication stream.
> Personally I think that this is a fair point. Suggestions for
> another title that is more attractive are welcome.
> 2. Coupling of production house and the RFC Editor role.
> A few folks mentioned that it is probably not a good idea to
> separate the RFC Editor role from the Production house role.
> Here we have to make a distinction between the model and its
> implementation. The model currently separates the roles while it
> allows for an implementation that awards the responsibilities to
> separate persons/institutions. The model also allows an
> implementation that bundles those roles (and the others) and award
> them in a single contract. The last point that Bob made above argues
> to bundle the roles.
> However, the question is wether on the long term there are benefits
> for maintaining a distinction between the roles. It occurs that
> maintaining the rfc-editor and production house as seperate roles
> from a model that describes the production and its processes allows
> for some flexibility in the future.
> I hope that with this mail more comments and feedback are triggered.
> --Olaf (wearing no particular hats)
>  For the benefit of folk not familiar with this: an example of
> such contract can be found at http://iaoc.ietf.org/documents/CopyEdit_Contract.pdf
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest