Just a few choice bits. On Tue, May 26, 2026, at 17:32, Brian E Carpenter wrote: > Yes, although iirc the RPC allows one author to explicitly delegate > AUTH48 to a co-author.
That's not something I'd encourage them to keep in light of this perspective. >> Section 3 talks about contributors making smaller contributions, but the >> example of withdrawal in Section 2 and the entirety of Section 4 makes that >> a lie. Contributors are simply people who made notable contributions to the >> document. The key difference is that they don't claim ownership of the >> content of the document. > > Yes, but I don't think there's much in the section 3 text that is > affected by that. It very strongly suggests that the line between contributor and author is the *size* of contributions, which is not the case. >> Section 4 would need significant reframing in light of this. The editor >> role carries a weaker notion of responsibility than an author. > > I think that's debatable. We're not talking about a copy editor or a > technical editor. I don't think an RFC2418-style editor has any less > responsibility than their co-authors. On reflection, I have to agree. A possible distinction then is whether there is an expectation that the person in the "editor" generated substantial portions of text. I'm listed on documents as editor where I generated most of the text, so I don't know if that holds. I do believe that the editor role was assigned specifically so there would be a lower degree of "ownership". Stating that editor implies the same responsibility as authors, but not necessarily original authorship of content, is probably the right way to handle this. Though I think you need to acknowledge that someone might be designated as editor rather than author for multiple reasons. >> Section 6 talks about previous versions. The responsibility razor here is a >> useful tool. Previous authors who are willing to assume responsibility for >> the new version should be listed as authors. Those who do not should be >> listed as contributors. (This is a very clean approach, but there is always >> room for finding mutually-agreeable outcomes, as the draft notes.) > > That's certainly true for the IETF stream I'm not 100% certain for the > other streams. I suggest that we set the core policy as I indicated and rely on the per-stream policy override clause to cover any divergence from that. -- rswg mailing list -- [email protected] To unsubscribe send an email to [email protected]
