Proposing feature requests to the R Core Team [closed]

Answer 1

At useR this year, Brian Ripley told an anecdote that explains the R-core team's stance. He said he accepted a two line patch to a function from a well respected R programmer (John Chambers, if I remember rightly). The two lines of code contained three bugs (!), which he then had to fix. Since then, R-core's default position is to refuse feature requests for R-base, even those with supplied code. (Bug fix requests are fine, as long as you've treble-checked that it really is a bug. Use the R Bug Tracking System for this.)

While it isn't impossible to get something into R-base it is almost always significantly (p < 1e-6) easier to create a package yourself or add to an existing one.

Answer 2

This is a great question. While really liking R a lot, I find its development model frustrating at times. I would say the best options are

0. (Based on a comment from @Matifou) Check whether your idea has been previously discussed on r-devel@r-project.org. Although the archives don't provide a search interface, you can do a Google search prefixed with site:stat.ethz.ch/pipermail/r-devel (e.g. site:stat.ethz.ch/pipermail/r-devel sweep). Nabble also provides a searchable interface but is ugly and ad-heavy ...
1. post the initial idea (without extensive code) to R-devel and see if you can get discussion/enthusiasm going. You have to be willing to push: for example, I managed to get some additional error-checking incorporated in sweep a few years ago (having it actually complain about mismatched dimensions rather than silently returning the wrong answer), but only after proposing the idea; waiting a week; re-raising the idea; sending some prototype code; testing it to make sure it didn't cause a performance hit; further discussion ...
2. implement your idea as an add-on package. This is of course much harder if what you propose is a change to core R functionality (on the other hand, that kind of change will also be much harder to get accepted). On the other hand, you can implement just about anything you want in an add-on package, and it has several advantages. (1) Your code will be available for everyone to use immediately (if you post on R-forge, Rforge, GitHub, or CRAN); (2) it is a way for the ideas to get developed and refined without buy-in from R core; (3) even if it never gets accepted in R-core, it will still be around as a package.
3. Try to find an existing utility or "misc" package to contribute to (for example, I have contributed to Jim Lemon's plotrix package, which is a compilation of small plotting utilities), and contact the maintainer/author.
4. Post your wish-list items to the R bug tracker (with code attachments etc.). However, they will get seen by many fewer people than if you use options #1 or #2, and as a result are more likely to languish in the bug tracker without ever seeing the light of day.

Answer 3

You are very unlikely to get new features into base R itself, unless i) it piques the interest of one of the R Core Development Team, or ii) is an extension of existing functionality that improves the way it works or makes it more efficient and a member of R Core is sufficiently interested. You can of course file a bug under the Wish list criterion, and provide code, but do not be surprised if the R Core Team don't accept totally new features even if they come with code.

The reasons for this stance have been discussed before; Even if you provide code implementing new feature X for inclusion in R, you are passing the maintenance burden on to the R Core Team and these guys have limited resources and time to do this. The R Core Team effectively develop the base of R for their own interests/research/needs.

As R packages are almost first-class citizens, there is little reason to even ask R core to implement or include your code for feature X. So, as others have said, implement your ideas features in your own package or contribute them to another package that already provides code related to your new feature X.

Even incredibly useful packages that are widely used, e.g. data.table are unlikely to make it into base R in the short-medium term because they increase the complexity of the code base, have a maintenance burden on the R Core Team, and/or are not drop in replacements for existing code; data.table provides a data frame-like extension that is incredibly fast and better suited to large data sets and "queries" on those data. It is not compatible with R's data frame though, employing different conventions. It works well as a package and can continue to do so as such without needing to be in R.

The above describes the situation as I see it for new features. For bug reports, file a bug report! Then consider following up with further discussion on R-Devel quoting the bug report ID. Patches provided to support your bug report will make it easier for bugs to be fixed or new features/enhancements added. The patch should include both the R sources that need changing plus a patch to any documentation that needs to change as a result. The patch should be against the SVN tree found at the R SVN server. As @BenBolker mentions in the comments, bug reports are best filed in R's bug reporting website. Any discussion of the bug on R-Devel should link to the bug report. This way bugs don't fall into cracks and get missed.

Answer 4

The usual way is to write a package, and get it onto CRAN. (All announcements sent to the package list get copied to rhelp.) Then using demonstrating its productive use on rhelp (or perhaps SO) will get it noticed. I'm thinking here of the efforts over the years of Hadley Wickham, Dirk Eddelbuettel, Terry Therneau, Gabor Grothendieck, Frank Harrell, and Matthew Dowle, to name the first six contributors coming to mind who have made my R efforts more productive. Actually as I was writing that list, it kept getting longer and I apologize to several other people that have made contributions I use often.