Skip to content

Instantly share code, notes, and snippets.

@darcyclarke
Last active October 16, 2019 15:51
Show Gist options
  • Save darcyclarke/dd77c8f1fb895c5063bf39723a27d0fa to your computer and use it in GitHub Desktop.
Save darcyclarke/dd77c8f1fb895c5063bf39723a27d0fa to your computer and use it in GitHub Desktop.
Package Maintenance: Support [Draft]

Package Maintenance: Support [Draft]

Table of Contents:

Why?

The currently drafted proposal for a support field[1] is very large in scope, introducing a number of net-new concepts, making it hard to gain consensus.

What?

I've created an updated proposal that looks to split out the three primary areas of concern (ie. Backing Maintainers, Maintenance Level & Activity & Supported Environments & Targets) in the hopes of moving the conversation forward. This proposal reflects smaller package.json-specific changes.

Things that should be kept in mind are:

  • Why does this exist?
  • What is the solution?
  • How is that solution implemented?
  • Who is the intended audience or implementator?

How?

Funding Maintainers

Why?

Package maintainers want to clearly indentify how their software is currently, or could be in the future, supported monetarily.

What?

  • See Prior Art: Funding Maintainers
  • Provide a means to identify the type of backing
  • Provide a means to reference existing backers or funding opportunities

How?

  • Add a funding field to package.json
    • supports a string URL or object with...
    • keys that support arbitrary string identifiers (ex. "sponsor", "sponsors", "foundations", "donations", "bounties", "contributors", "patrons" etc.)
    • values that represent a string URL or an array of URLs

Examples:

{
  ...
  "funding": "https://www.patreon.com/my-account"
  ...
}
{
  ...
  "funding": {
    "foundations": "https://openjsf.org/"
  }
  ...
}
{
  ...
  "funding": {
    "corporations": [
      "https://microsoft.com/",
      "https://google.com/"
    ]
  }
  ...
}
{
  ...
  "funding": {
    "sponsor": [
      "https://github.com/users/my-account/sponsorship",
      "https://opencollective.com/my-account",
      "https://www.patreon.com/my-account"
    ],
    "sponsors": "https://github.com/users/my-account/sponsorship#sponsors",
    "contributors": "https://opencollective.com/my-account#section-contributors",
    "patrons": [
      "https://patrons-site-one.com/",
      "https://patrons-site-two.com/",
      "https://patrons-site-three.com/"
    ]
  }
  ...
}

Who?

  • npm intends to ship support for the funding field in npm v6.13
    • Adding notification at the end of output for npm i (ex. 23 packages are looking for funding. Run "npm fund" to find out more.)
    • Adding --no-fund flag to opt-out of this ouput when installing
    • Adding npm fund subcommand which will: open the URL (string) OR list the funding references (object)
    • Adding a visual representation for the funding field/value on package pages at npmjs.com

Maintenance Level & Activity

Why?

Package maintainers want to communicate their availability & a response time they can accomodate.

What?

How?

  • Add a support key to package.json which supports a string URL

Example:

{
  ...
  "support": "https://unpkg.com/browse/my-package/SUPPORT.md",
  ...
}

Who?

  • npm is prepared to display this link on package pages while considering other options/additions to the Packument object going forward.

Supported Environments & Targets

Why?

Package maintainers often want to maintain a subset of their published software &/or the environments in which that software functions.

What?

How?

  • Add a support key to package.json which supports a string URL

Example:

{
  ...
  "support": "https://unpkg.com/browse/my-package/SUPPORT.md",
  ...
}

Who?

  • npm is prepared to display this link on package pages while considering other options/additions to the Packument object going forward.

References

Prior Art: Funding Maintainers

Prior Art: Maintenance Level & Activity

  • Open Source licenses explicitly outline software as being distributed "as-is"
  • Maintenance expectations have been & are considered "best effort"
  • Maintenance expiry is communicated through deprecation
  • Help information is communicated through the bugs field (typically an issue tracker reference)
  • Maintainer information is communicated through author, contributors, maintainers & owner[10]

Prior Art: Supported Environments & Targets

  • Supported environments are communicated through cpu, os & engines values

Work & Conversations

  1. PM WG: "Document support levels" Draft
  2. PM WG: "Document support levels" Blog post to announce
  3. PM WG: "Document support levels" Blog post to validate
  4. PM WG: support field license Issue
  5. PM WG: "Future direction of support field" Issue
  6. npm: sustainability PR
  7. npm: support PR
  8. thanks: "Read URL from package.json" Issue
  9. funding: "Collaborate with the PM WG" Issue
  10. Differences between: "author", "contributors", "maintainers" & "owner"
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment