Tarek Ziadé wrote:
> 
> Tarek Ziadé <ziade.tarek@gmail.com> added the comment:
> 
>> We already have authors and maintainers (which causes confusion), 
>> adding yet another field for contributors is overkill,
> 
> Not on the Metadata side though. That's only on setup() side. The
> resulting metadata only contains "Author" and "Author-email", and it's
> calculated using 'author' *or* 'maintainer' arguments. Meaning that when
> you fill both, one is lost. (and leading to the current inconsistency).
>
> So being able to have several Authors (not yet another field, an
> existing one, but multi-valued) and an "authors" argument would fix this
> inconsistency since we would be able to keep both.
> 
> This is not a big change on the metadata format, it just means that we
> can have extra "Author:" lines, so it's backward compatible.
> 
> OTHO, deprecating "maintainer" and "maintainer_email" on setup() side,
> and making it clear that there's only one Author and one email could
> work too.

In order to clear up the inconsistency with maintainer not
being a possible meta-data field, I think "Maintainer" should
be added to the meta-data. Dito for "Maintainer-EMail".

Regarding making the meta-data fields multi-valued, you have
to be aware that when parsing the meta-data using an rfc822
style module, code assuming that only one Author field
exists, will return (just) one of the available fields and
it's not at all clear which.

I still believe that we're better off with a single Author
field using comma delimited names, e-mail addresses, etc.

Adding "authors" as new keyword argument to setup() isn't
going to make things more consistent, only more complex
code-wise, so I don't think it's worth the trouble.