Update the scope for API wrappers

[maelle]

Define criteria for "something more than a thin wrapper"

Cc @emilyriederer @noamross

[maelle]

I've set the current milestone for November but should this be considered as something more urgent actually?

[maelle]

Related: "Why would your API package delight users?" https://ropensci.org/blog/2022/06/16/publicize-api-client-yes-no/#why-would-your-api-package-delight-users

[mpadge]

@maelle I actually don't think we need to act on this. We currently have this statement under Data Retrieval:

Packages for accessing and downloading data from online sources with scientific applications. Our definition of scientific applications is broad, including data storage services, journals, and other remote servers, as many data sources may be of interest to researchers. However, retrieval packages should be focused on data sources / topics, rather than services. For example a general client for Amazon Web Services data storage would not be in-scope.

Given that, I think any further explicit mention of API wrappers would only confuse things. As it stands, we do not explicitly mention that we accept "API wrappers", but authors can clearly interpret those Data Retrieval guidelines to include such, if a package adheres to that description. Okay to close as not planned?

[maelle]

@mpadge do you think this can happen for release 1.0.0 which will be in August? If not, please remove the milestone from this issue. Thank you!

[mpadge]

@mpadge do you think this can happen for release 1.0.0 which will be in August? If not, please remove the milestone from this issue. Thank you!

Removed, thamks

[maelle]

Are we sure this needs to be postponed? This issue is about adding something about the level of interface expected in this item

dev_guide/softwarereview_policies.Rmd

Line 63 in 78c009a

- **data retrieval**: Packages for accessing and downloading data from online sources with scientific applications. Our definition of scientific applications is broad, including data storage services, journals, and other remote servers, as many data sources may be of interest to researchers. However, retrieval packages should be focused on data *sources* / *topics*, rather than *services*. For example a general client for Amazon Web Services data storage would not be in-scope. (Examples: [**rotl**](https://github.com/ropensci/software-review/issues/17),

This came from rejecting a presub enquiry for being a too thin wrapper, if I remember correctly.