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). -```