last call "On Authors, Contributors, Editors, and overload."

Hello -

This past autumn, a discussion started regarding the need to clarify
terms and responsibilities for Authors, Contributing Authors, Editors,
and Contributors (see
http://permalink.gmane.org/gmane.ietf.rfc.interest/2395 for the original
discussion).  Olaf drafted a policy statement, collected feedback, and
now we'd like to give this final blessing and close out the issue.

The text as it stands now is below.  For those of you who have been
tracking the conversation and want the short, short version, there is a
diff at the bottom of this message.

Final substantive comments are welcome through 17-Jan-2012.

-Heather Flanagan (RFC Series Editor)

-----------


On Authors, Contributors, Editors, and overload.


The specific policy is as follows:

* Headers, Addresses section, AUTH48: the 1:1:1 mapping

  A small set of names, with affiliations, may appear on the front
  page header. These should be the lead author(s) or editors; those
  who are most responsible for the actual text. Below we will refer to
  these as "AUTHORS" and "EDITORS" (all caps)

  The AUTHORS or EDITORS that appear on the front page header all need
  to sign-off during AUTH48 and are the primary contacts in case
  follow-up is needed. Hence they are the ones that are listed in the
  RFC metadata and the ones that are listed in the Authors' or
  Editors' Addresses section. We call this the 1:1:1 mapping. It is
  not subject to negotiation although the RFC Editor might make
  exceptions e.g. during the AUTH48 process.

  Also see: http://www.rfc-editor.org/policy.html#policy.authresp

  If there are more than five AUTHORS or EDITORS stream-approval is
  required.

* AUTHORS or EDITORS

  The designation AUTHOR or EDITOR is one that is made by the
  individuals themselves.


* Contributing Authors

  An RFC may include a Contributing Authors section, listing those
  contributors who deserve significant credit for the document
  contents.

  The Contributing Authors section is intended to provide a level of
  recognition greater than an acknowledgment and nearly equal to
  listing on the front page.

  The choice of either, both, or none of Contributing Authors and
  Acknowledgment sections in a particular RFC depends upon the
  circumstance. That choice is primarily based on conventions within
  a stream and often suggested by the AUTHORS' or EDITORS'.

  The format and requirements of the Contributing Authors section are
  the same as the Authors' Addresses.

  If the Contributing Authors section is used, then it is likely that
  AUTHORS are actually EDITORS. In that case the Authors' Addresses
  section could be named Editors' Addresses. The RFC Editor does not
  enforce such guidelines, but may ask for clarification.

  If an EDITOR is also a contributing author, her name may appear in
  the Contributing Authors section as well, without the 'editor'
  designation.

* Contributors

  As an alternative to the strict-format "Contributing Authors"
  section RFC writers may opt to use a Contributors section. The
  Contributors section may contain free floating text and is also
  intended to credit major contributors to the content.

* Acknowledgements

  The body of an RFC may include an Acknowledgements section. An
  Acknowledgments section may explain scope and nature of
  contributions. It may also specify affiliations.

* Exceptions

  The RFC Editor may grant exceptions to these guidelines upon a
  specific request from the stream approval body (e.g. the IESG) or in
  other exceptional circumstances.



During the discussion of this policy Joe Touch provided

* Acknowledgments are to provide credit to those who gave feedback, or
  for specific ideas - for those who did not contribute extended text.

* Contributors are to provide credit for those who contribute extended
  text, as is often the case with large FAQs or BCPs.

* Contributing Authors is a cookie to those who were left off the
  Author list due to a process issue.





Background and motivation


When the RFC Editor refers to 'AUTHORS' or 'EDITORS', we mean exactly
the set of names listed on the first page of an RFC. These people are
considered to be equally responsible for the contents of the
document. AUTHORS will be asked to read and approve the RFC before
publication and will be the persons that have their contact addresses
listed for clarification, comments, suggestions, or questions from 3rd
parties e.g. on the validity of errata, or on the use of text
fragments beyond that licensed by the IETF trust. This contact
information will occur in the Author's Address (or Authors' Addresses)
section at the end of an RFC.

The IESG and IETF have ratified a policy of limiting the number of
AUTHORS listed in the first page header of an RFC. Objections to huge
author lists are both practical and ideological. The practical issues
have to do with the long-existing RFC formatting conventions that do
not comfortably handle large author lists. Ideological objections stem
from the Internet community's tradition of individual rather than
corporate action and responsibility. For instance, some might see a
list of 17 authors on one RFC as motivated by a desire for
name-dropping, which would be inappropriate in the IETF/RFC context.
If there is a desire to demonstrate how many people or companies are
interested in this spec, a simple acknowledgment section can
accomplish the same thing, without Author Overload.

The Internet community's conventions for RFC authors are one of the
distinctive features of the IETF culture. Most standards bodies
publish anonymous standards, whereas we attach the names of real
people, who get both credit and blame, to our specifications. (This is
probably a result of the historical beginnings of the IETF in the
academic research community.) The person(s) who actually write a
document take responsibility for it, even though there may be a large
working group of several hundred people who potentially contributed to
it. When there are a number of significant contributors, there is
usually a single person tasked with integrating the results into a
single document; that person may be listed as "Editor", with
acknowledgments for the other contributors.

There is no rigid limit on the size of this set, but there is likely
to be a discussion if the set exceeds five AUTHORS, in which case the
right answer is probably to list one, or two, EDITORs.  For instance,
when there are many contributors, the best choice will be to list the
person or (few) persons who acted as document editor(s) (e.g.,"Tom
Smith, Ed.").


$Id: authors-policy.txt,v 1.6 2012/01/03 19:04:24 olaf Exp $

-----------------------------------------------------------------------
Diff

RCS file: RCS/authors-policy.txt,v
retrieving revision 1.5
diff -r1.5 authors-policy.txt
20c20,22
<   not subject to negotiation.
---
  not subject to negotiation although the RFC Editor might make
  exceptions e.g. during the AUTH48 process.

44,45c46,47
<   circumstance. That choice is primarily an AUTHORS' or EDITORS'
<   decision.
---
  circumstance. That choice is primarily based on conventions within
  a stream and often suggested by the AUTHORS' or EDITORS'.
79a82,96
During the discussion of this policy Joe Touch provided

* Acknowledgments are to provide credit to those who gave feedback, or
  for specific ideas - for those who did not contribute extended text.

* Contributors are to provide credit for those who contribute extended
  text, as is often the case with large FAQs or BCPs.

* Contributing Authors is a cookie to those who were left off the
  Author list due to a process issue.





81a99

100c118
< list of 17 authors on one RFC as motivated by a desire for corporate
---
list of 17 authors on one RFC as motivated by a desire for
102,104c120,122
< If there is a desire to demonstrate how many companies are interested
< in this spec, a simple acknowledgment section can accomplish the same
< thing, without Author Overload.
---
If there is a desire to demonstrate how many people or companies are
interested in this spec, a simple acknowledgment section can
accomplish the same thing, without Author Overload.
127c145
< $Id: authors-policy.txt,v 1.5 2011/09/20 12:21:16 olaf Exp $
---
$Id: authors-policy.txt,v 1.6 2012/01/03 19:04:24 olaf Exp $
__________________________________

_______________________________________________
rfc-interest mailing list
rfc-interest@...
https://www.rfc-editor.org/mailman/listinfo/rfc-interest