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.