[Standards] XEP Authors

Kevin Smith kevin.smith at isode.com
Fri Jun 9 13:35:22 UTC 2017


On 9 Jun 2017, at 14:08, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 
> On 6/9/17 5:37 AM, Philipp Hancke wrote:
>>> However, I don't think this is particularly contentious. We have lots
>>> of documents for which one of the "Authors" hasn't made any input for
>>> several revisions. 
>> 
>> See the Jingle XEPs for example. I doubt the Google folks listed as
>> authors have looked at this spec in a _decade_ (and at least one of them
>> has left google).
> 
> True.
> 
>> Removing someone who did a lot of work on a specification feels bad so
>> people tend to avoid doing.
>> 
>>> I see three cases for moving Authors to a "Previous
>>> Authors" section:
>>> 
>>> a) This legal issue, which might expose authors and their employers.
>>> By clearly marking that an author is not current, it should address
>>> the concerns of (for example) Cisco's legal department.
>>> b) The case where an Author discovers their name still against a XEP
>>> and is concerned that the XEP misrepresents their views. I believe we
>>> have had such cases, and although obviously Authors can already
>>> request their removal in entirety, this also removes all
>>> acknowledgement for previous hard work.
>> 
>> Yes, I've had that situation with Peter once in the past. Resolved
>> happily in a subsequent revision and we talked a lot thereafter :-)
> 
> Indeed, many thanks to you.
> 
>>> c) The case where Authors are simply unresponsive to concrete
>>> proposals and stall the standards process. While Council can again
>>> remove an Author entirely, this often seems like a nuclear option - as
>>> if Council is punishing, rather than simply moving things along.
>>> 
>>> I see, on the other hand, no advantage to *not* having a Previous
>>> Authors section which properly acknowledges those who have put
>>> considerable effort into the document. I'm also happy to list these at
>>> the top of the document, maybe just like:
>> 
>> +1 -- this seems to work well for the W3C. It is also a bigger
>> acknowledgement than just adding them to the list of people who
>> contributed.
>> 
>> Also thank you for taking the time to raise this!
> 
> IETF RFCs have a "Contributors" section in which previous authors (and,
> for instance, those who have written a significant block of text) are
> acknowledged. This is different from the "Acknowledgements" section. See
> for instance the recently published RFC 8141:
> 
> ###
> 
> Acknowledgements
> 
>   Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha
>   Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean
>   Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian
>   Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other
>   participants in the URNBIS working group for their input.  Alfred
>   Hoenes in particular edited an earlier draft version of this document
>   and served as co-chair of the URNBIS working group.
> 
>   Juha Hakala deserves special recognition for his dedication to
>   successfully completing this work, as do Andrew Newton and Melinda
>   Shore in their roles as working group co-chairs and Barry Leiba in
>   his role as area director and then as co-chair.
> 
> Contributors
> 
>   RFC 2141, which provided the basis for the syntax portion of this
>   document, was authored by Ryan Moats.
> 
>   RFC 3406, which provided the basis for the namespace portion of this
>   document, was authored by Leslie Daigle, Dirk-Willem van Gulik,
>   Renato Iannella, and Patrik Faltstrom.
> 
> ###
> 
> There are several reasons to pursue the path that Dave has suggested,
> even without legal speculation or engaging counsel that we don't have.
> We've previously suggested adding a list of Maintainers, but Authors
> (people who are responsible now) and Contributors (people who might have
> authored or contributed significantly to the document before) feels cleaner.
> 

I like the contributors idea. It avoids the “Someone submitting a one-off significant patch, so should be added do Authors even though they’ll never do anything again” issue that we sometimes see.

/K



More information about the Standards mailing list