Jims Package Recommendations

[grantdadams]

Thanks again for chatting about Rceattle yesterday, I'm super excited about Rceattle for several reasons including:

1. Jump-start for MICE models by sharing code, with potential to export to other LMEs or science centers, and for AFSC ensembles;
2. Easier ability to share code for real-use AFSC assessments, for use by other programs to test inputs (e.g., RPA, etc);
3. Ability to test new options for larger uptake by AFSC assessors.

I left unsure if there's any place I can document my suggestions for additions, or process by which you plan to "filter" input. Do you have a place where those should be recorded, like in the issue tracker?

But at first glance:

1. I think its important to have the feature-set documented as you go, so that later rebuilds (or other people simultaneously doing this in other regions) can see what features you think are vital. You can see the feature set for VAST here: https://github.com/James-Thorson/VAST/tree/development/manual, see "List of Features"

2. I also think its important to reposit both example data sets AND results when running with those data as .rda files, so that you can use it as a "checksums" test that new updates don't break backwards compatibility. I wish I had more of these myself! but you can see some here: https://github.com/James-Thorson/VAST/tree/master/tests

3. I highly recommend using semantic-version-numbering for numbered releases, see e.g., https://github.com/James-Thorson/VAST/releases. These can then be used by authors to re-load old versions, and also easily refer to specific releases.

4. I recommend listing your naming and notation conventions somewhere in the documentation and sticking with those. I try to use notation conventions from: https://besjournals.onlinelibrary.wiley.com/doi/full/10.1111/2041-210X.13105 and Ropensci code conventions; it seems like you're already using something a bit like Ropensci naming conventions (verb_noun for functions)

5. It seems like you're using different branches for development etc which is good. I recommend talking early with Christine Stawitz about toolbox standards and starting a discussion of when it might be worth getting up there.

6. It sounds like you have a developers team of you both + Ianelli + Kerim. So maybe that's the "steering committee" that also decides on what external advice to accept or ignore. So I'm glad to understand that more.