pyOpenSci Meeting Notes - 24 october 2019#
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
Pandera is APPROVED / accepted!!
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
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 the correct metadata are in the setup.py or codemeta.json file
this might the 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.
come up with the metadata fields 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 accommodate 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
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.
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.