Packages page

[karthik]

As @cboettig pointed out, it's not great to have just a long list. I'm thinking maybe a small paragraph of text saying, here are some key packages, and themes we cover. If you're new, this would be a good place to start. Otherwise see the exhaustive list below.

What other information can we include in the table? I agree that on CRAN is not particularly useful. Besides package name and description, anything else needs to go on there? We have a field for whether or not an API key is required but again not sure if that's really useful to know at this list stage. Maybe just package name, version(?) and description. A link to the github repo since that will always exist regardless of cran?

[cboettig]

Small paragraph followed by full list sounds perfect.

I actually do think being "on CRAN" is useful for the comprehensive list, since I see it as an important benchmark at which we are making some commitment to support regular users and to not break the API, while when a package is still on Github (like EML and RNeXML for me) I feel like I'm still hardening the user interface.

Name, version and description all sound good. I wonder if release dates might be useful? Our newest CRAN releases often seem to represent our best work to date, (though maybe that's just a transient in our learning curve), and it feels they should get more attention than older packages... maybe I'm off base here.

Despite their retro look, I kind of like the level of detail and even the narrative feel provided by CRAN taskviews, though decent description fields might accomplish that.

I've been trying to make my description fields a bit more expressive and sexy than "an R interface to XX". For instance, RNeXML is: "Implementing semantically rich NeXML I/O in R". I need to be better about standardizing this stuff across the Github description, the DESCRIPTION file, etc, and improving the descriptions of other packages I maintain. Input welcome.

Yeah I agree that the API key thing is not that helpful. It seems to imply this kind of burden over the packages that really isn't such a big deal.

[sckott]

yeah, pkg name, version description and link to github repo seems good to me

[karthik]

- [ ] We'll need another column for version number

• [ ] Clean up descriptions where possible.
• [x] Trim out deprecated packages?

For each subsection, a sentence or two below the header might be nice. E.g What is altmetrics? A few links to help the uninformed.

• [x] Also need to name sure CRAN and GitHub don't overlap too much.

[karthik]

On further thought, version numbers here don't seem that helpful. Also adds another item for us to manually update and I worry it will result in more things being out of sync. Do it anyway? @cboettig @sckott?

[sckott]

Yeah, no version seems fine to me

[cboettig]

Yeah, definitely don't want to do this manually. maybe one day we have something that scrapes this data, since that's easy enough to do. I agree with skipping it for now. Anyway, I agree that version numbers would be mostly clutter anyway. Ideally the package description or README states all of these details.

Hmm, which begs the question: would it be good to automatically pull some of the metadata from DESCRIPTION and output it into the "About" sections in our README.Rmd's?

On Wed, Apr 23, 2014 at 9:53 AM, Scott Chamberlain <notifications@github.com

wrote:

Yeah, no version seems fine to me

— Reply to this email directly or view it on GitHubhttps://github.com/karthik/roweb/issues/7#issuecomment-41186046 .

Carl Boettiger UC Santa Cruz http://carlboettiger.info/

[karthik]

I'm done with the packages page. All the descriptions need a better rewrite, and I'll need help linking up all the CRAN and GitHub links. Otherwise we're done here. Getting close to actually folding in the real content!

[sckott]

nice

[karthik]

Sweet. Scott is editing the page now. So we're set on this one.