search

openjournals / joss

The Journal of Open Source Software
https://joss.theoj.org
MIT License
1.55k stars 187 forks source link

Pre-submission enquiry #1339

Open HPicatto opened 6 months ago

HPicatto commented 6 months ago

I am currently preparing to submit a paper to the Journal of Open Source Software and intend to publish the accompanying code. The codebase is housed in a private GitHub repository. Due to confidentiality constraints, not all content in the repository can be made public at the time of the paper's publication. To comply with JOSS's open-source requirements, I am considering creating a parallel public repository that includes only the components releasable at this stage. However, I am concerned that this approach might result in the loss of the original commit history and the contributions' authorship records. Could you please advise on the best practices or recommend strategies for managing this situation?

logological commented 6 months ago

Are the individual components that you can publically release under an OSI-approved licence usable and useful without the ones that you will be holding back? If not, then the software may not meet JOSS's core "obvious research application" requirement.

Regarding the authorship records, AFAIK there's no requirement that these take the form of a Git commit log. You could instead credit the authors in comments in the individual source files, and/or in a dedicated text file listing the contributors.

sneakers-the-rat commented 6 months ago

not commenting on scope, but you could fork the repo and use git-filter-repo to remove the stuff you need to keep private, preserving the rest of the repo history

geoHeil commented 3 months ago

@sneakers-the-rat do you have any experience with https://github.com/open-condo-software/gitexporter ?

sneakers-the-rat commented 3 months ago

no, but it seems pretty much like a tool to do what i'm thinking of :). make a fork/copy the repo and modify the remotes. git-filter-repo to remove private files and their histories from the repo and rebuild its history. preserve remaining history and etc. if i wanted to keep them linked then i would probably just automate merges/cherrypicks excluding some directories. if the history is less important in the secondary repo, you could just continually filter, rebuild, and force push to ensure you don't get pollution between the repos.

edit: this is neither legal, security, or official JOSS advice <3