Reviewer response for version 1
The article describes an R package (gprofiler2) that wraps around the REST interface of a g:Profiler web service. 
The paper outlines the method used to access the API, and explains that providing an R API makes it easier to integrate with the functionality of other R packages. 
The description of the software is sufficient and complementary to the source code repository (and backed by a Zenodo archive). 
The examples given nicely demonstrate the functionality and I tried many of them in rstudio (some comments below). 
The visualisation, as is most functionality, is inherited from the website, and as such benefits from a larger user base.
The choice of the combination of having the code base under version control, archiving on Zenodo, and distribution via CRAN shows high-quality standards. 
A test suite, unfortunately, is missing, and adding it is recommended. 
Furthermore, it could be interesting to explore curl as a replacement of RCurl, as I had trouble with SSL certificates with the RCurl package on Windows (but not essential).
I can build the package from source. 
When applying a regular CRAN check on the package I get a couple of warnings and notes, but none that are affecting this paper. 
I left two source code suggestions: https://github.com/egonw/r-gprofiler2/pull/1 .
I also like to note that I found out that the interactive plot does not seem to work in RStudio: I only get an empty window.
Regarding the content of the article, I have the following questions. 
First, the argument that the computation is done on a central server as an advantage depends on the use case and is not generally true. 
For example, it requires all information to be shared with the server, which is not possible for everyone that may be interested in the server. 
As such, one could imagine having a Docker with the webservice and method parameters in the R package to interact with servers with a different domain or IP address. 
This is, however, just a future feature request.
Second, regarding the data used in the functionality, I have three questions. 
How is the ordering of pathways in for KEGG, Reactome, and WikiPathways defined? 
For Reactome, I can imagine their own hierarchy is used. 
What about KEGG and WikiPathways? 
Is the Pathway Ontology used for the latter? 
A similar question applies when using custom GMT files? 
The ordering is then defined by the other in the file, I assume? 
Finally, in the Reproducibility section, but it is not clear to me why version information is not given for the data GO, KEGG, Reactome, etc. 
I would strongly suggest providing that information too. 
I would suggest clarifying the first two in the manuscript, but the last one may require additional functionality. 
Alternatively, the article should be clear that version information is only given for a subset of used resources.
A third topic I like to ask about is the following: 
If g:Profile is an ELIXIR RIR, have you consider adding the option to use the Identifiers.org prefixes, e.g. "wikipathways" in addition to "WP"?
Fourth, the "Use case" uses packages that need to be installed. 
The keep symmetry with the description of gprofiler2 itself, please consider adding install instructions for these Bioconductor packages.
Last, I collected a number of small textual suggestions and have annotated these with hypothes.is: https://hyp.is/rE4tRurJEeqMHW_RYqO0xA/f1000research.com/articles/9-709 .
These suggestions include a number of title fixes in the bibliography where article titles are all converted to lower case, which looks weird for names of tools.
Structure
Recap
Recap
Strength
Strength
Recap
Strength
Todo
Todo
Other
Other
Other
Weakness
Structure
Weakness
Weakness
Other
Other
Other
Todo
Other
Todo
Todo
Todo
Todo
Weakness
Todo
Todo
Todo
Structure
Todo
Recap
Todo
Other
Todo