[Bioperl-l] distant thoughts from a dinosaur...

[Lincoln Stein]

Gosh, I didn't mean to imply any particular methodology.  Stylus and clay 
tablet representations will work.  The important thing is that the picture is 
both clear in our minds and that each member of the (small) group involved 
has the same picture.

Lincoln

On Thursday 17 July 2003 01:58 pm, Chris Mungall wrote:
> Hi Lincoln
>
> When you say "a clear model", do you necessarily mean object model? If so,
> how would this be defined... UML / POD / Class::Contract?
>
> My opinion is that we shouldn't make a decision just yet. It would be
> great to explore this using Aaron's bioperl-experimental repository idea -
> I'm really keen on this.
>
> Or perhaps the plan is to proceed with bioperl-2.0 immediately, and
> independently of bioperl-experimental?
>
> If this is the case, do you think it would be a good idea to have an RFC
> process, like perl6?
>
> I am really keen on the idea of starting with a strong, clear design, as
> Lincoln suggests. I think the only flaw with the 'extreme programming'
> approach that many bioperlers espouse is that it is sort of anti-design.
> I'm not advocating we spend 2 years faffing around with rational rose
> before writing a line of code... but the core model should be in place at
> the beginning.
>
> I also think splitting the mail list might be a good idea.
>
> Cheers
> Chris
>
> On Thu, 17 Jul 2003, Lincoln Stein wrote:
> > The successful open source projects are the ones in which there is a
> > small central group to create the design and framework and a large cloud
> > of volunteers with clearly defined tasks.
> >
> > Bioperl needs a clear model of the canonical biological objects:
> > sequence, alignment, taxonomic tree, ontology.  This needs to be put
> > together by a manageable group with a clear leader.  For each major part,
> > there should be one example of how to extend the paradigm.  For example,
> > if SeqIO were to be redesigned (which I'm not sure it should be), the
> > core group would create SeqIO::embl, and leave the other format parsers
> > to the larger group to work on.  Preferably, these modules would be
> > "outside the core" in the sense that people could contribute them without
> > extensive refereeing.
> >
> > I'll take Ewan's advice and not even think of volunteering for the
> > leadership position, although I want to be involved in the development of
> > the sequence feature model.  Aaron and Heikki have my full confidence. 
> > The idea of an outsider is a good one; can someone suggest some names?
> >
> > Lincoln
> >
> > On Monday 07 July 2003 09:30 pm, Steve Chervitz wrote:
> > > Nice comments, Ewan. A two-week break with absolutely no computer
> > > connection would probably do us all good.
> > >
> > > I've been mulling these issues for a while, wondering the best way to
> > > proceed. Today I noticed some similarities between Bioperl and the
> > > Mozilla project, which is on the verge of a major overhaul to de-bloat.
> > > See http://www.mozilla.org/roadmap.html.
> > >
> > > I think we can learn some things from these hardcore hackers. One
> > > lesson I think we should take to heart is: First create a roadmap. In
> > > this, we would outline what sort of changes we see up ahead for
> > > Bioperl, and establish some milestones to aim for along the way.
> > >
> > > Anyone want to take a crack at a roadmap for Bioperl? Summarizing the
> > > various bioperl-l discussions would be a start. It might make sense for
> > > several (or all) core team people to create a roadmap, then merge these
> > > into a unified version that all core folks agree to.
> > >
> > > Parts of the Mozilla code review guidelines may apply to Bioperl as
> > > well (http://www.mozilla.org/hacking/). Their reviews center on how
> > > well does a patch fix a bug. For us, think of this as "how well does a
> > > module solve a bioinformatics need?" (Another code-review idea: Take a
> > > look at other open-bio projects, see what has/hasn't worked and
> > > incorporate best-practices from them.)
> > >
> > > Regarding:
> > >
> > > On Monday, Jul 7, 2003, at 11:22 US/Pacific, Ewan Birney wrote:
> > > > <snip>
> > > >    --- I would claim that the main thing we should take from Bioperl
> > > > is community and culture; being:
> > > >
> > > >     - community of people who do real-life bioinformatics in Perl
> > > >
> > > >     - culture being open with
> > > >
> > > >         - anybody can join; anybody can lead. You prove
> > > >           yourself by your comments on the list and the
> > > >           code/documentation you provide
> > > >
> > > >         - whoever codes it wins the argument
> > > >            aka:
> > > >         - working code trumps abstract arguments
> > > >
> > > >         - we should live up to our promises as much as
> > > >           possible for:
> > > >              - testing as much as possible
> > > >              - documenting sensibly
> > > >              - bug finding and fixing as much as possible
> > > >              - stability of API when we say it is stable
> > >
> > > The community culture is definitely a great part of Bioperl, but we
> > > might want to re-consider the "whoever codes it wins" motto. At least,
> > > define what we mean be "wins". We don't want to stifle competition or
> > > say that the first solution will become *the* Bioperl way for all time.
> > > There could be a section of BioPAN where people can contribute
> > > different modules that provide the same functionality. But there would
> > > be more control over what goes into the core distributions.
> > >
> > > Here's are some quotes from the Mozilla roadmap that are relevant:
> > >
> > > "Simply put: great applications cannot be managed as common land, with
> > > whoever is most motivated in a particular area, or just the last to
> > > check in, determining the piecewise look and feel of the application.
> > > ..
> > > Continue the move away from an ownership model involving a large cloud
> > > of hackers with unlimited CVS access, to a model, more common in the
> > > open source world, of vigorously defended modules with strong
> > > leadership and clear delegation..."
> > >
> > > Bioperl isn't an application like Mozilla, but it is more like a set of
> > > applications, a toolkit. They mention the need for "application czars"
> > > to provide "cross-application consistency" and "coherent UI".
> > > Substitute module for application and API for UI and I think the
> > > concept applies to Bioperl as well.
> > >
> > > Steve

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY
========================================================================