Journal of Open Source Software – Developing a Software Review Community

--- tags: seminar series title: Journal of Open Source Software – Developing a Software Review Community --- :::danger **General info** - **Video connection details:** - Zoom ID: 662 0907 5434 - Zoom password: rse - Zoom invite link: https://uwasa.zoom.us/j/66209075434?pwd=VmRBaFRVOXNKNFRYb1NDRGY5SXZndz09 - **Contact:** - **Date and time**: 27th April 2022, 13:00 CET [convert to your time zone](https://arewemeetingyet.com/Helsinki/2022-04-27/14:00) - **This page:** <https://hackmd.io/@nordic-rse/joss-talk> ::: # Journal of Open Source Software – Developing a Software Review Community ## Ice breaker: Have you published in software journals before? * No, but I'd like to! - not yet, but very much enjoyed reviewing submissions for JOSS - Not yet, but would have been useful in the past! ## About the series This is an event in the Nordic RSE seminar series. * Reminder about starting recording * Find out about future events: * Check https://nordic-rse.org/events/seminar-series/. * Previous seminar talks videos available at [Youtube channel](https://www.youtube.com/channel/UC8OyVrmJEuT2lrH7zXoBrhQ) * Follow [@nordic_rse](https://twitter.com/nordic_rse) on Twitter for announcements * Join the [Nordic RSE stream](https://coderefinery.zulipchat.com/#narrow/stream/213720-nordic-rse) of the CodeRefinery chat * Suggest speakers: * on the [Nordic RSE stream](https://coderefinery.zulipchat.com/#narrow/stream/213720-nordic-rse) * by creating an issue on the [Nordic RSE website repository](https://github.com/nordic-rse/nordic-rse.github.io/issues) ## About the Nordic RSE * Represents Research Software Engineers in the Nordics. * Check out [nordic-rse.org](https://nordic-rse.org/) for other activities. * Registereed as an association in Fall 2021. * To become a member, fill in the [membership form](https://forms.gle/qCVVRGXPi3Hq7inW6). ## Speaker: Arfon Smith Dr Arfon Smith is Director of Product Manager for Data at GitHub, supporting the work of GitHub's data science and data engineering teams. Previously, he founded and led the Data Science Mission Office at [STScI](http://stsci.edu/) in Baltimore – the home of Hubble Space Telescope and other flagship NASA science missions. He was at GitHub once before (2013–2016), helping to bring open source to academia. A lapsed academic with a passion for new models of scientific collaboration, he's used big telescopes to study [dust in space](/assets/thesis.pdf), built sequencing platforms in [Cambridge](http://www.sanger.ac.uk/) and have engaged millions of people in online citizen science by co-founding the [Zooniverse](http://www.zooniverse.org/). He's also been known to publish the [odd paper](http://arxiv.org/find/all/1/all:+arfon/0/1/0/all/0/1) and have also accidentally built a couple of academic journals in my time too. The most recent of which is the [Journal of Open Source Software](http://joss.theoj.org/) (JOSS), a developer friendly, open access journal for research software packages. ## Abstract In this presentation, I'll introduce the Journal of Open Source Software, a community-run diamond open access journal for publishing open source software packages. I'll share some of the motivations behind the journal, how it works, and how the journal has evolved over the last six years of operations ## Ask your questions here - is this a question? - yes, and this is an answer - for "core API documentation", is this at the user level, or developer level? Let's say it's a command line program, is "core API" basically only the command line interface? - A: Yes, but it also depends on the targeting of the software. A CLI program which is more targeted to deeper integrated would need more internal docs, for example. - You mentioned at the beginning the alternative to a JOSS like approach being multidimensional credit. How would you see this possibily playing out? Would this involve more specialised roles in academia?: https://openresearchsoftware.metajnl.com/articles/10.5334/jors.by/ - Thanks - Related to authorship question (if it's not already being answered): any thoughts on the "minimum publishable unit" and requirement for discrete, static outputs. Compared to the typical OSS project lifecycle that is continually moving with people joining and leaving. Any deeper philosophical thoughts here, beyond the obvious? - A: one core philosophy is "if a JOSS paper shows up on someones CV, it means something". This guides a lot of the compromises JOSS makes. - (Sorry - not a question) While we are here, for anyone in Finland, JOSS will shortly be under review to reach JUFO 1 again. If you are interested in publishing in JOSS, you might be able to help by adding it to your "TOP10" in the JUFO portal https://jfp.csc.fi/ . Sign in (top right) -> Search "Journal of Open Source Software" -> Gear (⚙️) -> Add to TOP 10 list