pyOpenSci Meeting Notes - 30 May 2019
pyOpenSci Meeting Notes - 30 May 2019#
Leah Wasser (Earth Lab, CU Boulder)
Martin Skarzynski (National Cancer Institute and FAES)
Luiz Irber (UC Davis)
Neil Chue Hong (Software Sustainability Institute, University of Edinburgh)
Filipe Fernandes (IOOS/NOAA)
Levi John Wolf (University of Bristol) – core geopandas dev & pysal!
Max Joseph (Earth Lab, CU Boulder)
Carson Farmer (Textile.io)
Leonardo Uieda (U of Hawaii)
Chris and Kylen are traveling / in meetings today
Communication – What is the best way for us to communicate and who wants to be involved in what types of communication? Some options
discuss could be the way to go for this
private group in discuss …
we might separate editorial vs governance in the future..
conda-forge has subchannels - github and discuss
teams on github…
Slack – unless you pay for it - you don’t have a record of messages. There is a 10k message limit.
For now we will focus on discuss and github!
What do folks prefer?
Governance / define roles and associated task timelines (is this in the dev_guide)
Editor in Chief (Leah, Luiz, Martin, Carson?) -
Associate Editors (Carson?) -
Reviewers (Filipe, Martin, Carson)
How do we track new reviewers?
Is there a concise, “how to start a review” document?
Social media & Website
Role Definition (please feel free to edit this or leave comments!!)
Starting with the rOpenSci structure but we may want to adjust accordingly. And ofcourse the time commitment can really be flexible but just trying to give folks a sense of time that might be associated with each role.
Responsible for making final decisions about the direction of POS
Communication: weekly / bi weekly, slack, discuss private forum (Chris H can help us set this up i think??, emails)
Editors in Chief (2-3?):#
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 hy hy hy hy hy h
Depending on load, this might be an area Carson could contribute as well
Pool of Associate Editors (8+)#
Associated editors are a group of people who are willing to fill the editor role for a single package at a 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 of the editors in chief.
General contribution load: 2-4 packages a year?? (just throwing out a number here)
NEIL / LEO – 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.
Responsible for providing feedback & guidance regarding the direction of POS
Spread the word about POS
Communication: every other month / quarterly? meetings??
Carson would be happy to be an external/industry advisor
Neil feels this is probably the best role for his input, but also happy to help out with funding
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.
Available to review software packages (no more than 1 at a time and x a year or something manageable)
Communication - as packages come in that may be in your area of expertise
Time: as you have available
filipe would like to be a reviewer
leo would too
Neil happy to do occasional reviews
I just started with a number from ROS.
Community Members, Supporters (∞):
Attend community calls (monthly?)
Who is interested in interfacing with RopenSci on their slack channel
email@example.com martin is interested in interfacing with the ropensci communications
Funding – numfocus support vs moore funding#
focusing on numfocus for funding / support in kind. they are looking into many options
Filipe’s suggestion: conda-forge – they put them on “probation” for a year first… try to get associated soon… at scypi try to setup in person talks… Filipe can provide names. maybe we could talk with them together?? Neil used to be directly involved. levi – pysal is approaching them.
Numfocus provides legal advice and has a diversity subgroup… review websites, etc etc
*carpentries moved away from numfocus but neil feels like those issues have been since resolved
other option - code for science and society – but neil things they are more focused on small software projects… danielle robinson
Updates: 6 packages in the submission queue!
pacifica – we need to make a decision on it. it’s an envt / set of tools. So the question at hand is DOES pyopensci accept these types of submissions? Or do we prefer individual submissions at this point. It would be good to decide this week
Luiz: I think it’s a good submission in the future, but it’s a really hard submission at the moment (due to complexity).
filipe – maybe a platform is a bit much for us to review
leah agrees with this …let’s suggest we may consider it in the future but we don’t have the capacity now!
Three packages submitted by one author. We probably can’t review 3 at once. so we should consider a one at a time per submittor policy. Can each person pick one of these to have a look at to recommend review or not review in the next week?
nbless - Easiest to review / use. Only uses python, 2 dependencies, jupyter & click
Filipe – this week
Interfaces with (and requires) R for most commands. Brings up scoping considerations - are we ok with reviewing things that interface with other langs? If so, which? -MJ. Based on discussions, if we use the capacity to review a package as a pre-requisite, we can review this.
relies on gitpython,
this is how Martin uses git now
Leo this week?
General comments – the review process
from leo – larger review – larger chunk of text vs
opening smaller issues
Use checkboxes on github (
Leo: I usually include this when starting a review “Please include a mention of the review issue in any issues and PRs (
pyOpenSci/software-review#6) so that we can keep track of progress”
what joss does
smaller questions they post as comments
but they encourage people to open issues in the software repo – but they are linked in the review thread. [x] add a checkbox – that the author is OK with “opening issues upstream”
do we want to accept packages that have other language dependencies. If our criteria to decide is our expertise – we do have combined R and python in this group
scope vs capacity to review.
TO DO – change the submission template to add a text box for “the reviewers opening issues in their repo”
we should space out reviews –
Martin: Becoming a NumFOCUS affialated project should be a priority in my opinion.
just a note that leah will look into a few options given right now we do have some support via cu and that is how ropensci started. BUT leah needs to chat with Karthik and Carl and Noam a bit more about this!!