[Bioc-devel] ANN: BioC Developer's Meeting/agenda/discussion

[Vincent Carey 525-2265]

> Hi,
>
>   To amplify a bit on both Gordon and Vince's comments. Yes packages
> should be mentioned in multiple places, but there are also reasons to
> split functionality into separate packages so that users have more
> choice about methods that they use (this has always been a strength of R
> and one that I am much in favor of) and the situations in which they use
> them. But that said, we still need a mechanism that will allow for
> multiple listings, one that lets package authors control the comments
> and as Vince suggested, different comments for different headings does
> seem worthwile, but not necessary.

i will try to get the multiple listings approach done soon and
then check in the package so others can add value.

>
> Also, I think Achim had mostly a CRAN view in mind when designing ctv
> (hence its name) and while that view (where most packages do only one
> thing and package dependencies are rare and not very complicated) is a
> pretty good one for CRAN, it is less good for Bioconductor where there
> are both more dependencies and more multi-purpose packages. So I think
> some changes would be helpful, or perhaps the two repositories are so
> different that we need a btv :-)
>
> We almost surely need some standard markup for the package author to
> write what they want to have seen, once some vague notion of task views
> are set up. My very strong preference is to do this in XML since there
> are good tools for parsing and working with it. Quite possible in

i agree that we will use XML.  i am not happy about starting
things out in XML as opposed to doing the data modeling and
function design in R, and then getting the infrastructure
to serialize to/deserialize from XML.  oddly enough I think
one virtue of XML is that we can edit it manually and add
content which R can then validate/process conveniently.

> inst/ctv would be a sensible spot so that it was available after
> installation (although that might not be necessary). It would be very
> straight forward to write some code to put in ctv that wrote one of
> these out from basic user input, no need for them to know XML and
> someone could surely write a widget in tcl/tk if they were so inclined.

right, but enough of our developers can write simple XML readily
enough so no input infrastructre is absolutely necessary ... i think
achim is expecting people to write the ctv-xml files by hand

>
> Life would be much simpler with an ontology, but that does not seem

well, this basically is an ontology, like it or not.  it could
be modeled in OWL with protege and i will probably do this before
too long.

> likely to appear in any short order but perhaps we could decide if we
> like the terms that Vince has used, and if there are any other
> extensions. In some sense these belong either in ctv, or some other
> place so that new developers have easy access to them (and no I don't
> think we should use the KEYWORDS file in R; I have to say I find that
> mechanism distinctly unhelpful). Gordon, do you have input on the
> hierarchy of terms? And do you think it would be useful to have package
> developers add themselves in and out, or should this be done by the
> maintainer?
>
> Initially there were some arguments against developers doing it, as we
> might want to have the view managed by an expert in the field who could
> also give recommendations.

this is a good topic for "future of bioconductor".  we'd like this
to be as non-confrontational as possible -- the developers should
supply content/suggestions and some curators, perhaps a rotating group,
would verify the content/suggestions, iterate with the developers on the
view material, and then it would be finalized for a release.