[BioRuby] development updates?

[Rutger Vos]

I certainly appreciate Pjotr's point that whoever writes the code calls the
shots - and since I have written zero code my opinion carries no weight.
That said, now that this thread was started there is probably no harm in
trying to address the points in the original post, if only for posterity's
sake. I would start by saying that I commend Anurag for his (youthful, if he
doesn't mind) enthusiasm. It seems to me that the points he raises are
already being addressed in a way that evidently suits the bioruby community:


> I would suggest that the list be constantly updated :
> 1. short and long term goals - targets for minor and major releases,
> prioritizing bugs or feature requests or design decisions.
>

There is currently on the bioruby homepage a link to a bug tracker and a
feature request tracker. There is also one on the github page. Adding
another technological fix (some tracker tool) will do nothing but fragment
things.

As far as design decisions are concerned, none of the OBF(-like) projects I
follow are really designed by committee, so in general there are no formal
decisions that need to be communicated to lower echelons.


> 2. what is cooking - each developer could update the list on what he/she is
> working at, or/and a fortnightly or a monthly update on the cummulative
> development status( how much of the target has been achieved and stuff )
>

On the bioruby homepage are links to a number of blogs by people who very
generously take the time to record what they do so that others can learn
from that and use it. That is probably about as good as it's gonna get given
the time constraints that researcher/programmers are under.


> 3. important decisions and changes.
>

I doubt that this is how things work. People use bioruby to get their work
done, and they add things if they are deemed useful. This isn't the kind of
open source project where the user base vastly outnumbers the developer
community (e.g. apache, firefox, and so on) so that there would need to be
impressive "milestones" and cool sounding code names sent through formal
lines of communication.


> Perhaps, a development specific list can be setup to keep the user and the
> developer space segregated. A development list can also be attached to the
> issue tracker so that developers are automatically updated on new bugs and
> feature requests.
>

I have been subscribed to a number of <projectname>-guts at example.org mailing
lists to which bugs and commits are automatically piped. They have been of
dubious value - I filter the messages automatically from my inbox to some
folder which I then never visit, it turns out. In any case, to say that a
list can be setup is to say that a real person should spend time setting up
a list. Maybe that is not necessary given that source code repositories and
bug trackers have RSS feeds.


> Or, a blog can be setup where regular commiters have posting access.
>

Again, this is something that a real person would need to do. To the extent
that I know the people in the bioruby core (I only "know" a couple) I know
that they are all people with heavy academic work loads - perhaps even
(heaven forbid) with departmental duties on top of that. They do what they
can, I assume they already pretty much exhaust their copious amounts of
spare time as it is :)


> P.S : The idea behind this mail is to spark some discussion on a more
> efficient software development culture and hopefully adopt it :).
>

I don't think cultures are ever adopted unless there is very, very forceful
management that imposes it (which of course there isn't for OBF projects) or
unless it grows around certain key people with long term involvement in a
project. But this is probably just a roundabout way of repeating Pjotr's
point that the way to change things is to act.

Rutger

-- 
Dr. Rutger A. Vos
School of Biological Sciences
Philip Lyle Building, Level 4
University of Reading
Reading
RG6 6BX
United Kingdom
Tel: +44 (0) 118 378 7535
http://www.nexml.org
http://rutgervos.blogspot.com