[REVIEW]: pvpumpingsystem: a python package for modeling and sizing photovoltaic water pumping systems

[whedon]

Submitting author: @tylunel (Tanguy Lunel)
Repository: https://github.com/tylunel/pvpumpingsystem
Version: v1.0.0
Editor: @kbarnhart
Reviewer: @samuelduchesne, @robinroche
Archive: 10.5281/zenodo.4134280

⚠️ 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/cdd86249b4abcd1d664802fd08f9894d"><img src="https://joss.theoj.org/papers/cdd86249b4abcd1d664802fd08f9894d/status.svg"></a>
Markdown: [![status](https://joss.theoj.org/papers/cdd86249b4abcd1d664802fd08f9894d/status.svg)](https://joss.theoj.org/papers/cdd86249b4abcd1d664802fd08f9894d)

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

@samuelduchesne & @robinroche, 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 @kbarnhart 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 @samuelduchesne

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 (@tylunel) 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: Do the authors clearly state 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 @robinroche

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 (@tylunel) 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: Do the authors clearly state 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. @samuelduchesne, @robinroche 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.21105/joss.00884 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[whedon]

👉 Check article proof 📄 👈

[kbarnhart]

@samuelduchesne and @robinroche thanks for agreeing to review this submission to JOSS. As noted above, we are trying to adjust to authors, reviewers, and editors needs under COVID. Thus we are asking reviewers try and complete reviews in 6 weeks. I am going to use whedon the editorial bot to remind you about your review in three weeks, half way through the requested timeline.

If there are any questions from the authors or reviewers throughout the process, please feel free to let me know here or directly at [email protected].

Thanks again for contributing to the JOSS review process.

[kbarnhart]

@whedon remind @samuelduchesne in three weeks

[whedon]

Reminder set for @samuelduchesne in three weeks

[kbarnhart]

@whedon remind @robinroche in three weeks

[whedon]

Reminder set for @robinroche in three weeks

[whedon]

👋 @samuelduchesne, please update us on how your review is going.

[whedon]

👋 @robinroche, please update us on how your review is going.

[robinroche]

Hi, I will work on it next week. Sorry for the delay.

[samuelduchesne]

Still working on it! Thanks

[kbarnhart]

@robinroche and @samuelduchesne thanks for checking in. As I noted above, the recent reminder marks three weeks into the review and JOSS is asking reviewers to complete reviews in six weeks. Thanks in advance for your contributions to the JOSS review process.

[robinroche]

@tylunel @kbarnhart
I am done with my review.
I have some suggestions for improvement:

1. Installation

• "open the command line interface ‘Anaconda prompt’": briefly explain how, or link to a page explaining how.
• "cd src/pvpumpingsystem pytest": I am on linux and this command did not work as is. However, splitting it in two worked.
• More information on the automated test script should be provided to the user. What can the user expect to see when running it? I got 26 warnings (see below).
• "Besides the libraries contained in Anaconda, pvpumpingsystem also requires: * pvlib-python: * fluids: * numpy-financial:": there is a minor formatting issue with this list.
• I feel that a "Getting started" page would help right after installation, and describe the basic steps of the design of a simple system design. The examples are great, but I feel that this would make the new user more comfortable.

Documentation:

• Examples of target audiences are not listed in the documentation, unless I missed it.
• Explain briefly what each example does.
• What is the source of data on pumps, etc.?

Paper:

• There is no comparison with any comparable existing software. What is new/better in the proposed one?

---

Results of the test script:

============================================ test session starts ============================================
platform linux -- Python 3.7.6, pytest-5.3.5, py-1.8.1, pluggy-0.13.1
rootdir: /home/rroche/src/pvpumpingsystem
plugins: doctestplus-0.5.0, arraydiff-0.3, astropy-header-0.1.2, hypothesis-5.5.4, remotedata-0.3.2, openfiles-0.4.0
collected 16 items

pvpumpingsystem/test/test_pump.py ....... [ 43%]
pvpumpingsystem/test/test_pvpumpsystem.py ..... [ 75%]
pvpumpingsystem/test/test_sizing.py .... [100%]

============================================= warnings summary ==============================================
pvpumpingsystem/test/test_pump.py::test_init
pvpumpingsystem/test/test_pump.py::test_all_models_coeffs
pvpumpingsystem/test/test_pump.py::test_functIforVH
pvpumpingsystem/test/test_pump.py::test_functQforPH
pvpumpingsystem/test/test_pump.py::test_iv_curve_data
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_mppt
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_mppt
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_direct
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_direct
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:102: UserWarning: idname attribute overwritten.
warnings.warn('idname attribute overwritten.')

pvpumpingsystem/test/test_pump.py::test_init
pvpumpingsystem/test/test_pump.py::test_limited_pump_data_1
pvpumpingsystem/test/test_pump.py::test_all_models_coeffs
pvpumpingsystem/test/test_pump.py::test_functIforVH
pvpumpingsystem/test/test_pump.py::test_functQforPH
pvpumpingsystem/test/test_pump.py::test_iv_curve_data
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:112: UserWarning: motor_electrical_architecture attribute overwritten.
warnings.warn('motor_electrical_architecture '

pvpumpingsystem/test/test_pump.py::test_limited_pump_data_1
pvpumpingsystem/test/test_pump.py::test_limited_pump_data_2
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:1515: UserWarning: Power and current data will be recomputedwith constant efficiency assumption.
warnings.warn('Power and current data will be recomputed'

pvpumpingsystem/test/test_pump.py::test_limited_pump_data_2
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:1297: UserWarning: Simplistic model of constant efficiency applied.Better model could be used if permanent_magnet
warnings.warn('Simplistic model of constant efficiency applied.'

pvpumpingsystem/test/test_pump.py::test_functIforVH
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/inverse.py:199: RuntimeWarning: Trouble calculating inverse for values: [7.]
"%s" % str(yin[~resultsmask]), RuntimeWarning)

pvpumpingsystem/test/test_pump.py::test_functIforVH
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:381: RuntimeWarning: invalid value encountered in sqrt
return R_ai + betanp.sqrt(i)

pvpumpingsystem/test/test_pump.py::test_functIforVH
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/inverse.py:207: RuntimeWarning: Results obtained with less than 2 decimal digits of accuracy
% accuracy, RuntimeWarning)

pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_mppt
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_direct
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/pump.py:94: UserWarning: price attribute overwritten.
warnings.warn('price attribute overwritten.')

pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_mppt
pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_direct
/home/rroche/anaconda3/lib/python3.7/site-packages/scipy/optimize/minpack.py:808: OptimizeWarning: Covariance of the parameters could not be estimated
category=OptimizeWarning)

pvpumpingsystem/test/test_sizing.py::test_sizing_minimize_npv_direct
/home/rroche/src/pvpumpingsystem/pvpumpingsystem/sizing.py:225: UserWarning: Pump Shurflo_9325 and PV module voltage do not match
'do not match').format(pump.idname))

-- Docs: https://docs.pytest.org/en/latest/warnings.html
===================================== 16 passed, 26 warnings in 17.41s ======================================

[samuelduchesne]

@kbarnhart, I am done with the review as well. On my end, I worked on MacOS and had no issues installing and using the tool from the installation documentation. I enjoyed trying out this package which is very well coded (excellent programming ethics). The examples were very useful to understand how to use the package. Having both jupyter notebooks and python scripts in the examples folder is a welcomed feature.

Regarding installation, my only suggestion would be to upload the package to PyPi (or to conda-forge) so that a regular pip install (or conda install) is possible; installing in editable mode is unusual for published packages.

I agree with @robinroche's suggestions for improvement which cover most of the package-related considerations. I do have general comments as well as some questions regarding the methodology the tool implements (which should not be overlooked...). I present them bellow.

Scope

• The scope section (and the readme) needs a good diagram visually explaining the tool (the jupyter notebook example has a nice one). This will help users understand quickly the use of this tool.

Mention of "minimization"

There is very little information in the docs as well as in the paper about the kind of optimization that is performed in the sizing module.

• How is the NPV minimized? It seems that only a parametric study is performed where some configurations are kept and others are discarded;
• Looking at the code, it seems that sizing_minimize_npv() returns a list of possible PV module and pump configurations. What if multiple systems satisfy the constraints? Then, the user must choose?

Also, the hardcoded values of 45° and 180° for the PV surface tilt and azimuth in subset_respecting_llp_direct is questionable; An optimal panel angle usually follows the latitude of the location.

• Why did the author chose these values?https://github.com/tylunel/pvpumpingsystem/blob/5a6bb6e1c3d1387e04a989cdf1a54baa956f7b50/pvpumpingsystem/sizing.py#L172-L173

• I suggest that the author more clearly define the two use cases in the documentation (and the paper): 1. the modeling of pv pumping system operation and 2. the sizing of such systems.

• Clearly mention the limitations of the sizing module. What are the variables that can (or cannot) be optimized?

[robinroche]

@kbarnhart
Reading @samuelduchesne 's comments, I realize that I somehow forgot to paste my comments on the technical (application) aspects and conclusions. However they are similar to @samuelduchesne 's. This a nice contribution that can be useful to both researchers and designers of such systems.

[tylunel]

Thanks for you very constructive comments @samuelduchesne @robinroche ! I will address the points you raise and come back to you with the corresponding improvements.

But before I have two questions. The first is about the warnings in the tests:

More information on the automated test script should be provided to the user. What can the user expect to see when running it? I got 26 warnings (see below)

I am not sure what is the best practice here, and unfortunately internet did not provide a clear answer on it either haha. I added several warnings in my code in order to guide the user during a normal simulation or sizing, but this results in having all these warnings in the tests as well. Should I try not to add as much UserWarning (in my view it would make the use of the software maybe more complicated for unexperienced user)? Or is it okay to ignore some class of warnings in the tests like UserWarnings (as implicitly suggested here: https://docs.pytest.org/en/stable/warnings.html)? Or is it enough just to tell the user that it is normal to see 26 warnings when she/he runs the tests?

The second question in actually more a request for clarification to @robinroche :

I feel that a "Getting started" page would help right after installation, and describe the basic steps of the design of a simple system design. The examples are great, but I feel that this would make the new user more comfortable.

What does this "Getting started" page should contain more exactly in your opinion? Help on how to run the python and jupyter notebook examples? More general explanations around what is a PV pumping system (so far, I assume that the users have a minimum knowledge about PV pumping systems)? A more abstract layout of the steps of simulation than what is proposed in the examples? Thanks in advance for providing further details

[kbarnhart]

@robinroche and @samuelduchesne Thanks for your thoughtful reviews! At this point in the JOSS process we will now let @tylunel address these issues. If more extensive discussion needs to take place I would recommend that @tylunel make an issue in the submitted repository, paste and link to the above review comments, and focus the discussion there. This makes it easier to keep track of multiple threads.

I'll weigh in briefly regarding two items.

1. I agree with @samuelduchesne that distributing via conda-forge or pip would be highly encouraged.
2. Regarding warnings and the result of tests I think the most important thing is to communicate to a user how to evaluate whether the tests passed or not. Secondly I think that if you know (as the developer) that a test will produce a warning (e.g., the example above where the warning is "UserWarning: price attribute overwritten.") you should set up the tests so that that warning is expected, handled, and the test fails if the warning is not raised (e.g., using pytest.warns()).

Regarding other warnings (e.g., RuntimeWarning, DeprecationWarning), there are lots of options for warning handling in testing tools (I'm mostly familiar with those in pytest) but I think that how one uses them is a matter of developer preference (e.g., you could turn them all off using a configuration file, but perhaps you want to know when DeprecationWarnings arrive). Ultimately this means that it is important for the developer to communicate to someone who might use the tests about what they should see.

Happy to discuss these and other points. Please let me know how I can assist as you respond and clarify reviewer comments.

[robinroche]

What does this "Getting started" page should contain more exactly in your opinion? Help on how to run the python and jupyter notebook examples? More general explanations around what is a PV pumping system (so far, I assume that the users have a minimum knowledge about PV pumping systems)? A more abstract layout of the steps of simulation than what is proposed in the examples? Thanks in advance for providing further details

@tylunel Yes, I was thinking of a high level explanation of how to use the code, and pointing the user to the basic example at the end of the installation.

More information on the automated test script should be provided to the user. What can the user expect to see when running it? I got 26 warnings (see below)

@tylunel I agree with @kbarnhart . I did not notice anything worrying in the warnings, but I think that the user should know that getting these warnings may be normal. Otherwise one may wonder if the code will be fully operational or not.

[tylunel]

The changes have been made as proposed in the reviews. I hope that it corresponds well to your expectations @robinroche @samuelduchesne.

There is one point that was maybe not addressed completely as expected, it is for the clear definition of the 2 use cases (penultimate item of @samuelduchesne). On that, I did not want to insist too much on the sizing case, as it is not the core of the package. The modeling tools are the core, and the sizing tool proposed is more a wrapper of the previous tools, and should be more seen as an example of how the code can be used to adress complex problems. I tried to clarify it in the docs as well.

For the rest of the modifications, there were all useful I think, thanks!

[robinroche]

@tylunel Thanks, my comments have been addressed. Congratulations on this package that will hopefully be useful to many.

[samuelduchesne]

Thank you @tylunel for addressing these comments. I have nothing to add 😀

[kbarnhart]

@robinroche and @samuelduchesne thank you for your thoughtful comments and timely review. @tylunel thank you for responding to the reviewer comments.

Now that the reviewers have completed the checklist and recommended publication the next step is that I will do a final proofreading step on the publication (I may make a PR or just provide a list). This will happen in the next few days. Once that is complete I will ask @tylunel to complete a few steps to create the final archive and will then pass the submission on to the JOSS Editors in Chief for final processing.

[kbarnhart]

@tylunel it looks like there is an issue with the paper.md file that makes it not compile. Would you address it and then ping me so I can proceed.

If you make changes on a test branch, know that you can use whedon to compile off a custom branch:

# Compile the paper from alternative branch
@whedon generate pdf from branch custom-branch-name

[tylunel]

@kbarnhart Sorry for that, I forgot to check the encoding in UTF-8 after the last changes in paper.md.
It should be okay now!

[kbarnhart]

@whedon generate pdf

[whedon]

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

[kbarnhart]

@whedon generate pdf

[whedon]

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

[kbarnhart]

@tylunel thanks for merging those copyedits. Congratulations on making to the end of the JOSS review process.

At this point could you:

• Make a tagged release of your software, and list the version tag of the archived version here.
• Archive the reviewed software in Zenodo or a similar service (e.g., figshare, an institutional repository)
• Check the archival deposit (e.g., in Zenodo) has the correct metadata. This includes the title (should match the paper title) and author list (make sure the list is correct and people who only made a small fix are not on it). You may also add the authors' ORCID.
• Please list the DOI of the archived version here.

I can then move forward with accepting the submission.

[tylunel]

The release version is v1.0.0 (https://github.com/tylunel/pvpumpingsystem/releases/tag/v1.0.0) and the DOI of the archive version is 10.5281/zenodo.4134280 (https://zenodo.org/record/4134280).

[kbarnhart]

@whedon set v1.0.0 as version

[whedon]

OK. v1.0.0 is the version.

[kbarnhart]

@whedon set 10.5281/zenodo.4134280 as archive

[whedon]

OK. 10.5281/zenodo.4134280 is the archive.

[kbarnhart]

@whedon accept

[whedon]

Attempting dry run of processing paper acceptance...

[whedon]

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

OK DOIs

- 10.21105/joss.00884 is OK

MISSING DOIs

- None

INVALID DOIs

- None

[kbarnhart]

@tylunel this is now in the hands of the JOSS handling Editor in Chief who manages final publication.

[whedon]

👋 @openjournals/joss-eics, this paper is ready to be accepted and published.

Check final proof 👉 openjournals/joss-papers#1864

If the paper PDF and Crossref deposit XML look good in openjournals/joss-papers#1864, then you can now move forward with accepting the submission by compiling again with the flag deposit=true e.g.

@whedon accept deposit=true

[arfon]

@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.02637 joss-papers#1873
1. Wait a couple of minutes to verify that the paper DOI resolves https://doi.org/10.21105/joss.02637
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...

[arfon]

@samuelduchesne, @robinroche - many thanks for your reviews here and to @kbarnhart for editing this submission ✨

@tylunel - your paper is now accepted into JOSS ⚡🚀💥

[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.02637/status.svg)](https://doi.org/10.21105/joss.02637)

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

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

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

[tylunel]

A big thank you to all! I wish you all the best :D