What things do you think should be covered in a package review?

[stephlocke]

We can do a lot of different things in a package review. What do you think should be included?

[maelle]

Random suggestions

• typos via devtools::spell_check ()

• URLs to repo and issues tracker in DESCRIPTION

[stephlocke]

Path construction with paste

This needs automation to be adopted:

1. CI using lintr/gp: "Probable path construction using paste0 at line..." https://twitter.com/noamross/status/852185834648461312

[noamross]

• Somewhat meta, but checking for continuous integration
• consistency in function naming, functions only have dots if they are S3 methods
• check README.Rmd as a vignette, to ensure it builds
• "coverage" in examples and vignettes

(maybe opinionated=TRUE does things like require snake_case functions, prefers xml2 to XML, code of conduct etc.)

[maelle]

Reg. the second point in @noamross's list maybe use lintr

[rorynolan]

Unit testing, i.e. the existence of a non-empty tests/ directory in the source.

[maelle]

Reg. unit testing maybe it'd also be useful to count the skip_on_something commands in the tests.

[zkamvar]

User-readable errors and warnings (bonus: with suggestions). Relying on some other function to tell the user they have a character string instead of a data frame is asking for trouble.

[stephlocke]

Great idea @zkamvar !

[stephlocke]

Documentation Comments DOI Tests Use cases https://twitter.com/tpoi/status/856517513533935618

[cderv]

Some ideas:

• NEWS file to document new features in release
• At least one vignette about usage or use cases.
• unit test
• not all functions in one R script.
• assertive checks in function to help user with error

[Hendrik147]

There need to be some clear statements on what the package does better than other packages and possibly clearness on known package limitations.