This guide is intended to help you get the most out of the R mailing lists, and to avoid embarrassment. Like many responses posted on the list, it is written in a concise manner. This is not intended to be unfriendly - it is more a consequence of allocating the limited available time and space to technical issues rather than to social niceties.
The list: Remember that R is free software, constructed and maintained by volunteers. They have various reasons for contributing software and participating on the mailing lists, but often have limited time.
Good manners: Remember that customs differ. Some people are very direct. Others surround everything they say with hedges and apologies. Be tolerant. Rudeness is never warranted, but sometimes `read the manual’ is the appropriate response. Don’t waste time discussing such matters on the list. Ad hominem comments are absolutely out of place.
Questions about statistics: The R mailing lists are primarily intended for questions and discussion about the R software. However, questions about statistical methodology are sometimes posted. If the question is well-asked and of interest to someone on the list, it may elicit an informative up-to-date answer. See also the Usenet groups sci.stat.consult (applied statistics and consulting) and sci.stat.math (mathematical stat and probability).
Basic statistics and classroom homework: R-help is not intended for these.
Which list: R-help, R-package-devel, R-devel, or Bioconductor? There have been two, now three widely used mailing lists for questions and discussion about R and a list dedicated more specifically to issues in the use of bioconductor packages and bioinformatics. R-help is intended to be comprehensible to people who want to use R to solve problems but who are not necessarily interested in or knowledgeable about programming. R-package-devel has been created in May 2015 specifically to help R package authors in writing and checking their R packages, notably those meant for CRAN. R-devel is intended for questions and discussion about R development and programming. Questions likely to prompt discussion unintelligible to non-programmers should rather go to R-devel than R-help. Questions about package development, however, e.g., passing
R CMD check should go to
R-package-devel rather than R-devel. For example, questions involving C, C++, etc. code should go to R-devel. More general questions involving pure R code and questions likely to be of interest to the large and diverse set of subscribers to R-help should go to R-help.
Bioconductor is for announcements about the development of Bioconductor, availability of new code, questions and answers about problems and solutions using Bioconductor, etc. See Bioconductor mailing lists for details. See below for questions on contributed packages.
Platform-specific questions: There are lists R-sig-Mac, R-sig-Debian and R-sig-Fedora for R on Mac OS X, Debian/Ubuntu and Fedora/Redhat respectively. Questions specific to those platforms (especially re installation and the R.app GUI on Mac OS X) are more likely to get informed responses on the appropriate list, and that is certainly the place to discuss possible bugs.
Do your homework before posting: If it is clear that you have done basic background research, you are far more likely to get an informative response. See also Further Resources further down this page.
apropos("keyword")with different keywords (type this at the R prompt).
RSiteSearch("keyword")with different keywords (at the R prompt) to search R functions, contributed packages and R-Help postings. See
?RSiteSearchfor further options and to restrict searches.
?prod, at the R prompt)
Technical details of posting: See General Instructions for more details of the following:
Surprising behavior and bugs: What you think is a bug may be many other things, such as a default behavior that you do not like, a feature, an undocumented feature, or a bug in the documentation. You do not need to commit yourself to one of these in order to ask a question. If it is a real bug, someone will notice it. Before you post a real bug report, make sure you read R Bugs in the R-faq. If you’re not completely and utterly sure something is a bug, post a question to r-help, not a bug report to r-bugs - every bug report requires manual action by one of the R-core members. Also, see Simon Tatham’s essay on How to Report Bugs Effectively.
For questions about unexpected behavior or a possible bug, you should, at a minimum, copy and paste the output from
sessionInfo() into your message. When mentioning version numbers, always use the full version number, e.g., `2.6.1’, not just `2.6’, and also mention the platform (Windows, Linux, MacOS X, with their versions). Other potentially relevant details include the locale (type
Sys.getlocale() at the R prompt), and whether you installed a pre-compiled binary version of R or compiled it yourself. If the function is in a package other than `base’, include the header output from
library(help=thatPackage). If you are using an old version of R and think it does not work properly, upgrade to the latest version and try that, before posting. If possible, try the current R-patched or R-devel version of R (see the FAQ for details), to see if the problem has already been addressed.
For questions about functions in standard packages distributed with R (see the FAQ Add-on packages in R), ask questions on R-help.
If the question relates to a contributed package , e.g., one downloaded from CRAN, try contacting the package maintainer first. You can also use
packageDescription("packagename") to find this information. Only send such questions to R-help or R-devel if you get no reply or need further assistance. This applies to both requests for help and to bug reports.
Don’t say `R crashed’, which you may take to mean that R gave an error and terminated your piece of code, but most people will take to mean abnormal termination of the R program. Say exactly what happened, including any error messages you received.
Examples: Sometimes it helps to provide a small example that someone can actually run. For example:
If I have a matrix x as follows: > x <- matrix(1:8, nrow=4, ncol=2, dimnames=list(c("A","B","C","D"), c("x","y")) > x x y A 1 5 B 2 6 C 3 7 D 4 8 > how can I turn it into a dataframe with 8 rows, and three columns named `row', `col', and `value', which have the dimension names as the values of `row' and `col', like this: > x.df row col value 1 A x 1 ... (To which the answer might be: > x.df <- reshape(data.frame(row=rownames(x), x), direction="long", varying=list(colnames(x)), times=colnames(x), v.names="value", timevar="col", idvar="row") )
When providing examples, it is best to give an R command that constructs the data, as in the
matrix() expression above. For more complicated data structures,
dump("x", file=stdout()) will print an expression that will recreate the object
Further resources: not always consulting these before posting is OK, except perhaps if you have a very general question and the topic of the document indicates immediate relevancy. A response might just point you towards one of these.
Responding to other posts:
4*runif(1)at the R prompt, and wait this many hours
Common posting mistakes:
It is a skill to ask good questions. If at first you don’t get the answers that are useful to you, don’t get discouraged. A response that is concise and technically accurate may be just that, and not an intended putdown. If you feel insulted by some response to a post of yours, don’t make any hasty response in return - you’re more likely than not to regret it. Read Eric Raymond’s essay How To Ask Questions The Smart Way for more suggestions, and for insight into people’s behavior on technical mailing lists (but don’t try asking people at catb.org questions about R).
Posters should be aware that the R lists are public discussion lists and anything you post will be archived and accessible via several websites for many years.
Compiled by Tony Plate (tplate at acm dot org), most recently updated July, 2013