├── _static ├── logo.png ├── logo-dark-mode.png ├── logo-light-mode.png ├── fonts │ ├── poppins-v20-latin-500.woff2 │ ├── poppins-v20-latin-600.woff2 │ ├── poppins-v20-latin-700.woff2 │ ├── itim-v14-latin-regular.woff2 │ ├── poppins-v20-latin-italic.woff2 │ ├── poppins-v20-latin-regular.woff2 │ └── poppins-v20-latin-700italic.woff2 ├── matomo.js └── pyos.css ├── images ├── assign-issue.png ├── astropy-banner-dark.png ├── pyos-review-starting.png ├── dashboard-last-updated.png ├── pyopensci-pillars-flower.png ├── dashboard-last-comment-date.png ├── python-stack-jupyter-earth.png ├── peer-review-metrics-dashboard.png ├── peer-review-partners-process.png ├── pyopensci-joss-review-labels.png ├── pyopensci-pre-commit-autofix.png ├── pyos-accepted-package-message.png ├── pyos-partnerships-peer-review.png ├── github-pyos-contributors-action.png ├── pyopensci-accepted-review-labels.png ├── pyos-discourse-packages-channel.png ├── pyos-running-contributor-action.png ├── pyos-under-review-project-board.png └── astropy_project_logo.svg ├── requirements.txt ├── LICENSE ├── code-of-conduct.md ├── appendices ├── issue-review-template.md ├── gen-ai-checklist.md ├── editor-initial-response-template.md ├── reviewer-request-template.md ├── glossary.md ├── package-approval-template.md ├── editor-in-chief-checks.md ├── templates.md └── review-template.md ├── .circleci └── config.yml ├── .github └── workflows │ ├── help_wanted.yaml │ ├── artifact_redirect.yml │ └── build-book.yml ├── changelog.md ├── pyproject.toml ├── about ├── why-open-review.md ├── benefits.md ├── our-goals.md └── intro.md ├── .pre-commit-config.yaml ├── noxfile.py ├── .gitignore ├── CONTRIBUTING.md ├── partners ├── pangeo.md ├── astropy.md └── joss.md ├── our-process ├── how-review-works.md ├── review-timeline.md └── policies.md ├── .zenodo.json ├── index.md ├── how-to ├── finding-reviewers.md ├── peer-review-lead.md ├── reviewer-guide.md ├── review-triage-team.md ├── onboarding-guide.md └── author-guide.md ├── conf.py └── .all-contributorsrc /_static/logo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/logo.png -------------------------------------------------------------------------------- /images/assign-issue.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/assign-issue.png -------------------------------------------------------------------------------- /_static/logo-dark-mode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/logo-dark-mode.png -------------------------------------------------------------------------------- /_static/logo-light-mode.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/logo-light-mode.png -------------------------------------------------------------------------------- /images/astropy-banner-dark.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/astropy-banner-dark.png -------------------------------------------------------------------------------- /images/pyos-review-starting.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-review-starting.png -------------------------------------------------------------------------------- /images/dashboard-last-updated.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/dashboard-last-updated.png -------------------------------------------------------------------------------- /images/pyopensci-pillars-flower.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyopensci-pillars-flower.png -------------------------------------------------------------------------------- /images/dashboard-last-comment-date.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/dashboard-last-comment-date.png -------------------------------------------------------------------------------- /images/python-stack-jupyter-earth.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/python-stack-jupyter-earth.png -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-500.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-500.woff2 -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-600.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-600.woff2 -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-700.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-700.woff2 -------------------------------------------------------------------------------- /images/peer-review-metrics-dashboard.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/peer-review-metrics-dashboard.png -------------------------------------------------------------------------------- /images/peer-review-partners-process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/peer-review-partners-process.png -------------------------------------------------------------------------------- /images/pyopensci-joss-review-labels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyopensci-joss-review-labels.png -------------------------------------------------------------------------------- /images/pyopensci-pre-commit-autofix.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyopensci-pre-commit-autofix.png -------------------------------------------------------------------------------- /images/pyos-accepted-package-message.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-accepted-package-message.png -------------------------------------------------------------------------------- /images/pyos-partnerships-peer-review.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-partnerships-peer-review.png -------------------------------------------------------------------------------- /_static/fonts/itim-v14-latin-regular.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/itim-v14-latin-regular.woff2 -------------------------------------------------------------------------------- /images/github-pyos-contributors-action.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/github-pyos-contributors-action.png -------------------------------------------------------------------------------- /images/pyopensci-accepted-review-labels.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyopensci-accepted-review-labels.png -------------------------------------------------------------------------------- /images/pyos-discourse-packages-channel.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-discourse-packages-channel.png -------------------------------------------------------------------------------- /images/pyos-running-contributor-action.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-running-contributor-action.png -------------------------------------------------------------------------------- /images/pyos-under-review-project-board.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/images/pyos-under-review-project-board.png -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-italic.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-italic.woff2 -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-regular.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-regular.woff2 -------------------------------------------------------------------------------- /_static/fonts/poppins-v20-latin-700italic.woff2: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/pyOpenSci/software-peer-review/HEAD/_static/fonts/poppins-v20-latin-700italic.woff2 -------------------------------------------------------------------------------- /requirements.txt: -------------------------------------------------------------------------------- 1 | pyos-sphinx-theme 2 | myst-nb 3 | sphinx 4 | sphinx-autobuild 5 | sphinx-copybutton 6 | sphinx-design 7 | # XML feed for analytics 8 | sphinx-sitemap 9 | # Support for social / adds meta tags 10 | sphinxext-opengraph 11 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | All content in this book (ie, any files and content in the `content/` folder) 2 | is licensed under the 3 | [Creative Commons Attribution-ShareAlike 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/) (CC BY-SA 4.0) license. 4 | -------------------------------------------------------------------------------- /code-of-conduct.md: -------------------------------------------------------------------------------- 1 | # pyOpenSci Code of Conduct 2 | 3 | All individuals participating in any pyOpenSci program such as our peer review process, need to abide by our code of conduct. 4 | 5 | [Click here to 6 | read our full code of conduct now.](https://www.pyopensci.org/handbook/CODE_OF_CONDUCT.html) 7 | -------------------------------------------------------------------------------- /_static/matomo.js: -------------------------------------------------------------------------------- 1 | // Matomo analytics 2 | var _paq = window._paq = window._paq || []; 3 | /* tracker methods like "setCustomDimension" should be called before "trackPageView" */ 4 | _paq.push(['trackPageView']); 5 | _paq.push(['enableLinkTracking']); 6 | (function() { 7 | var u="https://pyopensci.matomo.cloud/"; 8 | _paq.push(['setTrackerUrl', u+'matomo.php']); 9 | _paq.push(['setSiteId', '2']); 10 | var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0]; 11 | g.async=true; g.src='//cdn.matomo.cloud/pyopensci.matomo.cloud/matomo.js'; s.parentNode.insertBefore(g,s); 12 | })(); 13 | -------------------------------------------------------------------------------- /appendices/issue-review-template.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | --- 3 | name: Submit Software for Review 4 | about: Use to submit your Python package for pyOpenSci peer review 5 | title: '' 6 | labels: 1/editor-checks, New Submission! 7 | assignees: '' 8 | --- 9 | Submitting Author: Name (@github_handle) 10 | All current maintainers: (@github_handle1, @github_handle2) 11 | Package Name: Package name here 12 | One-Line Description of Package: Description here 13 | Repository Link: 14 | Version submitted: 15 | Editor: TBD 16 | Reviewer 1: TBD 17 | Reviewer 2: TBD 18 | Archive: TBD 19 | Version accepted: TBD 20 | Date accepted (month/day/year): TBD 21 | --- 22 | ``` 23 | -------------------------------------------------------------------------------- /.circleci/config.yml: -------------------------------------------------------------------------------- 1 | version: 2.1 2 | jobs: 3 | build-book: 4 | docker: 5 | - image: cimg/python:3.9 6 | steps: 7 | - checkout 8 | - run: 9 | name: setup environment 10 | command: | 11 | pip install --upgrade pip 12 | pip install nox 13 | pip list 14 | - run: 15 | name: Build book html 16 | command: nox -s docs 17 | 18 | - store_artifacts: 19 | path: _build/html 20 | destination: html 21 | 22 | # Tell CircleCI to use this workflow when it builds the site 23 | workflows: 24 | version: 2 25 | build_book: 26 | jobs: 27 | - build-book 28 | -------------------------------------------------------------------------------- /.github/workflows/help_wanted.yaml: -------------------------------------------------------------------------------- 1 | name: Add help-wanted issues to help wanted board 2 | 3 | on: 4 | issues: 5 | types: 6 | - labeled 7 | 8 | jobs: 9 | add-help-wanted: 10 | runs-on: ubuntu-latest 11 | steps: 12 | - name: Add issue to project 13 | id: add-to-project 14 | uses: actions/add-to-project@v1.0.1 15 | with: 16 | project-url: https://github.com/orgs/pyOpenSci/projects/3 17 | # This is a organization level token so it can be used across all repos in our org 18 | github-token: ${{ secrets.GHPROJECT_HELP_WANTED }} 19 | labeled: help wanted, sprintable 20 | label-operator: OR 21 | -------------------------------------------------------------------------------- /.github/workflows/artifact_redirect.yml: -------------------------------------------------------------------------------- 1 | name: CircleCI artifacts redirector 2 | on: [status] 3 | 4 | concurrency: 5 | group: docs-preview-${{ github.ref }} 6 | cancel-in-progress: true 7 | 8 | jobs: 9 | circleci_artifacts_redirector_job: 10 | runs-on: ubuntu-latest 11 | # For testing this action on a fork, remove the "github.repository =="" condition. 12 | if: "github.event.context == 'ci/circleci: build-book'" 13 | permissions: 14 | statuses: write 15 | name: Run CircleCI artifacts redirector 16 | steps: 17 | - name: GitHub Action step 18 | id: step1 19 | uses: larsoner/circleci-artifacts-redirector-action@master 20 | with: 21 | repo-token: ${{ secrets.GITHUB_TOKEN }} 22 | api-token: ${{ secrets.CIRCLECI_TOKEN }} 23 | artifact-path: 0/html/index.html 24 | circleci-jobs: build-book 25 | job-title: View rendered book here! 26 | -------------------------------------------------------------------------------- /changelog.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | ## v0.5 - Jan 31 2023 release 4 | 21 Dec 2022 5 | This release followed a significant review with numerous contributors. 6 | 7 | ### Contributors 8 | 9 | @rabernat @TomAugspurger @Batalex @nickledav @lwasser @arianesasso 10 | @sneakers-the-rat 11 | 12 | 13 | ## v0.4 - Dec 2022 release 14 | 21 Dec 2022 15 | This release followed a significant review with numerous contributors. 16 | 17 | ### Contributors 18 | Note: some contributors may be missing for this release but all are 19 | recognized in the jan 2023 release above. 20 | @nickledav @lwasser @arianesasso @willingc 21 | 22 | ## v0.3b - Fall 2022 release (post funding) 23 | 26 September 2022 24 | 25 | This is a release in the fall 2022 that began to tease out peer review 26 | guide materials from packaging guide. 27 | 28 | ### Contributors 29 | @nickledav @lwasser @kysolvik @xmnlab 30 | 31 | ## v0.1 - Initial Release 32 | 20 October 2018 - Initial peer review guide was called contributing 33 | guide. it contained a mixture of what is now our packaging guide and 34 | this peer review guide content 35 | 36 | ### Contributors 37 | @choldgraf, @kysolvik 38 | -------------------------------------------------------------------------------- /pyproject.toml: -------------------------------------------------------------------------------- 1 | [build-system] 2 | requires = ["hatchling", "hatch-vcs"] 3 | build-backend = "hatchling.build" 4 | 5 | [project] 6 | name = "peer-review-guide" 7 | dynamic = [ 8 | "version" 9 | ] 10 | dependencies = [ 11 | "pyos_sphinx_theme", 12 | "myst-nb", 13 | "sphinx", 14 | "sphinx-autobuild", 15 | "sphinx-copybutton", 16 | "sphinx-design", 17 | "sphinx-favicon", 18 | "sphinx-togglebutton", 19 | # XML feed for analytics 20 | "sphinx-sitemap", 21 | # Support for social / adds meta tags 22 | "sphinxext-opengraph", 23 | "sphinx-inline-tabs", 24 | # for project cards 25 | "matplotlib", 26 | "pandas", 27 | "sphinx-codeautolink", 28 | "rich", 29 | "sphinxcontrib-youtube", 30 | ] 31 | 32 | [project.optional-dependencies] 33 | dev = [ 34 | # for general build workflows 35 | "nox", 36 | ] 37 | 38 | [tool.hatch.build.targets.wheel] 39 | bypass-selection = true 40 | 41 | [tool.hatch] 42 | version.source = "vcs" 43 | 44 | 45 | # https://github.com/codespell-project/codespell#usage 46 | [tool.codespell] 47 | #ignore-words = "codespell-ignore.txt" 48 | skip = "./.git,./.nox,./_static,./_build,codespell-ignore.txt,*.svg" 49 | 50 | 51 | [tool.jupytext] 52 | # Pair ipynb notebooks to py:percent text notebooks 53 | formats = "ipynb,myst" 54 | -------------------------------------------------------------------------------- /about/why-open-review.md: -------------------------------------------------------------------------------- 1 | # Our Software Peer Review is Open 2 | 3 | Our reviewing threads are public. Authors, reviewers, and editors all know 4 | each other’s identities. The broader community can view or even participate 5 | in the conversation as it happens. This provides an incentive to be thorough 6 | and provide non-adversarial, constructive reviews. 7 | 8 | It also has the benefit of building a community. Participants have the 9 | opportunity to meaningfully network with new peers, and new collaborations 10 | have emerged via ideas spawned during the review process. 11 | 12 | We are aware that open systems can have drawbacks. For instance, in 13 | traditional academic review, [double-blind peer review can increase representation of female authors](https://www.sciencedirect.com/science/article/pii/S0169534707002704), 14 | suggesting bias in non-blind reviews. 15 | 16 | It is also possible reviewers are less critical in open review. However, we 17 | believe that the openness of the review conversation provides a check on 18 | review quality and bias; it’s harder to inject unsupported or subjective 19 | comments in public and without the cover of anonymity. 20 | 21 | > Ultimately, we 22 | > believe that having direct and public communication between authors and 23 | > reviewers improves quality and fairness of reviews. 24 | -------------------------------------------------------------------------------- /appendices/gen-ai-checklist.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | - [ ] Generative AI was used to produce some of the material in this submission. 3 | - [ ] If generative AI was used in this project, the authors affirm that all generated material has been reviewed and edited for clarity, correctness, and completeness. The authors are responsible for the content of their work and affirm that it is in a state where reviewers will not be responsible for primary editing and review of machine-generated material. 4 | 5 | If you checked the first box above, please describe how generative AI was used, including: 6 | 7 | - **Which parts** of the submission were generated (e.g., documentation, tests, code). In addition to a general description, please specifically indicate any substantial portions of code (classes, modules, subpackages) that were wholly or primarily generated by AI. 8 | - **The approximate scale** of the generated portions (e.g., "all of the tests were generated and then checked by a human," "small routines were generated and copied into the code"). 9 | - **How the generative AI was used** (e.g., line completion, help with translation, queried separately and integrated, agentic workflow). 10 | 11 | If you have a policy around generative AI use in your project, please provide a link to it below: 12 | 13 | - _Your link here (remove this line if you don't have a link)_ 14 | ``` 15 | -------------------------------------------------------------------------------- /appendices/editor-initial-response-template.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | ## Editor response to review: 3 | 4 | --- 5 | 6 | ## Editor comments 7 | 8 | 9 | 10 | 11 | ### Please fill out our pre-review survey 12 | Before beginning your review, please fill out our [pre-review survey](https://forms.gle/F9mou7S3jhe8DMJ16). This helps us improve all aspects of our review and better understand our community. No personal data will be shared from this survey - it will only be used in an aggregated format by our Executive Director to improve our processes and programs. 13 | - [ ] reviewer 1 survey completed. 14 | - [ ] reviewer 2 survey completed. 15 | - [ ] reviewer 3 (if applicable) 16 | 17 | 18 | The following resources will help you complete your review: 19 | 20 | 1. Here is the **[reviewers guide](https://www.pyopensci.org/software-peer-review/how-to/reviewer-guide.html)**. This guide contains all of the steps and information needed to complete your review. 21 | 2. Here is the **[review template](https://www.pyopensci.org/software-peer-review/how-to/reviewer-guide.html#peer-review-template)** that you will need to fill out and submit 22 | here as a comment, once your review is complete. 23 | 24 | Please get in touch with any questions or concerns! Your review is due: 25 | --- 26 | 27 | Reviewers: 28 | Due date: 29 | ``` 30 | -------------------------------------------------------------------------------- /.pre-commit-config.yaml: -------------------------------------------------------------------------------- 1 | # pre-commit is a tool that you run locally 2 | # to perform a predefined set of tasks manually and/or 3 | # automatically before git commits are made. 4 | # Here we are using pre-commit with the precommit.ci bot to implement 5 | # code fixes automagically in pr's. You will still want to install pre-commit 6 | # to run locally 7 | # Config reference: https://pre-commit.com/#pre-commit-configyaml---top-level 8 | # To run on a pr, add a comment with the text "pre-commit.ci run" 9 | # Common tasks 10 | # 11 | # - Run on all files: pre-commit run --all-files 12 | # - Register git hooks: pre-commit install --install-hooks 13 | 14 | ci: 15 | autofix_prs: false 16 | #skip: [flake8, end-of-file-fixer] 17 | autofix_commit_msg: | 18 | '[pre-commit.ci 🤖] Apply code format tools to PR' 19 | # Update hook versions every quarter (so we don't get hit with weekly update pr's) 20 | autoupdate_schedule: quarterly 21 | 22 | repos: 23 | 24 | # Misc commit checks 25 | - repo: https://github.com/pre-commit/pre-commit-hooks 26 | rev: v6.0.0 27 | # ref: https://github.com/pre-commit/pre-commit-hooks#hooks-available 28 | hooks: 29 | # Autoformat: Makes sure files end in a newline and only a newline. 30 | - id: end-of-file-fixer 31 | # Lint: Check for files with names that would conflict on a 32 | # case-insensitive filesystem like MacOS HFS+ or Windows FAT. 33 | - id: check-case-conflict 34 | - id: trailing-whitespace 35 | 36 | - repo: https://github.com/codespell-project/codespell 37 | rev: v2.4.1 38 | hooks: 39 | - id: codespell 40 | -------------------------------------------------------------------------------- /noxfile.py: -------------------------------------------------------------------------------- 1 | import nox 2 | import pathlib 3 | 4 | nox.options.reuse_existing_virtualenvs = True 5 | 6 | build_command = ["-b", "html", ".", "_build/html"] 7 | 8 | AUTOBUILD_IGNORE = [ 9 | "_build", 10 | ".nox", 11 | "build_assets", 12 | "tmp", 13 | ".pytest_cache", 14 | ] 15 | 16 | # Sphinx output and source directories 17 | BUILD_DIR = "_build" 18 | OUTPUT_DIR = pathlib.Path(BUILD_DIR, "html") 19 | SOURCE_DIR = pathlib.Path(".") 20 | 21 | # Sphinx build commands 22 | SPHINX_BUILD = "sphinx-build" 23 | SPHINX_AUTO_BUILD = "sphinx-autobuild" 24 | 25 | # Sphinx parameters used to build the guide 26 | BUILD_PARAMETERS = ["-b", "html"] 27 | 28 | # Sphinx parameters used to test the build of the guide 29 | TEST_PARAMETERS = ["-W", "--keep-going", "-E", "-a"] 30 | 31 | 32 | @nox.session 33 | def docs(session): 34 | session.install("-r", "requirements.txt") 35 | cmd = ["sphinx-build"] 36 | cmd.extend(build_command + session.posargs) 37 | session.run(*cmd) 38 | 39 | 40 | @nox.session(name="docs-live") 41 | def docs_live(session): 42 | session.install("-r", "requirements.txt") 43 | cmd = ["sphinx-autobuild"] 44 | for folder in AUTOBUILD_IGNORE: 45 | cmd.extend(["--ignore", f"*/{folder}/*"]) 46 | cmd.extend(build_command + session.posargs) 47 | session.run(*cmd) 48 | 49 | 50 | @nox.session(name="docs-test") 51 | def docs_test(session): 52 | """ 53 | Build the packaging guide with more restricted parameters. 54 | 55 | Note: this is the session used in CI/CD to release the guide. 56 | """ 57 | session.install("-e", ".") 58 | session.run( 59 | SPHINX_BUILD, 60 | *BUILD_PARAMETERS, 61 | *TEST_PARAMETERS, 62 | SOURCE_DIR, 63 | OUTPUT_DIR, 64 | *session.posargs, 65 | ) 66 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | # Byte-compiled / optimized / DLL files 2 | __pycache__/ 3 | *.py[cod] 4 | *$py.class 5 | 6 | # C extensions 7 | *.so 8 | 9 | # Distribution / packaging 10 | .Python 11 | build/ 12 | develop-eggs/ 13 | dist/ 14 | downloads/ 15 | eggs/ 16 | .eggs/ 17 | lib/ 18 | lib64/ 19 | parts/ 20 | sdist/ 21 | var/ 22 | wheels/ 23 | *.egg-info/ 24 | .installed.cfg 25 | *.egg 26 | MANIFEST 27 | 28 | # PyInstaller 29 | # Usually these files are written by a python script from a template 30 | # before PyInstaller builds the exe, so as to inject date/other infos into it. 31 | *.manifest 32 | *.spec 33 | 34 | # Installer logs 35 | pip-log.txt 36 | pip-delete-this-directory.txt 37 | 38 | # Unit test / coverage reports 39 | htmlcov/ 40 | .tox/ 41 | .coverage 42 | .coverage.* 43 | .cache 44 | nosetests.xml 45 | coverage.xml 46 | *.cover 47 | .hypothesis/ 48 | .pytest_cache/ 49 | 50 | # Translations 51 | *.mo 52 | *.pot 53 | 54 | # Django stuff: 55 | *.log 56 | local_settings.py 57 | db.sqlite3 58 | 59 | # Flask stuff: 60 | instance/ 61 | .webassets-cache 62 | 63 | # Scrapy stuff: 64 | .scrapy 65 | 66 | # PyBuilder 67 | target/ 68 | 69 | # Jupyter Notebook 70 | .ipynb_checkpoints 71 | 72 | # pyenv 73 | .python-version 74 | 75 | # celery beat schedule file 76 | celerybeat-schedule 77 | 78 | # SageMath parsed files 79 | *.sage.py 80 | 81 | # Environments 82 | .env 83 | .venv 84 | env/ 85 | venv/ 86 | ENV/ 87 | env.bak/ 88 | venv.bak/ 89 | 90 | # Spyder project settings 91 | .spyderproject 92 | .spyproject 93 | 94 | # Rope project settings 95 | .ropeproject 96 | 97 | # mkdocs documentation 98 | /site 99 | 100 | # mypy 101 | .mypy_cache/ 102 | 103 | # Jekyll 104 | _site/ 105 | .sass-cache 106 | 107 | # Test builds 108 | _build 109 | 110 | .DS_Store 111 | -------------------------------------------------------------------------------- /appendices/reviewer-request-template.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | Dear [REVIEWER-Name], 3 | 4 | Hi, this is [EDITOR-Name]. [FRIENDLY BANTER]. I'm writing to ask if you have time 5 | to review a package for pyOpenSci. pyOpenSci has an open peer review of open source Python packages that support science. Accepted packages become a part of our pyOpenSci ecosystem of vetted community-adopted tools. Our review process is similar to that 6 | of open journals however it focuses on ensuring high quality packaging approaches 7 | that are inline with community adopted Python standards. 8 | 9 | The package, [PACKAGE] by [AUTHOR(S)], does [FUNCTION]. You can find it on GitHub here: [REPO LINK]. We conduct our open review process via GitHub as well, here: [ONBOARDING ISSUE] 10 | 11 | If you accept, note that we ask reviewers to complete reviews in three weeks (We’ve found it takes a similar amount of time to review a package as an academic paper.). 12 | 13 | Our [reviewers guide](https://www.pyopensci.org/software-peer-review/how-to/reviewer-guide.html) details what we look for in a package review, and includes links to example reviews. 14 | We also include a reviewer template on that page that you can use to guide your review. Our Python packaging standards are detailed in our [packaging guide](https://www.pyopensci.org/python-package-guide). 15 | 16 | If you have time, please have a look at the package first, to make 17 | sure that you do not have a conflict of interest with the package authors. 18 | 19 | If you have questions or feedback, feel free to ask me. 20 | 21 | {IF APPLICABLE: The authors have also chosen to jointly submit their package to the Journal of Open Source Software, so this package includes a short `paper.md` manuscript describing the software that we ask you include in your review.} 22 | 23 | Are you able to review? If you can not, I welcome any suggestions that you 24 | have for other reviewers. If I don't hear from you within a week, I will assume 25 | that you are unable to review this package at this time. 26 | 27 | Thank you for your time. 28 | 29 | Sincerely, 30 | 31 | [EDITOR] 32 | ``` 33 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Contributing Guide for the Python open source software packaging book 2 | 3 | Important! Before contributing to this repository, please be sure to review 4 | our [organization-wide contributing guide](https://www.pyopensci.org/handbook/CONTRIBUTING.html) which contains guidelines for 5 | contributions. 6 | 7 | This is a community resource. We welcome contributions in the form of issues and/or pull requests to this guide. 8 | 9 | - If you have an idea for something that should be included in the guide, [please open an issue here](https://github.com/pyOpenSci/python-package-guide/issues). 10 | - If you find a typo, feel free to [submit a pull request](https://github.com/pyOpenSci/python-package-guide/pulls) to modify the text directly. Or, if you are less comfortable with pull requests, feel free to open an issue. 11 | - If you want to see a larger change to the content of the guide book, please submit an issue first! 12 | 13 | ## How this guide is structured 14 | 15 | This guide is built using **Sphinx**, a documentation engine built in `Python` and the pydata_sphinx_theme. We use `myST` syntax to create each page in this book. 16 | 17 | If you wish to contribute by working on the guide book locally, you 18 | will first need to 19 | 20 | 1. Fork this repository 21 | 2. Clone it locally 22 | 3. Build the documentation locally 23 | 24 | ## Instructions for building the documentation locally on your computer 25 | 26 | The easiest way to build the documentation in this repository is to use `nox`, 27 | a tool for quickly building environments and running commands within them. 28 | Nox ensures that your environment has all the dependencies needed to build the documentation. 29 | 30 | To do so, follow these steps: 31 | 32 | 1. Install `nox` 33 | 34 | ``` 35 | pip install nox 36 | ``` 37 | 38 | 2. Build the documentation: 39 | 40 | ``` 41 | nox -s docs_build 42 | ``` 43 | 44 | This should create a local environment in a `.nox` folder, build the documentation (as specified in the `noxfile.py` configuration), and the output will be in `_build/html`. 45 | 46 | To build live documentation that updates when you update local files, run the following command: 47 | 48 | ``` 49 | nox -s docs_live 50 | ``` 51 | -------------------------------------------------------------------------------- /.github/workflows/build-book.yml: -------------------------------------------------------------------------------- 1 | name: deploy-book 2 | 3 | on: 4 | pull_request: 5 | push: 6 | branches: 7 | - main 8 | 9 | # This job installs dependencies, build the book, and pushes it to `gh-pages` 10 | jobs: 11 | build-test-book: 12 | runs-on: ubuntu-latest 13 | steps: 14 | - uses: actions/checkout@v4 15 | 16 | - name: Setup Python 17 | uses: actions/setup-python@v5 18 | with: 19 | python-version: "3.9" 20 | 21 | - name: Upgrade pip 22 | run: | 23 | # install pip=>20.1 to use "pip cache dir" 24 | python3 -m pip install --upgrade pip 25 | - name: Get pip cache dir 26 | id: pip-cache 27 | run: echo "::set-output name=dir::$(pip cache dir)" 28 | 29 | - name: Cache dependencies 30 | uses: actions/cache@v4 31 | with: 32 | path: ${{ steps.pip-cache.outputs.dir }} 33 | key: ${{ runner.os }}-pip-${{ hashFiles('**/requirements.txt') }} 34 | restore-keys: | 35 | ${{ runner.os }}-pip- 36 | 37 | - name: Install dependencies 38 | run: python3 -m pip install nox 39 | 40 | - name: Build book 41 | run: nox -s docs 42 | 43 | # Push the book's HTML to github-pages 44 | - name: Push to GitHub Pages 45 | # Only push if on main branch 46 | if: github.ref == 'refs/heads/main' 47 | uses: peaceiris/actions-gh-pages@v3.9.3 48 | with: 49 | github_token: ${{ secrets.GITHUB_TOKEN }} 50 | publish_dir: "./_build/html" 51 | 52 | # Test for bad links and ensure alt tags for usability 53 | - name: Check HTML using htmlproofer 54 | uses: chabad360/htmlproofer@master 55 | with: 56 | directory: ./_build/html 57 | arguments: | 58 | --ignore-files "/.+\/_static\/.+/" 59 | --ignore-status-codes "0, 200, 301, 401, 403, 429, 503" 60 | --ignore-urls "https://github.com/pyOpenSci/software-review/issues/18#issuecomment-581752433" 61 | 62 | # Save html as artifact 63 | - name: Save book html as artifact for viewing 64 | uses: actions/upload-artifact@v4 65 | with: 66 | name: book-html 67 | path: | 68 | ./_build/html 69 | -------------------------------------------------------------------------------- /partners/pangeo.md: -------------------------------------------------------------------------------- 1 | # pyOpenSci's partnership with Pangeo 2 | 3 | pyOpenSci is creating a collaboration workflow to 4 | collaborate with the [Pangeo](https://pangeo.io/) scientific community. Through 5 | this collaboration we add an additional layer of peer review checks to Pangeo-related 6 | packages that go through our [open peer review process](/about/intro). 7 | 8 | If you are submitting a package for review that fits into the Pangeo ecosystem, 9 | your package will be: 10 | 11 | - Reviewed against current pyOpenSci guidelines and checks. 12 | - Also reviewed against the Pangeo-specific guidelines listed below. 13 | 14 | (pangeo-collaboration)= 15 | 16 | ### Pangeo Specific Software Peer Review Guidelines 17 | 18 | In addition to [basic pyOpenSci review checks](https://www.pyopensci.org/software-peer-review/how-to/editor-in-chief-guide.html#editor-checklist-template), when reviewing a 19 | Pangeo-related package, we will also perform the checks below that are 20 | defined by the Pangeo community. 21 | 22 | - **Consume and produce high-level data structures** (e.g. **Xarray datasets**, **Pandas DataFrames**) wherever feasible. 23 | - **Operate lazily when called on Dask data structures:** To support larger-than-memory datasets, many Pangeo workflows use [Dask](https://dask.org) to parallelize the workflow. Doing this efficiently requires lazily loading data and triggering compute only when needed. See the [Dask documentation](https://docs.dask.org/en/stable/user-interfaces.html#laziness-and-computing) for more. 24 | 25 | - A few other resources related to lazy loading: 26 | 27 | - [Dask and stages of computation](https://docs.dask.org/en/stable/phases-of-computation.html): this provides and overview of using Dask effectively to optimize your compute workflow. 28 | - [Using Dask and Xarray together:](https://docs.xarray.dev/en/stable/user-guide/dask.html?highlight=lazy#using-dask-with-xarray) this page provides an overview of how to use Dask to optimize working with data arrays in Xarray. 29 | - [Tutorial on using Dask and lazy loading](https://tutorial.dask.org/01_dataframe.html) 30 | 31 | - **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. 32 | -------------------------------------------------------------------------------- /our-process/how-review-works.md: -------------------------------------------------------------------------------- 1 | # How pyOpenSci's open software peer review works 2 | 3 | 4 | ## Who submits packages and who runs the reviews 5 | 6 | pyOpenSci's [suite of packages](https://www.pyopensci.org/python-packages/) are 7 | contributed by community members with a great diversity of skills and backgrounds. This diversity 8 | of developer backgrounds enables us to vet and promote a broad ecosystem of 9 | high quality tools 10 | that supports scientists across domains with a suite of different data 11 | types and structures. 12 | 13 | ### Who reviews pyOpenSci packages? 14 | 15 | Our peer review process is run by volunteer members of the Python scientific 16 | community: 17 | 18 | * Editors manage incoming package submissions. Editors also ensure 19 | that package reviews move through the review process efficiently; 20 | * Authors create, submit and improve their package; 21 | * Reviewers, two per submission, examine the software code and user experience. 22 | 23 | Our [handbook documentation](https://www.pyopensci.org/handbook/) clarifies 24 | the various roles that support running our peer review process. 25 | 26 | ## Software reviews are contained within [GitHub](https://www.github.com/pyOpenSci) issues 27 | 28 | Our entire peer review process occurs on GitHub in the 29 | [pyOpenSci software-review repository](https://www.github.com/pyopensci/software-review). 30 | 31 | We use GitHub because: 32 | 33 | * It is free to create an account, 34 | * Anyone can read the review discussion without an account, making the process entirely open, 35 | * It facilitates collaboration and supports the community around a package, 36 | * It facilitates an open discussion between reviewers, package maintainers and the pyOpenSci volunteers, 37 | * Numerous packages store their code bases on GitHub. 38 | 39 | ### We use GitHub issue templates and labels to organize the review steps 40 | 41 | * We use GitHub issue templates as submission templates for new reviews and pre-submission review questions. 42 | * We label issues to track every step of the package submission and review progress (e.g. [1/initial-editor-checks, 2/reviewers-needed, 6/pyopensci-approved](https://github.com/pyOpenSci/software-review/labels)). 43 | 44 | ```{note} 45 | [Click here to read the review thread from a December 2022 46 | pyOpenSci pre-submission issue.](https://github.com/pyOpenSci/software-review/issues/65) Note the conversational 47 | tone of the pre-review. In this case the package was improved 48 | before the formal review even began. 49 | 50 | In the actual review process, two external reviews are important milestones. The editor will also provide the author with some feedback. 51 | ``` 52 | 53 | For more detailed overview of the peer review process, [check out our process 54 | timeline document here.](review-timeline) 55 | -------------------------------------------------------------------------------- /partners/astropy.md: -------------------------------------------------------------------------------- 1 | # pyOpenSci's partnership with Astropy 2 | 3 | :::{image} /images/astropy_project_logo.svg 4 | :alt: The Astropy logo. The logo is an orange egg shape with a white snake spiraling in it. The text of the image says The Astropy Project on three lines. 5 | :width: 600px 6 | :align: center 7 | ::: 8 | 9 | pyOpenSci has a collaboration with the [Astropy scientific community](https://www.astropy.org/). Through this collaboration we add an additional layer of peer review checks to Astropy-related packages that go through our [open peer review process](https://www.pyopensci.org/software-peer-review/about/intro.html). If the package meets both the [Astropy criteria for becoming an affiliated package](https://www.astropy.org/affiliated/#becoming-an-affiliated-package) and our pyOpenSci peer review criteria, it can then become both an Astropy-affiliated package and a pyOpenSci ecosystem package. 10 | 11 | If you are submitting a package for review and wish to also apply for Astropy affiliation, your package will be: 12 | 13 | * Reviewed against current pyOpenSci guidelines and checks. 14 | * Also reviewed against the Astropy-specific guidelines listed below. 15 | 16 | (astropy-collaboration)= 17 | ### Astropy Specific Software Peer Review Guidelines 18 | 19 | To be an affiliated Astropy package, your package should: 20 | 21 | - Be useful to astronomers. This can mean useful to a specific sub-domain of astronomy, or more broadly useful to a large fraction of astronomy (or beyond, as long as it is also useful for astronomy). 22 | - Specifically use, interface with, or provide complementary capabilities to other Astropy packages. 23 | - Use classes and functions from the astropy core package wherever possible and appropriate, and (as much as possible) avoid duplication with other packages in the Astropy ecosystem. This facilitates reuse of code and sharing of resources. 24 | 25 | ### Ecointegration - Integration with the Astropy Ecosystem 26 | 27 | Your package should clearly integrate into the broader Astropy ecosystem. It should: 28 | 29 | - Use Astropy or other affiliated packages wherever possible 30 | - Use / depend upon astropy or other affiliated packages functionality wherever possible to avoid duplication of functionality across the ecosystem. 31 | 32 | ## Long-term maintenance & affiliate status over time 33 | 34 | All packages accepted into the pyOpenSci ecosystem will follow the [pyOpenSci 35 | policies](archive-process) associated with package maintenance. 36 | 37 | They will also need to follow the Astropy standards as follows: 38 | 39 | If packages become unmaintained or do not meet the standards anymore, they may be removed from the list of affiliated packages. 40 | 41 | This rule also applies to any package that applies for affiliated status with a 42 | specific domain community through the pyOpenSci partnership program. 43 | -------------------------------------------------------------------------------- /about/benefits.md: -------------------------------------------------------------------------------- 1 | # The Benefits of Submitting a Package to pyOpenSci 2 | 3 | There are a host of benefits from submitting your open source Python package to pyOpenSci for peer review. 4 | 5 | ## Supportive feedback from your peers will improve the quality and usability of your package 6 | 7 | Our review process is focused on improving software quality and sustainability. We aim to provide constructive feedback to package authors and for our review process to be as open and supportive as possible. 8 | 9 | ## Support from the pyOpenSci community of maintainers and experts 10 | 11 | Upon acceptance, your package will receive support from the pyOpenSci community. You will retain ownership and control of your package. However, if you need help with ongoing maintenance issues, we will try to find people who can assist. You will also have access to our Slack community to engage with other maintainers and solicit help as needed. 12 | 13 | ## pyOpenSci will promote your package online 14 | 15 | pyOpenSci will promote your package online through our social media accounts 16 | and website catalog. We will also promote blogs and posts that you create about your 17 | package. You will also be invited to write a blog post on our website highlighting 18 | your package. 19 | 20 | - [webpage](https://www.pyopensci.org/python-packages/), 21 | - [blog](https://www.pyopensci.org/blog/), and 22 | - [social media account(s)](https://twitter.com/pyopensci). 23 | 24 | ## Long term maintenance support 25 | 26 | pyOpenSci values maintained open source tools. Should you need to step down from maintaining your tool, or should you need to build out a larger maintainer team, pyOpenSci will help identify potential contributors. In the case that it makes more sense for you to sunset your package, we will support you in that transition. 27 | 28 | ## Adherence to community-accepted standards 29 | 30 | pyOpenSci maintains a close watching brief on Python-specific community accepted standards in packaging. Thus our review process will help enforce those standards as far as appropriate. 31 | 32 | ## Reduced duplication of Python tools that support open science 33 | 34 | pyOpenSci has a broad view across the scientific Python ecosystem. When you submit your package for review, we will ask you to cross reference other packages in the ecosystem that may have similar functionality. In the long run, we hope to identify overlap in package functionality and foster collaborations among maintainers working on similar tools. 35 | 36 | ## Your package can be fast tracked and accepted by JOSS 37 | pyOpenSci packages that are in scope for the [Journal of Open-Source Software](https://joss.theoj.org/) and append the necessary accompanying short `paper.md` file, can, at the discretion of JOSS editors, benefit from a fast-tracked review process. [Read more about our partnership with JOSS here](/partners/joss). 38 | -------------------------------------------------------------------------------- /.zenodo.json: -------------------------------------------------------------------------------- 1 | { 2 | "creators": [ 3 | { 4 | "affiliation": "pyOpenSci", 5 | "name": "Wasser, Leah", 6 | "orcid": "0000-0002-8177-6550" 7 | }, 8 | { 9 | "affiliation": "", 10 | "name": "Nicholson, David", 11 | "orcid": "0000-0002-4261-4719" 12 | }, 13 | { 14 | "affiliation": "Hasso Plattner Institute", 15 | "name": "Sasso, Ariane", 16 | "orcid": "0000-0002-3669-4599" 17 | }, 18 | { 19 | "affiliation": "", 20 | "name": "Batisse, Alexandre", 21 | "orcid": "0000-0001-7912-3422" 22 | }, 23 | { 24 | "affiliation": "", 25 | "name": "Panda, Yuvi" 26 | }, 27 | { 28 | "affiliation": "2i2c, Project Jupyter", 29 | "name": "Holdgraf, Chris", 30 | "orcid": "0000-0002-2391-0678" 31 | }, 32 | { 33 | "affiliation": "2i2c, Project Jupyter", 34 | "name": "van der Walt, Stéfan", 35 | "orcid": "0000-0001-9276-1891" 36 | }, 37 | { 38 | "affiliation": "", 39 | "name": "Solvik, Kylen" 40 | }, 41 | { 42 | "affiliation": "", 43 | "name": "Ogasawara, Ivan" 44 | }, 45 | { 46 | "affiliation": "", 47 | "name": "Brett, Matthew" 48 | }, 49 | { 50 | "affiliation": "", 51 | "name": "Sundell, Erik" 52 | }, 53 | { 54 | "affiliation": "", 55 | "name": "Chen, Zehua" 56 | }, 57 | { 58 | "affiliation": "", 59 | "name": "Ogasawara, Ivan" 60 | }, 61 | { 62 | "affiliation": "", 63 | "name": "Joseph, Max" 64 | }, 65 | { 66 | "affiliation": "", 67 | "name": "Lau, Sam" 68 | }, 69 | { 70 | "affiliation": "", 71 | "name": "Roken, Ariel" 72 | }, 73 | { 74 | "affiliation": "", 75 | "name": "Willing, Carol" 76 | }, 77 | { 78 | "affiliation": "", 79 | "name": "Mason, James" 80 | }, 81 | { 82 | "affiliation": "", 83 | "name": "Bantilan, Niels" 84 | }, 85 | { 86 | "affiliation": "", 87 | "name": "Moss, Steve" 88 | }, 89 | { 90 | "affiliation": "", 91 | "name": "Bantilan, Niels" 92 | }, 93 | { 94 | "affiliation": "", 95 | "name": "Kashyap, Sumit" 96 | } 97 | ], 98 | "keywords": [ 99 | "open source software", 100 | "Python", 101 | "open peer review", 102 | "data science", 103 | "open reproducible science", 104 | "science" 105 | ], 106 | "license": "CC-BY-SA-4.0", 107 | "upload_type": "publication", 108 | "publication_type": "book" 109 | } 110 | -------------------------------------------------------------------------------- /appendices/glossary.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | The following are common terms in the scientific python community and their 4 | definitions for reference. 5 | 6 | * **branch**: A parallel copy of your GitHub repo. Use branches to write code and make changes that you don't want to affect the live version of your package. When you're ready, you can merge the changes back to the "main" branch. More info [here](https://help.github.com/articles/about-branches/). 7 | * **continuous integration**: The practice of automatically building and testing a project's source code as changes are made by developers. This helps identify bugs before they become a bigger problem. Travis CI is an example of a continuous integration service. 8 | * **code coverage**: A measure of the fraction of lines in a project's code that are run during testing. 100% coverage means that every line of code is executed during the tests. 9 | * **commit**: Saving a change (or changes) to git. Via git, each save/commit is given a unique ID, which lets you easily revert to a previous save/commit. 10 | * **documentation**: Text and/or images that accompany code to explain how it works and how to use it. 11 | * **docstring**: A miniature piece of documentation within the source code, usually documenting a specific function, class, or other piece of code. 12 | * **linting/linter**: A linter is a program that you can run on your code to identify potential errors. There are many linters for Python, e.g. flake8. 13 | * **module**: A file containing Python code. Modules can define functions, classes, and more, and can be imported by other Python code to use those defined objects. Some files are meant to be run directly instead of imported. These are "scripts". 14 | * **open source**: In simple terms, software for which the source code is freely available and can be modified and redistributed. What meets the standard of "open source" can be controversial, but the Open Source Initiative has a more thorough set of [guidelines](https://opensource.org/definition/). 15 | * **slug**: A short title, containing only letters, numbers, underscores, and hyphens. For example, a slug might replace spaces with underscores. Your package's "slug" is a handy shorthand. 16 | * **software license**: Contains the terms of use, modification, and distribution for a piece of software. Open source licenses generally grant freedom to modify and share software, but sometimes there are specific conditions. Read more from [OSI](https://opensource.org/licenses). 17 | * **testing**: Code tests check units of code to make sure that they are producing the expected result. For example, if you have a function "sum_nums" that sums numbers, you could write a test that makes sure that sum_nums(2, 2) == 4. Writing full tests helps to avoid bugs as you are writing or modifying your code. 18 | * **version control**: A system that keeps track of changes to files over time, allowing you to revert to a previous version if needed. For example, Git is the version control system that GitHub is built on. 19 | -------------------------------------------------------------------------------- /appendices/package-approval-template.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | --- 3 | 4 | 🎉 has been approved by pyOpenSci! Thank you for submitting and many thanks to for reviewing this package! 😸 5 | 6 | ## Author Wrap Up Tasks 7 | 8 | There are a few things left to do to wrap up this submission: 9 | 10 | - [ ] Activate [Zenodo](https://zenodo.org/) watching the repo if you haven't already done so. 11 | - [ ] Tag and create a release to create a Zenodo version and DOI. 12 | - [ ] Add the badge for pyOpenSci peer-review to the README.md of . The badge should be `[![pyOpenSci Peer-Reviewed](https://pyopensci.org/badges/peer-reviewed.svg)](https://github.com/pyOpenSci/software-review/issues/issue-number)`. 13 | - [ ] Please fill out the [post-review survey](https://forms.gle/BLGVCfUdiJHS5YJY7). All maintainers and reviewers should fill this out. 14 | 15 | 16 | It looks like you would like to submit this package to JOSS. Here are the next steps: 17 | 18 | - [ ] Once the JOSS issue is opened for the package, we strongly suggest that you subscribe to issue updates. This will allow you to continue to update the issue labels on this review as it goes through the JOSS process. 19 | - [ ] Login to the JOSS website and fill out the JOSS submission form using your Zenodo DOI. **When you fill out the form, be sure to mention and link to the approved pyOpenSci review.** JOSS will tag your package for expedited review if it is already pyOpenSci approved. 20 | - [ ] Wait for a JOSS editor to approve the presubmission (which includes a scope check). 21 | - [ ] Once the package is approved by JOSS, you will be given instructions by JOSS about updating the citation information in your README file. 22 | - [ ] When the JOSS review is complete, add a comment to your review in the pyOpenSci software-review repo here that it has been approved by JOSS. An editor will then add the JOSS-approved label to this issue. 23 | 24 | 🎉 Congratulations! You are now published with both JOSS and pyOpenSci! 🎉 25 | 26 | 27 | ## Editor Final Checks 28 | 29 | Please complete the final steps to wrap up this review. Editor, please do the following: 30 | 31 | - [ ] Make sure that the maintainers filled out the [post-review survey](https://forms.gle/BLGVCfUdiJHS5YJY7) 32 | - [ ] Invite the maintainers to submit a blog post highlighting their package. Feel free to use / adapt [language found in this comment](https://github.com/pyOpenSci/software-submission/issues/93#issuecomment-1591687581) to help guide the author. 33 | - [ ] Change the status tag of the issue to `6/pyOS-approved6 🚀🚀🚀`. (You can remove all other labels; If the the package is moving on to JOSS then add a JOSS label) 34 | - [ ] Update the header of this issue with the date accepted, the version accepted, and the accepted version DOI (from Zenodo) to the header of this issue. 35 | - [ ] Invite the package maintainer(s) and both reviewers to the pyOpenSci Slack. 36 | - [ ] If the review is complete (not submitting to JOSS), close the issue when all items on this checklist are complete. If it's moving to JOSS, please close the issue once the JOSS review is complete and you've performed the task below. 37 | - [ ] If the author submits to JOSS, please continue to update the labels for JOSS on this issue until the author is accepted (do not remove the `6/pyOS-approved` label). Once accepted add the label `9/joss-approved` to the issue. Skip this check if the package is not submitted to JOSS. 38 | - [ ] If the package is JOSS-accepted please add the JOSS DOI to the YAML at the top of the issue. 39 | 40 | --- 41 | 42 | If you have any feedback for us about the review process please feel free to share it here. We are always looking to improve our process and documentation in the [peer-review-guide](https://www.pyopensci.org/software-peer-review). 43 | ``` 44 | -------------------------------------------------------------------------------- /appendices/editor-in-chief-checks.md: -------------------------------------------------------------------------------- 1 | ```markdown 2 | ## Editor in Chief checks 3 | 4 | Hi there! Thank you for submitting your package for pyOpenSci 5 | review. Below are the basic checks that your package needs to pass 6 | to begin our review. If some of these are missing, we will ask you 7 | to work on them before the review process begins. 8 | 9 | Please check our [Python packaging guide](https://www.pyopensci.org/python-package-guide) for more information on the elements 10 | below. 11 | 12 | - [ ] **Installation** The package can be installed from a community repository such as PyPI (preferred), and/or a community channel on conda (for example, conda-forge, bioconda). 13 | - [ ] The package imports properly into a standard Python environment `import package`. 14 | - [ ] **Fit** The package meets criteria for [fit](https://www.pyopensci.org/software-peer-review/about/package-scope.html#what-types-of-packages-does-pyopensci-review) and [overlap](https://www.pyopensci.org/software-peer-review/about/package-scope.html#package-overlap). 15 | - [ ] **Documentation** The package has sufficient online documentation to allow us to evaluate the package's function and scope *without installing the package*. This includes: 16 | - [ ] User-facing documentation that overviews how to install and start using the package. 17 | - [ ] Short, quickstart tutorials that help a user understand how to use the package and what it can do for them. 18 | - [ ] API documentation (documentation for your code's functions, classes, methods, and attributes): this includes clearly written docstrings with variables defined using a standard docstring format. 19 | - [ ] Core GitHub repository Files 20 | - [ ] **README** The package has a `README.md` file with a clear explanation of what the package does, instructions on how to install it, and a link to development instructions. 21 | - [ ] **Contributing File** The package has a `CONTRIBUTING.md` file that details how to install and contribute to the package. 22 | - [ ] **Code of Conduct** The package has a `CODE_OF_CONDUCT.md` file. 23 | - [ ] **License** The package has an [OSI approved license](https://opensource.org/licenses). 24 | NOTE: We prefer that you have development instructions in your documentation too. 25 | - [ ] **Issue Submission Documentation** All of the information is filled out in the `YAML` header of the issue (located at the top of the issue template). 26 | - [ ] **Automated tests** Package has a testing suite and is tested via a Continuous Integration service. 27 | - [ ] **Repository** The repository link resolves correctly. 28 | - [ ] **Package overlap** The package doesn't entirely overlap with the functionality of other packages that have already been submitted to pyOpenSci. 29 | - [ ] **Archive** (JOSS only, may be post-review): The repository DOI resolves correctly. 30 | - [ ] **Version** (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)? 31 | - [ ] The package authors have disclosed the use of Generative AI tools in the development and/or maintenance of their package. 32 | 33 | **Optional:** Let projects know that it's a great idea for projects to have a .github repository for the project organization where they can host a commonly used LICENSE, Code of Conduct, and even a YAML file with label definitions. These items will then be automatically applied to every repository in the organization to ensure consistency (but can be customized within repos too). The [SunPy project](https://github.com/sunpy/.github/) has a great example of this. 34 | 35 | --- 36 | - [ ] [Initial onboarding survey was filled out ](https://forms.gle/F9mou7S3jhe8DMJ16) 37 | We appreciate each maintainer of the package filling out this survey individually. :raised_hands: 38 | A big thank you in advance to authors for setting aside five to ten minutes to do this. It truly helps our organization! :raised_hands: 39 | --- 40 | 41 | ******* 42 | 43 | ## Editor comments 44 | 45 | 46 | ``` 47 | -------------------------------------------------------------------------------- /appendices/templates.md: -------------------------------------------------------------------------------- 1 | # Appendix: Templates 2 | 3 | These are templates to be used by editors and reviewers. When a package is submitted, the assigned editor fills out the Editor's Template and posts it in the submission's issue thread on GitHub. 4 | 5 | ## Editor's Template 6 | 7 | ```{include} editor-initial-response-template.md 8 | ``` 9 | 10 | 11 | ```{include} review-template.md 12 | ``` 13 | 14 | ## Review Request Template 15 | 16 | Editors may make use of the e-mail template below in recruiting reviewers: 17 | 18 | ```{include} reviewer-request-template.md 19 | ``` 20 | 21 | [reviewers guide]: https://www.pyopensci.org/contributing-guide/peer-review-guides/reviewer-guide.html 22 | [packaging guide]: https://www.pyopensci.org/contributing-guide/authoring/index.html#packaging-guide 23 | [template]: https://www.pyopensci.org/contributing-guide/appendices/templates.html#review-template 24 | 25 | 26 | ## Editor Approval Comment Template 27 | ``` 28 | ---------------------------------------------- 29 | 🎉 has been approved by pyOpenSci! Thank you for submitting and many thanks to for reviewing this package! 😸 30 | 31 | There are a few things left to do to wrap up this submission: 32 | - [ ] Add the badge for pyOpenSci peer-review to the README.md of . The badge should be `[![pyOpenSci](https://tinyurl.com/y22nb8up)](https://github.com/pyOpenSci/software-review/issues/issue-number)` 33 | - [ ] Add to the pyOpenSci website. , please open a pr to update [this file](https://github.com/pyOpenSci/pyopensci.github.io/blob/main/_data/packages.yml): to add your package and name to the list of contributors 34 | - [ ] if you have time and are open to being listed on our website, please add yourselves to [this file](https://github.com/pyOpenSci/pyopensci.github.io/blob/main/_data/contributors.yml) via a pr so we can list you on our website as contributors! 35 | 36 | 37 | This package is going to move on to JOSS for review. I believe @arfon will ask you to implement the items below but let's let him chime in here first! 38 | - [ ] Activate Zenodo watching the repo 39 | - [ ] Tag and create a release so as to create a Zenodo version and DOI 40 | - [ ] Submit to JOSS using the Zenodo DOI. We will tag it for expedited review. 41 | 42 | 43 | 44 | All -- if you have any feedback for us about the review process please feel free to share it here. We are always looking to improve our process and our documentation in the [contributing-guide](https://www.pyopensci.org/contributing-guide). We have also been updating our documentation to improve the process so all feedback is appreciated! 45 | ``` 46 | 47 | ## Generic new member template 48 | 49 | A template for inviting others to join the pyOpenSci community calls and otherwise 50 | get engaged. 51 | 52 | ``` 53 | < short greeting /> 54 | 55 | I'm writing to see if you'd be interested in participating with pyOpenSci, a new community around improving the quality of software in the scientific python stack. 56 | 57 | pyOpenSci provides resources, mentoring, and documentation for making scientific python packages more useful and maintainable. It builds off of the successful rOpenSci model, with a Python flavor. It primarily coordinates a review process by which experienced developers in the scientific python ecosystem can provide feedback and suggestions to other (usually fairly small) packages. 58 | 59 | You've been in the scientific Python community for some time now, and I think you'd be a great part of the pyOpenSci community. Would you be interested in joining us? Participation can be as small or large as you wish - for example, you could submit your own package for review in pyOpenSci, offer to be a reviewer of someone else's package, or begin attending pyOpenSci planning meetings as we build and refine our processes. We'd just be happy to have you around :-) 60 | 61 | < short goodbye /> 62 | ``` 63 | -------------------------------------------------------------------------------- /index.md: -------------------------------------------------------------------------------- 1 | # Welcome to the pyOpenSci Software Peer Review Guidebook! 2 | 3 | ::::{grid} 2 4 | :reverse: 5 | 6 | :::{grid-item} 7 | :columns: 4 8 | :class: sd-m-auto 9 | ::: 10 | 11 | :::{grid-item} 12 | :columns: 12 13 | :class: sd-fs-5 14 | 15 | pyOpenSci is a diverse community that supports the open Python tools that 16 | drive open science. 17 | 18 | % The SVG rendering breaks latex builds for the GitHub badge, so only include in HTML 19 | 20 | ```{only} html 21 | ![GitHub release (latest by date)](https://img.shields.io/github/v/release/pyopensci/contributing-guide?color=purple&display_name=tag&style=plastic) 22 | [![](https://img.shields.io/github/stars/pyopensci/contributing-guide?style=social)](https://github.com/pyopensci/contributing-guide) 23 | [![DOI](https://zenodo.org/badge/DOI/10.5281/zenodo.7101778.svg)](https://doi.org/10.5281/zenodo.7101778) 24 | ``` 25 | 26 | ::: 27 | 28 | :::: 29 | 30 | :::::{grid} 1 2 3 3 31 | :class-container: text-center 32 | :gutter: 3 33 | 34 | ::::{grid-item} 35 | :::{card} {octicon}`book;1.5em;sd-mr-1` Learn About Software Peer Review 36 | :class-card: left-aligned 37 | :link: about/intro 38 | :link-type: doc 39 | 40 | Get a basic overview of our open peer review process for Python scientific open source 41 | software. 42 | ::: 43 | :::: 44 | 45 | ::::{grid-item} 46 | :::{card} {octicon}`rocket;1.5em;sd-mr-1` Package Scope (What We Review) 47 | :link: about/package-scope 48 | :link-type: doc 49 | :class-header: bg-light 50 | 51 | We review packages that support scientists creating open science workflows. 52 | Learn about the scope of the packages that we review. 53 | ::: 54 | :::: 55 | 56 | ::::{grid-item} 57 | :::{card} {octicon}`code-square;1.5em;sd-mr-1`Authors Guide 58 | :link: how-to/author-guide 59 | :link-type: doc 60 | :class-header: bg-light 61 | 62 | Are you a package author / maintainer? ✨ 63 | 64 | Learn how to submit a package for peer review with pyOpenSci. 65 | ::: 66 | :::: 67 | 68 | ::::{grid-item} 69 | :::{card} {octicon}`pencil;1.5em;sd-mr-1`Editors Guide 70 | :link: how-to/editors-guide 71 | :link-type: doc 72 | :class-header: bg-light 73 | 74 | ✨ Our editor guide will walk you through the editorial process. ✨ 75 | ::: 76 | :::: 77 | 78 | ::::{grid-item} 79 | :::{card} {octicon}`codescan-checkmark;1.5em;sd-mr-1` For Reviewers 80 | :link: how-to/reviewer-guide 81 | :link-type: doc 82 | :class-header: bg-light 83 | 84 | Are you a reviewer? ✨ 85 | 86 | Click here to read our reviewer guide which will walk you through the review 87 | process step-by-step. 88 | ::: 89 | :::: 90 | 91 | ::::{grid-item} 92 | :::{card} {octicon}`people;1.5em;sd-mr-1` Our Partners 93 | :link: partners/scientific-communities 94 | :link-type: doc 95 | :class-header: bg-light 96 | 97 | Scientific Community Partnerships ✨ 98 | 99 | We partner with other scientific communities. Learn about our partnerships with 100 | JOSS and Pangeo. 101 | ::: 102 | :::: 103 | 104 | ::::: 105 | 106 | ## Why pyOpenSci? 107 | 108 | pyOpenSci promotes open and reproducible research through peer-review of 109 | scientific Python packages. We also build technical capacity by providing a 110 | curated repository of high-quality packages and enabling scientists to write 111 | and share their own software. We hope to foster a greater sense of community 112 | among scientific Python users so that we can help each other become better 113 | programmers and researchers. 114 | 115 | :::{figure-md} pyos-badge-home 116 | :class: myclass 117 | 118 | The pyOpenSci badge- On the left is the badge in grey and it says pyOpenSci. On the right it is bright green and says Peer Reviewed. 119 | 120 | **pyOpenSci Peer Review Badge will appear on the README.md file of packages that have been 121 | reviewed and vetted by us.** 122 | ::: 123 | 124 | ```{toctree} 125 | :hidden: 126 | :caption: About peer review 127 | 128 | About 129 | ``` 130 | 131 | ```{toctree} 132 | :hidden: 133 | :caption: Partners 134 | 135 | Partnerships 136 | ``` 137 | 138 | ```{toctree} 139 | :hidden: 140 | :caption: How To Guides 141 | 142 | Review Guides 143 | 144 | ``` 145 | -------------------------------------------------------------------------------- /partners/joss.md: -------------------------------------------------------------------------------- 1 | (joss)= 2 | # pyOpenSci and Journal of Open Source Software (JOSS) Partnership 3 | 4 | pyOpenSci has a formal partnership with 5 | [the Journal of Open Source Software (JOSS)](https://joss.theoj.org/). JOSS is 6 | a journal and a publisher that provides a way for developers of 7 | research software to get academic credit for their work. 8 | 9 | The JOSS review process is about publication. A review from JOSS will provide 10 | you with a citable, [Crossref digital object identifier (DOI)](https://www.crossref.org/). 11 | pyOpenSci aligns closely with the broad mission of 12 | JOSS to provide maintainers with credit for their open source work. However, 13 | our mission is also more focused. pyOpenSci is not just about open source 14 | maintainers getting academic credit for their work. 15 | 16 | pyOpenSci is different from JOSS because: 17 | 18 | * We build community around the scientific Python ecosystem. Maintainers that go through our process can ask questions and get help. Or they can just talk to other maintainers who might have similar challenges. 19 | * We support the Python tools that drive scientific open reproducible science workflows. We also provide training in that space to support new users and future maintainers and contributors. 20 | * We focus on enforcement and encouragement of Python-specific packaging standards and best practices. As such we try to help maintainers improve the quality of their package. 21 | * We focus on package documentation and usability as a way to improve quality and user experience. 22 | * We have a view across the entire scientific ecosystem. As such we will try our best to identify redundancy in package function across the ecosystem. 23 | * We provide additional visibility for our packages through our tool catalog, website and social media presence. 24 | 25 | At the end of the day the pyOpenSci badge represents packages that are high 26 | quality, maintained and vetted. We want the community to trust the tools in our 27 | ecosystem. 28 | 29 | ## How is review at pyOpenSci different from the JOSS review process? 30 | 31 | We are not a typical publisher or journal. Rather we are a community that provides support for both a diverse group of software maintainers and long term maintenance of our packages. 32 | 33 | The pyOpenSci review process is different from that of JOSS in a few ways: 34 | 35 | 1. Our review is specifically designed to enforce modern, community-accepted best practices for Python packaging. 36 | 1. We place heavy emphasis on documentation and usability in our reviews and associated standardization of both. 37 | 1. We build community around and visibility for its tools. 38 | 1. We will promote packages and package maintainers once they are accepted into our ecosystem. 39 | 1. We support long term maintenance of packages. If the maintainer needs to step down, we will ensure a new maintainer takes over or sunset and remove the package from our ecosystem. 40 | 1. We provide a welcoming forum for you to ask questions and get help with maintaining your package as needed. 41 | 42 | JOSS reviews are also [more limited in scope](https://joss.readthedocs.io/en/latest/submitting.html?highlight=scope#submission-requirements) 43 | compared to pyOpenSci. Some of the JOSS submission criteria 44 | are, in places, less stringent or less specific to the Python programming 45 | language than those of pyOpenSci. 46 | 47 | ## You can improve your package with a review at pyOpenSci and still publish in JOSS 48 | 49 | You don't have to chose between pyOpenSci and JOSS; You can submit your package to both. 50 | 51 | pyOpenSci and JOSS are complementary, partner organizations. You don't have 52 | to choose one or the other! After a package to pyOpenSci has been reviewed and 53 | accepted you can also choose to register it with JOSS. 54 | 55 | JOSS has [more limited scope](https://joss.readthedocs.io/en/latest/review_criteria.html) 56 | for packages that it will review. For instance, while pyOpenSci will review 57 | and accept API wrappers, JOSS won't. 58 | 59 | If your package is accepted by pyOpenSci and in scope for JOSS, JOSS will fast 60 | track your package through their review process given it was already reviewed by us. 61 | 62 | You do not need to go through two reviews! 63 | 64 | Once accepted by JOSS, you now have both a pyOpenSci acceptance and one by JOSS. 65 | 66 | * JOSS will give you a Crossref DOI for citation. 67 | * You can display that and your pyOpenSci peer reviewed badge at the top of your package's README.md file. 68 | -------------------------------------------------------------------------------- /how-to/finding-reviewers.md: -------------------------------------------------------------------------------- 1 | (finding-reviewers)= 2 | # Finding Reviewers 3 | 4 | Sometimes, the most challenging part of our pyOpenSci software peer review process 5 | is finding reviewers. This page provides tips and tricks to help you find the 6 | right people to review a scientific Python package. 7 | 8 | ## Where to Look for Reviewers? 9 | 10 | As an editor, you can find reviewers through: 11 | 12 | * Suggestions made by the submitting package authors. We suggest only using 13 | one of the suggested reviewers if this is the case. 14 | * Authors of existing [pyOpenSci packages](https://www.pyopensci.org/python-packages/). 15 | * Other [pyOpenSci contributors](https://www.pyopensci.org/our-community/). 16 | 17 | When the above doesn't work and you still need to find a reviewer: 18 | 19 | * Check our reviewer sign-up spreadsheet for names of people who have already 20 | volunteered to review for pyOpenSci. The link for this document is pinned to 21 | the pyOpenSci Slack `#private-editorial-channel`. 22 | * Ping other editors for ideas. 23 | * Post in the pyOpenSci Slack `#software-review` channel. 24 | * Look for users of the package or the data source/upstream service the 25 | package connects to (via their opening issues in the repository, starring 26 | it, citing it in papers, talking about it on social media). 27 | * Search for authors/maintainers of related packages on [PyPI](https://pypi.org/search/). 28 | * Coordinate with our Community Manager to post a call for reviewers on our 29 | pyOpenSci social channels. 30 | 31 | :::{important} 32 | 33 | If you do a reviewer search, please be sure to have new reviewers first sign 34 | up using our [reviewer signup form](https://docs.google.com/forms/d/e/1FAIpQLSeVf-L_1-jYeO84OvEE8UemEoCmIiD5ddP_aO8S90vb7srADQ/viewform). 35 | ::: 36 | 37 | ## Criteria for Choosing Reviewers 38 | 39 | Here are the key criteria to consider when selecting a reviewer. You might need to 40 | piece this information together by searching `PyPI`, `Conda` / `Conda-forge` 41 | and the potential reviewer’s GitHub page and general online presence (personal 42 | website, social media profiles). 43 | 44 | * Has not reviewed a package for us within the last 6 months. 45 | * Some package development/contribution experience. 46 | * Some domain experience in the field of the package or data source. 47 | * No [conflicts of interest](coi). 48 | 49 | (reviewer-diversity)= 50 | ### Reviewer Diversity Should Be Prioritized 51 | 52 | Try to balance your sense of the potential reviewer’s experience against the 53 | complexity of the package. 54 | 55 | * **Diversity:** Try to find reviewers from different backgrounds and gender identities. For example, if you have two reviewers, only one should be a cis white male. 56 | * **Openness** - reviewers should also have demonstrated interest in open 57 | source or Python community activities, although blind emailing is fine. 58 | 59 | Two package reviewers should review each submission. Although it is 60 | fine for one of them to have less package development experience and more 61 | domain knowledge, the review should not be split into two parts. Both 62 | reviewers need to review the package comprehensively, from their particular 63 | perspectives. If possible, at least one reviewer should have prior reviewing 64 | experience, and of course, inviting one new reviewer expands our pool of 65 | reviewers. 66 | 67 | At least one reviewer of the two should have some subject matter expertise associated with 68 | the package functionality. It is ok and even welcome if one reviewer has more 69 | technical knowledge and the other focuses on usability and is less technical. 70 | Read through the [Guidelines for Reviewers Section](reviewer-guide-sphinx) to learn more about finding 71 | and selecting reviewers. 72 | 73 | (review-mentorship)= 74 | ## Peer Review Mentorship 75 | 76 | pyOpenSci encourages those who are newer to review to become involved in our 77 | open peer review process. As such, we offer a reviewer mentorship program 78 | where we pair a new reviewer with someone in the community who has previous 79 | review experience. 80 | 81 | It is useful for reviewers to not only review the technical content of a 82 | package, but also to review the documentation and package installation process 83 | for usability. 84 | 85 | If a new reviewer is interested in becoming a reviewer but would like some 86 | support, do the following: 87 | 88 | 1. The Editor can lead the effort to find mentors for the new reviewers by posting in the `#software-review` Slack channel for help. 89 | 2. If the Editor needs support in finding a mentor, they can contact the **EiC** or **peer review lead** for guidance. 90 | 91 | ### Once a Mentor is Identified 92 | 93 | 1. Invite the new reviewer to our pyOpenSci Slack. 94 | 2. Start a private DM group chat with the new reviewer and the mentor(s) so 95 | they are introduced. 96 | 3. Let the review proceed from there. 97 | -------------------------------------------------------------------------------- /conf.py: -------------------------------------------------------------------------------- 1 | # Configuration file for the Sphinx documentation builder. 2 | # https://www.sphinx-doc.org/en/master/usage/configuration.html 3 | 4 | 5 | from datetime import datetime 6 | import subprocess 7 | 8 | current_year = datetime.now().year 9 | organization_name = "pyOpenSci" 10 | # -- Project information ----------------------------------------------------- 11 | 12 | project = "pyOpenSci Python Package Guide" 13 | copyright = f"{current_year}, {organization_name}" 14 | author = "pyOpenSci Community" 15 | 16 | # Get the latest Git tag - there might be a prettier way to do this but... 17 | try: 18 | release_value = ( 19 | subprocess.check_output(["git", "describe", "--tags"]) 20 | .decode("utf-8") 21 | .strip() 22 | ) 23 | release_value = release_value[:4] 24 | except subprocess.CalledProcessError: 25 | release_value = "0.1" # Default value in case there's no tag 26 | 27 | # Update the release value 28 | release = release_value 29 | 30 | 31 | # -- General configuration --------------------------------------------------- 32 | 33 | # Add any Sphinx extension module names here, as strings. They can be 34 | # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom 35 | # ones. 36 | extensions = [ 37 | "myst_nb", 38 | "sphinx_design", 39 | "sphinx.ext.intersphinx", 40 | "sphinx_sitemap", 41 | "sphinxext.opengraph", 42 | "sphinx_copybutton", 43 | "sphinx.ext.todo", 44 | ] 45 | 46 | # colon fence for card support in md 47 | myst_enable_extensions = ["colon_fence"] 48 | myst_heading_anchors = 3 49 | 50 | # Suppress as we have includes that don't need to start at h1 51 | suppress_warnings = ["myst.header"] 52 | 53 | # For generating sitemap 54 | html_baseurl = "https://www.pyopensci.org/software-peer-review/" 55 | sitemap_url_scheme = "{link}" 56 | 57 | # The theme to use for HTML and HTML Help pages. See the documentation for 58 | # a list of builtin themes. 59 | # 60 | html_theme = "pyos_sphinx_theme" 61 | html_title = "Software Peer Review Guide" 62 | html_logo = "_static/logo.png" 63 | html_static_path = ["_static"] 64 | html_js_files = ["matomo.js"] 65 | html_favicon = 'https://www.pyopensci.org/images/favicon.ico' 66 | 67 | # Theme options 68 | html_theme_options = { 69 | "announcement": "

Submit Your Python Package for Peer Review!

", 70 | "external_links": [ 71 | { 72 | "url": "https://www.pyopensci.org", 73 | "name": "pyOpenSci Website", 74 | }, 75 | { 76 | "url": "https://www.pyopensci.org/python-package-guide", 77 | "name": "Python Packaging Guide", 78 | }, 79 | { 80 | "url": "https://pyopensci.org/handbook", 81 | "name": "Handbook", 82 | }, 83 | ], 84 | "icon_links": [ 85 | { 86 | "name": "Mastodon", 87 | "url": "https://fosstodon.org/@pyOpenSci", 88 | "icon": "fa-brands fa-mastodon", 89 | }, 90 | ], 91 | "logo": { 92 | "text": "Peer Review Guide", 93 | "image_dark": "logo-dark-mode.png", 94 | "image_light": "logo-light-mode.png", 95 | "alt_text": "pyOpenSci Software Peer Review Guide. The pyOpenSci logo is a purple flower with pyOpenSci under it. The o in open sci is the center of the flower", 96 | }, 97 | "header_links_before_dropdown": 4, 98 | "use_edit_page_button": True, 99 | "show_toc_level": 1, 100 | "navbar_align": "left", # [left, content, right] For testing that the navbar items align properly 101 | "github_url": "https://github.com/pyOpenSci/software-peer-review", 102 | "footer_start": ["copyright"], 103 | "footer_end": [], 104 | } 105 | 106 | # html_theme_options["analytics"] = { 107 | # "google_analytics_id": "UA-141260825-1", 108 | # } 109 | 110 | html_context = { 111 | "github_user": "pyopensci", 112 | "github_repo": "software-peer-review", 113 | "github_version": "main", 114 | } 115 | 116 | 117 | # Add any paths that contain templates here, relative to this directory. 118 | templates_path = ["_templates"] 119 | 120 | # List of patterns, relative to source directory, that match files and 121 | # directories to ignore when looking for source files. 122 | # This pattern also affects html_static_path and html_extra_path. 123 | exclude_patterns = [ 124 | "_build", 125 | "Thumbs.db", 126 | ".DS_Store", 127 | ".github", 128 | ".nox", 129 | "README.md", 130 | ".pytest_cache", 131 | ".pytest_cache/*", 132 | ] 133 | 134 | 135 | # -- Options for HTML output ------------------------------------------------- 136 | 137 | 138 | # Add any paths that contain custom static files (such as style sheets) here, 139 | # relative to this directory. They are copied after the builtin static files, 140 | # so a file named "default.css" will overwrite the builtin "default.css". 141 | html_static_path = ["_static"] 142 | html_css_files = ["pyos.css"] 143 | -------------------------------------------------------------------------------- /appendices/review-template.md: -------------------------------------------------------------------------------- 1 | ## Peer Review Template 2 | 3 | ``` 4 | ## Package Review 5 | 6 | *Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide* 7 | 8 | - [ ] As the reviewer, I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor _before_ starting your review). 9 | 10 | #### Documentation 11 | 12 | The package includes all the following forms of documentation: 13 | 14 | - [ ] **A statement of need** clearly stating problems the software is designed to solve and its target audience in the README file. 15 | - [ ] **Installation instructions:** for the development version of the package and any non-standard dependencies in README. 16 | - [ ] **Short quickstart tutorials** demonstrating significant functionality that successfully runs locally. 17 | - [ ] **Function Documentation:** for all user-facing functions. 18 | - [ ] **Examples** for all user-facing functions. 19 | - [ ] **Community guidelines** including contribution guidelines in the README or CONTRIBUTING. 20 | - [ ] **Metadata** including author(s), author e-mail(s), a URL, and any other relevant metadata, for example, in a `pyproject.toml` file or elsewhere. 21 | 22 | Readme file requirements 23 | The package meets the readme requirements below: 24 | 25 | - [ ] Package has a README.md file in the root directory. 26 | 27 | The README should include, from top to bottom: 28 | 29 | - [ ] The package name 30 | - [ ] Badges for: 31 | - [ ] Continuous integration and test coverage, 32 | - [ ] Docs building (if you have a documentation website), 33 | - [ ] Python versions supported, 34 | - [ ] Current package version (on PyPI / Conda). 35 | 36 | *NOTE: If the README has many more badges, you might want to consider using a table for badges: [see this example](https://github.com/ropensci/drake). Such a table should be wider than high. A badge for pyOpenSci peer review will be provided when the package is accepted.* 37 | 38 | - [ ] Short description of package goals. 39 | - [ ] Package installation instructions 40 | - [ ] Any additional setup required to use the package (authentication tokens, etc.) 41 | - [ ] Descriptive links to all vignettes. If the package is small, there may only be a need for one vignette which could be placed in the README.md file. 42 | - [ ] Brief demonstration of package usage (as it makes sense - links to vignettes could also suffice here if package description is clear) 43 | - [ ] Link to your documentation website. 44 | - [ ] If applicable, how the package compares to other similar packages and/or how it relates to other packages in the scientific ecosystem. 45 | - [ ] Citation information 46 | 47 | #### Usability 48 | 49 | Reviewers are encouraged to submit suggestions (or pull requests) that will improve the usability of the package as a whole. 50 | The package structure should follow the general community best practices. In general, please consider whether: 51 | 52 | - [ ] Package documentation is clear and easy to find and use. 53 | - [ ] The need for the package is clear 54 | - [ ] All functions have documentation and associated examples for use 55 | - [ ] The package is easy to install 56 | 57 | 58 | #### Functionality 59 | 60 | - [ ] **Installation:** Installation succeeds as documented. 61 | - [ ] **Functionality:** Any functional claims of the software been confirmed. 62 | - [ ] **Performance:** Any performance claims of the software been confirmed. 63 | - [ ] **Automated tests:** 64 | - [ ] All tests pass on the reviewer's local machine for the package version submitted by the author. Ideally this should be a tagged version making it easy for reviewers to install. 65 | - [ ] Tests cover essential functions of the package and a reasonable range of inputs and conditions. 66 | - [ ] **Continuous Integration:** Has continuous integration setup (We suggest using Github actions but any CI platform is acceptable for review) 67 | - [ ] **Packaging guidelines**: The package conforms to the pyOpenSci [packaging guidelines](https://www.pyopensci.org/python-package-guide). 68 | A few notable highlights to look at: 69 | - [ ] Package supports modern versions of Python and not [End of life versions](https://endoflife.date/python). 70 | - [ ] Code format is standard throughout package and follows PEP 8 guidelines (CI tests for linting pass) 71 | 72 | #### For packages also submitting to JOSS 73 | 74 | - [ ] The package has an **obvious research application** according to JOSS's definition in their [submission requirements](http://joss.theoj.org/about#submission_requirements). 75 | 76 | *Note:* Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted. 77 | 78 | The package contains a `paper.md` matching [JOSS's requirements](http://joss.theoj.org/about#paper_structure) with: 79 | 80 | - [ ] **A short summary** describing the high-level functionality of the software 81 | - [ ] **Authors:** A list of authors with their affiliations 82 | - [ ] **A statement of need** clearly stating problems the software is designed to solve and its target audience. 83 | - [ ] **References:** With DOIs for all those that have one (e.g. papers, datasets, software). 84 | 85 | #### Final approval (post-review) 86 | 87 | - [ ] **The author has responded to my review and made changes to my satisfaction. I recommend approving this package.** 88 | 89 | Estimated hours spent reviewing: 90 | 91 | --- 92 | 93 | #### Review Comments 94 | 95 | 96 | ``` 97 | -------------------------------------------------------------------------------- /our-process/review-timeline.md: -------------------------------------------------------------------------------- 1 | # An Overview Of the Peer Review Process 2 | 3 | ## pyOpenSci open peer review steps 4 | There are several components to the pyOpenSci peer review process. Below, we overview the entire process 5 | from start to finish. 6 | 7 | ### Step 0. *optional* : Author submits pre-submission inquiry 8 | A **presubmission inquiry** is useful if you are unsure whether your package 9 | is in scope. To submit a pre-submission inquiry, open up an issue using the presubmission template in our [pyopensci/software-review repository](https://github.com/pyOpenSci/software-review/issues/new/choose/). During this time an editor in chief will review for scope and perform 10 | a basic check for package infrastructure. 11 | 12 | - Estimated time: ~1-2 weeks 13 | 14 | **Below, are the basic checks that your package should have prior to being 15 | submitted for peer review.** These are the checks that an editor in chief and/or 16 | editor will look at when evaluating your package for review. 17 | 18 | ```{include} /appendices/editor-in-chief-checks.md 19 | ``` 20 | 21 | ### 1. Author submits their package for review 22 | 23 | To do this, you open an issue using the software submission template in our 24 | [pyopensci/software-review repository](https://github.com/pyOpenSci/software-review/issues/new/choose/). 25 | 26 | ### 2. Editor in chief reviews package submission 27 | 28 | The editor in chief will review your submission at this point for both package scope and minimal infrastructure criteria 29 | (listed above). 30 | - TIME ~2 weeks (or longer if editor requests changes that take the author longer to implement) 31 | 32 | ### 3. Editor finds reviewers for package 33 | At this point if your package has the minimal infrastructure 34 | requirements and is in scope, the editor in chief will assign an editor 35 | to review your package. That editor will then identify 36 | suitable reviewers. 37 | 38 | Time: ~2-3 weeks 39 | 40 | ### 4. Peer review of submitted Python Package begins 41 | Once we have an editor and 2 reviewers on board, review begins. **Reviewers have 3 weeks to return a review.** To do this, 42 | they will use our reviewer template in the [reviewer guide](/how-to/reviewer-guide.md) and paste that, filled out, into the issue. 43 | 44 | TIME: ~3 weeks 45 | 46 | ### 5. Author responds to reviews 47 | 48 | At this point the authors should respond to the review. We prefer that **authors 49 | respond within 2 weeks of the submitted review**. We also understand that it may 50 | take longer to actually implement the changes requested in the review. However, we 51 | kindly request that authors respond to reviews to acknowledge 52 | that they have seen them. 53 | 54 | The reviewers are encouraged to open pull requests and issues to help the 55 | maintainers update their package. 56 | 57 | *Often there is some back and forth between reviewers and maintainers at this step.* 58 | 59 | There is no specified duration for this period. Rather as long as all 60 | parties are responsive within 2 weeks, the review shall continue until the author has completed work to address the reviews. 61 | 62 | ### 6. Package acceptance 63 | 64 | Once the maintainers have completed updating the package, the assigned editor 65 | will ask the reviewers if they are happy with changes made. At this point the 66 | editor performs one last check on the package and accepts it if that is appropriate. 67 | 68 | Now, there are a few final cleanup activities including: 69 | 70 | * Adding the pyOpenSci peer-reviewed badge to the package README file. 71 | * Creating a new release on GitHub from the reviewed version. 72 | * Adding package authors and the package to the pyOpenSci website. 73 | 74 | The package is now accepted into the pyOpenSci ecosystem! 75 | 76 | ### JOSS submission 77 | 78 | JOSS refers to the [Journal of Open Source Software](https://joss.theoj.org/). If the maintainer wishes, and their package is within JOSS' scope, they can now 79 | be fast tracked through the JOSS review process (another review is not required 80 | for this step). 81 | 82 | ## Peer review guides 83 | 84 | If you want to learn more about each step listed above, we suggest that you read 85 | through the peer-review guides below that are tailored to each role in the peer review process: 86 | 87 | 88 | ::::{grid} 1 1 1 2 89 | :class-container: text-center 90 | :gutter: 3 91 | 92 | :::{grid-item-card} {octicon}`code-square;1.5em;sd-mr-1` Author / Maintainer Guide 93 | :link: /how-to/author-guide 94 | :link-type: doc 95 | :class-header: bg-light 96 | 97 | Learn everything that you need to know about the peer review for **package maintainers** who submit a package to pyOpenSci for peer review. 98 | +++ 99 | Learn more » 100 | ::: 101 | 102 | :::{grid-item-card} {octicon}`pencil;1.5em;sd-mr-1` Editor Guide 103 | :link: /how-to/editors-guide 104 | :link-type: doc 105 | :class-header: bg-light 106 | +++ 107 | 108 | Learn about the process that editors follow in the pyOpenSci peer review 109 | process. 110 | +++ 111 | Learn more » 112 | ::: 113 | 114 | :::{grid-item-card} {octicon}`codescan-checkmark;1.5em;sd-mr-1` Reviewer Guide 115 | :link: /how-to/reviewer-guide 116 | :link-type: doc 117 | :class-header: bg-light 118 | 119 | Click here to read more about the process that reviewers take when reviewing 120 | a Python package for pyOpenSci. 121 | 122 | +++ 123 | Learn more » 124 | ::: 125 | 126 | :::{grid-item-card} {octicon}`pencil;1.5em;sd-mr-1` ✨ Editor in chief Guide 127 | :link: /how-to/editor-in-chief-guide 128 | :link-type: doc 129 | :class-header: bg-light 130 | 131 | The editor in chief is a rotating position within pyOpenSci held by members 132 | of the pyOpenSci editorial board. Learn more about the processes involved with 133 | being an editor in chief for pyOpenSci. 134 | +++ 135 | Learn more » 136 | ::: 137 | 138 | :::: 139 | -------------------------------------------------------------------------------- /about/our-goals.md: -------------------------------------------------------------------------------- 1 | # pyOpenSci Software Peer Review Goals 2 | 3 | Python is a flexible programming language that is used across numerous 4 | disciplines and domains. Python is so flexible that it is 5 | one of the few languages that can be used to wrap around other languages. 6 | 7 | If you are building a pure Python package, your setup may be simple. 8 | However, some scientific packages have complex 9 | requirements as they may need to support extensions or tools written 10 | in other languages such as C or C++. 11 | 12 | To support the myriad uses of Python, there are many ways 13 | to create a Python package. 14 | 15 | ```{admonition} Python supports extensions written in other languages 16 | :class: info 17 | 18 | The spatial data tool stack is a common example of tools that 19 | often have complex packaging requirements given they often need to use 20 | tools like GDAL to support spatial operations. 21 | ``` 22 | 23 | ## What makes Python unique and valuable can also make packaging complex 24 | The diversity of packaging options can be confusing, particularly 25 | if you are new to Python. However, we are working on a [Python packaging guide](https://www.pyopensci.org/python-package-guide) 26 | that will make the packaging landscape far easier to navigate. 27 | 28 | 29 | ## Working towards standardized packaging practices in the Scientific Python community 30 | 31 | While there is no single solution to the diverse needs of developers in the 32 | Python scientific community, pyOpenSci strives to encourage a standard approach 33 | to packaging through tutorials, documentation and guides as well as its peer review process. We do this by: 34 | 35 | 1. Following and encouraging best practices for Python packaging that follow modern Python Enhancement Protocols (PEPs). PEPs are standards written for the broader Python community to follow. 36 | 1. Reinforcing best practices accepted by the scientific community. This community most often develops packages that are not pure Python. Thus, the scientific community has additional layers of complexity in their tool builds that we need to consider. 37 | 1. Enforcing documentation best practices in our reviews that support both usability and accessibility. Great documentation is critical for a package to gain more users from varying backgrounds. 38 | 39 | As such, pyOpenSci embraces community driven standards created by organizations 40 | such as [Scientific Python](https://scientific-python.org/). 41 | 42 | We also endeavor to help maintainers use a similar infrastructure for 43 | their packages. In the long term, consistent infrastructure 44 | and packaging approaches will: 45 | 46 | * Make it easier for those who are new to packaging to get started (and in turn push open science forward), 47 | * Make it easier for new contributors to participate given similar infrastructure setup across the ecosystem. 48 | 49 | As it makes sense, we recommend (but do not require) packaging 50 | approaches implemented by existing packages in the scientific Python 51 | ecosystem. 52 | 53 | 54 | 55 | ## Specific pyOpenSci goals 56 | In addition to the broader goals laid out above, our specific goals for open peer review of Python packages are as follows. 57 | 58 | ### 1. A catalog of vetted, maintained tools 59 | We hope that scientists will look to [our online catalog of 60 | maintained and vetted tools](https://www.pyopensci.org/python-packages.html) to help them find tools that they can 61 | depend on. Over time as our catalog grows, this will reduce the 62 | need for searching and sorting through the many packages in various 63 | states of maintenance on PyPI. 64 | 65 | Through our peer review, we also help maintainer with outreach 66 | about their packages through our website, blog and social media 67 | presence. Currently, the most popular content on our website are 68 | the [blogs that maintainers have written about their tools](https://www.pyopensci.org/blog/movingpandas-movement-data-analysis). 69 | 70 | ### 2. Improved package usability through documentation 71 | 72 | Clear and useful documentation makes it easier for scientists to use your tools. 73 | During our reviews, we look carefully at: 74 | * documentation, 75 | * quick start tutorials and code examples to help users get started, 76 | * and code documentation (docstrings) 77 | 78 | to ensure that the package is user friendly. If you need help with documentation, 79 | we also have an entire section of our packaging guide devoted to documentation. 80 | 81 | ### 3. Reduce the number of packages with overlapping functionality 82 | 83 | It is easy to find multiple packages on `PyPI` that perform that same tasks 84 | (or overlapping tasks). When you submit a package to us, we ask that you cross reference 85 | other packages in our system that may perform similar purposes. This check will 86 | help us connect maintainers who are working towards similar functionality goals. 87 | It will also help us in the long term reduce the number of overlapping packages, 88 | in various states of maintenance on `PyPI`. 89 | 90 | In some cases just adding information to your **README.md** about how your 91 | package varies from others in the ecosystem is extremely valuable to users. 92 | 93 | * [See our discussion of package overlap for more](package-overlap) 94 | 95 | ### 4. Support long term maintenance of vetted tools 96 | 97 | Most maintainers are not renumerated for their efforts and thus work on tools 98 | in their free time. So what happens when a maintainer of a commonly used tool wants 99 | to step down? We help maintainers identify someone new to take over the reigns. 100 | If that doesn't make sense, we will help the maintainer gracefully sunset the 101 | package. 102 | 103 | One key element in this process is a clear development guide that outlines 104 | the tools and workflows that you are using to build and maintain your package. 105 | 106 | ### 5. Support implementation of standards and best practices 107 | 108 | Where possible we encourage and help maintainers to update and 109 | enhance their package infrastructure. Examples of this include moving 110 | package metadata from the `setup.py` file and into the modern 111 | [`pyproject.toml` standard format](https://snarky.ca/what-the-heck-is-pyproject-toml/). 112 | 113 | ### 6. Build a community support system for maintainers 114 | 115 | Many packages that are commonly used by scientists are being maintained by a single person. As devoted as this single maintainer 116 | may be, it is always easier to work when you have community support. 117 | 118 | Our online community both on [discourse](https://pyopensci.discourse.group/) and more privately on slack, is available for maintainers to interact with each other, ask questions and get support. Core to our 119 | mission is building a welcoming and diverse community for people 120 | of both differing technical background and skill as well as varying cultural background. 121 | -------------------------------------------------------------------------------- /how-to/peer-review-lead.md: -------------------------------------------------------------------------------- 1 | # Peer Review Lead Guide 2 | 3 | :::{tip} 4 | There are several resources that will help you with this role. 5 | Make sure that you have access to the: 6 | 7 | * shared Google folder that contains a list of editors and reviewers who have recently signed up to participate in our review process 8 | * Check out our [peer review status dashboard](https://www.pyopensci.org/metrics/peer-review/peer-review-status-dashboard.html) for the state of peer review 9 | * [Check out our editorial dashboard](https://www.pyopensci.org/metrics/peer-review/editorial-dashboard.html) to get a sense of how many of our editors are busy, and who might be available to lead a review. 10 | * Check out the current review status for the [current state of peer review](https://www.pyopensci.org/metrics/peer-review/current-review-status.html) 11 | ::: 12 | 13 | 14 | The Peer Review Lead is responsible for keeping the software review process moving forward. They are responsible for: 15 | 16 | * Keeping the review process moving forward by checking in on stalled reviews and supporting the editorial team. 17 | * Ensuring a diverse and active editorial board. 18 | * Onboarding and offboarding new editors. 19 | * Making updates to the [pyOpenSci Software Peer Review Guide](https://www.pyopensci.org/software-peer-review/) as needed. 20 | * Updating [software peer review policies](https://www.pyopensci.org/software-peer-review/our-process/policies.html) as needed. 21 | * Helping editors find reviewers as necessary. 22 | 23 | This role will also help manage conflicts that may arise in the software peer review process. 24 | 25 | :::{note} 26 | The pyOpenSci Executive Director has historically held the lead role in peer review. However, we are transitioning this role to a stipend position, which a community volunteer with excellent organizational and communication skills will hold. 27 | 28 | Ideally, this person has experience with our peer review process as an editor or has been part of our community for some time and is familiar with the process. 29 | ::: 30 | 31 | ## How to keep peer review moving forward 32 | 33 | A volunteer editorial team runs software peer review; it also relies on volunteer community reviewers. As with any volunteer-led effort, it is common for the review process to stall or slow down. 34 | 35 | As Peer Review Lead, you should monitor the status of reviews and help editors move stalled reviews forward. Our [review status dashboard](https://www.pyopensci.org/metrics/peer-review/current-review-status.html) will help you stay informed about the overall review process. 36 | 37 | Ideally, you should check in on peer reviews weekly or every other week, depending on the volume of reviews submitted. We anticipate that your time allocation in this role will be 4-8 hours a month. Some months may require additional hours if we are working on new policies. Others you may simply be checking in on the review process. 38 | 39 | Keep an eye on a few things when you check in: 40 | 41 | ### 1. Dashboard: check the date the comment date for every review 42 | 43 | Before you begin, ensure the peer review dashboard is up to date. At the top of the dashboard, you will see the **Last Updated** date. The metrics repository has a cron job that runs weekly to update review status metrics. If the date at the top of the page is older than 1-2 weeks, likely, a pull request, [similar to this one](https://github.com/pyOpenSci/metrics/pull/147) needs to be merged. Go ahead and merge that PR if one exists. If the dashboard date is old and there is no open PR to merge, our cron job has likely failed. In that case, please leave a note in our Slack `#pyos-maintainers-infrastructure` channel. Our infrastructure lead can investigate and resolve any issues that arise with our build. 44 | 45 | :::{image} /images/peer-review-metrics-dashboard.png 46 | :alt: Dashboard last updated date 47 | ::: 48 | 49 | ### 2. Check in on prereview checks 50 | 51 | Next, check in on the prereview checks by sorting the [all-open-reviews table](https://www.pyopensci.org/metrics/peer-review/current-review-status.html#all-open-reviews) table on the **Active_Status** column. Sometimes our Editor in Chief becomes overwhelmed with too many submissions at once. It's easy to forget that they are also able to [delegate the prereview checks to another editor on the team](pre-review-checks) if they fall behind. You can remind them and even help them find other editors to step in if needed. 52 | 53 | ### 3. Identify and check in on stalled reviews 54 | 55 | The [All Open Reviews](https://www.pyopensci.org/metrics/peer-review/current-review-status.html#all-open-reviews) section of this page will also help you keep tabs on the current activity status of our reviews. 56 | 57 | Check out the **The last date a comment was left on a review.** You can sort the table by this column to see the date that someone last commented on the issue. 58 | 59 | If a review has been quiet for over a month, it's a good idea to check in on things. You can either leave a note on the issue to see if anyone responds (this is ideal, as you can then track when someone responds to the issue or if you were the last person to respond!). If momentum is not gained by leaving a note for the editor and reviewers on the issue, then follow up with the editor in Slack after 2 weeks to see if they need some support. If Slack doesn't work normally, email works as a last attempt to connect with the editor. 60 | 61 | Also, check out the days open column. Keep an eye out for reviews that have been open for longer than 6 months. In some cases, you may want to check in with the editor to see how things are going and whether there is a way to move the review forward. 62 | 63 | In some cases a review hasn't moved forward because the editor is struggling to find reviewers. [This page](finding-reviewers) will help you with some tips on helping an editor find reviewers. Sometimes this is as easy as posting in our pyOpenSci #software-review channel. Other times we might need to run a call for reviewers. 64 | 65 | ### 4. Check the reviews seeking editors section 66 | 67 | The [**Editors Needed** section of the dashboard](https://www.pyopensci.org/metrics/peer-review/current-review-status.html#editors-needed) is useful for you to check in and see how the Editor in Chief (EiC) is doing. In some cases, the Editor in Chief needs support in onboarding a new editor. If packages are seeking editors for more than a month, it's time to check in. Sometimes, all that is needed is for the package to have an editor, but the YAML at the top of the issue hasn't been filled out properly. This is an easy fix - just add the editor to the `editor:` field at the top of the issue. In other cases, we may need to run a call for more editors. In that case, you can consult 68 | * Post in the software-review channel to see if anyone in our Slack community is interested in stepping into an editorial role 69 | * Please reach out to the Executive Director about posting on social media to find a new editor to join our team. [The editorial signup form can be found here](https://forms.gle/VEUxEzN6YmeWSb6t8), and the responses (names, emails, and domains only) to that form can be provided to you by the Executive Director upon request. It's not publicly shared to maintain the privacy of those who sign up to volunteer with us. 70 | -------------------------------------------------------------------------------- /about/intro.md: -------------------------------------------------------------------------------- 1 | # About the pyOpenSci software peer review process 2 | 3 | ```{toctree} 4 | :hidden: 5 | :caption: About peer review 6 | 7 | Intro 8 | Our Goals 9 | Benefits for Package Authors 10 | Package Scope (What we review) 11 | Why Open Review Matters 12 | 13 | ``` 14 | 15 | ```{toctree} 16 | :hidden: 17 | :caption: Our Process 18 | 19 | How Review Works <../our-process/how-review-works> 20 | Review Timeline <../our-process/review-timeline> 21 | Peer Review Policies <../our-process/policies> 22 | Code of Conduct <../code-of-conduct> 23 | ``` 24 | 25 | ```{toctree} 26 | :hidden: 27 | :caption: Appendices 28 | 29 | Changelog <../changelog> 30 | Glossary <../appendices/glossary> 31 | Templates <../appendices/templates> 32 | Contributing <../CONTRIBUTING> 33 | ``` 34 | 35 | ## Community-driven software peer review 36 | 37 | pyOpenSci leads an open, volunteer-based review process for scientific Python 38 | open source software. Our review process focuses on: 39 | 40 | - Code quality and style, 41 | - Documentation quality, 42 | - Package usability, 43 | - Test coverage that supports the maintenance of code function. Test coverage also makes it easier for contributors to understand how their contributions impact other parts of the code, 44 | - Evaluation of infrastructure such as continuous integration that runs test suites and code format checks on pull requests. This infrastructure supports software quality and reliability. It also makes it easier for contributors to submit changes to the code base and know that those changes aren't breaking other parts of the code. 45 | 46 | The overarching goal of this review process is to improve the quality, 47 | consistency and usability of scientific software tools over time. Further, we 48 | ensure that packages in our ecosystem are continuously maintained. Over time 49 | knowing that a tool is both vetted and maintained builds trust with tool users in the community. 50 | 51 | ## Peer review is needed in the scientific community 52 | 53 | Software peer review supports scientists receiving credit for putting in the 54 | effort of making tools that scientists need to propel open science forward. 55 | Software peer review provides credit for the community investment that 56 | developers make in creating and maintaining scientific software in the same way 57 | that paper review recognizes scientific findings. 58 | 59 | ### Peer review also addresses issues specific to the Python ecosystem 60 | 61 | The pyOpenSci peer review program also addresses several issues 62 | that are specific to the scientific Python ecosystem: 63 | 64 | 1. The struggle for scientists to select the right tool to use for their workflow given that there are often multiple packages with overlapping functionality and varying levels of maintenance. [See this example of the many packages that interface with Twitter on `PyPI`](https://pypi.org/search/?q=twitter) 65 | 1. Packages that are not documented enough to support: 66 | - Contributions from others 67 | - Directions on how to get started using the package functionality (quick start vignettes or tutorials) 68 | 1. Packages using varying types of packaging and documentation approaches making it more difficult to contribute. 69 | 1. Packages that are well-maintained and used but then maintenance comes to a halt when the maintainer needs to step down (burn-out is common and understandable). 70 | 1. Packages that are missing proper licensing and citation information. 71 | 72 | Further, pyOpenSci addresses the issue of software maintenance. 73 | It addresses the question: 74 | 75 | > What happens to a tool that the community is using when the maintainer needs to step down 76 | 77 | In these cases pyOpenSci will help find a new maintainer(s) for that tool. If 78 | that is not possible, we will help sunset the package in a way that allows 79 | users to gracefully update their workflows rather than be caught by 80 | surprise when a new bug arises. 81 | 82 | ### Peer review of open source software helps maintain consistent quality 83 | 84 | Peer review of python tools that support science is critical to enforcing 85 | quality and usability standards. All pyOpenSci packages contributed by the 86 | community undergo a transparent, constructive, non adversarial and open peer 87 | review process. The goal of that process is to enforce commonly accepted standards. 88 | These standards include technical structure of the package, usability of the 89 | package, documenting package functionality in a way that is accessible 90 | to all levels of users as well as proper licensing and citation information. 91 | 92 | ### Why is pyOpenSci focused on the Python programming language? 93 | 94 | Python is a general programming language used across many different applications 95 | that extend well beyond science. Furthermore, the Python package landscape is 96 | highly dynamic and constantly evolving to support many different types of 97 | users and developers. 98 | 99 | As such there is a huge amount of variation 100 | in the scientific Python ecosystem in terms of how tools are built, supported 101 | and documented. This variation can be hard for software users (data scientists for example) to find the right tool to use for their workflow. 102 | 103 | We aspire to help scientists find the high quality, documented and 104 | maintained tools that they need to do their science. We also support 105 | developers in maintaining their tools and receiving credit for their work. 106 | 107 | Our _peer review_ badge 108 | and catalog of tools will help scientists find the tools that they need. Our 109 | diverse and welcoming community will support maintainers as they maintain their tools. Advocating for citation of software will also help maintainers 110 | receive academic credit for their work. 111 | 112 | ```{note} 113 | [This blog post](https://www.numfocus.org/blog/how-ropensci-uses-code-review-to-promote-reproducible-science/) written by editors from our partner organization, rOpenSci, is a good introduction to the pyOpenSci software peer review process. 114 | ``` 115 | 116 | ### How do I know that a Python package has been reviewed by pyOpenSci? 117 | 118 | You can identify pyOpenSci packages that have been peer-reviewed by the green 119 | "peer-reviewed" badge at the top of their `README.md` file. 120 | 121 | :::{figure-md} pyos-badge 122 | :class: myclass 123 | 124 | The pyOpenSci Peer Reviewed badge 125 | 126 | pyOpenSci Peer Review Badge 127 | ::: 128 | 129 | This badge is added by the package author after the package 130 | has successfully completed review and ideally links to the specific GitHub issue 131 | where the tool was reviewed. [See this example from devicely, one of our accepted pyOpenSci ecosystem packages](https://github.com/hpi-dhc/devicely). 132 | 133 | 134 | ### Partnership with JOSS 135 | 136 | pyOpenSci collaborates with organizations that support the scientific community, for example, Journal of Open Source Software (JOSS). 137 | We are not a publisher, but rather a community that supports Python-specific packages. You don't have to choose between JOSS and us since we are complementary. See details [here](https://www.pyopensci.org/software-peer-review/partners/pangeo.html). 138 | -------------------------------------------------------------------------------- /how-to/reviewer-guide.md: -------------------------------------------------------------------------------- 1 | (reviewer-guide-sphinx)= 2 | # Guide for Reviewers 3 | 4 | ```{epigraph} 5 | Thank you for taking the time to review a package for pyOpenSci and for contributing 6 | to making open source scientific software easier to use by the community! If you 7 | have any questions about the review process, feel free to reach out to one of 8 | our editors or to post a question on our [discourse forum](https://pyopensci.discourse.group/). 9 | ``` 10 | 11 | Please be respectful and kind to the authors in your reviews. Our 12 | [code of conduct](https://www.pyopensci.org/handbook/CODE_OF_CONDUCT.html) is mandatory for everyone involved in our 13 | review process. 14 | 15 | ```{admonition} Not yet a pyOpenSci reviewer? Join us! 16 | :class: note 17 | 18 | We could use your help! Fill out our reviewer form. 19 | We will contact you if we have a package that we need reviewers for. 20 | It’s OK if you’ve never reviewed a package before! We’ll walk you through it. 21 | 22 | [Sign-up Here (Google Form)](https://forms.gle/GHfxvmS47nQFDcBM6) 23 | ``` 24 | 25 | 26 | ## A guide for new reviewers 27 | 28 | Thank you for considering reviewing for pyOpenSci. We welcome reviewers 29 | from a diversity of background and with varying levels of Python technical 30 | expertise. 31 | 32 | Some of the basic things that we look for in a review include: 33 | 34 | * Familiarity with using the Python programming language. 35 | * Ability to evaluate a Python package for usability and documentation quality. 36 | * Ability to provide a technical review of Python package structure and code quality / approach to solving the problems that the package seeks to address. 37 | 38 | We like to have a mix of technical and usability focus in our reviews so it's ok if you don't have all of the above skills! 39 | 40 | ```{admonition} New to package review? We offer mentorship! 41 | :class: note 42 | 43 | If you are interested in peer review but have never reviewed before, 44 | we offer a mentorship program where we will pair you up with someone 45 | who has more experience reviewing code. From this experience you can 46 | learn more and empower yourself with code review skills. Software review skills 47 | are generally useful in data science, so they are skills worth investing in! 48 | ``` 49 | 50 | ## Get Started With Your Review 51 | As a new reviewer you should start by installing the package that you are 52 | reviewing locally to test it out. 53 | 54 | To install the package, you can either: 55 | 56 | * fork the package repository and install it in 57 | development/ editable mode `pip install --editable .` 58 | * or you can install it directly from `pip` or `conda-forge`. 59 | 60 | ```{important} 61 | Be sure 62 | that the version that you are reviewing aligns with the version 63 | submitted by the author. The package version can 64 | be found at the top of the review issue. In the example below you can 65 | see that `pyrolite` version 0.2.5 66 | was submitted for review. 67 | 68 | That is the version that you should install! 69 | 70 | ``` 71 | 72 | Example header of a peer review submission issue on GitHub: 73 | 74 | ``` 75 | Submitting Author: Name (@morganjwilliams) 76 | Package Name: pyrolite 77 | One-Line Description of Package: A set of tools for getting the most from your geochemical data. 78 | Repository Link: https://github.com/morganjwilliams/pyrolite 79 | Version submitted: 0.2.5 80 | Editor: @lwasser 81 | ``` 82 | 83 | ### General Guidelines For Reviewing A Python Package for PyOpenSci 84 | 85 | ```{note} 86 | If you are submitting a review, we appreciate submission within 3 weeks of 87 | accepting a review. Please contact the editor directly or in the submission 88 | thread to inform them about possible delays. 89 | ``` 90 | 91 | To review a package, please begin by copying our 92 | review template (see below) and using it as a 93 | high-level checklist. 94 | 95 | ```{include} ../appendices/review-template.md 96 | ``` 97 | 98 | ### Other review guidelines to consider 99 | 100 | In addition to checking off the minimum criteria specified 101 | in the review template, please also provide general comments addressing the following: 102 | 103 | - Is the code well written and efficient? 104 | * Are there improvements that could be made to the code style? 105 | * Is there code duplication in the package that should be reduced? 106 | * Are there performance improvements that could be made? 107 | * Are functions and arguments named to work together to form a common, logical programming API that is easy to read, and autocomplete? 108 | 109 | * Does the package comply with [the pyOpenSci packaging guide](https://www.pyopensci.org/python-package-guide)? 110 | 111 | * Are there user interface improvements that could be made? 112 | * Is the documentation (installation instructions/vignettes/examples/demos) clear and sufficient? 113 | * Does the documentation use the principle of *multiple points of entry* i.e. takes into account the fact that any piece of documentation may be the first encounter the user has with the package and/or the tool/data it wraps? 114 | 115 | If you have your own relevant data/problem that you could use the package to solve, work through it with the package. You may find rough edges and use-cases the author didn't think about. 116 | 117 | ```{important} 118 | Some maintainers do not ship the tests with their package. 119 | This means that the dependencies for testing may be missing. 120 | Check to have at least pytest installed. 121 | Also, when cloning the repository to run the tests, please check the cloned version aligns with the submitted one. 122 | ``` 123 | 124 | ## Submit your review 125 | * When your review is complete, paste it as a comment into the package software-review issue. 126 | * Additional comments are welcome in the same issue. We hope that package reviews will work as an ongoing conversation with the authors as opposed to a single round of reviews typical of academic manuscripts. 127 | * You may also submit issues or pull requests directly to the package repo if you choose, but if you do, please comment about them and link to them in the software-review repo comment thread so we have a centralized record and text of your review. 128 | * Please include an estimate of how many hours you spent on your review afterwards. 129 | 130 | ## Review follow-Up 131 | Authors should respond within 2 weeks with their changes to the package in response to your review. At this stage, we ask that you respond as to whether the changes sufficiently address any issues raised in your review. We encourage ongoing discussion between package authors and reviewers, and you may ask editors to clarify issues in the review thread as well. 132 | 133 | 134 | ### Examples of Past pyOpenSci Reviews 135 | 136 | It might be helpful to consult some previous reviews and read about the 137 | experiences of other reviewers. In general you can find submission threads of 138 | onboarded packages here. Here are a few chosen examples of reviews (note that 139 | your reviews do not need to be as long as these examples): 140 | 141 | * `MovingPandas` [review 1](https://github.com/pyOpenSci/software-review/issues/18#issuecomment-579520816) and [review 2](https://github.com/pyOpenSci/software-review/issues/18#issuecomment-581752433) 142 | 143 | * `Pandera` [review 1](https://github.com/pyOpenSci/software-review/issues/12#issuecomment-527622205) and [review 2](https://github.com/pyOpenSci/software-review/issues/12#issuecomment-531491008) 144 | 145 | ## Lessons Learned from rOpenSci 146 | You can read blog posts written by reviewers about their experiences [via this link](https://ropensci.org/tags/reviewer/). In particular, in [this blog post by Mara Averick](https://ropensci.org/blog/2017/08/22/first-package-review/) read about the "naive user" role a reviewer can take to provide useful feedback even without being experts of the package's topic or implementation, by asking themselves _"What did I think this thing would do? Does it do it? What are things that scare me off?"_. In [another blog post](https://ropensci.org/blog/2017/09/08/first-review-experiences/) Verena Haunschmid explains how she alternated between using the package and checking its code. 147 | 148 | As both a former reviewer and package author [Adam Sparks](https://adamhsparks.com) [wrote this](https://twitter.com/adamhsparks/status/898132036451303425) "[write] a good critique of the package structure 149 | and best coding practices. If you know how to do something better, tell 150 | me. It’s easy to miss documentation opportunities as a developer, as a 151 | reviewer, you have a different view. You’re a user that can give 152 | feedback. What’s not clear in the package? How can it be made more 153 | clear? If you’re using it for the first time, is it easy? Do you know 154 | another `R` package that maybe I should be using? Or is there one I’m 155 | using that perhaps I shouldn’t be? If you can contribute to the package, 156 | offer." 157 | 158 | ### Feedback on the pyOpenSci open peer review process 159 | 160 | We welcome any feedback and/or questions about the review process! We encourage you to post any issues, feedback or questions in our [Discourse forum](https://pyopensci.discourse.group/c/review-process/7). 161 | -------------------------------------------------------------------------------- /images/astropy_project_logo.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 | 7 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 27 | 29 | 31 | 32 | 33 | 34 | 35 | 36 | 37 | 38 | 40 | 41 | 42 | 44 | 52 | 55 | 57 | 64 | 65 | 66 | 71 | 75 | 76 | 77 | 78 | 81 | 87 | 88 | 89 | 90 | 93 | 95 | 102 | 106 | 112 | 117 | 121 | 122 | 123 | 124 | -------------------------------------------------------------------------------- /_static/pyos.css: -------------------------------------------------------------------------------- 1 | /* PyOS-specific vars :) */ 2 | :root { 3 | --pyos-color-primary: #703c87; 4 | --pyos-color-secondary: #8045e5; 5 | --pyos-color-secondary-highlight: #591bc2; 6 | --pyos-color-tertiary: #A66C98; 7 | --pyos-color-dark: #542568; 8 | --pyos-color-light: #DAABCF; 9 | 10 | /* Darkmode Adjustments*/ 11 | --pyos-dm-color-primary: #C483E0; 12 | 13 | /* Fonts (overrides base theme) */ 14 | --pst-font-family-heading: 'Poppins', sans-serif; 15 | --pst-font-family-base: 'Poppins', sans-serif; 16 | --pyos-font-family-h1: 'Itim', serif; 17 | 18 | } 19 | 20 | 21 | /* anything related to the dark theme */ 22 | html[data-theme="dark"] { 23 | --pst-color-info-bg: #400f59!important; 24 | --pst-color-tbl-row: #2E2E2E!important; 25 | } 26 | 27 | /* anything related to the light theme */ 28 | html[data-theme="light"] { 29 | --pst-color-tbl-row: #f5f1ff!important; 30 | } 31 | } 32 | 33 | 34 | html, body { 35 | font-size: 1.0rem; 36 | } 37 | 38 | /* Allow the center content to expand to wide on wide screens */ 39 | @media (min-width: 960px){ 40 | .bd-page-width { 41 | max-width: min(100%, 1600px)!important; 42 | } 43 | } 44 | 45 | /* Make sure the header nav is centered - not sure why it's not overriding*/ 46 | .navbar-header-items .me-auto, .me-auto .navbar-header-items__center { 47 | margin-left: auto!important; 48 | margin-right: auto!important; 49 | } 50 | 51 | /* custom fonts */ 52 | 53 | html, body { 54 | font-size: 1.02rem; 55 | } 56 | 57 | body p { 58 | } 59 | 60 | .admonition { 61 | margin-top: 60px!important; 62 | margin-bottom: 70px!important; 63 | } 64 | 65 | h1 { 66 | margin-top: 10px; 67 | margin-bottom: 40px; 68 | font-family: var(--pyos-font-family-h1) !important; 69 | color: var(--pyos-h1-color); 70 | } 71 | h2 { 72 | margin-top: 80px; 73 | } 74 | 75 | h3 { 76 | margin-top: 60px} 77 | 78 | figcaption .caption-text { 79 | text-align: left!important; 80 | } 81 | 82 | figure { 83 | margin-top: 60px!important; 84 | margin-bottom: 60px!important; 85 | } 86 | 87 | figcaption { 88 | font-size: .9em; 89 | font-weight: bold; 90 | } 91 | 92 | 93 | .admonition p { 94 | font-size: .9em; 95 | } 96 | 97 | /* Navbar */ 98 | /* 99 | Don't fill all vertical space beneath TOC, which causes 100 | readthedocs version selector to fall off the page and the 101 | ugly scrollbar to show all the time 102 | */ 103 | .bd-sidebar-primary .sidebar-primary-items__end { 104 | margin-bottom: unset; 105 | margin-top: unset; 106 | } 107 | 108 | /* Tutorial block page */ 109 | .left-div { 110 | background-color: #3498db; 111 | color: #fff; 112 | text-align: center; 113 | padding: 20px; 114 | width: 35%; 115 | border-radius: 10px; 116 | } 117 | 118 | .right-div { 119 | margin-top: 10px; 120 | } 121 | 122 | .lesson-div { 123 | cursor: pointer; 124 | transition: background-color 0.3s; 125 | margin-bottom: 10px; 126 | padding: 10px; 127 | border-radius: 5px; 128 | text-align: center; 129 | color: #333; 130 | } 131 | 132 | .lesson-div a { 133 | color: inherit; 134 | text-decoration: none; 135 | display: block; 136 | height: 100%; 137 | width: 100%; 138 | } 139 | 140 | .lesson-div:hover { 141 | background-color: #ccc; 142 | } 143 | 144 | /* Different colors and their shades */ 145 | .lesson-div:nth-child(1) { 146 | background-color: #216A6B; 147 | color: #fff; 148 | } 149 | 150 | .lesson-div:nth-child(2) { 151 | background-color: #6D597A; 152 | color: #fff; 153 | } 154 | 155 | .lesson-div:nth-child(3) { 156 | background-color: #B56576; 157 | color: #fff; 158 | } 159 | 160 | .lesson-div:nth-child(4) { 161 | background-color: #3A8C8E; /* Shade of #216A6B */ 162 | } 163 | 164 | .lesson-div:nth-child(5) { 165 | background-color: #8F7B8D; /* Shade of #6D597A */ 166 | } 167 | 168 | .lesson-div:nth-child(6) { 169 | background-color: #D78287; /* Shade of #B56576 */ 170 | } 171 | 172 | .lesson-div:nth-child(7) { 173 | background-color: #185355; /* Darker shade of #216A6B */ 174 | color: #fff; 175 | } 176 | 177 | 178 | 179 | html[data-theme=light] { 180 | --pst-color-primary: var(--pyos-color-primary); 181 | --pst-color-primary-text: #fff; 182 | --pst-color-primary-highlight: #053f49; 183 | --sd-color-primary: var(--pst-color-primary); 184 | --sd-color-primary-text: var(--pst-color-primary-text); 185 | --sd-color-primary-highlight: var(--pst-color-primary-highlight); 186 | --sd-color-primary-bg: #d0ecf1; 187 | --sd-color-primary-bg-text: #14181e; 188 | --pst-color-secondary: var(--pyos-color-secondary); 189 | --pst-color-secondary-text: #fff; 190 | --pst-color-secondary-highlight: var(--pyos-color-secondary-highlight); 191 | --sd-color-secondary: var(--pst-color-secondary); 192 | --sd-color-secondary-text: var(--pst-color-secondary-text); 193 | --sd-color-secondary-highlight: var(--pst-color-secondary-highlight); 194 | --sd-color-secondary-bg: #e0c7ff; 195 | --sd-color-secondary-bg-text: #14181e; 196 | --pst-color-success: #00843f; 197 | --pst-color-success-text: #fff; 198 | --pst-color-success-highlight: #00381a; 199 | --sd-color-success: var(--pst-color-success); 200 | --sd-color-success-text: var(--pst-color-success-text); 201 | --sd-color-success-highlight: var(--pst-color-success-highlight); 202 | --sd-color-success-bg: #d6ece1; 203 | --sd-color-success-bg-text: #14181e; 204 | --pst-color-info: #A66C98; /* general admonition */ 205 | --pst-color-info-bg: #eac8e2; 206 | --pst-heading-color: var(--pyos-color-dark); 207 | --pyos-h1-color: var(--pyos-color-dark); 208 | } 209 | 210 | html[data-theme=dark] { 211 | --pst-color-primary: var(--pyos-dm-color-primary); 212 | --pst-color-link: var(--pyos-color-light); 213 | --pst-color-link-hover: var(--pyos-dm-color-primary); 214 | --pyos-h1-color: var(--pyos-color-light); 215 | } 216 | 217 | 218 | /* -------------------------------------- */ 219 | /* Generated by https://gwfh.mranftl.com/ */ 220 | 221 | /* poppins-regular - latin */ 222 | @font-face { 223 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 224 | font-family: 'Poppins'; 225 | font-style: normal; 226 | font-weight: 400; 227 | src: url('./fonts/poppins-v20-latin-regular.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 228 | } 229 | 230 | /* poppins-italic - latin */ 231 | @font-face { 232 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 233 | font-family: 'Poppins'; 234 | font-style: italic; 235 | font-weight: 400; 236 | src: url('./fonts/poppins-v20-latin-italic.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 237 | } 238 | 239 | /* poppins-700 - latin */ 240 | @font-face { 241 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 242 | font-family: 'Poppins'; 243 | font-style: normal; 244 | font-weight: 700; 245 | src: url('./fonts/poppins-v20-latin-700.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 246 | } 247 | 248 | /* poppins-700italic - latin */ 249 | @font-face { 250 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 251 | font-family: 'Poppins'; 252 | font-style: italic; 253 | font-weight: 700; 254 | src: url('./fonts/poppins-v20-latin-700italic.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 255 | } 256 | 257 | /* itim-regular - latin */ 258 | @font-face { 259 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 260 | font-family: 'Itim'; 261 | font-style: normal; 262 | font-weight: 400; 263 | src: url('./fonts/itim-v14-latin-regular.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 264 | } 265 | 266 | /* poppins-500 - latin */ 267 | @font-face { 268 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 269 | font-family: 'Poppins'; 270 | font-style: normal; 271 | font-weight: 500; 272 | src: url('./fonts/poppins-v20-latin-500.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 273 | } 274 | /* poppins-600 - latin */ 275 | @font-face { 276 | font-display: swap; /* Check https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face/font-display for other options. */ 277 | font-family: 'Poppins'; 278 | font-style: normal; 279 | font-weight: 600; 280 | src: url('./fonts/poppins-v20-latin-600.woff2') format('woff2'); /* Chrome 36+, Opera 23+, Firefox 39+, Safari 12+, iOS 10+ */ 281 | } 282 | /* Cards */ 283 | 284 | /* todo light and dark adaptations needed */ 285 | 286 | .sd-card-title { 287 | margin-bottom: 0.5rem; 288 | background-color: var(--pst-color-info-bg)!important; 289 | padding: .5rem; 290 | border-bottom: 2px solid #999; 291 | font-size: 1.2rem; 292 | font-weight: 600!important; 293 | } 294 | 295 | .sd-card-header { 296 | font-size: 1.2em; 297 | font-weight: 600; 298 | } 299 | 300 | .sd-card-body { 301 | padding: 0 0!important; 302 | 303 | .left-aligned 304 | & ul li { 305 | text-align: left; 306 | } 307 | } 308 | 309 | .sd-card { 310 | padding-bottom: 1.5em; 311 | } 312 | 313 | .sd-card-text { 314 | text-align: left; 315 | padding-right: 1.5em; 316 | padding-left: 1.5em; 317 | } 318 | 319 | #footnotes { 320 | font-size: .8em; 321 | line-height: 1.1; 322 | &span.label { 323 | font-weight:400 324 | } 325 | } 326 | 327 | aside.footnote { 328 | margin-bottom: 0.5rem; 329 | &:last-child { 330 | margin-bottom: 1rem; 331 | } 332 | span.label, 333 | span.backrefs { 334 | font-weight: 400!important; 335 | } 336 | 337 | &:target { 338 | background-color: var(--pst-color-target); 339 | } 340 | } 341 | 342 | 343 | .fa-circle-check { 344 | color: #7BCDBA; 345 | } 346 | 347 | /* pyOpenSci table styles */ 348 | 349 | .pyos-table { 350 | & th.head, .pyos-table th.head.stub { 351 | background-color: #33205C!important; 352 | 353 | & p { 354 | color: #fff 355 | } 356 | } 357 | & th.stub { 358 | background-color: var(--pst-color-tbl-row); 359 | font-weight: 500; 360 | } 361 | & td { 362 | vertical-align: middle; 363 | text-align: center; 364 | } 365 | } 366 | 367 | 368 | /* Make the first column in a table a "header" like thing */ 369 | 370 | 371 | /* Dark mode fix for tables */ 372 | @media (prefers-color-scheme: dark) { 373 | td:not(.row-header):nth-child(1) { 374 | background-color: var(--pst-color-tbl-row); /* Adjust the dark mode color */ 375 | color: #ffffff; /* Adjust the text color for better contrast */ 376 | font-weight: 500; 377 | } 378 | } 379 | 380 | td, th { 381 | border: 1px solid #ccc; /* Light gray border */ 382 | padding: 8px; /* Add some padding for better readability */ 383 | } 384 | -------------------------------------------------------------------------------- /.all-contributorsrc: -------------------------------------------------------------------------------- 1 | { 2 | "files": [ 3 | "README.md" 4 | ], 5 | "imageSize": 100, 6 | "commit": false, 7 | "commitConvention": "angular", 8 | "contributors": [ 9 | { 10 | "login": "TomAugspurger", 11 | "name": "Tom Augspurger", 12 | "avatar_url": "https://avatars.githubusercontent.com/u/1312546?v=4", 13 | "profile": "https://tomaugspurger.github.io", 14 | "contributions": [ 15 | "code", 16 | "review", 17 | "design" 18 | ] 19 | }, 20 | { 21 | "login": "arianesasso", 22 | "name": "Ariane Sasso", 23 | "avatar_url": "https://avatars.githubusercontent.com/u/3659681?v=4", 24 | "profile": "http://arianesasso.me", 25 | "contributions": [ 26 | "code", 27 | "review", 28 | "design" 29 | ] 30 | }, 31 | { 32 | "login": "rabernat", 33 | "name": "Ryan Abernathey", 34 | "avatar_url": "https://avatars.githubusercontent.com/u/1197350?v=4", 35 | "profile": "https://github.com/rabernat", 36 | "contributions": [ 37 | "code", 38 | "design", 39 | "review" 40 | ] 41 | }, 42 | { 43 | "login": "NickleDave", 44 | "name": "David Nicholson", 45 | "avatar_url": "https://avatars.githubusercontent.com/u/11934090?v=4", 46 | "profile": "https://nicholdav.info/", 47 | "contributions": [ 48 | "code", 49 | "review", 50 | "design" 51 | ] 52 | }, 53 | { 54 | "login": "stefanv", 55 | "name": "Stefan van der Walt", 56 | "avatar_url": "https://avatars.githubusercontent.com/u/45071?v=4", 57 | "profile": "https://mentat.za.net", 58 | "contributions": [ 59 | "code", 60 | "review", 61 | "design" 62 | ] 63 | }, 64 | { 65 | "login": "eriknw", 66 | "name": "Erik Welch", 67 | "avatar_url": "https://avatars.githubusercontent.com/u/2058401?v=4", 68 | "profile": "https://fosstodon.org/@eriknw", 69 | "contributions": [ 70 | "code", 71 | "review", 72 | "design" 73 | ] 74 | }, 75 | { 76 | "login": "batalex", 77 | "name": "Alex Batisse", 78 | "avatar_url": "https://avatars.githubusercontent.com/u/11004857?v=4", 79 | "profile": "http://batalex.github.io", 80 | "contributions": [ 81 | "code", 82 | "review", 83 | "design" 84 | ] 85 | }, 86 | { 87 | "login": "cmarmo", 88 | "name": "Chiara Marmo", 89 | "avatar_url": "https://avatars.githubusercontent.com/u/1662261?v=4", 90 | "profile": "https://orcid.org/0000-0003-2843-6044", 91 | "contributions": [ 92 | "code", 93 | "review", 94 | "design" 95 | ] 96 | }, 97 | { 98 | "login": "yuvipanda", 99 | "name": "Yuvi Panda", 100 | "avatar_url": "https://avatars.githubusercontent.com/u/30430?v=4", 101 | "profile": "https://github.com/yuvipanda", 102 | "contributions": [ 103 | "code", 104 | "design", 105 | "review" 106 | ] 107 | }, 108 | { 109 | "login": "cosmicBboy", 110 | "name": "Niels Bantilan", 111 | "avatar_url": "https://avatars.githubusercontent.com/u/2816689?v=4", 112 | "profile": "http://cosmicbboy.github.io/", 113 | "contributions": [ 114 | "code", 115 | "review" 116 | ] 117 | }, 118 | { 119 | "login": "willingc", 120 | "name": "Carol Willing", 121 | "avatar_url": "https://avatars.githubusercontent.com/u/2680980?v=4", 122 | "profile": "https://hachyderm.io/web/@willingc", 123 | "contributions": [ 124 | "review", 125 | "code" 126 | ] 127 | }, 128 | { 129 | "login": "choldgraf", 130 | "name": "Chris Holdgraf", 131 | "avatar_url": "https://avatars.githubusercontent.com/u/1839645?v=4", 132 | "profile": "http://chrisholdgraf.com", 133 | "contributions": [ 134 | "review", 135 | "code", 136 | "design" 137 | ] 138 | }, 139 | { 140 | "login": "gawbul", 141 | "name": "Steve Moss", 142 | "avatar_url": "https://avatars.githubusercontent.com/u/321291?v=4", 143 | "profile": "https://www.gawbul.io", 144 | "contributions": [ 145 | "review", 146 | "code" 147 | ] 148 | }, 149 | { 150 | "login": "xmnlab", 151 | "name": "Ivan Ogasawara", 152 | "avatar_url": "https://avatars.githubusercontent.com/u/5209757?v=4", 153 | "profile": "https://github.com/xmnlab", 154 | "contributions": [ 155 | "review", 156 | "code" 157 | ] 158 | }, 159 | { 160 | "login": "kysolvik", 161 | "name": "Kylen Solvik", 162 | "avatar_url": "https://avatars.githubusercontent.com/u/24379590?v=4", 163 | "profile": "https://github.com/kysolvik", 164 | "contributions": [ 165 | "review", 166 | "code", 167 | "design" 168 | ] 169 | }, 170 | { 171 | "login": "matthew-brett", 172 | "name": "Matthew Brett", 173 | "avatar_url": "https://avatars.githubusercontent.com/u/67612?v=4", 174 | "profile": "https://matthew.dynevor.org", 175 | "contributions": [ 176 | "review", 177 | "code" 178 | ] 179 | }, 180 | { 181 | "login": "ReventonC", 182 | "name": "Zehua Chen", 183 | "avatar_url": "https://avatars.githubusercontent.com/u/6276623?v=4", 184 | "profile": "http://zehuachen.com", 185 | "contributions": [ 186 | "review", 187 | "code" 188 | ] 189 | }, 190 | { 191 | "login": "sumit-158", 192 | "name": "Sumit Kashyap", 193 | "avatar_url": "https://avatars.githubusercontent.com/u/96618001?v=4", 194 | "profile": "https://github.com/sumit-158", 195 | "contributions": [ 196 | "code", 197 | "review" 198 | ] 199 | }, 200 | { 201 | "login": "consideRatio", 202 | "name": "Erik Sundell", 203 | "avatar_url": "https://avatars.githubusercontent.com/u/3837114?v=4", 204 | "profile": "https://github.com/consideRatio", 205 | "contributions": [ 206 | "review", 207 | "code" 208 | ] 209 | }, 210 | { 211 | "login": "mbjoseph", 212 | "name": "Max Joseph", 213 | "avatar_url": "https://avatars.githubusercontent.com/u/2664564?v=4", 214 | "profile": "https://mbjoseph.github.io", 215 | "contributions": [ 216 | "review", 217 | "code" 218 | ] 219 | }, 220 | { 221 | "login": "arokem", 222 | "name": "Ariel Rokem", 223 | "avatar_url": "https://avatars.githubusercontent.com/u/118582?v=4", 224 | "profile": "http://arokem.org", 225 | "contributions": [ 226 | "review", 227 | "code" 228 | ] 229 | }, 230 | { 231 | "login": "jmason86", 232 | "name": "James Mason", 233 | "avatar_url": "https://avatars.githubusercontent.com/u/947614?v=4", 234 | "profile": "http://jamespaulmason.com", 235 | "contributions": [ 236 | "review", 237 | "code" 238 | ] 239 | }, 240 | { 241 | "login": "astrojuanlu", 242 | "name": "Juan Luis Cano Rodríguez", 243 | "avatar_url": "https://avatars.githubusercontent.com/u/316517?v=4", 244 | "profile": "https://github.com/astrojuanlu", 245 | "contributions": [ 246 | "code", 247 | "review" 248 | ] 249 | }, 250 | { 251 | "login": "ForgottenProgramme", 252 | "name": "Mahe Iram Khan", 253 | "avatar_url": "https://avatars.githubusercontent.com/u/65779580?v=4", 254 | "profile": "https://forgottenprogramme.github.io/", 255 | "contributions": [ 256 | "code", 257 | "review" 258 | ] 259 | }, 260 | { 261 | "login": "chiinita", 262 | "name": "Qin", 263 | "avatar_url": "https://avatars.githubusercontent.com/u/17188345?v=4", 264 | "profile": "https://github.com/chiinita", 265 | "contributions": [ 266 | "code", 267 | "review" 268 | ] 269 | }, 270 | { 271 | "login": "dstansby", 272 | "name": "David Stansby", 273 | "avatar_url": "https://avatars.githubusercontent.com/u/6197628?v=4", 274 | "profile": "https://www.davidstansby.com", 275 | "contributions": [ 276 | "code", 277 | "review" 278 | ] 279 | }, 280 | { 281 | "login": "pllim", 282 | "name": "P. L. Lim", 283 | "avatar_url": "https://avatars.githubusercontent.com/u/2090236?v=4", 284 | "profile": "https://www.linkedin.com/in/pllim/", 285 | "contributions": [ 286 | "code", 287 | "review" 288 | ] 289 | }, 290 | { 291 | "login": "namurphy", 292 | "name": "Nick Murphy", 293 | "avatar_url": "https://avatars.githubusercontent.com/u/8931994?v=4", 294 | "profile": "https://orcid.org/0000-0001-6628-8033", 295 | "contributions": [ 296 | "code", 297 | "review" 298 | ] 299 | }, 300 | { 301 | "login": "hamogu", 302 | "name": "Hans Moritz Günther", 303 | "avatar_url": "https://avatars.githubusercontent.com/u/498688?v=4", 304 | "profile": "http://space.mit.edu/home/guenther/", 305 | "contributions": [ 306 | "code", 307 | "review" 308 | ] 309 | }, 310 | { 311 | "login": "g-patlewicz", 312 | "name": "g-patlewicz", 313 | "avatar_url": "https://avatars.githubusercontent.com/u/52672925?v=4", 314 | "profile": "https://github.com/g-patlewicz", 315 | "contributions": [ 316 | "code", 317 | "review" 318 | ] 319 | }, 320 | { 321 | "login": "yang-ruoxi", 322 | "name": "ruoxi", 323 | "avatar_url": "https://avatars.githubusercontent.com/u/13646711?v=4", 324 | "profile": "https://github.com/yang-ruoxi", 325 | "contributions": [ 326 | "code", 327 | "review" 328 | ] 329 | }, 330 | { 331 | "login": "grst", 332 | "name": "Gregor Sturm", 333 | "avatar_url": "https://avatars.githubusercontent.com/u/7051479?v=4", 334 | "profile": "https://grst.github.io", 335 | "contributions": [ 336 | "code", 337 | "review" 338 | ] 339 | }, 340 | { 341 | "login": "nutjob4life", 342 | "name": "Sean Kelly", 343 | "avatar_url": "https://avatars.githubusercontent.com/u/814813?v=4", 344 | "profile": "https://about.me/sean.c.kelly", 345 | "contributions": [ 346 | "code", 347 | "review" 348 | ] 349 | }, 350 | { 351 | "login": "kierisi", 352 | "name": "Jesse Mostipak", 353 | "avatar_url": "https://avatars.githubusercontent.com/u/23085445?v=4", 354 | "profile": "https://github.com/kierisi", 355 | "contributions": [ 356 | "code", 357 | "review" 358 | ] 359 | }, 360 | { 361 | "login": "megies", 362 | "name": "Tobias Megies", 363 | "avatar_url": "https://avatars.githubusercontent.com/u/1842780?v=4", 364 | "profile": "https://github.com/megies", 365 | "contributions": [ 366 | "code", 367 | "review" 368 | ] 369 | }, 370 | { 371 | "login": "ctb", 372 | "name": "C. Titus Brown", 373 | "avatar_url": "https://avatars.githubusercontent.com/u/51016?v=4", 374 | "profile": "http://ivory.idyll.org/blog/", 375 | "contributions": [ 376 | "code", 377 | "review" 378 | ] 379 | }, 380 | { 381 | "login": "banesullivan", 382 | "name": "Bane Sullivan", 383 | "avatar_url": "https://avatars.githubusercontent.com/u/22067021?v=4", 384 | "profile": "http://banesullivan.com", 385 | "contributions": [ 386 | "code", 387 | "review" 388 | ] 389 | }, 390 | { 391 | "login": "ab93", 392 | "name": "Avik Basu", 393 | "avatar_url": "https://avatars.githubusercontent.com/u/3485425?v=4", 394 | "profile": "https://github.com/ab93", 395 | "contributions": [ 396 | "code", 397 | "review" 398 | ] 399 | }, 400 | { 401 | "login": "crhea93", 402 | "name": "Carter Lee Rhea", 403 | "avatar_url": "https://avatars.githubusercontent.com/u/34322936?v=4", 404 | "profile": "https://github.com/crhea93", 405 | "contributions": [ 406 | "ideas", 407 | "review", 408 | "code" 409 | ] 410 | }, 411 | { 412 | "login": "coatless", 413 | "name": "James J Balamuta", 414 | "avatar_url": "https://avatars.githubusercontent.com/u/833642?v=4", 415 | "profile": "https://thecoatlessprofessor.com", 416 | "contributions": [ 417 | "code", 418 | "review" 419 | ] 420 | }, 421 | { 422 | "login": "jonas-eschle", 423 | "name": "Jonas Eschle", 424 | "avatar_url": "https://avatars.githubusercontent.com/u/17454848?v=4", 425 | "profile": "https://github.com/jonas-eschle", 426 | "contributions": [ 427 | "review" 428 | ] 429 | }, 430 | { 431 | "login": "InessaPawson", 432 | "name": "Inessa Pawson", 433 | "avatar_url": "https://avatars.githubusercontent.com/u/43481325?v=4", 434 | "profile": "https://github.com/InessaPawson", 435 | "contributions": [ 436 | "code", 437 | "review" 438 | ] 439 | }, 440 | { 441 | "login": "eliotwrobson", 442 | "name": "Eliot Robson", 443 | "avatar_url": "https://avatars.githubusercontent.com/u/1345068?v=4", 444 | "profile": "https://eliotwrobson.github.io/", 445 | "contributions": [ 446 | "review", 447 | "doc" 448 | ] 449 | }, 450 | { 451 | "login": "HaoZeke", 452 | "name": "Rohit Goswami", 453 | "avatar_url": "https://avatars.githubusercontent.com/u/4336207?v=4", 454 | "profile": "https://rgoswami.me", 455 | "contributions": [ 456 | "doc", 457 | "review" 458 | ] 459 | }, 460 | { 461 | "login": "jedbrown", 462 | "name": "Jed Brown", 463 | "avatar_url": "https://avatars.githubusercontent.com/u/3303?v=4", 464 | "profile": "https://jedbrown.org", 465 | "contributions": [ 466 | "doc", 467 | "review" 468 | ] 469 | }, 470 | { 471 | "login": "yeelauren", 472 | "name": "Lauren Yee", 473 | "avatar_url": "https://avatars.githubusercontent.com/u/12127746?v=4", 474 | "profile": "http://www.mapdatascience.com", 475 | "contributions": [ 476 | "doc", 477 | "review" 478 | ] 479 | } 480 | ], 481 | "contributorsPerLine": 6, 482 | "skipCi": true, 483 | "repoType": "github", 484 | "repoHost": "https://github.com", 485 | "projectName": "software-peer-review", 486 | "projectOwner": "pyOpenSci", 487 | "commitType": "docs" 488 | } 489 | -------------------------------------------------------------------------------- /how-to/review-triage-team.md: -------------------------------------------------------------------------------- 1 | # Editorial Review Triage Team 2 | 3 | The editorial board triage team focuses on ensuring review issues are complete with all metadata filled out in each GitHub review issue. Members of this team are considered an integral part of the [pyOpenSci editorial board](https://www.pyopensci.org/about-peer-review/index.html#our-editorial-board). 4 | 5 | ## Estimated time allocation for this team 6 | 7 | It is estimated that the time associated with this role will be a few hours a month, given we normally accept 1-2 packages each month. 8 | 9 | ```{note} 10 | There may be (rare) periods where additional time is needed. These include 11 | 1. When we need to update old, dated reviews and 12 | 1. If many submissions are accepted in a particular month. 13 | 14 | In the case that a time-intensive update process is required, such as a large 15 | update to the review metadata structure, we can enlist the help of others on 16 | the editorial board to get caught up. 17 | 18 | This role should never be a burdensome role on any individual community 19 | volunteer. 20 | ``` 21 | 22 | ## Why this team is needed 23 | 24 | All pyOpenSci reviews happen on GitHub in the [software-submission repository](https://github.com/pyOpenSci/software-submission). The metadata associated with each review is what is used to populate the [packaging listing on our website](https://www.pyopensci.org/python-packages.html). 25 | 26 | This team is important because: 27 | 28 | 1. Often when reviews wrap up, editors and maintainers are excited about the acceptance and forget to update the final metadata information. 29 | 2. Sometimes, we recognize the need for new metadata. And as such, we need to update older issues. This is rare but happens occasionally. See notes below on this type of effort as it may require help from the entire editorial team (or we can consider how to automate it). 30 | 31 | The metadata for each review looks something like the example below. However, because pyOpenSci has been operating peer review since 2019, some of the older issues may be missing some critical metadata. 32 | 33 | ## About the metadata 34 | 35 | The core metadata that should be available in every review includes: 36 | 37 | - Submitting Author 38 | - All current maintainers 39 | - Package Name 40 | - One-Line Description of Package 41 | - Repository Link 42 | - Version submitted 43 | - Editor 44 | - Reviewer 1 45 | - Reviewer 2 46 | - Reviewer 3 47 | - Sometimes there may be a third reviewer particularly in a mentorship situation or when specific domain expertise is required. We can add that to issues where it's needed but do NOT need it in every review. 48 | - Archive: 49 | - This is a link to either a github tag archive or a zenodo badge 50 | - JOSS DOI 51 | - This should be the JOSS badge associated with the JOSS pub 52 | - Version accepted 53 | - Date accepted (month/day/year) 54 | 55 | ### Example metadata in a review 56 | 57 | This is an example of a review submission. Notice that information that has not yet been filled out has a TBD next to it. Also notice that the author has added a few items that are not in our core template such as `Documentation`. Extra items are ok. We can ignore extra items. 58 | 59 | ```markdown 60 | Submitting Author: Name (@AlexanderJuestel) 61 | All current maintainers: (@AlexanderJuestel) 62 | Package Name: GemGIS 63 | One-Line Description of Package: Spatial Data Processing for Geomodeling 64 | Repository Link: https://github.com/cgre-aachen/gemgis 65 | Version submitted: 1.0.11 (soon 1.1 with bug fixes for some methods and the API Reference once it is working, no major functionality changes) 66 | Documentation: https://gemgis.readthedocs.io/en/latest/ 67 | JOSS Publication: https://joss.theoj.org/papers/10.21105/joss.03709 # We want to add the JOSS publication as well - but let's figure out a standardized way to do it. I think the JOSS badge would be great to display on our website. 68 | Editor: TBD 69 | Reviewer 1: TBD 70 | Reviewer 2: TBD # Sometimes there may be a third reviewer, particularly in a mentorship situation or when specific domain expertise is required 71 | Archive: TBD 72 | Version accepted: TBD 73 | Date accepted (month/day/year): TBD 74 | ``` 75 | 76 | At the end of a review, the completed metadata should look something like the example below, with all metadata items containing text. 77 | 78 | Notice in the example below, this particular review is missing the archive information and instead has `TBD`. This item should contain either a Zenodo link to a tagged release or a link to a tagged release on GitHub. It is also missing the version accepted. Since this review was accepted, we will update the metadata in the issue. 79 | 80 | ```markdown 81 | Submitting Author: Sam Pottinger (@sampottinger) 82 | All current maintainers: @sampottinger, @gizarp 83 | Package Name: afscgap 84 | One-Line Description of Package: Community contributed Python-based tools for working with public bottom trawl surveys data from the NOAA Alaska Fisheries Science Center Groundfish Assessment Program ([NOAA AFSC GAP](https://www.fisheries.noaa.gov/contact/groundfish-assessment-program)). 85 | Repository Link: https://github.com/SchmidtDSE/afscgap 86 | Version submitted: 0.0.7 87 | Editor: [Filipe Fernandes](https://github.com/ocefpaf) 88 | Reviewer 1: [Tylar Murray](https://github.com/7yl4r) 89 | Reviewer 2: [Ayush Anand](https://github.com/ayushanand18) 90 | Archive: TBD # TODO: Please add a link to the archive 91 | Version accepted: TBD # TODO: add the version that was accepted eg 1.4 92 | Date accepted (month/day/year): TBD # TODO: add the date 93 | ``` 94 | 95 | The issue should also have at least 1 or 2 final labels: 96 | 97 | - 6/pyOS-approved 🚀🚀🚀 98 | - 9/joss-approved 99 | 100 | If it is missing those labels please add them as it makes sense for the state of the review. If there are other, older labels you can remove those. 101 | 102 | ## Responsibilities of the triage team 103 | 104 | The review issue triage team's role is to do the following: 105 | 106 | - Ensure that after each review is closed, all metadata are filled out 107 | - Ensure that labels are updated accordingly. These labels are what we use to parse reviews that end up posted on our website. If they aren't labeled correctly, they will not get automagically added. 108 | - Ensure that the [post-review survey filled out](https://docs.google.com/spreadsheets/d/1jEk-DDpkz14Z07OX_o1cN2vHzVbJO6mQ83ihGXsWkLc/edit#gid=0) (for issues opened after March 2023). Note this page is only accessible to our editorial team and only contains names / gh user names of people who filled out the survey rather than any survey data. 109 | - Help the software review lead update older issues when metadata items are missing. 110 | - Post on the pyOpenSci Slack #pyos-updates channel announcing & celebrating that a successful review has been completed! 111 | - Make sure JOSS tracking is happening as expected 112 | 113 | The team might also do the following in some cases: 114 | 115 | - Close the issue if it is open, but complete 116 | 117 | ## Celebrating accepted packages 118 | 119 | We like to celebrate when a package is 120 | 121 | 1. accepted by pyOpenSci and 122 | 2. accepted by JOSS 123 | 124 | The editorial triage team will post on the pyOpenSci Slack `#pyos-updates` channel when we have a new accepted package. 125 | 126 | ## Updating reviews & contributors using GitHub actions 127 | 128 | The issue review team can also, as they wish, update packages and reviewers on the website by enabling the update_reviews and update_contributors workflow. Alternatively, you can merge an open PR, which will run the action every few days and submit a new pull request. 129 | 130 | To do this: 131 | 132 | 1. [Head to the pyOpenSci website repo](https://github.com/pyOpenSci/pyopensci.github.io/actions/workflows/update-contribs-reviews.yml). 133 | 2. Click the run workflow button to trigger a build that will update reviews and also editors, reviewers and associated contributions! 134 | 135 | :::{figure-md} contribs-action 136 | 137 | Image on a black background of the GitHub interface. on the right you can see a list of action names - 5 total. the one action Update Contribs & reviewers has a blue line next to it indicating it is the action being viewed on the screen. On the right of the image you see a run workflow button which is what needs to be pressed to manually make that action run 138 | 139 | When you go to the actions tab in github, you will see the Update Contribs and reviewers action. You can run that using the "run workflow" button. Once the workflow is run, a pr will be submitted with both an updated contributor list and an updated review list (if there have been new packages accepted and new contributors). 140 | ::: 141 | 142 | Once you trigger this, the action will run and submit a pull request. 143 | 144 | :::{figure-md} run-contrib-action 145 | 146 | Image showing a pull request with the title Update contributor and review data. The first comment is from the github-actions bot and says automated changes by create-pull-request GitHub action. 147 | 148 | This shows what a pr by the github actions bot looks like after the update contributor and review action has been run. 149 | ::: 150 | 151 | You may notice that the pull request has a pre-commit failure. You can fix that by adding a comment to the bottom of the issue that says: 152 | 153 | `pre-commit.ci autofix` 154 | 155 | :::{figure-md} pre-commit-autofix 156 | 157 | Image showing the github action results on a pull request. the pre-commit.ci - pr check has a failing x next to it. 158 | 159 | When you have a failed pr run you can just add a comment with the text pre-commit.ci autofix and the bot will lint and fix the pr. 160 | ::: 161 | 162 | Once checks have passed, you can merge this pr into the website repo to update reviews and contributions! 163 | 164 | Finally, delete the branch associated with the PR. 165 | 166 | ## How to know when the package was accepted 167 | 168 | In our peer review guide, we have a [template that editors should use](https://www.pyopensci.org/software-peer-review/how-to/editors-guide.html) to accept a package into our ecosystem. In an issue, you can look for this comment and use the date that the comment was posted as the date the package was accepted. 169 | 170 | There are cases when editors forget to use this template. But ideally, you can figure this out by searching for "accepted" in the review. OR you can simply just ask the editor in the `private-editorial` channel on our Slack. 171 | 172 | :::{figure-md} accepted-package 173 | 174 | Image on a black background of the GitHub interface. Generally what this shows is the template message that is provided by pyOpenSci when a package is accepted. It starts with hey there, username and then congratulates them for being accepted. Finally it provides a list of last steps needed to close out the review. 175 | 176 | Image showing the generic template text used for accepting a package into the pyOpenSci ecosystem. 177 | ::: 178 | 179 | ```markdown 180 | 🎉 bibat has been approved by pyOpenSci! Thank you @teddygroves for submitting bibat and many thanks to @OriolAbril 181 | and @alizma for reviewing this package! 😸 182 | ``` 183 | 184 | ## How to confirm that the post-survey was filled out 185 | 186 | At the end of each review, we ask reviewers and maintainers to fill out the post survey. You can check whether this has been completed by [looking at this document](https://docs.google.com/spreadsheets/d/1jEk-DDpkz14Z07OX_o1cN2vHzVbJO6mQ83ihGXsWkLc/edit?usp=sharing). NOTE: only editors have access to view this document. It simply contains a list of GitHub usernames that have completed the survey and the associated date. It will allow you to confirm that the step was completed! 187 | 188 | ## Adjusting labels & the project board on an issue 189 | 190 | Every issue has a label associated with it that tells us what 191 | part of the process the review is in. Our automated workflow 192 | finds packages that were accepted using the `6/pyOS-approved` 193 | tag (see below). 194 | 195 | :::{figure-md} accepted-review-label 196 | 197 | Image that shows an accepted review. The editor is the assignee. The labels on the review say 6/pyos-approved with three rocket emojis next to it. Below is 7/under-joss review, which is a green label. 198 | 199 | If a package has been accepted, it should have at least the pyos-approved label. If the package moves on to JOSS and is accepted, it should have the JOSS label as well. If the package is actively under review by JOSS, it should be marked as such. Otherwise, if it has been accepted, it should have the `9/joss-accepted` label. 200 | ::: 201 | 202 | Oftentimes it's easy for an editor to celebrate a review ending and forget to add that final tag. Or sometimes they might forget that they need to follow the package as it goes through the JOSS process (if it goes on to that process). 203 | 204 | The triage team should ensure that all accepted packages have the `6/pyOS-approved` label associated with them. You can remove any other labels on the issue once a package is approved. We can assume it's gone through all of the appropriate checks! 205 | 206 | In the case of a JOSS submission after our review, you can make sure that the editor is updating the label on the issue associated with JOSS. The review, once complete and accepted by both pyOpenSci and JOSS, should have two labels: 207 | 208 | * `6/pyos-approved` 209 | * `9/JOSS-approved`. 210 | 211 | :::{figure-md} joss-labels 212 | 213 | Image that shows the three options for JOSS labels. 7/under-joss-review, 8-joss-review-complete and 9/joss-approved. 214 | 215 | The JOSS labels indicate the state that a package is in. 216 | Once JOSS has accepted the package, ensure the final label has both `6/pyos-accepted` and `9/joss-approved`. At this point, the package review issue can be closed if all loose ends are complete! 217 | ::: 218 | 219 | ### Assign the issue to the editor leading the review 220 | 221 | Make sure that the issue is assigned to the editor leading the review. This step is often missed in our review process. 222 | 223 | :::{figure-md} start-review 224 | 225 | Image that shows the empty assignees section for a new review. Also, there are two labels 1/editor checks and new submission. 226 | 227 | When a review is just starting, the assignee should be the editor leading the review. The labels will begin with `editor-checks`. 228 | ::: 229 | 230 | ## Organization permissions needed for the editorial triage team 231 | 232 | The triage team will need the following permissions within the [pyOpenSci 233 | GitHub organization](https://github.com/pyOpenSci) to complete their responsibilities. 234 | 235 | Team members will need: 236 | 237 | - to be a part of the pyOpenSci GitHub organization 238 | - merge permissions on [pyopensci.github.io repository.](https://github.com/pyOpenSci/pyopensci.github.io) 239 | - edit permissions for reviews in the software-submission repository 240 | - access to post in the Slack `pyos-updates` channel 241 | -------------------------------------------------------------------------------- /our-process/policies.md: -------------------------------------------------------------------------------- 1 | # Peer Review Guidelines & Policies 2 | 3 | ## Review process guidelines 4 | 5 | pyOpenSci packages are reviewed for quality, fit, scope, documentation, and 6 | usability. The review process is similar to a manuscript review; however, it 7 | has a stronger focus on Python packaging best practices. 8 | 9 | Unlike a manuscript review, our peer review process is an ongoing conversation. 10 | Once all major issues and questions are addressed, the review editor will decide 11 | to accept, hold, or reject the package. 12 | 13 | Rejections are usually done early in the process, before the review process 14 | begins. In rare cases, a package may also not be onboarded into the pyOpenSci 15 | ecosystem after review & revision. 16 | 17 | It is ultimately the editor’s decision on whether or not to reject the package 18 | based on how the reviews are addressed. 19 | 20 | ## Review communication approach 21 | 22 | Communication between authors, reviewers, and editors takes 23 | place on GitHub. However, you may contact the editor by email if 24 | needed. 25 | 26 | When submitting a package, please make sure that your GitHub notification 27 | settings are turned on for the software-submission repository to notify you 28 | when you receive feedback on a review issue. 29 | 30 | (submission-volume)= 31 | 32 | ## Submission volume and maintainer overlap 33 | 34 | To protect our volunteer peer review team and ensure quality reviews for all 35 | packages, we have policies regarding the volume of simultaneous submissions. 36 | 37 | ### Unique point of contact requirement 38 | 39 | Each submission to pyOpenSci should have one point of contact per package. 40 | Each person listed as a point of contact may have only one submission under 41 | review at a time. 42 | 43 | This policy ensures that: 44 | 45 | - Review feedback receives appropriate attention from maintainers. 46 | - Maintainers don't become overwhelmed managing multiple concurrent reviews. 47 | - Our volunteer reviewers and editors can focus their efforts effectively. 48 | 49 | ### Multiple submissions with overlapping maintainer teams 50 | 51 | If multiple packages are submitted simultaneously with overlapping maintainer 52 | teams, we will evaluate our volunteer reviewer capacity and may request 53 | staggered submissions to ensure quality review for all packages and to protect 54 | the time and availability of our volunteer editorial team. 55 | 56 | We recognize that some situations may warrant exceptions to these guidelines. 57 | For example, two closely related packages that would benefit from review by 58 | the same editorial team may be handled together. All policies may have 59 | exceptions under the discretion of the editors, and decisions will be made by 60 | the Editor-in-Chief based on reviewer capacity and the specific circumstances 61 | of the submission. 62 | 63 | ## Submitting your package for review in other venues 64 | 65 | We recommend submitting your package for review with pyOpenSci before 66 | submitting a software paper describing the package to a journal. 67 | 68 | Review feedback may result in significant improvements and updates to your package, 69 | including changes that could break package functionality. 70 | 71 | Applying reviewer or editor recommendations to your package can improve your 72 | users' experience with future versions of your package, even if your package is 73 | already published on `PyPI` or `conda-forge`. 74 | 75 | > Please do not submit your package for review while it or an associated 76 | > manuscript is also under review at another venue, as this may result in 77 | > conflicting requests for changes from two sets of reviewers. 78 | 79 | ### Publication with Journal of Open Source Software (JOSS) 80 | 81 | If you have previously published your software package with the Journal of Open 82 | Source Software (JOSS), you can still submit it to pyOpenSci for review. This 83 | provides increased visibility for your package as a vetted tool within the scientific 84 | Python ecosystem and access to our long-term maintenance support. 85 | 86 | Since your package has already undergone a JOSS review, we have a specific, 87 | expedited review process to streamline the submission process and save time. 88 | Once accepted, your package will be treated like any other package in our ecosystem. 89 | 90 | #### Expedited Review Process 91 | 92 | We offer two pathways for packages previously reviewed by JOSS: 93 | 94 | 1. Fast-Track Review (Editor-Only): 95 | Your package is eligible for this fast-track review if it has been published by 96 | JOSS within the last year and has not undergone major changes in dependencies, design, or API 97 | since its JOSS publication. In this case, an editor will conduct the review by going 98 | through our pyOpenSci submission checklist to ensure all our specific requirements are met. 99 | 100 | 2. Expedited Review (Editor + One Reviewer): 101 | If your package's JOSS publication is over a year old, or if it has had major changes as described above 102 | since publication, it will undergo an expedited review with one editor and one external reviewer. 103 | The editor and reviewer will focus on any significant changes and ensure the package meets all current pyOpenSci 104 | standards. This approach reduces the burden of a full review while ensuring the quality of the package 105 | reflects its most recent version. 106 | 107 | :::{note} 108 | **Submitting to JOSS after pyOpenSci review:** 109 | 110 | While pyOpenSci's scope may be more flexible than JOSS in certain areas (such as 111 | package size requirements), packages must still meet JOSS's specific criteria to 112 | be eligible for JOSS fast-track submission. If your package is accepted by pyOpenSci 113 | but does not meet JOSS requirements (e.g., minimum lines of code), it will not be 114 | eligible for JOSS fast-track review. See our [package scope guidelines](package-size-effort) 115 | for more details. 116 | ::: 117 | 118 | (coi)= 119 | ## Conflict of interest for reviews and editors 120 | 121 | Following criteria are meant to be a guide for what constitutes a conflict of 122 | interest (COI) for an editor or reviewer. The potential editor or reviewer has 123 | a conflict of interest if: 124 | 125 | - The authors with a major role are from the potential reviewer/editor’s 126 | institution or institutional component (e.g., department). 127 | - Within the past three years, the potential reviewer/editor has been a 128 | collaborator or has had any other professional relationship with any person 129 | on the package who has a major role. 130 | - The potential reviewer/editor serves as a member of the advisory board for 131 | the project under review. 132 | - The potential reviewer/editor would receive a direct or indirect financial 133 | benefit if the package is accepted. 134 | - The potential reviewer/editor has significantly contributed to a competitor 135 | project. 136 | - There is also a lifetime COI for family members, business partners, 137 | thesis students/advisors, or mentors. 138 | 139 | In the case where none of the associate editors can serve as editor, an 140 | external guest editor will be recruited to lead the package review. 141 | 142 | (generative-ai-policy)= 143 | 144 | ## Policy for use of generative AI / LLMs 145 | 146 | :::{admonition} How this policy was developed 147 | :class: important 148 | 149 | The policy below was co-developed by the pyOpenSci community. Its goals are: 150 | 151 | - Acknowledgment of and transparency around the widespread use of Generative AI tools, with a focus on Large Language Models (LLMs) in Open Source development. 152 | - Ensure an equitable balance of effort in the peer review process: Authors acknowledge that a human has carefully reviewed parts of the package that are AI-generated. Generated material should be in a state that minimizes review time. Our reviewers are not responsible for correcting errors in machine-generated content. 153 | - Disclosure allows reviewers and editors to make informed decisions around the types of packages that they wish to review code for. 154 | - Raise awareness of challenges that Generative AI tools present to the scientific (and broader) open source community. 155 | 156 | [Please see this GitHub issue for a discussion of the topic.](https://github.com/pyOpenSci/software-peer-review/issues/331) 157 | ::: 158 | 159 | ### Disclosure of generative AI use in pyOpenSci reviewed packages 160 | 161 | - When you submit a package to pyOpenSci, please disclose any use of LLMs (Large Language Models) in your package's development by checking the appropriate box and describing your use of generative AI in its development and/or maintenance on our software submission form. Disclosure should include what parts of your package were developed using Generative AI tools. 162 | - Please also disclose this use of Generative AI tools in your package's `README.md` file and in any modules where generative AI contributions have been implemented. 163 | - We require that all aspects of your package have been reviewed carefully by a human on your maintainer team. Please ensure all text and code have been carefully checked for bugs and issues before submitting to pyOpenSci. 164 | - Your acknowledgment of using Generative AI will not prejudice the success of your submission. However, a reviewer can and will ask you to revisit your package's content if it appears that sections have been copied and pasted from other sources without human review. 165 | - If the review team (comprised of the editor and reviewers) determines that the code and text in the package are too challenging to review, they can decide to pause and/or discontinue the review following this policy’s guidelines. 166 | 167 | Below is the checklist that you will need to respond to in our submission form: 168 | 169 | ```{include} ../appendices/gen-ai-checklist.md 170 | 171 | ``` 172 | 173 | ## Review timelines and on-hold reviews 174 | 175 | At any time, an author can choose to have their submission put on hold 176 | (the editor applies the `on-hold` label to the GitHub issue). The `on-hold` 177 | status will be revisited every 3 months. If after one year there has been 178 | no movement on the review, the issue will be closed. 179 | 180 | (post-review-process)= 181 | 182 | ## After acceptance: package ownership and maintenance 183 | 184 | Package authors are expected to maintain and develop their software and 185 | retain 186 | ownership of it after acceptance into pyOpenSci, according to the peer review 187 | agreement acknowledged upon submission. This maintenance commitment should 188 | last for at least two years. The pyOpenSci team will not interfere with 189 | day-to-day tool maintenance unless someone in the community is explicitly added as 190 | a project collaborator. 191 | 192 | If you need to step down from maintaining your accepted pyOpenSci package, 193 | please promptly notify the pyOpenSci Editor-in-Chief or Software Review Lead. 194 | pyOpenSci will collaborate with you to either: 195 | 196 | - Find a new maintainer or 197 | - Archive the tool, depending on what best suits your specific scientific 198 | Python package. 199 | 200 | We will reach out to our package maintainers each year to verify the 201 | package is actively maintained and to see if there are any updates we can 202 | highlight through our social channels. 203 | 204 | ### Maintenance tracking 205 | 206 | pyOpenSci is building a system to track package metrics and activity, 207 | including issues, pull requests, and dates of the last release and last commit 208 | to the package repository. Activity is defined as a repository commit, pull 209 | request, or release. 210 | 211 | We will flag packages that haven't been updated within a 1-year/12-month time 212 | period based on activity. Packages with no activity after 12 months will be 213 | flagged. At that time, a pyOpenSci editorial team member will contact the package 214 | maintainers to evaluate the maintenance status of their package. 215 | 216 | (archive-process)= 217 | 218 | ### Package maintenance and maintainer responsiveness 219 | 220 | If, after one year, package maintainers are unresponsive to requests for 221 | package fixes or messages from the pyOpenSci team, we will initiate 222 | discussions about the package's ongoing inclusion within the pyOpenSci 223 | ecosystem. 224 | 225 | In cases where the community heavily uses a package, we may 226 | collaborate with the community to identify reasonable next steps, such as 227 | assisting in finding a new maintainer. If a solution for the ongoing package 228 | maintenance of your package is not found, the package will be archived within 229 | the pyOpenSci ecosystem. [See section on archiving below.](package-archive) 230 | 231 | If a sub-community decides to fork and maintain the package, we are open to 232 | working with the new maintainers to register the newly forked package within 233 | our ecosystem. The original package will be archived with a link to the new 234 | fork. 235 | 236 | We will also add a note to any blogs written that highlight your tool, that 237 | the package is no longer maintained. 238 | 239 | ### Quality commitment 240 | 241 | pyOpenSci strives to develop and promote high-quality research software. To 242 | ensure that your software meets our criteria, we review all of our submissions 243 | as part of the Software Peer Review process. We expect that you will continue 244 | to maintain a package that has been accepted continually. 245 | 246 | Despite our best efforts to support contributed software, errors are the 247 | responsibility of individual maintainers. Buggy, unmaintained software may 248 | be removed from our suite at any time. We also ask maintainers that they get 249 | in touch with us if they do need to step down from maintaining a tool. 250 | 251 | ### Requesting Package Removal from the pyOpenSci Ecosystem 252 | 253 | In the unlikely scenario that a contributor of a package requests removal of 254 | their package from our ecosystem, we retain the right to offer the last/most 255 | recently released version of that package in our ecosystem for archival 256 | purposes only. 257 | 258 | (package-archive)= 259 | 260 | ### Archiving a package 261 | 262 | If a package appears to be no longer maintained, we will mark it as 263 | archived, which moves the package from our 264 | [main package listing](https://www.pyopensci.org/python-packages.html#all-packages) 265 | to our [archived packaging](https://www.pyopensci.org/python-packages.html#archived-packages) 266 | listing section. 267 | 268 | To archive a pyOpenSci-approved package, add the 269 | [archive label](https://github.com/pyOpenSci/software-submission/issues?q=label%3Aarchived) 270 | to the original review issue. Once this label is applied to the issue, the 271 | website will automatically update to reflect this status. If at any point 272 | in the future, an archived package undergoes active maintenance again, this 273 | label can be removed from the issue to move the package back to an active 274 | status. 275 | 276 | We opt to archive inactive packages rather than remove them to preserve the 277 | history and contributions of the software, ensuring that others can still 278 | access and learn from it. This approach maintains the integrity of the 279 | scientific record and allows for potential future reactivation or forking 280 | of the project. By archiving rather than removing, we provide a clear 281 | status of the package while keeping its legacy intact for reference and 282 | educational purposes. 283 | -------------------------------------------------------------------------------- /how-to/onboarding-guide.md: -------------------------------------------------------------------------------- 1 | # Onboarding New Editors 2 | 3 | The pyOpenSci open peer review process is driven and led by volunteer editors 4 | and reviewers. Finding new volunteers to take on editorial and reviewer roles 5 | can sometimes be the trickiest part of the review process. However, we have 6 | resources available to help you in that effort! 7 | 8 | Below, we discuss processes for finding and onboarding new volunteers to our 9 | peer review process. 10 | 11 | ## About the Editorial Board 12 | 13 | The success of our peer review process is dependent upon a well-balanced 14 | editorial board. Our board needs to have combined expertise in: 15 | 16 | * A suite of specific science domains that fall within the scope of our peer 17 | review process 18 | * Technical expertise in Python packaging 19 | * Awareness of the importance of documentation and package usability 20 | * Awareness of the importance of CI/test suites to ensure robust software 21 | development 22 | 23 | We also strive to ensure our editorial team is diverse and comprised of people 24 | from different backgrounds, cultures, genders, and domains. 25 | 26 | ### Types of editors 27 | 28 | #### New editors start as "Guests" 29 | 30 | A new editor will be considered a guest editor for the first 3 months of their 31 | tenure and/or until they have completed their first review. Once a Guest Editor has 32 | completed a review, they are considered a full editor as deemed appropriate 33 | by the Software Review Lead and the current editorial board. 34 | 35 | #### _ad hoc_ guest editors 36 | 37 | An ad hoc editor has specific skill sets that are required to lead 38 | a single review. Examples of when pyOpenSci needs an _ad hoc_ editor 39 | include: 40 | 41 | * If there is a conflict of interest between a package submitter and the 42 | editorial team (for example, a close colleague of everyone on the team) 43 | * If the editorial board is at capacity, handling the current review load 44 | * If a very specialized skill set is needed (in a one-off type of situation) 45 | 46 | In this case, you may consider using our internal reviewer sign-up list to see 47 | if someone who signed up to be a reviewer wants to serve as an editor. 48 | 49 | ### Experience required to be an editor 50 | 51 | We prefer that editors have some experience with reviewing software. This 52 | experience could come from a previous review they worked on with pyOpenSci, 53 | rOpenSci, or JOSS. 54 | 55 | ### Editorial mentorship 56 | 57 | If a potential volunteer does not have prior software editorial experience, we 58 | offer a **mentorship process**. Editor mentorship is where someone with 59 | existing editorial experience mentors the new editor through their first 60 | review(s). 61 | 62 | ### Recruiting new editors 63 | 64 | Recruiting new editors and maintaining a sufficient and well-balanced 65 | editorial board is the responsibility of the 66 | [Software Review Lead](https://www.pyopensci.org/handbook/governance/structure.html#software-review-lead) 67 | with support and advice from the editorial board. 68 | 69 | :::{note} 70 | For the time being, the Software Review Lead role is being filled by the 71 | Executive Director with support from the Editor in Chief as we define our 72 | process and track the volume of submissions that we need to support. In the 73 | future, we will find someone with interest in leading peer review for 74 | pyOpenSci. 75 | ::: 76 | 77 | ## Where to find new editors 78 | 79 | Typically the Editor in Chief will work with the Software Review Lead to find and 80 | onboard new editors in scientific topical areas where pyOpenSci has existing 81 | gaps. 82 | 83 | You might find good candidates to be an editor through: 84 | 85 | * Your professional network: you may know people in a specific domain that 86 | might be a good fit to be an editor for pyOpenSci. 87 | * Our [pyOpenSci list of contributor pool](https://www.pyopensci.org/our-community/index.html#pyopensci-community-contributors) which includes: 88 | * Package authors and maintainers who have already submitted a package for 89 | review to pyOpenSci 90 | * Reviewers who have already led reviews for pyOpenSci 91 | * Past guest editors 92 | * Colleagues that you know who have reviewed for the Journal of Open Source 93 | Software (JOSS) or rOpenSci who have Python expertise 94 | * Community members in the pyOpenSci Slack (please post a call in our 95 | `#software-review` channel) 96 | 97 | When all of the above fails to return a good new editor candidate, you can find 98 | support from our pyOpenSci Community Manager who will post an open call on our 99 | [social media channels](https://www.pyopensci.org/handbook/community/social.html) 100 | with a link to our editorial board sign-up form. Using our online network will 101 | allow you to cast an even wider net to find new interested editors. 102 | 103 | :::{todo} 104 | Ideally, we want to have an online interface for the editors / EiC to own the 105 | process. When we have a link that will allow the EiC / Software Review Lead to 106 | search through something online, we should add it -- 107 | 108 | pyOpenSci maintains a database of contributors, and the Community Manager can 109 | assist you in identifying individuals who may be a good fit. Please reach out 110 | to them either in a private Slack message or via email, at 111 | [media@pyopensci.org](mailto:media@pyopensci.org). 112 | ::: 113 | 114 | 115 | ## Starting the editorial search 116 | 117 | To begin, first post in our `private-editorial-team` slack channel to see if any of our existing [Editorial Team](https://www.pyopensci.org/about-peer-review/index.html#meet-our-editorial-board) members can identify past reviewers or other people they know that might be a good editorial candidate. 118 | 119 | If there is a discussion around specific candidates, be sure to: 120 | 121 | * Start a private group message for discussion about particular candidates. This ensures there is not a visible history in a public channel that a new editor may see in the future (this could be awkward for someone to see!) 122 | * Ping editors using @here to be sure they get a notification, as this is an important topic. 123 | 124 | 125 | **IMPORTANT:** Provide up to a week of time for editors to chime in before onboarding a new editor. 126 | 127 | ### Leverage pyOpenSci social channels to find editors 128 | 129 | If you have tried all of the above and still aren't able to find a new 130 | candidate, then the pyOpenSci Community Manager can assist you by: 131 | 132 | * Posting on our social media channels about the position. 133 | * Writing a [call for editors blog post](https://www.pyopensci.org/blog/pyos-call-for-editors-may-2024.html) about our current editorial needs. 134 | 135 | :::{note} 136 | [See an example here of a post that seeks to recruit editors](https://fosstodon.org/@pyOpenSci/112497485980274296), a blog post, and call-outs in both our monthly and weekly newsletters. 137 | ::: 138 | 139 | To get support from the Community Manager in recruiting editors (or reviewers) follow the process below: 140 | 141 | * Post in our public `#software-review` slack channel pinging the community manager (`@username`). In your post, include the following details: 142 | 143 | * That you’re looking for editors. 144 | * Any specific domains or technical skills you need an editor to have, or if it’s a general call for editors. 145 | * Any specific packages that need an editor (include links to a package submission that they would lead if possible). 146 | 147 | :::{tip} 148 | It's helpful to post in our `#software-review` channel rather than 149 | an individual Direct Message (DM) because: 150 | 151 | * It allows other editors to see the type of expertise that you are requesting and that we offer this support from our Community Manager. 152 | * It allows other community members who may know of potential editors to see the request and potentially respond. 153 | ::: 154 | 155 | Our Community Manager engages with the broader community and partner communities, frequently interacting with individuals interested in joining our pyOpenSci review team. The Community Manager may, from time to time, meet community members who might make great editors or reviewers. In those cases, they will share that information with the current Editor in Chief and Software Review Lead. 156 | 157 | :::{todo} 158 | pyOpenSci anticipates being able to send targeted emails to community members that meet certain criteria related to domain expertise by the Fall of 2024. Please reach out to the pyOpenSci Community Manager with any questions about this process! 159 | ::: 160 | 161 | :::{note} 162 | 163 | It is important that a new reviewer or a new editor fill out the appropriate form prior to onboarding. 164 | 165 | * [reviewer signup form](https://docs.google.com/forms/d/e/1FAIpQLSeVf-L_1-jYeO84OvEE8UemEoCmIiD5ddP_aO8S90vb7srADQ/viewform) 166 | * [editor signup form](https://docs.google.com/forms/d/17NW0P_h8gpmzf7Fr0cAd8aEbIUWPljPfg4d7Rjs1UIE/edit) 167 | 168 | ::: 169 | 170 | 171 | ## On-boarding a new editor 172 | 173 | The Editor in Chief, working closely with the Software Review Lead, is responsible for inviting and onboarding a new editor to our peer review process. 174 | 175 | When the EIC has identified an editor who is not currently part of the pyOpenSci community, they should: 176 | 177 | * Extend a Slack invitation to the individual (or ask our Community Manager to do so) 178 | * Welcome the individual in Slack, and provide them with access to the `#private-editorial-team` and any other channels as needed. 179 | 180 | :::{note} 181 | The Community Manager will ensure that any new member who joins our Slack workspace is welcomed and set up with anything they need in our pyOpenSci Slack workspace. 182 | ::: 183 | 184 | 185 | ## Process for inviting a new editor 186 | 187 | * Editorial board candidates most often start as guest editors. 188 | * After 3 months or their first review (whichever comes first), the Software Review Lead working with the EiC will assess how the 189 | review process went. Allow other editors to provide input as well. 190 | * Once it is determined that the guest editor is committed to supporting the pyOpenSci 191 | review process, you can email them to participate on the editorial board 192 | using the template below. 193 | 194 | ``` 195 | Hi [NAME HERE]: 196 | 197 | We would like to formally invite you to join the pyOpenSci editorial board as a full 198 | member. [*SPECIFIC REASONS FOR INVITATION (mention contributions to pyOpenSci)*]. 199 | We think you will make a wonderful addition to our pyOpenSci open review team! 200 | 201 | [Here is an onboarding document to help you navigate your first weeks in this role.](https://docs.google.com/document/d/1UfG1Fe5wSiEAObvqNMT4etZ5sx7QXzW0f8mozKyK1NE/edit?tab=t.0) 202 | 203 | [IF GUEST EDITOR: You are familiar with the editor's role, as you've been a guest editor]. We aim for editors to handle reviews for four packages per year 204 | ([IF GUEST EDITOR including the one that you just finished!]). 205 | We ask that editors make an informal commitment to serve for two years and 206 | re-evaluate their participation after that. 207 | On a short-term basis, any editor can decline to handle a package or say, 208 | "I'm pretty busy, I can't handle a new package for a few weeks." 209 | 210 | In addition to handling packages, editors weigh in on group editorial decisions, 211 | such as whether a package is in scope, and support updates to our policies. 212 | We generally do this through Slack, which we expect editors to be able to check 213 | regularly. We have editorial board calls annually. 214 | 215 | Every 3-6 months, the Editor-in-Chief's responsibilities rotate to a new editor. 216 | You'll have the opportunity to enter this rotation once you have been on the 217 | editorial board for at least 6 months. 218 | 219 | OPTIONAL: Some editors also take on bigger projects to support pyOpenSci and 220 | improve the peer-review process. This is entirely optional, but please let us 221 | know if you are interested in additional activities that support the organization. 222 | 223 | We hope that you'll join our growing editorial board! 224 | 225 | Please give this some thought, ask us any questions you have, and let us know 226 | whether you can join us. 227 | 228 | Best, 229 | [your-name-here], on behalf of the pyOpenSci Editorial Board 230 | ``` 231 | 232 | (onboarding-a-new-editor)= 233 | ## Onboarding a new editor 234 | 235 | To onboard a new editor: 236 | 237 | * Message the pyOpenSci Community Manager and the new editor in Slack, introducing them to one another. The Community Manager will collaborate with the new editor to create a blog post introducing them, which will in turn get posted on the pyOpenSci blog, promoted on social media, and included in an upcoming newsletter. 238 | 239 | * Ask the new editor to turn on [two-factor authentication (2FA) for GitHub](https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa) if they haven't already done so. 240 | 241 | * Give editors permissions they will need on GitHub to manage reviews: 242 | * For ad-hoc guest editors: invite the editor to the `software-submission` repository 243 | with "maintain" permissions. 244 | * For new editors (not ad-hoc): invite editors to the pyOpenSci GitHub organization 245 | as a member of the [`editorial-board`](https://github.com/orgs/pyOpenSci/teams/editorial-board) team. This will give them appropriate permissions and allow them to get team-specific notifications. 246 | 247 | * Add the new editor to the pyOpenSci Slack workspace and specifically the `private-editorial` channel. 248 | 249 | * Post a welcome message for the new editor in the editor channel, pinging all editors. 250 | * Update the [website contributors.yml](https://github.com/pyOpenSci/pyopensci.github.io/blob/main/_data/contributors.yml) file with the name of the new editor. 251 | 252 | :::{note} 253 | We have a bi-weekly cron job that parses through existing issues and grabs the names of editors, reviewers and authors. However, if you want the editors name to be listed on the website prior to a review beginning and/or sooner than the cron job might pick up their name, then we suggest that you add their name, and GitHub username and title to the contributors.yml file through a pull request. 254 | 255 | You do not need to fill out all of the elements of the YAML file - only the name, GitHub user field and the `editorial_board: true` key:value pair. 256 | 257 | ::: 258 | 259 | ```yaml 260 | - name: FirstName LastName 261 | github_username: ghuser 262 | github_image_id: 1234566 263 | title: 264 | - Editor # Title to be listed under their name 265 | # ..... # 266 | editorial_board: true # Be sure editorial_board is set to true 267 | emeritus_editor: false # Emeritus is initially set to false 268 | # ..... # 269 | contributor_type: 270 | - editor # This field will be automatically updated after their first review 271 | - guidebook-contrib 272 | - reviewer 273 | ``` 274 | 275 | ## Off-boarding an editor 276 | 277 | When it is time for an editor to step down, do the following: 278 | 279 | * Thank them for their work! 280 | * Announce that they are stepping down, and than them in the private editors-only Slack channel. Then, remove them from the editors-only Slack channel. 281 | * Remove them from the [Editorial-Board GitHub team](https://github.com/orgs/pyOpenSci/teams/editorial-board). 282 | * Move them to `emeritus-editor` on the [pyOpenSci website](https://github.com/pyOpenSci/pyopensci.github.io/blob/main/_data/contributors.yml) by editing the yaml file as follows: 283 | 284 | ```yaml 285 | - name: FirstName LastName 286 | github_username: ghuser 287 | github_image_id: 1234566 288 | # ..... more here ... # 289 | editorial_board: false # Be sure editorial_board is set to FALSE 290 | emeritus_editor: true # Emeritus is now true if they've served as an editor 291 | # .. # 292 | ``` 293 | -------------------------------------------------------------------------------- /how-to/author-guide.md: -------------------------------------------------------------------------------- 1 | # Guide for Python Package Authors & Maintainers 2 | 3 | :::{toctree} 4 | :hidden: 5 | :caption: How To Guides 6 | 7 | Author Guide 8 | Reviewer Guide 9 | Editor Guide 10 | Editor-in-Chief Guide 11 | Triage Team Guide 12 | Peer Review Lead 13 | ::: 14 | 15 | ```{toctree} 16 | :hidden: 17 | :caption: Onboarding Editors & Reviewers 18 | 19 | Finding & Onboarding Editors 20 | Finding & Onboarding Reviewers 21 | ``` 22 | 23 | Are you considering submitting a package for review with pyOpenSci? You've 24 | come to the right place! Below you will find the steps that you need to follow 25 | to submit a package to pyOpenSci for peer review. 26 | 27 | ## Peer review resources 28 | 29 | :::::{grid} 1 2 3 3 30 | :class-container: text-center 31 | :gutter: 3 32 | 33 | ::::{grid-item} 34 | :::{card} Package scope 35 | :link: ../about/package-scope 36 | :link-type: doc 37 | :class-card: left-aligned 38 | 39 | Learn about the requirements and scope of packages that pyOpenSci reviews. 40 | ::: 41 | :::: 42 | 43 | ::::{grid-item} 44 | :::{card} How review works 45 | :link: ../our-process/how-review-works 46 | :link-type: doc 47 | :class-card: left-aligned 48 | 49 | We review packages openly using GitHub Issues. 50 | ::: 51 | :::: 52 | 53 | ::::{grid-item} 54 | :::{card} Review timeline 55 | :link: ../our-process/review-timeline 56 | :link-type: doc 57 | :class-card: left-aligned 58 | 59 | Curious about the general timeline for pyOpenSci reviews? 60 | ::: 61 | :::: 62 | 63 | ::::{grid-item} 64 | :::{card} Review Guidelines & Policies 65 | :link: ../our-process/policies 66 | :link-type: doc 67 | :class-card: left-aligned 68 | 69 | Read through our peer review policies before submitting a package to us. 70 | ::: 71 | :::: 72 | 73 | ::::{grid-item} 74 | :::{card} Need packaging guidance? 75 | :class-card: left-aligned 76 | 77 | [If you want to learn more about packaging best practices, you can check out our packaging guide.](https://www.pyopensci.org/python-package-guide) 78 | ::: 79 | :::: 80 | 81 | ::::: 82 | 83 | Before you begin this process, [please be sure to read the review process guidelines](../our-process/policies). 84 | 85 | ```{note} 86 | **Before you consider submitting to us, please consider the following:** 87 | 88 | 1. Please be sure that you have time to devote to making changes to your 89 | package. During review, you will receive feedback from an editor and two reviewers. Changes could 90 | take time. Please consider this before submitting. You can read more about the timeline for making changes on our [peer review policies page](../our-process/policies). 91 | 2. A diverse group of volunteer editors and reviewers leads peer review. 92 | Please be considerate when engaging with everyone online. 93 | 3. All participants in our peer review process need to follow the [pyOpenSci Code of Conduct](https://www.pyopensci.org/handbook/CODE_OF_CONDUCT.html). Please review it before submitting to us. 94 | ``` 95 | 96 | ## 1. Do you plan to continue to maintain your package? 97 | 98 | One of the goals of pyOpenSci is to maintain a curated list of 99 | community-approved, maintained, and vetted tools that support open science workflows. 100 | 101 | As such, we review packages that will be useful to the community 102 | and maintained over time. While we understand that burnout is real, 103 | and you may move on in the future to other projects, we ask that you commit 104 | to maintaining your package for at least 1-2 years after the review process 105 | is complete. 106 | 107 | If that maintenance commitment is too much, you might consider submitting 108 | your package to a journal that is more focused on publication only. 109 | 110 | ### Who should submit the package for review? 111 | 112 | If you have a team of people maintaining your package, please be sure 113 | that the submitting author is the person who "owns" or leads that maintenance. 114 | That person will become the long-term point of contact 115 | for pyOpenSci. 116 | 117 | - Please also include the names of all maintainers on the project 118 | as we also want to ensure that everyone working on the project receives full credit 119 | for their effort. 120 | 121 | ```{note} 122 | **Important**: To ensure quality reviews for all submissions and protect our 123 | volunteer review team, each active submission must have a unique point of contact. 124 | If you are currently the point of contact for another package under review, please 125 | wait until that review is complete before submitting another package. 126 | 127 | For more details, see our [submission volume policy](submission-volume). 128 | ``` 129 | 130 | ```{note} 131 | If your package is more of a tool to support a specific workflow that 132 | either: 133 | * may not be maintained long term or 134 | * may be so specific that it won't have a user base outside of your lab or work environment 135 | 136 | please consider submitting it directly to a publisher like the 137 | Journal of Open Source Software (JOSS). A publisher like JOSS has less 138 | emphasis on long-term software maintenance and focuses more on 139 | publication quality and citation/credit. 140 | ``` 141 | 142 | ## 2. Does your package meet packaging requirements? 143 | 144 | Before submitting your project for review with pyOpenSci, make sure that 145 | your package meets all of the requirements listed in the editor checks (see below). 146 | We use these checks as a baseline for all submissions and pre-submissions to 147 | pyOpenSci. 148 | 149 | If you have questions about any of the elements listed below, you can 150 | check out our [pyOpenSci Python packaging guide](https://www.pyopensci.org/python-package-guide) which includes an overview discussion of best practices 151 | for Python packaging, including discussions of: 152 | 153 | - Tools that you can use to create your package, 154 | - Tools for creating and publishing documentation, 155 | - Resources for creating files such as the README file, code of conduct, contributing guide, and more. 156 | 157 | ```{include} ../appendices/editor-in-chief-checks.md 158 | 159 | ``` 160 | 161 | :::{important} 162 | Given the increased use of Generative AI tools (LLMs), we have developed a disclosure policy for all packages submitted to pyOpenSci (generative-ai-policy). Please review this before submitting to us. 163 | ::: 164 | 165 | 166 | ```{hint} 167 | **Do you have questions about Python packaging or our peer review process?** 168 | 169 | [Post your question(s) in our Discourse forum under `coding-help`](https://pyopensci.discourse.group/c/coding-help/10). We will do our best to help you with questions 170 | surrounding: 171 | 172 | * Package structure 173 | * Setting up continuous integration 174 | * `PyPI` and `conda` publication 175 | * Getting started with test suites 176 | * Creating and publishing documentation 177 | * Anything related to our peer review process. 178 | 179 | Also, check our [Packaging Guide](https://www.pyopensci.org/python-package-guide). 180 | This guide includes: 181 | 182 | * a [beginner-friendly tutorial](https://www.pyopensci.org/python-package-guide/tutorials/create-python-package.html) for creating pure Python packages 183 | * [An overview of the packaging tool ecosystem 184 | that you can use to create a high-quality 185 | Python package.](https://www.pyopensci.org/python-package-guide/package-structure-code/python-package-build-tools.html) 186 | ``` 187 | 188 | ## 3. Is your package in scope for pyOpenSci? 189 | 190 | Next, check to see if your package falls within the topical and technical scope of pyOpenSci. If you aren't 191 | sure about whether your package fits within pyOpenSci's scope (below), submit 192 | a [presubmission inquiry issue on the software-review](https://github.com/pyOpenSci/software-review/issues/new?assignees=&labels=0%2Fpresubmission&template=presubmission-inquiry.md&title=) 193 | repository. After you submit an inquiry, a pyOpenSci editor will provide feedback regarding the fit of your package for pyOpenSci review. This can take 194 | up to a week. 195 | 196 | Our current categories for determining package scope are below: 197 | 198 | 199 | 200 | ```{button-link} ../about/package-scope.html 201 | :color: primary 202 | :class: sd-rounded-pill 203 | Click here to view our technical and domain scope requirements. 204 | ``` 205 | 206 | ## 4. Submit your package for peer review 207 | 208 | To submit your package for peer review, you can 209 | open an issue in our [pyopensci/software-review repo](https://github.com/pyOpenSci/software-review/issues/new/choose/) 210 | repository and fill out the [Submit Software for Review](https://github.com/pyOpenSci/software-submission/issues/new?template=submit-software-for-review.md) issue template. 211 | 212 | ## 5. Editor-in-Chief reviews package for scope and minimal infrastructure criteria 213 | 214 | Once the issue is opened, our editor-in-chief and an editor from our editorial board will review your submission within 215 | **2 weeks** and respond with next steps. The editor may request that you make updates 216 | to your package to meet minimal criteria before review. They may also reject your 217 | package if it does not fall within our scope. 218 | 219 | ```{button-link} ../how-to/editor-in-chief-guide.html#editor-checklist-template 220 | :color: primary 221 | :class: sd-rounded-pill 222 | Click here to view the editor checks that will be used to evaluate your package. 223 | ``` 224 | 225 | ## 6. The review begins 226 | 227 | If your package meets the minimal criteria for being 228 | reviewed, it may then be given to an editor with appropriate domain experience 229 | to manage the review process. That editor will assign 2-3 reviewers to review your 230 | package. Reviewers will be asked to provide review feedback as comments on your 231 | issue within **3 weeks**. Reviewers can also open issues in your package repository. 232 | We prefer issues that link back to the review as they document changes made to your 233 | package that were triggered by our review process. 234 | 235 | ## 7. Response to reviews 236 | 237 | You should respond to reviewers’ comments within **2 weeks** of the 238 | last-submitted review. You can make updates to your package at any time. We 239 | encourage ongoing conversations between authors and reviewers. See the 240 | [guide for package reviewers](reviewer-guide.md) for more details about reviewers' engagement with package 241 | maintainers during a review. 242 | 243 | ## 8. Acceptance into pyOpenSci 244 | 245 | Once the reviewers are happy with the changes that you've made to the package, the 246 | editor will review everything and accept your package into the pyOpenSci ecosystem. 247 | Congratulations! You are almost done! 248 | 249 | ## My package is approved, now what? 250 | 251 | Congratulations on being accepted into the pyOpenSci community of maintainers! 252 | Once your package is approved, a few things will happen: 253 | 254 | 1. We will ask you to ensure that your package is being tracked/archived using 255 | Zenodo. You will then create a tagged release representing the version of the 256 | package accepted by pyOpenSci. 257 | 1. We will ask you to add the pyOpenSci badge [![pyOpenSci Peer Reviewed](https://pyopensci.org/badges/peer-reviewed.svg)](https://github.com/pyOpenSci/software-review/issues/issue-number) to the 258 | top of your **README.md** file. 259 | 1. We will promote your package on our social media channels! 260 | 1. We will invite you to write a blog on our website spotlighting your package. The blogs our maintainers write are among the most popular content on the website! 261 | 262 | If you'd like to submit your package to JOSS, you can do so now. Remember that JOSS will accept our review as theirs, so **you DO NOT need to go through another review**. Read more below. 263 | 264 | ### Journal of Open Source Software (JOSS) submission 265 | 266 | pyOpenSci has a [partnership with JOSS](JOSS), where our review is accepted by JOSS by 267 | default if the package fits into the JOSS scope. 268 | 269 | - When you submit your package for pyOpenSci review, you can opt to include a 270 | submission to JOSS after passing pyOpenSci review. In this case, your package 271 | will be evaluated by JOSS through the pyOpenSci review. 272 | - To complete the JOSS submission, you will also need to craft a **paper.md** 273 | file describing the package following JOSS' standards (see below). More details on the requirements for JOSS can be found on [their website](https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain). 274 | - If you choose to opt into the pyOpenSci/JOSS partnership in your review, 275 | you DO NOT need to go through a second review with JOSS. JOSS accepts our review 276 | as theirs. Please start a review process with JOSS and reference the pyOpenSci 277 | review issue where your package was accepted. Make sure 278 | that you let the JOSS editor know that we have already accepted your package. The JOSS editor will review your paper. Once your package is accepted, you will be given a JOSS cross-ref-enabled DOI and badge to display on your README file. 279 | 280 | ```{note} 281 | Acceptance to pyOpenSci does not guarantee acceptance to JOSS. In particular, 282 | JOSS doesn't accept the full variety of packages that are in scope for 283 | pyOpenSci. For example, thin API wrappers fall within 284 | [pyOpenSci's scope](../about/package-scope) but 285 | are usually not accepted by JOSS. Be sure to review JOSS's 286 | [submission requirements](https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements) 287 | before writing up a paper about your package. 288 | ``` 289 | 290 | ## Post review - welcome to the pyOpenSci community 291 | 292 | Congratulations! Once your package has been accepted into the pyOpenSci ecosystem, you'll be invited to join our [community Slack](https://join.slack.com/t/pyopensci/shared_invite/zt-39qitgkqb-gZTIo79xCJhS5kSxW1yNfg) where you can connect with other package maintainers, get help with maintenance questions, and stay updated on community developments. 293 | 294 | ### Ongoing support from pyOpenSci 295 | 296 | We're committed to supporting you throughout your package's maintenance journey: 297 | 298 | **Annual check-ins**: We'll reach out each year to see how your package is doing and learn about any updates we can help highlight through our blog, social media, or newsletter. 299 | 300 | **Community resources**: Take advantage of our Slack community to connect with other maintainers, share experiences, and get advice on common maintenance challenges. We're also building additional resources and tools to help package maintainers succeed. 301 | 302 | **Maintenance assistance**: If you have specific maintenance challenges, our Slack community is a great place to ask questions. There is a lot of packaging and community expertise in our vibrant community! 303 | 304 | ### When you need help or want to step down 305 | 306 | Life changes and priorities shift. If maintaining your package becomes challenging, please reach out to us. We're here to help, and we have several options: 307 | 308 | - **Finding co-maintainers or new maintainers**: If you are interested, we can try to connect you with community members interested in contributing to or taking over maintenance of your package. 309 | - **Package archival**: If maintenance isn't sustainable, we can work together [to archive your package](https://www.pyopensci.org/python-packages.html#archived-packages). 310 | 311 | If the package is archived, we will remove it from our curated list 312 | of vetted tools. 313 | 314 | ### Maintenance policies 315 | 316 | For detailed information about our maintenance expectations, annual check-in process, and archival procedures, please take a look at our [post-review process documentation](post-review-process). Remember, you maintain full ownership of your package. We're here to support you, not interfere with your development process. 317 | 318 | :::{tip} 319 | We will [follow our package archive process to determine whether your package should be archived.](archive-process) 320 | ::: 321 | --------------------------------------------------------------------------------