Investigation group idea: collaborative workflow

[k-doering-NOAA]

To me, I think it seems important to set up FIMS in a way that makes the collaborative coding/contributing experience as painless as possible. I think this is addressed in the developer's experience requirements, but to me it really seems non-negotiable and something that needs to be set up at the begining of the project.

I think it would make sense to form an investigation group that could start brainstorming how to set up the tooling and collaborative workflow so that everyone involved in FIMS can successfully contribute, whether they are contributing ideas, documentation, code, code reviews, or something else.

This idea has some overlap with architecture/software platform and testing also - not sure if these ideas should just be addressed within those groups instead?

[Andrea-Havron-NOAA]

In the architecture investigation, I am ranking platforms with respect to developer experience. While similar to what you mention here, I don't specifically focus on setting up optimal collaborative workflows. I think this topic is worthy of its own investigation and could be informative to the architecture study.

[Bai-Li-NOAA]

Agree! I think this topic is worthy of its own investigation. I am interested in seeing more templates/step-by-step guidelines on how to report and fix a bug/issue, how to make changes and commits, how to make a pull request and merge the request, etc. 

How to add a new module, a new dataset, or a new test to the existing modeling systems is also an interesting part of a workflow. This rodent forecasting project has a vignette that talks about the steps for sandboxing a new model and a new dataset. It allows people to have two levels of model/data-adding. One is basic exploration working locally on a "development space", and another level is adding new model/data to the existing project's production pipeline in a "production space". 

[Rick-Methot-NOAA]

In response to Bai regarding adding new modules and data sets relevant for that module: This has been a long-standing discussion in the Stock Synthesis team. We simply have too many features to have a data set to test each combination of all possible feature options. Even if we did, updating all those datasets to work with the newest executable (if there is a mandatory I/O change) would be prohibitively challenging. So, some sort of easily automated approach to updating seems necessary; Kathryn can comment regarding how she does the updating currently for our 20+ test cases. We also have tried to have sufficient diversity in our testing library such that all major configurations get used when a test is run; but edge cases keep tripping us up. Getting a beta version out to the user community turns out to be a major part of testing! Rick

On Tue, Aug 17, 2021 at 6:12 AM Bai Li - NOAA @.***> wrote:

Agree! I think this topic is worthy of its own investigation. I am interested in seeing more templates/step-by-step guidelines on how to report and fix a bug/issue, how to make changes and commits, how to make a pull request and merge the request, etc.

How to add a new module, a new dataset, or a new test to the existing modeling systems is also an interesting part of a workflow. This rodent forecasting project has a vignette that talks about the steps for sandboxing a new model and a new dataset https://weecology.github.io/portalcasting/articles/adding_model_and_data.html. It allows people to have two levels of model/data-adding. One is basic exploration working locally on a "development space", and another level is adding new model/data to the existing project's production pipeline in a "production space".

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS-planning/issues/17#issuecomment-900286706, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPV4ICYCJ2U4K7ANBDIDHDT5JN5BANCNFSM5BWOVLCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[k-doering-NOAA]

Based on this discussion, I'm definitely agreeing it seems like a topic that could merit its own group (or if not enough people, could become part of the architecture discussion).

I think answers to these types of questions could be helpful (beyond the points brought up above, which are great!):

• How does a typical developer add code and contributions? What requirements must they meet for code to be added to FIMS? What about other groups, like a member of FIMS that usually doesn't contribute code, someone at NOAA not really involved in FIMS planning/development but has something contribute, someone outside of NOAA?
• Should there be separate production/development versions (thanks @Bai-Li-NOAA for bringing this up!) and how could this be set up on github (or other collaborative platform for git repos) in a way that's approachable for folks who don't use git frequently?
• How can documentation be written to make clear how contributions can be made and to foster an active community of contributors (e.g., how do we encourage bug reports?)?

[Rick-Methot-NOAA]

Other NOAA Modeling projects definitely take and encourage a production version and a development version, and with the development version open to the external community. Check out the github sites for the MOM6 ocean circulation model and even bigger, the Unified Forecast System (global weather model).

On Tue, Aug 17, 2021 at 9:31 AM Kathryn Doering @.***> wrote:

Based on this discussion, I'm definitely agreeing it seems like a topic that could merit its own group (or if not enough people, could become part of the architecture discussion).

I think answers to these types of questions could be helpful (beyond the points brought up above, which are great!):

• How does a typical developer add code and contributions? What requirements must they meet for code to be added to FIMS? What about other groups, like a member of FIMS that usually doesn't contribute code, someone at NOAA not really involved in FIMS planning/development but has something contribute, someone outside of NOAA?
• Should there be separate production/development versions (thanks @Bai-Li-NOAA https://github.com/Bai-Li-NOAA for bringing this up!) and how could this be set up on github (or other collaborative platform for git repos) in a way that's approachable for folks who don't use git frequently?
• How can documentation be written to make clear how contributions can be made and to foster an active community of contributors (e.g., how do we encourage bug reports?)?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/NOAA-FIMS/FIMS-planning/issues/17#issuecomment-900448240, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABPV4IHLJKW4LTAUJQ5KR43T5KFG3ANCNFSM5BWOVLCQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&utm_campaign=notification-email .

[k-doering-NOAA]

Other NOAA Modeling projects definitely take and encourage a production version and a development version, and with the development version open to the external community. Check out the github sites for the MOM6 ocean circulation model and even bigger, the Unified Forecast System (global weather model).

I think it is standard practice in a lot of other systems, too (like data processing/storage), so hopefully there will be a lot of examples to follow!