How do we start? - meeting on 9/29/23

[CarissaGervasi-NOAA]

Meets chat with Adyan Rios, Amy Freitag, Brendan Turley, Molly Stevens, Brittany Troast, David Hanisko, Holden Harris, Carissa Gervasi

• Github wikis could be a good place to host a formal document. Could start with issues or discussions and then migrate that list over.
• how do we get people to use different platforms? The openscapes answer would be to show and not tell
• can copy and paste emails into discussions/issues as well. Good kind of redundancy.
• Also good to tag people to prod them to check Github.

What do we need in order to automate ESRs? Or even just sticky things in any project that we could improve on?

• need to think about the natural modular parts of the project
• standardize file names and folder structure - the S-drive (SEDAR drive) is a great example: https://drive.google.com/drive/folders/1eU3-BnMgLvH3T4zxwh7lR8KZQ6nrEgos
• if data are not on Github, there needs to be a file that denotes where each dataset comes from and who to contact to get it
• Hosting large datasets through Github or linking to them - GitLFS - Holden has worked on this: https://docs.github.com/en/repositories/working-with-files/managing-large-files/configuring-git-large-file-storage
• a wiki could be a good option for tracking the steps of what has been done on a project - at least to re-cap each step of the process
• could start outlining in a google doc so it's more accessible to people
• Github projects - an example from Vivian's group: https://github.com/orgs/SEFSC/projects/7, Github has a project roadmap too https://github.com/orgs/github/projects/4247
• Vivian also has repositories designated just to organizing and not to code
• also might want to protect the main branch to require a review so no one can push to it, someone else has to accept it before it can be merged. Have a meeting and review all the pull requests before changing anything. In the settings go to branches and set up individual branch rules - require a review for a pull request in the main branch
• a section of the document should be collaboration rules to follow (including the above)
• one person could be like the Github manager, who sends out an email from Github (via discussion or issues) that recaps the project and gives and overview of what's next - to kind of nudge people to look at Github
• would be a good idea to start doing project management for ourselves, and then when we try to do it with projects it will be easier
• sidenote - the here package is useful for switching between computers if you need to pull and push to Github
• should also connect issues to commits just put # and the number of the issue in your commit message
• tag with as many things as you can!
• creating quarto books - break into chunks and only read in what you need for each chunk. See Ady's code for example: https://super-telegram-7v6ve7g.pages.github.io/
• how to avoid getting data in all different formats - good idea to come up with a structure, ask that the data come in the same format each time and offer to help if needed
• need to start moving away from excel and start using netcdf or other databases
• coding guidance doc: https://style.tidyverse.org/

How to summarize literature:
https://www.researchrabbit.ai/
https://obsidian.md/
RQDA looks like the R package, and here's a couple good examples: https://bookdown.org/daniel_dauber_io/r4np_book/mixed-methods-research.html
chatPDF