# 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

## Cookie Cutter

Luiz: cookie cutter is a good start. we can iterate in the future as more people become involved

* pytest only for testing
* removed non open source licenses
* worked with chris -- documentation updates
* Need other testers to ensure this will work for people!

## Dev Guide

* not a lot of new features - link cleanup and the "good better best" options for package dev
* package release guidelines for PyPI

2. Meeting with Joss next week!
3. 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
4. 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


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