Prepare for release:

• Check current CRAN check results
• Polish NEWS
• devtools::build_readme()
• urlchecker::url_check()
• devtools::check(remote = TRUE, manual = TRUE)
• devtools::check_win_devel()
• rhub::check_for_cran()
• rhub::check(platform = 'ubuntu-rchk')
• rhub::check_with_sanitizers()
• revdepcheck::revdep_check(num_workers = 4)
• Update cran-comments.md
• Review pkgdown reference index for, e.g., missing topics

Submit to CRAN:

• usethis::use_version('major')
• devtools::submit_cran()
• Approve email

Wait for CRAN...

• Accepted 🎉
• usethis::use_github_release()
• usethis::use_dev_version()
• Tweet

The README invokes and links to the Contributor Code of Conduct, but i was not able to find guidance on how to seek support, report issues, or contribute to the package. (GitHub also indicates that contributing guidelines are missing.) Typically this is done in a CONTRIBUTING file in the root or in the .github folder. Such guidelines are a requirement for publication in JOSS.

Part of this JOSS review.

I've prepared functions to implement network efficiency and information centrality on igraph objects. See the following repository for this function with the accompanying unit tests and documentation: https://github.com/TomKellyGenetics/info.centrality

I've wrapped this function in it's own package but could merge it with the "netrankr" package if feasible. If there is interest in doing so I can add this function to a fork of the devel branch and submit a pull request. In this case I will check if the "info.centrality" function is consistent with other centrality functions.

This package was suggested on an issue on the "rigraph" package:
igraph/rigraph#256 (comment)

• print
• summary
• plot

Great! Thanks for that!

One suggestion, at least for the index-calculating functions. I think it would make sense if they all would share the same first two arguments:

1. The graph.
2. Vertex ids for which the index will be calculated.

Just like igraph::betweenness for example. If one is interested in scores for only subset of vertices, or specific vertex, it will speed-up computation quite a bit.

This is more interpretative a question and not a review condition. rank_intervals() returns not only the intervals of each node's centrality rank range but their midpoints, which are NB'd to be different from the nodes' expected ranks. I gather that they are also not, in general, the nodes' median ranks. Are the midpoints theoretically interesting, or are they just a plotting convenience to anchor the intervals?

In case they are not intrinsically interesting, i would expect them to be more often than not misinterpreted or at least accorded undue importance by analysts, and i would suggest reconsidering them. (I apologize if this is explained in one of the papers; i have not read them thoroughly.)

Part of this JOSS review.

I expect that the centrality index builder is quite useful for anyone not proficient with R. It is natural to use, so i understand why it has minimal documentation, but i believe it would be helpful to include a sentence there about how the gadget works and what packages it depends on.

Part of this JOSS review.

The benchmarking vignette is compelling (and the availability of approximation methods is impressive), but i am unable to check the results for lack of source code. Certainly the vignette should not itself reproduce this analysis, but i believe the code, or code for a smaller, illustrative benchmarking test, should be included—with the repository if not with the package, e.g. in a folder ignored by the R build.

Part of this JOSS review.

The vignettes in this package are, on the whole, exemplary. I appreciate that each addresses a specific topic so that none grow to impractical length.

The vignette "Indirect relations in networks" has an obvious limitation: A reader who is not executing code along the way cannot see or interpret the results. While too many matrices of indirect relations are calculated to all be printed, it would be helpful for one or two (e.g. for a predefined relation and for a custom relation adapted from it) to be printed and compared (element-wise subtraction or division? juxtaposed visualizations?).

This won't hold up my review, but i believe it would make this functionality more readily accessible. : )

Part of this JOSS review.

• dbces
• florentine_m

The example graph used in the paper is not a real-world example but (i gather) a graph contrived to have different central nodes according to various common centrality measures. This is as it should be, given the purpose of the package! But i believe the graph should be introduced as such when used as an example.

So far only undirected and unweighted networks are supported.

vertex names are lost when calculating indirect relations and rank probabilities.

I guess this is to be fixed:

* checking for missing documentation entries ... OK
* checking for code/documentation mismatches ... WARNING
Codoc mismatches from documentation object 'exact_rank_prob':
exact_rank_prob
  Code: function(P, only.results = TRUE, verbose = FALSE, force =
                 FALSE)
  Docs: function(P, only.results = T, verbose = F, force = F)
  Mismatches in argument default values:
    Name: 'only.results' Code: TRUE Docs: T
    Name: 'verbose' Code: FALSE Docs: F
    Name: 'force' Code: FALSE Docs: F

Codoc mismatches from documentation object 'get_rankings':
get_rankings
  Code: function(data, force = FALSE)
  Docs: function(data, force = F)
  Mismatches in argument default values:
    Name: 'force' Code: FALSE Docs: F

* checking Rd \usage sections ... OK

In the installation, I'm receiving the following error message: Error : object ‘hcl.colors’ is not exported by 'namespace:grDevices'. This was a new feature in R-3.6 . Is there an archived version compatible with R-3.5?

Currently the root directory contains two license files: LICENSE and LICENSE.md. The first is cited in DESCRIPTION, but the second was created to address another reviewer's request. I believe CRAN requires and only recognizes the first name, so it would be helpful and possibly necessary to combine these into a single file, named 'LICENSE' but with the content of the Markdown file.

Part of this JOSS review.

I ran goodpractice::gp(), which flagged a few practices that might be changed to make code less fragile (though the quality of the code overall seems solid):

• sapply() can return different structures, especially when simplify is not set to FALSE; vapply() is more stable.
• F and T are variables that can be redefined; FALSE and TRUE are more stable.
• The single-colon operator : can produce unexpected output on edge cases; the seq_*() functions are more stable.

It also indicated that only 65% of code lines are covered by tests.

While i follow these practices myself, i leave it to the developers to decide for themselves; they will not affect my review. : )

Part of this JOSS review.

The index_builder addin for Rstudio is broken. Only prebuild Indices can currently
be used.