Ctrl+K

Submit Your Python Package for Peer Review - Learn More!

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 …

Agenda#

  • Review check-in:

    • 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:

  • 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.

    • Next steps

      • 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?? pyOpenSci/pyopensci.github.io

*** 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

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)

  • 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.

On this page
Edit on GitHub
Show Source