pyOpenSci Meeting Notes - 20 June 2019
pyOpenSci Meeting Notes - 20 June 2019#
Looks like you need to signin to hackmd to contribute to this document! but you can sign in using your github user. welcome guest!!
Leah Wasser, Earth Lab, University of Colorado, Boulder
Luiz Irber, UC Davis
Max Joseph, Earth Lab, University of Colorado, Boulder
Jenny Palomino, Earth Lab, University of Colorado, Boulder
Lindsey Heagy, UC Berkeley
Martin Skarzynski, National Cancer Institute
Leonardo Uieda, University of Hawaii at Manoa
SciPy BOF (1 hour)
Thursday 11 July 2019 6-7pm in Room 204
We could plan to get a drink or food after informally to discuss pyOpenSci more as well. (SciPy scheduled happy hour 7-11pm)
What should the structure be?
Overview of goals
Set expectations surrounding what we can accept now!
Overview of what we have done
Overview of what is next / what we could use
Avenue of how to get involved - discuss roles
identify areas where help is needed
this could be now and/or in the future so we don’t end up trying to onboard too many new people at once
Are there other discussions that we could have
ask the community what they would like to see from pyOpenSci (if they have a stake in what it is, there is more buy-in)
Our goal Outcomes:
people on board to submit packages
people on board to review
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.
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.
If you will be at SciPy, please add your name below:
Open Reviews – ERDAPPY
How do we handle disagreements between reviewers and submitters? Can we setup criteria around things like usability that can help resolve disputes?
Maybe we find a good example of a well document package
Examples of Good Documentation#
We could add this to the criteria
JOSS: “docs” criteria https://joss.readthedocs.io/en/latest/review_checklist.html#documentation
These things should be readily findable from the docs & the readme
clear statement of need
We should be careful about being too specific for instance
contains a README with instructions for installing the development version.
does it matter if it’s in the readme vs in the docs. it really doesn’t. there could be links in the readme
things just need to be easily findable
Clearly establish the goal of the review. The goal should be not only passing tests, but to improve the package as a whole in terms of usability. This would ensure we are not bound to the check items in the template.
Right now the checks are only “technical checks”. But there is not discussion of usability in the review template.
does it align with common practices
there is more space then for additional feedback then…
Actional feedback in the review. right now it’s a HUGE issue. (so much text). But we didn’t open issues in this particular example.
Reboot this review and potentially update the template in this issue.
Do we want to start fresh given lessons learned??
If we are encouraging reviewers to open issues - could they also open PR’s ? That would be a nice way to help the author along in their improvements to the package.
Make this an opt out?? opt out of having issues and pr’s in your repo. we could have it checked by default an they can open out by unchecking it.
update the checkbox to allow for people opening issues and pr’s
Earthpy - need reviewers? If the list below works, Luiz can update the issue and we can start again! If that is happening i may update the version as we just bumped it!!
Martin (FYI, I am a bio (not geo) person😃)
[name=Leah Wasser]i think that is fine!
Luiz: that’s sort of on purpose, you could focus more on package org and docs, and leo on the geo parts =]
Nbless – Status: need a second reviewer if leo does earthpy
Filipe (Thank you for completing this review!)
Second reviewer wanted: who is interested? kylen perhaps?
feedback (if there is time). We implemented a process that included opening issues in the package repo and that seemed to work great!
Open Issues How should we handle this todo list? maybe a space in our discourse forum that gets referenced in our checkins?? This gets into task management which i think we can do in github but i have always used asana :) Open Issues
[ ] https://github.com/pyOpenSci/dev_guide/issues/17
[ ] sign up here
[ ] https://github.com/pyOpenSci/dev_guide/issues/27
[ ] https://github.com/pyOpenSci/dev_guide/issues/28
Plan to discuss gitter for pyOpenSci in future meeting
Roles reminder (we can skip this if there’s not time today)
Role Definition Revisited (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?):#
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
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.
Provide feedback & guidance regarding the direction of POS
Spread the word about POS
Communication: every other month / quarterly? meetings??
Carson (external/industry advisor)
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.