Skimr

[elinw]

Summary

• What does this package do? (explain in 50 words or less):
  Creates compact and flexible data summaries that are pipeable and display nicely in the console. For a given data frame or vector the skim function provides a useful set of summary statistics (based on the class of the individual vector/column) that allows users to skim their data to get an overall sense of what is included, extent of missing values, and similar information. The skim generic can be extended by users to other data structures.

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

Package: skimr
Title: Compact and Flexible Summaries of Data 
Version: 0.9.92
Authors@R: c(
  person("Amelia", "McNamara", email="amcnamara@smith.edu", role = "aut"),
  person("Eduardo", "Arino de la Rubia", email="earino@gmail.com", role = "aut"),
  person("Hao", "Zhu", email="haozhu233@gmail.com", role = "aut"),
  person("Julia", "Lowndes", email="lowndes@nceas.ucsb.edu", role = 'ctb'),
  person("Shannon", "Ellis", email="sellis18@jhmi.edu", role = "aut"),
  person("Elin", "Waring", email="elin.waring@gmail.com", role = "cre"),
  person("Michael", "Quinn", email="msquinn2@illinois.edu", role = "aut"),
  person("Hope", "McLeod", email="hmgit2@gmail.com", role = 'ctb'),
  person("Hadley", "Wickham", email="hadley@rstudio.com", role = 'ctb'),
  person("Connor", "Kirkpatrick", email="hello@connorkirkpatrick.com", role = 'ctb')
  )
Maintainer: Elin Waring <elin.waring@gmail.com>
Description: A simple to use summary function that can be used with pipes
    and displays nicely in the console. The default summary statistics may be 
    modified by the user as can the default formatting. Support for data frames 
    and vectors is included, and users can implement their own skim methods for
    specific object types as described in a vignette. Default summaries include
    support for inline spark graphs. Instructions for managing these on 
    specific operating systems are given in the Using skimr vignette and the 
    README.
Depends:
    R (>= 3.1.2)
Imports:
    dplyr (>= 0.7),
    magrittr,
    pander,
    purrr,
    rlang,
    stats,
    stringr,
    knitr,
    tibble (>= 0.6),
    tidyr (>= 0.7),
    tidyselect
Suggests:
    extrafont,
    rmarkdown,
    testthat,
    withr
License: GPL-3 + file LICENSE
Encoding: UTF-8
LazyData: true
URL: https://github.com/ropenscilabs/skimr
BugReports: https://github.com/ropenscilabs/skimr/issues
VignetteBuilder: knitr
RoxygenNote: 6.0.1
Collate: 
    'skimr-package.R'
    'formats.R'
    'stats.R'
    'functions.R'
    'options.R'
    'skim.R'
    'skim_print.R'
    'skim_v.R'
    'summary.R'

• URL for the package (the development repository, not a stylized html page):
  https://github.com/ropenscilabs/skimr

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

"tools" Because skimr provides users with a way to get started with a new, unknown data set (by getting a quick overview (or skim) of the data that is readable and compact. It also serves as a good tool for reporting summary information about data.

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

• People who want to get a quick overview of a data set while initially reviewing, iteratively cleaning, or sharing with others.
• Beginning statistics students who need simple access to a set of basic descriptive statistics.

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

This is intended as an improved version of the r core summary functions available. Like summary, skim is a generic that users can extend to any R data object. It is designed to be somewhat like a more flexible version of fivenums() from stats or favstats() from the Mosaic package.

•   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, Coeveralls 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.
  • (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:

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

[karthik]

👋 @elinw
Thanks very much for this submission. I will assign an editor shortly and we will then work through the editor checklist before we assign reviewers. We normally strive to get the process started within 5 business days. But we are approaching winter break (I'll be offline all of next week). So in the chance that we are not able to assign an editor/reviewers in the next two days, you'll see an update to this thread in the first week of January.

[maelle]

@elinw thanks for your submission & sorry about the delay! I've seen development is still active, do you consider skimr stable enough for review? It'd be best not to change too many things while the reviewers are looking.

[maelle]

The tests now pass on my laptop using the latest testthat version, thanks @jimhester for the help!

He suggested to add testthat (>= 2.0.0) in DESCRIPTION.

[elinw]

Yes, as of now we have fixed the Windows issue in master. I'm about to push one more change and then I'm going to tag 1.0.1 sometime today. I'll definitely update the testthat minimum first.

[maelle]

And you can confirm that 1.0.1 will be good for review? I even have two reviewers lined up once you confirm that. 😄

[elinw]

Yes it will be.

[maelle]

Editor checks:

• [x ] Fit: The package meets criteria for fit and overlap
• [ x] Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• [ x] License: The package has a CRAN or OSI accepted license
• [ x] 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 again for your submission, if I understand correctly the version for review will be ready today?

• Add testthat minimal version in DESCRIPTION.

• You don't need to fill the Maintainer field in DESCRIPTION, it'll get filled from Authors@R

goodpractice output for you and the reviewers to have in mind

It is good practice to

  ✖ write short and simple functions. These functions have high cyclomatic
    complexity:kable.data.frame (60).
  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor
    windows that are about 80 characters wide. Try make your lines shorter than 80
    characters

    R\skim.R:14:1
    R\skim.R:73:1
    R\stats.R:28:1
    R\stats.R:52:1
    R\stats.R:64:1
    ... and 20 more lines

Two typos identified via devtools::spell_check()

differnt      skimr-package.Rd:16
faciliates    skim_to_wide.Rd:19

---

Reviewers: @jimhester @jenniferthompson
Due date: 2018-01-30

[maelle]

@jimhester and @jenniferthompson thanks for accepting to review this package! Your reviews are due on the 2018-01-30. 😺

You'll find here the review template and our reviewing guide.

[elinw]

Thanks for the quick checks. I have done the easy ones, but there is one issue that we can't fix and two I'd like feedback on.

1. The complex function one is a function that is brought in from knitr so we can't do anything about that. So in our code it is just
   kable.data.frame <- knitr::kable

2. In terms of long lines, the ones that remain are in tests of the print function so they are the full printed line. If we don't do that we get the tibble wrap which defeats the idea of testing the whole line. On the other hand if we want we could split those strings into two parts and then paste0() them which would keep the lines under 80 but still give us a correct version that is the full line. Does it make sense to do that? Or does that actually make the tests themselves harder to read?

3. We have some things that are only run for windows_os and those are the lines showing up without code coverage in good practices. We've excluded them from testing on Travis since the code will never be hit on Linux or Mac. Is it possible to write conditional exclusions so that the tests would run when built on Windows?

[jimhester]

You can run covr on appveyor as well, and the coverage reports will be automatically merged by codecov.

[elinw]

Cool, just add the same line to appveyor.yml?
- Rscript -e 'covr::codecov()'

[jimhester]

Appveyor needs to use double quotes and you can add it to on_success:

on_success:
  - Rscript -e "covr::codecov()"

And I think you may need to add your codecov token to the appveyor settings. You can get the token at https://codecov.io/gh/ropenscilabs/skimr/settings, and add it as CODECOV_TOKEN at https://ci.appveyor.com/project/ropenscilabs/skimr/settings/environment

[michaelquinn32]

Thanks Jim! It seems to be working after ropensci/skimr@c34cec7

[elinw]

Release 1.0.1 should be in CRAN at this point. @michaelquinn32 is doing some refactoring that should be invisible to end users, and we have plans for updating some tests and documentation (and some feature requests) but other than that things are stable.

[maelle]

@jimhester and @jenniferthompson friendly reminder that your reviews are due on Tuesday next week 😸

[jenniferthompson]

@michaelquinn32 @elinw FYI, I'm getting a "Project not found or access denied" error when I try to look at the Appveyor page via clicking the README badge. I'm not experienced in CI, so I'm not sure if that should have been addressed with the fix Jim mentioned a couple of weeks ago.

[jenniferthompson]

Also, if I've caught some typos in the vignettes/examples, would y'all like a PR or no?

[jimhester]

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.

---

Review Comments

All review comments are based off of version 1.0.1. Overall I feel like the
package would be a welcome addition to rOpenSci after the review process is complete.

README

• Get rid of ## Dev mode: on at the top.
• devel installation instructions better written as
  devtools::install_github("ropenscilabs/skimr@develop") (not sure it is
  necessary to mention the develop branch at all here)
• A markdown file should not have a yaml header and this file should really
  be built from a README.Rmd included in the repository.
  usethis::use_readme_rmd() is a good way to set this up.
• Should have links to kable() and pander(), and possibly include
  examples of what 'enhanced' options are available and what they look like.

skim

Displaying the results of skim() as seemingly a table, but having the
underlying data as a table in a different format is quite surprising. I pretty
strongly think that you should have two functions, one which returns the
summary information in a wide format, the other in the long format. e.g. From
the print output I would expect to be able to run the following to retrieve
variables in the dataset with standard deviations greater than 1

skim(iris, Sepal.Length, Petal.Length) %>%
  filter(sd > 1) %>%
  pull(variable)

but this instead throws a pretty confusing error

Error in filter_impl(.data, quo) :
  Evaluation error: comparison (6) is possible only for atomic and list types.

Because the data is actually in long format.

skim(iris, Sepal.Length, Petal.Length) %>%
  filter(stat == "sd", value > 1) %>%
  pull(variable)

Gives you the expected output.

As the print method hides this dichotomy I think this will cause users
confusion which would be best remedied by having two different functions. A
simple solution would be to return the skim_to_wide() representation from
skim(). Or maybe instead have a series of functions

• skim_wide()
• skim_long()
• skim_list()

Regardless of the exact API I think you should think hard about making it more
obvious the results of skim() are not simple rectangular tables.

I realize this is somewhat challenging because you have separate output for
different column types. Another possible solution which would require minimal
API changes is to modify the print method to make the heterogeneous parts more
clear.

skim_with

Designing skim_with() as a impure function which modifies global state seems
an odd choice when it could instead be written as a functional which returned
skim() functions with alternate defaults. Beside the impurity concerns it
also makes it more difficult to use different types of skim functions
interchangeably. If you really want the impure interface you could do so by
defining skim_with_defaults() with the same interface as skim_with() and an
implementation that simply calls the pure skim_with() function and assigns
the result as the new default.

Vignettes

Having the 'Using Fonts' vignette be a rmarkdown template is kind of strange,
also I think it might be worth listing a few fonts which do support all the
features needed for the sparklines / historgrams would be useful.

Miscellanea

get_funs() has a very weird implementation, particularly because it's behavior seems equivalent to double square bracket. e.g.
options$functions[["numeric"]] gives equivalent output to get_func("numeric"), likewise for get_func("xyz") (which is NULL).

The code inherited from
pillar
should have a comment nearby indicating such, so that you can more easily track
upstream changes if the pillar implementation changes in the future.

I really think you should reconsider changing min and max to p0 and
p100. min() and max() are self explanitory, but I would need to read the
quantile documentation to be sure that p0 is guaranteed to be the minimum
value in the distribution not subject to rounding error. I would actually
prefer dealing with -Inf and Inf in the all NA case to using
quantile(probs = 0).

[maelle]

Thanks for your review @jimhester! 😸

[jenniferthompson]

skimr Package Review

Jennifer Thompson

This review is of skimr version 1.0.2, downloaded from Github 2018-01-29. Other relevant info: R version is 3.4.3; devtools version is 1.13.4.

• As the reviewer I confirm that there are no conflicts of interest for me to review this work.

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 Yes, but see below
• 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: 5

---

Review Comments

skimr is a very, very useful package that is generally well thought in terms of both simplicity and extensibility. I particularly appreciate a thorough vignette for the main functions, intuitive function names, and the attention to where many users are likely to run into trouble, along with the proactive explanation of potential solutions. skimr does a specific set of tasks and does them simply and well. The source code is easy to digest in both style and function, and the comments are abundant, clear and helpful.

I do agree with Jim that it's confusing to have the printed output be a completely different format from what is output to the console; I'm most excited about (and expect) the wide format printed, vs the long data.frame returned. Perhaps have the default skim() return a named list, with an element for each data type containing the "wide" format as a data.frame, and have a skim_long that returns the current long data frame.

Some specific suggestions:

• README:
  • Clarify first bullet - "added missing, complete, n, sd" to what?
  • Suggested edit for brevity to statement of need: "skimr provides a frictionless approach to summary statistics which conforms to the principle of 'least surprise' [link to description of this principle], displaying summary statistics the user can skim quickly to understand their data. It handles different data types and returns a skimr object which can be included in a pipeline or displayed nicely for the human reader."
  • Remove YAML output at the top.
• Really helpful vignette for skim() - great work showing common use cases and some really helpful functionality. Made it easy to add my own summary statistics. I did find a few typos and can include these in a PR if desired.
• Examples in help files:
  • I'm not sure skim_format(.levels = list(nchar = 4)) is working. I changed the value of this argument several times, and skim(iris) looked the same every time, both printed and as a data.frame. Could be user error but I couldn't figure out how to make it affect the output.
  • ?skim: group_by example doesn't actually group by anything (works when I group by Species)
  • I'm not clear on the benefit of having the fonts vignette as an RMarkdown template. Also, it's not showing up as an option for me in RStudio (I only have HTML vignette and Github document, even with skimr loaded).
  • Would be helpful to show an example of skim_tee() - I'm not totally clear on when it's beneficial.
• The inline histograms are really helpful for truly continuous variables. Is it possible to make them smarter/more flexible? When I skim a numeric discrete variable with 5 levels (skim(sample(c(1:5, NA), size = 20, replace = TRUE))), I get a histogram with what appears to be 8 bars.
• Community guidelines: Provide links to contributing.md, Google style guide and CONDUCT.md.
• The error message when a variable has infinite values (produced via dplyr::cut, I think) could be clearer - could be a good warning message to include up front.
• I'd prefer p50 to median, particularly if you stick with p0 and p100. (In terms of workflow, I do prefer NAs to -Inf/Inf, though :) )

Overall I'm excited to use this package in my own work, and really appreciate the hard and thoughtful work of all the authors.

[maelle]

Thanks for the update @elinw and congrats on the release! 🎊 I guess you'll soon write the "final" answer to reviewers then?

[elinw]

@maelle That's the plan. I wanted to add that we now have in the develop branch a solution to the other issue that I think folks here and in our tracker have wanted. That is now you can define your own complete list of functions with a name and use skim_with() to append or replace the default skimmers. So the way I think about this the use case would be that you have several different lists that you use for different situations e.g. my_funs1, my_funs2, my_funs3. Then you still have to do two steps but it is e.g.

skim_with(.list = my_funs1, append = FALSE)
skim(x)
skim_with(.list = my_funs2, append = FALSE)
skim(y)
skim_with(!!!my_funs3, append=FALSE)
skim_with_defaults()

I think if this were part of your usual workflow you might write your own functions so you don't need to do that append=FALSE and .list=.

There's also a PR making it so that if you define an empty list of functions for a type that type is removed from the analysis.

[maelle]

Cool work! 😸 Thanks for the update.

[maelle]

@elinw Any update? 😺

[maelle]

@elinw @michaelquinn32 any update? ☺

[elinw]

Hi, Yes I think the development branch pretty much has addressed all, I just wanted to put in Jenny’s suggestion to make the display a bit nicer. I’ll do that once I recover from the unconfirmed! And then I think we could call it ready and everything else in terms of possibly changing the API etc will be for 2.0.

…

On May 22, 2018, at 1:32 PM, Maëlle Salmon ***@***.***> wrote: @elinw <https://github.com/elinw> @michaelquinn32 <https://github.com/michaelquinn32> any update? ☺ — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#175 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuEfd3bjl5B7xuc5tO8gmbV3rr7HvyJks5t1HX7gaJpZM4RIge_>.

[maelle]

Ok thanks. Don't hesitate to notify the reviewers in person 😉

[elinw]

Okay here's an update @jimhester @jenniferthompson @michaelquinn32
As of now all changes have been merged into the master branch, and I'm planning to do a release of 1.0.3 because I got a message from Brian Ripley about a typo in a test (I can't believe that all the eyes that looked at this before missed it).
I think we have responded to all of the issues except the possibility of changing the API. Michael has written a road map for skimr 2.0 that addresses that along with some architectural issues. But I think over the course of the discussion here and in the skimr repository we all came to agreement that cosmetic changes that make the fact that the skim print results do not represent a single data frame more clear would be okay for skimr 1.

[michaelquinn32]

Changes for 2.0 are in this doc.
https://docs.google.com/document/d/18lBStDZzd1rJq08O-4Sw2qHhuHEZ79QX4sBkeyzWNFY/edit?usp=sharing

I'm writing tests for the next version right now.

[maelle]

Thanks for the updates @elinw and @michaelquinn32, very cool to see such active development!

@jimhester and @jenniferthompson , are you happy with the current version of skimr?

[jimhester]

LGTM

[jenniferthompson]

Very likely! I'm traveling and won't have time to look at the latest version till next week, but will do asap.

[maelle]

Thanks @jimhester!

@jenniferthompson, thank you, we'll wait for your input next week, happy travels!

[jenniferthompson]

Sorry for the delay, y'all (jet lag is very real) - just looked at the updated version and it looks super! 🎉 Awesome work, @elinw @michaelquinn32.

Going to check out the version 2.0 roadmap now 🏃‍♀️

[elinw]

Thanks @jenniferthompson @jimhester!

[michaelquinn32]

I really appreciate all of the hard work everyone has put in. skimr has improved in so many ways thanks to this process. Thanks!

[maelle]

Approved! 🎊 Thanks a ton @jimhester and @jenniferthompson for your reviews and @elinw and @michaelquinn32 for your development work!

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

• Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. I'll make you both admins once you do.
• Fix any links in badges for CI and coverage to point to the ropensci URL. We don't transfer Appveyor projects from personal accounts any more but since the project is under ropenscilabs we'll transfer it to ropensci account, once you've transferred the repo I'll activate the project.
• add rOpenSci footer to README
  [![ropensci_footer](https://ropensci.org/public_images/ropensci_footer.png)](https://ropensci.org)
• 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.

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.

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.

[maelle]

@elinw @michaelquinn32 👋 could you soon tackle the list above? Thank you! 😃

[elinw]

Planned for this weekend! Elin

…

On Jun 30, 2018, at 7:53 AM, Maëlle Salmon ***@***.***> wrote: @elinw <https://github.com/elinw> @michaelquinn32 <https://github.com/michaelquinn32> 👋 could you soon tackle the list above? Thank you! 😃 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#175 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAuEfYN1nk4oe9ge7tHOpAXahKbV1TYzks5uB2bLgaJpZM4RIge_>.

[elinw]

• Transfer the repo to the rOpenSci organization under "Settings" in your repo. I have invited you to a team that should allow you to do so. I'll make you both admins once you do.
• Fix any links in badges for CI and coverage to point to the ropensci URL. We don't transfer Appveyor projects from personal accounts any more but since the project is under ropenscilabs we'll transfer it to ropensci account, once you've transferred the repo I'll activate the project.
  add rOpenSci footer to README
• 
• 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.

About Appveyor that currently doesn't have a badge because of some problem we had before but we do run it off of @michaelquinn32's account. So what to do? We're happy to start from scratch on it.

[maelle]

You can keep the Appveyor project under @michaelquinn32's account if you prefer!

[elinw]

I think it makes sense to put it in ropensci.

[maelle]

Closing this, we can sort out CI details elsewhere and this way the peer-review badge will become green. 😉

[stefaniebutland]

@elinw Tired of writing about skimr yet? Or might you be interested in writing a post for the rOpenSci blog?

[elinw]

@jimhester @jenniferthompson @maelle I think we are finally close to release for v2 which addresses most of the issues we discussed, specifically the format of the skim object. We still need to rewrite vignettes and the readme. We'll be adding a pkgdown site although we're not making that as a blocker for the release. I think there is one important issue to resolve. (We'll probably do one more v1 release since we have fixed a few issues there in the past month.) @michaelquinn32 anything to add?

[maelle]

Once you have the vignette I'd recommend making the pkgdown website right away because it'll be little effort and will allow you to put the link in DESCRIPTION before you submit the new version to CRAN 😉