Merge pull request #368 from NLeSC/all_the_small_things

Assorted changes: audience, contributing guidelines, remove .zenodo.json

Author: egpbos

.zenodo.json

@@ -33,6 +33,7 @@
 * `.pylintrc` file, was too strict, too soon [#267](https://github.com/NLeSC/python-template/issues/267)
 * Unused development dependencies [#167](https://github.com/NLeSC/python-template/issues/167)
 * Statements in project_setup.md already mentioned in README.dev.md
+* .zenodo.json is no longer necessary, CITATION.cff also works with Zenodo.
 
 ## 0.4.0
 

CHANGELOG.md

@@ -36,7 +36,22 @@ in line with what is recommended there. If not, please [contribute to the guide]
 1. make sure the existing tests still work by running ``pytest``. If project tests fail use ``pytest --keep-baked-projects`` to keep generated project files in `/tmp/pytest-*` and investigate;
 1. add your own tests (if necessary);
 1. update or expand the documentation;
-1. push your feature branch to (your fork of) the Python Template repository on GitHub;
+1. update the `CHANGELOG.md` file with your change;
+1. [push](http://rogerdudler.github.io/git-guide/) your feature branch to (your fork of) the Python Template repository on GitHub;
 1. create the pull request, e.g. following the instructions [here](https://help.github.com/articles/creating-a-pull-request/).
 
 In case you feel like you've made a valuable contribution, but you don't know how to write or run tests for it, or how to generate the documentation: don't let this discourage you from making the pull request; we can help you! Just go ahead and submit the pull request, but keep in mind that you might be asked to append additional commits to your pull request.
+
+## You want to make a new release of the code base
+
+To create a release you need write permission on the repository.
+
+1. Check the author list in [`CITATION.cff`](CITATION.cff)
+1. Update the version number in setup.cfg and CITATION.cff
+1. Update the `CHANGELOG.md` to include changes made
+1. Go to the [GitHub release page](https://github.com/nlesc/python-template/releases)
+1. Press draft a new release button
+1. Fill version, title and description field
+1. Press the Publish Release button
+
+Also a Zenodo entry will be made for the release with its own DOI.

CONTRIBUTING.md

@@ -92,7 +92,7 @@ Follow the instructions from `my-python-project/README.dev.md` and make sure tha
 ### Preparation
 
 1. Make sure the `CHANGELOG.md` has been updated
-2. Verify that the information in `CITATION.cff` is correct, and that `.zenodo.json` contains equivalent data
+2. Verify that the information in `CITATION.cff` is correct.
 3. Make sure that `version` in [setup.cfg](setup.cfg) and  `version` in [CITATION.cff](CITATION.cff) have been bumped to the to-be-released version of the template
 4. Run the unit tests with `pytest tests/`
 5. Go through the steps outlined above for [generating a new package from the command line](#using-cookiecutter-to-generate-a-new-package-from-the-command-line), and verify that the generated package works as it should.

README.dev.md

@@ -11,10 +11,9 @@ It is likely that your `CITATION.cff` currently doesn't pass validation. The err
 - [ ] Update the `doi` key with the conceptDOI for your repository (see [https://help.zenodo.org](https://help.zenodo.org/) for more information on what a conceptDOI is). If your project doesn't have a DOI yet, you can use the string `10.0000/FIXME` to pass validation.
 - [ ] Verify that the `keywords` array accurately describes your project.
 
-Once you do all the steps above, the `cffconvert` workflow will tell you what content it expected to see in `.zenodo.json`. Copy-paste from the GitHub Action log into a new file `.zenodo.json`. Afterwards, the `cffconvert` GitHub Action should be green.
+Afterwards, the `cffconvert` GitHub Action should be green.
 
-
-To help you keep the citation metadata up to date and synchronized, the [`cffconvert`]({{cookiecutter.repository_url}}/actions/workflows/cffconvert.yml) GitHub Action checks the following 6 aspects:
+To make sure services like [Zenodo](https://zenodo.org) and the [Research Software Directory](https://research-software-directory.org/) can keep your citation data up to date, the [`cffconvert`]({{cookiecutter.repository_url}}/actions/workflows/cffconvert.yml) GitHub Action checks the following:
 
 1. Whether your repository includes a `CITATION.cff` file.
 
@@ -27,17 +26,3 @@ To help you keep the citation metadata up to date and synchronized, the [`cffcon
 1. Whether your `CITATION.cff` adheres to the schema (as listed in the `CITATION.cff` file itself under key `cff-version`).
 
     _The Citation File Format schema can be found [here](https://github.com/citation-file-format/citation-file-format), along with an explanation of all the keys. You're advised to use the latest available schema version._
-
-1. Whether your repository includes a `.zenodo.json` file.
-
-    _With this file, you can control what metadata should be associated with any future releases of your software on Zenodo: things like the author names, along with their affiliations and their ORCIDs, the license under which the software has been released, as well as the name of your software and a short description. If your repository doesn't have a .zenodo.json file, Zenodo will take a somewhat crude guess to assign these metadata._
-
-    _The `cffconvert` GitHub action will tell you what it expects to find in `.zenodo.json`, just copy and paste it to a new file named `.zenodo.json`. The suggested text ignores CITATION.cff's `version`, `commit`, and `date-released`. `cffconvert` considers these keys `suspect` in the sense that they are often out of date, and there is little purpose to telling Zenodo about these properties: Zenodo already knows._
-
-1. Whether `.zenodo.json` is valid JSON.
-
-    _Currently unimplemented, but you can check for yourself on [https://jsonlint.com/](https://jsonlint.com/)._ 
-
-1. Whether `CITATION.cff` and `.zenodo.json` contain equivalent data.
-
-    _This final check verifies that the two files are in sync. The check ignores CITATION.cff's `version`, `commit`, and `date-released`._

{{cookiecutter.directory_name}}/.github/next_steps/02_citation.md

@@ -17,5 +17,7 @@ jobs:
       - uses: actions/checkout@v3
         name: Check out a copy of the repository
 
-      - uses: citation-file-format/cffconvert-github-action@main
-        name: Check whether the citation metadata from CITATION.cff is equivalent to that in .zenodo.json
+      - name: Check whether the citation metadata from CITATION.cff is valid
+        uses: citation-file-format/cffconvert-github-action@2.0.0
+        with:
+          args: "--validate"

{{cookiecutter.directory_name}}/.github/workflows/cffconvert.yml

@@ -30,12 +30,39 @@ The sections below outline the steps in each case.
 
 1. (**important**) announce your plan to the rest of the community *before you start working*. This announcement should be in the form of a (new) issue;
 1. (**important**) wait until some kind of consensus is reached about your idea being a good idea;
-1. if needed, fork the repository to your own Github profile and create your own feature branch off of the latest master commit. While working on your feature branch, make sure to stay up to date with the master branch by pulling in changes, possibly from the 'upstream' repository (follow the instructions [here](https://help.github.com/articles/configuring-a-remote-for-a-fork/) and [here](https://help.github.com/articles/syncing-a-fork/));
+1. if needed, fork the repository to your own Github profile and create your own feature branch off of the latest main commit. While working on your feature branch, make sure to stay up to date with the main branch by pulling in changes, possibly from the 'upstream' repository (follow the instructions [here](https://help.github.com/articles/configuring-a-remote-for-a-fork/) and [here](https://help.github.com/articles/syncing-a-fork/));
+1. install dependencies (see the [development documentation](README.dev.md#development_install));
 1. make sure the existing tests still work by running ``pytest``;
 1. add your own tests (if necessary);
 1. update or expand the documentation;
-1. update the `CHANGELOG.md` file with change;
-1. push your feature branch to (your fork of) the {{ cookiecutter.package_name }} repository on GitHub;
+1. update the `CHANGELOG.md` file with your change;
+1. [push](http://rogerdudler.github.io/git-guide/) your feature branch to (your fork of) the {{ cookiecutter.package_name }} repository on GitHub;
 1. create the pull request, e.g. following the instructions [here](https://help.github.com/articles/creating-a-pull-request/).
 
 In case you feel like you've made a valuable contribution, but you don't know how to write or run tests for it, or how to generate the documentation: don't let this discourage you from making the pull request; we can help you! Just go ahead and submit the pull request, but keep in mind that you might be asked to append additional commits to your pull request.
+
+## You want to make a new release of the code base
+
+To create a release you need write permission on the repository.
+
+1. Check the author list in [`CITATION.cff`](CITATION.cff)
+1. Bump the version using `bump-my-version bump <major|minor|patch>`. For example, `bump-my-version bump major` will increase major version numbers everywhere it's needed (code, meta, etc.) in the repo. Alternatively the version can be manually changed in {{ cookiecutter.package_name }}/__init__.py, pyproject.toml, CITATION.cff and docs/conf.py (and other places it was possibly added).
+1. Update the `CHANGELOG.md` to include changes made
+1. Go to the [GitHub release page]({{ cookiecutter.repository_url }}/releases)
+1. Press draft a new release button
+1. Fill version, title and description field
+1. Press the Publish Release button
+<!--
+For projects that automatically publish to PyPI using a release or publish workflow, something like the following could be useful to add (make sure to replace the names and links):
+
+1. Wait until [PyPi publish workflow]({{ cookiecutter.repository_url }}/actions/workflows/publish.yml) has completed
+1. Verify new release is on [PyPi](https://pypi.org/project/matchms/#history)
+-->
+<!--
+For projects that also build conda packages, e.g. on conda-forge or Bioconda, something like the following could be useful to add (example taken from matchms, make sure to replace the names and links):
+
+1. Wait until new release is also on Bioconda (https://anaconda.org/bioconda/{{ cookiecutter.package_name }}) via a automaticly created PR on [bioconda recipes repo](https://github.com/bioconda/bioconda-recipes/pulls?q=is%3Apr+is%3Aopen+{{ cookiecutter.package_name }})
+1. Test {{ cookiecutter.package_name }} from bioconda by manually running [Conda verify]({{ cookiecutter.repository_url }}/actions/workflows/conda_verify.yml) workflow
+-->
+
+Also a Zenodo entry will be made for the release with its own DOI.

{{cookiecutter.directory_name}}/CONTRIBUTING.md

@@ -132,7 +132,7 @@ This section describes how to make a release in 3 parts:
 ### (1/3) Preparation
 
 1. Update the <CHANGELOG.md> (don't forget to update links at bottom of page)
-2. Verify that the information in `CITATION.cff` is correct, and that `.zenodo.json` contains equivalent data
+2. Verify that the information in [`CITATION.cff`](CITATION.cff) is correct.
 3. Make sure the [version has been updated](#versioning).
 4. Run the unit tests with `pytest -v`
 

{{cookiecutter.directory_name}}/README.dev.md

@@ -14,6 +14,7 @@ authors = [
 classifiers = [
     "Development Status :: 2 - Pre-Alpha",
     "Intended Audience :: Developers",
+    "Intended Audience :: Science/Research",
     "{{ {'Apache Software License 2.0': 'License :: OSI Approved :: Apache Software License',
         'MIT license': 'License :: OSI Approved :: MIT License',
         'BSD license': 'License :: OSI Approved :: BSD License',