I agree with Kasper. I generally like the approach of getting the software
out there sooner rather than later. Especially if the paper you are talking
about is a method paper about the software algorithm, rather than a result
paper. In that case, getting it into a public, DOI'ed repository quickly
protects you from being scooped (if that is a concern of yours, it's
generally not a super large one of mine).
This will also give the community and package reviewers a chance to give
you feedback, resulting in the paper being written about a better piece of
software when it does happen. Just like manuscripts, no (ok, *vanishingly
few *but almost surely not yours or mine) software is perfect after its
first development pass, so i'd strongly advise you not to think of your
software as 'complete' the moment you hit submit. Consider it an important
part of the development process.
On Wed, Apr 4, 2018 at 4:34 AM, Kasper Daniel Hansen <
> This is a subjective question. As a paper reviewer I like to see the
> package accepted. That increases trust. As a package reviewer I like some
> idea of what the package actually does, so a statement like "we implement X
> which is described in (XX, in preparation), is also irritating.
> Unless you're trying to not show anything prior to publication (which
> happens) I like submitting the package first.
> On Wed, Apr 4, 2018 at 12:31 PM, Kenneth Condon <roonysga...@gmail.com>
>> Hi Gabe & Levi,
>> Here is my current plan:
>> 1 - complete the requirements checklist (
>> 2 - get feedback the in-house NGS team, and then from the rest of in-house
>> bioinformatics (others who use R more may spot some issues)
>> 3 - set up pull requests release on github for community testing
>> 4 - advertise github repo on bioconductor and biostars forums
>> 5 - compare to other packages
>> 6 - write paper (decide which journal)
>> 7 - have submission of paper + package ready for October deadline.
>> Regarding the sequence of events - do other authors usually release on
>> bioconductor before submission of a paper or at the same time?
>> What would you recommend?
>> Thanks for the help
>> On Tue, Apr 3, 2018 at 4:56 PM, Gabe Becker <becker.g...@gene.com> wrote:
>> > Indeed, and to be a bit more explicit about Levi's point, you *can*
>> > publish your package to bioconductor any time after the deadline, it
>> > simply go to the development repo for ~6 months, which, as he points
>> > may not be a bad thing if it's not ready yet.
>> > On Tue, Apr 3, 2018 at 8:06 AM, Levi Waldron <
>> > wrote:
>> >> On Tue, Apr 3, 2018 at 5:32 AM, Kenneth Condon <roonysga...@gmail.com>
>> >> wrote:
>> >> > Have I missed the deadline for the latest release? I have created a
>> >> > package, that runs great but there are a number of errors still from
>> >> CMD
>> >> > check that I am sorting out.
>> >> >
>> >> > This is my first R package so I'm not sure if development is far
>> >> > along, although I suspect it might be.
>> >> >
>> >> IMHO, when you're not sure a package is mature enough, and especially
>> >> a
>> >> first package, it's actually better to miss the release deadline and
>> >> bioc-devel users test your package for 6 months before entering the
>> >> release
>> >> cycle. Making significant bug fixes and other changes becomes more
>> >> complicated and more of a pain for you and your users once you are in
>> >> release...
>> >> [[alternative HTML version deleted]]
>> >> _______________________________________________
>> >> Biocfirstname.lastname@example.org mailing list
>> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>> > --
>> > Gabriel Becker, Ph.D
>> > Scientist
>> > Bioinformatics and Computational Biology
>> > Genentech Research
>> [[alternative HTML version deleted]]
>> Biocemail@example.com mailing list
Gabriel Becker, Ph.D
Bioinformatics and Computational Biology
[[alternative HTML version deleted]]
Biocfirstname.lastname@example.org mailing list