Submission: rcites

[JonasGeschke]

Summary

• What does this package do? (explain in 50 words or less):
  With rcites we provide an R client to access to the Speciesplus database. We provide functions to 1. access the Speciesplus taxon concept, and thereafter 2. get a species' legislation status, both from CITES and from the European Union, 3. get a species' country-wise distribution range, as listed in Speciesplus, and 4. get the references on which a Speciesplus listing is based.

• Paste the full DESCRIPTION file inside a code block below:

Package: rcites
Type: Package
Title: R Interface to the Species+ Database
Version: 0.1.0
Authors@R: c(person("Jonas", "Geschke", role = c("aut"), email = "jonas.e.geschke@gmail.com", comment = c(ORCID = "0000-0002-5654-9313")),
  person("Kevin", "Cazelles", role = c("aut", "cre"), email = "kevin.cazelles@gmail.com", comment = c(ORCID = "0000-0001-6619-9874")),
  person("Ignasi", "Bartomeus", role = c("aut"), comment = c(ORCID = "0000-0001-7893-4389")),
  person("Jonathan", "Goldenberg", role = c("ctb")),
  person("Marie-Bé", "Leduc", role = c("ctb")),
  person("Yasmine", "Verzelen", role = c("ctb")))
Description: A programmatic interface to the Species+ <https://speciesplus.net/> database via the Species+/CITES Checklist API <https://api.speciesplus.net/>.
URL: https://ibartomeus.github.io/rcites/, https://github.com/ibartomeus/rcites
BugReports: https://github.com/ibartomeus/rcites/issues
License: MIT + file LICENSE
Depends:
  R (>= 3.1.0)
Imports:
  httr,
  data.table,
  methods
Encoding: UTF-8
RoxygenNote: 6.1.0
Suggests: knitr, rmarkdown, testthat, rworldmap
VignetteBuilder: knitr

• URL for the package (the development repository, not a stylized html page):
  https://github.com/ibartomeus/rcites

• Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):
  Database access, because the package gives access to the Species+/CITES Checklist API

•   Who is the target audience and what are scientific applications of this package?  
  Researchers and national authorities

• Are there other R packages that accomplish the same thing? If so, how does
  yours differ or meet our criteria for best-in-category?
  No

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

Requirements

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 a CRAN and OSI accepted 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, including reporting of test coverage, using services such as Travis CI, Coveralls and/or CodeCov.
• I agree to abide by ROpenSci's Code of Conduct during the review process and in maintaining my package should it be accepted.

Publication options

• Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package has an obvious research application according to JOSS's definition.
  • 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:
  • (Do not submit your package separately to JOSS)
• Do you wish to submit an Applications Article about your package to Methods in Ecology and Evolution? If so:
  • The package is novel and will be of interest to the broad readership of the journal.
  • The manuscript describing the package is no longer than 3000 words.
  • You intend to archive the code for the package in a long-term repository which meets the requirements of the journal (see MEE's Policy on Publishing Code)
  • (Scope: Do consider MEE's Aims and Scope for your manuscript. We make no gaurantee that your manuscript willl be within MEE scope.)
  • (Although not required, we strongly recommend having a full manuscript prepared when you submit here.)
  • (Please do not submit your package separately to Methods in Ecology and Evolution)

Detail

• Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

• Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

• If this is a resubmission following rejection, please explain the change in circumstances:

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:
  https://github.com/karthik
  https://github.com/geanders

[sckott]

hi @JonasGeschke Thanks for your submission.

I have a clarifying question. What is the relationship of Species+/CITES to IUCN Red List, if any? Does it contain any overlapping information/data?

(p.s. you didn't check Do you intend for this package to go on CRAN? - i think you're pkg is already on CRAN, so go ahead and check that)

[JonasGeschke]

Hi @sckott thanks for your quick message.

There is no relationship between the IUCN Red List and the CITES Speciesplus database. The IUCN Red List contains data about the conservation/endangerment status of species; the CITES Speciesplus database contains data about the (illegal) trade status of endangered species, so it goes beyond the Red List. Actually, the Speciesplus database also contains data about the protection status of species under the Convention on Migrating Species (CMS), but the API so far only allows access to the CITES legislation status information.

Regarding the Do you intend for this package to go on CRAN? question thats right. By mistake, we already submitted the package to CRAN before having it reviewed via ROpenSci. So we dont intend the package to go on CRAN, as it already is on CRAN. Thus, we are looking forward to the reviewing process and how big the first update of the package on CRAN will be.

[sckott]

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 a CRAN or OSI accepted license
• 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

Thanks for your submission @JonasGeschke !

Here's the output from goodpractice. If you haven't used goodpractice it's an R package that checks a number of things with another package - most of which we agree with and want authors to follow. You don't need to address these now, it's info for reviewers to use to get started. There's very little in the report below, which is a good thing!

── GP rcites ──────────

It is good practice to

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about
    80 characters wide. Try make your lines shorter than 80 characters

    R/sppplus_simplify.R:29:1
    R/sppplus_simplify.R:32:1
    R/sppplus_simplify.R:50:1
    R/sppplus_taxonconcept.R:35:1
    R/sppplus_taxonconcept.R:48:1
    ... and 30 more lines

Seeking reviewers now 🕐

---

Reviewers:

• @noamross due date 2018-09-07
• @mcsiple due date 2018-09-10

[KevCaz]

@sckott thanks!

Actually, following the guidelines of Ropenscience, we've used goodpractice (that's why we got rid of a sapply()!). Regarding the length of code line issue, I'd be happy to have your feed back: we used tidy_dir() from formatR package with a width.cutoff=80, so, should we reduce the cutoff?

[sckott]

If those lines are already 80 or shorter, then all good. I didn't check them myself. there are definitely exceptions when it's just too cumbersome to do so

[sckott]

Reviewers assigned:

• @noamross due date 2018-09-07
• @mcsiple due date 2018-09-10

[noamross]

Package Review

• 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
  • See comments on README below
• 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 exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
  • No examples for spplus_simplify()
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

For packages co-submitting to JOSS

• The package has an obvious research application according to JOSS's definition

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

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: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

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: 5

---

Review Comments

This is a very useful package to retrieve species CITES status and history. I've actually developed a related package: https://github.com/ecohealthalliance/cites/, which provides access to data pulled from the non-API friendly trade.cites.org. I was very glad to see rcites and it work together just fine!

The package is well-constructed and documented. Setting up authentication follows best practices and was fast and easy.

The major challenge that the package has to deal with is the complexity of returned objects from the API. I think this could be better handled in both API and documentation. I also think the authors should consider how to deal with workflows for bulk analysis. I detail more on these and a few other things below.

Simplifying/processing objects

The API returns fairly complex records that are challenging to wrangle, which the authors simplify in most functions, with the option of simplifying further with simplify=TRUE options. This works OK but should be more aggressive. Even simplified tables still have, for instance, list entries which are lists of NULL objects. This might be a matter of including more list types as "special cases" (e.g., "term", "source", "eu_decision_type"), or it might require more special handling on a field-by-field basis.

I also note that "special cases" fields that end up as factors when most of them (like URLs) should be characters.

I think aggressive simplification should be the default output, and the alternative should be a simple unprocessed list (maybe raw=FALSE), which would let users then deal with post-processing themselves if they have some specialized need.

I note that the functions return data.tables, not data frames. I think this is unnecessary and can even trip people up who are not expecting this data type. (Follow the principle of least astonishment¹). The data.table package is great but it's primary benefit - performance - is basically nonexistent here when we are dealing with tables of maybe of dozens of rows.

Printing objects

Because the objects returned are complex, and also because they often include very long text fields, they don't print well. There are a couple of ways to approach this. One would be to make the returned objects custom S3 classes (e.g., "spl_leg", "spl_eu_leg") with their own print methods that print summaries. A second would be to assign the data frames in the returned objects class c("tbl_df", "tbl", "data.frame"). This would provide more succinct printing for users who have tidyverse packages loaded without adding those packages as dependencies.

If you return the raw list I suggest above, you could take a tip from the gh package, give it the class c("list", "spl_raw") and have a nice JSON print method like shown here.

Function API

The authors use the sppplus_ prefix for some functions, and taxon_ for others. It might be simpler to have all functions retrieving something from the API to start with the same prefix (if you want it shorter, I suggest spl_).

I note you use data.table to modify tables in place with spplus_simplify(). This is confusing and non-standard behavior. It would make more sense to return the simplified data frames as objects (e.g. simpl_df <- sppplus_simplify(res1)). The current behavior precludes a functional workflows such as simplifying all tables in an object (leg_smpl <- lapply(leg1, sppplus_simplify)).

None of the functions currently have an argument to define the language parameter of the API, which I think is important. Also taxon_cites/eu_legislation() functions don't accept arguments for the scope parameter, and should.

sppplus_taxonconcept accepts a single taxon name and returns a single taxon concept record, but this API endpoint has many more parameters for selecting taxon concepts in bulk. All these should be made available (see "Bulk Analysis" below), though perhaps you want to break this into two functions - one to grab info on one species, and one for the broader downloads that aggregates the data differently.

Documentation, README, and Vignette

The documentation is very good, and I'm glad that everything refers back to the appropriate API documentation page. I'd suggest just a little more wording in the @return fields like, "see the API documentation for definitions of all return fields."

The README is a bit sparse. It could use more of an introduction, in which the authors describe what the Species+ API is and what data can be retrieved from it, and a few lines of basic usage examples. (See https://ropensci.github.io/dev_guide/building.html#readme). Remember the principle of first entry ¹ - any piece of documentation may be the first encounter the user has with the API, data source, or even the CITES treaty/organization. Don't pass up the opportunity to give a curious data scientist some environmental education!

The vignette, probably because of the need to make API calls, doesn't actually compile and therefore doesn't show outputs from the code that is run. (The outputs also make for challenging reading, which is why I suggest better printing methods above). This isn't very helpful and I suggest that the authors compile the vignette to a markdown output locally and have a vignette with all the evaluated output blocks (still name *.Rmd*) in the vignettes/` folder. This will allow for a useful vignette on CRAN and the pkgdown site. (But you need to remember to update it manually!)

While the vignette demonstrates use of a few functions, it would be much more helpful if it explained the type of information that was returned, the structure of the object, and demonstrate a few additional workflow of manipulating these results and using them in analysis, e.g.:

taxon_cites_legislation()" returns information on legislative acts related to the species. Let's see which countries have quotas on exports of Elephant ivory....The object returned is a list of three types of actions taken - listings, quotas, and suspensions. Here we extract and work with cites_quotas...

The vigenette doesn't show sppplus_simplify() or explain anything about the simplify arguments. These are key to understanding the package workflow and should be elaborated on along with explanations of the data structures returned, though of course this depends on changes you may make to the simplification approaches described above.

Bulk Analysis

The package currently only has non-vectorized functions and focuses on a workflow where one is examining information on a single species. I think there is a lot of potential for enabling different analyses. First, as I mention above, all the taxon concept endpoint parameters should be accessible so that one can retrieve a list of taxa to operate on. A natural extension of this would be to at least show in the vignette how to get the paginated return values, and then iterate over them to retrieve, say, legislation for all those species. I think a better solution would be to build auto-pagination into the taxon concept function, and then add vectorization into the rest of the functions (thinking carefully of how to aggregate all the results into a set of usable data frames).

A major change to consider would be to cache/store downloaded data in a local database that can then be queried in more ways. For instance, it would be good to be able to ask "What quotas were started in 2010?". I note that the Species+ API anticipates this, describing a workflow where data is cached in the local client and updated by calling the taxon_concepts endpoint with the updated_at parameter to get a list of species whose information has changed since the last download. A few RO packages have this design pattern, like taxizedb, restez, and my own cites package. I won't demand this for the current review but think you should consider it for 1.0 or 2.0.

Tiny stuff

None of the >80 character line widths are egregious or problematic, but I recommend shortening the lines in the examples to this width or less so that they show up help files without overrunning the width of the viewer.

Implemented as a PR:

• Rename vignette for current package name
• Fix top-level package docs roxygen syntax

---

¹ https://en.wikipedia.org/wiki/Principle_of_least_astonishment

² This one I made up a while back, but it's about what we recommend at https://ropensci.github.io/dev_guide/building.html#readme

[KevCaz]

Many thanks @noamross for your very careful review of our package. We'll do our best to integrate all of these valuable comments.

[sckott]

thx for your review @noamross !

[JonasGeschke]

@noamross thank you for this very comprehensive review. Your comments will help us a lot, we will do our best to address them all! Also I like that your cites package for the trade database, which actually was a thought of mine to potentially include this in rcites lateron, too.

[KevCaz]

@noamross I have two questions regarding your review:

functions currently have an argument to define the language parameter of the API

Do you mean JSON/XML?

Also, regarding data.table, do you think we should rather not use it? I think we'll be able to do the same manipulations without it, so it means we'll have one less dependency, which may be desired.

Thanks!

[JonasGeschke]

regarding the language parameter:
@KevCaz I think @noamross means the CITES and EU legislation as well as distributions API enable a language parameter to select if the outcome is provided in English (default), French or Spanish.
we should be able to include this parameter as query string.

[KevCaz]

Oh! Now I understand! Sorry!

[noamross]

Correct, I meant the English/French/Spanish parameter.

Yes, I'd drop data.table as a dependency.

Also, my advice is to hold off on major changes prior to getting your second review. It's usually easier to address them simultaneously, and @mcsiple may not agree with me on everything!

[mcsiple]

Hi @JonasGeschke et al. - I am having the same compiling issues as @noamross with the .Rmd files for vignettes, and it would be helpful for using and reviewing if the outputs were visible (either by pasting in blocks or putting a pdf in the vignettes folder, if API key issues happen often).

I did a temp fix by adding my own API key to the .Rmd file but had to add the token to each line with an rcites function. If other reviewers are assigned (and if it is in accordance with rOpenSci reviewing practices) it might be helpful to make a compiled pdf or html available.

[JonasGeschke]

Hi @mcsiple thank you for your post. Yes, making the vignette more comprehensive and with outputs visible is on our list. If you have any further reviewing comments, we are happy to receive those. Thank you!

[mcsiple]

The rest of my comments are coming soon - I just wanted to post that one in case other reviewers are assigned and need the compiled vignettes in the meantime!

[mcsiple]

Package Review

• 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
  - Currently the vignette is included as a file that doesn't compile locally because of API issues (as mentioned by @noamross).
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

For packages co-submitting to JOSS

• The package has an obvious research application according to JOSS's definition

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

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: Unit tests cover essential functions of the package
  and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

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: 8

---

General comments

I found this package lovely, easy to use, and well-documented. I think the authors have done a good job of wrangling some complex data types from the API and am sure this package will be widely used. Most of the suggestions I have are about interfacing with the API, as well as a few about usability.

Review Comments

Documentation

Once compiled, the vignette is quite concise and nicely written (There are a few typos in the vignette but none that affect functionality or clarity). Some parts of the vignette could be fleshed out a little more: for example, the "Legislation information" section does not have text to accompany the code. When I compiled the vignette, the spp_cites_legislation() piece here returns an "invalid factor level" warning, and some accompanying text would help me as a user figure out what I am supposed to see here, and whether it is an issue with the vignette or with the code.

The README is also good.

As I mentioned in my earlier comment, the API token needs to be set in the environment before the .Rmd file will compile (i.e., even if a valid token is entered at the beginning, set_token() has to be used before the vignette will knit).

Functions

Setting the token: set_token() example should note that token is entered as a character string if it is within the function, and without quotes (not a character object) when it's entered after the prompt.
E.g.,
set_token("VrXZVlHjhEsVjerBfqsV5Qtt")
or set_token()
Enter your token: VrXZVlHjhEsVjerBfqsV5Qtt
If the token is entered as a character object with the prompt, the token will not set properly and the dependent functions don't work.

There are a lot of rcites_ functions within the package functions (e.g., rcites_getsecret() which is used in spp_taxonconcept()) which don't work on their own. Since the wrapper functions around them work, I think it's fine; I was just confused as to what they are. I'm not sure what the rOpenSci guidelines are for these functions.

Icing to add: improving processing time

One of the greatest challenges I have with any package that uses an API is the processing time to get bulk entries.

For example, I usually have a dataframe for which I need to access and merge data I've gathered through something like rcites. While I found that rcites returns objects that are easy to extract, I think it would be particularly wonderful if there were a few ways to access that data without having the re-look them up with the API every time. For example, if the same list of species is looked up multiple times, could those data be stored locally for faster access if the user wants to look up something else about them? I think @noamross also mentions this in his review. This would also be helpful so authors don't overload the API. I don't know if the CITES API limits how many data requests each user can make at a time, but this added functionality would help avoid that issue.

Finally, I also think the authors should make tibble output an option for all the users who will be using dplyr with rcites (I would!).

Mapping

I love that code for making distribution maps is included in the vignette, but had some issues with the example. The mapping example in the vignette doesn't work- the following error occurs when running as.data.frame(spp_distributions("4521")):
"cannot coerce class ‘"spp_distr"’ to a data.frame"

I know that this is not the main point of the package, but it's cool that there is an easy way to make these maps with rcites output, so I would love to see the outputs from this example.

rOpenSci guidelines:

• Does the code comply with general principles in the Mozilla reviewing guide?
• Does the package comply with the rOpenSci packaging guide?

[KevCaz]

Yes!

[JonasGeschke]

Oh, thanks for following up so quickly @sckott and @KevCaz for your additional efforts again!
@sckott would you like to be added as reviewer as well?

[sckott]

@JonasGeschke thanks for the offer, but i'm just happy to help here

[sckott]

@KevCaz sometimes I forget, but yes, e.g., you could test that timeout works, e.g.,

expect_error(some_fxn(httr::timeout(10)), "some message")
# or just that it errors with any message
expect_error(some_fxn(httr::timeout(10)))

[KevCaz]

@sckott added and now tested! Thanks for the tip!

[sckott]

Approved! Thanks again for your submission @JonasGeschke @KevCaz !

To-dos:

• Please transfer the package to ropensci- I've invited you to a team within our ropensci organization. After you accept you should be able to move it. You'll be made admin once you do.
• add rOpenSci footer to README
  [![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)
• Change any needed links, such those for CI badges
• Travis CI should update to the new location automatically - you may have to update other CI systems manually
• add ropensci review badge to your readme [![](https://badges.ropensci.org/244_status.svg)](https://github.com/ropensci/onboarding/issues/244)
• We're starting to roll out software metadata files to all ropensci pkgs via the Codemeta initiative, see https://github.com/ropensci/codemetar/#codemetar for how to include it in your pkg, after installing the pkg - should be easy as running codemetar::write_codemeta() in the root of your pkg

---

We've started putting together a bookdown with our best practice and tips, this chapter starts the 3d section that's about guidance for after onboarding. Please tell us what could be improved. The repo is at https://github.com/ropensci/dev_guide

Are you interested in doing a blog post for our blog https://ropensci.org/blog/ ? either a short-form intro to it (https://ropensci.org/technotes/) or long-form post with more narrative about its development (https://ropensci.org/blog/). If so, we'll have our community manager @stefaniebutland get in touch with you on that

[JonasGeschke]

Great, thank you @sckott! We will work on the to-dos asap.

[ibartomeus]

Great! I can draft a blog post (and let @KevCaz and @JonasGeschke add stuff before doing anything else). @stefaniebutland let me know how to proceed.

[ibartomeus]

@sckott I didn't get an invitation, so I can't transfer the repo. Can you invite me too? Thanks!

[sckott]

@ibartomeus sent

[KevCaz]

@sckott one more question, what kind of access to the repo do we have? Are we allowed to change the settings of the repo? If yes I cannot do so currently! If no, can you just edit the URL at the home page of the GH repo: https://ibartomeus.github.io/rcites/ => https://ropensci.github.io/rcites/. Thanks!

[sckott]

these 3

now have admin access - now you should be able to change those things - of course you can manage access of your other contibutors

[stefaniebutland]

@JonasGeschke Great to hear you'd like to contribute a post!

This link will give you many examples of blog posts by authors of onboarded packages so you can get an idea of the style and length you prefer.

Here are some technical and editorial guidelines for contributing a blog post: https://github.com/ropensci/roweb2#contributing-a-blog-post. We ask that you submit your draft post via pull request a week before the planned publication date so we can give you some feedback.
I have 2018-12-18 available for publication. Would submission by 2018-12-11 work for you?

Happy to answer any questions.

[JonasGeschke]

@stefaniebutland thanks for your message, we are very happy to contribute a blog post. @ibartomeus I just put you in the loop so you also see the above two links.
submission by 2018-12-11 should be doable @ibartomeus ?!

[KevCaz]

@sckott just to let you know that codemeta.jsonis now added.

[JonasGeschke]

@sckott just to let you know that codemeta.jsonis now added.

and with this, all the above points (#244 (comment)) are done.
anything else you @sckott need us to do for now?

Zenono DOI also is done, as well as a CRAN release 1.0.0. thus I guess we are ready for the JOSS submission, right? do you @sckott have any recommendation for the JOSS editor?
(btw I dont know how long it then needs for the paper to pop up, but on wednesday there is the wildlife forum at the CBD COP-14. it would be a great opportunity to promote the paper and package.)

[stefaniebutland]

on wednesday there is the wildlife forum at the CBD COP-14. it would be a great opportunity to promote the paper and package

@JonasGeschke Seems reasonable that I could send a tweet from rOpenSci about the package if that might help? If you think this is a good idea, please send me a short phrase or two that I can use in tweet about pkg along with twitter handle and/or relevant conference hashtag, your twitter handle & that of any pkg co-authors I should tag.

[sckott]

@JonasGeschke no, nothing else. thanks much.

• For JOSS:
  • Looks like there's already a Zenodo web hook, so that's good.
  • If you haven't already, generate a new release associated with a git tag in your repo. This doesn't mean you have to submit to CRAN with that git tag/release, its just to get a Zenodo DOI - and you can put a zenodo badge in your readme, then after each git tag it will generate a new Zenodo release
  • Then submit your paper.md to JOSS at http://joss.theoj.org/papers/new

I'm not familiar with the editors at JOSS - Not sure how long it takes for review at JOSS - but I guess you could just link to the paper in your repo / zenodo?

[noamross]

@JonasGeschke You can certainly talk about it as "in press" if you want. If you want to accelerate processing, once you submit, you can go to the automatedly generate GitHub issue at https://github.com/openjournals/joss-reviews/issues, and comment that the package has been accepted here, linking back to this issue.

[JonasGeschke]

Thanks for your messages. So I submitted the paper to JOSS. I will let them know about the ropensci review process as told in https://ropensci.github.io/dev_guide/onboarding-guide-for-editors.html#for-joint-joss-submissions

If you haven't already, generate a new release associated with a git tag in your repo. This doesn't mean you have to submit to CRAN with that git tag/release, its just to get a Zenodo DOI - and you can put a zenodo badge in your readme, then after each git tag it will generate a new Zenodo release

@KevCaz you got this, right?

@stefaniebutland thanks, a tweet would be great! I will prepare you a text!

Then I guess this issue can be closed ... but this I believe is your task @sckott . Thanks for all your efforts!

[KevCaz]

Yep! BTW I was thinking that it may be a good idea to reference this thread or the repo in ropensci-archive/wishlist#29

[JonasGeschke]

btw: from yesterday to today, the download number jumped from around 620 to almost 1100! 👍

[JonasGeschke]

So the JOSS paper is published, this is great!

@stefaniebutland here its the tweet you can do tomorrow (21.11.2018):

It is #WildlifeForum today, promoting the sustainable use for conservation and livelihoods. #rcites helps with accessing the @cites #Speciesplus #trade database: https://doi.org/10.21105/joss.01091
by @J_Geschke @KCazelles @ibartomeus
#EgyptCOP14 #COP14 @unenvironment @unepwcmc @EU_ENV

[stefaniebutland]

Thanks @JonasGeschke. I'll adapt it to fit rOpenSci tweet style and schedule it for 21.11.2018.