Proposing feature requests to the R Core Team [closed]

问题

What's the recommended way/workflow of contacting the R Core Team in order to propose feature requests?

By "feature requests" I do not simply mean firing something like "I'd like to see functionality XY doing XY, so it'd be cool if you'd go ahead and implement that for me" but proposing actual code instead.

I love R and am willing to contribute, share code and all. Yet sometimes I find it a bit hard to figure out just exactly how to contribute ;-) I've looked at the R Project Developer Page and used the r-devel mailing list a couple of times. Especially with respect to the latter, I've gotten the impression that it's not the right place / not desired to elaborate one's feature request with actual code (which can sometimes be more than just a two liner). So I wonder if there's a "better" or more "systematical" way in order to do that.

EDIT 2011-11-09

I was asked to provide a short example:

I'm using S4 Reference Classes extensively and implemented a lot of little utility functions for my objects. One such utility function is some sort of a "reset" functionality:

setRefClass(
    "A", 
    fields=list(a="numeric", b="character"),
    methods=list(
        reset=function(fields=NULL, ...){
            temp <- new("A")
            if(is.null(fields)){
                fields <- names(getRefClass("A")$fields())
            }
            sapply(fields, function(x){
                .self$field(name=x, value=temp$field(x))        
            })
            return(TRUE)
        }
    )
)

x <- new("A", a=1:10, b=letters[1:10])

x$a
x$b
x$reset(fields="a")

x$a
x$b

x$reset()
x$a
x$b

Quite often, it's not the fanciest feature in the world that pops up on my "oh, that's missing" list. Plus it might be such a "singular" function that developing a whole package sometimes feels like cracking the nut with a sledgehammer.

回答1:

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

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 ...
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, 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.
edit: 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.
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.

回答2:

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.

回答3:

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.

回答4:

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.

来源：https://stackoverflow.com/questions/8065835/proposing-feature-requests-to-the-r-core-team

标签

open-source