Ctrl+K

Submit Your Python Package for Peer Review - Learn More!

pyOpenSci Meeting Notes - 30 May 2019#

Hackmd document link

Attendees#

  • 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)

note–

  • Chris and Kylen are traveling / in meetings today

Agenda#

  1. Communication – What is the best way for us to communicate and who wants to be involved in what types of communication? Some options

    • Discourse

      • 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!

  • Gitter

  • github organizations???

  • Other??

  • What do folks prefer?

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

      • Twitter (Martin)

      • Website

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

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)

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?):#

  • 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

    • Martin

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.

Advisory (4*):#

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

  • Neil ??

Reviewers (∞):

  • 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

  • Max

  • Martin

  • Levi

  • 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

  • marskar@gmail.com martin is interested in interfacing with the ropensci communications

  • Luiz (slack@luizirber.org)

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

  1. 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).

    • https://github.com/pyOpenSci/software-review/issues/2#issuecomment-494076938

    • 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

    • Reviewers:

      • Filipe – this week

      • Leo

    • Editor:

    • rmdawn

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

    • Reviewers:

      • Max

    • gitone

      • relies on gitpython,

      • this is how Martin uses git now

    • Reviewers:

      • Filipe

      • 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”

General questions

  • 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”

On this page
Edit on GitHub
Show Source