feat(policy): add policy around on hold and stale reviews

README.md

@@ -4,7 +4,7 @@
 <!-- ALL-CONTRIBUTORS-BADGE:END -->
 
 ![GitHub release (latest by date)](https://img.shields.io/github/v/release/pyopensci/peer-review-guide?color=purple&display_name=tag&style=plastic)
-[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.7641670.svg)](https://doi.org/10.5281/zenodo.7101777) 
+[![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.7641670.svg)](https://doi.org/10.5281/zenodo.7101777)
 ![deploy-book](https://github.com/pyOpenSci/peer-review-guide/actions/workflows/build-book.yml/badge.svg) [![CircleCI](https://circleci.com/gh/pyOpenSci/software-peer-review.svg?style=svg)](https://app.circleci.com/pipelines/github/pyOpenSci/software-peer-review)
 
 https://www.pyopensci.org/peer-review-guide/

our-process/policies.md

@@ -22,10 +22,8 @@ When submitting a package, please make sure that your GitHub notification settin
 
 ## Submitting your package for review in other venues
 
-We recommend submitting your package for review with pyOpenSci before:
-
-- publishing to a package repository, such as `PyPI` and `conda-forge`;
-- submitting a software paper describing the package to a journal.
+We recommend submitting your package for review with pyOpenSci before
+submitting a software paper describing the package to a journal.
 
 Review feedback may result in major improvements and updates to your package,
 including changes that could be break package functionality.
@@ -46,6 +44,7 @@ submit it to pyOpenSci for review. This provides:
 - We will also keep in touch with you as a maintainer to support long term maintenance. If you need to step down from maintaining your package we will help find a new maintainer and/or help sunset the tool.
 
 (coi)=
+
 ### Conflict of interest for reviews and editors
 
 Following criteria are meant to be a guide for what constitutes a conflict of interest
@@ -64,6 +63,10 @@ if:
 In the case where none of the associate editors can serve as editor, an
 external guest editor will be recruited to lead the package review.
 
+## Review timelines and on-hold reviews
+
+At any time, an author can choose to have their submission put on hold (the editor applies the `on-hold` label to the GitHub issue). The `on-hold` status will be revisited every 3 months. If after one year there has been no movement on the review, then the issue will be closed.
+
 ## After Acceptance: Package Ownership and Maintenance
 
 Package authors are expected to maintain and develop their software and retain
@@ -91,6 +94,7 @@ the last release and last commit to the package repository. Activity is defined
 We will flag packages that haven't been updated within a 1 year/ 12 month time period based on activity. Packages with no activity after 12 months will be flagged. At that time, pyOpenSci editorial team member will contact the package maintainers to evaluate the maintenance status of their package.
 
 (archive-process)=
+
 ## Package Maintenance and Maintainer Responsiveness
 
 If, after one year, package maintainers are unresponsive to requests for package

partners/pangeo.md

@@ -29,4 +29,3 @@ defined by the Pangeo community.
     - [Tutorial on using Dask and lazy loading](https://tutorial.dask.org/01_dataframe.html)
 
 - **Use existing data reading and writing libraries rather than creating your own:** In general, your package should use existing libraries for reading and writing data (e.g. xarray, pandas, geopandas, or the libraries those are built on like Zarr, GDAL, pyarrow, etc.) and should not include its own custom code for read/write data operations. These tools already read and write a variety of file types to a variety of file systems that are important to Pangeo users, including Cloud Object storage.
-  [See 2i2c documentation for more on cloud native file format support.](https://docs.2i2c.org/user/topics/data/cloud/#cloud-native-formats)