[Koha-devel] "freezing" koha 3.0

[Galen Charlton]

Hi,

On Tue, May 13, 2008 at 3:56 PM, Paul POULAIN <paul.poulain at free.fr> wrote:
> Galen Charlton a écrit :
>
> > As Joshua mentioned, I currently work on nothing but Koha, spending
>  > perhaps three quarters of my time on development and bugfixing and a
>  > quarter on customer migration projects.
>
>  The only point I could note is that for instance you're hired by
>  LibLime. So you could/will/may/... face conflicts : community want
>  "that" and LibLime want "this". How will you deal with that problem.

Of course, that issue would affect any RM who is working for a Koha
support vendor, and even an RM working for a library wouldn't
necessarily be 100% immune to getting conflicts about features wanted
by that particularly library.

But it is a fair question.  Approaches I would take include:

* More and better communication about LibLime's proposed enhancements.
* Continuing Koha's use of sysprefs to guard optional features - this
may not be the ideal mechanism, but it does make it possible to
compromise on some features and let those who are interested in a
particular feature to maintain it.
* Where appropriate, implementing a drastic change in the form of a
separate OSS project that can integrate with Koha, such as Biblios or
the acquisitions client that LibLime is working on (and if I remember
correctly, the new acquisitions client that BibLibre is writing).
* Where there are disputes about fundamental Koha architecture,
discuss them and compromise.  One thing to keep in mind is that
LibLime's clients generally pay for specific features - nobody thus
far (and I predict, ever :) ), is likely to specifically want to pay
LibLime to rewrite Koha in Erlang or anything drastic like that.

>  The best solution would be, I agree with joshua that suggested it, to
>  have a collective pot that could let us have a RM independant from any
>  vendor.
>  How large should be the pot ? Who could put some money on it ?

An independent RM, perhaps somebody working for a library that uses
Koha, would be great -- it would reinforce a notion that libraries are
ultimately the owners of the Koha project.  However, I must admit that
I see many practical problems finding such a person quickly.  Who
would it be?  Being RM requires a large time commitment - is there
somebody out there working at a library who is familiar enough with
the code, well known enough to the developers, and able to get
permission from their employer?  If the vendors were to pitch in to
offer financial support, could that money be readily given to the
person without creating unsupportable conflicts of interest?  Would we
need to get a Koha project foundation up and running first to
accomplish it?

Of course, somebody could offer to RM as a "spare time" project, and
perhaps would be in a position to accept financial support as a sort
of second job.  if so, great.  Is anybody volunteering?

The one thing I don't think we should do is attempt to "hire" a RM
from outside of the community - for that person to have credibility,
he or she really must know Koha, be actively contributing to it or
have made significant contributions to the past, and ideally have a
direct interest in the success of the project, either by using Koha or
supporting Koha users.

>  > While I do some travel,
>  > mostly to conferences, I would be able to devote more time to RM
>  > duties.
>
>  mmm... do you mean you plan to do RM tasks mostly when at airport ?

To emphasize, while I do some travel, I do not do a *lot* of it, and
certainly much less than Joshua does.  Suggesting that I would be
"plan[ning] to do RM tasks mostly when at airport" is incorrect.  Of
course, there would be times when I'm not available, which is one
reason why I proposed the notion of a secondary RM.

>  > I agree with MJ's point - Koha is not a "benevolent dictator" sort of
>  > project, nor limited to any one view of library practice, so I suggest
>  > establishing a position of a secondary RM - someone who works with the
>  > primary RM to integrate patches, would do testing and signoffs of
>  > complicated patches, and, importantly, is designated to step in to
>  > keep the flow of patches going when the RM is away.
>
>  ++, although that would need a *huge* coordination between the 2 RMs,
>  which i'm not sure can be achieved.

It would require some coordination, but not necessarily a huge amount
of it.  The overall development plans should be communicated via
koha-devel RFCs and the staff wiki anyway, and those should be what
the RMs base their decisions on.  Sure, it's possible that the RMs
will occasionally disagree about a patch, but that's to be expected,
really, and would be worked out as such issues occur.

Regards,

Galen
-- 
Galen Charlton
Koha Application Developer
LibLime
galen.charlton at liblime.com
p: 1-888-564-2457 x709