Re: [R] Feature request: rating/review system for R packages

From: Heinz Tuechler <>
Date: Sun, 20 Mar 2011 23:38:16 +0100

It's unclear to me, why the rating/review system should relate to entire packages. Would it not be more informative, if single specific functions would be rated and reviewed?
I would like to see if "+" is rated better than "-", or if more difficulties are reported for "*" than for "/". I could then consider in the future to prefer sums over differences.


At 20.03.2011 19:03 +0000, Ben Bolker wrote:
>Dieter Menne <dieter.menne <at>> writes:
> >
> >
> > > After pondering all the pros and cons regarding the usefulness of a
> > > rating/review system for R packages, don't you think it would make sense
> > > to implement such a thing?
> > >
> >
> > Or to look what is there, and how little it is filled:
> >
> >
> >
> > Dieter
> If I were feeling a little more ambitious, I would write a contributed
>"popularity contest" package (cf. <>,
><>) that did the following:
> * recorded information on a user's configuration and installed packages
>and reported it *somewhere* (web server, etc.; R has plenty of communications
>facilities built in)
> for more intrusive but complete information:
> * gave users an option to install a `hook' that would report at some
>interval (regular? random?) which packages were actually loaded
>(on Unix-alike machines one might be able to use the 'atime' feature
>to guess when a package was *last* loaded even if it wasn't currently
>in use)
> * gave users an option to contribute further information (country,
>research field, etc.)
> * might pop up a window showing installed packages and offering users the
>option to comment or to give ratings to particularly good or bad
>packages, which
>would be sent to wherever ...
> This would be completely optional, but *if* word got around it
>could collect a useful (albeit completely statistically unsound)
>set of information.
> *If* I were writing this I would (a) be very clear in the package
>description etc etc what information would be collected and stored,
>where, and how it would be used; (b) carefully think about the tradeoffs
>between annoying users and collecting more information; (c) consult
>with the fine folks running CRANtastic to see if they wanted to somehow
>integrate it into their infrastructure.
> The big advantage of this approach is that you don't need to convince
>anyone from R-core to do anything, you just need to convince users to
>install your package.
> Ben Bolker
> mailing list
>PLEASE do read the posting guide
>and provide commented, minimal, self-contained, reproducible code. mailing list PLEASE do read the posting guide and provide commented, minimal, self-contained, reproducible code. Received on Sun 20 Mar 2011 - 22:45:38 GMT

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Sun 20 Mar 2011 - 22:50:23 GMT.

Mailing list information is available at Please read the posting guide before posting to the list.

list of date sections of archive