[Distutils] Simplify 426: Deprecate Author-email and Maintainer-email

[anatoly techtonik]

On Wed, Apr 24, 2013 at 7:54 PM, Donald Stufft <donald at stufft.io> wrote:

>
> On Apr 24, 2013, at 12:42 PM, Donald Stufft <donald at stufft.io> wrote:
>
> >
> > On Apr 24, 2013, at 11:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> >
> >> On Thu, Apr 25, 2013 at 12:45 AM, Daniel Holth <dholth at gmail.com>
> wrote:
> >>> Keep in mind that this is the structured index metadata, which is only
> >>> used to grab requirements (for end users, who usually don't need the
> >>> other information at all) and used to generate cheese shop web pages.
> >>> AUTHORS.txt works when you don't need an automatic "email the author"
> >>> button. Or the project's github information etc.
> >>>
> >>> Someday the JSON version of the metadata will certainly make all these
> >>> fields a little nicer to parse though.   Maybe
> >>>
> >>> "authors" : [{'name':'bob', 'email':'bob at example.org'}]
> >>>
> >>> The author/maintainer distinction will stay.
> >>
> >> FWIW, the current draft of PEP 426 has this note:
> >>
> >> .. note:
> >>
> >>   This section currently mimics the flat layout used in past metadata
> >>   versions. Perhaps it would be better to switch to a different format
> >>   closer to that used for the project URL field::
> >>
> >>       "contacts": {
> >>               "author": "\"C. Schultz\" <cschultz at example.com>"
> >>               "maintainer": "\"P. Patty\" <ppatty at example.com>"
> >>           }
> >>
> >> So yeah, I'm not particularly happy with the current structure for the
> >> contact metadata either, but it's a *long* way down my priority list
> >> of problems to address in the next draft. (My aim to get that posted
> >> last week proved to be overly optimistic. Because this next update is
> >> the key-value -> JSON-compatible structured metadata switch, it's hard
> >> to post a partial update and still have it even vaguely readable)
> >>
> >> Cheers,
> >> Nick.
> >>
> >> --
> >> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> >> _______________________________________________
> >> Distutils-SIG maillist  -  Distutils-SIG at python.org
> >> http://mail.python.org/mailman/listinfo/distutils-sig
> >
> >
> > Looking at other languages they all seem to accept N number of "authors"
> or
> > "contributors". Possibly something like that would be a good to do.
> >
> > -----------------
> > Donald Stufft
> > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372
> DCFA
> >
> > _______________________________________________
> > Distutils-SIG maillist  -  Distutils-SIG at python.org
> > http://mail.python.org/mailman/listinfo/distutils-sig
>
>
>
> To be specific, here's what node.js does
>
> They have an Author field, who represents the primary author of the
> package,
> and then a contributors field that accepts a list of people who have
> contributed
> to the package. NPM will also automatically fill this out if left blank by
> using an
> AUTHORS file assuming the file has 1 per line and each line is in the
> format
> of Name <email> (url).
>
> Ruby has an authors field which is a list of all the authors.


I see it this way. There are four user stories. In all three author field
is an id of:
1. (copyright)   software authors (collective team or single-person)
2. (credits)      contributors (people who helped)
3. (publishing) package maintainers (people who port stuff to different
systems)
4. (support)     software maintainers (contact points)

I guess the good rule is not overengineer the stuff. We can formalize
everything endlessly and will get XHTML in the end. I prefer practical
HTML5 approach where the data is directed by a user story. Every change
needs an existing user who has requirements and data format should cover
this specific user's story without making any speculations and assumptions
about future use.

To reach the consensus in this discussion, I guess we all agree that roles
in software projects may differ greatly. Even the 4 user stories listed are
not enough to give proper credits to all people involved. I guess we can
reach consensus stating that maintainers of packages in Python world are
not common - authors or contributors package stuff themselves. PyPI is not
Linux distribution where package maintainers play a significant and
different role. So the "author"+ and "contributor"* fields seem to be
reasonable minimum core.

Do we all agree on that minimum as the first step?

Now about the contents. Only Lennart expressed opinion that separate email
may be useful because it forces people to supply this email. If emails were
obligatory, we could consider this point, but my IMO is that this it is not
an reason to increase complexity of the system.
http://www.youtube.com/watch?v=rI8tNMsozo0

I like the ability to supply URL in the Author/Contributor field. It can be
used to link to the project specific way of listing people involved
(including GitHub pages). But for now I'd not formalize it and considered
as an optional feature. Just listed somewhere. I'd like not to formalize
the contents of this field at all leaving the recommendation to supply
content in "name[ email][, optional stuff]" format. Can we reach a
consensus on that?
-- 
anatoly t.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130425/9684fc3b/attachment-0001.html>