repo/folder structure

[MandyKarnauskas-NOAA]

On the readme file I think we had agreed to put one folder per indicator in the ESR repo. @imaginaryfish @CarissaGervasi-NOAA - It looks like you both added indicators as separate repos. Do we want to merge those into the mini-ESR repo, each in a subfolder?

[CarissaGervasi-NOAA]

I think we had talked about doing separate repos so that it would be harder to "mess up" an indicator if multiple people are working off the same repo at the same time. But @imaginaryfish @BrittanyTroast-NOAA correct me if I'm wrong. We could definitely try merging it all together.

[BrendanTurley-NOAA]

I think we were unsure how multiple people working on the same repo would resolve conflicts during the commit stage. So we just made separate repos. I thinking asking someone that has more experience or just trial and error on our side could resolve the uncertainty.

[BrendanTurley-NOAA]

@MandyKarnauskas-NOAA @CarissaGervasi-NOAA @BrittanyTroast-NOAA I was looking over the link that Carissa provided in the seaside chat. It talks about Github collaboration and provides some guidance that we touched upon in the meeting.

1. Start a new branch for features; in our case a new indicator
2. In that branch, you should only update that indicator
3. Collaborators should not work on the same branch at the same time to avoid overlapping code or conflicts
4. When the indicator is ready to be added, the team member responsible for it should submit a pull request
5. The request has to be approved by the repo admin before it is merged and the branch is deleted.
6. Do this for all the indicators; there can be many branches and merging should be straightforward if the new code is only for that indicator and is not working on other dependencies within the repo

These seem like straightforward github guidelines for collaboration. And to give credit, this is what Enrique was talking about.

[MandyKarnauskas-NOAA]

Hi Brendan Great job on the lightning talk today! Thanks for doing that. Thanks also for looking into this and figuring it out; this seems like a good way forward. Branching and pull requests are definitely going beyond my comfort zone in github, so maybe we can try it out as a group on our next seaside chat! Mandy

…

On Thu, Aug 18, 2022 at 2:47 PM Brendan Turley ***@***.***> wrote: @MandyKarnauskas-NOAA <https://github.com/MandyKarnauskas-NOAA> @CarissaGervasi-NOAA <https://github.com/CarissaGervasi-NOAA> @BrittanyTroast-NOAA <https://github.com/BrittanyTroast-NOAA> I was looking over the link ***@***.***/the-ultimate-github-collaboration-guide-df816e98fb67> that Carissa provided in the seaside chat. It talks about Github collaboration and provides some guidance that we touched upon in the meeting. 1. Start a new branch for features; in our case a new indicator 2. In that branch, you should only update that indicator 3. Collaborators should not work on the same branch at the same time to avoid overlapping code or conflicts 4. When the indicator is ready to be added, the team member reasonable for it should submit a pull request, the request has to be approved by the repo admin before it is merged and the branch is deleted. 5. Do this for all the indicators; there can be many branches and merging should be straightforward if the new code is only for that indicator and is not working on other dependencies within the repo These seem like straightforward github guidelines for collaboration. And to give credit, this is what Enrique was talking about. — Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGZ7STSCGBFCQ3L75ONF7SDVZ2ALVANCNFSM56JFCAVQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- Mandy Karnauskas, Ph.D. Ecosystem Science Lead, Southeast Fisheries Science Center NOAA Fisheries | U.S. Department of Commerce Office: (305) 361-4592 www.fisheries.noaa.gov