Skip to content
This repository has been archived by the owner on Jul 10, 2018. It is now read-only.

What is the distinction between author and maintainer? #133

Open
ilg-ul opened this issue Feb 28, 2017 · 3 comments
Open

What is the distinction between author and maintainer? #133

ilg-ul opened this issue Feb 28, 2017 · 3 comments
Labels

Comments

@ilg-ul
Copy link

ilg-ul commented Feb 28, 2017

the package.json page mentions at a certain point:

npm also sets a top-level "maintainers" field with your npm user info.

I could not find any other reference to "maintainer". where are maintainers defined?

the "author" field is also defined very loosely:

The "author" is one person

what does the "author" field mean, the person who created the package or the person who created the source files distributed in the package?

my special case is that I have some source files created by someone else (SEGGER GmbH to be exact), distributed under an open source license, that I want to pack in an npm package.

SEGGER explicitly agreed for the sources to be redistributed, and they obviously want to be attributed all rights, so the name, web address and email address must be mentioned correctly, but they did not ask to receive support requests related to this package on their email address.

my understanding of "authors" is that it is the package author, and it should define the person who is responsible for maintaining the package, and as such respond to possible support requests.

in this context, in my package I filled in "author" with my contact address, and I used SEGGER contact details to fill in the first person in the "contributors" array.

if the "author" field really means the person who originated the content, then we also need an official way to explicitly define the "maintainer".

suggestions:

  • clarify the distinction between author and maintainer in the documentation
  • eventually add a new "maintainer" field to the package.json file, with the same syntax as "author"
@ilg-ul
Copy link
Author

ilg-ul commented Mar 2, 2017

@isaacs, since this is a bit political, could you help?

@isaacs
Copy link

isaacs commented Mar 8, 2017

The "author" field in package.json is user-supplied metadata used for no purpose but for the publisher of the package to indicate the person who wrote the package. (Originally? Primarily? Not specified. Ask the publisher what they meant.)

The "contributors" field in package.json is user-supplied metadata used for no purpose but for the publisher of the package to indicate the people who contributed to the package. (Contributed code? Docs? Ideas? Not specified. Ask the publisher.)

The "maintainers" field in the top-level of the registry metadata (ie, not versioned) is the npm-controlled list of the npm usernames of the people with permission to write to that package. This can be modified via the npm owners command. (Confusing, I know.)

The "maintainers" field in a per-version metadata in the registry is a copy of the top-level "maintainers" field at the time that version was published. (Ie, it is a snapshot at time of publication of that specific version.)

The "_npmUser" field in the per-version metadata in the registry is the username of the authenticated account who wrote that version of the package into the registry. (Ie, it's "the account that did the publishing" for that version.) The "_npmUser" MUST always be one of the individuals listed in that version's "maintainers" list, or else it's a big serious WAT.

The "owner" can mean one of two things. Either it is synonymous with "maintainer" (ie, "people who have access to publish"), or in the case of packages that are maintained by an org, or @scoped packages belonging to a username, it's the scope (username or organization) that manages the access control for that package. For example, if the @foocorp package owns @foocorp/blerg then that means that the admins of the @foocorp org can assign read and read-write privileges to that package.

I hope this helps clear it up somewhat. Language is hard, and naming overlapping concepts in unambiguous ways is next to impossible, especially when things evolve over time to support use cases that were not anticipated at the time of their creation.

@ilg-ul
Copy link
Author

ilg-ul commented Mar 8, 2017

Thank you, Isaac.

Language is hard, indeed, but finally is a convention. Since you took the time to reply, perhaps these definitions could find a way to the documentation pages, to help others abide by this convention.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

4 participants