Re-introduce 'Maintainers' (#1485)

pep-0621.rst

@@ -246,10 +246,10 @@ expressions. If such support comes to fruition and a tool can
 unambiguously identify the license specified, then the tool MAY
 fill in the appropriate trove classifier.
 
-``authors``
-'''''''''''
+``authors``/``maintainers``
+'''''''''''''''''''''''''''
 - Format: Array of inline tables with string keys and values
-- `Core metadata`_: ``Author``/``Author-email``
+- `Core metadata`_: ``Author``/``Author-email``/``Maintainer``/``Maintainer-email``
   (`link <https://packaging.python.org/specifications/core-metadata/#author>`__)
 - Synonyms
 
@@ -265,7 +265,10 @@ project. The exact meaning is open to interpretation — it may list the
 original or primary authors, current maintainers, or owners of the
 package.
 
-The field accepts an array of tables with 2 keys: ``name`` and
+The "maintainers" field is similar to "authors" in that its exact
+meaning is open to interpretation.
+
+These fields accept an array of tables with 2 keys: ``name`` and
 ``email``. Both values must be strings. The ``name`` value MUST be a
 valid email name (i.e. whatever can be put as a name, before an email,
 in `RFC #822`_) and not contain commas. The ``email`` value MUST be a
@@ -273,18 +276,14 @@ valid email address. Both keys are optional.
 
 Using the data to fill in `core metadata`_ is as follows:
 
-1. If only ``name`` is provided, the value goes in ``Author``.
-2. If only ``email`` is provided, the value goes in ``Author-email``.
+1. If only ``name`` is provided, the value goes in
+   ``Author``/``Maintainer`` as appropriate.
+2. If only ``email`` is provided, the value goes in
+   ``Author-email``/``Maintainer-email`` as appropriate.
 3. If both ``email`` and ``name`` are provided, the value goes in
-   ``Author-email``, with the format ``{name} <{email}>``.
+   ``Author-email``/``Maintainer-email`` as appropriate, with the
+   format ``{name} <{email}>``.
 
-This use of the field is a slight deviation as the core metadata also
-supports a ``Maintainer`` field which goes unused by this PEP. The
-authors of this PEP felt this field was ambiguous and never clearly
-defined. Other ecosystems have selected "author" as the term to use.
-As such, it was decided it would be better to standardize on
-``Author`` in the core metadata as the place to list people
-maintaining a project.
 
 ``keywords``
 ''''''''''''
@@ -442,10 +441,12 @@ Example
   license = {file = "LICENSE.txt"}
   keywords = ["egg", "bacon", "sausage", "tomatoes", "Lobster Thermidor"]
   authors = [
-    {name = "Brett Cannon", email = "brett@python.org"},
     {email = "hi@pradyunsg.me"},
     {name = "Tzu-Ping Chung"}
   ]
+  maintainers = [
+    {name = "Brett Cannon", email = "brett@python.org"}
+  ]
   classifiers = [
     "Development Status :: 4 - Beta",
     "Programming Language :: Python"
@@ -618,6 +619,20 @@ brought up as to how exactly authors differed from maintainers. As this was
 never clearly defined and no one could come up with a good definition, the
 decision was made to drop the concept of maintainers.
 
+Drop ``maintainers`` to unify with ``authors``
+----------------------------------------------
+As the difference between ``Authors`` and ``Maintainers`` fields in
+the `core metadata`_ is unspecified and ambiguous, this PEP originally
+proposed unifying them as a single ``authors`` field. Other ecosystems
+have selected "author" as the term to use, so the thinking was to
+standardize on ``Author`` in the core metadata as the place to list
+people maintaining a project.
+
+In the end, though, the decision to adhere to the core metadata was
+deemed more important to help with the the acceptance of this PEP,
+rather than trying to introduce a new interpretation for some of the
+core metadata.
+
 Support an arbitrary depth of tables for ``project.entry-points``
 -----------------------------------------------------------------
 There was a worry that keeping ``project.entry-points`` to a depth of 1 for sub-tables