diff --git a/AUTHORSHIP.md b/AUTHORSHIP.md
deleted file mode 100644
index 8c45a2ca5..000000000
--- a/AUTHORSHIP.md
+++ /dev/null
@@ -1,74 +0,0 @@
-# Authorship guidelines for academic papers and software archives
-
-First of all, we are deeply thankful to everyone who has helped make Fatiando a
-Terra what it is today. Our goal for this document is to establish guidelines
-for giving credit to contributors for their work.
-To do so, we will attempt to define:
-
-- Fair and diverse ways of providing recognition for contributors' efforts.
-- Define _contributions_ in a broad way: writing code and/or documentation,
- providing ideas, fostering the community, etc.
-
-The following are the ways in which individuals who have contributed will be
-recognized.
-
-> **Note**: These policies are not set in stone and may be changed to
-> accommodate the growth of the project or the preferences of the community.
-
-## The `AUTHORS.md` file
-
-Anyone who has contributed a pull request to the project is welcome to add
-themselves to the `AUTHORS.md` file. This file lives in the repository and is
-packaged with distributions. This is an optional process.
-
-## Changelog for each release
-
-Every time we make a release, everyone who has made a commit to the repository
-since the previous release will be mentioned in the changelog entry. If their
-full name is available on GitHub, we will use it. Otherwise, we will use the
-GitHub handle. This is a way of saying "Thank you".
-
-## Authorship on Zenodo archives of releases
-
-Anyone who has contributed to the repository (i.e., appears on `git log`) will
-be invited to be an author on the Zenodo archive of new releases.
-
-To be included as an author, you *must* add the following to the `AUTHORS.md`
-file of the repository:
-
-1. Full name
-2. Affiliation (if omitted, we will use "Unaffiliated")
-3. ORCID (optional)
-
-The order of authors will be defined by the number of commits to the repository
-(`git shortlog -sne`). The order can also be changed on a case-by-case basis.
-
-If you have contributed and do not wish to be included in Zenodo archives,
-there are a few options:
-
-1. Don't add yourself to `AUTHORS.md`
-2. Remove yourself from `AUTHORS.md`
-3. Indicate next to your name on `AUTHORS.md` that you do not wish to be
- included with something like `(not included in Zenodo)`.
-
-## Scientific publications (papers)
-
-We aim to write academic papers for most of your software packages. Ideally, we
-will publish updated papers for major changes or large new components of the
-package.
-
-To be included as an author on the paper, you *must* satisfy the following
-criteria:
-
-1. Have made a contribution to the repository or significant non-coding
- contributions.
-2. Add your full name, affiliation, and (optionally) ORCID to the paper. These
- can be submitted on pull requests to the corresponding paper repository.
-3. Write and/or read and review the manuscript in a timely manner and provide
- comments on the paper (even if it's just an "OK", but preferably more).
-
-The order of authors will be defined by the number of commits made since the
-previous major release that has an associated paper (`git shortlog
-vX.0.0...HEAD -sne`). The order of any author who hasn't made any commits will
-be decided by all authors. The order can also be changed on a case-by-case
-basis.
diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md
index 72715db0c..85bd498f2 100644
--- a/CODE_OF_CONDUCT.md
+++ b/CODE_OF_CONDUCT.md
@@ -1,77 +1,4 @@
# Contributor Code of Conduct
-## Our Pledge
-
-In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
-our community a harassment-free experience for everyone, regardless of age,
-body size, disability, ethnicity, gender identity and expression, level of
-experience, nationality, personal appearance, race, religion, or sexual
-identity and orientation.
-
-## Our Standards
-
-Examples of behavior that contributes to creating a positive environment
-include:
-
-* Using welcoming and inclusive language
-* Being respectful of differing viewpoints and experiences
-* Gracefully accepting constructive criticism
-* Focusing on what is best for the community
-* Showing empathy towards other community members
-
-Examples of unacceptable behavior by participants include:
-
-* The use of sexualized language or imagery and unwelcome sexual attention or
- advances
-* Trolling, insulting/derogatory comments, and personal or political attacks
-* Public or private harassment
-* Publishing others' private information, such as a physical or electronic
- address, without explicit permission
-* Other conduct which could reasonably be considered inappropriate in a
- professional setting
-
-## Our Responsibilities
-
-Project maintainers are responsible for clarifying the standards of acceptable
-behavior and are expected to take appropriate and fair corrective action in
-response to any instances of unacceptable behavior.
-
-Project maintainers have the right and responsibility to remove, edit, or
-reject comments, commits, code, wiki edits, issues, and other contributions
-that are not aligned to this Code of Conduct, or to ban temporarily or
-permanently any contributor for other behaviors that they deem inappropriate,
-threatening, offensive, or harmful.
-
-## Scope
-
-This Code of Conduct applies both within project spaces and in public spaces
-when an individual is representing the project or its community. Examples of
-representing a project or community include using an official project e-mail
-address, posting via an official social media account, or acting as an
-appointed representative at an online or offline event. Representation of a
-project may be further defined and clarified by project maintainers.
-
-## Enforcement
-
-Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting [Leonardo Uieda](http://www.leouieda.com).
-
-All complaints will be reviewed and investigated and will result in a response
-that is deemed necessary and appropriate to the circumstances. The project team
-is obligated to maintain confidentiality with regard to the reporter of an
-incident. Further details of specific enforcement policies may be posted
-separately.
-
-Project maintainers who do not follow or enforce the Code of Conduct in good
-faith may face temporary or permanent repercussions as determined by other
-members of the project's leadership.
-
-## Attribution
-
-This Code of Conduct is adapted from the [Contributor Covenant][homepage],
-version 1.4, available at
-[http://contributor-covenant.org/version/1/4][version]
-
-[homepage]: http://contributor-covenant.org
-[version]: http://contributor-covenant.org/version/1/4/
+Please refer to our organization-wide
+[Code of Conduct](https://github.com/fatiando/community/blob/main/CODE_OF_CONDUCT.md).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ad43271f4..29806e81c 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -2,8 +2,8 @@
:tada: **First off, thank you for considering contributing to our project!** :tada:
-This is a community-driven project, so it's people like you that make it useful and
-successful.
+This is a community-driven project, so it's people like you that make it useful
+and successful.
These are some of the many ways to contribute:
* :bug: Submitting bug reports and feature requests
@@ -11,313 +11,31 @@ These are some of the many ways to contribute:
* :mag: Fixing typos and improving to the documentation
* :bulb: Writing code for everyone to use
-If you get stuck at any point you can create an issue on GitHub (look for the *Issues*
-tab in the repository) or contact us at one of the other channels mentioned below.
-
-For more information on contributing to open source projects,
-[GitHub's own guide](https://guides.github.com/activities/contributing-to-open-source/)
-is a great starting point if you are new to version control.
-Also, checkout the
-[Zen of Scientific Software Maintenance](https://jrleeman.github.io/ScientificSoftwareMaintenance/)
-for some guiding principles on how to create high quality scientific software
-contributions.
-
+**Please refer to our [organization-wide guidelines][contrib]**
+for general instructions on how to contribute to Fatiando projects.
## Ground Rules
The goal is to maintain a diverse community that's pleasant for everyone.
**Please be considerate and respectful of others**.
-Everyone must abide by our [Code of Conduct](CODE_OF_CONDUCT.md) and we encourage all to
-read it carefully.
-
-
-## Contents
-
-* [What Can I Do?](#what-can-i-do)
-* [How Can I Talk to You?](#how-can-i-talk-to-you)
-* [Getting credit for contributions](#getting-credit-for-contributions)
-* [Reporting a Bug](#reporting-a-bug)
-* [Editing the Documentation](#editing-the-documentation)
-* [Contributing Code](#contributing-code)
- - [General guidelines](#general-guidelines)
- - [Setting up your environment](#setting-up-your-environment)
- - [Code style](#code-style)
- - [Testing your code](#testing-your-code)
- - [Documentation](#documentation)
- - [Code Review](#code-review)
-
-
-## What Can I Do?
-
-* Tackle any issue that you wish! Some issues are labeled as **"good first issues"** to
- indicate that they are beginner friendly, meaning that they don't require extensive
- knowledge of the project.
-* Make a tutorial or example of how to do something.
-* Provide feedback about how we can improve the project or about your particular use
- case.
-* Contribute code you already have. It doesn't need to be perfect! We will help you
- clean things up, test it, etc.
-
+Everyone must abide by our [Code of Conduct][coc] and we encourage all to read
+it carefully.
-## How Can I Talk to You?
+## Authorship and credit
-Discussion often happens in the issues and pull requests.
-In addition, there is a [Slack chat room](http://contact.fatiando.org) for the
-Fatiando a Terra project where you can ask questions.
-
-
-## Getting credit for contributions
-
-We appreciate the effort that goes into making a contribution to our
-open-source projects. To say "thank you" and provide an extra incentive, we
-have established some criteria for giving credit to contributors in different
-ways: from having your name in the changelog, to authorship on academic
-publications. Please read the [Authorship Guidelines](AUTHORSHIP.md) for more
+We strive to adequately reward and credit all those who contribute to our
+project in any way.
+This can vary from an acknowledgment in the release notes to authorship in
+scientific publications.
+**Please refer to our [Authorship Guidelines][authorship]** for more
information.
+## For maintainers
-## Reporting a Bug
-
-Find the *Issues* tab on the top of the Github repository and click *New Issue*.
-You'll be prompted to choose between different types of issue, like bug reports and
-feature requests.
-Choose the one that best matches your need.
-The Issue will be populated with one of our templates.
-**Please try to fillout the template with as much detail as you can**.
-Remember: the more information we have, the easier it will be for us to solve your
-problem.
-
-
-## Editing the Documentation
-
-If you're browsing the documentation and notice a typo or something that could be
-improved, please consider letting us know by [creating an issue](#reporting-a-bug) or
-submitting a fix (even better :star2:).
-
-You can submit fixes to the documentation pages completely online without having to
-download and install anything:
-
-* On each documentation page, there should be an "Improve This Page" link at the very
- top.
-* Click on that link to open the respective source file (usually an `.rst` file in the
- `doc` folder) on Github for editing online (you'll need a Github account).
-* Make your desired changes.
-* When you're done, scroll to the bottom of the page.
-* Fill out the two fields under "Commit changes": the first is a short title describing
- your fixes; the second is a more detailed description of the changes. Try to be as
- detailed as possible and describe *why* you changed something.
-* Click on the "Commit changes" button to open a
- [pull request (see below)](#pull-requests).
-* We'll review your changes and then merge them in if everything is OK.
-* Done :tada::beer:
-
-Alternatively, you can make the changes offline to the files in the `doc` folder or the
-example scripts. See [Contributing Code](#contributing-code) for instructions.
-
-
-## Contributing Code
-
-**Is this your first contribution?**
-Please take a look at these resources to learn about git and pull requests (don't
-hesitate to [ask questions](#how-can-i-talk-to-you)):
-
-* [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/).
-* 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
-make changes to our codebase.
-Every change made goes through a pull request, even our own, so that our
-[continuous integration](https://en.wikipedia.org/wiki/Continuous_integration) services
-have a change to check that the code is up to standards and passes all our tests.
-This way, the *master* branch is always stable.
-
-General guidelines for pull requests (PRs):
-
-* **Open an issue first** describing what you want to do. If there is already an issue
- that matches your PR, leave a comment there instead to let us know what you plan to
- do.
-* Each pull request should consist of a **small** and logical collection of changes.
-* Larger changes should be broken down into smaller components and integrated
- separately.
-* Bug fixes should be submitted in separate PRs.
-* Describe what your PR changes and *why* this is a good thing. Be as specific as you
- can. The PR description is how we keep track of the changes made to the project over
- time.
-* Do not commit changes to files that are irrelevant to your feature or bugfix (eg:
- `.gitignore`, IDE project files, etc).
-* Write descriptive commit messages. Chris Beams has written a
- [guide](https://chris.beams.io/posts/git-commit/) on how to write good commit
- messages.
-* Be willing to accept criticism and work on improving your code; we don't want to break
- other users' code, so care must be taken not to introduce bugs.
-* Be aware that the pull request review process is not immediate, and is generally
- proportional to the size of the pull request.
-
-### Setting up your environment
-
-We highly recommend using [Anaconda](https://www.anaconda.com/download/) and the `conda`
-package manager to install and manage your Python packages.
-It will make your life a lot easier!
-
-The repository includes a conda environment file `environment.yml` with the
-specification for all development requirements to build and test the project.
-Once you have forked and clone the repository to your local machine, you use this file
-to create an isolated environment on which you can work.
-Run the following on the base of the repository:
-
-```bash
-conda env create
-```
-
-Before building and testing the project, you have to activate the environment:
-
-```bash
-conda activate ENVIRONMENT_NAME
-```
-
-You'll need to do this every time you start a new terminal.
-
-See the [`environment.yml`](environment.yml) file for the list of dependencies and the
-environment name.
-
-We have a [`Makefile`](Makefile) that provides commands for installing, running the
-tests and coverage analysis, running linters, etc.
-If you don't want to use `make`, open the `Makefile` and copy the commands you want to
-run.
-
-To install the current source code into your testing environment, run:
-
-```bash
-make install
-```
-
-This installs your project in *editable* mode, meaning that changes made to the source
-code will be available when you import the package (even if you're on a different
-directory).
-
-### Code style
-
-We use [Black](https://github.com/ambv/black) to format the code so we don't have to
-think about it.
-Black loosely follows the [PEP8](http://pep8.org) guide but with a few differences.
-Regardless, you won't have to worry about formatting the code yourself.
-Before committing, run it to automatically format your code:
-
-```bash
-make format
-```
-
-Don't worry if you forget to do it.
-Our continuous integration systems will warn us and you can make a new commit with the
-formatted code.
-
-We also use [flake8](http://flake8.pycqa.org/en/latest/) and
-[pylint](https://www.pylint.org/) to check the quality of the code and quickly catch
-common errors.
-The [`Makefile`](Makefile) contains rules for running both checks:
-
-```bash
-make check # Runs flake8 and black (in check mode)
-make lint # Runs pylint, which is a bit slower
-```
-
-#### Docstrings
-
-**All docstrings** should follow the
-[numpy style guide](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt).
-All functions/classes/methods should have docstrings with a full description of all
-arguments and return values.
-
-While the maximum line length for code is automatically set by *Black*, docstrings
-must be formatted manually. To play nicely with Jupyter and IPython, **keep docstrings
-limited to 79 characters** per line. We don't have a good way of enforcing this
-automatically yet, so please do your best.
-
-### Testing your code
-
-Automated testing helps ensure that our code is as free of bugs as it can be.
-It also lets us know immediately if a change we make breaks any other part of the code.
-
-All of our test code and data are stored in the `tests` subpackage.
-We use the [pytest](https://pytest.org/) framework to run the test suite.
-
-Please write tests for your code so that we can be sure that it won't break any of the
-existing functionality.
-Tests also help us be confident that we won't break your code in the future.
-
-If you're **new to testing**, see existing test files for examples of things to do.
-**Don't let the tests keep you from submitting your contribution!**
-If you're not sure how to do this or are having trouble, submit your pull request
-anyway.
-We will help you create the tests and sort out any kind of problem during code review.
-
-Run the tests and calculate test coverage using:
-
- make test
-
-The coverage report will let you know which lines of code are touched by the tests.
-**Strive to get 100% coverage for the lines you changed.**
-It's OK if you can't or don't know how to test something.
-Leave a comment in the PR and we'll help you out.
-
-### Documentation
-
-Most documentation sources are in the `doc` folder.
-We use [sphinx](http://www.sphinx-doc.org/) to build the web pages from these sources.
-To build the HTML files:
-
-```bash
-cd doc
-make all
-```
-
-This will build the HTML files in `doc/_build/html`.
-Open `doc/_build/html/index.html` in your browser to view the pages.
-
-The API reference is manually assembled in `doc/api/index.rst`.
-The *autodoc* sphinx extension will automatically create pages for each
-function/class/module listed there.
-
-You can reference classes, functions, and modules from anywhere (including docstrings)
-using :func:\`package.module.function\`
,
-:class:\`package.module.class\`
, or
-:mod:\`package.module\`
.
-Sphinx will create a link to the automatically generated page for that
-function/class/module.
-
-### Code Review
-
-After you've submitted a pull request, you should expect to hear at least a comment
-within a couple of days.
-We may suggest some changes or improvements or alternatives.
-
-Some things that will increase the chance that your pull request is accepted quickly:
-
-* Write a good and detailed description of what the PR does.
-* Write tests for the code you wrote/modified.
-* Readable code is better than clever code (even with comments).
-* Write documentation for your code (docstrings) and leave comments explaining the
- *reason* behind non-obvious things.
-* Include an example of new features in the gallery or tutorials.
-* Follow the [PEP8](http://pep8.org) style guide for code and the
- [numpy guide](https://github.com/numpy/numpy/blob/master/doc/HOWTO_DOCUMENT.rst.txt)
- for documentation.
+You'll find more information about project maintenance (releases, reviews, etc)
+in our organization-wide [Maintainers Guide][maintenance].
-Pull requests will automatically have tests run by TravisCI and AppVeyor.
-This includes running both the unit tests as well as code linters.
-Github will show the status of these checks on the pull request.
-Try to get them all passing (green).
-If you have any trouble, leave a comment in the PR or
-[get in touch](#how-can-i-talk-to-you).
+[coc]: https://github.com/fatiando/community/blob/main/CODE_OF_CONDUCT.md
+[contrib]: https://github.com/fatiando/community/blob/main/CONTRIBUTING.md
+[maintenance]: https://github.com/fatiando/community/blob/main/MAINTENANCE.md
+[authorship]: https://github.com/fatiando/community/blob/main/AUTHORSHIP.md
diff --git a/MAINTENANCE.md b/MAINTENANCE.md
deleted file mode 100644
index 97984d8c7..000000000
--- a/MAINTENANCE.md
+++ /dev/null
@@ -1,225 +0,0 @@
-# Maintainers Guide
-
-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
- branch. Make a new branch and submit a pull request instead.
-* *gh-pages*: Holds the HTML documentation and is served by Github. Pages for the master
- branch are in the `dev` folder. Pages for each release are in their own folders.
- **Automatically updated by TravisCI** so you shouldn't have to make commits here.
-
-
-## Reviewing and merging pull requests
-
-A few guidelines for reviewing:
-
-* Always **be polite** and give constructive feedback.
-* Welcome new users and thank them for their time, even if we don't plan on merging the
- PR.
-* Don't be harsh with code style or performance. If the code is bad, either (1) merge
- the pull request and open a new one fixing the code and pinging the original submitter
- (2) comment on the PR detailing how the code could be improved. Both ways are focused
- on showing the contributor **how to write good code**, not shaming them.
-
-Pull requests should be **squash merged**.
-This means that all commits will be collapsed into one.
-The main advantages of this are:
-
-* Eliminates experimental commits or commits to undo previous changes.
-* Makes sure every commit on master passes the tests and has a defined purpose.
-* The maintainer writes the final commit message, so we can make sure it's good and
- descriptive.
-
-
-## Continuous Integration
-
-We use GitHub Actions continuous integration (CI) services to build and
-test the project on Windows, Linux, and Mac.
-The configuration files for this service are in `.github/workflows`.
-They rely on the `requirements.txt`, `requirements-optional.txt`, etc
-files to install the required dependencies using conda or pip.
-
-The CI jobs include:
-
-* Running the test suite on multiple combinations of OS, Python version,
- with and without optional dependencies.
-* Running Black, flake8, and pylint to check the code for style.
-* Building the documentation to make sure it works.
-* Pushing the built documentation HTML to the `gh-pages` branch.
-* Upload source and wheel distributions to TestPyPI (on master) and PyPI
- (on releases).
-
-This way, most day-to-day maintenance operations are automatic.
-
-
-## Making a Release
-
-We try to automate the release process as much as possible.
-Travis handles publishing new releases to PyPI and updating the documentation.
-The version number is set automatically using setuptools-scm based on information it gets
-from git.
-There are a few steps that still must be done manually, though.
-
-### 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`](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.
-
-### Update the changelog
-
-1. Generate a list of commits between the last release tag and now:
-
- ```bash
- git log HEAD...v0.1.2 > changes.rst
- ```
-
-2. Edit the changes list to remove any trivial changes (updates to the README, typo
- fixes, CI configuration, etc).
-3. Replace the PR number in the commit titles with a link to the Github PR page. In Vim,
- use `` %s$#\([0-9]\+\)$`#\1 `__$g ``
- to make the change automatically.
-4. Copy the remaining changes to `doc/changes.rst` under a new section for the
- intended release.
-5. Add a list of people who contributed to the release (use `git shortlog HEAD...v1.2.0 -sne`).
-5. Include the DOI badge in the changelog. Remember to replace your DOI inside the badge
- url.
-
- ```
- .. image:: https://zenodo.org/badge/DOI/.svg
- :alt: Digital Object Identifier for the Zenodo archive
- :target: https://doi.org/
- ```
-
-6. Add a link to the new release version documentation in `README.rst`.
-7. Open a new PR with the updated changelog.
-
-### Check the README syntax
-
-Github is a bit forgiving when it comes to the RST syntax in the README but PyPI is not.
-So slightly broken RST can cause the PyPI page to not render the correct content. Check
-using the `rst2html.py` script that comes with docutils:
-
-```
-python setup.py --long-description | rst2html.py --no-raw > index.html
-```
-
-Open `index.html` and check for any flaws or error messages.
-
-### Release
-
-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` (`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 `changes.rst` file can be
- converted to Markdown using `pandoc`:
- ```
- pandoc -s changes.rst -o changes.md --wrap=none
- ```
-3. Publish the release.
-
-### Archive on Zenodo
-
-Grab a zip file from the Github release and upload to Zenodo using the previously
-reserved DOI.
-
-### Update the conda package
-
-After CI 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. 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`.
-
-## 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:
-
-
-
-This is an open-access publication. The paper and the associated reviews can be
-freely accessed at: https://doi.org/
-
-The link above includes full citation information and export formats (BibTeX,
-Mendeley, etc).
-```