[Koha-devel] my candidacy

[Pat Eyler]

Given that I've been nominated as the Koha Dictator, people should
know where I stand on things.  Hopefully the following helps:

			       Overview
I'm most focused on a three issues: cleanliness of code (including
inline comments and a solid testsuite), inclusion of features for
other libraries (e.g., MARC), and the uptake of Koha in the larger
(international) market and the Open Source world.  Each of these is
discussed below:

   Code Cleanliness -
I believe that to be successful code need to be legible, testable, and
understandable.  Everyone working on it needs to have a sense of
ownership so that they can go in and fix problems, add functions, and
be able to contribute them back to the community at large.  I'm a firm
believer in test driven design, refactoring, and many other tenants of
the eXtreme Programming culture.

   Feature Inclusion -
I believe that Koha is a great system which can be made better.  As
the community adds features of interest to potential users, we need to
ensure that a) we're adding them in a maintainable way, b) we're not
excluding current users, and c) we're providing backwards-compatability
and/or migration tools.  Some of the features that seem most pressing
to me are:  an installer, MARC, Z39.50, and better front-end/back-end
modularization.

   Koha Uptake -
For Koha to be successful outside it's current market, I believe that
we must succeed in the two areas described above.  I also feel that we
need to reach out to potential users and developers.  We need to
develop a strategy of approaching (or creating) potential partners to
help push Koha into new territories (e.g., Latin America).

		   How do I propose getting there?

I think that our existing road map is a good place to start.  I'm
encouraged by the amount of coordination that already occurs on the
list and in irc, and encourage more of this.  If elected, I would like
to use a staff (described below) to help build and lead the community.

To encourage code cleanliness, I feel that we need to encourage the
development of tests and documentation.  Liberally seeding the
codebase will make a good start.  Encouraging the addition of tests for
new features before checkin (indeed, the successful passing of the
complete testsuite before checkin) will also be a great help.
Frequent building of the project's POD and automatically posting it to
a community website would be good too.  I'd also like to see bugzilla
(or the tracker in SourceForge) used to track problems and reward top
bughunters.

To drive feature inclusion, I believe that following a roadmap,
communicating within the community, and keeping a development
vs. stabilization separation (with release managers on both sides)
will be the key.  As librarians, developers, and commercial interests
work together to define release targets, then a release manager guides
development toward the target, We should see an organized inclusion of
features as we progress toward a Koha 2.0 release.

Building a larger Koha community through uptake of the project will
require evangelization and coordinated communication to selected
communities.  We will also want to encourage developers and
organizations to adopt Koha by supporting them through the learning
curve.  In some cases, this will mean encouraging commercial interests
to start supporting koha in their region (or helping to form
commercial interests to support koha in their region).


		       What are my liablities?

I'm not the perfect candidate, and may not even be the best
candidate.  Here are some reasons you may not want me to be the
Dictator.

1)  I'm pretty new to the whole project.

2)  I come from a different coding background.  I'm a sys-admin who
    really believes that OO and XP are better.

3)  I'm likely to be very busy with other things during the summer.
    This might mean that I can't put in as much time as I'd like to.

4)  I have the typical hacker personality ... I can come off as
    abrasive, annoying, and abrubt.

5)  I can be quite a pest about getting things done.