- Koha-devel - lists.koha-community.org

german translation needed?
by das.t 23 Apr '06

23 Apr '06

hello & good day to everybody koha ... ;-) i am new in here & would like to ask: is there an insitiative to translate koha into german? i would like to either do that or pariticipate. this way i hope to get to know the software and find ways to do other work later. i would be glad to become a part of koha. ;-) (by the way, i understand koha3 is on the way, is there a release date yet?) a sort introduction: i am a librarian with quite some interest in it stuff and open source. currently i am not able to program, therefore i need other ways to help, but i am planning to learn. if you want to know more about my interests you might visit my (still beta) homepage at www.tonstrom.de. unfortunately i cannot participate in the kohacon. greetings, tobias

2 1

german translation needed?
by tobs 22 Apr '06

22 Apr '06

hello & good day to everybody koha ... ;-),,i am new in here & would like to ask: is there an insitiative to translate koha into german? i would like to either do that or pariticipate. this way i hope to get to know the software and find ways to do other work later.,i would be glad to become a part of koha. ;-),(by the way, i understand koha3 is on the way, is there a release date yet?),,a sort introduction: i am a librarian with quite some interest in it stuff and open source. currently i am not able to program, therefore i need other ways to help, but i am planning to learn.,if you want to know more about my interests you might visit my (still beta) homepage at www.tonstrom.de.,,unfortunately i cannot participate in the kohacon.,,greetings,,,tobias

1 0

new Koha & koha-translate ?
by Serhij Dubyk 22 Apr '06

22 Apr '06

Hello In which state preparation of update version (2.2.6 or 2.4)? What's about with support of Ukrainian (http://lists.gnu.org/archive/html/koha-announce/2006-01/index.html)? Serhij Dubyk, Lviv, Ukraine

1 0

acquisitions redesign
by Pierrick LE GALL 21 Apr '06

21 Apr '06

Hi koha-devel, Wanting to fix bug 285 (which is not one on HEAD) I've played today with the acquisition module. I must admit I've found it confusing. There are terminology incoherence (basket/order are used at wrong place for instance). I've found complicated to "search a supplier" to add an order to a "still not existing" basket :-/ So I propose to redesign Acquisitions. Only screens, not C4::Acquisitions or data model, only ergonomy. - on the main page, having the following links: - pending suggestion lists - supplier list - basket list - order list - funds and budgets management - currencies management and still on the main page, the "Help" box already existing in 2.2 - "list" link would have an associated page. The lists are HTML tables with filter capability. On the supplier line of acqui/supplier.pl we would have a link "show baskets" to a filtered list on acqui/basket.pl and "show orders" to a filtered list on acqui/order.pl. On the basket line of acqui/basket.pl... you see what I mean. - on each page we would have a link to "Add a supplier", "Add a basket"... - most important of all is the mecanism to add an order to a basket. Here is what I would find a better way : 1. the connected user selects an opened basket 2. if the connected user has an opened basket, the pending suggestion list, the search.marc/search.pl and MARCdetail.pl pages would have a link to order the selected biblio. As the catalogue is currently broken on my HEAD copy (zebra issues) I would be able to code only the adding of orders from pending suggestions, as long as catalogue is broken. What is your opinion about my suggestions? Bye -- Pierrick LE GALL INEO media system

3 3

first bug squashing party of 2006, april
by Pierrick LE GALL 19 Apr '06

19 Apr '06

Hi Koha development team, Let's try to organize a Bug Squashing Party on 2006, april 18th (tuesday) 13:00 GMT. This hour won't let new zealand participate but Ohio, France, England and Turkey should be more available. Is it OK? Who will be attending? Cheers, -- Pierrick LE GALL INEO media system

3 3

devWeek in Marseille, quick question
by Paul POULAIN 19 Apr '06

19 Apr '06

Hello, a quick question to everybody coming to Marseille for the devWeek : who comes with it's own computer (I hope almost everybody) ? who has wifi ? (answer by pm if you prefer, I ask koha-devel to avoid missing someone ;-) ) -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

2 1

maxoutstanding, maxreserves, noissuescharge
by Owen Leonard 19 Apr '06

19 Apr '06

I've been looking at Bug 426 today, and it got me thinking about some system preferences: maxoutstanding: maximum amount withstanding to be able make reserves maxreserves: maximum number of reserves a member can make noissuescharge: maximum amount withstanding to be able to check out an item Shouldn't these variables be set in borrower categories instead of system preferences? -- Owen

3 2

css for prog : a commit from me & pierrick rollback
by Paul POULAIN 18 Apr '06

18 Apr '06

Pierrick LE GALL a écrit : > Changes by: Pierrick LE GALL <plg(a)savannah.gnu.org> 06/04/18 09:53:10 > Log message: > modification: removed fieldset and label CSS properties. Modifications > introduced by tipaul are not compliant with every template (depending on how > you use HTML labels). Shouldn't this kind of customization only be made > outside "prog" template? > -fieldset { > - display:inline; > - vertical-align:top; > - > -label { > - width:10em; > -} You're right pierrick, they should not be in PROG. However : - without this small label property, you can't see where you have forgotten the <label> - without the fieldset css, all fieldset are vertically aligned, and you get a lot of empty space on the right and a looonnnggg page. So I don't think they are a problem, and they should be reintroduced. What does ppl think of this ? -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)

2 1

Koha Foundation
by Joshua Ferraro 14 Apr '06

14 Apr '06

Hi all, Over the past few weeks we've discussed the idea of forming a Koha Foundation -- a non-profit organization for Koha. I'd like to open this topic up to koha-devel to hear what your reasons are for wanting such an organization, as well as how you think it should be set up (and where). Any takers? Cheers, -- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf(a)liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS

12 31

QA manager
by Pierrick LE GALL 14 Apr '06

14 Apr '06

Hi koha-devel, On the last Koha team meeting of March 20th, 2006, we discussed about the position INEO (me for instance) could officialy take on the project. Joshua and Paul proposed me to be Quality Assurance (QA) manager, and I personnaly accepted this role for a two months try. I've just asked my INEO managers for a formal validation. On IRC, the definition about QA manager was discussed, because everybody doesn't define it the same way. Paul said "responsible for heavy testing" and I answered I did not agree with this point of view, not in OSS model. thd asked what difference I made between open and closed source QA. Let's answer this question by mail, as requested by Russ. See details on IRC logs [1]. I first answer to the question "what difference I make between open and closed source QA", then I'll describe what is my vision of QA manager for an OSS project like Koha. QA, proprietay Vs OSS ===================== I've worked on the two sides of softwares : proprietary and OSS. I think I understand the advantages and drawbacks of each model, concerning QA. In a proprietary model, the software *must* be /stable/ when reaching customers. In my vision, /stable/ means: - without bug that may corrupt customers data - without blocking bug Consequently, a proprietary software vendor needs to have a QA team. This team assures the stability of releases. No right to mistakes because financial penalties will be requested by customers. OSS model is different because it *involves* customer on QA. This is a very important point in my opinion. An OSS project must provide efficient tools to communicate with core dev team. Customers/users are willing to propose patches. OSS model partially moves QA to customers. Not completely of course, and I'll describe muy vision of QA management later. I'm sure Koha developers have all read Eric Raymond essay "The Cathedral & the Bazaar" [2] (if not, I encourage the reading). In this essay, you can read the summarize of Linus's law : "Given enough eyeballs, all bugs are shallow.". Koha team will never have enough eyeballs, this is why customers must be involved in bug tracking, from notification to test & validation. Having worked nearly 3 years in a proprietary software company, I can assure you that QA is one of the most critical task, and very often underestimated since it costs a lot while not giving back money directly. QA team needs to grow at the same speed as development team output, and even more because complexity increases more than linearly. OSS offers a solution to assure software quality without costing a lot more. Indeed, the more customers, the more requested features, the more tests required. If customers are involved in QA process, the number of testers will increase the same as the number of features. My conclusion is that in OSS, QA dedicated team don't need to be as big as development team. My explanations are very theoretical, in the reality OSS vendors have to "release often, release early" [2] and involve their customer at an early stage of deployment, not only before production deployment. This is why HEAD builds, 3.0-RCx are necessary. I think some customers will accept to play the role of beta tester. I ask Paul, Joshua, Russ and other Koha services vendor to give their opinion. My QA manager vision on Koha ============================ I come to my vision of QA manager on Koha project. The most important of the QA manager is to know the content of the bug tracker: 1. being notified on every update 2. dispatch issue to developers (with developer authorization) 3. check that each issue is assigned/treated 4. reduce time between bug notification and its closure It is important that no bug remain a too long time unassigned/untreated. If this happens, customer won't feel useful to involve herself. A bug rapidly corrected with a efficient communication between reporter and developer will encourage customers to report bugs, thus improving Koha quality in the long run. An additionnal task of the QA manager is Bug Squashing Party (BSP) coordination. I need to be explained how Koha worked on this in the past. I'm waiting for your feedback. [1] http://tinyurl.com/n4234 [2] http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ Cheers, -- Pierrick LE GALL INEO media system

5 5