| TOC |
|
This memo provides the background and motivations for the recommendations made in draft-kowack-rfc-editor-model-v2-overview-00. It represents the perspectives resulting from an individual managerial and analytical effort of nearly one year's duration. It contains a summary of the factors considered to be essential to the job of RFC Series Editor (RSE). This includes a summary of the work done as part of the RFC Editor, the differences between [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.)and the [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) recommendations, a discussion of development work that should be done, and an assessment of the time needed to perform the RSE job. There is also a section listing and responding to questions surrounding the recommendations.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
This Internet-Draft will expire on June 23, 2011.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
1.
Introduction
2.
Key Observations and Drivers of Design Choices
3.
What Does the RFC Editor Do?
3.1.
Editing Work is Performed by Production Center Staff
3.2.
How is the RFC Editor Managed?
3.2.1.
Coordination and Meetings
3.3.
Why the RFC Editor and Series Still Need a Manager
3.3.1.
Scale, Complexity, Formality, and Duration Make Management Inevitable
3.3.2.
The Community's Way of Doing Business Has its Own Overhead
3.4.
What Does the RFC Series Editor Do?
3.4.1.
Addressing questions and problems from within the RFC Editor
3.4.2.
RSE Activity Example: Ensuring and Improving Access to RFCs
3.4.3.
RFC Editor Escalation Procedure
4.
Differences between V2-Overview and RFC 5620
4.1.
General and Design Strategy Differences
4.2.
Specific Differences
4.2.1.
Series Editor Authority and Supervisory Duties
4.2.2.
RFC Editor Oversight Committee and RSAG
4.2.3.
Decommissioned RFC Series Advisory Group
4.2.4.
The IAOC and IAD
4.2.5.
The Series Editor and General Management Issues
5.
RFC Editor and Series Development Work
5.1.
Update, Improve, and Reorganize the Style Manual
5.2.
Develop and Publish a Procedures Manual
5.3.
Improvements to the RFC Editor Web Pages
5.4.
Investigate Enhanced Training for RFC Authors
5.5.
Investigate Providing Support for RFCs in Additional Languages
5.6.
Consider Supporting RFC Clusters and Enhanced RFC Annotation
5.7.
Investigate Reinforcing the Status of the Series as Academic Publications
5.8.
Investigate Formal Persistent Names or Identifiers for RFCs
5.9.
Lead Discussion on Universal Access and the ASCII Format of Normative Versions of RFCs
6.
RSE Time Requirements
6.1.
General Recommendations
6.2.
Current Level of Effort
6.3.
Additional responsibilities under V2-Overview
6.4.
Which Levels of Appointment Make Practical Sense?
6.5.
Orientation Time Requirements
7.
Key Questions and Answers
8.
IANA Considerations
9.
Security Considerations
10.
Normative References
§
Author's Address
| TOC |
As Transitional RFC Series Editor (TRSE), I performed the job of RFC Series Editor (RSE or “Series Editor”) throughout 2010. While actively engaged in the role, I was to analyze work requirements, engage in community discussion, and recommend changes as necessary to [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.). (Note to the reader: I use 'community' to refer to anyone who participates in, or uses the output of, the technical, organizational, and other discussions associated with the I* entities.) A specific problem was also to be addressed: the defined RSE position must attract qualified candidates. Those recommendations are summarized in [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.). This memo provides the background and motivations for the recommendations. It pays particular attention to the role of the Series Editor and how [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) differs from [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.). This document is not a community document. Rather, it contains the perspectives resulting from an individual managerial and analytical effort of nearly one year's duration.
If the community wants an RFC Editor that is responsive and productive, then the IAB must appoint an RFC Series Editor who has management and development skills and who is given authority across the entire Editor."> I observe that a segment of the community wishes to minimize the role of the Series Editor, envisioning the job as merely a senior editor. My experience this year demonstrates that this will limit the ability of the RFC Editor to deal with its backlog of development requirements and its ability to adapt to emerging community issues. The scale, complexity, and richness of the subject matter of the Editor create regular demands for management and coordination.
| TOC |
The key observations behind, and drivers of the design for [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) are:
The RFC Editor must work, and be structured to work, in the community's interest.
The RFC Editor (or 'Editor') must not allow anyone to have inappropriate influence over, or 'capture' the Editor - using it in his own interests. This includes the Series Editor, staff, contractors, unauthorized I* entities, individuals, or groups. For all substantive issues, the community must clearly be in charge.
Issues addressed by the Series Editor consistently demand a high degree of publications-related knowledge and analytical skills not common in our community.
Because RFCs do not change once they are published, prospective innovations must be thought out in advance very carefully and with special attention to unexpected consequences, putting a premium on expertise and prior experience. During 2010, I did not see issues that were rudimentary or only required text editorial skills. Rather, each issue required deliberate review and analysis to uncover its character and extent, often including RFC Editor staff, RSAG members, and community members. These required sophisticated management and service design skills, not merely editing skills.
There is a substantial body of important RFC Editor and Series development work waiting to be done.
A priority is protection against RFC Editor service interruptions. Included are improvements in documentation of editorial practices and processes, Series access, guidance for authors, and the RFC Editor web site. Support for end-user ease of understanding what RFCs are required to implement specific services, persistent name technology, and others, have been cited by community members.
A balance must be maintained between (i) demands of RFC production, and (ii) RFC Editor and Series development.
During 2010, RFC production worked well - confirming that part of the model - in part because it allows editorial staff to focus on production. Staff must participate in Editor and Series development, which must be balanced with production work. This balance can be assured only by having an experienced, knowledgeable, manager with explicit responsibility for the performance of the entire Editor.
As defined in RFC 5620, RFC Editor management structure is complex and unclear.
The Series Editor is responsible for resolving policy issues and providing "executive level management" of their implementation, but does not have authority to assign resources. Today, this gap is filled by the IAD and IAOC, which are not structured for the requisite publications expertise or focus. There is also a regular oversight meeting during and between IETF meetings, called by the IAD, and attended by the IAOC chair, the streams, AMS staff and management, and the Series Editor. The IAB, to which the RSE reports, has a very heavy workload, multiple competing priorities, and is not structured for publications expertise. Clarifying authority and responsibility is required to attract a qualified Series Editor.
The major design choices in [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.), and thus the recommended changes to [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) are:
The proposed Series Editor role is conceptually equivalent to the head of a publications department in a technical organization.
The community has not yet converged on a common view of the span of authority and responsibility of the Series Editor, the type and level of expertise required, or the structure of RFC Editor oversight. Through a description of the work of the RFC Series Editor as performed during 2010 and related observations, this memo seeks to motivate necessary changes to the Series Editor, including attracting suitable, qualified candidates.
| TOC |
The following is based on my experience as TRSE during 2010. I call out those cases where the role differs from RFC Editor Model (Version 1) described in [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), based on how the role presented itself to me, and as a consequence how I now believe it needs to be organized.
RFC Editor output is produced through two functions: the RFC Production Center (or RPC), and RFC Publisher (the 'Publisher'). Per [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the Series Editor provides "Executive-Level management". During 2010, In order to observe how the model is currently working, I intervened as little as possible in RPC or Publisher activities.
Here is a review of some aspects of performance that I observed:
Day-to-Day, the RFC Editor Model works well for basic RFC production and publication.
During 2010, RFC production has been steady. There is general satisfaction with the rate and quality of output, with the service provided by the editorial staff, and with their responsiveness. Staff of the Production Center and Publisher staff understand their jobs and are focused; I did not observe anything blocking their performance.
Day-to-Day, the streams model works well.
The participants in and leadership of each of the streams appear to understand the scope of their subject areas. I have not observed any problems, nor heard any substantive concerns, about how each should use the services of the Editor. All discussions of inter-stream conflicts were satisfactorily resolved by the concerned parties, following documented procedures
I observe that, following many years of experience and refinement, the RFC Editor is highly organized for steady-state RFC production and publication using a single, narrow service and editorial model. However, this is not the entire range of required RFC Editor services, as I will describe in following sections.
| TOC |
The RFC Production Center (RPC) center is provided by AMS under contract. It performs regular RFC Editor document production. AMS also provides the RFC Publisher service.
Following generally-accepted editorial style and procedures, much of which is lore learned by editorial staff over many years, editors receive approved documents from the streams; they make textual changes for correctness and clarity, and formal changes, such as formatting and adding specific boilerplate text; they engage IANA as necessary.
The Production Center has its own director, an AMS staff member. She manages the day-to-day activity of the editorial staff, including document assignments and customer interaction. She also works as an individual contributor alongside the other editorial staff, and is the senior and most experienced editor. The Production Center publishes regular production reports, comprised primarily of statistics.
The staff of the Production Center are the Editor’s most frequent point of contact with stream participants and approvers. They provide the vast majority of production-oriented services. In excess of 90% of drafts come from the IETF stream. Furthermore, the Production Center director acts as liaison to the IESG, to whom she submits regular reports; these are available on the RFC Editor web site. Consequently, the majority of document-oriented interaction and support is between the Production Center and one of the four streams.
As with other service organizations dominated by a single user or customer, it can be inherently challenging to provide balanced service and support to all of the other customers. During the TRSE period, I did not observe any problems or complaints in balancing Editor resource allocation across the streams. Beyond that, however, there is a substantial backlog in non-production services and capabilities that have not been adequately addressed or implemented, nor integrated into a long-term plan with specific priorities; nor has their content and value been sufficiently represented to the community. I address these in Section 5 (RFC Editor and Series Development Work).
| TOC |
| TOC |
A weekly teleconference of all RFC Editor staff is attended regularly by the:
During the RFC Editor meeting, ongoing issues and monthly output are reviewed and discussed. Topics frequently include issues for which current policy is insufficient. These often turn to review and analysis of past and current practices, including their origins and varying application over the years.
Attendees are presently based in different locations throughout the continental US, plus the Independent Submissions Editor in New Zealand. I have not observed any problems arising from the remote distribution of staff. To the contrary, everyone appears diligent at keeping this from becoming an issue.
The RSE is RFC Editor liaison to the IAB, for whom he prepares regular reports. During 2010, the RSE attended IESG meetings, as a visitor sitting in for orientation while TRSE.
During IETF meetings, the IETF Administrative Director (IAD) also calls a regular RFC Editor lunch comprised of the IETF Administrative Oversight Committee (IAOC) chair, stream approver chairs, the RPC director and invited staff, AMS management, and the RSE. These participants review and discuss overall RFC Editor activity as well as stream observations. This is the one regular meeting at which most of the leadership cited in the Model meet face to face. There is also an RFC Editor teleconference between IETFs, also called and led by the IAD, during which RFC Editor issues are reviewed. This is consistent with [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), although not explicitly called for.
Senior RPC staff, the ISE, and RSE, are available to community members during IETF meetings.
The RSAG is unstructured and, except for a regular "Tuesday lunch" during IETFs, has no regularly scheduled meetings, nor structured reports. Per 5620, the RSAG is available on request of the RSE to answer questions, provide advice, and to help formulate recommendations to the IAB when necessary.
| TOC |
Throughout its entire history, the Editor and the Series have been led by a single manager, beginning with Jon Postel and then Joyce Reynolds and Bob Braden. The current success of the Editor and the Series is due significantly to this historical fact.
| TOC |
Successful organizations invariably grow along multiple dimensions. They get larger and more complex, accumulate practices and precedents for decision-making, and become more sophisticated at their work and their understanding of their environment. They have correspondingly richer and more complex interactions with other entities that are evolving similarly. Good organizations strive to keep their structure and practices simple, and to avoid creating unnecessary bureaucracy. However, scale and duration have implicit overheads that cannot be ignored. All these things are true of the I* and the RFC Editor.
As organizations grow and as complexity increases, ad hoc coordination becomes less and less effective, and the cost of failing to coordinate matters increases. In the Editor, when a policy issue arises it presents a practical problem: a decision needs to be made but extensive discussion and coordination is nearly always required. Resolution is not necessarily obvious or straightforward, and there may be broad implications. Making concerted decisions is especially important because the community wants I* entities to be responsive - to their comments, questions, requests for information, and requests for changes or corrections to problems. Someone needs to be sure these processes are managed well, and brought to timely conclusions.
The I* has grown sufficiently large and complex that issues which appear to be simple are often very subtle, and their resolution may have far-reaching conclusions sensitive to the particulars of the decision. For the RFC Editor, someone has to own that effort. The point person must vet it past experts, bring it to the community, anticipate the consequences of the different options, and be insightful at finding a suitable outcome when the right choice may be far from obvious.
We need to acknowledge that such activities cannot be managed in an ad hoc way, nor should they be assigned to staff that have regular production duties - the split interest would mean serving both purposes poorly.
There is another oft-neglected point. Explicit assignments of responsibility let everyone know who is responsible. If responsible parties are good at their jobs and are transparent about their work, everyone knows how the decisions are being made. This markedly reduces the overheads suffered by suspicion-prone (meaning just about all) organizations. If, on the contrary, responsible parties are not formally and publicly appointed, then others will surely step in when they think they are needed, often with the best of intentions, but will too often make decisions that align more with their particular perspectives than with the long-term interests of the broader community.
| TOC |
Every organization has its own style for doing business, including the I* entities. The I*'s preference for open participation and extensive discussion ensures that all major changes require significant effort by a representative of the RFC Editor.
This has two broad consequences. First, many initiatives should be carefully considered and developed before they are taken to the community. Not doing so can waste valuable time and cause unnecessary contention while the actual issue is still being clarified. Nevertheless, community review will often require a substantial amount of attention and calendar time to make progress. This is the environment in which the RFC Editor finds itself, and it may account for some of the historical debate about its purposes and processes. The second is that, serving the community in this environment requires a dedicated, focused expert who has no other interests, who can devote the time (including months or years of developing perspectives) and energy to make this process work.
| TOC |
Per [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the primary job of the RSE is to lead development of new policy when current policy is insufficient. RFC activity in this area may originate from within the RFC Editor, the community, other I-star entities, or from the Series Editor's own work. The Series Editor does this work in conjunction with the Editor, the RSAG (or the REOC in the future), and the community, and involves the IAB as necessary to ensure compliance with community interest and appropriate processes.
The Series Editor provides guidance when the layer below - the Production Center staff or the Publisher - encounters a situation that is not clearly covered by existing policies or practices. RFC 5620 calls for the Series Editor to carry such issues to the RSAG and the community for discussion and resolution. However, [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) is silent about the authority of the Series Editor over RPC and the Publisher when small issues arise day to day, or when the Series Editor must make resource allocation decisions.
Per [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), and as practiced this year, the Series Editor does not participate in day-to-day production and publication activities, or any other regular production activities. The RSE, like any other manager, does not do the work of the layer that reports to him (although the analogy is limited; under [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the RPC does not report to the RSE). The RSE is not and should not act as a "team leader", a supervisor who is also a regular individual contributor working alongside other team members.
During 2010, as RSE I participated in the following, also consistent with [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.):
I also responded to an author complaint by initiating an escalation procedure. However, [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) does not clearly authorize the RSE to do so.
The RSE activities I describe here are exclusive of my TRSE activities. The latter consisted of research, surveying the community, preparing and delivering various interim presentations and reports, and the production and discussions of my final recommendations.
Immediately below, I describe in more detail Editor-originated policy discussions of issues that arose from the community and beyond, and from my experience performing an escalation procedure.
| TOC |
When RFC Editor staff comes upon an issue not addressed by current editorial policy, that issue becomes an agenda item at the next RFC Editor meeting. It is impressive how complex these issues can be, how often they touch upon many different dimensions of Editor work and the Series, how intricate and extensive their implications can be for Editor practices and the Series, and how much investigation it can take to pry loose all the issues. If we are unable to resolve a question swiftly, as RSE I bring it to the RSAG
During this period, typically several issues typically arose each month from within the RFC Editor. All required significant discussion. We usually asked the following sorts of questions:
The important questions often concerned impact on RFC Editor processes and the Series, and the Series’ long-term character. During 2010 we were not presented with issues primarily having to do with technical writing. Nor did we see issues with significant computer-scientific content related to protocols - that is, issues outside the scope of the Editor. I provide here an example of issues presented to and discussed within the Editor, after which I review my experience in leading an "escalation procedure".
| TOC |
Early this year, we received a request from a company doing business with the US Government. Among other things, they wanted to know how to fill out a required form on the sources of IETF standards, including the publisher of RFCs. The RPC sought guidance because there was no previous policy about who is the publisher of RFCs. After brief discussion we realized there was no obvious answer. I took that issue to the RSAG.
This also triggered a discussion about the RFC Series' ISSN (International Standard Series Number). ISSNs are often used to search for periodicals and disambiguate references. During 2008, the IETF Trust obtained an ISSN for the Series from the ISSN International Centre. However, we weren't sure whether the ISSN was still valid (or what the policy was for expiration), or whether we'd already answered questions therein about who is the publisher of RFCs. We checked and confirmed that our ISSN was still valid.
We were unable to find any reference to our ISSN over the web, nor through any of the major electronic card catalogs. No one had apparently been assigned responsibility for following through after obtaining the ISSN. I contacted old colleagues at one of the largest universities libraries in the world, and had them add the Series ISSN to their card catalog. Nearly all major libraries cross-reference their catalogs, so our ISSN can now be found all over the world.
I mention this to provide a distinct example of loose ends around the management of the availability of the Series. If someone out in the world uses the same sorts of tools that the community does, and looks at things the way the community does, then there is a good chance they will be able to find the Series, get to the web site, and continue from there. But, for someone not like us, for instance an academic, it may be a different story entirely. And access is an identified priority for the Editor and the Series.
These examples may appear small, but they sum to significantly reduced Series availability. They also illustrate how the Editor, outside of document production, depends upon someone’s just happening to notice an issue - that someone typically being a random volunteer willing to take initiative.
This is not a criticism of anyone involved in these issues. In the past, there has been such a narrow focus on production, probably necessarily so, that this sort of broader management was not given the necessary priority. The best remedy will be to task someone with general assignments (e.g., "ensure access"), to develop a big picture, seek out all the relevant parts, and then be given the authority and resources to drive those issues to completion.
The RFC Editor is uniquely positioned within the I*: it is a major formal vehicle through which the world obtains the work of the community. It is vital that this Editor ensures availability to the entire world, especially when many people may not use the same access techniques, as does the community.
A related subject is that we have not posted convenient examples for how RFCs should be referred to in other documents. This lack of guidance increases the chance that references will be inaccurate or ambiguous. Work has already been done on increasing the vitality, breadth of use, influence, and stature of the Series by demonstrating that RFCs are as rigorously reviewed as publications in conventional academic journals. Early in January 2010, RSAG members Brian Carpenter and Craig Partridge published “Internet requests for comments (RFCs) as scholarly publications” in ACM SIGCOMM Computer Communication Review.
Apprised of these developments, I called for the formation of an “RSE Committee” on Citations. A member of the RFC Series Advisory Group (RSAG) led this committee whose membership came from the community (a general call was made for members on the rfc-interest list.) They were asked to:
This assignment conveniently combined issues of the ISSN and library user access issues with those of reference examples.
The committee has been working on these related issues during 2010 and I expect to see their recommendations shortly. Those will be vetted by the RSAG and posted for discussion and review by the community.
The Series Editor's choice of this new, experimental model for addressing Editor issues demonstrates how the RSE can have significant positive influence, by crafting ways to investigate and develop issues. In the future, this should be done with the advice and consent of the RFC Editor Oversight Committee.
An important part of the managerial expertise required of the RSE is not just to know how to investigate issues and drive them to conclusion, but to know how best to harness the interest of the community in the process. Doing this well will improve overall outcomes by insuring their alignment with community interest.
| TOC |
During 2010, I received only one significant complaint about editorial performance. How this was handled is useful input into understanding the sort of managerial activities that will occasionally, and unavoidably, be required.
The complaint was from the author of a document while it was being edited. After extensive discussions with the author and the RPC staff member and director I was unable to satisfy the author and initiated an escalation procedure. Since there was no procedure specified for dealing with such cases, I notified the RSAG and the IAB, kept them apprised of my activities, and frequently requested feedback as the process unfolded.
I reviewed RPC editorial practices and performance with the voluntary support of the Independent Submission Editor (ISE). RPC management was highly responsive and supportive. I communicated my observations to the author.
Neither the specifics of the complaint nor the outcome are significant. What is significant, however, is that this case illustrates a general limitation of [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), which does not clearly assign (to the Series Editor or to anyone else) authority for initiating or managing such a procedure. Nor does it do so more broadly by, for example, assigning authority for day-to-day oversight of the RFC Editor. The most obvious candidates for this responsibility would be the IAD and IAOC due to their contractual oversight role, or to the Series Editor. I found that this task required a high degree of editorial background, and knowledge of current practices and the immediate circumstances of the RFC Editor. Furthermore, as I requested time and attention from RPC staff, it became clear that there would be noticeable impact on the rate of RFCs output by the Editor. However, [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) does not give the RSE authority or responsibility for Editor output, which could cause him to pay insufficient attention to any impact on productivity. Finally, although the RPC director was exceptionally supportive, this might not have been the case. The RSE needs sufficient authority to insist upon support, in case future RPC management is not as enlightened.
I also observed that the procedure, as performed, required far more than simple expertise in technical writing. Issues that came to light included:
Responding to questions of this sort with appropriate procedures requires an understanding of technical writing practices, experience managing the editing of publications, and sensitivity to the long-term implications of any intervention for the character and quality of the series. Experts should guide the resolution of these sorts of issues. Furthermore, insofar as it is possible, leadership should be continuous (that is, fixed to a role and not assigned on a case-by-case basis) to provide institutional memory in case there are repeated reviews.
I observe a gap in [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) between day-to-day production by the RPC, and the policy development and execution authority of the RSE. I recommend that this gap be filled by the RSE, the only person who will have the requisite editorial and managerial expertise. The RSE should be responsible for, and have authority over, Editor output. I also observe that day-to-day oversight by the Editor requires a level of experience beyond that of the IAD and the IAOC.
Finally, there is an issue of community and I* responsibility to professional staff. If we are going to evaluate staff, that evaluation must be led by our most qualified people. This not only includes critical analysis of work performance and subsequent recommendations and implementing of remedies. It also includes defending our professionals' performance when they are doing their work well under contentious or politically charged circumstances. Doing anything less is organizationally irresponsible and risks unfair treatment of our contractors' staff. Only a knowledgeable, continuously involved, authorized professional manager and supervisor can reasonably satisfy this requirement.
| TOC |
| TOC |
[RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) aims to ensure community control by dividing responsibility for the RFC Editor into multiple functions, allowing each to be contracted or appointed separately: the Production Center, Publisher, Series Editor and RSAG, and the Independent Submissions Editor and Independent Submissions Editorial Board. This division permits each part to focus on its mission. It also permits the community to more clearly see the performance of each part, which facilitates performance review. Indeed, this breaking out of the Production Center and Publisher has been highly successful.
[RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) does an excellent job of establishing part-by-part focus on each Editor component, but its “divided responsibility” strategy, carried all the way up to the oversight of RFC Editor operations, does not establish any corresponding integration of managing the operation of the Editor.
The IAOC and IAD continue their historical authority for management of the contracts, and the IAB for arms-length oversight. This is appropriate for those specific responsibilities. However, as defined in [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the Series Editor has authority only for what is left over: exploring and discussing issues as they arise from the community or within the Editor. Unfortunately the result is a minimal and apparently unappealing job.
Though not obvious from a first reading of [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), my experience of day-to-day operation of the RFC Editor and performance of the Series Editor role exposed a critical flaw: no one entity or person is assigned responsibility for bringing together all the different inputs from the Editor, plus input from the community and beyond, and making them all work together under the very serious demands of document production. This is required so that the RFC Editor as a whole operates smoothly and efficiently.
This lack of defined overall management authority also contributed to the failure to find a satisfactory candidate.
[RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) distributes authority for the Editor across two committees and two managers. This division is problematic. Committees are widely understood to be excellent at ensuring that multiple interests are addressed, but not at integrating inputs into a single, focused plan, nor for driving insights when developing such plans. Committees also, often with the best of intentions, suffer from having divided interests. Being comprised of members from disparate entities or parts of the community, they may, even unknowingly, have divided interests. This applies to the management structure in [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.). Without some one person assigned responsibility for overall management and development of the Editor, the community has a very difficult, perhaps impossible job, of knowing who is responsible for what is being done, and whom to talk to when there is dissatisfaction.
Furthermore, [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) explicitly chooses not to define a reporting structure for the RFC Editor. Instead, it treats the reporting structure as an implementation detail, to be established or changed by the IAOC on a case-by-case basis. There are three issues associated with this approach. First, the duration and intensity of community debate indicates that this issue needs to be resolved by the community as a basic design decision of the Editor. Second, reporting structure is fundamental to defining the RSE role, including qualifications and level of experience. Finally, it is extremely unlikely, as has already been demonstrated, that a motivated, qualified profession would accept that the reporting structure is to be determined in the future. [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) brings this decision to the fore for community consideration. It also makes future changes to the reporting structure substantive, permitting changes only with the approval of the IAB.
V2 Overview makes the Series Editor responsible to the community for the overall performance and operation of the RFC Editor. In this way the community will always know who is responsible for the Editor and the Series, and that the Series Editor has no other interest.
| TOC |
| TOC |
Under [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the responsibilities of the Series Editor are limited and insufficient. The Series Editor is responsible for addressing shortfalls in policy by taking them to the RSAG and the community for discussion and community resolution and, as required, confirmation by the IAB. The RSE is also responsible for 'implementation', without explaining what this means and without empowering the RSE to achieve implementation. That is, [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) does not state that the RSE has authority to direct the resources of the Editor (the Production Center and Publisher) in any implementation. It is likely that in many cases the Production Center would temporarily need to reduce their rate of document output in order to implement a new policy, and would need to be directed to take such actions. The RSE should be able to provide directions to do so after discussion and review by the streams and the REOC. However, under [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) the RSE would need to seek permission from the contract administrators, the IAOC or IAD. This is problematic. First, understanding the impact of any change on RFC production is best done by someone who has intimate knowledge of the production process, and to ensure community alignment; this should be done by under Series Editor leadership with the Production Center director. Second, putting control in the hands of the IAOC (or IAD) is problematic in that the IAOC and IAD are not structured for such publications expertise, and have multiple responsibilities that could conceivably compete with their attention to this subject. Finally, not having this sort of responsibility, and instead having to go through "contracts administration" (which is how it could be perceived) each time there was a sub-contract level change, would be unnecessary overhead, and very likely unacceptable to any qualified RSE candidate.
Supervision should be the responsibility of the most knowledgeable and experienced manager available. If there is to be an RSE, why not assign a direct supervisory role to the position, rather than put supervision in the hands of staff that are less knowledgeable (w/r/t editing and publications)? The same argument applies to reviews of performance. The RSE should lead reviews of the performance of the contractors, while the IAOC should lead annual reviews of Editor performance overall.
Nothing here is an argument against oversight, which this memo maintains is required. RFC Editor oversight must be focused, must have a suitable level of understanding or experience in publication, and must support the RSE via an "advise and consent" model.
The sorts of issues managed by the RFC Editor are different from those of the IAD and IAOC. The IAD and IAOC regularly agree to new contracts with significant financial exposure for the overall organization. The RSE will only rarely (perhaps once every few years) be involved in teamwork regarding major financial commitments (for example, when RFC Production Center and Publisher contracts are renewed or re-bid). Most of the time, the RSE will be involved primarily in many small daily and weekly decisions regarding editorial and publication work and policies. Such decisions will only occasionally have contractual consequences. In this case, it is not necessary to have the same degree of executive involvement by the REOC, as is the case with the IAOC.
| TOC |
Under 5620, the IAB provides oversight for the RFC Editor both in terms of chartered responsibility and regular reporting. However, the IAB is involved in a great many priority issues that compete with the RFC Editor, and cannot give a great deal of time or attention to the RFC Editor. Furthermore, the skill set required of IAB members conflicts with the skill set required of those who would directly oversee the RFC Editor and RSE.
Under [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the RSAG is an informal advisory body with no authority for oversight of the Series or the RSE. Having oversight authority would be awkward at best, since it is the Series Editor who nominates RSAG members.
V2 Overview calls for the formation of an RFC Editor Oversight Committee (REOC), that follows an “advise and consent” model to support the Series Editor and ensure alignment with community interests. This committee is structured to focus strictly on RFC Editor issues, and should be populated with members with significant interest, experience and expertise in the area of technical editing, publishing, and the Series itself. This is not a re-labeling of the RSAG. The REOC is selected differently (by the IAB, not the RSE), has a different mission (oversight, not strictly advice), and real authority (consent, which may be denied).
The role of the REOC is significantly different from that of the IAOC, in spite of having a similar name. The IAOC is directly involved in contractual, legal, and financial matters at the administrative level, and at least 3 times a year has to investigate, plan, and make major financial commitments for IETF meetings. The RSE and REOC will only be involved in such matters every few years, as the contracts for the RPC and Publisher renew. Even then, the RSE and REOC will be involved primarily as publications subject matter experts and not as financial administrators or contracts specialists. Rather, the RSE and REOC will focus on the large number of policy and operational issues, and their complex interactions and relative priorities that are of interest to the Editor and thus to the community.
This motivates the "advise and consent" REOC model, in place of having the RSE reporting to a management committee. The RSE should have far more publications and editorial expertise than the collective of the REOC, have much more intimate knowledge of all the day-to-day issues, and should thus be able to take a more leading role - all the while with the consent of the REOC. This approach will ensure alignment with community interest while encouraging initiative and innovation.
The IAB will retain its chartered responsibility for the RFC Editor, and will be consulted by the REOC on substantive policy questions. Thus the IAB will be relieved from involvement in day-to-day questions by delegating much of its oversight role to the REOC.
| TOC |
In [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), RFC Series Advisory Group (RSAG) members are nominated by the RSE and approved by the IAB. The RSAG has few formal duties. V2 Overview decommissions the RSAG to avoid redundancy with the REOC and thus reduce committee overhead. For transparency, [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) states that the Series Editor may have advisors, and that their names should be publicized. There is nevertheless a need for continuity and maintenance of institutional memory within the RFC Editor. The RSAG members should be asked to remain on board at least until the REOC is fully oriented and up to speed. This is consistent with the text in V2 Overview that states that the RSE may have informal advisors. (Since that text is not strictly necessary, it may be removed from V2 Overview depending on community input.)
Although not a major design flaw, it is notable that [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) takes a contradictory approach to the RSAG. RSAG has no real authority, being largely an informal team of advisors nominated by the RSE. Membership under such terms does not typically require approval, although [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.) mandates IAB approval of RSAG nominees. [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) corrects this situation by disbanding the RSAG, giving the REOC significant authority, and mandating IAB authority for selecting REOC members.
| TOC |
[I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.) does not call for any change in the chartered responsibilities of the IAOC. It does explicitly propose to have the RSE (as the resident editorial and publications expert) join the IAOC when it is reviewing contractor performance, re-issuing of contracts, preparing requests for proposals, and reviewing bids.
| TOC |
V2 Overview gives the Series Editor exclusive direct management over its facilities by assigning him responsibility for overall performance of the Editor. All current regular meetings should be reviewed, and possibly put under RSE management, to avoid any confusion about where Editor directions are coming from.
| TOC |
The following steps to improve the series and its accessibility are based on input from community members and on my own experience and analysis. Unless otherwise stated, these are areas requiring eventual attention, not a list of efforts that the RSE should necessarily engage in immediately. Each will require leadership by the Series Editor to ensure responsiveness, knowledgeable discussion within the community, and reasonable progress towards a consensus solution. Leadership is also necessary to ensure correct prioritization of this type of work, and that all changes work well together.
Because the work of the community is done almost entirely by volunteers, the Series Editor should be careful not to interfere with or replace volunteer activities. Very often the Series Editor will not actually direct various activities but rather will make sure that critical issues are being addressed and that participants are aware of the big picture.
| TOC |
The RFC Style Manual (or 'Guide') is a lightly organized collection of seven web pages on the RFC Editor site. Those include several different documents (one of which is an expired Internet Draft); various parts are redundant; and there is limited information to guide the novice's use of and interpretation of the Manual. One community member mentioned that various parts of the RFC style were a major input to the style guide of his own corporation (a major software developer). His colleagues need to be able to refer to the RFC Style Manual, which they say they cannot do in its present state. Fixing this problem will increase the consistency and stature of the Series.
The Style Manual as it stands is insufficient to direct substitute editors in case of an unexpected break in service. The Manual should be reorganized, consolidated, and updated as necessary. This should include a part-by-part review for currency and accuracy.
Community members have suggested the Manual be divided into two sections: a small, slowly evolving core of 'musts' to be enforced by Editor staff. This core should be kept as minimal and straightforward as possible. It should be augmented by a larger, more quickly developing set of guidelines for authors, possibly in a separate document. The core information should be published as an RFC, while more frequently changing sections (e.g., the abbreviations list) could be left to (or incrementally updated as) web pages.
The Editor does not presently recommend any general style manuals (e.g., The (University of) Chicago Manual of Style) to guide authors above and beyond the RFC Editor Style Manual. The Editor should do so, but, to ensure that the Series does not become stylistically narrow, might better suggest several widely accepted style manuals that authors might refer to than require their adherence to one particular manual.
The above are rough suggestions. General and detailed decisions should be left up to the incoming Series Editor with support from the Editor staff, REOC members, and in concert with the community. The new Series Editor should consider establishing a standing committee comprising knowledgeable people from each of these groups. I see no reason why there cannot be far more direct participation by the community in this effort than in the past.
| TOC |
There is no one place (particularly, not among the RFC Editor web pages) where one can find a definitive description of the processes followed by the Editor, and how the Editor interacts with the Streams. As previously identified, the Procedures Manual, along with the Style Manual, is the core device for ensuring quick guidance of alternate editors in case of an unexpected interruption in service. As with the Style Manual, a comprehensive effort should be undertaken to collect all relevant policies in one place, once again involving staff, committees and knowledgeable community members.
Particular attention should be paid to documenting procedures at the correct level of detail. Many procedures fall near the boundary between common sense, editorial lore, and a need for formal documentation. The Procedures Manual should be designed to permit incremental addition over the years; all participants should guard against adding more detail than is necessary.
| TOC |
Community members frequently assert that the RFC Editor web site is rudimentary, has an old-style look and feel, and needs to be reorganized for clarity. The web site is a key entry point for access to the Series, and especially to facilitate new authors' understanding of how to write an Internet draft on the way to publishing an RFC. Given the community's increasingly international membership, adding support for languages other than English may in time be appropriate.
The Series Editor should consult with the Oversight Committee and the community to explore how the site might be improved, and formulate a plan for doing so depending upon acquisition of resources including volunteers.
| TOC |
The Editor provides an orientation for draft writers during the IETF week that focuses on draft- and RFC-specific issues. Enlarging this orientation to provide general guidance for how to write technical documents could we an efficient was to assist both authors and production center staff. I am not suggesting that the Series Editor personally provide this training, which requires very specific skills. Rather, the RSE should join with the streams to identify if there are efficiencies to be gained by one or more types of such training, and to determine if a plan should be developed for obtaining that training, which can be very expensive to produce. Contracting with an outside training organization is one option.
| TOC |
Our community is constantly becoming more international. Some suggest we may be asked, for example, to improve the ease of participation by non-native English speakers by providing pointers to unofficial translations of RFCs. We may eventually wish to certify such translations as being within certain quality criteria. The RFC Editor’s responsibilities may grow to include ensuring that such requests by community participants (or RFC end-users) are handled expeditiously. If work begins in this area, it should be done in concert with other internationalization efforts, such as support for non-English languages in the RFC Editor web site, as mentioned above.
| TOC |
At present, if one wishes to know the relationships between various RFCs, one has to read the metadata and ‘walk’ from RFC to RFC. Also, despite the enormous body of knowledge in the community, there is no commonly available facility that describes:
Volunteer work in this area is already under way. The Series Editor should informally encourage and support these efforts and investigate whether more significant support should be given.
| TOC |
How to increase the standing of the RFCs and the Series in the academic world is already under discussion. This process may be valuable to continue.
| TOC |
I am told that Digital Object Identifiers (DOIs) have become common in academic publishing, and that citations more and more often require DOIs. We do not presently have any plans to provide URIs (Uniform Resource Identifiers) or DOIs for RFCs. The RSE should begin a process to determine whether there is a need for such facilities, and if so what sort of process should be followed to determine what needs to be done and how to do it.
| TOC |
A significant number of community members have noted that discussion about the ASCII format goes through cycles of intensity. The Series Editor will need to participate in these discussions and attempt to make them productive. One of the identified problems is the limit of ASCII art. Community members tell me that they cannot produce complex mathematical notation using ASCII, which they claim keeps them from publishing certain RFCs (if this is so, then our universality-oriented policy is keeping some RFCs from being created in the first place). Another concern is the impossibility of representing author names that require non-ASCII character sets. The Series Editor and Oversight Committee should survey community thinking on the subject, decide whether and when a comprehensive review should take place, and specify the process(es) that review should follow, while keeping in mind the need for long-term accessibility of archival documents.
| TOC |
| TOC |
A one-third-time appointment is the absolute minimum for the Series Editor position for the appointee to provide ongoing leadership and to represent the Editor and the Series on an ongoing basis.
Additional time is required to discuss, analyze, prioritize, communicate, and guide through to implementation the regular flow of development issues that come to the Editor (exclusive of ongoing document production). Still more time is required to participate in exceptional events, such as community controversies or debates, customer complaints that could result in escalation procedures, or time-consuming external demands. Altogether, these tasks add a minimum of roughly 20%-time, to bring the position to a minimum half-time appointment.
An appointment beyond half-time would be reasonable but is not strictly required. Above that level depends upon the desire by the community for faster or additional Series and Editor development.
These observations are based on the work level analysis below, and are consistent with my sense of the character and scale of the work as I experienced it.
| TOC |
Currently, and consistent with [RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), the RSE regularly participates in (exclusive of TRSE work):
These are activities are structurally required or follow from continuing community interest. Below are rough estimates for some of these activities. For convenience I assume 12 four-week months a year, and represent a week as 2% of a year, and a month as 8.5% of a year (both rounded down slightly). These are well within the accuracy of these sorts of observations.
Regular meetings:
IETF meetings:
3 per year, 1 week per meeting, plus an equal amount of preparation and follow-up time. 1.5 months per year, or 12% time.
RFC Editor weekly meetings:
1 hour each, plus 1 hour of prep and/or follow-up. 8 hours per month (12 days / year), or 6% time.
IAB bi-monthly meetings:
2 hours each, plus 2 hours report preparation time, bi-monthly. 8 hours / month (12 days / year), or 6% time.
Total time, regular meetings:
approximately 25%-time requirement.
See Section 6.3 (Additional responsibilities under V2-Overview), below, for how these values correspond to the anticipated workload cited in [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.).
General Representation and Communication:
E-mail, rfc-interest list, phone conversations, etc:
4 hours/week (24 days/year), or 12 % time.
The span of communications, including email traffic, on which the Series Editor needs to be current, requires a considerable time investment. The RFC Editor is a place where many different activities of the community meet. Recent discussions about the standards process are an example. The RFC Series Editor needs to follow such discussions to maintain general community context, to anticipate impact on the Editor or the Series, and to represent his observations. Preparing for participation in email threads requires a significant amount of time.
Total time, regular meetings and general communications:
this is slightly more than a 1/3 time appointment (37%, which is 25% plus 12%). This is within the range of accuracy of the 1/3 time appointment recommendation above.
| TOC |
Under [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.), time previously required for interaction with the IAB and RSAG will be replaced by interaction with the REOC.
I anticipate that the REOC will eventually meet monthly for one to two hours, but initially, every two weeks. There will also be somewhat more frequent discussions between the RSE and individual REOC members, which I anticipate will depend upon the level of Editor and Series development work. Overall, I expect that the time devoted to upwards reporting will increase slightly compared to past practice.
Major Planning Cycles, Annual and Multi-Year:
In addition to ongoing work there will be annual reviews of Editor performance. Also, every few years there will be major investments of time devoted to reviews of long-term performance of contractors, and constructing new requests for proposals.
Annual reviews of RFC Editor and Publisher:
1 week, or 2% time.
This activity slightly increases the average yearly commitment of the Series Editor, but does not alter my one-third-time recommendation.
End-of-Contract review of performance of Production Center and Publisher:
This item includes joint work with the IAD and IAOC on major reviews, revisions to contracts, creation of new requests for proposals (RFPs), preparation for and participation in bidders conferences, and reviews of bids.
End of Contract Reviews:
4 weeks (although in case of very large changes, time requirements could be much greater). 8% time.
Because the new contract activities occur so irregularly, I do not explicitly include them in the annual baseline. They are better considered as part of project work.
| TOC |
Practically speaking, just two work level ranges are sensible and would be acceptable to a professional: full-time; or a defined level up to and including 50 or 60%.
Increasing the level much above 50% but not up to 100% could be problematic. Few people find themselves able to limit themselves to, for instance, an 80% job; at some point there is a strong tendency for such a position to become full-time. It is commonplace in our industry, and in publishing, for “full-time” professionals to far exceed 40 hours per week. This indicates that once the job’s minimum time requirements begin to exceed ~60% of a nominal 40-hour work week, the community will get much more value for money from a full-time employee.
| TOC |
Learning the Series Editor job will be very time-consuming, depending upon the level of orientation and support provided and the appointees' prior knowledge of the environment. My experience suggests that a relative novice will require approximately 6 months to get up to speed; even someone quite familiar with our environment will take at least several months. I strongly recommend development of an orientation plan, to include multiple orientation meetings (working sessions well beyond getting-to-know-you meetings), walks through all key RFCs, and extensive review of all other relevant documents and processes.
| TOC |
Over the years, the RFC Editor has had progressively narrower scope and authority. After removing any influence over the technical content of RFCs, splitting out the Independent Submissions Editor role, and moving the technical editors into a separate organization, why is an RSE necessary at all?
[RFC5620] (Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” August 2009.), documenting an earlier consensus, mandates an RSE role. My experience in the position has documented (above) significant outstanding management and development issues. Many of these cannot be ignored and, if not managed explicitly, could end up being done in an ad hoc fashion, and quite possibly badly. I present reasons, above and below, why a committee is unlikely to do the job effectively.
Can’t the Production Center Director do the job?
In spite of the excellence of the entire RFC Production Center staff at technical writing, and their understanding of the current state of Editor practice, they have not had prior experience at the sort of work I describe. Furthermore, assigning the RSE role to Production Center management could create a problematic division of their attention and eventually either the planning or the production would suffer. Asking a single person to fill both positions will make it more difficult for the community to observe and assess how matters are being prioritized. Finally, a very significant part of the incoming RSE role will be to review all the editorial and other practices of the Editor to develop a real and complete Style Manual and a real and complete Procedures Manual; someone other than the production staff must do this. Otherwise, the community can have no confidence that the process will provide insurance against breaks in editorial service. Said differently, Production Staff cannot be expected to review themselves, which would be a conflict of interest. And, as described below, the necessary review requires more, and more continuous, attention and focus than can be expected of those volunteers who oversee the RSE.
I emphasize that these are structural observations and in no way any criticism of staff or AMS. All have performed professionally and diligently during my tenure.
Can’t a Community Committee do the Job?
A committee is simply not a good vehicle for discerning and pursuing strategic needs, particularly if the committee has other duties or is made up of members with varied interest. A committee can provide support, guidance and oversight, but cannot do the primary thing this job requires: focus on uncovering Editor issues and driving them to conclusion, in combination, and in a way that improves the long-term performance of the RFC Editor. That means making sense of the entire Editor, its operations, policies and relationship to staff, the community and other community entities. This includes establishing means to ensure no interruption of service. Lessons from management, and past experience in the community, argue that a single professional responsible for making this happen, and for being accountable for it happening, is necessary.
Should the RSE come from the community or should an outsider do the job?
Someone from the community may be able to do the job, but only if qualified as defined above and in [I‑D.v2‑overview] (Kowack, G., Ed., “RFC Editor Model Version 2,” November 2010.). However, significant publications management experience and expertise in not widely found in the community. Furthermore, there is a great opportunity for the community to find an experienced outsider who will drive new thinking and debate. This is far less likely with someone from the community.
Keep in mind that the REOC and IAB, and an anticipated, predictable degree of community participation, will provide a very rich and steady flow of community input on all issues.
After the reductions in the RSE role mentioned above, is there anything left to attract an experienced publications professional?
There can be, if the job is appropriately structured, and properly supported by the REOC, IAB, and the community. The RFC Series is one of the most important technical collections in history. Many qualified professionals would leap at the chance to lead the community in improving the Series and the operation of the Editor. They would also love to learn how and why this amazing Series and innovative community work; this is a real career builder. However, the incoming RSE must understand that their job is to lead the community in discovering, defining, prioritizing, and agreeing on changes, improvements and innovations, and then implementing them. (This, in spite of the confusing terminology of the Editor: the RFC Editor is actually a publisher, the RFC Publisher is actually an archive and access server, and the RFC Series Editor is actually the head of a publications department in which there are four 'editors' not appointed by the Series Editor -- the four stream approvers.) In years past, this might not have been attractive to a publication professional, which would have expected far more control. However, in significant part thanks to the Internet, the world of publications has changed. An example of this is Wikipedia, whose leadership provides an environment for a community of writers and editors, establishes rules, and lets the world of contributors do the rest. However, the role is still somewhat thin compared to the degree of autonomy usually granted to professionals leading this scale of series and sort of effort. Hence, his having authority over the Production Center and Publisher is all the more important; not giving the RSE this authority could preclude attracting strong candidates.
Can a Volunteer to the Job?
Of course it is possible, if the community can find someone qualified and willing to do the job. However, that appears unlikely, for structural reasons. In our community, those who occupy senior positions that require a substantial fraction of their time, such as membership in the IAB or IESG, require substantial support from their employers; this is effectively 'seconding' an employee to the volunteer job. Employers do this because of the strategic value and stature it brings their organizations. This value is often related to the strategic insights and influence that follow from the roles, and such value depends on the Community work the 'seconded' professional does being strategic to the employer. This does not generally apply to editing. Finding an organization in the publications world that would support a 'seconding' is unlikely. Conclusion: Seeking volunteers, may be a time and energy-consuming dead-end. It could be done on a limited basis before reverting to seeking a paid professional.
There is another issue. This job is complex, difficult, rich with personalities and opinions. Paying someone to do it may be required for him to insure continuity under the challenges and pressures that will invariably occur.
What keeps the Series Editor from having undue influence or 'capturing' the community and making them dependent upon him?
First, a major goal of the RSE is to ensure that no one in the Editor, or outside the Editor, can have undue influence, and that includes him. When writing the documents that ensure quick provision of alternate editing resources, he must also document his part in those processes and decisions. The REOC should remain diligent about this his supporting this requirement, and they have tools at their disposal to be sure they can do so. First, the RSE will not have any control of his own over Editor resources; my recommendations require that he not come from any of the other contractors of Editor services. Second, they should have enough expertise to review the RSE's work to ensure it is complete. Third, the recommendations stipulate a 3-year term of office; long enough to learn the job and get good at it, but not long enough to insert himself irreversibly into various relationships, and short enough that the clock will run out on its own in a reasonable amount of time. Finally, the RSE is a planning and oversight job. Except for brief intervals when the RSE is critically important to development of some activity, they should not be important to any real-time events during which they could 'squeeze' the community. Professionals being very good at their jobs, and providing great value to the community, has nothing to do with 'capture'. Using that, or other values, to gain improper results of any form in defiance of community will, does.
| TOC |
None.
| TOC |
None.
| TOC |
| [I-D.v2-overview] | Kowack, G., Ed., “RFC Editor Model Version 2,” I-D draft-kowack-rfc-editor-model-v2-overview-00, November 2010. |
| [RFC5620] | Kolkman, O. and IAB, “RFC Series Editor Model (Version 1),” RFC 5620, August 2009. |
| TOC |
| Glenn Kowack | |
| Riveronce | |
| Email: | glenn@riveronce.com |