[Koha] Proposal to form Koha Technical Committee

Wagner, Jane jwagner at liblime.com
Thu Nov 4 21:00:08 NZDT 2010


I’ve been touring New Zealand all week without Internet access, so I’m just
now catching up with my email.  This is a topic that is of great interest
and concern to us, and I look forward to the meeting next week.  As I
discussed with Chris Cormack during Kohacon, we have a large number of new
development features in the works, which we’ll post to the RFC page as soon
as the client finalizes the list.  Most should be ready for 3.4.



Flying home tomorrow so I’ll be out of touch for a while again, but I did
want to chime in with our interest in the topic.



Jane Wagner

Senior Project Manager

LibLime, a division of PTFS

Content Management and Library Solutions

6400 Goldsboro Road, Suite 200

Bethesda, MD  20817

(301) 654-8088 x 151

jwagner at liblime.com <jwagner at ptfs.com>



*From:* koha-bounces at lists.katipo.co.nz [mailto:
koha-bounces at lists.katipo.co.nz] *On Behalf Of *Irma Birchall
*Sent:* Wednesday, November 03, 2010 6:19 AM
*To:* koha at lists.katipo.co.nz
*Subject:* [Koha] Proposal to form Koha Technical Committee



Below are notes that Bob and I compiled from a meeting at the KohaCon10
hackfest in Wellington last Sunday.
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.
The notes are self explanatory, we hope.
We look forward to a vigorous discussion (as usual).

Irma
CALYX

Discussion about decision making for Koha technical issues
kohacon10 hackfest 31 October 2010

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.

In the broad-ranging discussion, the following points were made:

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.

It is not clear how to get decisions made about major software issues. There
is also the problem of coordinating development of features.

   - how do we coordinate development?
   - who decides?
   - what is the structure for deciding?

The current decision-making forum is the monthly irc meeting. Other forums
for discussion include the developers' list and the wiki (especially RFCs).

Issues discussed on irc and koha-devel sometimes don't get resolved. No
clear roadmap about what will get included in next official release.

Some other open source projects have a suite of core code and plug-ins for
extra or alternative features.

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.

The problem applies to both software architecture issues and features. There
may be one solution or several strategies to mitigate the problem.

Suggestion to create a Technical Committee.

Alternatively a committee structure : small working groups to make
recommendations.

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.

Current meetings deal with the immediate, not the long term. A structural
development meeting could be held regularly to discuss longer term
development.

The need may be for:

   - a transparent process about what development will make it into official
   Koha; plus
   - each company must have its own procedure for dealing with
   client-sponsored features that will not be selected into a release version.

RFCs are the usual way to elicit discussion of proposed features.

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.

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.

Technical Committee could have 6 to 8 members – rotating.

Opportunity for Librarians Discussion Group as another regular meeting?
Ensure library standards are applied and kept up to date. Could link project
with academia.

Another potential forum is an Opac Advisory Committee.

Current practice is that all meetings are open to all to attend. Mood is to
retain this approach.

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?).

Format for minutes of meetings was discussed.

For further discussion and resolution at the Monthly IRC Meeting on 10
November.

 --
Irma Birchall
CALYX information essentials
Koha & Kete implementations and services
T:(02) 80061603
M: 0413 510 717
irma at calyx.net.au
www.calyx.net.au
http://koha-community.org/
http://kete.net.nz/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20101104/9d09fe86/attachment-0001.htm 


More information about the Koha mailing list