[Bioc-devel] Invitation to the bioC developers Meeting in Seattle Mon 15 Aug

[Robert Gentleman]

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
>