deprecate CHANGELOG, improve release action, PR template, Contributing doc

[twelch]

This is a draft PR that adds more to the release action, open for discussion. It:

• Automatically marks a new release as the latest. I noticed that 6.5 was still marked as the current Github release, so the automated action didn't update that.
• Generates release notes automatically from the commit log and add mention to the contributor. (CHANGELOG is deprecated with a message in favor of using release notes).
• Marks the release as draft, so that a human can review, cleaning up the auto-notes, adding breaking change instructions, and press the button to publish the release record.

This PR also:

• refactors Contributing including new release docs
• Simplifies the pull request template

The release steps need to get tested, and corrected as needed, on the next release.

[smallsaucepan]

Another thing worth noting is that the URLs of github releases are predictable - the URL for 8.2.3 will be https://github.com/Turfjs/turf/releases/tag/v8.2.3 for example

That means when we're preparing for a release, we could put the following at the top of CHANGELOG.md before we even tag the code:

v8.2.3

Release notes - https://github.com/Turfjs/turf/releases/tag/v8.2.3

If there are already some changes people have been saving to CHANGELOG.md as we go, just cut them into a draft release and replace with the above.

And that's it. We can augment any manually copied notes with the auto generate feature in the release. Minimises duplication, though still keeps a CHANGELOG.md in the project root for people to use as a jumping off point.

With the changelog side of things removed, automating the release creation doesn't really save us much labour. I'm wary of trying to over-automate things. Publishing to NPM is significant / rare enough an event that it probably benefits from a bit of manual preparation, Slack chatter, etc even if the final publishing process itself is largely automated.

[mfedderly]

I like this approach, I don't think we should be manually managing changelogs.
I assume this means that we need more useful PR titles because that's what gets put into the Github changelogs?

[twelch]

Appreciate the thoughts. To answer your question @mfedderly, yes the auto release notes uses the PR title or commit description. Here's an example of what they could look like:

What's Changed

• Simplify unnecessary union type in turfDistance by @isti115 in #2618
• Add inches, yards, meters to turf-distance units parameters by @twelch in #346
  ...[further list of commits]

Full Changelog: v6.5.0...v7.0.0

With the blessing you gave @mfedderly, as the person making most of the changelog edits lately, I'd like to try this auto-approach and just deprecate the changelog. I've added to this PR doing so, and started to draft some new instructions in the CONTRIBUTING doc. I think there's still something missing here @mfedderly if you don't mind taking a look.

My observation is that people aren't really updating the changelog as we go. Edits to it feel very ad-hoc right now, and not done as PR's come in, or just after, but rather right before a pre-release or release by a core contributor reviewing the commit log. @mfedderly you were the main person doing changelog updates lately, so your blessing on switching to Github releases is well heard.

[mfedderly]

My observation is that people aren't really updating the changelog as we go.

Yeah its pretty rough trying to go back through the commits and write up meaningful changes. I'm a big fan of us not doing that any more. My only flag is that the PR titles should get some attention in CRs going forward to make sure we're happy with the wording, since it'll go directly into the changelog (at least for the first draft).

[twelch]

Thanks @mfedderly I've updated the release instructions accordingly if you could give a final look.

[twelch]

Okay @smallsaucepan @mfedderly I've reworked and simplified more of the Contributing page, filling in lots of holes for someone starting from scratch (and myself not having done a release). I've simplified the pull request template to point to a checklist in a new "Preparing a pull request" section of the doc.

[smallsaucepan]

I think this works out to around 1 comment per 4 lines of code changed, which is probably a new record. Nice work.