List of things to do for JOSS publication

[chiaral]

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 made major contributions to the software? Does the full list of paper authors seem appropriate and complete?

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 in code
NOTES:
Let's not touch the .pyf files for now - those should be automatically generated, so I am not sure we should add text to it.
Be mindful of the space before the """ for consistency use """ instead of ''' (although both work just fine)

• copy documentation from bunkers_model_lev to bunkers_pressure_lev @chiaral fortran documentation 1 #37
• adapt documentation from bunkers_model_lev/pressure_lev for CAPE_CODE_model_lev/pressure_lev (for the outer loops routines @chiaral
• SREH_model_lev/pressure_lev lack all documentation @chiaral added doc to srh fortran #46
• stdheight_2D_model_lev/pressure_lev lack all documentation @xebadir Added Documentation to model and pressure level standard height routines #43
• cape_fortran.py lacks documentation @xebadir Added Documentation to CAPE_fortran.py #42
• eliminate cape_numba.py? @chiaral
• Not sure we need to add text to duck_array_ops.py, @chiaral will check
  within core.py
• • _cape_dummy: @chiaral fortran documentation 1 #37
• • _calc_cape_numpy: take out numba reference, add a few comments for better readability @chiaral fortran documentation 1 #37
• • _calc_srh_gufunc: adapt _calc_cape_gufunc @chiaral fortran documentation 1 #37
• • calc_srh: add a few comments for better readability @chiaral fortran documentation 1 #37

Documentation

• Create readdocs Build docs #36 try fixing readdocs by fixing structure #38
• update the readdocs template to extend copyright time range.
• 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?
• Are the test described so that the functionality of the software can be verified? adding documentation to test #41
• 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

• Create Paper folder/md/bib - added draft paper.md #35
• 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?
• Check if compiles here

[xebadir]

SRH Documentation was added - but something seems to have gone wrong with the pull request for it as it didn't get added. Have added as a comment to the documentation set (#38) - but seems to be pull request here: #30

CAPE documentation for fortran I added and had in one of the pull requests - must've screwed something up. Will readdress.

[xebadir]

Added initial statement of need/and purpose to paper - some of this might be better place in summary, but figured I'd run it here so we can edit it. Feel free to modify/edit.
Steps Remaining:

• Add references to this paragraph.
• We need to do some comparisons to the options available in the field, I say we go for Metpy, SharpPY.

[xebadir]

Addressed CAPE_fortran.py documentation in #42
Addressed stdheight_model_lev.f90 and stdheight_pressure_lev.f90 in #43