pyOpenSci / software-submission

Submit your package for review by pyOpenSci here! If you have questions please post them here: https://pyopensci.discourse.group/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

EarthPy: Software Submission for Review

lwasser opened this issue · comments

Submitting Author: Leah Wasser (@lwasser)
All current maintainers: (@lwasser, @nkorinek, @mbjoseph, @joemcglinchy, @jlpalomino)
Package Name: earthpy
One-Line Description of Package: A package built to support working with spatial data using open source python
Repository Link: https://github.com/earthlab/earthpy
Version submitted: 0.7
Editor: @luizirber
Reviewer 1: @HaoZeke
Reviewer 2: @sgillies
Archive: DOI
JOSS DOI: DOI
Version accepted: v 0.7.5
Date accepted (month/day/year): 11/06/2019


  • Paste the full DESCRIPTION file inside a code block below:
Python is a generic programming language designed to support many different applications. Because of this, many commonly performed spatial tasks for science including plotting and working with spatial data take many steps of code. EarthPy takes advantage of functionality developed for raster data (rasterio) and vector data (geopandas) and simplifies the code needed to :

    Stack raster bands from data such as Landsat into an easy to use numpy array
    Work with masks to set bad pixels such a those covered by clouds and cloud-shadows to NA (mask_pixels())
    Plot rgb (color), color infrared and other 3 band combination images (plot_rgb())
    View histograms of sets of raster
    Create discrete (categorical) legends

EarthPy also has an io module that allows users to

    Quickly access pre-created datasubsets used in the earth-analytics courses hosted on www.earthdatascience.org
    Download other datasets that they may want to use in their workflows.

Scope

  • Please indicate which category or categories this package falls under:
    • Data retrieval
    • Data extraction
    • Data munging
    • Data deposition
    • Reproducibility
    • Geospatial
    • Education
    • Data visualization*

* Please fill out a pre-submission inquiry before submitting a data visualization package. For more info, see this section of our guidebook.

  • Explain how the and why the package falls under these categories (briefly, 1-2 sentences):
    This package wraps around rasterio and geopandas to make working with geospatial data easier.

  • Who is the target audience and what are scientific applications of this package?
    The target audience is people working with different types of raster and vector data in python. There are many operations that are often repeated by users that require a lot of code. This package simplifies these operations so users can quickly explore their data.

  • Are there other Python packages that accomplish the same thing? If so, how does yours differ?
    Not that we know of! this is why we created this package.

  • If you made a pre-submission enquiry, please paste the link to the corresponding issue, forum post, or other discussion, or @tag the editor you contacted:

Technical checks

For details about the pyOpenSci packaging requirements, see our packaging guide. Confirm each of the following by checking the box. This package:

  • does not violate the Terms of Service of any service it interacts with.
  • has an OSI approved license
  • contains a README with instructions for installing the development version.
  • includes documentation with examples for all functions.
  • contains a vignette with examples of its essential functions and uses.
  • has a test suite.
  • has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.

Publication options

JOSS Checks
  • The package has an obvious research application according to JOSS's definition in their submission requirements. Be aware that completing the pyOpenSci review process does not guarantee acceptance to JOSS. Be sure to read their submission requirements (linked above) if you are interested in submitting to JOSS.
  • The package is not a "minor utility" as defined by JOSS's submission requirements: "Minor ‘utility’ packages, including ‘thin’ API clients, are not acceptable." pyOpenSci welcomes these packages under "Data Retrieval", but JOSS has slightly different criteria.
  • The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • The package is deposited in a long-term repository with the DOI:

Note: Do not submit your package separately to JOSS

Code of conduct

P.S. Have feedback/comments about our review process? Leave a comment here

NOTE: I am actually not sure what research application means according to Joss!! may followup with Arfon on this.

@luizirber as the editor for this package, will you please ping the reviewers and give them a 3 week deadline to perform the review?

Editor checks:

  • Fit: The package meets criteria for fit and overlap.
  • Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
  • License: The package has an OSI accepted license
    • yes, BSD 3-Clause
  • Repository: The repository link resolves correctly
  • Archive (JOSS only, may be post-review): The repository DOI resolves correctly
  • Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

Editor comments


Reviewer: @HaoZeke
Reviewer: @sgillies
Due date: 2019-10-25

@lwasser I don't have permission to change labels in this issue, but ready for review (past editor checks and reviewer assignment)

@luizirber !! i Just made you an admin for this repo so you should have permissions now. Please let me know if you don't!! And thank you for letting me know and for being willing to serve as an editor!!

Hi @kysolvik and @carsonfarmer! Anything I can do to help you with your reviews? Next steps are:

our docs are building again too - yay! they were down due to a RTD issue. thank you @luizirber

hey guys @carsonfarmer @luizirber -- wanted to followup on here. @kysolvik pointed out that there is a potential conflict of interest here given Kylen has worked for me and i'm not sure if that would apply with @carsonfarmer as well given we were both a part of earth lab for some time. we may need to reassign reviewers. @luizirber i tried to ping you on slack but am not sure if you saw it! just want to ensure this review moves forward given we definitely need to swap out atleast one reviewer!! i was wondering if @leouieda could do it instead of @kysolvik and kylen could do one of martin's submissions as one idea. but very open to thoughts.

Good point, I reset the reviewers and changed the label back to seeking reviewers.

If @leouieda agree to review this one, maybe @marskar would like to be a reviewer? It is a geospatial submission, but since @leouieda can cover the specific area I think it is good to have someone with a distinct expertise taking a look too.

@marskar @leouieda what do you think?

@luizirber i think we have confirmation as of today from @marskar and @leouieda that they are willing to work on reviewing earthpy!! i'll find someone else for nbless :)

Hi @leouieda and @marskar! You've been assigned, next steps are:

hello there @luizirber @leouieda @marskar just checking in to see where this review is now?? i've bumped the version of earthpy up a few times since submitting so if the review hasn't started i might update the version here. and if it has and you guys have questions, please say the word!

Hi @lwasser,
Let's work with the latest version.
I have a bio (not geo) background, so maybe @leouieda could address the science behind earthpy first and I will read his review and then follow up with more general packaging advice (testing, docs, etc.). Does that sound like a good plan?

hey team. i thijnk we might need to regroup on this review! given there has been no activity here. i suggest we reassign everything: editor, and reviewers. @luizirber i feel like you are super busy and don't have time. i'm wondering if @marskar or someone else might want to serve as the editor and we can find two new reviewers then! i have one reviewer in mind who's using this package for lessons for the carpentries!! let me know what you guys think. a package review shouldn't sit for this long!

many thanks!

Hi @lwasser, I am happy to serve as editor. In my opinion, the more, the merrier in terms of reviewers. Earth science is not my field, though I am happy to learn. It would be excellent if we could have involve the reviewer you mentioned, the one with experience using EarthPy!

ok let's try that! this review has been stale for a while so i'd like to see it move forward. @rbavery was one person i thought might be able to review for us. Ryan would you be game for that? but if not, can you suggest 1 or 2 people? We could also ask around (Twitter maybe??) to find some else that has time and can make our 3 week review window!

I don't have any experience with EarthPy but I have some experience with GIS ... let me know if I can help in any way.

thank you @xmnlab because earthpy is something i worked on, i'm trying hard to stand back from the review :) but it is a spatial library! it's designed to make exploring spatial data a bit easier. it has wrappers around rasterio and geopandas. you just did a (great) review and i know you are wrapping that up. i'll step back and will let @marskar decide on what he'd like to do as editor :) @marskar if you have any questions about the review / editor process please do say the word as well. we can also chat on thursday. Thank you both for stepping up. i think people are just very busy and i totally get that!!

@luizirber it sounds like @HaoZeke might be available to review this as well.

Yup, @luizirber and @lwasser, I'd be happy to review this one here and later for JOSS once it's been written up and submitted there as well.

Awesome, thanks @HaoZeke!

So let's get this train rolling: @HaoZeke and @marskar have been assigned, next steps are:

Due date for reviews is 2019-10-25

Hey all, we have a new potential reviewer! @sgillies responded on Twitter, so I recommend we try either:

I kind of like the three reviewers idea, what do you think @marskar?

hi colleagues. whoever does review this please note that the clip module is being migrated to geopandas (it fits there better!!) it's underway. but ofcourse if you have implemention comments i'll totally move that over to geopandas in that pr!

@HaoZeke and @marskar can you please post your reviewer checklist to acknowledge you started?

And @marskar, do you prefer the 3 reviewers approach or moving to another review?

Thanks!

@HaoZeke @marskar How is it going? Anything I can do to help you with your review?

Hi @luizirber, I think it will be better to stick to 2 reviewers.
So my suggestion is to move forward with @HaoZeke and @sgillies as the reviewers.
If there is a problem with this, please let me know and I will jump back into the review.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all user-facing functions
  • Examples for all user-facing functions
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING.
  • Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a setup.py file or elsewhere.

Readme requirements
The package meets the readme requirements below:

  • Package has a README.md file in the root directory.

The README should include, from top to bottom:

  • The package name
  • Badges for continuous integration and test coverage, the badge for pyOpenSci peer-review once it has started (see below), a repostatus.org badge, and any other badges. If the README has many more badges, you might want to consider using a table for badges, see this example, that one and that one. Such a table should be more wide than high.
  • Short description of goals of package, with descriptive links to all vignettes (rendered, i.e. readable, cf the documentation website section) unless the package is small and there’s only one vignette repeating the README.
  • Installation instructions
  • Any additional setup required (authentication tokens, etc)
  • Brief demonstration usage
  • Direction to more detailed documentation (e.g. your documentation files or website).
  • If applicable, how the package compares to other similar packages and/or how it relates to other packages
  • Citation information

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Continuous Integration: Has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.
  • Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines.

For packages co-submitting to JOSS

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing:


Review Comments

@luizirber. Many apologies for the long wait, I've had a few other reviews to close. I will be happy to finish this in a day or so now!

Thanks for the feedback, @marskar! Let's proceed with 2 reviewers then.

@sgillies are you still available for this review?

@HaoZeke No worries! Review due date is Oct 25th, and might be postponed depending on @sgillies response. And thanks for posting the reviewer checklist =]

@luizirber I am. Shall I also copy the checklist into this issue and begin? I have some evening time this week and expect no trouble with the 25 October deadline.

Cool, thanks @sgillies! Copying the checklist here and you're good to go =]

you guys rock!! again just a note that the CLIP module is moving to GEOPANDAS:

geopandas/geopandas#1128

but i am open to feedback on it as we move it over if you wish to provide it :)

Here we go. I'm excited to learn a new process and help out.

Package Review

Please check off boxes as applicable, and elaborate in comments below. Your review is not limited to these topics, as described in the reviewer guide

  • As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

  • A statement of need clearly stating problems the software is designed to solve and its target audience in README
  • Installation instructions: for the development version of package and any non-standard dependencies in README
  • Vignette(s) demonstrating major functionality that runs successfully locally
  • Function Documentation: for all user-facing functions
  • Examples for all user-facing functions
  • Community guidelines including contribution guidelines in the README or CONTRIBUTING.
  • Metadata including author(s), author e-mail(s), a url, and any other relevant metadata e.g., in a setup.py file or elsewhere.

Readme requirements
The package meets the readme requirements below:

  • Package has a README.md file in the root directory.

The README should include, from top to bottom:

  • The package name
  • Badges for continuous integration and test coverage, the badge for pyOpenSci peer-review once it has started (see below), a repostatus.org badge, and any other badges. If the README has many more badges, you might want to consider using a table for badges, see this example, that one and that one. Such a table should be more wide than high.
  • Short description of goals of package, with descriptive links to all vignettes (rendered, i.e. readable, cf the documentation website section) unless the package is small and there’s only one vignette repeating the README.
  • Installation instructions
  • Any additional setup required (authentication tokens, etc)
  • Brief demonstration usage
  • Direction to more detailed documentation (e.g. your documentation files or website).
  • If applicable, how the package compares to other similar packages and/or how it relates to other packages
  • Citation information

Functionality

  • Installation: Installation succeeds as documented.
  • Functionality: Any functional claims of the software been confirmed.
  • Performance: Any performance claims of the software been confirmed.
  • Automated tests: Tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
  • Continuous Integration: Has continuous integration, such as Travis CI, AppVeyor, CircleCI, and/or others.
  • Packaging guidelines: The package conforms to the pyOpenSci packaging guidelines.

For packages co-submitting to JOSS

Note: Be sure to check this carefully, as JOSS's submission requirements and scope differ from pyOpenSci's in terms of what types of packages are accepted.

The package contains a paper.md matching JOSS's requirements with:

  • A short summary describing the high-level functionality of the software
  • Authors: A list of authors with their affiliations
  • A statement of need clearly stating problems the software is designed to solve and its target audience.
  • References: with DOIs for all those that have one (e.g. papers, datasets, software).

Final approval (post-review)

  • The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 6.


Review Comments

I've created issues for review comments and they are collected in https://github.com/earthlab/earthpy/issues/created_by/sgillies.

I'm impressed at the quality of the code, the vignettes, and the documentation. I wish my own projects did as well as earthpy.

@luizirber my review is complete.

@HaoZeke @sgillies any questions about the process, or any other help I can offer?

@luizirber the earthpy package has not also been submitted to JOSS correct? I can leave those boxes unchecked?

@sgillies @HaoZeke we'd like to submit to JOSS but i've never been through that process before and this is my first time having a package reviewed. So i was going to complete this initial review with pyopensci and then if all goes well, ask for things to be pushed along to JOSS. i need to contact arfon again about how that works. I believe that the JOSS reviewers look at the paper.md. @luizirber do you know given your experience with JOSS?? if you need the paper now i can begin working on it!! i can ask @leouieda if you guys don't know. i just need more info :)

ok thank you @HaoZeke i will dig into the joss part. This is the first package that will move on to JOSS. it needs to pass pyopensci review first however. I will do a bit of research on that document and will get back to you guys soon!! in the meantime i'm working on comments and issues from this review and are so appreciative of everything suggested so far!!

ok i am working my way through @sgillies comments and issues which are all great -- THANK YOU!! @HaoZeke do you have a review for us coming? i didn't see your review template as filled out.

in the meantime we will have a paper.md file pushed in the next few days for JOSS!!

Hi @luizirber. I have completed my review, and I am satisfied with the code both in terms of functionality as well as documentation and reproducibility. I am not much of a geologist, but I am certain such a well crafted tool will be of much use to the community. I recommend this for endorsement. Also @lwasser, thank you for your patience. I would be willing to review this submission when you submit it to JOSS as well.

Hello all,

thanks for the reviews @sgillies and @HaoZeke! I see that the only item missing in both your checklist is the final approval (and the JOSS parts), so I think this is ready to be approved (if you don't have any other concerns).

awesome. just a note that

  1. we will not address the issue associated with the clip modules as that is moving to geopandas and we are working on the PR there. we will however integrate sean's suggestions in that PR!
  2. we were going to implement logging but after some discussion with @sgillies we decided that this might not be necessary for earthpy. so if everyone is on board, i think we are in good shape. I do have the joss paper in the repo now AND it's passing all of the JOSS whedon tests. so when i get the final approval here, i'll submit it to JOSS. i am more than happy however to address any other items if need be !!!

@lwasser went above and beyond in responding to my review comments. I've checked off the last box. Thanks for letting me get involved, I found the process and documentation quite interesting and well done.

Thanks @sgillies!

@HaoZeke, any final comments before we move to approved?

Thanks @HaoZeke!

Label updated, now EarthPy is 6/approved!

Approved! Thanks @lwasser for submitting and @HaoZeke and @sgillies for your reviews! 😸

To-dos:

  • Transfer the repo to our "pyOpenSci" GitHub organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. You'll be made admin once you do.
  • Fix any links in badges for CI and coverage to point to the pyOpenSci URL. For Appveryor projects, you should still use your personal Appveyor account. After transfer of your repo to the "pyOpenSci" GitHub organization the badge should be [![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/pyOpenSci/pkgname?branch=master&svg=true)](https://ci.appveyor.com/project/individualaccount/pkgname).

For JOSS:

  • Activate Zenodo watching the repo
  • Tag and create a release so as to create a Zenodo version and DOI
  • Submit to JOSS using the Zenodo DOI. We will tag it for expedited review.

We've started putting together a gitbook with our best practice and tips, this chapter starts the 3rd section that's about guidance for after onboarding. Please tell us what could be improved, the corresponding repo is here.

and this approval template might need some tweaks, since we are not asking repos to be moved to pyopensci... But the JOSS items are relevant!

oh yay !! ok @luizirber that's a great idea to update the template. whatever suggestions you have would be awesome!!

I will create a release and submit to JOSS next. @arfon told me to just link to this issue as documentation that we are approved by pyopensci. You may know more than me on this but i'll submit it first and will report back here in this issue. Please let me know if you have any suggestions!!

@HaoZeke and @sgillies thank you AGAIN for your reviews. i think we made some great improvements to earthpy through this process.

JOSS review is happening here: openjournals/joss-reviews#1869

this has also been approved!! so closing the issue!! yay!