Suggestion: Display a projects business model about package-maintenance HOT 8 CLOSED

A badge isn’t programmatically usable; perhaps a package.json field, like the spdx-compliant license field, would be more useful?

from package-maintenance.

I'm not necessarily fond of having this in a badge, mainly because it's a lot of information to convey. However +1 to disclosing this information explicitly.

from package-maintenance.

related: https://maintained.tech and http://unmaintained.tech

and agreed on utility of a badge being limited and non-programmable

from package-maintenance.

perhaps a package.json field, like the spdx-compliant license field, would be more useful?

Agreed. This enables tooling like projectz to take that field and render it as a badge as well as a readme section, as well as "business model" / "maintenance" linters to scan deps for unsupported packages.

Will need to have a discussion of what the different tiers should be. The one's in the OP I think are good enough, but are probably likely to need revision.

from package-maintenance.

I suggested something similar for a "support statement" in #119. I was thinking of support levels, but the "business model" is a different dimension from what level of support is targeted. I might not call it business model but instead maybe "sponsorship".

So I think we may want 2 new package.json entries:

• support level (see #119 (comment))
• sponsorship

from package-maintenance.

I'm also thinking that this fits into the "baseline" practices being discussed in #119. A baseline practice would be to state your level of sponsorship and then we define/maintain the list to make it easier for the module owners to choose. We might also want to talk to npm to see if we can have the default which is generated by npm init be "individual" supported.

Another level to add to the list might also be project supported (or maybe foundation?), with the ability to list that project. This would be useful, for example for modules that are under the 'nodejs' org and for modules that are part of the JavaScript foundation.

from package-maintenance.

First cut at a baseline practice which incorporates this suggestion: #139

from package-maintenance.

This has been addressed in #220

Closing
Feel free to reopen if we miss some point

from package-maintenance.