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)