Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | Source code for crantastic.org: a community site for R edit |
-
I was thinking that it could be done similarly to the way Ohloh does it, e.g. that there is a "this is me" button visible on author pages for logged in users. When clicked, the author id would be linked with the user. This could potentially be abused, but any misbehaving users could be blocked (I don't really think it will be a problem though). Alternatively, there could be a second step where a link gets emailed to the Author mail address and the user has to click it (will be a hassle for author profiles with invalid email addresses though, e.g. "at" instead of "@").
Comments
-
To minimise proliferation of similar tags
Comments
-
Comments
Similarly, should we consider pulling in packages in development from (r-forge)[http://r-forge.r-project.org] as well?
We might need some badging on the packages to indicate their source, and to somehow deal with packages that are present in multiple sources. For example, hexbin is in cran and bioconductor, and many of the packages in r-forge will have releases on cran.
Yes, this will require some thought. I believe it might be harder to pull stuff from r-forge, or do they have some kind of API as well?
R-forge behaves like a normal R repository, so it should be possible to pull down data in the same way as from cran.
Ah, for some reason I thought R-forge differed from the others.
Ideally, we should just have a top level list of all repositories we want to pull packages in from. Then if we discover a new source we can just add it to the list.
Bioconductor has a more complex structure than CRAN, with several sub-repositories. From their install script:
## Bioconductor CRAN-style repositories. ## The software repo (bioc) _must_ be the first element. repos <- c( "2.4/bioc", "2.4/data/annotation", "2.4/data/experiment", "2.4/extra" ) repos <- paste("http://bioconductor.org/packages", repos, sep="/") c(repos, "http://brainarray.mbni.med.umich.edu/bioc", "http://cran.fhcrc.org")Do we need all of these or is the main one enough? (http://bioconductor.org/packages/2.4/bioc/)
Since they keep version numbers in the URLs these has to be updated when new versions of Bioconductor are released.
There are differences between the DESCRIPTION files in CRAN and Bioconductor (probably r-forge as well), so special rules has to be added for each. Bioconductor includes a list of views right in the DESCRIPTION file, which is quite useful for our purposes. E.g. "biocViews: DNACopyNumber, DataImport, Genetics"
-
Should briefly describe crantastic, what we're working, what we have planned and how to contribute your ideas.
Comments
-
We need a favicon and a profile icon for twitter. Any ideas?
Comments
-
E.g. Rltools both imports and suggests the xtable package
Comments
Actually I'm not sure if this is a bug? Right now the page shows imports + depends in regular type, and suggested in italics. Maybe the UI for this part should be changed, since enhanced packages also should be displayed.
-
In light of new digests - I think most people will probably want to subscribe to a weekly or daily digest, rather than the raw feeds. Both email and rss links from navbar should go to a page which describe all the options.
Comments
-
This new plugin seems to have a lot more neat features than the one we are currently using. Link
Comments
That sounds reasonable. Could we require the user to make put in some effort to reduce the potential for abuse? e.g. http://recaptcha.net/
If it turns out to be a problem, we could require an extra field in the DESCRIPTION file like crantasticid: 103, 156
Recaptcha protection is added in hadley@a15aaa1
Is this pulic in the ui yet?
Actually it might need to be on the package page as well so that authors (and not just maintainers) can associate themselves with a package. This might need some db changes unfortunately
The hard part is extracting the correct author names from the author fields -- there's a lot of prose etc. there. :) Getting closer, though, and the rest of the code is working well.
I thought you would just ignore that and allow the user to say that they're any author of any package. What ate you thinking?
Yes but currently authors == maintainers (only maintainers are stored in the db as Authors). Also the current Version <-> Author relation only exists for maintainers as well, so there is no automatic way to detect if a non-maintainer author authored a given package.
An alternative route would be to give the users more control, e.g. giving them the power to claim that they are a package author (entering the details into a form, resulting in a new Author record) and then claim that they wrote a package through the user interface. This would then ignore any data from the fields in DESCRIPTION (or maybe just use some parts of it).
Would you prefer the latter, or maybe some combination?
A related important issue is that the same author can have is named spelled slightly differently in different DESCRIPTION files. E.g. "Eun-kyung Lee" and "Eun-Kyung Lee" are now stored as two different authors even though it clearly is the same person. I propose to create a merging-function, available only to admins/moderators, that makes it possible to merge authors together. This can be done by keeping track of a list of aliased names, updating existing relations to point to the correct author id, and finally delete the old record.
Can we just not side step this issue entirely by allowing any user to say they are a contributor to a package? This reificiation of author names is a tricky process.
I'm starting to agree - depending on automatic recognition here is too error-prone (or would require large amounts of work).
It was suggested earlier to highlight "expert" reviews - maybe we could define users that has contributed to N packages as being experts? That would add some extra incentive for users to register their contributions.
Maybe we could have little tags next to user names? Maybe just the number of packages they have contributed to? With a description title attribute so you could see that 3 actually meant "Has contributed to 3 packages"