search

ropensci / software-review

rOpenSci Software Peer Review.
291 stars 104 forks source link

NLMR #188

Closed marcosci closed 6 years ago

marcosci commented 6 years ago

Summary

Package: NLMR
Type: Package
Title: Simulating Neutral Landscape Models
Version: 0.2
Authors@R: c(person("Marco", "Sciaini", email = "sciaini.marco@gmail.com", role = c("aut", "cre")), 
    person("Matthias", "Fritsch", email = "matthias.fritsch@forst.uni-goettingen.de", role =  c("aut")),
    person("Craig", "Simpkins", email = "simpkinscraig063@gmail.com", role =  c("aut")),
    person("Cédric", "Scherer", email = "cedricphilippscherer@gmail.com", role =  c("ctb"), comment = "Implemented nlm_neigh"))
Description: Provides neutral landscape models 
    (Gardner et al. 1987 <doi:10.1007/BF02275262>,
    With 1997 <doi:10.1046/j.1523-1739.1997.96210.x>) that can easily extend in 
    existing landscape analyses. Neutral landscape models range from "hard" 
    neutral models (completely random distibuted), to "soft" neutral models (definable spatial characteristics) and 
    generate landscape patterns that are independent of ecological processes.
    Thus, these patterns can be used as null models in landscape ecology. 'NLMR' 
    combines a large number of algorithms from other published software for simulating neutral landscapes (Saura & 
    Martínez 2000   <doi:10.1023/A:1008107902848>, Etherington et
    al. 2015 <doi:10.1111/2041-210X.12308>) and
    includes utility functions to classify and combine the multiple landscapes. The 
    simulation results are obtained in a geospatial data format (raster* objects 
    from the 'raster' package) and can, therefore, be used 
    in any sort of raster data operation that is performed with standard 
    observation data.                                                                                                  
License: GPL-3
Copyright: file inst/COPYRIGHTS
Encoding: UTF-8
LazyData: true
ByteCompile: true
Depends:
    R (>= 3.1.0)
RoxygenNote: 6.0.1
Imports:
    checkmate,
    dismo,
    dplyr,
    ggplot2,
    igraph,
    magrittr,
    purrr,
    RandomFields,
    raster,
    rasterVis,
    sp,
    spatstat,
    stats,
    tibble,
    viridis,
    extrafont
URL: https://marcosci.github.io/NLMR/
BugReports: https://github.com/marcosci/NLMR/issues/
Suggests:
    testthat,
    covr,
    knitr,
    rmarkdown,
    lintr
VignetteBuilder:
    knitr

Requirements

Confirm each of the following by checking the box. This package:

Publication options

Detail

marcosci commented 6 years ago

Hi Folks,

was quite unsure about the fit of our package into the rOpenSci world - but we would love to get your review and platform.

Best wishes, Marco

sckott commented 6 years ago

thanks for your submission @marcosci we've been discussing and will get back to you asap

maelle commented 6 years ago

Editor checks:

Editor comments

Thanks for your submission @marcosci! I'm currently looking for reviewers. I have these comments/questions:

Reviewers: @laurajanegraham @jhollist Due date: 2018-02-21

marcosci commented 6 years ago

Hey @maelle and @sckott,

thanks a lot for the effort :)

The font is used in the theme function (theme_nlm) and can be imported via util_import_roboto_condensed.

Which badge? :) There seems to be something missing in your reply.

maelle commented 6 years ago

Oops indeed! 🙀 [![](https://badges.ropensci.org/188_status.svg)](https://github.com/ropensci/onboarding/issues/188)

maelle commented 6 years ago

@laurajanegraham @jhollist thanks for accepting to review this package! 😺

Your review is due on 2018-02-21.

Please find here our reviewing guide and the review template.

maelle commented 6 years ago

@laurajanegraham @jhollist just a friendly reminder that your reviews are due on 2018-02-21 😸

jhollist commented 6 years ago

Starting to look at it now! I do have a question. Next week is crazy for me as it is school vacation week. OK for a 7-10 day extension?

maelle commented 6 years ago

@jhollist ok, thanks for the update! March the 1st?

jhollist commented 6 years ago

Perfect and thank you.

On Feb 16, 2018 11:35 AM, "Maëlle Salmon" notifications@github.com wrote:

@jhollist https://github.com/jhollist ok, thanks for the update! March the 1st?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/188#issuecomment-366287026, or mute the thread https://github.com/notifications/unsubscribe-auth/AFL8SyqLmwOuTY6ufoDmLMZA4r31u6a4ks5tVa46gaJpZM4RrS2f .

laurajanegraham commented 6 years ago

Hi,

Thanks for the reminder.

I have put time aside Monday and Tuesday to get this review done.

Cheers,

Laura

On 16 Feb 2018 16:51, "Jeffrey W Hollister" notifications@github.com wrote:

Perfect and thank you.

On Feb 16, 2018 11:35 AM, "Maëlle Salmon" notifications@github.com wrote:

@jhollist https://github.com/jhollist ok, thanks for the update! March the 1st?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/188# issuecomment-366287026, or mute the thread https://github.com/notifications/unsubscribe-auth/ AFL8SyqLmwOuTY6ufoDmLMZA4r31u6a4ks5tVa46gaJpZM4RrS2f .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/188#issuecomment-366291974, or mute the thread https://github.com/notifications/unsubscribe-auth/AFFAxGeEQEKLGiUlcp5583hUVTfLdVq-ks5tVbICgaJpZM4RrS2f .

maelle commented 6 years ago

Thanks a lot @laurajanegraham! 😃

maelle commented 6 years ago

@marcosci the branch that's stable for review is the master branch right? I see recent activity in the repo. 😉

marcosci commented 6 years ago

Yup :) But develop should also be stable, master contains only the CRAN versions :)

maelle commented 6 years ago

Ok, so which one should the reviewers review?

Can you confirm you're not undertaking any big changes in the package at the moment?

Thank you for your quick answer! 😃

marcosci commented 6 years ago

master makes more sense maybe, yes. We plan to integrate the ecomodtools package and I am in contact with the author - but there is no schedule for that yet :)

maelle commented 6 years ago

OK thanks.

If a big change is planned now, it might make sense to put the review on hold real quick, but as you say it's a plan for the future then that's fine.

marcosci commented 6 years ago

I think this is rather something for the next couple of months, so the review should not be affected.

laurajanegraham commented 6 years ago

Hi @maelle . It's taking me a little bit longer to do this review than I anticipate. I don't have too much left to do, but would you mind if I get it to you by Friday instead please due to other commitments? Thanks!

maelle commented 6 years ago

No problem, thanks for your work & this update!

laurajanegraham commented 6 years ago

Package Review

Hi @maelle and @marcosci, here is my review. I really like this package, and reviewing it has given me a good opportunity to get to know the features in more depth, so thanks both :)

Documentation

The package includes all the following forms of documentation:

Functionality

Final approval (post-review)

Estimated hours spent reviewing: 8

Review Comments

The package authors have provided a much needed collection of neutral landscape models for the R platform. I was pleased to see that it was not just a repackaging of the Python nlmpy package, but also provides additional neutral landscape models as well as some utility functions for visualising these landscapes. In terms of statement of need; the README provides a good explanation of the need for the package, but I would also add that it allows users to create NLMs within a self-contained, reproducible framework.

The code is mostly compact, efficient and follows the standards for rOpenSci packages. I have some concerns around the unit tests: the tests check that the output is of the correct form (class, size etc.), but do not go for edge cases, or try to break the functions. I have noted below some specific cases where functions either broke or did not work as expected.

One way in which I would suggest for improvement of the package would be to improve the documentation. It is mostly good, but the amount of information on the functions is variable. I have commented where I think specific functions could do with more documentation below. I do, however, see this as more of a long term thing, rather than something I'd expect to be improved as part of this review process.

The package name is sensible. It is, however, not in lower case as recommended by the packaging guide. The functions and variables all follow rOpenSci guidelines.

Functionality

Below I have outlined some issues I found with some of the functions. I think most of these are pretty easy fixes with the exception of nlm_fBm: I'm not entirely sure that this is fixable, unless I've misunderstood one of the arguments to the underlying RandomFields function, and without being able to include the full range of values, I think it may be better to remove this function.

metric_area: This function will only give the values of either one class, or all classes. For example:

library(NLMR)
x <- nlm_random(100, 100)
y <- c(0.5, 0.25, 0.25)
z <- util_classify(x, y)

metric_area(z, c(1,2))
## Error in `$<-.data.frame`(`*tmp*`, "class", value = c(1, 2)): replacement has 2 rows, data has 3

The problem is in the if(length(poi) == 1) statement. This is not necessary. Any input could be evaluated by the code inside of the if part. Additionally this outputs a dataframe for Proportion_Area, and not a tibble, as stated in the documentation.

nlm_curds & nlm_wheys:

nlm_edgegradient: The call to nlm_planargradient (L66) is misspecified. It should be gradient_raster <- nlm_planargradient(ncol, nrow, direction = direction)

or

gradient_raster <- nlm_planargradient(ncol, nrow, resolution, direction)

or change the order of the arguments to nlm_planargradient

nlm_fbm: 

fBm_raster  <- nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1.9)
## Error in rfInit(model = list("Simulate", setseed = eval(parse(text = "quote(set.seed(seed=seed))")), : searching a simulation method for 'RMfbm':  Running out of list of methods. Are the RFoptions() too restrictive?
##  You get (more) internal information if you set RFoptions(cPrintlevel=3) before running your code.
nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1, user_seed = 30)
## NOTE: simulation is performed with fixed random seed 30.
## Set 'RFoptions(seed=NA)' to make the seed arbitrary.
## class       : RasterLayer 
## dimensions  : 30, 20, 600  (nrow, ncol, ncell)
## resolution  : 1, 1  (x, y)
## extent      : 0, 20, 0, 30  (xmin, xmax, ymin, ymax)
## coord. ref. : NA 
## data source : in memory
## names       : layer 
## values      : 0, 1  (min, max)
nlm_fBm(ncol = 20, nrow = 30, fract_dim = 1)
## NOTE: simulation is performed with fixed random seed 30.
## Set 'RFoptions(seed=NA)' to make the seed arbitrary.
## class       : RasterLayer 
## dimensions  : 30, 20, 600  (nrow, ncol, ncell)
## resolution  : 1, 1  (x, y)
## extent      : 0, 20, 0, 30  (xmin, xmax, ymin, ymax)
## coord. ref. : NA 
## data source : in memory
## names       : layer 
## values      : 0, 1  (min, max)

nlm_gaussianfield:

nlm_mosaicfield:

nlm_mpd:

nlm_neigh:

nlm_polylands:

nlm_randomcluster:

nlm_randomrectangularcluster:

util_calc_boundaries and util_w2cp: should these be exported, or are they meant to be internal functions?

util_facetplot: is it possible to add a nrow or ncol option into here to control how the facet is laid out?

maelle commented 6 years ago

@laurajanegraham thanks a lot for your excellent review! 👌 👏

@marcosci you can keep the name of the package now that it's on CRAN, not a strict rule on our part. :-) you can wait for the second review before responding if you prefer!

marcosci commented 6 years ago

thanks @laurajanegraham for your effort - really appreciate it 👍 didn't find anything that should not be fixable in my head - will wait for Jeff and then go through your code and test comments.

and your definitely right - the documentation needs improvement ... we're on it. 🚶

jhollist commented 6 years ago

Top of my to-do list for next week and have already started it...

Like what I see so-far!

On Fri, Feb 23, 2018 at 11:19 AM, Marco Sciaini notifications@github.com wrote:

thanks @laurajanegraham https://github.com/laurajanegraham for your effort - really appreciate it 👍 didn't find anything that should not be fixable in my head - will wait for Jeff and then go through your code and test comments.

and your definitely right - the documentation needs improvement ... we're on it. 🚶

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/188#issuecomment-368057470, or mute the thread https://github.com/notifications/unsubscribe-auth/AFL8S3tDwD1jYHASL498g6qBu8MhJ1uNks5tXuUGgaJpZM4RrS2f .

-- Jeff W. Hollister email: jeff.w.hollister@gmail.com cell: 401 556 4087

jhollist commented 6 years ago

Here is my review! In short, I like the package and hope to find some uses for it. I also have review envy. Really nice job on your review, @laurajanegraham !!!

Any questions, let me know.

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

Documentation

The package includes all the following forms of documentation:

For packages co-submitting to JOSS

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

Final approval (post-review)

Estimated hours spent reviewing: ~ 8 hours

Review Comments

General Comments

The NLMR package provides a suite of functions to simulate neutral landscapes with multiple algorithms plus a set of utility functions for working with the resulting raster objects. As a landscape ecologist who cut his teeth when many of these neutral landscapes were being developed, seeing them implemented as an R package was exciting. Their implementation in NLMR is nice and the functions are straightforward to use. There are a few improvements that need to be made. When those are done I feel this will be a very nice addition to the rOpenSci suite of packages. That it is in my home field is a really nice added bonus. In short, very nice work. Now I need to find a reason to dig back into neutral landscape models!

Package Review Checklist

Few notes on the Package Review checklist above. I did not check off Vignettes, Community guidelines and Packaging guidelines. Details on each:

Specific Thoughts

See below for some more specific suggestions.

Package Scope

Some general thoughts and suggestions on the overal scope of the package. I personally am a fan of trying to keep packages as streamlined as possible. NLMR currently has two main types of functions, the nlm_ functions an the util_ functions. I could easily see these being split into to separate functions. If you do this it could faciliate re-naming the package (see above on NLMR vs nlmr) and creating a new "utilities" package. This works, I think, because it would make maintaing the pacakges easier, and would also get more exposure to some of the utlity functions which seem a bit more general purpose for rasters and not just neutral landscapes. Additionally, in issue 10 you suggest landscape metrics as a possible enhancement. I personally think incorporating that into NLMR would be a mistake since those types of functions have utility well beyond applications geared towards neutral landscapes. Many of the traditional "FRAGSTATS" type metrics already do exists in the `SDMTools' package, but that hasn't seen any updates in ~4 years. As such, developing a standalone landscape metrics package is, I believe, an excellent idea. In any event, I would encourage (and likely contribute to) a R landscape metrics package, but strongly believe that be done on its own and not incorportated into another pacakge.

Dependencies

Somewhat following on my discussion of scope are the number of dependencies that NLMR currently has. I prefer to keep my packages as light as possible and rely on base R whenever possible. I would like to see some thinning of the dependencies on this. For example, you import magrittr. While, I love magrittr in analysis workflows I avoid its use in packages as it is an unnecessary dependency and, in my experience, can make de-bugging a bit challenging. Look for opportunities like this to drop some of the packages you import.

Future-proofing

It is an exciting time to be working on spatial data in R, but also challenging becuase the underlying packages supporting spatial data in R are in a bit of flux. Currently, NLMR relies on raster and sp, which are the traditional spatial pacakges. However, with the release of sf, the development of stars, and discussions about the future of raster you will need to be actively thinking about how to make sure that NLMR stays relevant and incorporates the new directions for spatial data in R. And as I am writing this, I had the idea that this would be a good opportunity to split up the pacakge (e.g. see Package Scope). New and more streamlined packages could be developed that also build off of the newer and tidier set of spatial packages.

Misc

A few miscellaneous thoughts:

marcosci commented 6 years ago

thanks @jhollist - I like your thoughts, nice complement to Laura's comments :-)

Will tackle both reviews in the next days and report here.

maelle commented 6 years ago

Thanks a ton @jhollist, what a good review! 😃

Nice plan @marcosci! 😉

laurajanegraham commented 6 years ago

Aw thanks @jhollist . I like the suggestion of narrowing the package scope and splitting into two packages. The util functions definitely are useful beyond just NLMs.

I would also be interested in contributing to a standalone landscape metrics package, should this happen.

jhollist commented 6 years ago

Added two small things related to metric_area to my review above... Slipped through the cracks first time around.

maelle commented 6 years ago

A few notes:

Thanks again to both reviewers, and nice work until now @marcosci!

marcosci commented 6 years ago

Response to reviews

@laurajanegraham and @jhollist - thanks again for your reviews

We decided to follow the recommendations of Laura and Jeff to split the package. This leaves us with:

@maelle, you said:

By the way if you split the package, the one that'd still be a good fit for onboarding is the non-metrics one.

... my gut feeling says that only the nlmr package is now of interest and not the combination of landscapetools and nlmr (however this combination may look like - meta package, second onboarding issue, ...)? If I am mistaken, I will provide comments on the reviewers' remarks on the utility functions. Otherwise, I will focus for now on nlmr.

responses to @laurajanegraham comments

nlm_curds & nlm_wheys:

We combined both functions. You get the wheyed pattern now by providing the argument wheyes (#16). Since you recursively subdivide the landscape into smaller and smaller blocks, I can not think of an efficient way to implement this whole specifically controlling for nrow and ncol.

nlm_edgegradient:

We did that here #17.

nlm_fbm:

Values of fract_dim between ~1.56 and ~1.99 should work now if you set the RandomFields option to sloppy. You can do that now via the nlm_fBm function - we are not quite sure why you have to do this, but we contacted the maintainer of RandomFields and as soon as we know more, we will implement it. At least the functions produce now valid patterns for the whole range of fract_dim. We also implemented the rest of your comments, see #18.

nlm_gaussianfield

Made all perfect sense, we implemented everything you said #19.

nlm_mosaicfield

We fixed the issue with the loop - #20.

nlm_neigh

Again, we changed everything as you recommended :) #22

nlm_polylands

We changed the name of this function, splitted it and got rid of nlm_randomelement. nlm_randomelement and nlm_polylands both rely on the simulation of point pattern processes and a spatial interpolation of these patterns. Since we use the well-established spatstat package to simulate the point patterns, we do not need nlm_randomelement as a direct copy of its NLMpy equivalent and can combine the first option of nlm_polylands and nlm_randomelement.

The two new functions are: nlm_mosaictess (a unified version of option 1 on nlm_polylands and nlm_randomelement) and nlm_mosaicgibbs.

In nlm_mosaicgibbs we changed the function to control the hardcore process that creates the spatial point pattern, it should be faster now and takes fewer arguments to control the output.

All that should be in #23.

nlm_randomcluster

We had a look at that function again and completely changed it after your comments. Again, it was a direct copy as it is done in NLMpy - but the implementation in NLMpy is actually not the algorithm they cited as reference.

It is now a direct implementation of the random cluster algorithm by Saura et al. (2000), and you can control for all the parameters they state in their publication.

See our changes in #33.

nlm_randomrectangularcluster

Check: #25

Documentation

We did some pieces here and there and Craig is currently going through that again. Hope that is fine with you? :)

responses to @jhollist comments

Vignettes

We had a look on the way usethis is doing that (thanks @maelle for the hint), and for now only the getstarted vignette is part of the package. The rest is only visible on the homepage.

Craig is currently working on the vignettes and documentation to make it a bit more verbose, but we already got rid of the raster section.

Community guidelines

Check: #28

Package Scope

As stated at the beginning, by splitting the package the scope of them should be rather streamlined now.

Future proofing

We changed every function that used sp functions to sf, there is no direct dependency on sp anymore. However, I see no point at the moment to use stars. As far as I know, the future of the raster package is still rather vague - the last thing I have read was that 2D raster should find a unified home in raster as a single raster class and more dimensional raster should find their home in stars. If I am mistaken here, or you see a way to use stars here please let me know.

jhollist commented 6 years ago

First, I'd be honored to be the mascot!!! If time allows, would be happy to more than that too.

Second, very happy with the response and direction this is taking. Two thumbs up on everything and as far as my review is concerned, nlmr is good to go.

Again, really nice job. Makes me happy to see landscape ecology getting better representation in R!

marcosci commented 6 years ago

Response to reviews regarding the utility functions

With respect to the comments on slack yesterday, this issue is supposed to cover now both nlmr and landscapetools.

Again, you can find landscapetools here:

https://github.com/marcosci/landscapetools

responses to @laurajanegraham comments

util_calc_boundaries and util_w2cp

Both of the functions are only internal ones, for the reclassification function. I can't see any direct use of them - if I am mistaken, we can certainly make them public.

util_facetplot

You can now specify the number of rows and cols, see #26.

responses to @jhollist comments

util_import_roboto_condensed is this necessary?

I see some value in providing a font with better kerning pairs and geometrics numbers (compared to the default font ggplot uses). If the dependency on extrafont is not worth it in your opinion, we can definitely cut that.

... did I miss anything regarding the utility functions?

General

As discussed on twitter, I included both of you in the respective description of the packages - thanks a lot again :) And the mascot comment was just a joke - we would definitely benefit from your input Jeff :)

jhollist commented 6 years ago

A joke I appreciated! Also probably to most likely level of involvement I can promise. I am begrudgingly well entrenched in mid-career and as such time to work on things I want to is a rare commodity.

And again, nice job on these packages. I'll include a mention in a talk I am working on for US-IALE.

On Thu, Mar 22, 2018 at 6:00 AM, Marco Sciaini notifications@github.com wrote:

Response to reviews regarding the utility functions

With respect to the comments on slack yesterday, this issue is supposed to cover now both nlmr and landscapetools.

Again, you can find landscapetools here:

https://github.com/marcosci/landscapetools responses to @laurajanegraham https://github.com/laurajanegraham comments

util_calc_boundaries and util_w2cp

Both of the functions are only internal ones, for the reclassification function. I can't see any direct use of them - if I am mistaken, we can certainly make them public.

util_facetplot

You can now specify the number of rows and cols, see #26 https://github.com/marcosci/nlmr/issues/26. responses to @jhollist https://github.com/jhollist comments

util_import_roboto_condensed is this necessary?

I see some value in providing a font with better kerning pairs and geometrics numbers (compared to the default font ggplot uses). If the dependency on extrafont is not worth it in your opinion, we can definitely cut that.

... did I miss anything regarding the utility functions? General

As discussed on twitter, I included both of you in the respective description of the packages - thanks a lot again :) And the mascot comment was just a joke - we would definitely benefit from your input Jeff :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ropensci/onboarding/issues/188#issuecomment-375241071, or mute the thread https://github.com/notifications/unsubscribe-auth/AFL8S6VbHkX_ly9FwR2lcsbvpbODWHf7ks5tg3YhgaJpZM4RrS2f .

-- Jeff W. Hollister email: jeff.w.hollister@gmail.com cell: 401 556 4087

laurajanegraham commented 6 years ago

All looking great @marcosci!

maelle commented 6 years ago

Thanks a lot for your work @marcosci and thanks @jhollist & @laurajanegraham for very productive reviews! 🎊

A few last comments from me:

Now here is the list of things you have to do before I close this issue 😉

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, @stefaniebutland will be in touch about content and timing.

marcosci commented 6 years ago

Yeah 🙌

@maelle comments

In all three repos, I think it'd make sense to comment a bit on all of them, maybe in a "See also" section.

You mean crossreferencing nlmr and landscapetools in the readmes of the packages? :)

Add the pkgdown link to DESCRIPTION, see http://enpiar.com/2017/11/21/getting-down-with-pkgdown/ "if you already have a URL there (say, to your package’s GitHub repository), you can add a second URL to your pkgdown site, separated by a comma"

Done.

In the pkgdown website (of landscapetools in particular) you might want to make the grouping of functions in reference more useful. See https://github.com/dirkschumacher/ompr for an example

Done.

@maelle list of things

And we would be more than happy to write a blog post :smile:

maelle commented 6 years ago

Thanks!

Yes I meant cross-referencing with a short blurb explaining how they relate to each other.

I've now made you an admin of both repositories (so you can access the repo description again for instance) and will activate them on Appveyor.

maelle commented 6 years ago

Appveyor badges

Closing this since the blog post discussion can still happen once it's closed. :-)

maelle commented 6 years ago

I forgot two points @marcosci 🙈

marcosci commented 6 years ago

I am here to serve 😜 all done.

maelle commented 6 years ago

😂 thx a ton!

stefaniebutland commented 6 years ago

Glad to hear you're interested it writing a post @marcosci. Here are some technical and editorial guidelines: https://github.com/ropensci/roweb2#contributing-a-blog-post

We ask that you submit a draft via pull request at least one week before the planned publication date. At this point I have posts scheduled through April so perhaps best for you to suggest a deadline by which you would like to submit a draft.

marcosci commented 6 years ago

Hi @stefaniebutland and thanks :-) Would the last couple of days in April be fine to hand in the draft for the blog post?

stefaniebutland commented 6 years ago

Yes @marcosci end of April for a draft is good. Tentative publication date is Tues May 8 so latest to submit draft is May 1st. Thanks!