Simplify PyGMT Release process

.github/ISSUE_TEMPLATE/release_checklist.md

@@ -0,0 +1,36 @@
+---
+name: PyGMT release checklist
+about: Checklist for a new PyGMT release.
+title: 'Release PyGMT x.x.x'
+labels: 'maintenance'
+assignees: ''
+
+---
+
+**Release**: [v0.x.x](https://github.com/GenericMappingTools/pygmt/milestones/0.x.x)
+**Scheduled Date**: YYYY/MM/DD
+
+**Before release**:
+- [ ] Reserve a DOI on [Zenodo](https://zenodo.org) by clicking on "New Version"
+- [ ] Update Changelog
+
+**Release**:
+- [ ] Make a tag and push it to Github
+```
+git tag vX.Y.Z
+git push --tags
+```
+- [ ] Go to [GitHub Release](https://github.com/GenericMappingTools/pygmt/releases) and make a release
+- [ ] Manually upload the pygmt-vX.Y.Z.zip file to https://zenodo.org/deposit, make sure you file it under the correct reserved DOI
+- [ ] Announce the releases on the GMT [forum](https://forum.generic-mapping-tools.org/c/news/), [website](https://github.com/GenericMappingTools/website) (News) and [ResearchGate](https://www.researchgate.net/project/PyGMT-A-Python-interface-for-the-Generic-Mapping-Tools)
+
+**After release**:
+- [ ] Create branch 0.x for bug-fixes if this is a minor release (i.e. create branch 0.1 after 0.1.0 is released)
+- [ ] Commit changes to Github
+
+**3rd party update**:
+- [ ] Update conda-forge [pygmt-feedstock](https://github.com/conda-forge/pygmt-feedstock) [Usually done automatically by conda-forge's bot]
+
+---
+
+- [ ] Party :tada: (don't tick before all other checkboxes are ticked!)

.github/release-drafter.yml

@@ -0,0 +1,26 @@
+name-template: 'v$NEXT_PATCH_VERSION'
+tag-template: 'v$NEXT_PATCH_VERSION'
+categories:
+  - title: 'New Features'
+    label: 'feature'
+  - title: 'Enhancements'
+    label: 'enhancement'
+  - title: 'Documentation'
+    label: 'documentation'
+  - title: 'Bug Fixes'
+    label: 'bug'
+  - title: 'Maintenance'
+    label: 'maintenance'
+  - title: 'Deprecations'
+    label: 'deprecation'
+exclude-labels:
+  - 'skip-changelog'
+change-template: '* $TITLE (#$NUMBER) @$AUTHOR'
+template: |
+  [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.3781524.svg)](https://doi.org/10.5281/zenodo.3781524)
+
+  ## Highlights
+
+  *
+
+  $CHANGES

.github/workflows/release-drafter.yml

@@ -0,0 +1,19 @@
+name: Release Drafter
+
+on:
+  push:
+    # branches to consider in the event; optional, defaults to all
+    branches:
+      - master
+
+jobs:
+  update_release_draft:
+    runs-on: ubuntu-latest
+    steps:
+      # Drafts your next Release notes as Pull Requests are merged into "master"
+      - uses: release-drafter/[email protected]
+        with:
+          # (Optional) specify config name to use, relative to .github/. Default: release-drafter.yml
+          # config-name: my-config.yml
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

MAINTENANCE.md

@@ -81,6 +81,17 @@ There are a few steps that still must be done manually, though.
 
 ### Updating the changelog
 
+The Release Drafter Github Action will automatically keep a draft changelog at
+https://github.com/GenericMappingTools/pygmt/releases, adding a new entry
+every time a Pull Request (with a proper label) is merged into the master branch.
+This release drafter tool has two configuration files, one for the Github Action
+at .github/workflows/release-drafter.yml, and one for the changelog template
+at .github/release-drafter.yml. Configuration settings can be found at
+https://github.com/release-drafter/release-drafter.
+
+The drafted release notes are not perfect, so we will need to tidy it prior to
+publishing the actual release notes at https://www.pygmt.org/latest/changes.html.
+
 1. Generate a list of commits between the last release tag and now:
 
     ```bash
@@ -141,17 +152,18 @@ this new folder.
 Grab a zip file from the Github release and upload to Zenodo using the previously
 reserved DOI.
 
-### Updating the conda package (Not available yet)
+### Updating the conda package
+
+When a new version is released on PyPI, conda-forge's bot automatically creates version
+updates for the feedstock. In most cases, the maintainers can simply merge that PR.
 
-After Travis is done building the tag and all builds pass, we need to update the conda
-package.
-Unfortunately, this needs to be done manually for now.
+If changes need to be done manually, you can:
 
-1. Fork the feedstock repository (https://github.com/conda-forge/pygmt-feedstock) if
+1. Fork the [pygmt feedstock repository](https://github.com/conda-forge/pygmt-feedstock) if
    you haven't already. If you have a fork, update it.
 2. Update the version number and sha256 hash on `recipe/meta.yaml`. You can get the hash
    from the PyPI "Download files" section.
 3. Add or remove any new dependencies (most are probably only `run` dependencies).
-4. Make a new branch, commit, and push your changes **to your fork**.
+4. Make a new branch, commit, and push the changes **to your personal fork**.
 5. Create a PR against the original feedstock master.
-6. Once the CIs are passing, merge or as a maintainer to do so.
+6. Once the CI tests pass, merge the PR or ask a maintainer to do so.