22. Clarify author field Proposal:
I would like to see some clarification of what an author is, especially since the numbers of distros * that change ownership * that use collaboration * that use shared maintenance * that cycle releasers frequently is rising. Is it the original author (PAUSE jargon »first-come«)? Is it someone who contributed code? Is it the original author even though he informally abandoned the distro? Is it the original author even though he formally transferred or gave up ownership? Is it a maintainer (PAUSE jargon »co-maint«)? ([https://rt.cpan.org/Dist/Display.html?Name=DBIx-Class DBIx-Class has 20 maintainers], and apparently this maintainer information is generally not available in any other way.) Is it the one maintainer of the current maintainers of the distro who released this distro? (A specific distro can only have exactly one releaser, e.g. RIBASUSHI/DBIx-Class-0.08109.tar.gz.) Comments: * Should the author field be split up into finer grained roles? I don't think so, but keep in mind that the author field is automatically populated by build tools from the Pod of a module, and it should DTRT with respect to what the author field meant/means. (Funny bug: remember [http://search.cpan.org/diff?from=Text-Balanced-2.01&to=Text-Balanced-2.02 when Alias took over Text-Balanced]?) * I concur on the need for improved meaning. Since META.yml is aimed at machine to machine and is not supposed to be read by humans normally, something like maintainer or release manager or the uploader is potentially the best option here. Assuming we can also lock it down as an email address, having it defined as "who to spam for problems with this module" might be useful AdamKennedy * To stay backward compatible and require no toolchain changes, I propose [http://scsys.co.uk:8001/33086 this Pod] as a good practice. -- Daxim * From inside a distribution directory, there is no way to know who the uploader was or where it lives on CPAN. Should 'author' be the CPANID of the person releasing it? I'm not convinced it should, but want to put it out there for consideration. (Yes, it means changing how things are auto-populated today.) (Dagolden) * I think there are two things you want to know about the distribution: who to contact with questions or bugs (in the event that there is no bugtracker) and who holds the copyright. Copyright gets complicated quickly, and is probably best described to humans apart from the case in which a single "license" entry works. Author is probably best as "contact point." One or more people to contact makes sense, and I see no real reason to distinguish between them. rjbs * I feel the 'author' field should contain a list of the contributors to the code within. Perhaps an additional field ('maintainer'?) could be added to the mix, using a PAUSEID to identify the release manager/current maintainer. (Barbie) * What would a list of contributors actually be consumed by, and what functionality would it drive? The "contact" definition can trigger various "Email the author" type behaviours, but I don't see what useful features a list of contributors might drive beyond the list in the POD --Adam K * Picking up on rjbs' point -- perhaps we should follow Perl 6 on this and rename the field to 'auth', short for either 'author' or 'authority' and clarify that it's a contact person, not a copyright holder (Dagolden)
