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

[Chris Mungall]

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
>
>