[BioRuby] bioruby docs

[jan aerts (RI)]

I agree with Trevor that modularization of the bioruby code would be a good thing, as he also explained in one of the mails last week.

As for the wiki: go for the one at open-bio. They've got the thing running, and that would remove the hassle for Toshiaki. We shouldn't see the wiki as something that is writable by _everyone_, but rather a website that can be added to by a limited number of people. I could e.g. put the Bio::Graphics tutorial there :-)

As for bug fixing: you're right that the mailing list is at the moment sufficient for tracking that. But still I think it's a good idea that we'd use a little bit more formal system. That's what I do for Bio::Graphics: instead of having to remember that someone send a bug report or a feature request, I just put it on rubyforge and don't have to worry that I forget.

jan.




-----Original Message-----
From: bioruby-bounces at lists.open-bio.org on behalf of Trevor Wennblom
Sent: Tue 23/10/2007 05:31
To: bioruby at lists.open-bio.org
Subject: Re: [BioRuby] bioruby docs
 
Hi all,

On Oct 22, 2007, at 11:08 PM, Toshiaki Katayama wrote:
> Trevor has been kindly provided bioruby-doc.org for the API documentation site.

I'm not sure if this is really needed anymore. It's currently "on
hold" from my end. I believe anything kept on it could be at
bioruby.org.  Basically, a public wiki was a poor substitute for proper
documentation. I'm open to suggestions as to how it could be best used.

I'm still voting for splitting BioRuby into a core module with a clearly
debated, agreed, and defined purpose and pulling out everything that
doesn't meet that purpose into extensions.


> 3. radically integrate it with Trac and SVN system at open-bio.org?!

I wonder how much Trac is really needed at this point. With BioRuby's
relatively slow release cycle it may be more trouble than it's worth,
and the mailing list seems sufficient for resolving bugs. While I'm
still by far in favor of Subversion over CVS, I strongly believe
Mercurial would ultimately be better. It would seem a distributed
revision control system (RCS) would better meet the needs of the project
since many people seem to want to take the project in different
directions. A distributed RCS would make the entire issue of project
forks non-existent, hopefully driving more aggressive development
activity from individuals outside the core development group.

_______________________________________________
BioRuby mailing list
BioRuby at lists.open-bio.org
http://lists.open-bio.org/mailman/listinfo/bioruby