update instructions with template checklist (#242)

Author: jdkent

docs/development/release_instructions.rst

@@ -35,18 +35,26 @@ Instructions
    Add and commit ``long_description.rst``.
 5. Push the branch onto your forked repository and open a pull request.
 6. Name the Pull Request ``[REL] vX.Y.ZrcN``
-7. After reviewing ``CHANGELOG.rst`` and ``long_description.rst``, merge the pull request.
-8. Go to the Releases section on the repository and create a new release.
-9. Copy the brief summary from ``CHANGELOG.rst`` and add it below the ``CHANGES`` section
-   in the text provided by Release Drafter.
-10. Tag the release as ``vX.Y.ZrcN`` where X, Y, and Z are the major, minor, and patch numbers
+7. Create a checklist to ensure:
+
+    - ``CHANGELOG.rst`` is finalized
+    - ``long_description.rst`` is finalized
+    - new contributors are added to ``.zenodo.json``
+    - ask repeat contributors if they want to be a creator.
+    - other issues that pop up during the release (for example, deployment is not working)
+
+8. After all creators review ``CHANGELOG.rst`` and optionally other changes, merge the pull request.
+9. Go to the Releases section on the repository and create a new release.
+10. Copy the brief summary from ``CHANGELOG.rst`` and add it below the ``CHANGES`` section
+    in the text provided by Release Drafter.
+11. Tag the release as ``vX.Y.ZrcN`` where X, Y, and Z are the major, minor, and patch numbers
     respectively, and N is the release candidate number starting with 1.
-11. Mark the release as a pre-release.
-12. Create the release and check if nibetaseries is being built and deployed on ``dockerhub``
+12. Mark the release as a pre-release.
+13. Create the release and check if nibetaseries is being built and deployed on ``dockerhub``
     and ``pypi`` correctly.
-13. If not successful, create another branch called ``rel_vX.Y.ZrcN`` with N being incremented.
-14. Make the necessary changes to fix deployment and go back to step 5.
-15. If successful, create a new tag ``vX.Y.Z`` copying all release drafter information
+14. If not successful, create another branch called ``rel_vX.Y.ZrcN`` with N being incremented.
+15. Make the necessary changes to fix deployment and go back to step 5.
+16. If successful, create a new tag ``vX.Y.Z`` copying all release drafter information
     from the last successful release candidate.
 
 Yay! If you've followed these instructions, you'll be a release pro in no time.