Hi, Pariksheet. For #1, I suspect that it might be challenging to publish a paper based on the context you provide, but I do not have a good handle on the specific changes you have proposed. To make your work publishable, you would probably need to at least publish the software and it appears from #2 that piece is not quite done. Bioconductor does not have any recommendations on journals that folks use.
For #2, your best bet is to reach out to the package maintainers via email since not all maintainers use GitHub as religiously as others. Bioconductor team does not generally push changes to Bioconductor software repos; that is the responsibility of the package maintainer. Also, it appears that your issue is from several years ago, so it may have slipped off the radar. To make it easier for package maintainers to accept changes, be sure to provide a formal pull request (not code in an issue) against the current main/master branch on github to minimize maintainer work. Best, Sean From: Bioc-devel <bioc-devel-boun...@r-project.org> on behalf of Pariksheet Nanda <pariksheet.na...@uconn.edu> Date: Wednesday, December 1, 2021 at 5:18 AM To: bioc-devel@r-project.org <bioc-devel@r-project.org> Subject: [Bioc-devel] Merging or renaming a fork, and appropriate journal for package updates Hi folks, I'm wrapping up my dissertation and one of the chapters touches on a summer of patching a Bioconductor package that currently lives as a separate GitHub fork (the list of changes is here [1]). 2 of the questions I've been asked by a member of my committee are whether to: (1) associate a publication with the work, and (2) republish the code with the original or as a separate package. For (1) while I appreciate the traditional unit of research output is the publication, I'm struggling to think of a suitable journal for what essentially is discussion about enhancements and some bugfixes. I've seen R package updates published in the Journal of Statistical Software (JSS) which might be appropriate? I suppose any place that gets indexed on pubmed would work (yes, JSS is part of the NLM catalog [2]). What would you suggest? Perhaps the Bioconductor project collect metrics for publication activity about its packages to get more funding and has some preference? For (2) I would prefer to merge back with the original Bioconductor package. I tried upstreaming an early changeset [3], but besides my issue being open, there are currently 2 other open GitHub issues with no response which makes me wonder if upstream is dead. If that's the case, would someone from the Bioconductor core team be willing to work with me to proxy commit to git.bioconductor.org? I've made some API breaking changes, so I expect I would need to create at least 2 branches: one that can be commit with a deprecation warning for upcoming API breaking changes, and a second branch with API breaking changes to be commit at the subsequent Bioconductor release. Or maybe I would need to create a branch for each feature change; honestly I don't know if that would be or less work but certainly it would be easier to read the git history. Pariksheet [1] https://github.com/coregenomics/groHMM/blob/1.99.x/NEWS [2] https://www.ncbi.nlm.nih.gov/nlmcatalog/101307056 [3] https://github.com/Kraus-Lab/groHMM/issues/2 _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel