[BioRuby] Fork => suggestions

[jan aerts (RI)]

Trevor,

I must admit that I stopped mailing the list months ago after not
getting much response... I'm afraid that also included answering to
other people's questions.

Was thinking about some suggestions for a project like bioruby to keep
people informed and make clear (or sure?) that it's very much alive. I
believe I mentioned some/most of these in earlier posts way back, and
many/most of these will be completely stupid (copyright: myself), but it
might get people thinking a bit. Note that the _last_ thing I want to do
is step on the toes of the real developers.

Just read this as some thoughts during your coffee....

(1) bioruby board
-----------------
As English is only my x-th language, I can't think of another word than
'board'. Wouldn't it be nice if there was a limited group of people (3
to 5) that would act as a central authority so to speak to represent
bioruby. This 'board' would preferably consist of people from different
continents. Some things that this group could do is:
* make sure that questions on the mailing list get answered or at least
directed to the right people for answering
* make the end-decision on which new modules (from BiorubyExtensions,
see below) should be added
* discuss releases

(2) BiorubyEdge aka BiorubyExtensions
-------------------------------------
Purpose: to make clear what's in store for bioruby in the near future
and to allow for preparing new classes for inclusion in bioruby.

I suppose that more people will have ruby classes defined locally that
are not really ready to be included in an 'official' repository like
bioruby, but that could become candidates later on. I know I have. How
about creating something like BiorubyExtensions, which would be like a
waiting room for classes before they get into bioruby. If a class gets
polished enough and ends up fitting into the official bioruby structure,
it could be 'upgraded' to the main bioruby. On the other hand: it can
also be removed from BiorubyExtensions instead if not supported or
well-developed enough, of course.
An example would be Bio::Graphics. Someone asked about that a while ago
on the mailing list, and some people (including myself) might actually
have a working class for this. It's just not polished enough and misses
some functionality. And therefore a candidate for such an 'extensions'
waiting room.


(3) feature requests + bugs
---------------------------
How about using the rubyforge system for bugs and feature requests?
(This mainly means making it clear on the bioruby website to submit them
on rubyforge...)


(5) blog
--------
I don't want to sound like trying to follow latest trends nilly-willy,
but a bioruby blog by the board-thingy (see above) and/or developers (a)
would make really clear to the community that people are working on
bioruby, (b) give more background on the development and/or (c) could
give additional examples on how to use it.


(6) manuscript
--------------
I believe bioruby needs a reference in a journal read by a large
cross-section of bioinformaticians (Bioinformatics? BMC
Bioinformatics?). I've actually worked on this about year ago with
Toshiaki, but it kind-a got stranded in the end...

Just to get some discussion started... Comments welcome.

jan.



> -----Original Message-----
> From: bioruby-bounces at lists.open-bio.org 
> [mailto:bioruby-bounces at lists.open-bio.org] On Behalf Of 
> Trevor Wennblom
> Sent: 25 March 2007 07:27
> To: bioruby at lists.open-bio.org
> Subject: [BioRuby] Fork
> 
> Judging by the overwhelming response that I've received over 
> the past year (2006-2007) compared to the previous year 
> (2005-2006) does this mean that's it's time for a fork?
> 
> If it's time let's do it.
> 
> Wake.  Up.
> 
> Trevor
> _______________________________________________
> BioRuby mailing list
> BioRuby at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioruby
>