Finalizing Repo for Publication

[wincowgerDEV]

Hey @hsherrod2019, Putting in some time to review the repo before you send it off. Here are some final comments to consider before you submit to JOSS. After you fix these, feel free to submit by following the instructions on the JOSS website.

• remove .DS_Store throughout the repo.
• Add some fun badges to the top of the readme, there are ones that will track the status of your package too.
• Installation should have instructions on how to install from cran
• You can only submit one repo as far as I know so consider if you want to app to live in this repo along with the package or not.
• Joss review is pretty unique, read through the last submission I made to get a sense of what is in store. [REVIEW]: Trash AI: A Web GUI for Serverless Computer Vision Analysis of Images of Trash openjournals/joss-reviews#5136. Most importantly, read the review checklist and use it yourself to review your app before you submit. This checklist is what the reviewers will use to say go no go on publishing your manuscript. If you have a lot of things unaccounted for it will hold up the process, they have to be able to check off everything before you are accepted. [REVIEW]: Trash AI: A Web GUI for Serverless Computer Vision Analysis of Images of Trash openjournals/joss-reviews#5136 (comment). Some things I notice right away, the repo doesn't currently have a CONTRIBUTING.md file, it says it does but the file isn't in the repo.
• Somewhere in the repo and/or manuscript there should be a link to openanalysis.org/one4all which is going to be the long term url for the live test app, this will allow the reviewers and future users to easily test the tool.

I am working off of this manuscript version and will give you feedback below using the line numbers in the margin.
paper.zip

• Line 16; do we want to call the portal "The One4All", I think it's just "One4All"
• Line 17; say graphic user interface instead of portal.
• Line 41; mention that it can also be used locally without a web browser and that low level functions can be used to integrate the package into other apps.
• Watched the video, still very relevant, nice work!
• Figure 4; I think you may want to structure this differently I recommend cropping off the last two empty columns in the image, people know what hashes are so you don't need to show the whole thing but make sure the time and package version are fully open. Explain that the IDs are hashes in the figure caption because most programmers will easily understand that but may be confused by the word ID.
• Figure 6, don't make this a screenshot, make it inline text. If you type out what I can see in that image into the md file, it should be structured appropriately in the manuscript. Same for 7-10. For Figure 12 you can structure it as yaml code and make it inline text instead of a screenshot, e.g. below. This allows the text to be copy and pasted easier and looks more professionally done.

some:
  yaml: data

• Line 72; I think this section should start with some description about how the package relates to the app and the overarching goal or theory behind the package functions.
• Line 83; remove the if(False) from the code. The users just want to see the functions operating by themselves.
• Line 84; I think I agree with Tony, putting the overview section before the app and package section helps the reader understand what they are getting into with the app and package sections. I think figrue 13 should be the first figure the reader sees. Then figure 11 and 12, then the other figures. In this section make sure it is clear that the rules and config files power both the app functioning and the package functions.
• Line 90; sheets or files.
• Figure 11 caption, make sure the reader knows this isn't the only rules sheet you can use, they can adapt it for whatever data they want to use. What you are showing is the example rules sheet and example config, they will be adapting these for their own purposes.
• Figure 13; recommend making the upload data arros both straight, one has a crook in it.
• Line 126; cite chatgpt
• Future goals section; currently reads a bit like a list; recommend working on the flow between sentences a bit.
• Line 129; Microplastic data portal is used here but I think the relationship between it and the one4all needs to be explained somewhere, one4all is the general framework and microplastic data portal is a specific implementation of it for microplastic data.
• Line 128; make data visualization tool and microplastic image explorer proper nouns and cite them with a link to the folders they live in, do the same with microplastic data portal.
• Mention that we can use one4all to collect data for trash ai too and cite the joss paper: https://doi.org/10.21105/joss.05136
• In the introduction, mention that microplastic research is starting to embrace open data and cite this paper: https://doi.org/10.3389/fenvs.2022.912107
• Also should cite this paper as rationale for the microplastic data portal schema: https://journals.sagepub.com/doi/full/10.1177/0003702820930292
• Also cite this paper as rationale for the open source framework being used to create the microplastic data portal in the statement of need: https://pubs.rsc.org/en/content/articlehtml/2023/va/d2va00275b and mention that the data portal was written into law and will be mandated to be used by accredited microplastic labs and cite this policy document: https://www.waterboards.ca.gov/drinking_water/certlic/drinkingwater/docs/2022/mp-hndbk.pdf

[wincowgerDEV]

Finished