Hi, On Tue, May 13, 2008 at 3:56 PM, Paul POULAIN <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
