pre-publish methods should be private?

[7yl4r]

Good point raised by @mjm8 . Maybe this repo should be private?

I like leaving it public for collaborative, easy-of-use, and (potential future) cost reasons. However we can easily switch it to private once we have something in here we don't want public.

"DAG" definitions in general are going to be hard for someone outside of IMaRS to use without our help because they only describe the jobs at a high level. We can always develop individual software packages separately and then use them from within airflow (like the wv2-processing scripts).

[mjm8]

Perhaps we could have one folder for a public repository that is non-active (i.e. unused by us in practice), and another, private, folder containing the scripts we actually run, and that we can modify as needed. Does that make sense? In other words, copy all of the scripts we're currently using into a "public" folder, and make the current folder private.

…

On Thu, Aug 2, 2018 at 4:11 PM, Tylar ***@***.***> wrote: Good point raised by @mjm8 <https://github.com/mjm8> . Maybe this repo should be private? I like leaving it public for collaborative, easy-of-use, and (potential future) cost reasons. However we can easily switch it to private once we have something in here we don't want public. "DAG" definitions in general are going to be hard for someone outside of IMaRS to use without our help because they describe the jobs at a high level. We can always develop individual software packages separately and then use them from within airflow (like the wv2-processing scripts <https://github.com/USF-IMARS/wv2-processing/>). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#80>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Af6OKHtk2InQjwL-Uvm7QrHQ6reugY6Qks5uM1zzgaJpZM4Vs7kX> .

-- Matt McCarthy, Ph.D. Biological Oceanography College of Marine Science University of South Florida 140 7th Avenue South St Petersburg, FL 33701-5016 727-553-1186

[7yl4r]

Ok. I think I may have misinterpreted your concerns.

You are saying that we don't want to publish something before it is done so that we can avoid sharing confusing or incomplete work?

This is handled (sort of) by "branches" in git.
The "test" branch (aka "development" branch) is for works-in-progress, but the "production" (aka "stable") branch is the public-facing version.

Both branches are publicly visible, but if we are sharing publicly we link to the "production" branch.
This is a pattern common to most software development efforts.

For this repo the branches are:

• test/development is called "master"
• production/stable is called "prod"

The branch names could easily be changed.

A good visual of how the branches are related is the "network graph".
Here is a more complex example of branches: nasa/CMR net graph. There they have dev branches for fixing particular issues which get merged into master (their production branch) after the issue is fixed. Then periodic numbered release branches pull from the master.

Does this address your concern or am I still missing something?

[mjm8]

I don't want anything publicly available until after we've published the manuscripts that came from it. So if we're done editing a script, but haven't published that work yet, that script should still be private, even if we are routinely using it. Otherwise these scripts will be scooped by people who beat us to publication. Once we publish that work, we will discuss which scripts should be made public. How does that sound? So why not copy everything we have now into a folder that is publicly available for download, and make the current working folder private as we edit and utilize?

…

On Thu, Aug 2, 2018 at 4:44 PM, Tylar ***@***.***> wrote: Ok. I think I may have misinterpreted your concerns. You are saying that we don't want to publish something before it is done so that we can avoid sharing confusing or incomplete work? This is handled (sort of) by "branches" in git. The "test" branch (aka "development" branch) is for works-in-progress, but the "production" (aka "stable") branch is the public-facing version. Both branches are publicly visible, but if we are sharing publicly we link to the "production" branch. This is a pattern common to most software development efforts. For this repo the branches are: - test/development is called "master" <https://github.com/USF-IMARS/imars_dags> - production/stable is called "prod" <https://github.com/USF-IMARS/imars_dags/tree/prod> The branch names could easily be changed. A good visual of how the branches are related is the "network graph <https://github.com/USF-IMARS/imars_dags/network>". Here is a more complex example of branches: nasa/CMR net graph <https://github.com/nasa/Common-Metadata-Repository/network> Does this address your concern or am I still missing something? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Af6OKIL-SlWja8RXJd_3otMDo3Or6jY7ks5uM2TBgaJpZM4Vs7kX> .

-- Matt McCarthy, Ph.D. Biological Oceanography College of Marine Science University of South Florida 140 7th Avenue South St Petersburg, FL 33701-5016 727-553-1186

[7yl4r]

I see. You are correct then.

To maximize protection from getting scooped we should make this repository private and release publicly elsewhere.

I do maintain that this repository will not contain anything worth scooping, but I will make it private to be on the safe side. I just need to check that @IMaRS-bot is set up on the nodes first.

[mjm8]

Sounds good. Thanks!

…

On Thu, Aug 2, 2018 at 5:59 PM, Tylar ***@***.***> wrote: I see. You are correct then. To maximize protection from getting scooped we should make this repository private and release publicly elsewhere. I do maintain that this repository will not contain anything worth scooping, but I will make it private to be on the safe side. I just need to check that @IMaRS-bot <https://github.com/IMaRS-bot> is set up on the nodes first. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/Af6OKCuJOVrQzJ_ZIYbTd_GAn2mrPvt-ks5uM3Y1gaJpZM4Vs7kX> .

-- Matt McCarthy, Ph.D. Biological Oceanography College of Marine Science University of South Florida 140 7th Avenue South St Petersburg, FL 33701-5016 727-553-1186