[schooltool-dev] tuesday dev meeting

[Tom Hoffman]

In addition to the usual updates, tomorrow we can discuss my initial
thoughts about how we might approach next year's development, which I
wrote down last week and sent to some of you (and copied below).

--Tom

SchoolTool's development strategy for 2007 has been conservative.  We
have sought to emulate a traditional client/developer relationship
between two partner schools and two local developers.  As a result, as
of August 2007, we have avoided wasted effort and false starts due to
overly broad or ambiguous requirements.  The developers have focused
on meeting the concrete requirements of two real schools, and the
codebase as a whole is on more solid footing than at the beginning of
the year.  Additionally, the CanDo project has continued to move
forward, successfully launched an ambitious program to train student
interns to further SchoolTool and CanDo develoment in coming years.  I
remain convinced that our approach this year was the best move at this
time.

The question we face now is how to organize the work next year.  The
biggest weakness we have encountered in the current model is the level
of commitment of partner schools.  We have intentionally worked with
schools that were sufficiently interested in implementing SchoolTool
to enter into a partnership with us, but we did not seek out schools
who would have an absolute dependency on SchoolTool starting on
September 2007.  As a result, however, it is easy for SchoolTool to
become lost in the shuffle of the many demands put on school staff.
In reading about the broader context of researchers and foundations
seeking out schools as partners, I've realized this is a general
problem in the field, even when significant time and experience is
applied.

If we continue using a partnership approach with simulates a
client/developer relationship, I believe that we would have to find a
committed partner that would feel much more internal pressure to
implement SchoolTool in production schoolwide in the fall of 2008 as
their primary school information system.  We would need to find a
school that would be actively engaged, clear and insistent about their
needs.

If we stick to the requirement that they work with a local Zope 3
developer, it will be very hard to find a good pair.  Unfortunately,
the organization of Lithuanian schools all but rules out such a school
appearing in Vilnius.  It would probably be easier to find a school in
Europe and have Ignas visit periodically, but I consider using a
remote developer in a partnership with a school to be inherently
risky.

The second significant drawback to this approach is that focusing on
individual partners means NOT focusing on building a larger community
and doing general releases.  If Zope 3 and SchoolTool technology was
easier to learn or widely used (particularly in schools), this would
not be such a serious problem; there would likely be additional
community members willing and able to make contributions on their own.
 As it is, for the forseeable future the (non-CanDo) SchoolTool user
community will make many more requests than contributions.  If we are
going to build a broader community of user schools, we will have to
devote significant developer time to supporting their feature requests
and bug reports.  In the past year the project as a whole has
maintained a quiet public face so we could focus on our partners
needs.  If we focus on partners for another year, it is possible we
won't have a complete general release until 2009, which doesn't seem
acceptable.

One other thing which has changed this year is the maturation of
Launchpad.  We now have a platform for managing distributed
development which includes tracking proposals, bugs, multiple
development branches, bounties and intern/mentor relationships.

The alternative of another year focused on expanded partnerships would
be to finally establish a robust community process in 2009.  Once
again reaching out to the open source in education community (which as
grown substantially in the past two years), but now with a much more
fleshed out, if still incomplete, SchoolTool and an advanced
infrastructure for managing the collaboration.  We would solicit
specifications and bug reports based on the current version of
SchoolTool packaged for Dapper beginning in November 2007, establish
priorities in collaboration with the community and attach bounties to
the work.  Ignas would continue as lead developer to do core
development and oversee contributions.  Ignas and Jean-Francois would
continue to work part-time with our current partners to support their
installations.  We would not have direct responsibility for any new
partners.

The main goals for the year would rotate around releases in sync with
Ubuntu releases.