[REVIEW]: pyrexMD: Workflow-Orientated Python Package for Replica Exchange Molecular Dynamics

[whedon]

Submitting author: @ArtVoro (Arthur Voronin)
Repository: https://github.com/KIT-MBS/pyREX
Version: v1.0
Editor: @jgostick
Reviewers: @janash, @rosecers, @jarvist
Archive: 10.5281/zenodo.5744760

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

Status

Status badge code:

HTML: <a href="https://joss.theoj.org/papers/957b0672d03306d75cc12fada3a6b6da"><img src="https://joss.theoj.org/papers/957b0672d03306d75cc12fada3a6b6da/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/957b0672d03306d75cc12fada3a6b6da/status.svg)](https://joss.theoj.org/papers/957b0672d03306d75cc12fada3a6b6da)

Reviewers and authors:

Please avoid lengthy details of difficulties in the review thread. Instead, please create a new issue in the target repository and link to those issues (especially acceptance-blockers) by leaving comments in the review thread below. (For completists: if the target issue tracker is also on GitHub, linking the review thread in the issue or vice versa will create corresponding breadcrumb trails in the link target.)

Reviewer instructions & questions

@janash & @rosecers, please carry out your review in this issue by updating the checklist below. If you cannot edit the checklist please:

1. Make sure you're logged in to your GitHub account
2. Be sure to accept the invite at this URL: https://github.com/openjournals/joss-reviews/invitations

The reviewer guidelines are available here: https://joss.readthedocs.io/en/latest/reviewer_guidelines.html. Any questions/concerns please let @jgostick know.

✨ Please start on your review when you are able, and be sure to complete your review in the next six weeks, at the very latest ✨

Review checklist for @janash

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@ArtVoro) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

I believe that this check mark is what has been causing the delay for both me and @rosecers. Unfortunately, when this paper was first submitted, the package was not well-documented and was hard to understand. We have asked for some clarification and code clean up. Unfortunately, I feel that even with the improvements this work does not meet the requirements of JOSS for substantial scholarly effort and I can't recommend this package for publication in JOSS at this time.

JOSS defines the following for substantial scholarly effort:

As a rule of thumb, JOSS’ minimum allowable contribution should represent not less than three months of work for an individual. Some factors that may be considered by editors and reviewers when judging effort include:

• Age of software (is this a well-established software project) / length of commit history.
• Number of commits.
• Number of authors.

This package has only one author.

• Total lines of code (LOC). Submissions under 1000 LOC will usually be flagged, those under 300 LOC will be desk rejected.

While this submission appears to fit this criteria, upon closer inspection this is questionable. Many of the functions in misc.py, for example do not add any functionality that are not in Python already (for example

This package has many more lines of code than are needed to achieve its objective. Many of the functions are what I would call light wrappers around other libraries and do not add much functionality themselves. Many functions (particularly in misc.py reimplement functionality that are already available in Python or have statements that are unnecessary.

• Whether the software has already been cited in academic papers.

The software has not been cited in academic papers

• Whether the software is sufficiently useful that it is likely to be cited by your peer group.

I am not convinced of this point because the software is mostly thin wrappers around existing code.

I unfortunately cannot recommend this software package for publication in JOSS at this time. I think it would be more appropriate for the author to obtain a DOI through something like Zenodo and resubmit for publication if the package proves sufficiently useful.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Review checklist for @rosecers

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@ArtVoro) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?
• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.
• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).
• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?
• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?
• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?
• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?
• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

[whedon]

Hello human, I'm @whedon, a robot that can help you with some common editorial tasks. @janash, @rosecers it looks like you're currently assigned to review this paper 🎉.

⚠️ JOSS reduced service mode ⚠️

Due to the challenges of the COVID-19 pandemic, JOSS is currently operating in a "reduced service mode". You can read more about what that means in our blog post.

⭐ Important ⭐

If you haven't already, you should seriously consider unsubscribing from GitHub notifications for this (https://github.com/openjournals/joss-reviews) repository. As a reviewer, you're probably currently watching this repository which means for GitHub's default behaviour you will receive notifications (emails) for all reviews 😿

To fix this do the following two things:

1. Set yourself as 'Not watching' https://github.com/openjournals/joss-reviews:

2. You may also like to change your default settings for this watching repositories in your GitHub profile here: https://github.com/settings/notifications

For a list of things I can do to help you, just type:

@whedon commands

For example, to regenerate the paper pdf after making changes in the paper's md or bib files, type:

@whedon generate pdf

[whedon]

Reference check summary (note 'MISSING' DOIs are suggestions that need verification):

OK DOIs

- 10.1016/S0009-2614(99)01123-9 is OK
- 10.1063/1.2056540 is OK
- 10.1002/jcc.20291 is OK
- 10.1073/pnas.1111471108 is OK
- 10.1021/acs.jpcb.6b13105 is OK
-  10.25080/Majora-629e541a-00e  is OK
- 10.1002/jcc.21787 is OK
- 10.1093/bioinformatics/btx789 is OK
- 10.5281/zenodo.2654393 is OK
- 10.1371/journal.pone.0242072 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

Software report (experimental):

github.com/AlDanial/cloc v 1.88  T=0.87 s (96.6 files/s, 92505.3 lines/s)
-------------------------------------------------------------------------------
Language                     files          blank        comment           code
-------------------------------------------------------------------------------
HTML                            22           4640             66          20004
JavaScript                      14           2404           2467           9203
Python                          21           1955           4952           5588
SVG                              1              0              0           2671
CSS                              5            208             45            809
Jupyter Notebook                10              0          24370            551
Markdown                         2             45              0            135
TeX                              1             12              0            122
reStructuredText                 6             38             66             43
DOS Batch                        1              8              1             26
make                             1              4              7              9
-------------------------------------------------------------------------------
SUM:                            84           9314          31974          39161
-------------------------------------------------------------------------------


Statistical information for the repository 'ceb0d5cffa2b47c6e28644d8' was
gathered on 2021/06/01.
The following historical commit information, by author, was found:

Author                     Commits    Insertions      Deletions    % of changes
Arthur                          50         20471           4475           63.93
Arthur Voronin                  64         12204           1870           36.07

Below are the number of rows from each author that have survived and are still
intact in the current revision:

Author                     Rows      Stability          Age       % in comments
Arthur                    26569          129.8          1.5               14.26

[whedon]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[whedon]

👋 @janash, please update us on how your review is going (this is an automated reminder).

[whedon]

👋 @rosecers, please update us on how your review is going (this is an automated reminder).

[janash]

Hi @whedon - I've gone over the COI and general checks and installed the dependencies. Planning to closely review the software later this week and this weekend!

[rosecers]

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.
  General checks
• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@ArtVoro) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

My largest concern comes from the citability and need within the community -- there are no publications that mention "pyrexMD", and the publications of the two authors using REMD (3 as of 2020) have not yet been cited*. To this end, the authors need to comment on two things: the breadth of scope of this software (it appears quite narrow), and whether similar workflows would be supported by pre-existing software (particularly SSAGES).
*All citation metrics checked via searching WebOfKnowledge and GoogleScholar.

Functionality

• Installation: Does installation proceed as outlined in the documentation?
• Functionality: Have the functional claims of the software been confirmed?

The results contained in the paper summary are reproducible in the examples. Beyond that, no functional claims have been made.

• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?

The authors have an explicit statement of need in their write-up; however, mentioned above, they have not addressed the breadth of the scope of this package and the currently available software packages intended to this end.

• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.

The requirements for pyrexMD need to be more prominently featured. For example, some packages require specific python versions, which may not be clear upon installation. pytest and autopep8should be added as a requirement for testing and examples purposes.

• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).

The authors include examples, however, these are not well-documented and require more explanation / commenting, without which I can't know what the examples are intending to demonstrate or if the results are as expected.

Additionally, the authors should embed some examples in the documentation -- if there is a user considering using this package, they may want to see a demonstration of the package before downloading and without searching through the API.

• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

There is API documentation -- it is sufficient, but could greatly benefit from further formatting and editing.

• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?

The tests are sufficient, however, they currently raise several warnings, which should be remedied. As for coverage, no coverage test or CI is implemented to check on the functionality.

• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

No.

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?

The summary is minimal -- the authors should expand considerably on the REX methodology and the workflows supported by pyrexMD.

• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?

There is an explicit statement of need that needs to be amended (described in preceding comments).

• State of the field: Do the authors describe how this software compares to other commonly-used packages?

No.

• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?

The authors are fairly terse in their writing, and need to expand in several places (e.g. the figure explanations and applications).

• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Overall, the examples, use cases, and need for this software need to be expanded upon. The examples should include commentary as to the expected behavior and "behind the scenes" operation of the software, including an introductory paragraph at the top of the example to explain what is being demonstrated. The authors have not identified use cases for this software beyond their own publications -- they should detail in their write-up examples of the sorts of analyses possible with this software. Finally, there needs to be some statement as to the novelty of this software -- is it fulfilling a need within the community which is not currently being met?

[ArtVoro]

thank you for the feedback. i will try to solve most of the things mentioned over this weekend.

[janash]

Conflict of interest

• I confirm that I have read the JOSS conflict of interest (COI) policy and that: I have no COIs with reviewing this work or that any perceived COIs have been waived by JOSS for the purpose of this review.

Code of Conduct

• I confirm that I read and will adhere to the JOSS code of conduct.

General checks

• Repository: Is the source code for this software available at the repository url?
• License: Does the repository contain a plain-text LICENSE file with the contents of an OSI approved software license?
• Contribution and authorship: Has the submitting author (@ArtVoro) made major contributions to the software? Does the full list of paper authors seem appropriate and complete?
• Substantial scholarly effort: Does this submission meet the scope eligibility described in the JOSS guidelines

This software mainly seems to be a wrapper around three libraries - gromacs, nglview, and mdanalysis. The software has not yet been cited in academic papers. In its current state, the paper does not appear to meet the definition of substantial scholarly effort.

Functionality

• Installation: Does installation proceed as outlined in the documentation?

I had difficulty installing the software due to a missing dependency with mpi4py on my mac. I used brew install mpich which then allowed my installation to proceed. I recommend adding a CI action (GitHub Actions or other of your choice) to test installation on supported operating systems. You should also run your tests using CI and add code coverage.

• [] Functionality: Have the functional claims of the software been confirmed?

I feel that I need expanded example usage documentation to determine this. The main functional claims of the software are in the last paragraph of the statement of need. It might be beneficial to number the examples as tutorials and reference the tutorial numbers in the paper.

• Performance: If there are any performance claims of the software, have they been confirmed? (If there are no claims, please check off this item.)

No performance claims made.

Documentation

• A statement of need: Do the authors clearly state what problems the software is designed to solve and who the target audience is?
• Installation instructions: Is there a clearly-stated list of dependencies? Ideally these should be handled with an automated package management solution.

There is a list of installation instructions. I did encounter an error with dependencies as described above. I have a few comments about the installation instructions:

• there is no need to do an "editable' -e install for most users, unless you expect them to be pulling from the repo for updates.
• I recommend putting the package on the Python Package Index (PyPI) so that users can install with pip.

• Example usage: Do the authors include examples of how to use the software (ideally to solve real-world analysis problems).

There is example usage, but the documentation associated with the example usage needs to be expanded. Please use a combination of markdown and code cells in your example notebook to give an explanation of tutorials.

• Functionality documentation: Is the core functionality of the software documented to a satisfactory level (e.g., API method documentation)?

Please move documentation link on the readme to top. There is API documentation that is adequate for using the package. However, it would benefit from additional documentation or better organization.

• Automated tests: Are there automated tests or manual steps described so that the functionality of the software can be verified?

There is a set of tests which can be run with pytest (manual steps), but there are no automated tests.

• Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

No.

Software paper

• Summary: Has a clear description of the high-level functionality and purpose of the software for a diverse, non-specialist audience been provided?
• A statement of need: Does the paper have a section titled 'Statement of Need' that clearly states what problems the software is designed to solve and who the target audience is?
• State of the field: Do the authors describe how this software compares to other commonly-used packages?

No. Please expand this portion.

• Quality of writing: Is the paper well written (i.e., it does not require editing for structure, language, or writing quality)?

• References: Is the list of references complete, and is everything cited appropriately that should be cited (e.g., papers, datasets, software)? Do references in the text use the proper citation syntax?

Summary
The author needs to give more justification for the scholarly effort of this package as suggested by @rosecers . The documentation should be improved and expanded, with more explanation given for the examples. A tutorial describing a full workflow (set-up, running simulation, and analysis) should be provided as well.

I also suggest automated building and testing of your package using GitHub Actions, and putting your package on PyPI for ease of installation.

[rosecers]

Functionality

• Installation: Does installation proceed as outlined in the documentation?

I had difficulty installing the software due to a missing dependency with mpi4py on my mac. I used brew install mpich which then allowed my installation to proceed. I recommend adding a CI action (GitHub Actions or other of your choice) to test installation on supported operating systems. You should also run your tests using CI and add code coverage.

I'd like to echo @janash's difficulty with installation, as I also had issue with mpi4py on my mac; I concur that the authors should test installation on supported operating systems. Ultimately, I needed to run:

cd $INSTALL_DIR
git clone https://github.com/KIT-MBS/pyrexMD.git
cd pyrexMD
conda install clangxx_osx-64
pip install mpi4py
python -m pip install -e .

[jgostick]

@janash and @rosecers, thanks for the thorough review so far! @ArtVoro, you have a clear list of things to work on, so I'll check back next week.

[ArtVoro]

sorry for the late response.

I did some CI with building and testing the software (took me longer than expected) and reworked the tutorials (juypter notebooks). Now ill expand the online documentation and then revisit the paper.

[ArtVoro]

Update about the tasks:

• reworked the installation instructions
• added code coverage
• added CI via github actions: build gromacs -> build python package -> run tests -> update documentation
  (build and tests are performed on ubuntu & mac)
• reworked example jupyter notebooks
• added a quick guide to online documentation (https://kit-mbs.github.io/pyrexMD/quick_guide.html)

Todo:

• tasks related to the paper itself

[ArtVoro]

A few notes:

• The package was private until the JOSS submission so obviously there are no citations about the software. However I am submitting a paper within the next month where I explicitly call the name of the software.
• I intend to upload the package to PyPI but will wait until the end of this review because (as far as I know) it is not possible to reuse a package version number

[ArtVoro]

@jgostick we pushed a new version of paper.md and extended the citations accordingly. I think all points mentioned from the reviewers should be covered now.

[ArtVoro]

@whedon generate pdf

[whedon]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[janash]

Thank you @ArtVoro, the documentation is much improved. I would still like to see some additional comments/explanation in the example notebook tutorials.

I have concerns about code quality and maintainability. Particularly, a large amount of code is repeated when it need not be. Please see the issue I have filed on your repository (KIT-MBS/pyrexMD#1). I would suggest some sort of decorator for the gromacs functions instead of the current implementation.

This is relevant for a few reasons: 1 - Repeating code in this way is a bad practice. Since the functionality is the same for all these parts, it will be harder to maintain or change in the future (think having to change several places vs one place if you want to change behavior). 2. JOSS lists lines of code as a metric in scholarly effort.

[ArtVoro]

thanks for the feedback. the repeated code on gmx.py was actually on my todo list but had low priority. however since its not much effort i can fix it over this weekend.

about the notebooks, i can take another look at it and add more comments/explanation as you suggested but I dont know when exactly. Im working on 2 papers right now and my schedule is already packed. due to the delays in reviews I want to send out the drafts first.

[ArtVoro]

i fixed the repeated code by calling help functions now.

[rosecers]

Hey @ArtVoro, I've finally been able to get another look at this and was once again in a tornado of trying to install the package and run the tests.

Comments on installation and testing:

• You have included both a requirements.txt and requirements_python3.6.txt. You should instead use environment markers to automatically detect the two and avoid confusion.
• In general the installation requirements are quite stringent -- are all of these exact versions necessary?
• Issues with requirements_python3.6.txt:
  • heat=1.0.0 requires python >=3.7
  • ipywidgets 7.4.2 depends on widgetsnbextension~=3.4.0, and the requested version is 3.5.1
• Running pyrexMD/tests/test_gmx.py currently results in an error due to a segfault. I am not a regular GROMACS user, so this may be due to my install, but should be addressed nonetheless in case it is due to memory concerns:
  gmx convert-tpr -s pyrexMD/examples/files/protein//../traj/traj_protein.tpr -o /Users/rosecers/work_folders/cosmo/tests/pyrexmd/pyrexMD/traj_protein_protein.tpr

Comments on what I've been able to get through in the code:

• gmx.py: I am concerned with how much of gmx.py is modified versions of GromacsWrapper or effectively switch statements. For the functions which are primarily purposed in GromacsWrapper, I would suggest you create a fork of GromacsWrapper to modify the code or propose the modified functions directly to that repository if you think these functions will be appreciated by the community at large. I don't think that they necessitate inclusion into a new package.
• misc.py: How much of this is original code, and how much are wrappers to slim down code or add a print statement? This is a rather bloated file, most of which should be deleted.

  • Please delete everything that is effectively

          import module 
          def func(*args, **kwargs):
              return module.func(*args, **kwargs)

    and just refer to the original module functions or a set of module functions instead. There is also code for which the functionality already exists in the current dependencies. Examples: cwd, pwd, isdir, isfile, pathexists, realpath, dirpath, get_filedir, mkdir, and many more.

  • apply_matplotlib_rc_settings can just be a matplotlib style sheet.

  • is update_alias_docstring just for your own use to create docstrings? Where else is it used?

  • What are the functional purposes of CONFIG? With the exception deepcopy_without and update_by_alias, it appears to contain functions that are just renamings, not even wrappers, of built-in functions.

All in all the documentation, paper, and code have been improved, but still need to be streamlined. I'll try to give another look-over next week.

[whedon]

OK, @jarvist is now a reviewer

[kthyng]

@janash, @rosecers I am not sure if you've followed the developments on this JOSS submission after you worked on reviews. In short, we have had another person contribute to the review and it has been found in good enough shape for acceptance. Currently you are both listed as reviewers and we'd like to list you as reviewers in recognition of your efforts here, but understand if you do not wish to be listed. Could you please comment here as to your preference either way?

[janash]

Hi @kthyng - yes,I have been following. Thanks to @jarvist for finishing up the review. Please do keep my name on the reviewers list. Thanks

[kthyng]

Thank you @janash!

[jgostick]

I emailed @rosecers about this in case she doesn't receive github notifications. Will let you know when I hear.

[jgostick]

@rosecers has also given her go-ahead to list her as a reviewer, so this is good-to-go

[ArtVoro]

@kthyng just pinging you, since I asume you don't get automatic notifications.

[kthyng]

Ok, great sounds like the reviewer question is answered fully! I'll go through the rest of the final steps.

[kthyng]

@ArtVoro things look good, though please preserve capitalization for Jupyter in a reference with {} in the .bib file around the word or character. Also check the other references carefully for correct capitalization.

[ArtVoro]

@kthyng i checked the reference titles based on the proof from openjournals/joss-papers#2780. I fixed some and they should all be correct now.

[kthyng]

@whedon generate pdf

[whedon]

👉📄 Download article proof 📄 View article proof on GitHub 📄 👈

[kthyng]

Ok looks good!

[kthyng]

@whedon accept deposit=true

[whedon]

Doing it live! Attempting automated processing of paper acceptance...

[whedon]

🐦🐦🐦 👉 Tweet for this paper 👈 🐦🐦🐦

[whedon]

🚨🚨🚨 THIS IS NOT A DRILL, YOU HAVE JUST ACCEPTED A PAPER INTO JOSS! 🚨🚨🚨

Here's what you must now do:

0. Check final PDF and Crossref metadata that was deposited 👉 Creating pull request for 10.21105.joss.03325 joss-papers#2787
1. Wait a couple of minutes, then verify that the paper DOI resolves https://doi.org/10.21105/joss.03325
2. If everything looks good, then close this review issue.
3. Party like you just published a paper! 🎉🌈🦄💃👻🤘

Any issues? Notify your editorial technical team...

[kthyng]

Congrats on your new publication @ArtVoro! Many thanks to editor @jgostick and reviewers @janash, @rosecers, and @jarvist on your time, hard work, and expertise!!

[whedon]

🎉🎉🎉 Congratulations on your paper acceptance! 🎉🎉🎉

If you would like to include a link to your paper from your README use the following code snippets:

Markdown:
[![DOI](https://joss.theoj.org/papers/10.21105/joss.03325/status.svg)](https://doi.org/10.21105/joss.03325)

HTML:
<a style="border-width:0" href="https://doi.org/10.21105/joss.03325">
  <img src="https://joss.theoj.org/papers/10.21105/joss.03325/status.svg" alt="DOI badge" >
</a>

reStructuredText:
.. image:: https://joss.theoj.org/papers/10.21105/joss.03325/status.svg
   :target: https://doi.org/10.21105/joss.03325

This is how it will look in your documentation:

We need your help!

Journal of Open Source Software is a community-run journal and relies upon volunteer effort. If you'd like to support us please consider doing either one (or both) of the the following:

• Volunteering to review for us sometime in the future. You can add your name to the reviewer list here: https://joss.theoj.org/reviewer-signup.html
• Making a small donation to support our running costs here: https://numfocus.org/donate-to-joss

[ArtVoro]

I would also like to thank you all for your help with this review.

Best regards
Arthur