Submit Your Python Package for Peer Review - Learn More!

pyOpenSci Meeting Notes - 6 March 2019#

https://hackmd.io/bn8W_GwFSqaPOBRzovfBvQ

Attendees#

  • Leah Wasser

  • Max Joseph

  • Jenny Palomino

  • Kylen Solvik

  • Chris Holdgraf

  • Luiz Irber

Agenda Items#

  1. Updates from Kylen - cookie cutter & dev guide are ready to go!

    • https://github.com/pyOpenSci/cookiecutter-pyopensci

    • https://github.com/pyOpenSci/dev_guide

Dev Guide#

  • not a lot of new features - link cleanup and the “good better best” options for package dev

  • package release guidelines for PyPI

  1. Meeting with Joss next week!

  2. Review participant list – anyone to add? who can contact whom on the list?

    • https://goo.gl/HNBmfa

    • provide home page of dev guide: https://pyopensci.github.io/dev_guide/intro

      • Leah/Kylen add info to pyopensci.org from dev guide, one pager, etc

      • LEAH WILL create pyOpenSci website and link to pyopensci.org

    • provide levels of involvement

      • minor: sharing of pyOpenSci with colleagues, providing contacts to other packages, coming to BOF at SciPy, add to GitHub organization

      • medium: come to a meeting, advisory board

      • high: become a reviewer

  3. Review package list - which ones should we prioritize? Are there others we should consider

    • https://goo.gl/71uWSa

    • start with Contextily (Danny Arribas)

Package Management Issues To Consider#

rOpenSci:

  • once reviewed, the package CAN be transferred to ropensci repo (As an option)

  • they expect the submitter to maintain the package, but in some cases they provide some level of maintenance and support.

    • example: if package breaks on cran, the maintainer is given 3 months to address the issue; if no response, rOpenSci steps in

    • Something to consider when targeting packages: can we maintain it if the maintainer is not available?

    • Potentially identify as second/backup maintainer

  • that support can be helped along via the discourse channel

  1. Community survey (to support Moore 3-pager). What data would be powerful to speak to the need for pyopensci

  • https://docs.google.com/document/d/1OETzG9OASXIH3WdxyUUl_IDa4Ozfabj6T0HDDSqmkv4/edit

Data That We Could Collect#

  • COMMUNITY CAPACITY / CHALLENGES: why are people writing code and not turning into packages

  • Discoverability: where do people go to find scientific python tools

  • Number of packages with / without testing / docs

  • People who have packages that want to grow a community, but the package is under their name (personal ownership vs community )

  • For people maintaining a package: do you think docs could be improved, complete, is clear enough to cover the range of potential users… – chris can share some data on people’s use of docs —

  • How often do you document your code?

  • How do you document your code?

  • What is the key challenge in documenting code…

  • How and where did you learn to use python?

  • What perspective someone’s docs takes – does it consider the less technical user, for the community etc

  • Are there contributing guidelines? community direction that support building community

  • Do you executable code in your docs and does it run??

  • How many people have contributed to open source, how many people are interested? what are the challenges associated with contributing?

  • TRAINING IDEA: documentation and python dev

From Chris: research on practices around documentation in the open source community.

Here’s a short blog post writeup: https://bids.berkeley.edu/publications/types-roles-and-practices-documentation-data-analytics-open-source-software-libraries

Here’s the paper that eventually came out: https://link.springer.com/article/10.1007%2Fs10606-018-9333-1

Here’s the dataset that we collected: https://github.com/choldgraf/blog-documentation_questionnaire