From bb13b8744e7c5fb8ea76a209ef49b37070205777 Mon Sep 17 00:00:00 2001
From: bart1 <1662852+bart1@users.noreply.github.com>
Date: Wed, 26 Apr 2023 12:04:32 +0200
Subject: [PATCH] Update softwarereview_author.Rmd

fix #661 (maturing is being phased out)
---
 softwarereview_author.Rmd | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/softwarereview_author.Rmd b/softwarereview_author.Rmd
index b6b48d38f..c3f288b84 100644
--- a/softwarereview_author.Rmd
+++ b/softwarereview_author.Rmd
@@ -14,7 +14,7 @@ This concise guide presents the software peer review process for you as a packag
     - We strongly suggest submitting your package for review _before_ publishing on CRAN or submitting a software paper describing the package to a journal. Review feedback may result in major improvements and updates to your package, including renaming and breaking changes to functions.
     -   Do not submit your package for review while it or an associated manuscript is also under review at another venue, as this may result in conflicting requests for changes.
 - Please also consider the time and effort needed to respond to reviews: think about your availability or that of your collaborators in the next weeks and months following a submission. Note that reviewers are volunteers, and we ask that you respect their time and effort by responding in a timely and respectful manner.
-- If you use [repostatus.org badges](https://www.repostatus.org/) (which we recommend), submit when you're ready to get an _Active_ instead of _WIP_ badge. Similarly, if you use [lifecycle badges](https://www.tidyverse.org/lifecycle/), submission should happen when the package is at least _Maturing_.
+- If you use [repostatus.org badges](https://www.repostatus.org/) (which we recommend), submit when you're ready to get an _Active_ instead of _WIP_ badge. Similarly, if you use [lifecycle badges](https://www.tidyverse.org/lifecycle/), submission should happen when the package is _Stable_.
 - For any submission or pre-submission inquiry the README of your package should provide enough information about your package (goals, usage, similar packages) for the editors to assess its scope without having to install the package. Even better, set up a pkgdown website for allowing more detailed assessment of functionality online.
     - At the submission stage, all major functions should be stable enough to be fully documented and tested; the README should make a strong case for the package.
     - Your README file should strive to explain your package's functionality and aims, assuming readers have little to no domain knowledge. All technical tems, including references to other software, should be clarified.