--- 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 ... ## 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: * Do this now if you are game??!! * It will be posted here once merged: * please update this file with your info: * Pull request from chris: * JOSS LANGUAGE HERE: * 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?): * 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?? *** 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: ## 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) * Initial thoughts: * 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.