Remove trailing whitespace in policies.md

Removes trailing whitespace in policies.md

Author: InessaPawson

our-process/policies.md

@@ -2,28 +2,28 @@
 
 ## Review Process Guidelines
 
-pyOpenSci packages are reviewed for quality, fit, scope, documentation, and 
-usability. The review process is similar to a manuscript review, however, it 
+pyOpenSci packages are reviewed for quality, fit, scope, documentation, and
+usability. The review process is similar to a manuscript review, however, it
 has a stronger focus on Python packaging best practices.
 
-Unlike a manuscript review, our peer review process is an ongoing conversation. 
-Once all major issues and questions are addressed, the review editor will make 
+Unlike a manuscript review, our peer review process is an ongoing conversation.
+Once all major issues and questions are addressed, the review editor will make
 a decision to accept, hold, or reject the package.
 
-Rejections are usually done early in the process, before the review process 
-begins. In rare cases, a package may also not be on-boarded into the pyOpenSci 
+Rejections are usually done early in the process, before the review process
+begins. In rare cases, a package may also not be on-boarded into the pyOpenSci
 ecosystem after review & revision.
 
-It is ultimately the editor’s decision on whether or not to reject the package 
+It is ultimately the editor’s decision on whether or not to reject the package
 based on how the reviews are addressed.
 
 ## Review Communication Approach
 
 Communication between authors, reviewers, and editors takes
-place on GitHub. You can, however choose to contact the editor by email if 
+place on GitHub. You can, however choose to contact the editor by email if
 needed.
 
-When submitting a package, please make sure that your GitHub notification 
+When submitting a package, please make sure that your GitHub notification
 settings are setup to notify you when you receive feedback on the review issue.
 
 ## Submitting Your Package for Review in Other Venues
@@ -34,8 +34,8 @@ 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.
 
-Applying reviewer or editor recommendations to your package can improve your 
-users' experience with future versions of your package even if your package is 
+Applying reviewer or editor recommendations to your package can improve your
+users' experience with future versions of your package even if your package is
 already published on `PyPI` or `conda-forge`.
 
 > Please do not submit your package for review while it or an associated
@@ -57,8 +57,8 @@ submit it to pyOpenSci for review. This provides:
 
 ## Conflict of Interest for Reviews and Editors
 
-Following criteria are meant to be a guide for what constitutes a conflict of 
-interest (COI) for an editor or reviewer. The potential editor or reviewer has 
+Following criteria are meant to be a guide for what constitutes a conflict of
+interest (COI) for an editor or reviewer. The potential editor or reviewer has
 a conflict of interest if:
 
 - The authors with a major role are from the potential reviewer/editor’s
@@ -80,103 +80,103 @@ 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 
+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, the issue will be closed.
 
 ## After Acceptance: Package Ownership and Maintenance
 
-Package authors are expected to maintain and develop their software and 
+Package authors are expected to maintain and develop their software and
 retain
-ownership of it after acceptance into pyOpenSci, as per the peer review 
-agreement acknowledged upon submission. This maintenance commitment should 
-last for at least two years. The pyOpenSci team will not interfere with 
+ownership of it after acceptance into pyOpenSci, as per the peer review
+agreement acknowledged upon submission. This maintenance commitment should
+last for at least two years. The pyOpenSci team will not interfere with
 day-to-day tool maintenance unless explicitly added as collaborators.
 
-If you need to step down from maintaining your accepted pyOpenSci package, 
-please promptly notify the pyOpenSci Editor-in-Chief or Software Review Lead. 
+If you need to step down from maintaining your accepted pyOpenSci package,
+please promptly notify the pyOpenSci Editor-in-Chief or Software Review Lead.
 pyOpenSci will collaborate with you to either:
 
 - Find a new maintainer or
 - Archive the tool, depending on what best suits your specific scientific
   Python package.
 
-We will reach out to our package maintainers each year to verify the 
-package is actively maintained and to see if there are any updates we can 
+We will reach out to our package maintainers each year to verify the
+package is actively maintained and to see if there are any updates we can
 highlight through our social channels.
 
 ### Maintenance Tracking
 
-pyOpenSci is building a system to track package metrics and activity, 
-including issues, pull requests, and dates of the last release and last commit 
-to the package repository. Activity is defined as a repository commit, pull 
+pyOpenSci is building a system to track package metrics and activity,
+including issues, pull requests, and dates of the last release and last commit
+to the package repository. Activity is defined as a repository commit, pull
 request, or release.
 
-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 
+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 fixes or messages from the pyOpenSci team, we will initiate 
-discussions about the package's ongoing inclusion within the pyOpenSci 
+If, after one year, package maintainers are unresponsive to requests for
+package fixes or messages from the pyOpenSci team, we will initiate
+discussions about the package's ongoing inclusion within the pyOpenSci
 ecosystem.
 
-In cases where a package is heavily used by the community, we may 
-collaborate with the community to identify reasonable next steps, such as 
-assisting in finding a new maintainer. If a solution for ongoing package 
-maintenance is not found, the package will be archived within the pyOpenSci 
+In cases where a package is heavily used by the community, we may
+collaborate with the community to identify reasonable next steps, such as
+assisting in finding a new maintainer. If a solution for ongoing package
+maintenance is not found, the package will be archived within the pyOpenSci
 ecosystem.
 
 If a sub-community decides to fork and maintain the package, we are open to
-working with the new maintainers to register the newly forked package within 
-our ecosystem. The original package will be archived with a link to the new 
+working with the new maintainers to register the newly forked package within
+our ecosystem. The original package will be archived with a link to the new
 fork.
 
 ### Quality Commitment
 
-pyOpenSci strives to develop and promote high quality research software. To 
-ensure that your software meets our criteria, we review all of our submissions 
-as part of the Software Peer Review process. We expect that you will continue 
+pyOpenSci strives to develop and promote high quality research software. To
+ensure that your software meets our criteria, we review all of our submissions
+as part of the Software Peer Review process. We expect that you will continue
 to maintain a package that has been accepted continually.
 
-Despite our best efforts to support contributed software, errors are the 
-responsibility of individual maintainers. Buggy, unmaintained software may 
-be removed from our suite at any time. We also ask maintainers that they get 
+Despite our best efforts to support contributed software, errors are the
+responsibility of individual maintainers. Buggy, unmaintained software may
+be removed from our suite at any time. We also ask maintainers that they get
 in touch with us if they do need to step down from maintaining a tool.
 
 ### Requesting Package Removal from the pyOpenSci Ecosystem
 
-In the unlikely scenario that a contributor of a package requests removal of 
-their package from our ecosystem, we retain the right offer the last / most 
-recently released version of that package in our ecosystem for archival 
+In the unlikely scenario that a contributor of a package requests removal of
+their package from our ecosystem, we retain the right offer the last / most
+recently released version of that package in our ecosystem for archival
 purposes only.
 
 ### Archiving a Package
 
-If a package appears to be no longer maintained, we may move to mark it as 
-archived which moves the package from our 
-[main package listing](https://www.pyopensci.org/python-packages.html#all-packages) 
-to our [archived packaging](https://www.pyopensci.org/python-packages.html#archived-packages) 
+If a package appears to be no longer maintained, we may move to mark it as
+archived which moves the package from our
+[main package listing](https://www.pyopensci.org/python-packages.html#all-packages)
+to our [archived packaging](https://www.pyopensci.org/python-packages.html#archived-packages)
 listing section.
 
-To archive a pyOpenSci approved package, add the 
-[archive label](https://github.com/pyOpenSci/software-submission/issues?q=label%3Aarchived) 
-to the original review issue. Once this label is applied to the issue, the 
-website will automatically update to reflect this status. If at any point 
-in the future, an archived package undergoes active maintenance again, this 
-label can be removed from the issue to move the package back to an active 
+To archive a pyOpenSci approved package, add the
+[archive label](https://github.com/pyOpenSci/software-submission/issues?q=label%3Aarchived)
+to the original review issue. Once this label is applied to the issue, the
+website will automatically update to reflect this status. If at any point
+in the future, an archived package undergoes active maintenance again, this
+label can be removed from the issue to move the package back to an active
 status.
 
-We opt to archive inactive packages rather than remove them to preserve the 
-history and contributions of the software, ensuring that others can still 
-access and learn from it. This approach maintains the integrity of the 
-scientific record and allows for potential future reactivation or forking 
-of the project. By archiving rather than removing, we provide a clear 
-status of the package while keeping its legacy intact for reference and 
+We opt to archive inactive packages rather than remove them to preserve the
+history and contributions of the software, ensuring that others can still
+access and learn from it. This approach maintains the integrity of the
+scientific record and allows for potential future reactivation or forking
+of the project. By archiving rather than removing, we provide a clear
+status of the package while keeping its legacy intact for reference and
 educational purposes.