Closed SteveViss closed 4 years ago
Thanks for your submission, @SteveViss and co-authors! I am now seeking reviewers.
Regarding JOSS, from our end this simply means that we pass our reviews to the JOSS editors for them to use in place of new reviews. As you have multiple clients and would like to include them in a single submission to JOSS, I suggest you submit to JOSS and request they review the Julia client, and we will pass forward the reviews for the R client. This could wait until this review is finished or you could submit pre-emptively so that the Julia review starts, as well (as you may want to address review comments jointly should they affect common/upstream logic).
goodpractice::gp()
tests pass with flying colors.
Reviewers: Due date:
Reviewers assigned: Reviewer 1: @thomasp85 Reviewer 2: @arw36 Due date: 2019-08-26
@noamross we will submit to JOSS asap -- the Julia code is really tight (under 700 sloc), so review should be fast.
Great, please tag me in the issue there to track it.
Hi All
Please find my review below. All in all a very good job with this package 🙂
best Thomas
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
The package includes all the following forms of documentation:
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).
Estimated hours spent reviewing:
The rmangal package provides a clean and consistent API for interacting with the Mangal database. It is in general very well done and signals high quality to the user. Still, a few issues need to be addressed before approval but all of these are pretty minor and can easily be handled by the development team. My specific comments are below:
The website is good, and as it is hosted under the main service it wraps it gives credibility to the whole package. One issue that could be adressed is the reference index where a bit of care could be used to group functions and give each group a short description. This will help new users a lot when navigating the website.
The hard dependency on sf could be lifted as it doesn't appear to be used outside of a single functionality and sf has some very strong system dependencies. I suggest moving sf to suggest and testing for its availability when needed along with an error message about installing it if missing.
R CMD check reports a range of examples with run time > 5sec and a total runtime of examples of 53 sec. This is likely to be flagged by CRAN during submission and it might as well be fixed beforehand:
✔ checking examples (53.4s)
Examples with CPU or elapsed time > 5s
user system elapsed
get_collection 4.812 0.069 22.876
combine_mgNetworks 1.129 0.056 6.831
search_interactions 0.718 0.010 6.440
search_datasets 0.369 0.008 5.359
The README is a tad short. It does include installation instructions and some very useful links, but there is no motivating text for why this package may be of interest and what it tries to solve (besides being an API wrapper for a service). It should at least contain descriptions of why one might want to use the mangal database and an example of a network retrieval to show the strength of the API
This is a very good introduction to the package and shows of all important
features in an easy to understand way. I would personally include a short
section on visualising the networks, and maybe drag in tidygraph
and ggraph
(disclaimer: Author of both) for a more familiar interface to network analysis
and visualisation than igraph (at least to the tidyverse crowd). I will not
insist on this, though as package preferences are subjective
A few of the smaller functions lack examples, such a avail_type()
and
clear_cache_rmangal()
. These are both functions without arguments so it is not
clear that any example would add to the understanding, but in the interest of
completeness I'll just mention this.
Most of the documentations have very short, sub-title like descriptions, with
most of the text relegated to the Details section. This generally result in
documentation entries where one have to read quite a bit before the function is
justified and the experience could be improved by having a proper paragraph in
the Description section.
Cross referencing could be improved. All functions that work with mgNetwork or
mgNetworkCollection objects should link to or describe how one might obtain such
an object. The same is true for functions working with mgSearch objects. The
key `search_()could also benefit from better crosslinking by using the '@family
keyword from roxygen2.
There are documentation entries for all methods to generics (pointing to the
same doc). This makes the documentation index a bit messy so if this could be
solved it would add to the quality.
Small issues: combine_mgNetworks has a stray #'
in the ...
argument
The igraph integration is nice. With a very little modification you can make it work directly with tidygraph and ggraph.
as.igraph
method for mgNetwork
object, which
could simply be an alias for mg_to_igraph
. Tidygraph and ggraph will look
for such a method if no other exist and use that.as_tbl_graph
method directly. This can again just be a wrapper
around mg_to_igraph
, e.g.
as_tbl_graph.mgNetwork <- function(x, ...) {
as_tbl_graph(mg_to_igraph(x))
}
The obvious benefit of 1) is that you wouldn't need to list tidygraph as a dependency, while conversely the benefit of 2) is that you make support explicit
The package has a very good unit test coverage on all aspects of the code. The only area lacking is testing error handling as unit tests only tend to cover whether functions behave as expected with proper input. Tests for whether functions fails as expected and fails gracefully in the face of problems or bad input would be icing on the cake.
Thank you, @thomasp85! @SteveViss, I suggest waiting for @arw36's review so you can address them together.
Hi all,
Here is my review. Apologies coming in right at the deadline, first ROpenSci review...
Best, Anna
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
The package includes all the following forms of documentation:
URL
, BugReports
and Maintainer
(which may be autogenerated via Authors@R
).Not be minor 'utility' packages, such as 'thin' API clients.
Estimated hours spent reviewing:
rmangal
provides access and navigation of the Mangal database of ecological networks. The ease of this package combined with the valuable information stored in Mangal is an exciting and timely contribution to ecological research, and really expands the scale of between-network comparisons possible. I am particularly impressed with the integration of various taxonomic authorities, citation databases, and the addition of spatial information to published networks that will greatly enhance the flexibility of the collated dataset. I also really like showing the % progress of each dataset as it loads. Overall, a promising package with good coverage and usability. Here are some things that can improve the package.
df_net_unknown <- search_interactions(list(attr_id = 100), verbose = FALSE)
example is meant to accomplish in the search_interactions help file. This returned an empty dataframe for me. get_collection()
to the mg_insect example for search_networks
documentationattribute.id
and associated columns (name, description, unit) as well as user_id
. id
column, it may be worth clarifying: network_id
, edge_id
, node_id
, e.t.c. in the main table. This will allow easy linking across tables, as ids are referenced by this in other tables (e.g. the network_id
column in the nodes table). search_reference
is the only singular one. first_author
search_*(“”)
. This did not work for the reference table. Ease of full database download would be nice, perhaps with warnings about download times and file sizes. search_taxonomy
by the identified taxon rank. It would be really nice for broader rank taxon searches at the order or phylum level to retrieve all entries, even those that have a smaller scale taxonomy. For instance, as of now search_taxonomy(“Arthropoda”) returns no entries, despite there being lots of arthropods in the datasets. rglobi
) relate to this one, and citation information. rglobi
? May be worth saying something about contributing new data or identifying new papers. search_nodes
help page and rmangal.Rmd. Thanks @arw36 & @thomasp85 for your amazing and constructive reviews. We will refer each individual comments to issues & commits (as much as possible). In that way, you will be able to easily track modifications to the code.
Thank you @arw36! @SteveViss, yes, do tag and track as you incorporate your changes, but when you are done please provide a response to the reviewers here that summarizes your changes.
We would like to thank again both reviewers for their constructive comments. Below, we first highlight the major changes we made in the package before addressing all comments individually.
NB: currently Appveyor is failing because binary for ggraph 2.0.0
are not available yet.
Some of the comments made by one of the reviewer suggested changes to the database. We considered and applied some changes but refrained to incorporate others that implied major changes on the data model and consequently trigger downstream changes on the API and the website. However, we kept track of these recommendations and may integrate these recommendations in future version of the infrastructure. Speaking of the future of Mangal, and to answer one comment, opening the database to publication is now our priority. We are currently thinking about a publication / submission process of new ecological networks using the mgNetwork
class and a robust suite of tests to ensure data quality, and reduce curation time.
For the reason explained above, we did not prepopulate metrics (such as degree, centrality, connectance etc.) within the networks datatable. This will require extensive developments (for few functionalities) on the infrastructure backend. We have to change the model definition (i.e. add one by metric virtual / auto-generated field, compute metrics sometimes based on 2 other datatables: nodes and interactions).
We are also concerned about computing too many network descriptors / properties because several are sensitive to the algorithm selected. We basically recommend the user to do his own analysis through igraph
(for instance), which is well-suited for this purpose. We however decided to provide a summary
method that print a very simple set of network properties for mgNetwork
objects (see comment 7872b50)
As mentioned above we added a summary methods for mgNetwork
objects.
As suggested by one reviewer, instead of using mg_to_igraph()
we extended the as.igraph()
method for mgNetwork
objects (see 1d47483). This makes the conversion to igraph
and tbl_graph
objects seamless.
sf
has been moved to Suggests
. Moreover, sf
features are only used in search_networks_sf()
and when argument as_sf
is set to TRUE
, see #89.
search_references()
has been rewritten see #85;
Now the README includes much more details about rmangal to provide a better description of the goals of rmangal and to conform with ROpenSci packaging guidelines, see commits 275f30a, 0ec0789, b1c0d83.
We enhanced the API documentation by providing definition and type of all fields for each datatable. We made an explicit link to this in each R functions (see @references sections, be50421).
We moved some text from the details section to the description as suggested by one reviewer.
We now provide an example of network manipulation with tidygraph
and a an example of visualization with ggraph
. See 46e4a63. We also expand on how to use sf
with rmangal (see [#89])
search_references()
has been rewritten [#85];
as_sf
is set to TRUE
;
The website has been rebuilt and it is now deployed by Travis CI. We also broke down the reference page to four categories of functions (https://mangal-wg.github.io/rmangal/reference/index.html).
New features have all been covered in the unit testing and we added a little bit of icing on the cake!
One issue that could be adressed is the reference index where a bit of care could be used to group functions and give each group a short description. This will help new users a lot when navigating the website.
This has been done in https://mangal.io/doc/r/reference/index.html
The hard dependency on sf could be lifted as it doesn't appear to be used outside of a single functionality and sf has some very strong system dependencies. I suggest moving sf to suggest and testing for its availability when needed along with an error message about installing it if missing.
We have considered the recommandations (see this issue, and 0264bec).
R CMD check reports a range of examples with run time > 5sec and a total runtime of examples of 53 sec. This is likely to be flagged by CRAN during submission and it might as well be fixed beforehand:
checking examples (53.4s) Examples with CPU or elapsed time > 5s user system elapsed get_collection 4.812 0.069 22.876 combine_mgNetworks 1.129 0.056 6.831 search_interactions 0.718 0.010 6.440 search_datasets 0.369 0.008 5.359
We have now address this issue in commits f31417c, 621dcb8, ebc4cf0, 75dee5a by retrieving smaller networks and removing some examples. In improving examples, I noticed that examples are likely to have inconsistent timelapse because API responses are bandwidth dependent. If some issues are flagged by CRAN, we will use \donttest
.
The README is a tad short. It does include installation instructions and some very useful links, but there is no motivating text for why this package may be of interest and what it tries to solve (besides being an API wrapper for a service). It should at least contain descriptions of why one might want to use the mangal database and an example of a network retrieval to show the strength of the API
This comment has been addressed above (see section Readme).
This is a very good introduction to the package and shows of all important features in an easy to understand way. I would personally include a short section on visualising the networks, and maybe drag in tidygraph and ggraph (disclaimer: Author of both) for a more familiar interface to network analysis and visualisation than igraph (at least to the tidyverse crowd). I will not insist on this, though as package preferences are subjective Documentation
See section Vignette above.
A few of the smaller functions lack examples, such a avail_type() and clear_cache_rmangal(). These are both functions without arguments so it is not clear that any example would add to the understanding, but in the interest of completeness I'll just mention this.
avail_type()
enumerate the list of interactions accessible from the database. clear_cache_rmangal()
reset the memoise cache wrapped around get_gen()
& get_singleton()
. Both functions commit actions that do not required arguments. Because of that, we don't think any examples will improve functions usability.
Most of the documentations have very short, sub-title like descriptions, with most of the text relegated to the Details section. This generally result in documentation entries where one have to read quite a bit before the function is justified and the experience could be improved by having a proper paragraph in the Description section.
We have improved functions description in 4271bf8.
Cross referencing could be improved. All functions that work with mgNetwork or mgNetworkCollection objects should link to or describe how one might obtain such an object. The same is true for functions working with mgSearch* objects.
This has been done in 0ec0789
The key search_*() could also benefit from better crosslinking by using the '@family keyword from roxygen2. There are documentation entries for all methods to generics (pointing to the same doc). This makes the documentation index a bit messy so if this could be solved it would add to the quality.
Small issues: combine_mgNetworks has a stray#'in the...` argument
This typo error has been fixed.
The igraph integration is nice. With a very little modification you can make it work directly with tidygraph and ggraph.
Either provide an explicit as.igraph method for mgNetwork object, which could simply be an alias for mg_to_igraph. Tidygraph and ggraph will look for such a method if no other exist and use that. Provide an as_tbl_graph method directly. This can again just be a wrapper around mg_to_igraph, e.g.
as_tbl_graph.mgNetwork <- function(x, ...) { as_tbl_graph(mg_to_igraph(x)) }
The obvious benefit of 1) is that you wouldn't need to list tidygraph as a dependency, while conversely the benefit of 2) is that you make support explicit
This comment has been addressed (see section Package features).
The package has a very good unit test coverage on all aspects of the code. The only area lacking is testing error handling as unit tests only tend to cover whether functions behave as expected with proper input. Tests for whether functions fails as expected and fails gracefully in the face of problems or bad input would be icing on the cake.
Addressed in section Tests.
It would be easy to prepopulate standard metrics. For the network datatable this would include # of nodes and interactions, potentially a modularity factor, and the interactions database with degree and eigen.centrality.
This comment has been answered in section Compute apriori networks properties.
Unclear what the
df_net_unknown <- search_interactions(list(attr_id = 100), verbose = FALSE)
example is meant to accomplish in the search_interactions help file. This returned an empty dataframe for me.
We removed this example.
May want to add
get_collection()
to the mg_insect example forsearch_networks
documentation
Done!
Suggest you add California border to the plot(networks_in_area) example
Done!
I would like to see more metadata on variables including definitions for
attribute.id
and associated columns (name, description, unit) as well asuser_id
.
This has been answered in Documentation section.
For the date in the edges table, it is unclear when this is extracted as a network-level trait, is an trait specific to each edge, or is NA.
We removed the field date
in dataset table to avoid redundancies. We kept the date
in the network and interaction datatables. In most cases, dates documented in edges and networks should be identical. But the network / sampling location could be visited several times (e.g. research would like to cover the flowering period). In that case, we keep track of the observation period through the field date
in interaction datatable: the network datatable will contain the median date of the period and the interaction datable every observation dates.
For instance, for edges of network_id = 19 it appears to be extrapolated from the network trait, despite the dataset_id (1) giving a range of dates (1897-09 to 1899-07).
Regarding the dataset #1, all informations (dataset, network and interactions) point to the same date: 1899-07-01. We are not able to reproduce the range of dates given by the reviewer (see code below).
library(rmangal)
ds_1 <- search_datasets(list(id = 1))
net_19 <- get_collection(search_networks(list(id = 19)))
range(c(net_19$interactions$date, ds_1$date, net_19$network$date))
Each data table starts with an
id
column, it may be worth clarifying:network_id
,edge_id
,node_id
, e.t.c. in the main table. This will allow easy linking across tables, as ids are referenced by this in other tables (e.g. thenetwork_id
column in the nodes table).
We applied this suggestion on mgNetwork
objects (see c6cd9c0). However, the SQL side hasn't changed as it allows to make the distinction between primary key and foreign key.
I suggest you make all your functions plural (currently
search_reference
is the only singular one.
search_reference
is now renamed as search_references
and mgSearchReference
as mgSearchReferences
(see a98475b).
I suggest you rename the author column in the reference table to be
first_author
This suggestion has been taken into consideration.
I was able to retrieve complete data tables for network, dataset, node, interactions using
search_*(“”)
. This did not work for the reference table. Ease of full database download would be nice, perhaps with warnings about download times and file sizes.
search_references("")
is now working (see cc297c84)
I think there should be greater curation/spell checks done in the interaction table, method column. What does biblio mean? Standardize capitalization.
We standardized capitalization and replaced biblio
with literature
.
I find the categorization of interaction types to be non-standard. For instance, I would standardize null, NA, and none of interactions$attribute.unit to be the same (or clarify NA vs. none).
null
, NA
and none
are now true SQL NULL.
I think there is some confusion between edges/interactions. I wish the use of interaction was standardized in output text.
We replaced edges
for interactions
(see
cd1430d) in all code.
Currently, you can only
search_taxonomy
by the identified taxon rank. It would be really nice for broader rank taxon searches at the order or phylum level to retrieve all entries, even those that have a smaller scale taxonomy. For instance, as of now search_taxonomy(“Arthropoda”) returns no entries, despite there being lots of arthropods in the datasets.
Addressed in section Mangal database above.
To conform with ROpenSci packaging guidelines, you will need to add brief demonstration usage, a description of how similar packages (i.e.
rglobi
) relate to this one, and citation information.
Usage, description and rglobi
comparison have been added to the README except for the citation which can be found at https://mangal-wg.github.io/rmangal/authors.html or with citation('rmangal')
In general, the ReadMe is short. Keep in mind this ReadMe may be first point of entry, so could be fleshed out a bit more with material you already have in vignettes/website.
See section Readme above.
Do you expect users to upload networks to this database like
rglobi
? May be worth saying something about contributing new data or identifying new papers.
This comment has been discussed in section Mangal database above.
Thank you for your comprehensive response, @SteveViss! @thomasp85 and @arw36 please review and let us know if the changes and comments satisfy your concerns.
All my concerns have been addressed, but I will note (and urge a fix is made), that testing for the existence of sf
should be done like:
if (!requireNamespace("sf", quietly = TRUE)) {
stop("sf should be installed to use this functionality", call. = FALSE) #or whatever wording you prefer
}
instead of the current call to installed.packages()
Thanks for all the edits, all my concerns were covered. I particularly like the new summary feature and agree that with different metric algorithms this was the most practical solution.
Just a note about my confusion of the date dataset 1. I retrieved that date range by going back to the original reference material (roberson_1929), not by using the package. As that critique is of the underlying data within Mangal, rather than the functionality of rmangal
, I'm not concerned about this edit for ROpenSci publication. I would encourage somewhere, whether on the website or in the ReadMe you mention how to comment or suggest edits of data cleaning issues as these are not package bugs per se. Currently, contributions seem limited to network structure and analysis functionality. rmangal
may not best place to host data cleaning concerns, alternatively an "email us" note on the Mangal database would be better. I really don't mind the issue of not including the date range from roberson_1929 in particular (though 12 years of data collection tells something very different than one day of data collection), this was just an example of a data-cleaning issue that may occur elsewhere in Mangal. There are always some human extraction errors for databases of datasets like this, so an avenue to address them would benefit both users and the authors.
Thank you @SteveViss et al, @thomasp85 and @arw36, for an excellent review proccess! rmangal is approved. 🎉
To-dos:
[ ] Add the review badge to your README:
[![](https://badges.ropensci.org/332_status.svg)](https://github.com/ropensci/software-review/issues/332)
[ ] Transfer the repo to rOpenSci's "ropensci" 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 and you can add any team members you wish.
[ ] Update any links in badges for CI and coverage to point to the ropensci URL, and package. Also point documentation urls to https://docs.ropensci.org/{package}
. Docs should be built within 24 hours after transfer.
If/when you submit to a combined paper to JOSS, make a note in the pre-review thread that the R client has already been reviewed, linking to this thread, and tag @ropensci/editors
. That way JOSS editors can limit review to the Julia client.
Our developer guide has a section for ongoing maintenance after acceptance. Welcome aboard!
This client but also the combined mangal.io ecosystem would be a great topic for a post on our blog. If you are interested in writing something up please let @stefaniebutland know here. The timing is flexible can work with the other pieces of the system you are putting in place
Congratulations on approval @SteveViss! Given Noam's 👍🏼 for a blog post, here's some further information. Happy to answer any questions.
This tag gets you (diverse) examples of blog posts by authors of peer-reviewed packages: https://ropensci.org/tags/software-peer-review/.
Here are some technical and editorial guidelines: https://github.com/ropensci/roweb2#contributing-a-blog-post. Publication date is flexible. I like to get a draft via pull request a week before the planned publication date so I can review.
We're grateful to the @ropensci team for this fantastic and constructive experience. Thank you @noamross, @thomasp85 & @arw36. We are doing the final checklist.
@arw36, we fully agree with your last comment. On the short term, we are tracking all data issues in https://github.com/mangal-wg/mangal-api/issues. Github is well suited for developers but not for all network ecologists. So on the long term, we may consider opening a discourse platform which will be more inclusive and hopefully encourage users to flag potential data issues.
Hi @stefaniebutland ! We're interested in posting to the blog. Mangal.io will be presented during the BiodiversityNext poster session (end of october). If possible, we propose to submit the pull request 2 weeks before that event (same for the JOSS paper).
Do you prefer Tues Oct 15 or Tues Oct 22 blog publication date? (I saw pre-conf and main-conf dates). Once your pull request is submitted, I can give you a link to the post for your poster :-)
We can also coordinate this if you like: If you tweet to invite folks to your poster #, rOpenSci can quote tweet with a link to your post for more info and to bring more attention to your poster.
Tues Oct 22 for the main conf. So our deadline should be Tue Oct 15, right? Let me know if you need more time.
We can also coordinate this if you like: If you tweet to invite folks to your poster #, rOpenSci can quote tweet with a link to your post for more info and to bring more attention to your poster.
It will be great. Thank @stefaniebutland !
So our deadline should be Tue Oct 15, right?
Correct!
@SteveViss Checking in to confirm you'll submit a draft post on or before Tues Oct 15 for publication on 22nd. I'll have time to review it on Wed 16th.
On track?
@stefaniebutland I will be the one leading the blog post, we should be able to write the blog post by Tuesday !
Got it @KevCaz. Note that I'll be on vacation and mostly unavailable Fri Oct 18 - Mon Oct 21.
Noted!
Post submitted via pull request: https://github.com/ropensci/roweb2/pull/525
Submitting Author: Steve Vissault (@SteveViss)
Repository: https://github.com/mangal-wg/rmangal Version submitted: 1.9.1 Editor: @noamross
Reviewer 1: @thomasp85 Reviewer 2: @arw36 Archive: TBD
Version accepted: TBD
Scope
Please indicate which category or categories from our package fit policies this package falls under: (Please check an appropriate box below. If you are unsure, we suggest you make a pre-submission inquiry.):
Explain how the and why the package falls under these categories (briefly, 1-2 sentences).
The
rmangal
package provides all the functions to retrieve ecological networks stored in Mangal interactions database v2. Thermangal
package makes easier to integrate the data acquisition step of ecological networks into a reproducible workflow.Please note any areas you are unsure of:
reproducibility
This package targets mostly ecologists interested in the structure of interactions among species, individus and populations at different scales. By giving access to a large collection of networks around the globe, Mangal opens the path to study ecological networks properties (connectance, degree, trophic structure etc.) at global scale in a more reproducible way.
The only package that could have a potential overlap is
rglobi
.rmangal
serves a different purpose by giving access at ecological networks (already published) in a standardized matter; whether GloBI is aggregating pairwise interactions among species and do not keep track of the study context (e.g. sampling date and location). Mangal 1.0 was a data provider of the GloBi infrastructure, and we plan to do the same with Mangal 2.0.No
Accepted presubmission by @noamross in #318
Technical checks
Confirm each of the following by checking the box. This package:
Publication options
Yes, we are currently writing an abstract describing this package. In this paper, we would also like to introduce the julia client in order to streamline references to Mangal clients. That being said, we are not quite sure about what does this mean on your end, we believe that this implies that the Julia client will need to be reviewed independently.
JOSS Options
- [ ] The package has an **obvious research application** according to [JOSS's definition](https://joss.readthedocs.io/en/latest/submitting.html#submission-requirements). - [ ] The package contains a `paper.md` matching [JOSS's requirements](https://joss.readthedocs.io/en/latest/submitting.html#what-should-my-paper-contain) 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*)MEE Options
- [ ] 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](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/journal-resources/policy-on-publishing-code.html)) - (*Scope: Do consider MEE's [Aims and Scope](http://besjournals.onlinelibrary.wiley.com/hub/journal/10.1111/(ISSN)2041-210X/aims-and-scope/read-full-aims-and-scope.html) for your manuscript. We make no guarantee that your manuscript will 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*)Code of conduct
Best, Steve Vissault on the behalf of all authors / contributors (@KevCaz, @gabrielbouleau, @BenMerSci, @clementviolet, @tpoisot).