update from head

.azure-pipelines.yml

@@ -9,6 +9,12 @@ trigger:
     - master
     - refs/tags/*
 
+# Make sure triggers are set for PRs to any branch.
+pr:
+  branches:
+    include:
+    - '*'
+
 
 jobs:
 
@@ -21,7 +27,7 @@ jobs:
     vmImage: 'ubuntu-16.04'
 
   variables:
-    CONDA_INSTALL_EXTRA: "black flake8 pylint"
+    CONDA_INSTALL_EXTRA: "black>=20.8b1 flake8 pylint==2.4.*"
     PYTHON: '3.7'
 
   steps:
@@ -71,7 +77,7 @@ jobs:
   displayName: 'Mac'
 
   pool:
-    vmImage: 'macOS-10.13'
+    vmImage: 'macOS-10.15'
 
   variables:
     CONDA_REQUIREMENTS: requirements.txt

.travis.yml

@@ -3,8 +3,8 @@
 # We use miniconda for Python so don't need any Python specific tools
 language: generic
 
-# Use the container builds so we don't need sudo priviledges
-sudo: false
+os: linux
+dist: xenial
 
 # Only build pushes to the master branch and tags. This avoids the double
 # builds than happen when working on a branch instead of a fork.
@@ -33,7 +33,7 @@ env:
         - DEPLOY_PYPI=false
 
 # Specify the build configurations. Be sure to only deploy from a single build.
-matrix:
+jobs:
     include:
         - name: "Linux - Python 3.8"
           os: linux

CONTRIBUTING.md

@@ -125,6 +125,15 @@ hesitate to [ask questions](#how-can-i-talk-to-you)):
 * Aaron Meurer's [tutorial on the git workflow](http://www.asmeurer.com/git-workflow/)
 * [How to Contribute to an Open Source Project on GitHub](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github)
 
+If you're new to working with git, GitHub, and the Unix Shell, we recommend 
+starting with the [Software Carpentry](https://software-carpentry.org/) lessons, 
+which are available in English and Spanish:
+
+* :gb: [Version Control with Git](http://swcarpentry.github.io/git-novice/) / :es: [Control de
+versiones con Git](https://swcarpentry.github.io/git-novice-es/)
+* :gb: [The Unix Shell](http://swcarpentry.github.io/shell-novice/) / :es:
+[La Terminal de Unix](https://swcarpentry.github.io/shell-novice-es/)
+
 ### General guidelines
 
 We follow the [git pull request workflow](http://www.asmeurer.com/git-workflow/) to

MAINTENANCE.md

@@ -1,12 +1,27 @@
 # Maintainers Guide
 
-This page contains instructions for project maintainers about how our setup works,
-making releases, creating packages, etc.
+This page contains instructions for project maintainers about how our setup
+works, making releases, creating packages, etc.
 
 If you want to make a contribution to the project, see the
 [Contributing Guide](CONTRIBUTING.md) instead.
 
 
+## Contents
+
+* [Branches](#branches)
+* [Reviewing and merging pull requests](#reviewing-and-merging-pull-requests)
+* [Continuous Integration](#continuous-integration)
+* [Citations](#citations)
+* [Making a Release](#making-a-release)
+  * [Draft a new Zenodo release](#draft-a-new-zenodo-release)
+  * [Update the changelog](#update-the-changelog)
+  * [Check the README syntax](#check-the-readme-syntax)
+  * [Release](#release)
+  * [Archive on Zenodo](#archive-on-zenodo)
+  * [Update the conda package](#update-the-conda-package)
+
+
 ## Branches
 
 * *master*: Always tested and ready to become a new version. Don't push directly to this
@@ -62,6 +77,43 @@ If you find any problems with the test setup and deployment, please create issue
 submit pull requests to that repository.
 
 
+## Citations
+
+The citation for a package that doesn't have an associated paper will be the
+Zenodo DOI for all versions. This citation will include everyone who has
+contributed to the project and met our [authorship criteria](AUTHORSHIP.md).
+
+Include the following text in the `CITATION.rst` file:
+
+```
+This is research software **made by scientists**. Citations help us justify the
+effort that goes into building and maintaining this project.
+
+If you used this software in your research, please consider
+citing the following source: https://doi.org/10.5281/zenodo.3530749
+
+The link above includes full citation information and export formats (BibTeX,
+Mendeley, etc).
+```
+
+If the project has been publish as an academic paper (for example, on
+[JOSS](https://joss.theoj.org)), **update the `CITATION.rst` to point to the
+paper instead of the Zenodo archive**.
+
+```
+If you used this software in your research, please consider citing the
+following publication:
+
+    <full citation including authors, title, journal, DOI, etc>
+
+This is an open-access publication. The paper and the associated reviews can be
+freely accessed at: https://doi.org/<INSERT-DOI-HERE>
+
+The link above includes full citation information and export formats (BibTeX,
+Mendeley, etc).
+```
+
+
 ## Making a Release
 
 We try to automate the release process as much as possible.
@@ -70,23 +122,27 @@ The version number is set automatically using versioneer based information it ge
 git.
 There are a few steps that still must be done manually, though.
 
-### Drafting a new Zenodo release
+### Draft a new Zenodo release
 
 If the project already has releases on [Zenodo](https://zenodo.org/), you need to create
 a **New version** of it. Find the link to the latest Zenodo release on the `README.md`
 file of your project. Then:
 
 1. Delete all existing files (they will be replaced with the new version).
 2. Reserve a DOI and save the release draft.
-3. Add as authors any new contributors who have added themselves to `AUTHORS.md`.
+3. Add as authors any new contributors who have added themselves to
+   [`AUTHORS.md`](AUTHORS.md).
+4. Review author order to make sure it follows the guidelines on our
+   [Authorship Guide](AUTHORSHIP.md)
+5. Update release date.
 
 On the other hand, if you're making the first release of the project, you need to create
 a **New upload** for it inside the
 [Fatiando a Terra community at Zenodo](https://zenodo.org/communities/fatiando/).
 Make sure the Fatiando a Terra community is chosen when filling the release draft.
 The rest of the process is the same as above.
 
-### Updating the changelog
+### Update the changelog
 
 1. Generate a list of commits between the last release tag and now:
 
@@ -126,39 +182,48 @@ python setup.py --long-description | rst2html.py --no-raw > index.html
 
 Open `index.html` and check for any flaws or error messages.
 
-### Pushing to PyPI and updating the documentation
-
-After the changelog is updated, making a release should be as simple as creating a new
-git tag and pushing it to Github:
+### Release
 
-```bash
-git tag v0.2.0
-git push --tags
-```
+After the changelog is updated, making a release should be as simple as
+creating a new git tag.
+The continuous integration services will take care of pushing the package to
+PyPI and creating a new version of the documentation.
+A new folder with version number containing the HTML documentation will be
+pushed to *gh-pages*, and the `latest` link will be updated to point to this
+new folder.
 
 The tag should be version number (following [Semantic Versioning](https://semver.org/))
-with a leading `v`.
-This should trigger Travis to do all the work for us.
-A new source distribution will be uploaded to PyPI, a new folder with the documentation
-HTML will be pushed to *gh-pages*, and the `latest` link will be updated to point to
-this new folder.
+with a leading `v` (`v1.5.7`).
+
+To create a new tag, go to `https://github.com/fatiando/PROJECT/releases` and
+click on "Draft a new release":
+
+1. Use the version number (including the `v`) as the "Tag version" and "Release
+   title".
+2. Fill the release description with a Markdown version of the **latest**
+   changelog entry (including the DOI badge). The `doc/changes.rst` file can be
+   converted to Markdown using `pandoc`:
+   ```
+   pandoc -s doc/changes.rst -o changes.md --wrap=none
+   ```
+3. Publish the release.
 
-### Archiving on Zenodo
+### Archive on Zenodo
 
 Grab a zip file from the Github release and upload to Zenodo using the previously
 reserved DOI.
 
-### Updating the conda package
+### Update the conda package
 
-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.
+After Travis is done building the tag and all builds pass, we need to update
+the conda package.
+Fortunately, the conda-forge bot will submit a PR updating the package for us
+(it may take a couple of hours to do so).
+Most releases can be merged right away but some might need further changes to
+the conda recipe:
 
-1. Fork the feedstock repository (https://github.com/conda-forge/PROJECT-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**.
-5. Create a PR against the original feedstock master.
-6. Once the CIs are passing, merge or as a maintainer to do so.
+1. If the release added new dependencies, make sure they are included in the
+   `meta.yaml` file.
+2. If dropping/adding support for Python versions (or version of other
+   packages) make sure the correct version restrictions are applied in
+   `meta.yaml`.

Makefile

@@ -3,8 +3,8 @@ PROJECT=verde
 TESTDIR=tmp-test-dir-with-unique-name
 PYTEST_ARGS=--cov-config=../.coveragerc --cov-report=term-missing --cov=$(PROJECT) --doctest-modules -v --pyargs
 LINT_FILES=setup.py $(PROJECT)
-BLACK_FILES=setup.py $(PROJECT) examples data/examples tutorials
-FLAKE8_FILES=setup.py $(PROJECT) examples data/examples
+BLACK_FILES=setup.py $(PROJECT) examples data/examples doc/conf.py tutorials
+FLAKE8_FILES=setup.py $(PROJECT) examples data/examples doc/conf.py
 
 help:
 	@echo "Commands:"

README.rst

@@ -130,7 +130,7 @@ What could you possibly offer?
 We assure you that the little voice in your head is wrong.
 
 **Being a contributor doesn't just mean writing code**.
-Equality important contributions include:
+Equally important contributions include:
 writing or proof-reading documentation, suggesting or implementing tests, or
 even giving feedback about the project (including giving feedback about the
 contribution process).
@@ -159,6 +159,8 @@ Documentation for other versions
 * `Development <http://www.fatiando.org/verde/dev>`__ (reflects the *master* branch on
   Github)
 * `Latest release <http://www.fatiando.org/verde/latest>`__
+* `v1.5.0 <http://www.fatiando.org/verde/v1.5.0>`__
+* `v1.4.0 <http://www.fatiando.org/verde/v1.4.0>`__
 * `v1.3.0 <http://www.fatiando.org/verde/v1.3.0>`__
 * `v1.2.0 <http://www.fatiando.org/verde/v1.2.0>`__
 * `v1.1.0 <http://www.fatiando.org/verde/v1.1.0>`__

data/examples/baja_bathymetry.py

@@ -32,5 +32,4 @@
 plt.colorbar().set_label("meters")
 # Use an utility function to add tick labels and land and ocean features to the map.
 vd.datasets.setup_baja_bathymetry_map(ax)
-plt.tight_layout()
 plt.show()

data/examples/california_gps.py

@@ -51,5 +51,4 @@
 )
 plt.colorbar(tmp, ax=ax).set_label("meters/year")
 vd.datasets.setup_california_gps_map(ax)
-plt.tight_layout(w_pad=0)
 plt.show()

data/examples/rio_magnetic.py

@@ -47,5 +47,4 @@
 plt.colorbar(pad=0.01).set_label("nT")
 # Set the proper ticks for a Cartopy map
 vd.datasets.setup_rio_magnetic_map(ax)
-plt.tight_layout()
 plt.show()

data/examples/texas-wind.py

@@ -39,5 +39,4 @@
 )
 # Use an utility function to add tick labels and land and ocean features to the map.
 vd.datasets.setup_texas_wind_map(ax)
-plt.tight_layout()
 plt.show()