Package-maintenance: Blog post to get broader feedback on Support info for packages

[mhdawson]

Write blog that will

• Set the context/background for the issue being addressed.
• Identify and explain the contentious discussion points and how we've come to what is currently in the document.
• Highlight what's in the info, and ask people to give feedback that we can use to refine before we move it out of draft.

@darcyclarke, @mhdawson, @Eomm, @ghinks volunteered to write the first cut of the Blog post.

[mhdawson]

@darcyclarke, @mhdawson, @Eomm, @ghinks the first thing we should agree on is the outline for the blog post.

How does this look:

• Background and the issue being addressed
  
  
  
  • For package maintainers
  
  
  • For package consumers
  
  
• Contentious discussion points
  
  
  
  • SUPPORT.md vs json file
  
  
  • Separate file or in Package.json
  
  
  • External reference or published in the package itself
  
  
  • Any others?
  
  
• Overview of key elements
  
  
  
  • target
  
  
  • response
  
  
  • backing
  
  
• Call to Action

[Eomm]

Any others?

I would add also:

• SUPPORT.md vs json file

This TOC seems ok to me.
I don't know only if it is worth to add some use cases as a reference to start

[mhdawson]

@Eomm added your suggestion.

[wesleytodd]

https://blog.npmjs.org/post/187382017885/supporting-open-source-maintainers

Hey @darcyclarke & @ahmadnassri, is this something which we should be considering in relation to this effort? Can you provide us with more details so we can make sure there is alignment that this proposal will be able to work with your new effort?

[ghinks]

@Eomm are we intending to write this as a markdown file via PR?

[ghinks]

Should we be mentioning the work/collaboration we are having with @wesleytodd and express in this blog post. I think practical examples are helpful.

[Eomm]

I think we could submit a PR to a fork so we can work on that without annoying others with our draft, and when we have finished we could send a PR here (maybe in a /blog folder)
Of course, if you think it is better to open a PR to this repo, I agree with that also.

I think practical examples are helpful.

Sure, I remember some creepy stories about emails sent to maintainers with the subject "please fix this issue otherwise I will be fired!".

I never imagined this kind of stress for maintainers!

[ghinks]

ok, I'm making a start on this and I shall push it my fork this evening.

[ghinks]

https://github.com/ghinks/package-maintenance/invitations
https://github.com/ghinks/package-maintenance/blob/feature/blog-post-soliciting-broader-feedback/docs/drafts/blogs/broader-feedback.md

(just so we know the branch)

[ghinks]

I could do with a bit of brain storming on this section

Overview of key elements

• target
• response
• backing

[wesleytodd]

I posted my comment above because I am worried about us publishing a blog post without their input. I don't want to get in the way of getting it written, but if we publish a post, and npm is going to go and implement something different, we have a problem.

@darcyclarke or @ahmadnassri, any input on this direction would be great! If you plan to adopt/build out the spec we have proposed, then great! If, on the other hand, you are doing something materially different then we need to figure out how we are moving forward.

[ghinks]

agreed, I have started writing something as it is easier once we have a starting point. All input welcome. I think it would be good if we had something substantive before the next meeting if only to have something to critique. I am also sensitive to the case study section where I would like to say that express is our candidate first time trial.

[mhdawson]

I think the blog post was going to be centered around getting feedback on the support info we propose adding to package.json (or elsewhere). This has some good content but seems much more general?

[mhdawson]

@ghinks

This has some good content but seems much more general?

Is in relation to https://github.com/ghinks/package-maintenance/blob/feature/blog-post-soliciting-broader-feedback/docs/drafts/blogs/broader-feedback.md

[mhdawson]

I do think a more general one might be good a bit later as well, but would like to make a bit more progress with the express project first.

[mhdawson]

I could do with a bit of brain storming on this section

I will try to take a cut at writing some starting text for that early next week.

[mhdawson]

Overview of key elements

The new support level information that we are recommending has 3 main dimensions:

• target: the platform versions that the package maintainer aims to support.
• response: how quickly the maintainer chooses to, or is able to, respond to issues and
  contacts for that level of support
• backing: how the project is supported

The goal is to allow the package maintainers to clarify what versions they plan to support, how quickly a consumer can expect to get help and both the existing support for the packages as well as ways that consumers can support the package.

The target field which covers which versions the package maintainers plan to support is not just the currently supported versions, but the model that can be used to predict which versions will be supported in the future. In the context of Node.js, for example, lts would indicate that any given time the package maintainers intend to support the current LTS version of Node.js and that consumers won't be forced to update their Node.js version in order to get essential fixes.

The response field allows the package maintainer to communicate the levels of support that are available (or not), as well as contact information for being able to get or pay for that support.

The backing field allows the package maintainer to communicate the outside support/funding that the package is currently receiving, as well as the channels through which consumers can support the package.

These fields allow package maintainer to clearly set expectations with consumers, reducing the friction/stress/self-imposed guilt when consumers make and express expectations that don't match those of the package maintainer.

For the consumer, these fields allow consumers to:

• better understand which versions of Node.js may be supported in the future
• the risk associated with packages that they consume
• understand how/if they can get help if they have problems
• options/channels for helping both reduce their own risk as well as how to be a good consumer by
  helping to support packages which are important to them.

[mhdawson]

@ghinks let me know what you think of that ^^^

[ghinks]

Many thanks @mhdawson this is the sort of feedback and additional commentary I was looking for.

[ghinks]

I also think we should place the overview of key elements before the contentious issues section too.

[ghinks]

@Eomm @mhdawson sorry to have missed the last meeting. I have just got the video. I think we may need to get together to articulate the direction of this article. I did start very broad. My feelings are that the wider community do not know what we are up too and we would have to make some broad references to the greater goal. But I agree it is currently not refined to the point. I would like to set up some time with us in order to make it more so. Just a little brain storming.

[Eomm]

we may need to get together to articulate the direction of this article.

Yes, because right now I think we should speak more about the target instead of the results (like support field).
I say that because of this feedback https://github.com/npm/cli/pull/246#issuecomment-529077834 and we risk to write down an article that could be incompatible with the new npm features.

[ghinks]

I would like to propose that @Eomm @ghinks * @mhdawson meet together as suggested at the meeting of the 24th in order to discuss the blog to get broader feedback on Support for Packages.

I started off with a general introduction to package maintenance as I believe we are not broadly know about. We know have to drill down into the Support Topic.

We need to get into the deeper subject mater of support. I think a meeting between us on zoom would help. I know we are all busy at work too. Are there any days that work for you? We could try Tuesday 1st October at 3PM EST ( 9PM Italy )?

[ghinks]

As I have not had a response yet we may have to re-schedule this for another time. @mhdawson @Eomm

[Eomm]

What about 9 or 10 October?
3PM EST ( 9PM Italy ) would be ok for me 👍

[ghinks]

I think the 10th works for me at this time. Thank you.

[mhdawson]

Sorry for late reply. I think 3EST on the 10 would be good. @ghinks are you going to send out an invitation?

[ghinks]

Yes that seems to work.

[ghinks]

https://us04web.zoom.us/j/937762958

[mhdawson]

Closing as this went out: https://openjsf.org/blog/2020/09/23/node-js-package-maintenance-bridging-the-gap-between-maintainers-and-consumers/

[thescientist13]

@mhdawson
Did you mean to close the issue? Looks to still be open.