ijtiff

[rorynolan]

Summary

• What does this package do? (explain in 50 words or less):
  Correctly import TIFF files that were saved from ImageJ and write TIFF files than can be correctly read by ImageJ. Full support for TIFF files with floating point (real-numbered) pixels. Also supports text image I/O.

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

Package: ijtiff
Type: Package
Title: TIFF I/O for 'ImageJ' Users
Version: 0.1.0
Authors@R: c(person("Rory", "Nolan", email = "[email protected]", 
                    role = c("aut", "cre", "cph")),
             person("Sergi", "Padilla-Parra", email = "[email protected]", 
                    role = "ths"))
Maintainer: Rory Nolan <[email protected]>
Description: Correctly import TIFF files that were saved from 'ImageJ' and write 
    TIFF files than can be correctly read by 'ImageJ'. Full support for TIFF files
    with floating point (real-numbered) pixels. Also supports text image I/O.
License: GPL-3
SystemRequirements: libtiff
Encoding: UTF-8
LazyData: true
Depends: R (>= 3.4.0)
RoxygenNote: 6.0.1
URL: https://github.com/rorynolan/ijtiff
BugReports: https://github.com/rorynolan/ijtiff/issues
Roxygen: list(markdown = TRUE)
VignetteBuilder: knitr
Imports: checkmate,
    RSAGA,
    magrittr,
    filesstrings (>= 2.0.0),
    stringr,
    purrr,
    Rcpp,
    tiff,
    fields,
    grDevices,
    readr,
    abind
Suggests: knitr,
    testthat,
    rmarkdown,
    covr
LinkingTo: Rcpp

• URL for the package (the development repository, not a stylized html page):
  https://github.com/rorynolan/ijtiff
• Please indicate which category or categories from our package fit policies this package falls under *and why(? (e.g., data retrieval, reproducibility. If you are unsure, we suggest you make a pre-submission inquiry.):

[e.g., "data extraction, because the package parses a scientific data file format"]
Data extraction, because the package can import (correctly) a common type of TIFF file that is not currently well-supported in R.

• Who is the target audience?
  R users who also use ImageJ, or who collaborate with people who use ImageJ.
• 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's another R package for TIFF I/O, but it does not interface well with ImageJ (which I would argue is very important). It's also not actively maintained (I'm not getting responses when I file an issue).
•   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:

• [ y] does not violate the Terms of Service of any service it interacts with.
• [ y] has a CRAN and OSI accepted license.
• [ y] contains a README with instructions for installing the development version.
• [ y] includes documentation with examples for all functions.
• [ y] contains a vignette with examples of its essential functions and uses.
• [ y] has a test suite.
• [ y] has continuous integration, including reporting of test coverage, using services such as Travis CI, Coeveralls and/or CodeCov.
• [ y] 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

• [ y] Do you intend for this package to go on CRAN?
• [ y] Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • [y ] The package has an obvious research application according to JOSS's definition.
  • [ y] The package contains a paper.md matching JOSS's requirements with a high-level description in the package root or in inst/.
  • [ y] The package is deposited in a long-term repository with the DOI: 10.5281/zenodo.1068230
  • (Do not submit your package separately to JOSS)
• [n ] 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.
  • (Please do not submit your package separately to Methods in Ecology and Evolution)

Detail

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

• [ y] 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:
  Andrzej K. Oleś (aoles)

[sckott]

Thank you for your submission @rorynolan 😸

It's a good fit for rOpenSci - and we'll assign an editor asap

[sckott]

(@rorynolan is there a way to instal ImageJ on osx 10.13 (High Sierra), seems I don't need it to run your pkg, but still curious)

[sckott]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Thanks for your submission @rorynolan !!

Goodpractice output for you and reviewers to consider:

It is good practice to

  ✖ write unit tests for all functions, and all package code
    in general. 72% of code lines are covered by test cases.

    src/common.c:21:NA
    src/common.c:22:NA
    src/common.c:59:NA
    src/common.c:60:NA
    src/common.c:61:NA
    ... and 196 more lines

  ✖ avoid calling setwd(), it changes the global environment.
    If you need it, consider using on.exit() to restore the working
    directory.

    R/write.R:37:13
    R/write.R:38:5
    tests/testthat/test_graphics.R:5:11
    tests/testthat/test_graphics.R:6:3
    tests/testthat/test_io.R:4:11
    ... and 18 more lines

Seeking reviewers now 🕐

---

Reviewers: @jeroen @jonclayden
Due date: 2018-01-18

[rorynolan]

Hi @sckott,
To install ImageJ for Mac, head to https://imagej.net/Fiji/Downloads and download Fiji. Fiji stands for "Fiji Is Just ImageJ," but what it really is is ImageJ packaged up nicely with some add-ons which is easy to install. Kind of like a version of R that comes with the tidyverse installed.
To any potential reviewers, with regard to the goodpractice output, I've covered as much of the code lines as I can, and you'll notice that wherever I've used setwd(), I do indeed use on.exit() to restore the working directory.
Thanks for your selfless work.
Rory

[sckott]

ah right! i totally forgot about fiji - i did use it in the past, but forgot. thanks for the help

[sckott]

still seeking reviewers 🕐

[sckott]

Reviewers are @jeroen @jonclayden - Due 2018-01-18

[jeroen]

Review

Thank you for your submission and for introducing me to ImageJ!

ROpenSci is working on improving image processing/analysis tools in R and you are doing interesting work in this space. We should see if we can collaborate more in the future.

Main Points

The readme explains that ijtiff can be used to read tiff files that were written by ImageJ and that it may also work for some other tiff files. As a user who is not familiar with ImageJ I am confused about what this means. It would be nice to elaborate about how ImageJ tiff files are different from regular tiff files:

• Are there multiple tiff formats?
• Are these ImageJ files still proper tiff format or some derivative format?
• Does ijtiff read/write additional image metadata ?

Perhaps you should emphasize support for high dimensionality (multi frame) tiff images which I think that this is mainly about? Or am I missing something?

Example

The readme example image has 2 channels of 5 frames but does not explain what each channel contains. How does the user know what color or channel type the data is? Perhaps a 'real world' visible image data would be more helpful.

If we read the example image using the 'magick' package we get 10 frames with 1 channel instead of 5 frames with 2 channels.

library(magick)
path_2ch_ij <- system.file("img", "2ch_ij.tif", package = "ijtiff")
image_read(path_2ch_ij)

Is this a bug in ImageMagick (ignoring some tiff property) or a custom property of ImageJ to group frames into channels?

I am curious if some of ijtiff functionality could also be accomplished with the magick package? The benefit of ImageMagick is that it is not limited to tiff but will work for any image format. For example:

library(magick)
path <- system.file("extdata", "bleached.tif", package = "detrendr")
img <- magick::image_read(path)
frames <- lapply(img, image_data)

Can you write a little bit in your readme or vignette about what additional functionality ijtiff adds?

Small comments

I tried this example image from the ImageJ website: https://imagej.nih.gov/ij/images/Composite.tif. However it gives an error when reading this with ijtiff. Is this expected?

Why Depends: R > 3.4 ? Unless you are using features that are only available in R 3.4 it would be nice to be less restrictive so that the package can also be used on older versions of R.

Make sure you add the missing PROTECT() statements from: https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/ijtiff.out

Package does not build out of the box on Windows as promised. I will send a PR to fix this :)

[jonclayden]

Package Review

• As the reviewer I confirm that there are no conflicts of interest for me to review this work (If you are unsure whether you are in conflict, please speak to your editor before starting your review).

Documentation

The package includes all the following forms of documentation:

• A statement of need clearly stating problems the software is designed to solve and its target audience in README
• Installation instructions: for the development version of package and any non-standard dependencies in README
• Vignette(s) demonstrating major functionality that runs successfully locally
• Function Documentation: for all exported functions in R help
• Examples for all exported functions in R Help that run successfully locally
• Community guidelines including contribution guidelines in the README or CONTRIBUTING, and DESCRIPTION with URL, BugReports and Maintainer (which may be autogenerated via Authors@R).

For packages co-submitting to JOSS

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

The package contains a paper.md matching JOSS's requirements with:

• A short summary describing the high-level functionality of the software
• Authors: A list of authors with their affiliations
• A statement of need clearly stating problems the software is designed to solve and its target audience.
• References: with DOIs for all those that have one (e.g. papers, datasets, software).

Functionality

• Installation: Installation succeeds as documented.
• Functionality: Any functional claims of the software been confirmed.
• Performance: Any performance claims of the software been confirmed.
• Automated tests: Unit tests cover essential functions of the package and a reasonable range of inputs and conditions. All tests pass on the local machine.
• Packaging guidelines: The package conforms to the rOpenSci packaging guidelines

Final approval (post-review)

• The author has responded to my review and made changes to my satisfaction. I recommend approving this package.

Estimated hours spent reviewing: 3

---

Review Comments

This review is based on the package as of commit rorynolan/ijtiff@8bfa0ac. I realise some further commits have been made recently, but I need a stable reference point to base my comments on. Feel free to disregard any comments that no longer apply.

The ijtiff package has a clear purpose and straightforward, intelligible user interface. It follows the rOpenSci packaging guidelines closely, and appears to work as intended. Interoperability with ImageJ is indeed important in many scientific fields. I hope the following specific comments and suggestions are helpful.

1. The vignette is quite bare-bones. In particular, it doesn't set the scene, explaining why ImageJ generates TIFF files of the kind that it does, and why it is important to interpret them correctly in R. I would also suggest briefly explaining channels and frames in general, and (if appropriate) ImageJ's usage of them in particular. I would expect that "text images" may not be familiar to all readers—they weren't to me!—so perhaps you could also explain what they are.
2. At 71% overall, test coverage is respectable, although it is 42% for common.c and 59% for read.c, which perhaps could be improved.
3. The tests of write_tif()'s error handling take a long time to run, presumably because of the need to generate a very large vector. Is there any way around this?
4. The need for using setwd() isn't clear to me—although, admittedly, on.exit() is used to ensure that the working directory is always reverted. In the tests, it seems like it would be sufficient to use tempfile()s, which will be cleaned up by R. In write_tif() I note the comment that, "I've noticed that write_tif() sometimes fails when writing to far away directories". I'm happy to try and help get to the bottom of that if I can.
5. The ijtiff_img() function partially duplicates the functionality of the base function structure(), which sets a series of attributes on its first argument. I would suggest use of the latter to simplify the function.
6. In display(), it would be more transparent, and probably more idiomatic, to specify default pass-through parameters explicitly in the function arguments, viz. display <- function(img, axes = FALSE, col = grDevices::grey.colors(999,0,1), ...).
7. Is there a reason that namespace notation is used for required packages that are used everywhere, like checkmate? Would it not be cleaner just to import the package namespace? In my view using explicit namespace notation only really makes sense for suggested (rather than required or imported) dependencies.

[sckott]

Thanks for your reviews @jeroen and @jonclayden !

@rorynolan reviews are now in. There's no one way to respond to reviewers, but here's some examples of responses to reviewers that we like:

• weathercan #160 (comment)
• New submission: tidyhydat #152 (comment)
• Submission: comtradr #141 (comment)

[rorynolan]

Responding to @jeroen

Main Points

• Are there multiple tiff formats? Are these ImageJ files still proper tiff format or some derivative format?
  • No. The README now better explains that the main difference is that ImageJ has a weird (and I would say bad) way of encoding channel information, but the TIFF files that it writes are still bona fide TIFFs, not a different/derivative format. Please read the new README section entitled The peculiarity of ImageJ TIFF files and let me know if I have now succeeded in making it clear what the deal is with ImageJ TIFF files.
• Does ijtiff read/write additional image metadata ?
  • It writes to the TIFFTAG_SOFTWARE field to say that the TIFF was written with ijtiff. I have now mentioned this in the README. It currently reads all the TIFF tags that the original tiff package did and sets them as attributes to the read ijtiff_img object. In future, I plan to include all tags listed on https://www.awaresystems.be/imaging/tiff/tifftags.html as metadata when reading, and the option to write them.
• Perhaps you should emphasize support for high dimensionality (multi frame) tiff images which I think that this is mainly about? Or am I missing something?
  • This is more about reading channel information correctly. The original tiff package could read multi-frame images quite effectively, so ijtiff is not really a step forward in that regard. Admittedly, the confusion caused by the weird way ImageJ writes channel information is heightened with multi-frame images, but the point of ijtiff is really to deal correctly with channel information. I hope this is now clear from the new sections in the README.

Example

• The readme example image has 2 channels of 5 frames but does not explain what each channel contains. How does the user know what color or channel type the data is? Perhaps a 'real world' visible image data would be more helpful.
  • I've now changed my example to the banana cheerleader in front of the R logo that you use in your magick package and I've gone to more effort to make clear what the channels and frames represent. I hope you don't mind me using it, happy to remove it if you mind.
• If we read the example image using the 'magick' package we get 10 frames with 1 channel instead of 5 frames with 2 channels. Is this a bug in ImageMagick (ignoring some tiff property) or a custom property of ImageJ to group frames into channels?
  • I'm sure that this is just that ImageMagick doesn't account for the weird way in which ImageJ (sometimes) encodes channel information in TIFFTAG_DESCRIPTION. Personally, I think this is more of a problem with ImageJ than with ImageMagick.
• I am curious if some of ijtiff functionality could also be accomplished with the magick package? The benefit of ImageMagick is that it is not limited to tiff but will work for any image format. Can you write a little bit in your readme or vignette about what additional functionality ijtiff adds?
  • I do a lot of imaging fluorescence correlation spectroscopy (FCS) and that type of image processing. For purposes like this, it's best to have images as numeric arrays. Also, having viewed an image in ImageJ, I think it's the most understandable form of image representation, rather than a list whose elements are 2D or 3D arrays; for most cases, the list elements all have the same type and dimension, so the list is perfectly good to be represented as a numeric array. To get to an array with magick, one has to go through image_read() %>% lapply(image_data) %>% lapply(as.numeric) %>% purrr::reduce(abind, along = 4) which is OK, but a bit of a pain compared to read_tif(). Furthermore, like tiff and EBImage, magick reads the pixel values scaled to [0, 1], which is not the native TIFF representation. Some analyses like FCS are not scale-invariant, so this scaling needs to be undone to proceed. I prefer to hand the user the data in its native representation and to let them scale it if they want.
    In short, the functionality that ijtiff adds over magick is that is doesn't miss the weirdly encoded channel information from ImageJ and it gives the ImageJ user who is beginning to use R their data in the format they're most likely to expect and want. I hope that this is now clear from the README and vignette.

Small Comments

• I tried this example image from the ImageJ website: https://imagej.nih.gov/ij/images/Composite.tif. However it gives an error when reading this with ijtiff. Is this expected?

  • You've uncovered a weird one here. The error is TIFFFillStrip: Invalid strip byte count 0, strip 1. This is saying that TIFFTAG_STRIPBYTECOUNTS is either missing or zero (I can't tell which), but using ImageJ, I can open the image and I can see that TIFFTAG_STRIPBYTECOUNTS is equal to 143640. This makes sense because the image is 171x140 pixels, 3 channels and 16-bit (or 2-byte) and 171x140x3x2==143640. However all of ijtiff, tiff and magick error when trying to read this image which tells me that somewhere within TIFFFillStrip, libtiff is failing to figure our that TIFFTAG_STRIPBYTECOUNTS has value 143640. It's beyond me to fix this. With ijtiff, I can correctly read Images that tiff and magick read incorrectly, but I'm not able to read images that they can't read at all.

• Why Depends: R > 3.4 ? Unless you are using features that are only available in R 3.4 it would be nice to be less restrictive so that the package can also be used on older versions of R.

  • This was just me being silly. This is fixed now.

• Make sure you add the missing PROTECT() statements from: https://raw.githubusercontent.com/kalibera/cran-checks/master/rchk/results/ijtiff.out

  • Done.

Package does not build out of the box on Windows as promised. I will send a PR to fix this :)

• This is another weird one. Before (when I just put the onus on the user to configure libtiff before installing ijtiff), the package worked fine on CRAN. Now (after your kind PR), it works on 64-bit windows on CRAN, but not on 32-bit. It just crashes when read_tif() is called in examples and tests. AppVeyor suffers the same issue as CRAN (crashing in the 32-bit case). I need help to get around this, I can't think of how to fix it. The build errors are not informative, in fact they're blank. I've found the same sort of error (failing on 32-bit CRAN windows but not on 64-bit) at [R] fix for the 32 bit windows issue dmlc/xgboost#2994, along with their fix for it, but I'm not sure how their case relates to ijtiff, if at all.
  • For now, I've edited Makevars.win to do it's thing on 64-bit Windows only, since I can't get to the bottom of the 32-bit issue. This makes everything work fine on CRAN (but now 32-bit Windows users have to take care of installing libtiff themselves). I've also set AppVeyor to run on 64-bit architecture only so that it passes.

Finally

• ROpenSci is working on improving image processing/analysis tools in R and you are doing interesting work in this space. We should see if we can collaborate more in the future.
  • I'm delighted that you find my work interesting and I'm very keen to help, contribute and collaborate in any capacity.

Thank you for your review and for going to the considerable bother of a PR. I really appreciate it and I think the package is already much improved thanks to you.

PS @jonclayden, currently working on a response to your comments.

[rorynolan]

Responding to @jonclayden

1. The vignette is quite bare-bones. In particular, it doesn't set the scene, explaining why ImageJ generates TIFF files of the kind that it does, and why it is important to interpret them correctly in R. I would also suggest briefly explaining channels and frames in general, and (if appropriate) ImageJ's usage of them in particular. I would expect that "text images" may not be familiar to all readers—they weren't to me!—so perhaps you could also explain what they are.

• I've now addressed this in the The Peculiarity of ImageJ TIFF files, Frames and Channels in TIFF files and Text Images sections of the vignette.

2. At 71% overall, test coverage is respectable, although it is 42% for common.c and 59% for read.c, which perhaps could be improved.

• A lot of the code in read.c and common.c is taken straight from Simon Urbanek's tiff package. There's a lot of code in there that I can't quite get my head around and that I can't see how to test (in my tests I read and write all kinds of images). However I feel it's safer to leave it in there than to remove it, as it probably caters for some edge cases that I have not foreseen. It's a shame that Urbanek's tiff package isn't unit tested.

3. The tests of write_tif()'s error handling take a long time to run, presumably because of the need to generate a very large vector. Is there any way around this?

• This test is unnecessary so I've just removed it.

4. The need for using setwd() isn't clear to me—although, admittedly, on.exit() is used to ensure that the working directory is always reverted. In the tests, it seems like it would be sufficient to use tempfile()s, which will be cleaned up by R. In write_tif() I note the comment that, "I've noticed that write_tif() sometimes fails when writing to far away directories". I'm happy to try and help get to the bottom of that if I can.

• I've removed all setwd()s from the tests in favour of tempfile()s. In write_tif(), when trying to write to a far away directory e.g. a/b.tif, I would get an error message like cannot write to 'a/b.tif'. The use of setwd() completely fixes this (for reasons unknown to me). I would appreciate your help on this, however, given that the workaround works, it's not a priority. More important is to get the package working on 32-bit Windows on CRAN (see my comment to @jeroen above regarding his PR).

5. The ijtiff_img() function partially duplicates the functionality of the base function structure(), which sets a series of attributes on its first argument. I would suggest use of the latter to simplify the function.

• Thanks, this is now done. I never knew about the structure() function.

6. In display(), it would be more transparent, and probably more idiomatic, to specify default pass-through parameters explicitly in the function arguments, viz. display <- function(img, axes = FALSE, col = grDevices::grey.colors(999,0,1), ...).

• This is now done, although I still have axes hidden from the user because the type of axes that fields::image.plot() offers can be confusing as they reverse the indices of the pixels on the y axis. I don't want to have an easy option of axes = TRUE because that's more trouble than it's worth.

7. Is there a reason that namespace notation is used for required packages that are used everywhere, like checkmate? Would it not be cleaner just to import the package namespace? In my view using explicit namespace notation only really makes sense for suggested (rather than required or imported) dependencies.

• I was following the advice in http://r-pkgs.had.co.nz/namespace.html#imports. I like it this way because I don't have to go to the bother of library(checkmate) to step through a function that uses functions from checkmate line-by-line.

Thanks a lot for all your comments and suggestions @jonclayden. I really appreciate the time you're putting into this.

[jonclayden]

Thanks, Rory, for the quick response. I think the vignette is much clearer and more helpful now. The namespace syntax is really a matter of taste, so if you prefer it as it is then that's perfectly fine. (Hadley slightly contradicts himself, though, as he says to "always" use ::, and then two paragraphs later says, "If you are using functions repeatedly, you can avoid :: by importing the function with @importFrom pkg fun." 🤔)

The working directory issue is odd. Thanks for clarifying what you mean by a far-away directory, but I don't seem to be able to replicate the problem locally (with the relevant part of write_tif() commented out). Perhaps it is specific to certain paths (maybe those containing spaces somewhere?) or platforms. Unfortunately I don't know much about building packages on Windows, so I can't add much to the discussion on that front.

It's great to see more interest in image processing in R. Thanks again for your contribution!

[sckott]

(FYI, jeroen is on vacation for another two weeks, so likely won't get a response until then)

[sckott]

@jeroen are you happy with the maintainers response to your review? any other thoughts/comments?

[sckott]

@jeroen are you happy with the maintainers response to your review? any other thoughts/comments?

[jeroen]

Sorry for the delay. The updated readme is a big improvement, it's more clear now what problem exactly the package is solving. I think it's good to go.

I'll see if I can figure out what's going on with my 32bit windows libs.

[sckott]

is the 32bit windows libs thing something we should wait on here, or something for later?

[jeroen]

The author has already pushed to cran, it's fine.

[rorynolan]

Yeah sorry for jumping the gun and pushing to CRAN. The reason was that the old package was throwing some CRAN check errors and the CRAN maintainers were bugging me to fix them ASAP.
Regarding the 32bit libs, I think it's fine. It builds automatically on 64-bit windows and 32-bit users have to install libtiff themselves before installing ijtiff, which is not a big hassle. If it's not an easy fix, I'm sure @jeroen's talents would be better spent elsewhere.
Thanks for all your work on this @jeroen, I'm really grateful for it, very selfless of you.
Also thanks @sckott for making all of this happen. This is the most helpful review process I've ever experienced.

[sckott]

Thanks @rorynolan for the udpate.

I'll have a quick look over it ...

[sckott]

Approved! Thanks again for your submission @rorynolan

• Please transfer the package to ropensci- I've invited you to a team within our ropensci organization. After you accept you should be able to move it. You'll be made admin once you do.
• Make sure to
  • add rOpenSci footer to README
    [![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)
  • Change any needed links, such those for CI badges
  • Travis CI should update to the new location automatically - you may have to update other CI systems manually
• Add the ropensci review badge to your README

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

• Please do add a .github dir and the 3 files inside of it, see https://github.com/ropensci/dotgithubfiles/

---

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

[rorynolan]

Thank you @sckott for a wonderful review experience!

• I have transferred the project to ropensci and done all the stuff with links and badges and the .github stuff.
• I am interested in writing a longer form blog post 👍

Finally, can you tell me how the JOSS paper proceeds from here?
Thanks again!
Rory

[sckott]

@stefaniebutland ping on the longer form blog post ^^

[sckott]

Great, thanks @rorynolan and glad you enjoyed it!

For JOSS:

• I'ved added a Zenodo webhoook to your repo. Generate a new release associated with a git tag in your repo. This doesn't mean you have to submit to CRAN with that git tag/release, its just to get a Zenodo DOI - and you can put a zenodo badge in your readme
• Then submit your paper.md to JOSS at http://joss.theoj.org/papers/new

[stefaniebutland]

@rorynolan Glad to hear the review experience worked well for you and doubly glad you're interested in writing a post.

Here are some editorial and technical guidelines: https://github.com/ropensci/roweb2#contributing-a-blog-post. Here are some other posts in the onboarding series https://ropensci.org/tags/review/

We ask for a draft to be submitted by pull request a week prior to the publication date so that we have a chance to give you feedback. What do you think of March 20 for draft submission? If you submit earlier, it does give us an opportunity to post earlier if someone else postpones.

[rorynolan]

Hi @sckott,
I'll get to that JOSS stuff in the next few weeks. Is there any rush on it?
Thanks again for everything,
I've signed up as an ROpenSci reviewer to give something back!
Rory

[rorynolan]

Hi @stefaniebutland,
I'm happy with March 20 for draft submission. I have time to do it next week.
Thanks,
Rory

[sckott]

Is there any rush on it?

i don't know, is there any timing to consider between approval here and submission to JOSS @noamross ?

[stefaniebutland]

I'm happy with March 20 for draft submission.

Sounds good! I'll confirm your publication date after receiving your draft. Don't hesitate to ping me here if you have any questions.

[rorynolan]

Hi @stefaniebutland,
I just submitted the PR for my blog.
Thanks,
Rory