---
tags: pyopensci, python
---

# pyOpenSci Meeting Notes - 9 May 2019

https://hackmd.io/ewQZvQdFSteXh3OXJIJPdw

## Attendees

* Leah Wasser (Earth Lab, CU Boulder)
* Kylen Solvik (Earth Lab, CU Boulder)
* Lindsey Heagy (Berkeley)
* Neil Chue Hong (Software Sustainability Institute)
* Jenny Palomino (Earth Lab, CU Boulder)
* Max Joseph (Earth Lab, CU Boulder)
* Luiz Irber (UC Davis)
* Leonardo Uieda (University of Hawaii at Manoa)
* Noam Ross (EcoHealth Alliance / rOpenSci)

## Agenda

1. More new colleagues!
2. JOSS update -- partnership is in place!!
3. SciPy bof submitted!!
4. Review process -- where should the review template live to make it easier for people to find?
1. Create issues in package repo ala JOSS or do it all in the software-review repo ala rOpenSci? https://github.com/pyOpenSci/dev_guide/issues/17
2. Currently sits: https://www.pyopensci.org/dev_guide/appendices/templates.html#review-template
* NEIL -- didn't have an issue finding the template. he'd like to see it in the email AND the comment for the review ... so maybe the editor should do this OR Whedon the bot could do this??
* also in the guidances for reviewers and authors...
* https://pyopensci.discourse.group/
* Luiz: maybe create a review issue template, so the checklist doesn't need to be copied? example: https://github.com/datrs/hypercore/tree/master/.github/ISSUE_TEMPLATE
* have one template for review, another for pre-review, and submissions
* Kylen: We have issue templates for submission and pre-submission. Haven't made one for review because they are comments on existing issues, not new issues by themselves. Is there the option to create a comment template?
* Luiz: I don't think there is... sorry, I was thinking on the JOSS structure (where there is a pre-review and a review issue)
* Kylen (again): You can create saved replies in your own account, but not sure if you can create them on the repo/organization level. I'll keep looking into this.

5. Whedon the bot update / Discussion with Noam about rOpenSci goals & efforts
* [rOpenSci Requirements based on a discussion with Arfon](https://hackmd.io/KxM9HK-eSo-x2nkTOSBeow)
* [Notes from meeting with Arfon](https://hackmd.io/Vw2tyNxZQ5-PItkQFTZqhA)
* NOAM takes the floor:
* Ropensci is talking with Arfon as well. JOSS requires a zenodo doi, they want to ensure the version of the package is accepted is linked to a DOI. DOI's are relevant for JOSS but not explicitely tracked in the ropensci process. The DOI for teh final version in the review is used for JOSS.
* ropensci has a diagnostic package that they use to provide some feedback and it's run on submission in a standardized envt... and the bot will be able to spit out results
* They've had a few scenarios where authors have requested an updated review. It's not practical... because it's resource intensive...
* [Current whedon functionality](+)
* * one we get feedback on the bot, send all of the input to karthik, arfon and noam
* Linsdey -- dashboard with whedon -- allows them to look at editor and reviewer loads, etc etc... that is super helpful. JOSS backend might be a google sheet.

## JOSS vs rOpenSci Review process
* JOSS process follows PLOS -- minimal requirements whereas rOpenSci is more intense process.
* LEO: JOSS for example doesn't have (automated) test requirements. it's valuable for us to be more strict
* LUIZ: especially considering curating packages...we want to give our stamp of approval

## Funding Opportunity support via rOpenSci

* Ropensci applied for funding -- to support methods focused packages
* aggregate, automate and document current ropensci processes
* how to create a review community
* automation
* creating reviewer databases
* Send reminders, etc - create tools to handle this and make it easy for other groups to adopt
* Write standards for software in a way that can be tested
* (Luiz) semi-relevant: https://www.thoughtworks.com/insights/blog/fitness-function-driven-development

* Noam needs a letter of support by May 16.
* One pager: https://docs.google.com/document/d/1kZStdLA98TvFe1_0r0IuSBPyg-PL_32wBvw599Zu4NM/edit
* Support:
* +1000 (luiz)
* :tada: Lindsey
* This addresses a huge gap! +1 Max
* +1 leah !!
* :thumbsup: Jenny

6. First package review checkin: Jenny, Neil, Chris (might not make it)
* leah followed up with filipe. she will ping him again:)

7. Second package review -- [earthpy](https://github.com/pyOpenSci/software-review/issues/3)
* Editor needed: Luiz!!
* Luiz: I did, and would love to be the editor =] --- YAY!!
* Reviewers:
* Carson Farmer (check in with him again)
* Kylen S.
* Levi Wolf (of PySAL, Contextily, and Geopandas) volunteered to be a future reviewer
8. New pre-submission inquiry! [pacifica](https://github.com/pyOpenSci/software-review/issues/2)
* Please provide your feedback on whether we should encourage a submission in this document (be mindful this document is public so if you are not comfortable with that please email us or speak up during our meeting!!)
* More info might be helpful here - the provided link is https://github.com/pacifica but, that has many repos. It might be easier to review if we are reviewing one repository, rather than many repositories.
* The core repository is a Docker compose pipeline (https://github.com/pacifica/pacifica) composed of submodules, each of which is a package - maybe this would be hard to review?
* rOpenSci has onboarded suites of tools but also didn't accept a tool that wrapped around another language... given that would be outside of our expertise..
* a shiny app would not be accepted nor a larger system
* LUIZ: pyopensci is more for lego blocks vs .. do we watn to curate small packages or packages that can work together...
* NOAM: there are different ways that a python "package" could be presented. we might want to define what a package is and means...
* LEO: for python there is a standard packaging schema but you could have say a web app... that has a different structure. PAcifica does seem to have a set of a few sub packages that have stndard python packages..
* Luiz: would we consider jupyter for example...
* NEIL: we need to really define the scope of what creates a package and what we will review... perhaps we need something that refines the scope, the type of package, how it sits within a larger envt, etc...

TODO: how do we dfeine the scope of a what a package is....

9. Development glossary -- anyone want to contribute and where should we place it? https://github.com/pyOpenSci/dev_guide/issues/8

10. PyCon open space feedback (Luiz)
- a quickstart (condensed guide)
- nanopore interested in contributing software, might be a good venue
- EBI (European Bioinformatics Institute) has lots of open source packages, but not much marketing
- .org website feedback
- Link discourse to the main page of pyopensci.org: https://pyopensci.discourse.group/
- .org website -- too overwhelming for someone new??

- accept submissions to pyOpenSci that are already JOSS papers?
* another fast track?
* makes sense for the "curated packages" approach
- requirements?
- code coverage? (no)
- ropensci doesn't have a % coverage but automated testing and CI is required. The code coverage is required to be reported. if the coverage is low, you have to justify it to the editor...
- stable versions (semantic versioning?)
- Link to current reqs: https://www.pyopensci.org/dev_guide/packaging/packaging_guide.html#overview

## To Do Takeaways - For Everyone
1. Please review the whedon bot requirements and give us feedback
2. email to arfon, karthik and noam about whatever our requirements end up being for whedon.
3. Please review the pacifica submission and provide your input
4. TODO: how do we dfeine the scope of a what a package is....
5. LUIZ will begin the editor process for review of earthpy