Hello, https://www.researchgate.net/publication/305342071_Crowdsourcing_biomedical_research_Leveraging_communities_as_innovation_engines
cites our "Community-driven development for computational biology at Sprints, Hackathons and Codefests" paper https://www.researchgate.net/publication/268977937_Community-driven_development_for_computational_biology_at_Sprints_Hackathons_and_Codefests Now, being cited in a Nature Reviews Genetics paper is something that I presume we all appreciate. This other gang of four (the one first pointing me to the first gang of four I refer to gets another glas of water at our next sprint), and senior author Gustavo in particular, are known for the DREAM challenges (http://dreamchallenges.org/people/). I attended their preconference meeting at the ISMB in Dublin. I am bit shocked that our Sprints paper is already from 2014. But sure, it was right after the Berlin Codefest that synced with the 2014 ISMB. Debian Med has changed quite a bit since its last Debian Med centric publication. I am not sure about what what exactly should go into any upcoming description of ours, but I presume we all agree there should be an upgrade and we should aim at some higher impact factor than we modestly did in the past. We have: * exchange and integration with bio.tools - this we need to complete and give examples on how it is used * common-workflow-language - a description on how Debian Med adds value would be nice * minimal redundancy between software installations and community as a distinctive effort over linuxbrew * community communication with upstream developers, here we can cite above Sprints paper again :o) * continuous integration checks that ensure nothing goes wrong when removing the redundancy * the statistics of Andreas and popcon.debian.org that formally describe our development * scientific reproducibility with snapshot.debian.org * commerical HPC support via Roland * ? Also, I felt that we should think about describing how having software with Debian+Ubuntu+mint helps with using cloud services. I do not only mean the IaaS providers like Amazon+friends. There are also tantalising environments like Cloud9 (https://c9.io) that allow you to apt-get install stuff and I have not yet figured out what this means to us. Something that is intrinsically difficult to address is the different expectation for scientific and system software for when this should be updated. I only run testing or unstable, never stable, except for mere file servers, possibly. So, for all virtualised efforts (remotely on clouds or local with Docker or VirtualBox) I presume we all agree that testing (i.e. post CI) or unstable (you do the CI effectively yourself) is just fine. I hence want to motivate that we find a way to get Debian Med auto-transformed to one of the upcoming flat/snappy user-installable package formats. This way we'd be basically distribution-version-less happy and it would successfuly fight me personally from contributing more to linuxbrew. Chroot environments are a near miss. What we should also think more about are ways to invite non-maintainers to contribute. With Linuxbrew it is so easy and inviting to come up with new versions of whatever is missing, it almost hurts to see how we are doing it. I know, we are talking about any github-clone featuring our package instructions for ages, but even when we change things in our package repository, the next invocation of apt-get install still does not have any newer version, which it would with linuxbrew because we would have worked on a local clone of the packaging instructions and those are executed directly, not from any abstract source/binary package. So, we have some room for improvements, still, but nonetheless, we make the world a better place and should tell the same about it in an updated paper. I'll be at the ECCB in September - is anybody else on this list going? Best, Steffen
