R help - Aug 2011 - Wiki/revision control to management of CRAN package repository

I propose the following humbly, with little know how as to how to implement, and
realize it may have been proposed many times.  It is just something I had on my
mind.

Would it be possible/desirable to have the whole CRAN package repository
accessible through a public wiki, forge or version control interface (ideally a
fusion of the wiki and forge approach)?


It appears it would be a first for a software repository.

CRAN package repository is becoming a jungle of R code and may do well with
currating and editorial effort.  This can not/should not be the task of a single
person or small group of people.  Using a crowd sourced method by implementing a
wiki approach to the CRAN package repository would allow for the rapid editing,
sorting and improvement of this impressive and precious resource, while also
improving the accessibility, visibility and quality of individual packages.  It
would also bind the

For example, such an interface would allow the cleaning up of the repository
through the use of tagging of packages, using similar approaches to the
wikipedia project
(http://en.wikipedia.org/wiki/Wikipedia:Template_messages#Cleanup).

Such a tagging approach could be used within existing vcs, if the repository was
migrated/mirrored within one of these systems.


Packages could be marked using tags for all following actions prior to
implementing the action.  Actions could be undertaken directly by package users
after a delay or discussion.

Packages management/editorial effort:
	-Merging/
		-Combining packages that have:
			-Large overlap in functionality
			-Are largely interdependant
			-Are only minor extensions of another package
			-?
	-Split/fork
		-Subdividing behemoth packages into smaller packages with more specific tasks
	-Categorization
		-Packages could be sorted by use, improvement of Task View
		-Tags, keywords could be added to packages for searching
		-Packages could be placed in a hierarchy, not only by true dependance and
reverse dependance, but also by logical dependance/reverse dependance
			-ie. which package should probably be used with which package, an improvement
on the see also help section
	-Deletion
	-Marking/tagging
		-a stub/prototype
		-broken
Package improvements
	-Improving help files
	-Adding functions
	-Adding examples
	-Requiring, improving or adding references
		-References to the theory or approach used...
		-A section could include a list of articles making use of the package, with
package users encourage to enter this information
		-This would allow package author recognition and allow a package impact factor
	-Adding key words for indexing and searching
	-Function improvement
		-Adding compatibility with other packages/formats (including when merging
packages)
		-Speed improvements
Discussion
	-On package improvements, management steps directly attached to the package
	-Help discussion
	
	


These actions would be reversible, possibly with veto power from the author of
the package.

Links:
http://www.rforge.net/
http://sourceforge.net/
http://channel9.msdn.com/Forums/Coffeehouse/174561-Coding-Wiki
http://code.google.com/p/mcover/
http://www.tigris.org/

This is just an idea I had on my mind.

Thank you

Hello,

For the R Wiki, not very realistic to think about fusing it with the 
other tools, due to the nature of a wiki on one hand, and the necessity 
to share the CRAN site across different repositories on the other hand.

Also, I think that packages development is in the hand of their 
respective developers/maintainers. Except for making sure they pass R 
CMD check and respect a limited amount of requirements (license, size of 
enclosed documents, ...), it is probably not a good idea to FORCE people 
to collaborate, or share the same point of view for a given R extension. 
There are sometimes very different implementations of the same concept, 
e.g., object oriented approaches in S3/S4 (official), but see also R.oo 
or proto for alternative ideas. Another example: RUnit vs svUnit vs 
testthat. Would not be a good idea to force all these people to share 
the same implementation and fuse everything in a single package,... 
unless they decide by themselves, and completely freely, to do so.

This is an Open Source community, and it evolves a little bit like 
natural living ecosystems... with different ideas that could emerge and 
are ultimately selected by a kind of natural selection mechanism, 
related to (1) adoption of one or the other tool by the R community, and 
(2) the energy put in the project by their developers to maintain or 
make it better suitable to the community. That mechanism can only work 
if you are not too rigid in constraints for R packages.

The drawback is a little bit of confusion for the end-user that does not 
always easily know which of the different implementations he should adopt.

Best,

Philippe Grosjean


On 22/08/11 06:02, Etienne Low-D?carie wrote:
> I propose the following humbly, with little know how as to how to
implement, and realize it may have been proposed many times.  It is just
something I had on my mind.
>
> Would it be possible/desirable to have the whole CRAN package repository
accessible through a public wiki, forge or version control interface (ideally a
fusion of the wiki and forge approach)?
>
>
> It appears it would be a first for a software repository.
>
> CRAN package repository is becoming a jungle of R code and may do well with
currating and editorial effort.  This can not/should not be the task of a single
person or small group of people.  Using a crowd sourced method by implementing a
wiki approach to the CRAN package repository would allow for the rapid editing,
sorting and improvement of this impressive and precious resource, while also
improving the accessibility, visibility and quality of individual packages.  It
would also bind the
>
> For example, such an interface would allow the cleaning up of the
repository through the use of tagging of packages, using similar approaches to
the wikipedia project
(http://en.wikipedia.org/wiki/Wikipedia:Template_messages#Cleanup).
>
> Such a tagging approach could be used within existing vcs, if the
repository was migrated/mirrored within one of these systems.
>
>
> Packages could be marked using tags for all following actions prior to
implementing the action.  Actions could be undertaken directly by package users
after a delay or discussion.
>
> Packages management/editorial effort:
> 	-Merging/
> 		-Combining packages that have:
> 			-Large overlap in functionality
> 			-Are largely interdependant
> 			-Are only minor extensions of another package
> 			-?
> 	-Split/fork
> 		-Subdividing behemoth packages into smaller packages with more specific
tasks
> 	-Categorization
> 		-Packages could be sorted by use, improvement of Task View
> 		-Tags, keywords could be added to packages for searching
> 		-Packages could be placed in a hierarchy, not only by true dependance and
reverse dependance, but also by logical dependance/reverse dependance
> 			-ie. which package should probably be used with which package, an
improvement on the see also help section
> 	-Deletion
> 	-Marking/tagging
> 		-a stub/prototype
> 		-broken
> Package improvements
> 	-Improving help files
> 	-Adding functions
> 	-Adding examples
> 	-Requiring, improving or adding references
> 		-References to the theory or approach used...
> 		-A section could include a list of articles making use of the package,
with package users encourage to enter this information
> 		-This would allow package author recognition and allow a package impact
factor
> 	-Adding key words for indexing and searching
> 	-Function improvement
> 		-Adding compatibility with other packages/formats (including when merging
packages)
> 		-Speed improvements
> Discussion
> 	-On package improvements, management steps directly attached to the
package
> 	-Help discussion
> 	
> 	
>
>
> These actions would be reversible, possibly with veto power from the author
of the package.
>
> Links:
> http://www.rforge.net/
> http://sourceforge.net/
> http://channel9.msdn.com/Forums/Coffeehouse/174561-Coding-Wiki
> http://code.google.com/p/mcover/
> http://www.tigris.org/
>
> This is just an idea I had on my mind.
>
> Thank you
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
>

Hi,
Much of the tagging/sorting/commenting stuff is already implemented as
http://crantastic.org. Unfortunately few people have taken the time to
contribute reviews. I propose that those of us who would like to bring
more order to the R package universe should start by contributing
reviews, tags, etc. to crantastic.

Best,
Ista

2011/8/22 Etienne Low-D?carie <etienne.low-decarie at
mail.mcgill.ca>:
> I propose the following humbly, with little know how as to how to
implement, and realize it may have been proposed many times. ?It is just
something I had on my mind.
>
> Would it be possible/desirable to have the whole CRAN package repository
accessible through a public wiki, forge or version control interface (ideally a
fusion of the wiki and forge approach)?
>
>
> It appears it would be a first for a software repository.
>
> CRAN package repository is becoming a jungle of R code and may do well with
currating and editorial effort. ?This can not/should not be the task of a single
person or small group of people. ?Using a crowd sourced method by implementing a
wiki approach to the CRAN package repository would allow for the rapid editing,
sorting and improvement of this impressive and precious resource, while also
improving the accessibility, visibility and quality of individual packages. ?It
would also bind the
>
> For example, such an interface would allow the cleaning up of the
repository through the use of tagging of packages, using similar approaches to
the wikipedia project
(http://en.wikipedia.org/wiki/Wikipedia:Template_messages#Cleanup).
>
> Such a tagging approach could be used within existing vcs, if the
repository was migrated/mirrored within one of these systems.
>
>
> Packages could be marked using tags for all following actions prior to
implementing the action. ?Actions could be undertaken directly by package users
after a delay or discussion.
>
> Packages management/editorial effort:
> ? ? ? ?-Merging/
> ? ? ? ? ? ? ? ?-Combining packages that have:
> ? ? ? ? ? ? ? ? ? ? ? ?-Large overlap in functionality
> ? ? ? ? ? ? ? ? ? ? ? ?-Are largely interdependant
> ? ? ? ? ? ? ? ? ? ? ? ?-Are only minor extensions of another package
> ? ? ? ? ? ? ? ? ? ? ? ?-?
> ? ? ? ?-Split/fork
> ? ? ? ? ? ? ? ?-Subdividing behemoth packages into smaller packages with
more specific tasks
> ? ? ? ?-Categorization
> ? ? ? ? ? ? ? ?-Packages could be sorted by use, improvement of Task View
> ? ? ? ? ? ? ? ?-Tags, keywords could be added to packages for searching
> ? ? ? ? ? ? ? ?-Packages could be placed in a hierarchy, not only by true
dependance and reverse dependance, but also by logical dependance/reverse
dependance
> ? ? ? ? ? ? ? ? ? ? ? ?-ie. which package should probably be used with
which package, an improvement on the see also help section
> ? ? ? ?-Deletion
> ? ? ? ?-Marking/tagging
> ? ? ? ? ? ? ? ?-a stub/prototype
> ? ? ? ? ? ? ? ?-broken
> Package improvements
> ? ? ? ?-Improving help files
> ? ? ? ?-Adding functions
> ? ? ? ?-Adding examples
> ? ? ? ?-Requiring, improving or adding references
> ? ? ? ? ? ? ? ?-References to the theory or approach used...
> ? ? ? ? ? ? ? ?-A section could include a list of articles making use of
the package, with package users encourage to enter this information
> ? ? ? ? ? ? ? ?-This would allow package author recognition and allow a
package impact factor
> ? ? ? ?-Adding key words for indexing and searching
> ? ? ? ?-Function improvement
> ? ? ? ? ? ? ? ?-Adding compatibility with other packages/formats (including
when merging packages)
> ? ? ? ? ? ? ? ?-Speed improvements
> Discussion
> ? ? ? ?-On package improvements, management steps directly attached to the
package
> ? ? ? ?-Help discussion
>
>
>
>
> These actions would be reversible, possibly with veto power from the author
of the package.
>
> Links:
> http://www.rforge.net/
> http://sourceforge.net/
> http://channel9.msdn.com/Forums/Coffeehouse/174561-Coding-Wiki
> http://code.google.com/p/mcover/
> http://www.tigris.org/
>
> This is just an idea I had on my mind.
>
> Thank you
>
> ______________________________________________
> R-help at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide
http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>


-- 
Ista Zahn
Graduate student
University of Rochester
Department of Clinical and Social Psychology
http://yourpsyche.org