[Bioc-devel] Invitation to the bioC developers Meeting in Seattle Mon 15 Aug
Hi all, I think that it is important to realize that package authors generally create packages to solve local and immediate problems. They post them to BioC to let others use them, and hopefully to get feedback etc. So whether or not they interoperate or are of really high quality was not a primary issue for the developer. But, as time goes by, and if they do see use, then they warrant some more attention, redesign and improved effort in documentation etc. I think we should be pretty careful about setting barriers to entry and rather focus more on strategies for iterative improvement. One of the design goals of the vignettes was to encourage user contributions. Once someone, other than the package author has used a package for an analysis they have the capability to write a vignette, or to provide meaningful feedback to the package author. Unfortunately instances of this activity are as rare as sightings of the ivory-billed woodpecker. So let me encourage those of you who have used packages to try to find the time to provide helpful feedback to the author. As for what can the Bioconductor project do to help, a number of things. We can identify sets of packages, like the three aCGH ones, and encourage the adoption of a common data format, or at the very least the creation of coercion methods between data types. Amalgamation of packages can also be useful. But importantly we need to encourage these folks to talk to each other and to provide resources that will help them to achieve that goal. We have done that with the Affymetrix based microarray packages, tried to do it with the cDNA arrays, and are happy to try and help with aCGH and any other data formats. Wolfgang Huber has suggested a two or three day developer conference be held some time and I think that one of the goals is to make that a venue where this sort of redesign (and possibly even implementation) could take place - so I encourage those of you that are interested to ensure that that conference/workshop does take place. Best wishes, Robert
Fridlyand, Jane wrote:
I'd be happy to follow your suggestions on how to make the package fit more with affy-type packages (obvious things is creating subsettabble exprset-like object, possibly methods) for the next release. anything else that you have in mind? are you suggesting combining three packages? i am open to this but it would obviously depend on the other authors. jane ###################################################### Jane Fridlyand Assistant Professor of Epidemiology and Biostatistics Center for Bioinformatics and Molecular Biostatistics UCSF Comprehensive Cancer Center Office: 2340 Sutter str., N224, SF, CA 94114 Tel: 415-476-0168 Fax: 415-502-3179 ###################################################### -----Original Message----- From: bioc-devel-bounces at stat.math.ethz.ch [mailto:bioc-devel-bounces at stat.math.ethz.ch] On Behalf Of Jeff Gentry Sent: Friday, August 05, 2005 11:26 AM To: bioc-devel at stat.math.ethz.ch Subject: Re: [Bioc-devel] Invitation to the bioC developers Meeting in Seattle Mon 15 Aug On Fri, 5 Aug 2005, Furge, Kyle wrote:
aCGH, DNAcopy, GLAD all use different, internally defined formats for data storage. In addition, feature annotations are stored in separate formats rather then annotation environments. Currently, the convert package does not handle the aCGH, DNAcopy, or GLAD data or annotation formats. I do not want to speak for the original author or the authors of these packages, but in this example, it is worth requiring coerce methods for these (and other) formats into exprSets/annotation environments at the package acceptance stage?
IIRC, the convert package showed up chronologically before the three packages that you mentioned - which would explain why it does not handle the other three. At the same time it demonstrates the problem of keeping packages up to date with the state of the art in other packages as well. I know I'm guilty of this myself but often package authors/maintainers are not aware of changes in other packages which are relevant to their own, and this can be a problem. In a case like the one you describe, where you've personally identified a situation that seems like it would make sense to update one (or more) packages, IMO the thing to do is at the very least to contact the appropriate maintainers and raise this issue - or even better to develop the appropriate code/patches to those maintainers.
_______________________________________________ Bioc-devel at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel _______________________________________________ Bioc-devel at stat.math.ethz.ch mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel