---
tags: pyopensci, python
---

[Link for this hackmd document!](http://bit.ly/pyopensci-bof)
[If you want to join our next community meeting, keep track of this channel in our community discussion room! Login with GitHub and Join us in 3 weeks (i'll post details prior)](https://pyopensci.discourse.group/c/community-chat)

# pyOpenSci BoF ScyPi 2019 - 11 July 2019
Thursday 11 July 2019 6-7pm in Room 204

## Get in touch with the BoF Organizers (twitter handles)

leah: @leahawasser OR [github](https://github.com/lwasser/)
chris: @choldgraf OR [github](https://github.com/choldgraf/)
jenny: [github](https://github.com/jlpalomino/)

You can also ping us in the [community forum](https://pyopensci.discourse.group)!!

## Attendees
Please add your name and contact info to the google sheet below:
> [name=Leah Wasser]Colleagues - i've removed the spreadsheet link for privacy reasons from this document!!
[pyopensci dev guide](https://www.pyopensci.org/dev_guide/intro)

## BoF Agenda
(SciPy scheduled happy hour 7-11pm at Easy Tiger, 709 E 6th St.)

Leah, Chris and Jenny provided a general overview to kick things off:

1. What is pyOpenSci?
2. What's been done so far?
* Check out our website (it's a work in progress!) **pyopensci.org**!
* Also check out [our github org](https://github.com/pyopensci)**
* [Join our community forum](https://pyopensci.discourse.group/)
* Check out our [ongoing reviews](https://github.com/pyOpenSci/software-review) We have had 6 submissions so far and each is in a different state of review / submission.
* Check out our [documentation and processes document](https://www.pyopensci.org/dev_guide/intro)
3. Our goals
4. How to get involved

## Notes from the BoF Discussion With the Group

Leah's notes: licensing came up a lot during the discussion.
we tried to take notes during the session but it was challenging to take notes AND actively participate and lead things. Note to all who are reading this: If you care to add to the points below, please do so!!

Core issues below (leah's notes after the fact and in summary - friends, what am i missing??)

### Licenses OSI vs Others - Should they be required?
1. Licenses can be prohibitive for some who are at organizations that don't support OSI licenses. How do we handle that? NOTE: Ropensci just enforces that rule (see Noam's comment in our community forum)
2. also navigating licenses is confusing. How can we support the community in this effort of picking the right license for them?
3. What should pyopensci require in terms of licenses? See community discussion here: https://pyopensci.discourse.group/t/citations-to-require-or-not-require/51/2

### How Robust should our code review be?

Another set of comments / discussion was around the robustness of the code review itself. some packages have tests and look robust but the code is "messy" and not necessarily efficient. What level of review do we want to have?

Should people dig into code efficiency and software best practices (from a dev standpoint)? Most scientists are not dev's and don't have that level of coding skill? Could education play a role here? or how do we handle the review?

Maybe we could think a bit more about pyOpenSci in terms of discoverability. Maybe we could think about good, better and best coding practices but not set code quality expectations too high given we know scientists cant (and don't want to be) developers in the same way dev's aren't (always but could be!) scientists . Scientists need to do their science!

### Other ecosystems and pyOpenSci - How do we interact / overlap etc?

The question of other ecosystems of packages that are domain specific (astropy as an example) came up. How do we align review processes to allow for pyopensci to support those efforts if they are interested in being involved?

Leah's note: It would be fantastic if we could think about partnerships with groups like this that would facilitate sharing reviewers and review processes in the same way we are collaborating with JOSS.

### Messaging
note that someone looked at our website and thought we were like conda-forge. i (Leah) think we need to carefully consider the messaging on the website. :)

## Begin Community Notes
These notes were taken by jenny and chris et al during the meeting.
It was really hard to take notes and pay attention to those in the room :)

### License Discussion - community notes

* need - help with understanding licenses and how to choose but also how to explain/negotitate this with your home institution
* Not just legal questions but also practical questions for the implications and impact of a license on the community / users
* possible existing examples (sourced from the community? e.g. CZI)
* Need to be aware that universities are concerned about IP
* start discussion on https://pyopensci.discourse.group/
* [duecredit](https://github.com/duecredit/duecredit) package - useful for software citation, may be worth recommending
* for authors who'd like credit/citations/etc
* potential conda channel for pyOpenSci?
*
> [name=Leah Wasser]we prob don't want a new channel as this would be messy but another idea was poised about just having metadata associated with pyopensci affiliation. i think this is where a badge in the readme could be good
* thoughts about decision-making process for accepting packages with affiliated packages (e.g. nested packages)?
* Show of hands - it seems that code review is important to this community
* style
* scientific robustness
* usability
* What are the best practices that pyOpenSci wants to promote?
* is it about making sure that the package continues to work?
* are these packages supposed to be examples of best practices for writing code?
* decisions on what is "good" code?
* is there a related goal of trying to diffuse "good" coding skills across the community?
* good, better, best plus education can help
* is good documentation enough, or does the code really have to be "really good"? packages are developed for different reasons, etc
* e.g. do users really care whether a package adheres to PEP 8
*
* Long term issues: AstroPy noted challenges around previously-reviewed packages growing stale or becoming incompatible with dependency changes
* astropy (eric t.) also mentioned that they have ongoing re-review. they re-review every few years and only have reviews done by the core astropy leads which is taxing. astropy could be interested in sharing our infrastructure (eric is going to followup with his group about this)
* what about packages that require infrastructure (e.g. eg a cluster, hpc cloud computer)? Who pays for the testing?
* rOpenSci has an official statement about not reviewing packages if there is an explicit challenge like this
* ropensci considers review and community capacity and will turn away packages that they don't have the capacity to review.

## Roles (contribute http://bit.ly/pyopensci-bof)

Please note that we are trying to define roles in pyOpenSci to allow people to get involved. Right now the roles below are based upon the ropensci infrastructure. we've discussed them several times in our community meetings. however we did not discuss roles in detail during our BoF.

### Role Definition Revisited (please feel free to edit this or leave comments on the roles!! This has been an ongoing discussion)

Starting with the [rOpenSci structure](https://ropensci.org/about/) but we may want to adjust accordingly. And of course the time commitment can really be flexible but just trying to give folks a sense of time that might be associated with each role.

### Leadership (3-5):
* Responsible for making final decisions about the direction of POS
* POS
* Communication: weekly / bi weekly, slack, discuss private forum (Chris H can help us set this up i think??, emails)
* Gitter https://gitter.im/pyOpenSci/

### Community, Social Media, Outreach, Website (?future or someone doing part):
Ropensci has an outreach person. I wonder if we could start with anyone who had
just a bit of time to help us start to build an online presence. Potential for a fall intern...
(Neil: we could also apply to https://www.outreachy.org/)
* website
* twitter
* spreading the word (easy peasy just tell people about us)

### Editors in Chief (2-3?):
* What about defining this initially as editors ?
* All editors will be pinged when a new package is submitted. Then based on workload, one will be assigned to it as an editor.
* Luiz: I would like to be in this group, to eventually bootstrap the bioinformatics area =]
* _Depending on load, this might be an area Carson could contribute as well_
* Martin

### Pool of Associate Editors (8+)
A group of people who are willing to fill the editor role for a single package for a shorter duration of time throughout the year. Associate editors will be pinged by the core editor group to assess their time availability and expertise relative to serving in an editor capacity for a particular capacity. Their time can be more limited than the time required of the editors in chief.
* General contribution load: 2-4 packages a year?? (_just throwing out a number here_)

NOTES: JOSS model: Joss has a small number (4) of editors in chief. each week one is on call and responsible for everything. has a larger pool of associated editors. this might work better if there is a larger community who want to jump in here and there.

### Advisory (4*):
#### Responsibilities:
* Provide feedback & guidance regarding the direction of POS
* Spread the word about POS
* Communication: every other month / quarterly? meetings??
---
* Carson (external/industry advisor)
* Neil

### Funding & Business Development

This role helps guide the direction we go in terms of funding the organization. Ideally this person has expertise working with various funding types and connections in the community. But this role could also be someone who is keen to help us write proposals -- 1 pagers 3 pagers etc that go to organizations that may be willing to fund us.

---
* Neil ??

* Create a shared hackmd and post it on the discourse forum.
* for onboarding -- we want name, email, github username, what they work on (what domain they are in) what they may want to contibute??
* Joss has a google form that they can submit if they want to be a reviewer.
* [JOSS reviewer list](https://docs.google.com/spreadsheets/d/1PAPRJ63yq9aPC1COLjaQp8mHmEq3rZUzwUYxTulyu78/edit?usp=sharing)
* How does rOpenSci keep track of / pick / rotate reviewers?
* joss has a dashboard to keep track of reviewers / reviews. might be worth chatting with Arfon about how that works.