[BioRuby] development updates?

[Chris Fields]

Just want to add my 2c, from the bioperl perspective.  The vast majority of bioperl devs have other jobs or obligations, so when they develop for whatever Bio* it tends to be to scratch a particular itch (fulfill something they need), and not much beyond that.

With BioPerl the tendency is that whoever codes first wins; talking about design leads to bikeshedding and tends to go nowhere unless you have something to point to (just drop in on the threads on the perl6 mail list sometime for many examples of this).  Yes, sometimes we have conflicts of opinion and get into spats, sometimes new code clobbers tests (git/github helps here), and sometime we even get a pretty decent design out of it (sometimes not :), but regardless every time we have code to work with or something to point to for our efforts.  It's good to discuss things, but you have to produce something of value at the end of the day.

So, just to reiterate what Rutger and Pjotr are saying, actions speak volumes. Take up the reins on something, get involved, and actually do something that benefits the project you are interested in.  

chris

On Aug 9, 2010, at 8:45 AM, Rutger Vos wrote:

> 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
> _______________________________________________
> BioRuby Project - http://www.bioruby.org/
> BioRuby mailing list
> BioRuby at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioruby