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.