Proposing feature requests to the R Core Team
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.
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
- (Based on a comment from @Matifou) Check whether your idea has been previously discussed on
[email protected]. Although the archives don't provide a search interface, you can do a Google search prefixed withsite: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 ... - 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
sweepa 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 ... - 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.
- Try to find an existing utility or "misc" package to contribute to (for example, I have contributed to Jim Lemon's
plotrixpackage, which is a compilation of small plotting utilities), and contact the maintainer/author. - 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.