<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
Below are notes that Bob and I compiled
from a meeting at the KohaCon10 hackfest in Wellington last Sunday.
<br>
We're trying to put these up on the wiki but haven't found how to
edit the relevant page. In the meantime, we'll just share them here
on list.
<br>
The notes are self explanatory, we
hope.
<br>
We look forward to a vigorous
discussion (as usual).
<br>
<br>
Irma
<br>
CALYX
<br>
<br>
Discussion about decision making for
Koha technical issues <br>
kohacon10 hackfest 31 October 2010
<br>
<br>
At the kohacon10 hackfest, Paul Poulain
of Biblibre initiated a discussion about the way strategic decisions
are to be made in relation to the Koha software. Paul is concerned
that there is no forum for decision making beyond the next release.
The role of Release Manager is focused on ensuring there is a
stable,
on-time release incorporating agreed features. But there are other
longer-term architectural issues to be determined beyond the scope
of
the RM role.
<br>
<br>
In the broad-ranging discussion, the
following points were made:
<br>
<br>
Pending decisions include: move to
solR; mod_perl or plack; move to T::T ; move to time based release;
how to coordinate developments like EDI and RFID, amongst others.
<br>
<br>
It is not clear how to get decisions
made about major software issues. There is also the problem of
coordinating development of features.
<ul>
<li>how do we coordinate development? </li>
<li>who decides? </li>
<li>what is the structure for deciding?
</li>
</ul>
The current decision-making forum is
the monthly irc meeting. Other forums for discussion include the
developers' list and the wiki (especially RFCs). <br>
<br>
Issues discussed on irc and koha-devel
sometimes don't get resolved. No clear roadmap about what will get
included in next official release. <br>
<br>
Some other open source projects have a
suite of core code and plug-ins for extra or alternative features.
<br>
<br>
Commitments made to clients have to be
met often between official releases. This has affected Biblibre,
Xercode, Software Coop and Liblime. Risk of more forks if structure
to decide is not clear.
<br>
<br>
The problem applies to both software
architecture issues and features. There may be one solution or
several strategies to mitigate the problem. <br>
<br>
Suggestion to create a Technical
Committee.
<br>
<br>
Alternatively a committee structure : small working groups to make
recommendations.
<br>
<br>
Observation that arranging meetings
across world time zones is difficult. Meetings are time consuming.
Hard for key developers to attend multiple meetings. Keep
difficulties in mind.
<br>
<br>
Current meetings deal with the
immediate, not the long term. A structural development meeting could
be held regularly to discuss longer term development.
<br>
<br>
The need may be for:
<ul>
<li>a transparent process about what development will make it into
official Koha; plus </li>
<li>each company must have its own procedure for dealing with
client-sponsored features that will not be selected into a
release version.
</li>
</ul>
RFCs are the usual way to elicit
discussion of proposed features.
<br>
<br>
But because everyone is so busy, they
usually don't attract much discussion. For example, a number of RFCs
were submitted in September by Nucsoft OSS but don't seem to have
received much comment.
<br>
<br>
Suggestion for developers to make an
on-line (skype or irc) presentation of major proposed new features.
Forum for input by others. Follow up discussion would be on list.
<br>
<br>
Technical Committee could have 6 to 8
members – rotating.
<br>
<br>
Opportunity for Librarians Discussion
Group as another regular meeting? Ensure library standards are
applied and kept up to date. Could link project with academia. <br>
<br>
Another potential forum is an Opac
Advisory Committee. <br>
<br>
Current practice is that all meetings
are open to all to attend. Mood is to retain this approach.
<br>
<br>
People scheduling a meeting should add
the event to the Calendar on koha-community.org and send an email to
the list. (To check if this can be automated?).
<br>
<br>
Format for minutes of meetings was
discussed.
<br>
<br>
For further discussion and resolution
at the Monthly IRC Meeting on 10 November.<br>
<br>
<br>
<div class="moz-signature">-- <br>
Irma Birchall<br>
CALYX information essentials<br>
Koha & Kete implementations and services<br>
T:(02) 80061603<br>
M: 0413 510 717<br>
<a href="mailto:irma@calyx.net.au">irma@calyx.net.au</a><br>
<a href="http://www.calyx.net.au/">www.calyx.net.au</a><br>
<a href="http://koha-community.org/">http://koha-community.org/</a><br>
<a href="http://kete.net.nz/">http://kete.net.nz/</a><br>
</div>
</body>
</html>