submission: spatsoc

[robitalec]

Summary

• What does this package do? (explain in 50 words or less):

The spatsoc package detects spatial and temporal groups in GPS relocations. For social network analysis, spatsoc can be used to build proximity-based social networks and perform network randomizations. It can also be used to detect potential interactions between individuals, shared space use, etc.

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

Package: spatsoc
Title: Group Animal Relocation Data by Spatial and Temporal Relationship
Version: 0.1.0
Authors@R: c(
    person("Alec L.", "Robitaille", role = c("aut", "cre"), email = "robit.alec@gmail.com"),
    person("Quinn", "Webber", role = c("aut")),
    person("Eric", "Vander Wal", role = c("aut"))
    )
Description: Detects spatial and temporal groups in GPS relocations. 
    It can be used to convert GPS relocations to
    gambit-of-the-group format to build proximity-based social networks.
    In addition, the randomizations function provides data-stream
    randomization methods suitable for GPS data.
Depends: R (>= 3.4)
License: GPL-3 | file LICENSE
Encoding: UTF-8
LazyData: true
Imports: data.table (>= 1.10.5),
    sp,
    rgeos,
    adehabitatHR,
    igraph,
    methods
Suggests: testthat,
    knitr,
    rmarkdown
SystemRequirements: GEOS (>= 3.2.0)
RoxygenNote: 6.0.1
VignetteBuilder: knitr
Roxygen: list(markdown = TRUE)
BugReports: https://www.gitlab.com/robit.a/spatsoc/issues
URL: https://spatsoc.gitlab.io

• URL for the package (the development repository, not a stylized html page):

https://gitlab.com/robit.a/spatsoc/

(also mirrored to https://github.com/robitalec/spatsoc)

• Please indicate which category or categories from our package fit policies this package falls under and why:

data munging and geospatial - because it manipulates a specific type of spatial data (GPS relocations) to assist social network analysis

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

The spatsoc package targets researchers using social network analysis with animal relocation datasets. The applications include disease transmission modeling, interactions between individuals, community structure.

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

There are no other R packages for creating social networks from GPS relocations. Other R packages exist for social network analysis, notably igraph and asnipe, but there is no overlap in functionality. spatsoc can be viewed as a precursor step before passing the outputs to the aforementioned packages.

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

There are no NOTEs, WARNINGs, or ERRORs.

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

[lmullen]

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

@robitalec et al. Thanks for your submission. I will be editing this submission.

Local R CMD check looks fine.

There are 3 warnings and 1 note reported by R CMD check on your CI service (e.g., the most recent job). Please fix the WARNINGs, and the NOTE if possible, before the review begins.

There are several misspellings reported by spelling::spell_check(). Those should be corrected as well.

Good work on the test coverage.

Selection from goodpractice::gp()

It is good practice to


  ✖ not import packages as a whole, as this can cause name clashes between
    the imported packages. Instead, import only the specific functions you need.

This appears to be coming from a full import of the data.table package. Can you import only specific functions from that package?

I have begun soliciting reviewers and will let you all know when the review begins.

[robitalec]

Thanks @lmullen.

I've fixed the misspellings. There are some leftovers detected by spelling::spell_check_package but they are function arguments (e.g.: datetime, DT), last names, and "et al.".

We're importing the full data.table package because we use fread and data.table syntax in the tests and throughout the package's functions. It also does not have any of its own dependencies.

I've added @importFrom for all other functions (from other packages) used in the package.

I fixed the NOTEs and WARNINGs in the ci. I also added an r-devel image so we are testing on both the latest release and development version of R. Here is the latest pipeline.

[lmullen]

@robitalec Could you please add an "under review" badge to your repository? Here is the code:

[![](https://badges.ropensci.org/237_status.svg)](https://github.com/ropensci/onboarding/issues/237)

[lmullen]

Reviewer: @pmnatural
Reviewer: @FilipeamTeixeira
Due date: 2018-08-16

Thanks to our two reviewers for agreeing to undertake this peer review. As a reminder, you can find the reviewers' guide here, and you can ping me with questions.

[robitalec]

Badge added.

Thank you @pmnatural and @FilipeamTeixeira!

[FilipeamTeixeira]

@robitalec Here's my review. If there's something you feel like correcting please let me know. There's still quite some stuff to go through but for now I think that it's better to start from what I mention below and to go from there.

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

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:

---

Review Comments

test_check() gives 16 warnings with the following arguments:

test-pts.R:214: warning: withinGroup is not returned to the user
found duplicate id in a timegroup and/or splitBy - does your group_times threshold match the fix rate?

test-pts.R:229: warning: no rows are added to the result DT
found duplicate id in a timegroup and/or splitBy - does your group_times threshold match the fix rate?

test-pts.R:245: warning: only one column added to the result DT
found duplicate id in a timegroup and/or splitBy - does your group_times threshold match the fix rate?

test-pts.R:260: warning: group column is added to result
found duplicate id in a timegroup and/or splitBy - does your group_times threshold match the fix rate?
────────────────────────────────────────────────────────────────────────────────────────
✔ | 22   1   | test randomizations [2.6 s]
────────────────────────────────────────────────────────────────────────────────────────
test-random.R:11: warning: (unknown)
found duplicate id in a timegroup and/or splitBy - does your group_times threshold match the fix rate?
────────────────────────────────────────────────────────────────────────────────────────
✔ | 27   11   | test group_times [3.7 s]
────────────────────────────────────────────────────────────────────────────────────────
test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length

test-time.R:71: warning: threshold with minutes fails with > 60
number of items to replace is not a multiple of replacement length
────────────────────────────────────────────────────────────────────────────────────────

══ Results ═════════════════════════════════════════════════════════════════════════════
Duration: 64.2 s

OK:       163
Failed:   0
Warnings: 16`
Skipped:  0

Documentation

It would be interesting to have a help(spatsoc) available. This can be easily achieved and it saves the users from headaches or from having to go to the gitlab/github account to find some basic information about your package.

Same goes for the possibility of running a vignette("spatsoc").

Importing data

In the vignettes you start by importing the spatsoc example dataset. However, you're missing the library(data.table) as it is required by the function following your code. This might seem obvious for people familiar with the data.table package, but not everybody might be aware of it.

I would also recommend to create a function which imports data automatically. It's just two lines of code, but it might make the difference for unexperienced users. If I'm not aware that I have to use the data.table format, or even to convert the dates to a POSIXct format, it will take a while until I would understand what the error is. So you either have that at the beginning of your documentation (now it's at the end), or you create a specific function which does that for the user, and instruct the users that they should use that function.

Functions

group_times

Running the function with minutes goes well, but with hours and days gives me a warning.
As for hours, I get warnings:
Warning message: In group_times(DT, datetime = "datetime", threshold = "2 hours") : block, timegroup columns found in input DT and will be overwritten by this function

As for days I get the following warnings:
Warning messages: 1: In group_times(DT, datetime = "datetime", threshold = "5 days") : block, timegroup columns found in input DT and will be overwritten by this function 2: In group_times(DT, datetime = "datetime", threshold = "5 days") : the minimum and maximum days in DT are not evenly divisible by the provided block length

All functions

• Similar warnings occur along the package with other functions which from what I can see are generated by you. However, it's confusing on why does it generate this warning on demand. It doesn't necessarily mean that you have a problem, but it might confuse some users.

• I recommend as well that you mention what the output means. For example when running group_times() I get a variable called minday but I'm not sure of what am I getting. Is this something users should know if they are acquainted with the data? If not, there should be more information.

• Before looking at the rest of the code, I strongly recommend you to improve the documentation and to make it more accessible to other users. From how to import the data, what are the requirements (e.g. variables, format), to explain the warning messages and the output you get from those functions.

Summary

You're going on the right path, but there're some changes to be made. If there's something you don't agree with or something I've missed please let me know. As soon as you fix those issues or in case I'm wrong, explain what I'm missing, I'll proceed with the rest of the review.

Thank you

[robitalec]

Thank you @FilipeamTeixeira.

In response to just the tests for now:
I'm having a bit of trouble reproducing those test results.
We are passing all tests locally on Linux, Mac and Windows, on our GitLab CI and through CRAN.
What OS are you using? Did you get these same results with devtools::test()?

Just hoping to reproduce them locally so I can fix them!

I will update you as I work through the rest of your comments.

[robitalec]

I just released our FAQ vignette (available here and here).
It was in the works, but your points made a great incentive to fill it in and make it public.
Still lots of points to fill in and things to translate to the function documentation but figured I would mention it as I think it clears up some of your points @FilipeamTeixeira.

In addition, I changed some of the warnings to messages. I think I was using warnings everywhere, where in some cases, messages are preferred.

I added a help(spatsoc).

I will keep you posted as I continue to improve spatsoc thanks to the feedback.

[FilipeamTeixeira]

Dear @robitalec, first of all thank you for your work on this. Regarding the tests indeed they were ran with devtools::test() which uses the package testthat. I'm using macOS Sierra 10.12.6 but the test results don't seem to be OS dependant.
I'm using as well the latest testthat and devtools version, just in case.

Regarding the vignettes and the FAQs, thank you for adding it. Unfortunately I still can't get the vignettes by typing vignettes("spatsoc"). Actually the vignettes aren't even listed on the browseVignettes() function.

As for the warnings vs messages, or even the content of the help files, I recommend you to go through what I wrote before and if there's something that wasn't clear enough please let me know as I can explain better why I found the messages and the instructions not clear enough. However, to summarise it, my comments were mainly related to the lack of information on the output we get when using your package. I believe that a strong package shouldn't be exclusively for experts, but for anyone who might have to use it. Ask someone who never used the package to do something with it, and ask them about their interpretation on the results.

Nevertheless, I'll wait as well for the other reviewers to state their comments as well.

I'll keep on going through your package and I'll let you know something as soon as possible.

[lmullen]

Glad to see this back and forth with the aim of improving the package. I'll provide some editorial commentary when all the reviews are in (still plenty of time for that).

[robitalec]

@FilipeamTeixeira I've updated the README/website with a better install line:

devtools::install_git('https://gitlab.com/robit.a/spatsoc.git', build_vignettes = TRUE)

I didn't realize, but devtools doesn't build vignettes automatically. See this note to devtools users.
Let me know if that helps with browseVignettes("spatsoc").

Thanks for getting back to me concerning OS/test environment. I wonder if it isn't a timezone or locale issue... because they all appear to be related to group_times. Still trying to reproduce those results on my end. Keep you posted.

Lots of documentation improvements today, more to come!

[robitalec]

EDIT: my apologies @lmullen, the tag makes sense - I interpreted 5/awaiting-reviewer(s)-response as reviewers' reviews instead of author responses to reviewers..

---

@lmullen should the tag currently be 5/awaiting-reviewer(s)-response and not 3/reviewer(s)-assigned?

[FilipeamTeixeira]

@robitalec Any news on the updated package? I would like to go through it once again, but before it would be nice to see those changes mentioned above made.

[robitalec]

@FilipeamTeixeira I think I was confused about the status of the reviews and deadline date stated by @lmullen. Apologies all for the delay.. Moving forward:

Were you able to see the vignettes with the updated install line?

Some of the changes were previously mentioned, as I completed them, but here is a full list of all changes since your initial review:

• help(spatsoc) added with author, maintainers, see also, description, details
• devtools::install(build_vignettes = TRUE); browseVignettes(package = "spatsoc") runs successfully
• added CODE_OF_CONDUCT.md
• added CONTRIBUTING.md
• documentation better explains outputs
• documentation better explains messages
• documentation better explains data.table input
• FAQ vignette released
• vignettes run successfully
• examples run successfully

One thing I recognize is missing right now is how spatsoc integrates with other social network analysis tools/R packages. A vignette is in the works...

As for the problems you initially reported with the tests, I still haven't been able to reproduce them locally (with Mac/Windows/Linux/CI/CRAN tests, I get 0 errors/warnings/notes)... I'm not sure how to address these problems.

Excited to hear more feedback from reviewers @pmnatural and @FilipeamTeixeira. Thank you!

[FilipeamTeixeira]

My apologies for being almost a month late with my review, but there were some professional reasons contributing for this delay. I'll have a final review by Sunday the 9th.

[lmullen]

@robitalec Yes, as you figured out the current tag is correct.

@FilipeamTeixeira Thanks for the update, and for going back and forth with @robitalec about these changes.

I've also been in correspondence with @pmnatural about her review. So everything is proceeding just fine.

[robitalec]

Thank you @pmnatural for your review.

First off, a question: what is missing for the Community guidelines?

---

Detailed responses:

Vignette and help for the different functions are available now and have greatly improved. Every variable in the output is explained in the help.

Thank you @pmnatural. This review process has helped us highlight weak points in the documentation and functions and I'm glad to be moving forward with a better version of the package.

An Import function would be really useful which puts data into a DT class and time in the correct format and gives a warning when data is unprojected (eg. lat-long coordinates) and forces to input a projection, e.g. as in build_lines.

I won't repeat all points from my response to @FilipeamTeixeira about the potential import function, please see above.

build_lines does not explicitly require projected coordinates because it simply creates a SpatialLines object from a data.table of coordinates by individual.

In the case of group_lines, rgeos::gBuffer returns a warning that the GEOS expects planar coordinates.

In the case of group_polys and build_polys, I can't find any explicit statement in adehabitatHR documentation or vignettes about the requirement for planar coordinates though they do mention unin and unout as being units of "m", "km" or "m2", "km2", "ha". No warnings are returned when unprojected coordinates are provided to the adehabitatHR::mcp or adehabitatHR::kernelUD, so I clarified the expectations in the faq and function documentation.

11a5703
934446
0488aae

A type of summary message (or function) for the imported data could be included, particularly considering

Separate from an import function, this type of summary information should be straightforward to glean from the input data using the follow lines of code.

total number of individual and groups, ...

# Number of unique individuals
DT[, uniqueN(ID)]

# Number of unique individuals by group
DT[, uniqueN(ID), by = group]

the total of time involved, as it is needed to choose the time grouping periods properly

Here is an example of evaluating the temporal range of the data but we'd like to emphasize that the selection of a temporal threshold should have more to do about the biology of the study species, system and hypotheses of the user.

DT[, range(datetime)]

the maximum extent of the data or the bounding box of the points, relocations or GPS fixes, as it will help to chose reasonable distance thresholds when doing any of the spatial groupings, particularly when data does not come from an sp object.

Similar to temporal threshold, the distance threshold should be linked to the specific system and species.

# All individuals
DT[, .(minX = min(X),
       maxX = max(X),
       minY = min(Y),
       maxY = max(Y),)]

# By individual
DT[, .(minX = min(X),
       maxX = max(X),
       minY = min(Y),
       maxY = max(Y),),
   by = ID]

[lmullen]

Thank you for these responses,@robitalec.

@pmnatural and @FilipeamTeixeira Could you please respond to these comments and let us know of any needed fixes by October 5 (about one week)?

[pmnatural]

Hi @robitalec
Regarding the community guidelines, I simply forgot to check it down.
In relation to a data summary useful for defining parameters to use with spatsoc, I still think having a function to do this would greatly improve the usage. Even knowing what time or distance make sense for a species or particular problem, you still need to get the bounds of your dataset before running a spatsoc analysis if you don´t want error messages to appear because you chose a wrong time period or distance. With the code presented in the examples, you could just have all in a function that outs puts a list with all the results. If this seems too complicated, disregard my suggestion, but include the code somewhere as help.

[robitalec]

Ok, good to know concerning community guidelines.

I have added the summary information code chunks to the FAQ. I think this section will grow as we come up with more information that might be useful to help users understand their input data for functions provided by spatsoc. This also makes it simpler to add more chunks in the future.
6e982e

I think this is a good example of how to select spatial distance thresholds for functions in spatsoc:

We defined social associations based on spatial proximity of
active lizards. We considered a direct social contact occurred if
lizards were within 2 m of each other. [...] We determined a threshold
distance between GPS location records to deduce direct social
contact. Because each GPS device had a median precision of 6 m
(see above) we considered two lizards could be within 2 m of each
other if the recorded locations were up to 14 m apart. [...]

from: Leu et al., 2010

[lmullen]

Hi @pmnatural and @FilipeamTeixeira. Have @robitalec's changes satisfied your critiques above? Are there any remaining issues to be fixed before you are willing to accept this package?

[lmullen]

Hi @pmnatural and @FilipeamTeixeira: Can you please confirm that that the changes made have satisfied your critique and confirm whether you now recommend the package for acceptance?

[FilipeamTeixeira]

@lmullen I went through the changes and through some of the comments and my position stands as before. I recommend the package for acceptance. Thank you for your patience and for waiting for my feedback.

[robitalec]

Thank you @FilipeamTeixeira for the feedback throughout this onboarding process.

[pmnatural]

I recommend the package for acceptance. The clarification of options and examples on using spatsoc for social network analysis has been greatly improved. Thanks you for your patience in waitung for this acceptance.

[lmullen]

Approved! Thanks @robitalec for submitting and @pmnatural and @FilipeamTeixeira for your reviews! 🚀

To-dos:

• Transfer the repo to rOpenSci's "ropensci" GitHub organization under "Settings" in your repo. Soon I will invite you to a team that should allow you to do so. You'll be made admin once you do.
• As necessary, please publish the revised version of the package to CRAN.
• Add the rOpenSci footer to the bottom of your README.

[![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org

• Fix any links in badges for CI and coverage to point to the ropensci URL. We no longer transfer Appveyor projects to ropensci Appveyor account so after transfer of your repo to rOpenSci's "ropensci" GitHub organization the badge should be (check the package and account names) [![AppVeyor Build Status](https://ci.appveyor.com/api/projects/status/github/ropensci/spatsoc?branch=master&svg=true)](https://ci.appveyor.com/project/individualaccount/pkgname).
• We're starting to roll out software metadata files to all ropensci packages via the Codemeta initiative, see https://github.com/ropensci/codemetar/#codemetar for how to include it in your package, after installing the package - should be easy as running codemetar::write_codemeta() in the root of your package.

Should you want to acknowledge your reviewers in your package DESCRIPTION, you can do so by making them "rev"-type contributors in the Authors@R field (with their consent). More info on this here.

Welcome aboard! We'd also love a blog post about your package, either a short-form intro to it (https://ropensci.org/tech-notes/) or long-form post with more narrative about its development. (https://ropensci.org/blog/). If you are interested, @stefaniebutland will be in touch about content and timing.

We've started putting together a gitbook 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 corresponding repo is here.

[robitalec]

Thank you @pmnatural for your feedback.

[lmullen]

@robitalec I’ve added you to the rOpenSci organization and the spatsoc team.

[robitalec]

Thank you @lmullen, I really appreciate your efforts as an editor during this process.

• added the rOpenSci footer
• repo transferred and URLs updated throughout.
• cran_comments updated and submitted to CRAN. I'll update when it is accepted.
• added codemetar

We'd definitely be interested in a blog post.

I noticed I can't access the settings tab... do I have full access to the repository?

[lmullen]

@robitalec Great. Thanks for doing that. I've just made you an admin on the spatsoc repository so you should have access to the settings now. That can't happen until after the repository is transferred.

[robitalec]

Perfect! Thank you @lmullen.

[stefaniebutland]

We'd definitely be interested in a blog post.

This is great to hear @robitalec.
This link gives you many examples of blog posts by authors of onboarded packages so you can get an idea of the style and length you prefer: https://ropensci.org/tags/review/. Tech Notes are here: https://ropensci.org/technotes/.

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-11-13 and 2018-11-27 available for publication. Would one of those work for you?

Happy to answer any questions.

[robitalec]

Thank you for the information @stefaniebutland.
2018-11-27 would work for us.

I will let you know if we have any questions.

[stefaniebutland]

@robitalec Will you be able to submit a draft via pull request for review soon? Planned publication is 2018-11-27. Don't hesitate to let me know if you need to change that date.

[robitalec]

Thanks @stefaniebutland, I think we'll need to delay the draft. I was hoping to have it today, but it isn't ready yet... Sorry for the late notice.

[stefaniebutland]

Not a problem! Do you think a week from today is good timing for draft submission? 2018-11-27 for publication >= a week after that? Or would you prefer a bit later?

[robitalec]

Yes that would be perfect. Thank you!

[stefaniebutland]

Blog post: Detecting spatiotemporal groups in relocation data with spatsoc

[stefaniebutland]

@robitalec Neat outcome of your package & post. I just spoke with a colleague, Stephanie O'Donnell, who is the Community Manager for https://www.wildlabs.net/ (https://twitter.com/wildlabsnet) and noticed their webinar next week has Sarah Davidson, Data Curator at Movebank as a speaker: https://www.wildlabs.net/resources/community-announcements/wildlabs-virtual-meetup-event-big-data-conservation-dec-12th

I told Steph about your package and blog post and she would like to re-post it with permission of you and co-authors (she will link back to rOpenSci version as well). She is a trusted peer and I'm quite impressed with the way she handles WILDLABS community. Maybe this would get even more eyes on your work. Let me know what you think.

Apparently their webinars have quite active 45min discussions after speakers so worth attending if it looks to be of interest to you.

[robitalec]

@stefaniebutland That would be really cool and we are glad to have the package spread through another community. None of us had heard of WildLabs and this webinar seems really interesting. We'll be checking it out for sure. Thank you!
(Let us know when there's a link!)