---
tags: pyopensci, python
---

# pyOpenSci Meeting Notes - 24 october 2019

## Attendees

* Leah Wasser - Earth Lab University of Colorado, Boulder
* Jenny Palomino - Earth Lab University of Colorado, Boulder
* Luiz Irber - DIB Lab, UC Davis
* Max Joseph - Earth Lab, CU Boulder
* Sasha Kielbowicz
* Ivan Ogasawara
* Nicholas Sofroniew - Chan Zuckerberg Initiative

## Agenda

* Review checkin:
* Pandera is APPROVED / accepted!!
* blog TBD
* earthpy -- under review??
* Next package to review?? -- martin has 2 others as presubmissions. we could begin reviewing
* ping twitter -- for more submissions??
* Max would be happy to work on `rmdawn` (editor)
* Next steps (Max):
* Contact Martin to get a submission PR open
* Find reviewers (ping rOpenSci slack channel)

* Add your name to the website as a contributor please:
* Do this now if you are game??!! https://github.com/pyOpenSci/pyopensci.github.io/blob/master/_data/contributors.yml
* It will be posted here once merged: https://www.pyopensci.org/contributors/
* please update this file with your info: https://github.com/pyOpenSci/pyopensci.github.io/blob/master/_data/contributors.yml
* Pull request from chris: https://github.com/pyOpenSci/pyopensci.github.io/pull/24
* JOSS LANGUAGE HERE: https://github.com/pyOpenSci/pyopensci.github.io/pull/24/files#diff-2143091391115ad4c04dc0658967bad4R65
* pyopensci is trying to improve the ecosystem of python packages...
* max left some comments about what packages might be considered for JOSS...
* Repo metadata specs discussion (Chris?): https://pyopensci.discourse.group/t/finding-a-specification-for-repository-metadata/119
* Codemetapy -- tool to create the json codemeta file...
* we can give people some guidelines to ensure that hte correct metadata are in the setup.py or codemeta.json file
* this migh tbe ideal with pre-commit hooks to update that JSON file which luiz mentioned might be an issue
* This might be an opportunity to contribute back to the codemetapy package.
* Next steps
* come up with the metadata fiels that we want for python packages
* codemeta.json -- do we require this or is it optional ?? rOpenSci recommends using a codemeta.json file.
* Can we provide instructions for setting up a pre-commit hook for users who want to ensure their json is always up to date.
* ropensci makes codemeta a recommendation not a requirement..

## Badges -- do we want a review with a version stamp on it
* for records -- we should specify the version of the package that was review.
* the package badge should have the version that was reviewed...
* how do we deal with the dynamic nature of software dev?
* where should we document the package version that was reviewed.
* we could have reviews have an expiration date? good business model except we are charging ourselves.
* optional:: people can resubmit as an option --
* what is people who submit and have packages approved -- they agree to check in on packages that were already reviewed to see if updates were made.

IDEA: add the version that was reviewed to this file??
https://github.com/pyOpenSci/pyopensci.github.io/blob/master/_data/packages.yml

*** let's add this as a discourse topic ...

Another stream of consciousness thought: Crev is a software review system that I've seen used in the Rust ecossystem. Seems like it could be path forward for 'permanent review' that accounts for new versions?
More info: https://wiki.alopex.li/ActuallyUsingCrev

## Notes for Existing Maintainers
* if we have changes -- the expectations should be that even approved packages should accomodate these updates.
* should we have an area on the discourse site for maintainers?? we need a way to communicate with maintainers over time!
* let's look into this
From Chris:
For the metadata conversation, I think the main question to ask is: do we want to define a minimal amount of metadata that repositories need to have? I don't see anything like this in the rOpenSci packaging guide. We could also try piggy-backing off of fields in the DESCRIPTION file specification. I think most of those files probably already exist in Python's `setup.py` spec, so I think in the short-term we should just tell authors to use that (maybe we also allow pyproject.toml etc, but treat it as an advanced use-case that we don't provide documentation about).
* Pyopensci Blog (Ivan)
* Initial thoughts: https://hackmd.io/RX2nz6WFSm-RjHyOIsmTnA

* Website update: FAQ that explains who we are vs joss
* Other ideas to community who we are as there is some confusion on twitter
* PyOpenSci Google Calendar (Ivan)?
* Maybe would be good to have a public calendar
*
* PyOpenSci introduction slides?
* Is there already any slides that has some introduction about PyOpenSci? It would help us to spread the word in conferences, communities meeting or internally in our jobs.
* NEXT MEETING!!!

## Community feedback
* Not enough activity / things going on... seems quiet
* We could write content on the blog -- about what we are doing!!
* we could get reviewers and editors to contribute too
* Sasha -- something more numerical... numpy pandas, etc!! physics background.