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@calyx.net.au <mailto:irma@calyx.net.au> www.calyx.net.au <http://www.calyx.net.au/> http://koha-community.org/ http://kete.net.nz/
What I see a technical committee being, is just another step in the current process. IE they make recommendations, but things are still decided the way they are now, in the open on irc and mailing lists. If this is the case, and they are simply interested individuals who discuss issues and make recommendations then I'm ok with that. If they are expected to determine things, then I'm not ok with that. Chris 2010/11/3 Irma Birchall <irmalibraries@gmail.com>:
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@calyx.net.au www.calyx.net.au http://koha-community.org/ http://kete.net.nz/
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
From the recent email traffic, it sounds like there is a concern over
At the risk of sticking more than just a toe in water I've not been in a REALLY long time : ) and because I enjoy kicking over beehives -- How about a halfway step between vesting a subset of the community with authority or continuing to try to run everything through a whole group....? Would someone be willing to pull together a committee or two of volunteers (of necessity including a few of the usual suspects like the Release Manager) that at least are recognized as being willing to stay on top of some things, and pull things together. tracking things and too much needed to be followed/organized/etc by the same folks. I'd suggest, rather than the generic Technical Committee, something more specific -- I much prefer any committee to have a defined output/responsibility, rather than just meeting for the sake of meeting. Accepting Chris's thought the idea that the "Committee of the Whole" (the list & IRC participants) is the ultimate decision making mechanism, I'd say try to get some folks be step forward handle some specific functions as support to the process. Namely as... - an RFC Wrangling Committee, which would meet minimum once a month (just to check in) and/or within some set time period of new RFCs coming it (as in triggered by). The volunteers for this would maintain the RFC list, and assign states to things ("needs more info","for discussion","in progress","in code","fully incorporated" for example). The community can then use that state list to drive the overall agenda. This would make sure nothing gets ignored or forgotten. This should have a Senior and Junior Wrangler identified, who would help keep things focused - but would preserve broader community say in things. - a release committee (effectively exists now anyway) - which would be the developers and whomever else they feel is needed to define the Next Koha Release, juggled as it is now by current Release Manager. This gang should be left mostly alone by the "Whole" to worry about day-to-day/immediate questions. It might be worth trying to get a new volunteer/victim to be the next release manager very much in advance of the release date... that way, the general/scheduling discussion can get settled for the next release much sooner - without stressing out the "sitting" release manager. Call it the "prospective release manager" job, maybe? That way you get someone who'll be thinking about the long term but who'll have to live with that long term in the deliverable sense. As a further thought... If the volunteers for Senior and Junior Wrangler are in widely separate places, they could meet with subsets of the RFC group - which would be open meetings of course- on IRC, if desired, with less timezone headache. Does any of that help? Nick
On Wed, 3 Nov 2010, Irma Birchall wrote:
There is also the problem of coordinating development of features.
* how do we coordinate development? * who decides? * what is the structure for deciding?
this at lease seems like it should have a straightforward set of answers. Q: how do we coordinate development? by announceing what you are working on on this mailing list and letting other people comment if they are working on the same thing (or want to work with you on the feature) Q: who decides? Q: what is the structure for deciding? whoever is willing to do the work decides that a feature is being worked on. If there are disagreements on how a feature should be implemented (either due to multiple people working on the feature, or due to reviews of the code disputing details) the matter gets discussed on the mailing list. when the matter settles to a concensus, the release manager (or whoever is allowed to put code in the main tree) can then accept the code. As far as the issue of needing to do things between official releases, I would suggest that community opinion and preasure push really hard for this sort of change to be accepted into the central tree before it's shipped by anyone to customers. If this is not done, the company shipping the change is running the risk that it will not be accepted upstream and they will have to maintain it as a fork forever. If this is done there is little risk that the code will change significantly before the next release. While this second version is technically still a fork, it's a very closely related fork that is clearly temporary and will disappear as soon as the next official release takes place. note that faster releases significantly reduce this problem. David Lang _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
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@liblime.com <jwagner@ptfs.com> *From:* koha-bounces@lists.katipo.co.nz [mailto: koha-bounces@lists.katipo.co.nz] *On Behalf Of *Irma Birchall *Sent:* Wednesday, November 03, 2010 6:19 AM *To:* koha@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@calyx.net.au www.calyx.net.au http://koha-community.org/ http://kete.net.nz/
Irma Birchall wrote:
Below are notes that Bob and I compiled from a meeting at the KohaCon10 hackfest in Wellington last Sunday.
That was last Sunday, after myself and some others had left. Even at its peak, I think only 8 of 20+ development groups were present at the hackfest. Who was still present when this unannounced meeting happened? Did anyone comment on the inappropriate timing and minority attendence? Nevertheless, I sent some comments to Irma, Bob and others as soon as I heard about the topics, but most don't seem to be reflected in the notes, so I restate some of them here. Basically, I feel we already have the tools to solve the problems expressed; and not all of the things suggested as problems are problems; so we don't need a Technical Committee yet.
[...] Paul is concerned that there is no forum for decision making beyond the next release. [...]
Shortage of forums hardly seems a problem, as later in the notes:
The current decision-making forum is the monthly irc meeting. Other forums for discussion include the developers' list and the wiki (especially RFCs).
[...]
It is not clear how to get decisions made about major software issues. There is also the problem of coordinating development of features.
What problem? Sometimes features are implemented in multiple ways - sometimes this is healthy competition and sometimes it's because companies don't have the resources to share externally quickly, preferring to risk more competition.
* how do we coordinate development?
By IRC, Email, Bugzilla, Git, ...
* who decides?
Depends on the decisions, but it's likely to be either the Release Manager or the Koha Community.
* what is the structure for deciding?
You ask in a decision-making forum and get a decision.
Issues discussed on irc and koha-devel sometimes don't get resolved. No clear roadmap about what will get included in next official release.
There have been roadmaps: * http://wiki.koha-community.org/wiki/Roadmap_to_3.0 * http://wiki.koha-community.org/wiki/Roadmap_to_3.2 * http://wiki.koha-community.org/wiki/Roadmap_to_3.4 So, maybe the problem is not lack of roadmap, but that recent RMs have not kept roadmaps current? I think Chris's http://koha-releasemanagement.branchable.com/ and creative use of branches could help to populate the 3.4 roadmap and keep it current, but I'm not sure how. [...]
Suggestion to create a Technical Committee.
I really feel this isn't the right solution for our community. While Technical Committees are one way of settling disputes between developers, is one necessary for our mostly-friendly community? I feel it would be far better to empower and encourage the Release Manager for short-term decisions and to try using the current general community structures for long-term decisions.
Current meetings deal with the immediate, not the long term. A structural development meeting could be held regularly to discuss longer term development.
When did anyone last add a longer-term item to a meeting agenda? [...]
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.
Those RFCs were too late for 3.2 and we needed to see that before being able to make good comments on those RFCs. There's currently a bit of a problem with how the RFCs have been added to the new wiki, which has been discussed on devel and may be resolved soon.
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.
Skype would be very inappropriate for a free software community. I can set up a conference call accessible by SIP or telephone if needed, but IRC (and its web chat interface) seem fine so far.
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.
Is this a plan to overload us with bureaucracy and more meetings to attend? [...]
For further discussion and resolution at the Monthly IRC Meeting on 10 November.
Please don't. That would be really unfair to those of us who were not privy to the meeting and have just travelled back from KohaCon10. Also, surely no changes should be made to 3.4's process, else we will break Chris Cormack's brave release date statement, so why the tearing hurry? I note it's not on the agenda yet, so I suggest it would also be a bit cruel to anyone not following the email list closely to add such a major item with at most one day's notice. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
On 9 November 2010 02:03, MJ Ray <mjr@phonecoop.coop> wrote:
Irma Birchall wrote:
Below are notes that Bob and I compiled from a meeting at the KohaCon10 hackfest in Wellington last Sunday.
That was last Sunday, after myself and some others had left. Even at its peak, I think only 8 of 20+ development groups were present at the hackfest. Who was still present when this unannounced meeting happened? Did anyone comment on the inappropriate timing and minority attendence?
It was my clear understanding that none of those present at this "meeting" in any way saw it as a formal meeting, or one that was able to make any kind of decision on behalf of the community. I think it was made clear that this was an informal exchange of ideas - ideas that would then be taken to the proper fora - mailinglists and IRC meetings. This may not have come through in the notes from Bob and Irma.
Is this a plan to overload us with bureaucracy and more meetings to attend?
That was not what I heard. I think the main thing was to get more discussion/involvement around RFCs and long term decisions. And it was thought that one way to do this would be to have some kind of group of interested people looking into matters of interest, and then making their comments/recommendations available to the rest of the community before decisions are made.
For further discussion and resolution at the Monthly IRC Meeting on 10 November.
Please don't.
Agreed. It would seem out of character for our community to decide anything of this magnitude so fast. ;-) But let's discuss it a bit tomorrow and then let the meeting decide the next step(s)? Best regards, Magnus libriotech.no
Magnus Enger wrote:
On 9 November 2010 02:03, MJ Ray <mjr@phonecoop.coop> wrote:
Irma Birchall wrote:
Below are notes that Bob and I compiled from a meeting at the KohaCon10 hackfest in Wellington last Sunday.
That was last Sunday, after myself and some others had left. Even at its peak, I think only 8 of 20+ development groups were present at the hackfest. Who was still present when this unannounced meeting happened? Did anyone comment on the inappropriate timing and minority attendence?
It was my clear understanding that none of those present at this "meeting" in any way saw it as a formal meeting, [...]
Thanks, that's great to know, but doesn't answer either question. Who was present and did anyone comment on the timing and minority of views? There was a published schedule for the first day at the hackfest, which could have shown this. There was the final session at the main conference which could have discussed this too. These aren't topics which only appeared during the hackfest: someone had discussed them with me earlier and I'd outlined why I feel a technical committee would be an unnecessary backwards step. So I hope you can see why I feel this may have been submarined until some of us more-community/ less-businessy types had left.
Is this a plan to overload us with bureaucracy and more meetings to attend?
That was not what I heard. I think the main thing was to get more discussion/involvement around RFCs and long term decisions. And it was thought that one way to do this would be to have some kind of group of interested people looking into matters of interest, and then making their comments/recommendations available to the rest of the community before decisions are made.
That may be one way to do it, but have you ever tried to get a committee recommendation overturned in a similar system? It's hard. If we want to generate more RFC discussions, then I think there are simpler ways we should try first, before we disempower the release managers and wider community in this way. For example, we could start talking about feature RFCs more than bloody bureaucracy. I'd also clarify the boundaries and ban cross-posting between koha lists, to reduce the mail volumes. And appeal for people to average at most two or three list emails a day. Is this an attempt by some developers to externalise the cost of leading RFC discussions onto the wider community? But developers have the most to gain from an RFC they started being accepted... What are the specific problems with long-term decisions? I think one thing that some developers are worried about is that a long-term decision might not stick. If so, then the way to make it stick is to build consensus, not to appoint a ruling committee. As you can see from our lovely UK government and probably others, a change of composition in the ruling committee can mean reversal of a "long-term" decision if there wasn't consensus anyway.
For further discussion and resolution at the Monthly IRC Meeting on 10 November.
Please don't.
Agreed. It would seem out of character for our community to decide anything of this magnitude so fast. ;-) But let's discuss it a bit tomorrow and then let the meeting decide the next step(s)?
Pfff! As I pointed out, if we introduce a technical committee ruling over the release manager during 3.4, we probably break Chris's release date before work's hardly started. Why compound the AAF proposal arising from an unannounced meeting by holding a timetabling discussion at short notice? Hope that clarifies, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
On 10 November 2010 03:26, MJ Ray <mjr@phonecoop.coop> wrote:
Magnus Enger wrote:
On 9 November 2010 02:03, MJ Ray <mjr@phonecoop.coop> wrote:
Irma Birchall wrote:
Below are notes that Bob and I compiled from a meeting at the KohaCon10 hackfest in Wellington last Sunday.
That was last Sunday, after myself and some others had left. Even at its peak, I think only 8 of 20+ development groups were present at the hackfest. Who was still present when this unannounced meeting happened? Did anyone comment on the inappropriate timing and minority attendence?
It was my clear understanding that none of those present at this "meeting" in any way saw it as a formal meeting, [...]
Thanks, that's great to know, but doesn't answer either question. Who was present and did anyone comment on the timing and minority of views?
I was present, and yes I did point that out. I can't remember what I exactly said, but the thrust of it was that I didn't think it was something we should be discussing at hackfest. But the reason it was discussed after you left was not due to some nefarious plan to wait until you had gone, but more to the fact that I had managed to keep it off the agenda for the first 2 days and lost the fight on the last day. Chris
disclaimer : english is not my mother-language. Apologize for any frenchism, and, please, don't be offended by any term/word/sentence that may look aggressive: It's a mistake. Hello world, I'll try to answer everyone question/comments in this mail. * about the timing and the discussion : I made this discussion happend. I started to speak of our problems/questions/doubts/fears/needs/feelings on koha-devel mailing lists months ago (see "BibLibre strategy for Koha 3.4 and next version" thread, june, 2nd), tried many times to start (maybe I missed to be clear enough), and was really thinking that kohacon was THE place to speak of this, because we all would be here. Frankly, that's the only reason why hdl came (well, he was also happy to meet ppl, but we are overwhelmed by stuff, so...) Chris was thinking that we already had too much discussions during the 1st part of the kohacon, and wanted to help newbies. He organised the conference, so I let him choose, hoping he would understand how important it was to me. At the end, he understood and on sunday morning aknowledged to speak of this. No shadow or hidden or anything bad (frankly speaking MJ, your suspiciousness is really <<don't know which word to say here. Don't want to offend, but let me just say it's hard to feel like guilty of something bad>>) * about the content of the discussion : what I/BibLibre want(ed) to point was that WE (the community) HAVE A PROBLEM. Believe me or not, but we have one, and we must deal with it ! Let me explain what I think by taking some examples: * on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new features on circulation & announcing RFCs. NO-ONE, answered this mail. NO-ONE argued. We had/have a contract. So we did the job. That's a problem : all our customers are now live with those features. But we don't know if they will be accepted in the main trunk, because no-one said "ok, let's do it, from a strategic/feature/technical point of view, it's where the Koha project want to go". * last month, we sent a mail about moving to solR. Another sponsored work (thanks St Etienne). Some have answered. BUT : no decision has been taken. I don't mean here saying "ok, BibLibre, we will integrate your work without looking at how you did it", but no-one has said "OK, BibLibre, it's where the project want to go, your arguments are fine, there is only one problem with z3950 server that seems to be solvable. If it is solved, this streategic decision is taken". We have to go ahead, and now, if it's not accepted by the community, our only option will be to fork ! * Last week, I wrote many mails on koha-devel to announce all our underway RFCs. Maybe you can argue there's something wrong with what I wrote. The problem is that, once again, no-one has said anything ! So, what must we do next ? * Savitra Sirohi wrote detailled RFCs in september. And they look awesome from a functionnal point of view. hdl asked for some schedules, got an answer, but I feel it's not enough. We (community) should work more closely with him to know sooner if/how the coding is going. As other companies, we have contracts we must fulfill. But : if "the community" think RFC-X is a wrong idea, then I'm ready to go back to the customer and say : "well, the community argues it's a bad idea, could we find a solution that would fit everyone needs" ? In fact, i'm sure the sponsoring library will accept and we will find a solution (mostly because 1-I trust the community as "wise". So i think/am sure the community won't reject something unless it's a bad idea and 2-our sponsoring libraries understand what is Free Software and won't want to fork!) SO: we (BibLibre) don't want a "technical commitee", what we want is to have a working workflow to manage how things evolve/are improved/... Our workflow works quite well ... if it goes to the end. But nothing prevents us from having something falling in a black hole (frenchism suspected). And we (BibLibre) can't accept/deal with that. Not sure it's the correct term but http://en.wikipedia.org/wiki/Finite-state_machine is maybe what I want to express : in our workflow, we can sometimes have no result to a given starting action. Something like a technical commitee may fit the need. It may be something else. It's just that today, the situation is not sustainable ! Our (community) two problems may be summarised by : * short term problem : our workflow to deal with proposed contributions/features * long term problem : the strategic/major orientations of the project Chris C.: see my comment below (to nicholas rosasco) David Lang : I hope that you realise the previous lines are the answers to your answer: announcing is not enough: we did it, and it hasn't worked. And more than one time. Nicolas : I really LOVE your mail ! thanks to jump in the discussion:
How about a halfway step between vesting a subset of the community with authority or continuing to try to run everything through a whole group....? Maybe. I don't *want* to have a subset with authority. I just want to have a *working* workflow . Maybe a subset could be more efficient with authority. Maybe a subset reporting to "community" could be better. Maybe the community can decide everything (but : who is member of "the community" ?). an RFC Wrangling Committee, which would meet minimum once a month (just to check in) and/or within some set time period of new RFCs coming it (as in triggered by). The volunteers for this would maintain the RFC list, and assign states to things ("needs more info","for discussion","in progress","in code","fully incorporated" for example). The community can then use that state list to drive the overall agenda. This would make sure nothing gets ignored or forgotten. This should have a Senior and Junior Wrangler identified, who would help keep things focused - but would preserve broader community say in things
Sounds like a great idea ! (and I immediatly volunteer to be a member of this RFC wrangling committee !)
It might be worth trying to get a new volunteer/victim to be the next release manager very much in advance of the release date... that way, the general/scheduling discussion can get settled for the next release much sooner - without stressing out the "sitting" release manager. Call it the "prospective release manager" job, maybe? That way you get someone who'll be thinking about the long term but who'll have to live with that long term in the deliverable sense.
Not sure we need the Koha3.6 RM known today. But definetly, we need to plan the long-term evolutions of Koha ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
From my perspective (outsider with an investment in Koha success overall)... it sounds like an RFC Wrangler is just what is needed. To build on Nicolas' idea.... I see that person (or persons) as someone who wouldn't have an investment in any particular development path or particular feature but have the limited role of ensuring that an agreed-upon workflow developed, known to all, and is followed.
People need to know where to submit requests, how to write useful RFCs and how to submit them. Then when they are properly submitted, the RFC Wrangler ensures they are properly vetted by developers and sent back to the community or users and/or people who wrote the RFC for more work, more comment, minor adjustments, etc. That seems like it resolves the workflow issue, keeps the developers in control, and doesn't add unwanted bureaucracy into the mix. Lori On Tue, Nov 9, 2010 at 8:45 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
disclaimer : english is not my mother-language. Apologize for any frenchism, and, please, don't be offended by any term/word/sentence that may look aggressive: It's a mistake.
Hello world,
I'll try to answer everyone question/comments in this mail.
* about the timing and the discussion : I made this discussion happend. I started to speak of our problems/questions/doubts/fears/needs/feelings on koha-devel mailing lists months ago (see "BibLibre strategy for Koha 3.4 and next version" thread, june, 2nd), tried many times to start (maybe I missed to be clear enough), and was really thinking that kohacon was THE place to speak of this, because we all would be here. Frankly, that's the only reason why hdl came (well, he was also happy to meet ppl, but we are overwhelmed by stuff, so...) Chris was thinking that we already had too much discussions during the 1st part of the kohacon, and wanted to help newbies. He organised the conference, so I let him choose, hoping he would understand how important it was to me. At the end, he understood and on sunday morning aknowledged to speak of this. No shadow or hidden or anything bad (frankly speaking MJ, your suspiciousness is really <<don't know which word to say here. Don't want to offend, but let me just say it's hard to feel like guilty of something bad>>) * about the content of the discussion : what I/BibLibre want(ed) to point was that WE (the community) HAVE A PROBLEM. Believe me or not, but we have one, and we must deal with it !
Let me explain what I think by taking some examples: * on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new features on circulation & announcing RFCs. NO-ONE, answered this mail. NO-ONE argued. We had/have a contract. So we did the job. That's a problem : all our customers are now live with those features. But we don't know if they will be accepted in the main trunk, because no-one said "ok, let's do it, from a strategic/feature/technical point of view, it's where the Koha project want to go". * last month, we sent a mail about moving to solR. Another sponsored work (thanks St Etienne). Some have answered. BUT : no decision has been taken. I don't mean here saying "ok, BibLibre, we will integrate your work without looking at how you did it", but no-one has said "OK, BibLibre, it's where the project want to go, your arguments are fine, there is only one problem with z3950 server that seems to be solvable. If it is solved, this streategic decision is taken". We have to go ahead, and now, if it's not accepted by the community, our only option will be to fork ! * Last week, I wrote many mails on koha-devel to announce all our underway RFCs. Maybe you can argue there's something wrong with what I wrote. The problem is that, once again, no-one has said anything ! So, what must we do next ? * Savitra Sirohi wrote detailled RFCs in september. And they look awesome from a functionnal point of view. hdl asked for some schedules, got an answer, but I feel it's not enough. We (community) should work more closely with him to know sooner if/how the coding is going.
As other companies, we have contracts we must fulfill. But : if "the community" think RFC-X is a wrong idea, then I'm ready to go back to the customer and say : "well, the community argues it's a bad idea, could we find a solution that would fit everyone needs" ? In fact, i'm sure the sponsoring library will accept and we will find a solution (mostly because 1-I trust the community as "wise". So i think/am sure the community won't reject something unless it's a bad idea and 2-our sponsoring libraries understand what is Free Software and won't want to fork!)
SO: we (BibLibre) don't want a "technical commitee", what we want is to have a working workflow to manage how things evolve/are improved/... Our workflow works quite well ... if it goes to the end. But nothing prevents us from having something falling in a black hole (frenchism suspected). And we (BibLibre) can't accept/deal with that. Not sure it's the correct term but http://en.wikipedia.org/wiki/Finite-state_machine is maybe what I want to express : in our workflow, we can sometimes have no result to a given starting action. Something like a technical commitee may fit the need. It may be something else. It's just that today, the situation is not sustainable !
Our (community) two problems may be summarised by : * short term problem : our workflow to deal with proposed contributions/features * long term problem : the strategic/major orientations of the project
Chris C.: see my comment below (to nicholas rosasco)
David Lang : I hope that you realise the previous lines are the answers to your answer: announcing is not enough: we did it, and it hasn't worked. And more than one time.
Nicolas : I really LOVE your mail ! thanks to jump in the discussion:
How about a halfway step between vesting a subset of the community with authority or continuing to try to run everything through a whole group....? Maybe. I don't *want* to have a subset with authority. I just want to have a *working* workflow . Maybe a subset could be more efficient with authority. Maybe a subset reporting to "community" could be better. Maybe the community can decide everything (but : who is member of "the community" ?). an RFC Wrangling Committee, which would meet minimum once a month (just to check in) and/or within some set time period of new RFCs coming it (as in triggered by). The volunteers for this would maintain the RFC list, and assign states to things ("needs more info","for discussion","in progress","in code","fully incorporated" for example). The community can then use that state list to drive the overall agenda. This would make sure nothing gets ignored or forgotten. This should have a Senior and Junior Wrangler identified, who would help keep things focused - but would preserve broader community say in things
It might be worth trying to get a new volunteer/victim to be the next release manager very much in advance of the release date... that way, the general/scheduling discussion can get settled for the next release much sooner - without stressing out the "sitting" release manager. Call it
Sounds like a great idea ! (and I immediatly volunteer to be a member of this RFC wrangling committee !) the
"prospective release manager" job, maybe? That way you get someone who'll be thinking about the long term but who'll have to live with that long term in the deliverable sense.
Not sure we need the Koha3.6 RM known today. But definetly, we need to plan the long-term evolutions of Koha !
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi to all, this my answer to different questions done by Paul and about form a Koha Technical Committee.
* last month, we sent a mail about moving to solR. Another sponsored work (thanks St Etienne). Some have answered. BUT : no decision has been taken. I don't mean here saying "ok, BibLibre, we will integrate your work without looking at how you did it", but no-one has said "OK, BibLibre, it's where the project want to go, your arguments are fine, there is only one problem with z3950 server that seems to be solvable. If it is solved, this streategic decision is taken". We have to go ahead, and now, if it's not accepted by the community, our only option will be to fork !
For me (and others two italian users, not here and not CILEA clients) the answer is: Yes, do the solr search BUT mantains Zebra option. Using a periodical reboot, for us, the deamon zebraque is OK And we use only latin char.* Last week, I wrote many mails on koha-devel to announce all our
underway RFCs. Maybe you can argue there's something wrong with what I wrote. The problem is that, once again, no-one has said anything ! So, what must we do next ?
For me are OK.
* Savitra Sirohi wrote detailled RFCs in september. And they look awesome from a functionnal point of view. hdl asked for some schedules, got an answer, but I feel it's not enough. We (community) should work more closely with him to know sooner if/how the coding is going.
Now I'm working with Savitra Sirohi about the RFC "Analytic Record support" http://wiki.koha-community.org/wiki/Analytic_Record_support We speak on the lists and on IRC. I update the wiki with the request of everyone. Now we are working and there is a branch on git And we have received a fix from Henri-Damien LAURENT I know there is a "multi-level biblios" RFC but I don't know where is.
Something like a technical commitee may fit the need. It may be something else. It's just that today, the situation is not sustainable !
I'm agree, the situation is not sustainable. For me a technical committee is OK. Or also a RM as benevolent dictator (like Linus on Linux kernel). Bye Zeno Tajoli -- Zeno Tajoli CILEA - Segrate (MI) tajoliAT_SPAM_no_prendiATcilea.it (Indirizzo mascherato anti-spam; sostituisci qaunto tra AT con @)
Le 09/11/2010 18:24, Zeno Tajoli a écrit : >> * last month, we sent a mail about moving to solR. Another sponsored >> work (thanks St Etienne). Some have answered. BUT : no decision has been >> taken. I don't mean here saying "ok, BibLibre, we will integrate your >> work without looking at how you did it", but no-one has said "OK, >> BibLibre, it's where the project want to go, your arguments are fine, >> there is only one problem with z3950 server that seems to be solvable. >> If it is solved, this streategic decision is taken". We have to go >> ahead, and now, if it's not accepted by the community, our only option >> will be to fork ! > For me (and others two italian users, not here and not CILEA clients) > the answer is: > Yes, do the solr search BUT mantains Zebra option. > Using a periodical reboot, for us, the deamon zebraque is OK > And we use only latin char.* Last week, I wrote many mails on > koha-devel to announce all our It's really too hard to do : - the language we use to speak to zebra (ccl/cql) differs to the language we use with solR. - plus there are a lot of clumsy things in Search.pm that are adressed directly by solR (like facets management). - the index management we will add directly in Koha can't be done with zebra. - we were not able to deal with 2 index engines (yes, NoZebra was hoped to be an "index engine") that had exactly the same API, i'm sure it's impossible to deal with zebra+solR at the same time ! If we really would like to deal with both, the correct way to do it would be to rewrite for both solR and zebra. Keeping the zebra API&behaviour and using solR instead is just a no-no. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain wrote:
* about the timing and the discussion : I made this discussion happend. I started to speak of our problems/questions/doubts/fears/needs/feelings on koha-devel mailing lists months ago (see "BibLibre strategy for Koha 3.4 and next version" thread, june, 2nd), tried many times to start (maybe I missed to be clear enough), and was really thinking that kohacon was THE place to speak of this, because we all would be here.
http://lists.koha-community.org/pipermail/koha-devel/2010-June/034106.html I saw that thread and decided, ultimately, that it was not my place to comment on BibLibre's strategy. I wouldn't run a business that way, but it's up to you. Koha 3.4 strategy is in Chris C's capable hands, so I didn't comment on the initial post at all. Even if I think it's not really up to BibLibre to try to tell the RM what that strategy should be, I'm sure it's better if I don't post it in my usual colourful language ;-) I didn't understand that "we must have a heavily organised team" actually meant adding more committees too, else I would have made a counter-proposal: let's try this lean time-based release before going to the other extreme and festooning koha-community with committees. Past RMs trying to disempower the new Release Managers so early in favour of a technical committee seems a bit unkind. It's never good if a release date slips, but it's not unique to the last release and I think the last two BibLibre RMs didn't give 100% accurate roadmaps and release dates either (for example, Koha 2.2.0 was announced for Sep 2004 but actually released Jan 2005) and the rest of us had to deal with that, although it did get worse afterwards.
[...] No shadow or hidden or anything bad (frankly speaking MJ, your suspiciousness is really <<don't know which word to say here. Don't want to offend, but let me just say it's hard to feel like guilty of something bad>>)
Consider this: the topic had been raised with me in private and I explained that I felt much already was in the power of the RM, that it's unreasonable to expect decisions to be irreversible, and that the hackfest was a bad place to hold such a non-hacking discussion. Then, the day after I left, the discussion happens anyway. I'm not saying it was subterfuge, but you probably couldn't make it look more like subterfuge without it actually being it. It smells very rotten. If you don't want people to be suspicious, don't walk softly behind them with knives, even if you're just making sandwiches. If you want to be obviously honest, tell them you're going to make sandwiches beforehand.
* about the content of the discussion : what I/BibLibre want(ed) to point was that WE (the community) HAVE A PROBLEM. Believe me or not, but we have one, and we must deal with it !
What is that problem? I know what problem was suggested to me, but is it low-comment RFCs, long-term technical decisions, or something else? This seems like an ill-framed discussion where each participant thinks it is trying to do something slightly different. Identify the problem clearly at the outset, not after random examples, and then maybe some solutions will become obvious to people.
Let me explain what I think by taking some examples: * on oct, 2009, Nicolas Morin wrote a mail about Lyon3 sponsored new features on circulation & announcing RFCs. NO-ONE, answered this mail. NO-ONE argued. We had/have a contract. So we did the job. That's a problem : all our customers are now live with those features. But we don't know if they will be accepted in the main trunk, because no-one said "ok, let's do it, from a strategic/feature/technical point of view, it's where the Koha project want to go".
http://lists.koha-community.org/pipermail/koha-devel/2009-October/032987.htm... People were asked to answer on the wiki instead of the mail, so why are you surprised no-one answered the mail? If you've deployed a private fork with those enhancements to all your clients, then I think that's a basic error, but you're very successful while the co-op is still looking for more clients, so who am I to criticise not selling real koha? Maybe I should sell our notorious one-library fork to clients instead of real koha?
* last month, we sent a mail about moving to solR. Another sponsored work (thanks St Etienne). Some have answered. BUT : no decision has been taken. I don't mean here saying "ok, BibLibre, we will integrate your work without looking at how you did it", but no-one has said "OK, BibLibre, it's where the project want to go, your arguments are fine, there is only one problem with z3950 server that seems to be solvable. If it is solved, this streategic decision is taken". We have to go ahead, and now, if it's not accepted by the community, our only option will be to fork !
Maybe you didn't notice, but last month many of us were at a conference on the other side of the world! BibLibre may be a large operation and able to undertake two large community efforts while serving all its client contracts, but if I'm spending weeks away, that means the rest of the co-op is probably working almost exclusively for clients. Be reasonable. I still have the thread to review, but there are numerous questions, some of which may be stupid (for example, what's a POC? Piece Of Cake? Piece of Code?) and it looks like something for 4.0 rather than 3.4. But again, you've got the contract, so ultimately, what is the incentive for most other developers to comment now, rather than waiting and seeing if it's any good and adaptable for mainline?
* Last week, I wrote many mails on koha-devel to announce all our underway RFCs. Maybe you can argue there's something wrong with what I wrote. The problem is that, once again, no-one has said anything ! So, what must we do next ?
Maybe you didn't notice, but last week many of us were travelling back from a conference on the other side of the world! Have you tried leading discussions about the RFCs, instead of flooding koha-devel with announcement emails? I don't remember the recent flood, so I've probably not read them yet, but a discussion is more than an announcement with "Comments welcome" on the end. [...]
SO: we (BibLibre) don't want a "technical commitee", what we want is to have a working workflow to manage how things evolve/are improved/... Our workflow works quite well ... if it goes to the end. But nothing prevents us from having something falling in a black hole (frenchism suspected). And we (BibLibre) can't accept/deal with that.
Well, where are the black holes? The main one mentioned so far is at the discussion stage, which I think means either: a. it's not important to anyone else, so it's between developer and RM to take it forward or kill it; b. the discussion is being led badly, which is up to the developer to remedy, or any interested party if they wish. If the developer does not take it forward, or does not remedy the bad discussion, then I feel they have effectively moved it to the "dead" state and it's just taking the process a while to catch up with that.
Our (community) two problems may be summarised by : * short term problem : our workflow to deal with proposed contributions/features
The Koha Community side is explained at http://wiki.koha-community.org/wiki/Category:RFCs The rest seems like BibLibre's problem. Why should we fix BibLibre?
* long term problem : the strategic/major orientations of the project
I don't really see a problem with this. To an extent, we go where libraries and technology take us, where seems obvious and where people are willing to try taking us.
[...] Maybe a subset reporting to "community" could be better. Maybe the community can decide everything (but : who is member of "the community" ?).
Please don't reopen that discussion. Koha Community was defined in the HLT Committee setup talks. I'm sure it's on the website. Yep, here it is: "Koha Community means those individuals and entities with a present active interest in the Koha Software or the Koha Project." http://koha-community.org/koha-project-organization/horowhenua-library-trust... [...]
an RFC Wrangling Committee, which would meet minimum once a month [...] Sounds like a great idea ! (and I immediatly volunteer to be a member of this RFC wrangling committee !)
Oh good grief. Another committee? If you want to wrangle RFCs, please just get on and do it. It would be very welcome to organise them better, such as the "abandoned" ones attributed correctly and those and the 3.0 and 3.2 ones being marked as done, obsolete or for future consideration. So could we try a time-based release and identify/remedy the problems with the RFC process as best we can now, rather than create committees? Thanks, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
I've been watching the discussion about a technical committee with some interest. But I am lost as to the need. One side says that we need a technical committee to wrangle the releases and RFC's for the various enhancements and fixes, but the other side says that's the Release Manager's job? When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they? And if dates slip, well, gee, won't we be getting a better release due to the extra work? Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise. I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with. Just my thoughts. Lenora StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
Lenora : +1 On Wed, Nov 10, 2010 at 8:15 AM, Lenora Oftedahl <OFTL@critfc.org> wrote:
I've been watching the discussion about a technical committee with some interest. But I am lost as to the need. One side says that we need a technical committee to wrangle the releases and RFC's for the various enhancements and fixes, but the other side says that's the Release Manager's job? When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Just my thoughts.
Lenora StreamNet Regional Librarian Columbia River Inter-Tribal Fish Commission http://www.fishlib.org
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. *Q: Why is this email three sentences or less? A: http://three.sentenc.es*
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed. Clearly the RM should: 1. Be knowledgeable of RFCs which are proposed for the current version. 2. Lead by example in the matter of participation in the RFC process. However, to suggest that the RM bares the responsibility for doing the leg-work in the RFC process will probably reduce the future candidate pool of RM's due to fear of being worked to death. It is, in fact, the responsibility of the author of the RFC (or the author's employer) to promote that RFC and keep it before the community. And it is the responsibility of the *community* to vet, critique, correct, and/or amend RFCs. Historically there have been failures on both parts. Things are looking up, however.
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. People who might be considered crazy (like me) and run the cutting edge code probably don't care. But not everyone can afford those risks. This is a problem which can be and is being addressed.
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I agree with this.
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Really about the best we can get without *active* * community* participation is an RFC cheerleader. I'm not sure what there is here to manage. The process/workflow is simple: 1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain. I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc. Kind Regards, Chris
The process/workflow is simple: 1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain. I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc. Chris, I think one of the problems is that the above-described simple process/workflow is not articulated clearly anywhere. There is a page ( http://koha-community.org/about/enhancing-koha/) that talks about varies ways to use Bugzilla but no mention of RFCs and that part of the process. Maybe adding a page that describes the process would help. With some sample RFCs. And info on how that relates to Bugzilla. Such a page could be linked to from "For Librarians" as well as the "Get Involved" page and possibly others. Lori Ayre On Tue, Nov 9, 2010 at 1:01 PM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed. Clearly the RM should:
1. Be knowledgeable of RFCs which are proposed for the current version.
2. Lead by example in the matter of participation in the RFC process.
However, to suggest that the RM bares the responsibility for doing the leg-work in the RFC process will probably reduce the future candidate pool of RM's due to fear of being worked to death.
It is, in fact, the responsibility of the author of the RFC (or the author's employer) to promote that RFC and keep it before the community.
And it is the responsibility of the *community* to vet, critique, correct, and/or amend RFCs.
Historically there have been failures on both parts. Things are looking up, however.
And if dates slip, well, gee, won't we be getting a better release due to
the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. People who might be considered crazy (like me) and run the cutting edge code probably don't care. But not everyone can afford those risks. This is a problem which can be and is being addressed.
Again, I think we are slipping into the commercial vendor mode where more
voices are being added for no purpose other than to make noise.
I agree with this.
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Really about the best we can get without *active* * community* participation is an RFC cheerleader. I'm not sure what there is here to manage.
The process/workflow is simple:
1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain.
I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc.
Kind Regards, Chris _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Lori, On Tue, Nov 9, 2010 at 7:48 PM, Lori Bowen Ayre <lori.ayre@galecia.com> wrote:
Chris, I think one of the problems is that the above-described simple process/workflow is not articulated clearly anywhere. There is a page (http://koha-community.org/about/enhancing-koha/) that talks about varies ways to use Bugzilla but no mention of RFCs and that part of the process. Maybe adding a page that describes the process would help. With some sample RFCs. And info on how that relates to Bugzilla. Such a page could be linked to from "For Librarians" as well as the "Get Involved" page and possibly others.
Actually this information is available on the wiki and is linked to from both the "For Librarians<http://koha-community.org/get-involved/for-librarians/>->Submitting your ideas (RFCs)" and the "For Developers<http://koha-community.org/get-involved/for-developers/>->RFC Guidelines" pages on the website. It is also linked to from the "Participation," "Development," and "Release Management" in the wiki. The direct link is: http://wiki.koha-community.org/wiki/Category:RFCs and has been up since back in May sometime. Kind Regards, Chris
Thanks for pointing out those links. Glad there is the start of a path to find the info. Yet, I didn't find any guidelines for writing an RFC. Here's what happens: "For Librarians" page prominently displays the link to Add your request to our bug database <http://bugs.koha-community.org/> (pointing you to Bugzilla) and then says for "detailed instruction" See this page on our wiki for detailed instructions (which points you to) <http://wiki.koha-community.org/wiki/Enhancement_Request_Guidelines> http://wiki.koha-community.org/wiki/Enhancement_Request_Guidelines which is not about RFCs at all. It is a confusing and scary screenshot of Bugzilla (at first glance anyway). The wiki page called RFCs-Koha Wiki says this much about RFCs: "add an RFC on the wiki. Be as detailled as possible. Specify an expected date of availability (deadline if sponsored), if it's sponsored (and if you want, by who). Use the template RFC (see below) to fill your template" Here's what I (as someone thinking the new feature I might want to pursue) feel is missing (and I'm no usability expert). I a am suggesting these specifics in hopes of being helpful, not to complain: - What does RFC means. - Is there a template or an example of a good one. - How to post it (the instructions do say to "send a mail on the mailing list but again...saying what? attaching the RFC? including the RFC in the post? naming the Bugzilla numbers? feature names?) - Are there guidelines about how to name it and relate it back to a Bugzilla entry. Is it one Bugzilla entry per RFC or could there be multiple Bugzilla entries in an RFC? And back to the RFC Wrangler (RW?) idea, maybe the RM could select the RW who would serve with him or her throughout the release cycle? Just a thought. I do think it would be useful to have someone monitor the enhancement request process and try to coordinate and track what people need to ensure it funnels into the RM and development team. Lori On Tue, Nov 9, 2010 at 6:53 PM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Lori,
On Tue, Nov 9, 2010 at 7:48 PM, Lori Bowen Ayre <lori.ayre@galecia.com> wrote:
Chris, I think one of the problems is that the above-described simple process/workflow is not articulated clearly anywhere. There is a page (http://koha-community.org/about/enhancing-koha/) that talks about varies ways to use Bugzilla but no mention of RFCs and that part of the process. Maybe adding a page that describes the process would help. With some sample RFCs. And info on how that relates to Bugzilla. Such a page could be linked to from "For Librarians" as well as the "Get Involved" page and possibly others.
Actually this information is available on the wiki and is linked to from both the "For Librarians<http://koha-community.org/get-involved/for-librarians/>->Submitting your ideas (RFCs)" and the "For Developers<http://koha-community.org/get-involved/for-developers/>->RFC Guidelines" pages on the website. It is also linked to from the "Participation," "Development," and "Release Management" in the wiki. The direct link is: http://wiki.koha-community.org/wiki/Category:RFCs and has been up since back in May sometime.
Kind Regards, Chris
Have you looked at all at http://wiki.koha-community.org/wiki/Category:RFCs This was recently written, and is now linked into the website so most (if not all) of the issues you bring up should be addressed. It's also a living document, and I'm sure will improve with time. Liz Rea NEKLS On Nov 10, 2010, at 9:38 AM, Lori Bowen Ayre wrote:
Thanks for pointing out those links. Glad there is the start of a path to find the info. Yet, I didn't find any guidelines for writing an RFC. Here's what happens:
"For Librarians" page prominently displays the link to Add your request to our bug database (pointing you to Bugzilla) and then says for "detailed instruction" See this page on our wiki for detailed instructions (which points you to) http://wiki.koha-community.org/wiki/Enhancement_Request_Guidelines which is not about RFCs at all. It is a confusing and scary screenshot of Bugzilla (at first glance anyway).
The wiki page called RFCs-Koha Wiki says this much about RFCs: "add an RFC on the wiki. Be as detailled as possible. Specify an expected date of availability (deadline if sponsored), if it's sponsored (and if you want, by who). Use the template RFC (see below) to fill your template"
Here's what I (as someone thinking the new feature I might want to pursue) feel is missing (and I'm no usability expert). I a am suggesting these specifics in hopes of being helpful, not to complain: What does RFC means. Is there a template or an example of a good one. How to post it (the instructions do say to "send a mail on the mailing list but again...saying what? attaching the RFC? including the RFC in the post? naming the Bugzilla numbers? feature names?) Are there guidelines about how to name it and relate it back to a Bugzilla entry. Is it one Bugzilla entry per RFC or could there be multiple Bugzilla entries in an RFC? And back to the RFC Wrangler (RW?) idea, maybe the RM could select the RW who would serve with him or her throughout the release cycle? Just a thought. I do think it would be useful to have someone monitor the enhancement request process and try to coordinate and track what people need to ensure it funnels into the RM and development team.
Lori
On Tue, Nov 9, 2010 at 6:53 PM, Chris Nighswonger <cnighswonger@foundations.edu> wrote: Hi Lori,
On Tue, Nov 9, 2010 at 7:48 PM, Lori Bowen Ayre <lori.ayre@galecia.com> wrote:
Chris, I think one of the problems is that the above-described simple process/workflow is not articulated clearly anywhere. There is a page (http://koha-community.org/about/enhancing-koha/) that talks about varies ways to use Bugzilla but no mention of RFCs and that part of the process. Maybe adding a page that describes the process would help. With some sample RFCs. And info on how that relates to Bugzilla. Such a page could be linked to from "For Librarians" as well as the "Get Involved" page and possibly others.
Actually this information is available on the wiki and is linked to from both the "For Librarians->Submitting your ideas (RFCs)" and the "For Developers->RFC Guidelines" pages on the website. It is also linked to from the "Participation," "Development," and "Release Management" in the wiki. The direct link is: http://wiki.koha-community.org/wiki/Category:RFCs and has been up since back in May sometime.
Kind Regards, Chris
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Liz, I did look at this and it was very helpful. The questions I still have remain unanswered but this would be the best place to answer those questions. I could work on making some of those changes directly if you like. What is the protocol for editing those pages? Lori On Wed, Nov 10, 2010 at 9:40 AM, Liz Rea <lrea@nekls.org> wrote:
Have you looked at all at http://wiki.koha-community.org/wiki/Category:RFCs
This was recently written, and is now linked into the website so most (if not all) of the issues you bring up should be addressed.
It's also a living document, and I'm sure will improve with time.
Liz Rea NEKLS
On Nov 10, 2010, at 9:38 AM, Lori Bowen Ayre wrote:
Thanks for pointing out those links. Glad there is the start of a path to find the info. Yet, I didn't find any guidelines for writing an RFC. Here's what happens:
"For Librarians" page prominently displays the link to Add your request to our bug database <http://bugs.koha-community.org/> (pointing you to Bugzilla) and then says for "detailed instruction" See this page on our wiki for detailed instructions (which points you to) <http://wiki.koha-community.org/wiki/Enhancement_Request_Guidelines> http://wiki.koha-community.org/wiki/Enhancement_Request_Guidelines which is not about RFCs at all. It is a confusing and scary screenshot of Bugzilla (at first glance anyway).
The wiki page called RFCs-Koha Wiki says this much about RFCs: "add an RFC on the wiki. Be as detailled as possible. Specify an expected date of availability (deadline if sponsored), if it's sponsored (and if you want, by who). Use the template RFC (see below) to fill your template"
Here's what I (as someone thinking the new feature I might want to pursue) feel is missing (and I'm no usability expert). I a am suggesting these specifics in hopes of being helpful, not to complain:
- What does RFC means. - Is there a template or an example of a good one. - How to post it (the instructions do say to "send a mail on the mailing list but again...saying what? attaching the RFC? including the RFC in the post? naming the Bugzilla numbers? feature names?) - Are there guidelines about how to name it and relate it back to a Bugzilla entry. Is it one Bugzilla entry per RFC or could there be multiple Bugzilla entries in an RFC?
And back to the RFC Wrangler (RW?) idea, maybe the RM could select the RW who would serve with him or her throughout the release cycle? Just a thought. I do think it would be useful to have someone monitor the enhancement request process and try to coordinate and track what people need to ensure it funnels into the RM and development team.
Lori
On Tue, Nov 9, 2010 at 6:53 PM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
Hi Lori,
Chris, I think one of the problems is that the above-described simple process/workflow is not articulated clearly anywhere. There is a page (http://koha-community.org/about/enhancing-koha/) that talks about varies ways to use Bugzilla but no mention of RFCs and that part of the
On Tue, Nov 9, 2010 at 7:48 PM, Lori Bowen Ayre <lori.ayre@galecia.com> wrote: process.
Maybe adding a page that describes the process would help. With some sample RFCs. And info on how that relates to Bugzilla. Such a page could be linked to from "For Librarians" as well as the "Get Involved" page and possibly others.
Actually this information is available on the wiki and is linked to from both the "For Librarians<http://koha-community.org/get-involved/for-librarians/>->Submitting your ideas (RFCs)" and the "For Developers<http://koha-community.org/get-involved/for-developers/>->RFC Guidelines" pages on the website. It is also linked to from the "Participation," "Development," and "Release Management" in the wiki. The direct link is: http://wiki.koha-community.org/wiki/Category:RFCs and has been up since back in May sometime.
Kind Regards, Chris
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
2010/11/11 Lori Bowen Ayre <lori.ayre@galecia.com>:
Hi Liz, I did look at this and it was very helpful. The questions I still have remain unanswered but this would be the best place to answer those questions. I could work on making some of those changes directly if you like. What is the protocol for editing those pages? Lori
Its a wiki, edit it. :) Chris
Lori Bowen Ayre wrote: [...]
Here's what I (as someone thinking the new feature I might want to pursue) feel is missing (and I'm no usability expert). I a am suggesting these specifics in hopes of being helpful, not to complain:
- What does RFC means.
From Virtual Entity of Relevant Acronyms (Version 1.9, June 2002) [vera]:
RFC Request For Comments (Internet, RFC)
- Is there a template or an example of a good one.
http://wiki.koha-community.org/wiki/Template:RFC is a template. http://wiki.koha-community.org/wiki/Add_support_for_NORMARC is an example of a good one, but you can see many examples of bad ones (particularly those mangled by moving from the old wiki) which are still valid and worthwhile RFCs, so don't feel that you have to write a good one first time.
- How to post it (the instructions do say to "send a mail on the mailing list but again...saying what? attaching the RFC? including the RFC in the post? naming the Bugzilla numbers? feature names?)
I'd summarise the RFC in the post and probably give bugzilla numbers and feature names, but not attach the whole RFC. It's up to you and how you feel most comfortable trying to start a discussion, though. It sounds like a few people can give examples of how *not* to do it, from recent emails.
- Are there guidelines about how to name it and relate it back to a Bugzilla entry. Is it one Bugzilla entry per RFC or could there be multiple Bugzilla entries in an RFC?
There aren't really any naming guidelines yet and I think there could be multiple bugs per RFC in some cases, but should be at least one.
And back to the RFC Wrangler (RW?) idea, maybe the RM could select the RW who would serve with him or her throughout the release cycle?
Yes, the RM could do that. I think it's overcomplicating things, but each to their own.
Just a thought. I do think it would be useful to have someone monitor the enhancement request process and try to coordinate and track what people need to ensure it funnels into the RM and development team.
I think the RM will need some way to track, whether a RW or directly. Developers will also need to track things for their own interests and sponsors/commissioners probably should want to too. So, I feel that we need to improve trackability in general, whether that's for any specific person or not. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Le 09/11/2010 22:01, Chris Nighswonger a écrit :
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed.
I fully agree with you. And that's why i'm proposing to have another structure/team/guy/whatever to work on strategic/long-term things. To answer MJ question related to that question : I fully agree solR won't probably be included in 3.4 (not ready enough,...) But do we want it for 3.6 ? (to answer your comment : yes we have a contract, but i'm ready, if "the community" argue & decide it's a wrong idea, to reach the library and explain the problem. And find a solution) But atm, I have no clear decision taken, just a global feeling that "ppl think it's a good idea if we succeed to address the z3950 server problem". Do you think I should consider this as enough and go my way? I don't think so, because the customer want his sponsored work to be in official Koha. Does it mean I just should shut my mouth, candidate to be the RM for 3.6, and do what I want here in term of strategic decision ? Well, if ppl think it's how I should do, then I'll do. But that's not how I want to do it : community matter
Clearly the RM should:
1. Be knowledgeable of RFCs which are proposed for the current version.
++
2. Lead by example in the matter of participation in the RFC process.
++
However, to suggest that the RM bares the responsibility for doing the leg-work in the RFC process will probably reduce the future candidate pool of RM's due to fear of being worked to death.
++ AND (as I already wrote), the RM deals with the next version, and sometimes things will be for the next-next version. Or the next-next-next. Or some things are related to long-term so must be addressed separately (ie : not just in a given version)
It is, in fact, the responsibility of the author of the RFC (or the author's employer) to promote that RFC and keep it before the community.
And it is the responsibility of the *community* to vet, critique, correct, and/or amend RFCs.
Historically there have been failures on both parts. Things are looking up, however.
Agreed. (I'm not trying to say I did everything well. But I try to learn from my mistakes, and I just want Koha to be always more and more reliable & sustainable & predictible)
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. ++ and i'm 10000% happy with the time-based release for 3.4 & for futures versions hopefully.
And, once again, I feel very uncomfortable when chris says : "it's the decision for 3.4, the 3.6RM will decide how he want to deal with it". I strongly disagree : it should a community "stable" decision a RM can't change just because he want to change it. That's a question of being sustainable & predictible (for both vendors and users)
People who might be considered crazy (like me) and run the cutting edge code probably don't care. But not everyone can afford those risks. This is a problem which can be and is being addressed.
agreed
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I agree with this.
Not sure I understand well what's meaning here. (The fact is that many new features are developed by sponsored work and commercial vendors, so we have to deal with that ! )
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Really about the best we can get without *active* * community* participation is an RFC cheerleader. I'm not sure what there is here to manage.
The process/workflow is simple:
1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain.
Well, that's what I do : I complain loudly ;-)
I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc.
++ I think it's a great idea too ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
the problem is that you are asking for a binding decision. open source software projects really don't work that way. if it's useful to a library (or if a library thingks it would be useful), there's probably very little that would be rejected based on the description (what would show up in an RFC) when it comes to the implementation, it's primarily a matter of taste, and there you have a lot of people who can object to the implementation, and they can object at any point up to (or even shortly after) the point where it is merged. the RM makes the final decision on if the code is clean enough for the RMto be comfortable shipping it. you may be targeting a feature at 3.6, but there is no way that you can get assurance that it will be accepted into 3.6 this early in the process. depending on how the code works, how it's written, and how comfortable the RM is that it will work and be supported, it may get into 3.6, or the 3.6 RM may decide not to accept it at which point you should then try to either convince the 3.6 maintainier that he's wrong, or wait for 3.8 and try to convince that RM. I know this is not what you are wanting to hear, but this is one of the differences with open source projects, there is not the same commitment to prior decisions that you see in closed source projects. This is especially true when doing time-based releases. If a feature is 'ready' it will be included, if it's not 'ready' it won't be. 'ready' can include a lot more than just 'does the code work', it can include style, taste of the implementation, documentation, support concerns (if you are submitting something that nobody else thinks is very useful, but the community has concerns that you may just drop off the code and disappear leaving them to maintain the code the community will be less willing to accept the code) as you develop the feature, maintain communication. as you make design decisions let people know about it. as soon as you have something that works (however imperfectly and unpolished) publish what you have so people can look at it. there is no point past which you can rule out major redesign requsts. It may be that after you have things working someone will notice similarities with other code and ask you re refactor things to better share code. on the other hand, just because someone asks you to make a change doesn't mean that you must make that change, even if it's the RM. as the person writing the code you have a fair amount of power. you can argue back on why you don't want to do so. don't overuse this power, if things get heated it's playing a game of chicken with the community, but if the request is something that's really a problem for you, push back. If it's a matter of not having time in this release, you may be able to negotiate 'accept this as-is and I willre-write the functionality as you ask and have it ready for the next release', this sort of thing requires that you have built a reputation with the community so that they can trust you, and that the changes that are needed are mostly (if not completely) transparent to the users. in the case of alternate search capibilities, the initial implemenation may be a either/or approach where you completely replace the existing search. a second cut of the implementation may re-write the search interface to be more general and less tuned for either specific search option. a third cut of the implementation may refactor both search implementations to share a lot of their code and only differ in the routines that call the search engine. a fourth cut of the implementation may include expanding this to support some additional search options to demonstrate that the search interface is now generic enough to be useful going forward. David Lang On Wed, 10 Nov 2010, Paul Poulain wrote:
Le 09/11/2010 22:01, Chris Nighswonger a ?crit :
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed.
I fully agree with you. And that's why i'm proposing to have another structure/team/guy/whatever to work on strategic/long-term things.
To answer MJ question related to that question : I fully agree solR won't probably be included in 3.4 (not ready enough,...) But do we want it for 3.6 ? (to answer your comment : yes we have a contract, but i'm ready, if "the community" argue & decide it's a wrong idea, to reach the library and explain the problem. And find a solution) But atm, I have no clear decision taken, just a global feeling that "ppl think it's a good idea if we succeed to address the z3950 server problem". Do you think I should consider this as enough and go my way? I don't think so, because the customer want his sponsored work to be in official Koha.
Does it mean I just should shut my mouth, candidate to be the RM for 3.6, and do what I want here in term of strategic decision ? Well, if ppl think it's how I should do, then I'll do. But that's not how I want to do it : community matter
Clearly the RM should:
1. Be knowledgeable of RFCs which are proposed for the current version.
++
2. Lead by example in the matter of participation in the RFC process.
++
However, to suggest that the RM bares the responsibility for doing the leg-work in the RFC process will probably reduce the future candidate pool of RM's due to fear of being worked to death.
++
AND (as I already wrote), the RM deals with the next version, and sometimes things will be for the next-next version. Or the next-next-next. Or some things are related to long-term so must be addressed separately (ie : not just in a given version)
It is, in fact, the responsibility of the author of the RFC (or the author's employer) to promote that RFC and keep it before the community.
And it is the responsibility of the *community* to vet, critique, correct, and/or amend RFCs.
Historically there have been failures on both parts. Things are looking up, however.
Agreed. (I'm not trying to say I did everything well. But I try to learn from my mistakes, and I just want Koha to be always more and more reliable & sustainable & predictible)
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. ++ and i'm 10000% happy with the time-based release for 3.4 & for futures versions hopefully.
And, once again, I feel very uncomfortable when chris says : "it's the decision for 3.4, the 3.6RM will decide how he want to deal with it". I strongly disagree : it should a community "stable" decision a RM can't change just because he want to change it. That's a question of being sustainable & predictible (for both vendors and users)
People who might be considered crazy (like me) and run the cutting edge code probably don't care. But not everyone can afford those risks. This is a problem which can be and is being addressed.
agreed
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I agree with this.
Not sure I understand well what's meaning here. (The fact is that many new features are developed by sponsored work and commercial vendors, so we have to deal with that ! )
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Really about the best we can get without *active* * community* participation is an RFC cheerleader. I'm not sure what there is here to manage.
The process/workflow is simple:
1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain.
Well, that's what I do : I complain loudly ;-)
I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc.
++ I think it's a great idea too !
[This discussion has mostly been continued in other threads on the koha-devel list and in threads related to RFCs on this list.] At an earlier point in the discussion, we may have lost sight of a basic premise under which Koha has been developed even if has occasionally been neglected by a few people from time to time. We want everyone's good contributions to Koha. We do not want any patches to fall on the floor and become lost kittens. We have demonstrated that the collaborative open source development model works by our ability to produce software which is more useful to more people than what any small group of us would be able to create working in isolation, despite all imperfections. Most importantly, the free software license gives each of us the right to take that collaborative effort and change the code to suit each of own preferences which the collective effort has not yet met. Including individually modified code within the collaborative effort helps everyone, especially whoever has made the modification. Having given a reminder about the usual case, this discussion is about what happens when there are collaboration conflicts. We hope to resolve collaborative conflicts in a manner which encourages the inclusion of each of our preferences within one larger collaborative work, thus avoiding the need for individual implementations to use different code. Remainder of reply inline: 1. DECISION TAKING PROCESS. On Wed, November 10, 2010 18:07, david@lang.hm wrote:
the problem is that you are asking for a binding decision. open source software projects really don't work that way.
I agree with the basic point which David Lang is making. However, there is some difference between binding decisions and obtaining a reasonable consensus.
if it's useful to a library (or if a library thingks it would be useful), there's probably very little that would be rejected based on the description (what would show up in an RFC)
when it comes to the implementation, it's primarily a matter of taste, and there you have a lot of people who can object to the implementation, and they can object at any point up to (or even shortly after) the point where it is merged.
With or without a consensus, if some patch is appropriate for Koha and would not disrupt other past or present development, then there should be no formal reason not to include such a patch in the general release. Patches should ideally be tested for approval by people independent from the original author of the patch. 2. ROLE OF RELEASE MANAGER.
the RM makes the final decision on if the code is clean enough for the RMto be comfortable shipping it.
The release manager is elected to unify work for a particular release and to be mindful of any schedule for that release. While the release manager should be subject to persuasion from reasonable arguments, the release manager needs to be able to exercise final control over what patches are included and how they are included to adequate unify everyone's work within the context of any schedule.
you may be targeting a feature at 3.6, but there is no way that you can get assurance that it will be accepted into 3.6 this early in the process. depending on how the code works, how it's written, and how comfortable the RM is that it will work and be supported, it may get into 3.6, or the 3.6 RM may decide not to accept it at which point you should then try to either convince the 3.6 maintainier that he's wrong, or wait for 3.8 and try to convince that RM.
[I think David Lang meant RM (release manager) when using 'maintainer' in the previous sentence. Release maintainer is a similar but different role for the current stable release.] 3. CORRECTING DECISIONS.
I know this is not what you are wanting to hear, but this is one of the differences with open source projects, there is not the same commitment to prior decisions that you see in closed source projects.
All decisions should always be subject to open minded consideration in any context. Rethinking decisions allows for recovery from past, present, and future mistakes. Some decisions are more difficult to effectively change than others, such as the choice of programming language for the project. [This example is merely a good one and not a subtle argument for or against using work from any particular programming language.] Free software projects provide freedom to modify the code locally instead of the tight control of the proprietary development process. 4. CODE READINESS.
This is especially true when doing time-based releases. If a feature is 'ready' it will be included, if it's not 'ready' it won't be. 'ready' can include a lot more than just 'does the code work', it can include style, taste of the implementation, documentation, support concerns
Any minimal sense of readiness for patches should include running, usable implementation, and not creating uncorrected problems for other features. David adds style, documentation, and support concerns as important criteria which may be the next most important concerns but which I do not think should be grounds for not including a patch. The last point for minimal readiness about not creating uncorrected problems for other features is the difficulty which I understand has brought this discussion forward. Features might include anything from security standards to specific user functionality.
(if you are submitting something that nobody else thinks is very useful, but the community has concerns that you may just drop off the code and disappear leaving them to maintain the code the community will be less willing to accept the code)
The community should be happy to have good well written code 'dropped off' even if a vested interest in maintaining code would be preferred. If a patch is sufficiently useful, someone is liable to come forward to maintain it and and improve it. 5. COMMUNICATION.
as you develop the feature, maintain communication. as you make design decisions let people know about it. as soon as you have something that works (however imperfectly and unpolished) publish what you have so people can look at it.
It is the responsibility of those developing something for Koha to introduce it early and often prior to and throughout the planning and during the implementation of the work. Developers should contact anyone and everyone with whom it may be useful to consult for comment and criticism. Those with an interest in particular aspects of Koha have an obligation to give attention to development announcements on the koha-devel mailing list. Ignoring well publicised: sufficiently detailed RFCs; implementation strategies; and posting of running code might reasonably be interpreted as the absence of an objection. However, it is the obligation of developers to do more to encourage comment if there has not been any comment. Developers need to take comments which they receive seriously. People need good reason to believe that their comments may be liable to have a meaningful effect on actual development to have sufficient incentive to take a close examination and comment well. 6. CAREFUL RESEARCH AND PLANNING.
there is no point past which you can rule out major redesign requsts. It may be that after you have things working someone will notice similarities with other code and ask you re refactor things to better share code.
Anyone might identify a problem at any point which may not have been previously apparent. A developer has an obligation to research and plan an implementation carefully to avoid the risk of others making a late discovery of a problem which the developer could have readily identified earlier by taking more care in advance. 7. SHOWING COMPATIBILITY.
on the other hand, just because someone asks you to make a change doesn't mean that you must make that change, even if it's the RM. as the person writing the code you have a fair amount of power. you can argue back on why you don't want to do so. don't overuse this power, if things get heated it's playing a game of chicken with the community, but if the request is something that's really a problem for you, push back. If it's a matter of not having time in this release, you may be able to negotiate 'accept this as-is and I willre-write the functionality as you ask and have it ready for the next release', this sort of thing requires that you have built a reputation with the community so that they can trust you, and that the changes that are needed are mostly (if not completely) transparent to the users.
Someone may comment that a prospective development conflicts with existing features or other current development. If a developer believes that the presumption of a conflict is mistaken, it is the responsibility of the developer to show how the prospective development would not create such a conflict. 8. REFACTORING OR REWRITING TO AVOID COLLABORATIVE CONFLICTS.
in the case of alternate search capibilities, the initial implemenation may be a either/or approach where you completely replace the existing search. a second cut of the implementation may re-write the search interface to be more general and less tuned for either specific search option. a third cut of the implementation may refactor both search implementations to share a lot of their code and only differ in the routines that call the search engine. a fourth cut of the implementation may include expanding this to support some additional search options to demonstrate that the search interface is now generic enough to be useful going forward.
Well designed code should not need to be rewritten but merely refactored for some functional purpose such as abstraction. Refactoring to avoid conflicts with other development may be necessary for collaboration to go forward. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
Paul Poulain wrote:
I fully agree with you. And that's why i'm proposing to have another structure/team/guy/whatever to work on strategic/long-term things.
Which seems a bit daft to me when it's not clear why/how the current structure isn't working. I asked "What is that problem?" in my mail of Wed Nov 10 07:33:14 NZDT 2010 and no answer to that yet from any of the tech-ctte advocates... a solution looking for a problem, then?
To answer MJ question related to that question : I fully agree solR won't probably be included in 3.4 (not ready enough,...) But do we want it for 3.6 ?
Personally, I don't know yet. I've asked some questions in the Solr thread, but there are many many many</Lassard> questions which seemed unanswered by the announcement and I didn't feel like a discussion was really wanted. At the moment, Solr looks like an awful overreaction based on very few real problems and maybe no insoluable ones, but it's maybe just that the basis was hidden away inside biblibre instead of shared with the community as it developed, so I've a bit of catching up to do. [...]
Historically there have been failures on both parts. Things are looking up, however.
Agreed. (I'm not trying to say I did everything well. But I try to learn from my mistakes, and I just want Koha to be always more and more reliable & sustainable & predictible)
OK, so what did you learn from 2.2's release date slip? Please share it with the later RMs and help us all. [...]
I strongly disagree : it should a community "stable" decision a RM can't change just because he want to change it. That's a question of being sustainable & predictible (for both vendors and users)
Well, if such a community decision is taken, I think it would be an unlikely-to-be-appointed RM candidate who didn't respect it. [...]
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I agree with this.
Not sure I understand well what's meaning here. (The fact is that many new features are developed by sponsored work and commercial vendors, so we have to deal with that ! )
Not necessarily. Globally, we have no obligation to accept every sponsored POC which vendors offer to the community. It is in the vendors' interest to get those things accepted, but it is in the community's interests only to accept the "right" ones. [...]
The process/workflow is simple:
1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain.
Well, that's what I do : I complain loudly ;-)
Yeah. Still not seen BibLibre actively promoting RFC discussion. http://lists.koha-community.org/pipermail/koha-devel/2010-November/034557.ht... is not a serious discussion-starter. One short mail for 32 RFCs? It's barely longer than the mail I sent for my last one RFC http://lists.katipo.co.nz/public/koha/2010-September/025182.html and the 32-RFC mail doesn't ask any specific questions. So to make it blunt what I think Chris N might have been trying to say subtly: don't complain and try promoting RFC discussion. ;-) Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Past Koha Release Manager (2.0), LMS programmer, statistician, webmaster. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Reply inline: On Wed, November 10, 2010 15:54, Paul Poulain wrote:
Le 09/11/2010 22:01, Chris Nighswonger a écrit :
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
1. ADVISING THE DEVELOPMENT PROCESS.
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed.
I fully agree with you. And that's why i'm proposing to have another structure/team/guy/whatever to work on strategic/long-term things.
I fully understand the need to have discussion, comment, and criticism of prospective development plans to have a good sense of what the community would favour. Forming any ad hoc group for consultation is something which anyone can do at any time. The more open the group, the more legitimacy its work would have to the rest of the Koha community. A select small group of interested people is also fine for obtaining a perspective outside of one development organisation and would obtain legitimacy by a demonstration of critical detailed examination of development work. Everyone benefits by having work examined by those outside the self-reinforcing insularity of the organisation preparing some work. As I explained in my concurrence with David Lang, rigid long term decisions are antithetical to the vibrancy of the open source development model used in free software projects, http://lists.katipo.co.nz/pipermail/koha/2010-November/026272.html . Rigid long term decisions are also a weakness of the development model most often used for proprietary software. We should not empower any group to do more than advise the development process. Whatever comment can be obtained from whomever one can obtain it, can inform the development process of an organisation. Favourable comments and the absence of objections can be used to reassure development clients of the likelihood of successful feature integration and help persuade the release manager to include a development option as the best course even when there is some conflict with other development. If an issue is sufficiently important, a community consensus can be obtained which a release manager would be reluctant to oppose. We should be careful not to impose an undue burden on anyone who has been willing to do the work of release manager. We should also be careful not to mistake the 'tyranny of the majority' for a consensus which could clobber features used by a minority. Remember that everyone is a member of the minority for something. The easiest means to ensuring cooperative development inclusion is careful planning in advance and early wide consultation to avoid development conflicts. Developers need to be prepared to make appropriate changes any time there is serious criticism of their work. We want all the good work relevant to Koha which people produce to be included. 2. SOLR/LUCENE BASED RECORD INDEXING AND RETRIEVAL.
To answer MJ question related to that question : I fully agree solR won't probably be included in 3.4 (not ready enough,...) But do we want it for 3.6 ? (to answer your comment : yes we have a contract, but i'm ready, if "the community" argue & decide it's a wrong idea, to reach the library and explain the problem. And find a solution) But atm, I have no clear decision taken, just a global feeling that "ppl think it's a good idea if we succeed to address the z3950 server problem".
I hope that BibLibre and others will take the following as the constructive criticism it is intended to be. Everyone should be reminded that BibLibre and Paul Poulain's predecessor business have provided in my opinion the greatest share of important features for Koha without which most of us would not be using Koha. Paul Poulain's business also did much of the most difficult early development work for Zebra. The prospect of dropping Zebra support in favour of a Solr/Lucene support being developed by BibLibre is a major factor which has led to discussions about how to best manage development conflicts. I think that Solr/Lucene will prove to be the best option for local record indexing in Koha long term which it would not have been at the time Zebra support was developed for Koha. The disagreement from me at least is only over how the consequences of such a change are managed. An issue is whether Zebra remains available for use as an option along side Solr/Lucene at least until everyone is satisfied that Zebra can be replaced without loss of capabilities. Much of the capabilities which Zebra support provides are not being used in Koha and we are comparing our own familiarity with Zebra difficulties with a rosy ideal of what Solr/Lucene offers. The first advantage of Solr/Lucene is that it empowers less sophisticated users to control how indexing is configured via a web interface. A web interface could be created for Zebra but that is not an existing feature. I am for everything which empowers users to more easily exercise control over their software. There is more than just the problem of losing very good Z39.50/SRU server support which would follow from BibLibre's announced implementation of Solr/Lucene for local indexing. Z39.50 client support which was undertaken for local indexing with Zebra could enable future Z39.50/SRU client development without Zebra. In rewriting searching for their own testing branch of Koha for Solr/Lucene implementation, BibLibre have removed valuable Z39.50 client support which could be used in future features such as querying Z39.50 servers in addition to Solr/Lucene in the OPAC and presenting a unified result set using Pazpar2. Z39.50 client copy cataloguing support is independent from C4::Search and is thus safe but could not be improved using code from C4::Search if that code is gone. As I have stated previously, C4::Search ought to be rewritten in future using prefix query format (PQF) as the native language for Z39.50. Continuing to support Common Command Language (CCL) is trivial because Yaz translates CCL to PQF as it does now for Koha. In the context of refactoring to support all options, future rewriting of C4::Search for Zebra would be rewriting it in C4::Search::Zebra along with C4::Search::Solr and C4::Search would become a neutral abstraction. When the opportunity to rewrite the Zebra code would arise, rewriting would be much easier with known working code to use as a starting point, however imperfects. The Koha community, especially BibLibre, have a huge amount of work invested in Zebra support and as I stress the development which underlies Zebra support. It would be a shame to loose the future benefit of that investment for problems which all seem resolvable to me even if Solr/Lucene is found to be a superior solution for local indexing as I expect it will be in due time. I continue to investigate JZKit for a Z39.50/SRU server from Knowledge Integration and options from Index Data. Today, I reminded Ian Ibbotson from Knowledge Integration that I am still waiting for a direct reply to some specific questions which I posed over two weeks ago about JZKit. Most of the details which I know about JZKit came from carefully examining the source code but I do not want to rely upon that examination and other clues alone in the absence of documentation. I will present a full report with a detailed examination of capabilities and options when I have received a further response from those who know their code best. I have raised all of these issues on the koha-devel list without much specific response. On the koha-devel list, MJ Ray has also more recently asked for more details about Zebra problems in a form which could be independently examined by others and he should have more complete replies than he has had thus far, http://lists.koha-community.org/pipermail/koha-devel/2010-November/034664.ht... . I have other comments to make about the prospective Solr/Lucene implementation which I have not put forward but I do not wish to confuse what I could improve later for Solr/Lucine support with what would be extraordinarily difficult to improve if support would be removed for Zebra. 3. CONTINUING DISCUSSION.
Do you think I should consider this as enough and go my way? I don't think so, because the customer want his sponsored work to be in official Koha.
Does it mean I just should shut my mouth, candidate to be the RM for 3.6, and do what I want here in term of strategic decision ? Well, if ppl think it's how I should do, then I'll do. But that's not how I want to do it : community matter
Hooray for the customer wanting cooperation and not relegation to a difficult to maintain fork of Koha. I have great respect for everyone who takes the time to engage in discussion, presents evidence in support, and argues for a position based on evidence. We only risk running aground when we do not take the time to have discussions.
Clearly the RM should:
1. Be knowledgeable of RFCs which are proposed for the current version.
++
2. Lead by example in the matter of participation in the RFC process.
++
However, to suggest that the RM bares the responsibility for doing the leg-work in the RFC process will probably reduce the future candidate pool of RM's due to fear of being worked to death.
++
AND (as I already wrote), the RM deals with the next version, and sometimes things will be for the next-next version. Or the next-next-next. Or some things are related to long-term so must be addressed separately (ie : not just in a given version)
It is, in fact, the responsibility of the author of the RFC (or the author's employer) to promote that RFC and keep it before the community.
And it is the responsibility of the *community* to vet, critique, correct, and/or amend RFCs.
Historically there have been failures on both parts. Things are looking up, however.
Agreed. (I'm not trying to say I did everything well. But I try to learn from my mistakes, and I just want Koha to be always more and more reliable & sustainable & predictible)
We all have to make mistakes to learn from them and the more work one does the more likely one is to make mistakes which are learning opportunities. I commend BibLibre for their hard work. I hope for more than mere predictability for Koha. I hope to be regularly astonished by unpredictable improvements in Koha in which I would include Solr/Lucene based indexing when it is well implemented.
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. ++ and i'm 10000% happy with the time-based release for 3.4 & for futures versions hopefully.
And, once again, I feel very uncomfortable when chris says : "it's the decision for 3.4, the 3.6RM will decide how he want to deal with it". I strongly disagree : it should a community "stable" decision a RM can't change just because he want to change it.
This point could just as easily be taken in the opposite way. The 'community stable decision' in which everyone participated had been to choose Zebra in 2005 and in this case the release manager is merely acting to preserve people's options and not undue what had been the community consensus or loose a good feature even if only a minority of users are currently making use of it. Some people in the community could decide that some new development should be acceptable despite concerns about bugs and safety.
That's a question of being sustainable & predictible (for both vendors and users)
People who might be considered crazy (like me) and run the cutting edge code probably don't care. But not everyone can afford those risks. This is a problem which can be and is being addressed.
agreed
Again, I think we are slipping into the commercial vendor mode where more voices are being added for no purpose other than to make noise.
I agree with this.
Not sure I understand well what's meaning here. (The fact is that many new features are developed by sponsored work and commercial vendors, so we have to deal with that ! )
I think adding a SINGLE person to the release team of RFC manager to make comments and organize RFC's might help the RM, but that's up to the Release Manager to choose someone they can work with.
Really about the best we can get without *active* * community* participation is an RFC cheerleader. I'm not sure what there is here to manage.
The process/workflow is simple:
1. Post your RFC on *both* the wiki and both lists. 2. Bump the post to the lists if you (as the author) feel that there is not enough vetting, etc. going on. 3. If you (as the author) are actively promoting your RFC and it is not getting enough discussion, feel free to complain loudly; otherwise, don't complain.
Well, that's what I do : I complain loudly ;-)
I think the idea suggested in another thread of having a section of the monthly news letter to highlight RFCs is a great idea. Perhaps it could especially highlight those with fewer comments/discussion/etc.
++ I think it's a great idea too !
The more publicity for RFCs the better. The brief RFCs descriptions which people tend to write should not become mere static documents as originally described by the developer. They should be expanded with implementation details when implementation options are considered. Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
On Fri, 19 Nov 2010, Thomas Dukleth wrote:
On Wed, November 10, 2010 15:54, Paul Poulain wrote:
Le 09/11/2010 22:01, Chris Nighswonger a ?crit :
On Tue, Nov 9, 2010 at 2:15 PM, Lenora Oftedahl <OFTL@critfc.org> wrote:
1. ADVISING THE DEVELOPMENT PROCESS.
When the Release Manager is chosen and accepts the position, they understand what they are taking on, don't they?
Just to clarify: It is *not* the responsibility of the RM to vet RFCs and pursue the critique, correction, and/or amending of them. The RM simply wields the final say over what is finally actually pushed.
I fully agree with you. And that's why i'm proposing to have another structure/team/guy/whatever to work on strategic/long-term things.
<SNIP>
If an issue is sufficiently important, a community consensus can be obtained which a release manager would be reluctant to oppose. We should be careful not to impose an undue burden on anyone who has been willing to do the work of release manager.
or the person who will have to maintain the version after the initial release.
We should also be careful not to mistake the 'tyranny of the majority' for a consensus which could clobber features used by a minority. Remember that everyone is a member of the minority for something.
this is a very important point. "I don't see a need for this" is not a valid reason to not get something upstream. "this is complicated, confusing code, that interacts with all this other stuff that I have to maintain, and you will not be helping me maintain it" could be a valid reason. Thomas is indicating that things like maintinance, documentation, taste, etc are not valid reasons for not merging something, but I think that the in some cases it may a good reason, it really depends on how intrusive the changes are. If it's a module that is only used if people enable that specific feature, the criteria is close to 'if it works, ship it', but if it's changes to core code, the bar to accepting is much higher.
2. SOLR/LUCENE BASED RECORD INDEXING AND RETRIEVAL.
To answer MJ question related to that question : I fully agree solR won't probably be included in 3.4 (not ready enough,...) But do we want it for 3.6 ? (to answer your comment : yes we have a contract, but i'm ready, if "the community" argue & decide it's a wrong idea, to reach the library and explain the problem. And find a solution) But atm, I have no clear decision taken, just a global feeling that "ppl think it's a good idea if we succeed to address the z3950 server problem".
I hope that BibLibre and others will take the following as the constructive criticism it is intended to be. Everyone should be reminded that BibLibre and Paul Poulain's predecessor business have provided in my opinion the greatest share of important features for Koha without which most of us would not be using Koha. Paul Poulain's business also did much of the most difficult early development work for Zebra. The prospect of dropping Zebra support in favour of a Solr/Lucene support being developed by BibLibre is a major factor which has led to discussions about how to best manage development conflicts.
I think that Solr/Lucene will prove to be the best option for local record indexing in Koha long term which it would not have been at the time Zebra support was developed for Koha. The disagreement from me at least is only over how the consequences of such a change are managed. An issue is whether Zebra remains available for use as an option along side Solr/Lucene at least until everyone is satisfied that Zebra can be replaced without loss of capabilities.
I would say that it would probably be a good move to make it so that both indexers are supported, and it would probably be a good idea to setup the framework so that if someone came in tomorrow with a third indexer they could write it to work with this framework and users could select any of the three at installation time (with some thought to how to convert from one to another after running for a while) This is the sort of thing I was referring to when I said that someone proposing a change may be asked to make things more generic and flexible. This is also a case where the party proposing the new solution (Solr) is asked to modify the existing solution (Zebra) to use the new interface. note that I know nothing about Zebra or Solr and in no way am saying that either is better than the other. But I am saying that moving from one solution to two possible solutions should be generalized into supporting many possible solutions. I've heard a quote (and I have no idea who from) along the lines of There are three interesting values in Computer Science, 0, 1, and many we are moving from 1 to 2, moving to many is probably not a very big change (although doing so may require re-thinking the interface calls to be more generic)
And if dates slip, well, gee, won't we be getting a better release due to the extra work?
Again looking at history, the type of slippage traditionally seen is terrible for users, vendors, and clients of vendors. You cannot plan around an ever-moving date. ++ and i'm 10000% happy with the time-based release for 3.4 & for futures versions hopefully.
And, once again, I feel very uncomfortable when chris says : "it's the decision for 3.4, the 3.6RM will decide how he want to deal with it". I strongly disagree : it should a community "stable" decision a RM can't change just because he want to change it.
This point could just as easily be taken in the opposite way. The 'community stable decision' in which everyone participated had been to choose Zebra in 2005 and in this case the release manager is merely acting to preserve people's options and not undue what had been the community consensus or loose a good feature even if only a minority of users are currently making use of it.
I have seen this same argument around time based releases happen on the linux-kernel lists. Several years of time based releases after many years of 'let the dates slip, the release will be better' seems to show pretty decisivly that frequent releases with what's ready at that time work better in practice than delaying a release until the features that were tagged for it are all ready. if you delay a release until the feature is ready, there is a lot of preasure to declare it ready when it really isn't, because people really want all the other features that are in a new release. because the releases aren't predictable, developers really want thir stuff to go into _this_ release because they don't know how long they will have to wait for the next one. If you have frequent releases, the knowledge of when the next release will happen (and therefor when the code will be upstream) In addition, with opensource projects, the developers who aren't working at a particular bug are generally not working on that release, they are working on new features for the next release. this leads to a cycle where 1. lots of stuff goes in to a release 2. the release gets delayed 3. more stuff goes into the next release, making more interactions, more new stuff to test (and have bugs) 4. the release gets delayed longer 5. goto 3
Some people in the community could decide that some new development should be acceptable despite concerns about bugs and safety.
From thomas' comments, there is no community concern that this feature would be dropped in and the the developers would disappear, so the
remember that is the new version of a feature (in this case Solr for seach) still allows the old version (zebra) to be used), the only reason to argue against the change is that it makes the code worse and reliability will suffer. maintinance, documentations, etc issues that I was listing should not be an issue. so if you create a generic 'search engine' interface and use it for Solr and modify Zebra to use it there is probably very little that could derail your work. such a interface could then have someone else create a google module (either dealing with a google search appliance, or talking to a google cloud service, or both), and it's possible that a couple years down the line someone comes up with a new search module that everyone likes so much that neither Zebra or Solr are used by anyone. If that happens, it would still be a win for this project, and for the developers who introduce Solr (because they made all the other search experimentation possible) David Lang
Le 19/11/2010 22:41, Thomas Dukleth a écrit :
Reply inline:
Much of the capabilities which Zebra support provides are not being used in Koha and we are comparing our own familiarity with Zebra difficulties with a rosy ideal of what Solr/Lucene offers. The first advantage of Solr/Lucene is that it empowers less sophisticated users to control how indexing is configured via a web interface. A web interface could be created for Zebra but that is not an existing feature. I am for everything which empowers users to more easily exercise control over their software. As far as I know, solr is succesfully everyday used in many opensource OPACS, and other projects too (thunderbird, alfresco, Drupal, .... ). I donot claim that they are better than we do. But why should we doubt
[snip]> that this solution, widely used, which is a real kind of standard in indexing engine would be a good one ? a) Getting and providing Suppport fot that tool would be easier. Solr community exists. b) Since it has been used in Vufind, and Blacklight, i think we could share experiences more easily, Eventually direct bridges between Koha and those solutions.
There is more than just the problem of losing very good Z39.50/SRU server support which would follow from BibLibre's announced implementation of Solr/Lucene for local indexing. Z39.50 client support which was undertaken for local indexing with Zebra could enable future Z39.50/SRU client development without Zebra. In rewriting searching for their own testing branch of Koha for Solr/Lucene implementation, BibLibre have removed valuable Z39.50 client support which could be used in future features such as querying Z39.50 servers in addition to Solr/Lucene in the OPAC and presenting a unified result set using Pazpar2. Z39.50 client copy cataloguing support is independent from C4::Search and is thus safe but could not be improved using code from C4::Search if that code is gone.
It was done in koha2.2 and as far as I know, without zebra, this feature still exists in our testing box. It is just using direct ZOOM search rather than C4::Search::SimpleSearch. So this valuable feature is still there. And we care not to break existing features. Same for the Z3950 server which we wrote a wrapper using Net::Z3950::SimpleServer. This would allow ppl to expose their collection as a Z3950 server.
As I have stated previously, C4::Search ought to be rewritten in future using prefix query format (PQF) as the native language for Z39.50.
Well, Rewriting the whole Search With PQF would not be handy in many aspects. I have thought about that many times. And using PQF still appears to me not to be the solution. a) It is really a pain to maintain and analyse. b) Whenever you need some more feature in your search, you have to add some more qualifiers, and therefore provide a robust parser.
Continuing to support Common Command Language (CCL) is trivial because Yaz translates CCL to PQF as it does now for Koha. In the context of refactoring to support all options, future rewriting of C4::Search for Zebra would be rewriting it in C4::Search::Zebra along with C4::Search::Solr and C4::Search would become a neutral abstraction. Again, we used Data::SearchEngine as a base for coding, and use the results from qurying Data::SearchEngine If anyone is willing to write a Data::SearchEngine::Zebra, Data::SearchEngine::Nutch, Data::SearchEngine::Pazpar2, feel free to do so. We will contribute not just to our little community. But to the wider PERL community.
When the opportunity to rewrite the Zebra code would arise, rewriting would be much easier with known working code to use as a starting point, however imperfects. This is why we are willing to gather use cases. To build Tests !!! No tests have ever really been built for C4::Search. So at the moment, I can't assign your fear of loss of features. Provide tests and will do our best to make it pass. If it is proven that we can't then we will talk precisely. By the way, did you know that the "valuable" feature you told about searching "The" was not really a zebra feature as you stated. But provided by the Search itself. It duplicated the old need for null words in Koha. But then again, there was no tests for that.
I have raised all of these issues on the koha-devel list without much specific response. On the koha-devel list, MJ Ray has also more recently asked for more details about Zebra problems in a form which could be independently examined by others and he should have more complete replies than he has had thus far, http://lists.koha-community.org/pipermail/koha-devel/2010-November/034664.ht...
Well I wanted a meeting to be held and we were working on testing and trying to assing all the raised problems in order to provide you with more technical details. Expect another message from us soon. -- Henri-Damien LAURENT BibLibre
Apparently, I had not been explicitly clear in a couple of messages relating to Solr/Lucene. Being as clear as I can be briefly: I favour using Solr/Lucene for local indexing in Koha. I oppose losing support for Zebra as a Z39.50/SRU server without a replacement with a sufficiently comparable feature set. There is no other free software Z39.50/SRU server with a sufficiently comparable feature set at present. I also oppose losing the Z39.50 client support in Koha and other useful searching features which had been developed for Zebra. Such a loss would affect future development but not currently implemented features if Solr/Lucene would replace Zebra. BibLibre's prospective rewrite of searching does not affect the current Koha Z39.50 client for copy cataloguing which does not rely upon the Koha search module, C4::Search. Only possible improvements in copy cataloguing would be affected if some Koha search code would no longer be available as a model. Anyone who has worked with Zebra knows that it can be like working with a mysterious black box when updating indexes at least. Reports of failures from Zebra with no error message and I presume conversely no success code on success need close investigation if we are relying on Zebra for any purpose. Good error reporting is vital for good software. No software ever 'just works'. The presumption that software 'just works' comes from not examining it closely enough or because errors are within some tolerance range for errors. After determining that Solr/Lucene is now suitable for Koha, I have given my attention to seeing what would need to be done to improve some Z39.50/SRU server option to have a sufficiently comparable feature set to Zebra but with support for Solr/Lucene. The attention which I have given to the BibLibre suggestion of JZKit as a replacement Z39.50/SRU server may have led me to neglect other things such as the full significance of BibLibre's use of the Data::SearchEngine Perl module for adding Solr/Lucene support to Koha. Remainder of reply inline: On Sat, November 20, 2010 04:49, LAURENT Henri-Damien wrote:
Le 19/11/2010 22:41, Thomas Dukleth a écrit :
Reply inline:
[snip]>
1. QUALITIES OF SOLR/LUCENE.
Much of the capabilities which Zebra support provides are not being used in Koha and we are comparing our own familiarity with Zebra difficulties with a rosy ideal of what Solr/Lucene offers. The first advantage of Solr/Lucene is that it empowers less sophisticated users to control how indexing is configured via a web interface. A web interface could be created for Zebra but that is not an existing feature. I am for everything which empowers users to more easily exercise control over their software. As far as I know, solr is succesfully everyday used in many opensource OPACS, and other projects too (thunderbird, alfresco, Drupal, .... ). I donot claim that they are better than we do. But why should we doubt that this solution, widely used, which is a real kind of standard in indexing engine would be a good one ?
I do not doubt that Solr/Lucene provides for good indexing and searching. At the time which the projects which Henri-Damien Laurent lists started using Solr/Lucene, the Solr/Lucene feature set was not sufficiently sophisticated for Koha and clearly less well developed than Zebra. Lucene would have been sufficient by 2006 but not the simplified subset of features supplied by Solr/Lucene at the time. See my koha-devel list message about the issue, http://lists.koha-community.org/pipermail/koha-devel/2010-October/034468.htm... .
a) Getting and providing Suppport fot that tool would be easier. Solr community exists.
A large independent software community is certainly better than depending on the small library market. However, libraries have additional special needs, such as Z39.50/SRU support which the wider market should not be expected to provide. 2. OVERSIMPLIFICATION.
b) Since it has been used in Vufind, and Blacklight, i think we could share experiences more easily, Eventually direct bridges between Koha and those solutions.
We may well be able to learn much from the experience which VuFind and Blacklight have had with Solr/Lucene. They are attractive OPACs which do not have the burden of providing a proper library automation system. However, in ignoring library science principles, they have not served their users as well as they might have otherwise. The most significant advantages of VuFind and Blacklight are a primitive implementation of faceted browsing from the result set. Their model copied the same primitive model provided by Endeca for NCSU, http://www2.lib.ncsu.edu/catalog . Facets are treated as mere text strings often without contextual meaning. Subfields are treated in isolation with no contextual association, most usually only subfield $a appears in facets. Authority control is not used for authority controlled fields. In adding faceting from the result set to Koha, Joshua Ferraro followed the fashionable interest of the moment in the NCSU Endeca OPAC which was also the easiest to implement. Endeca had done much better work for non-library customers previously. I tried to interest Joshua in using a model more like facet browsing systems such as AquaBrowser, interfaces from OVID, and others. I even added my own more flexible design to the Koha wiki. Joshua continued to advocate the fashion for the NCSU Endeca OPAC and added a claim that LibLime users would not want a more sophisticated and necessarily more complex model. The BibLibre Solr/Lucene implementation seems to match the existing Koha implementation of facets which is no detriment to the hard work of BibLibre. A more sophisticated faceting model can always be provided for Koha in future. When cooperating with other projects, we should be aware that other projects have had limited goals. I hope that Koha will have as much to teach other projects as to learn from them in future.
3. Z39.50 CLIENT SUPPORT.
There is more than just the problem of losing very good Z39.50/SRU server support which would follow from BibLibre's announced implementation of Solr/Lucene for local indexing. Z39.50 client support which was undertaken for local indexing with Zebra could enable future Z39.50/SRU client development without Zebra. In rewriting searching for their own testing branch of Koha for Solr/Lucene implementation, BibLibre have removed valuable Z39.50 client support which could be used in future features such as querying Z39.50 servers in addition to Solr/Lucene in the OPAC and presenting a unified result set using Pazpar2.
Support for Pazpar2 may be the more significant part of the potential loss in this case. Koha has no UNIMARC specific support for Pazpar2, therefore, the possibility that people at BibLibre may under-appreciate the benefit of Pazpar2 is understandable. 3.1. Z39.50 CLIENT COPY CATALOGUING SUPPORT.
Z39.50 client copy cataloguing support is independent from C4::Search and is thus safe but could not be improved using code from C4::Search if that code is gone. It was done in koha2.2 and as far as I know, without zebra, this feature still exists in our testing box. It is just using direct ZOOM search rather than C4::Search::SimpleSearch. So this valuable feature is still there. And we care not to break existing features.
I should have put the Z39.50 client copy cataloguing sentence in a paragraph of its own. Henri-Damien seems to have misunderstood. My sentence clearly states that the Z39.50 client copy cataloguing support is safe. My concern is about the potential loss of search code which could be used to improve the copy cataloguing client in possible future development. 4. SIMPLESERVER.
Same for the Z3950 server which we wrote a wrapper using Net::Z3950::SimpleServer. This would allow ppl to expose their collection as a Z3950 server.
Net::Z39.50::SimpleServer has been on my list as one option which would need improvement to have features sufficiently comparable to Zebra as a Z39.50 Server. 'Simple' may be taken to mean that supporting complexity is an exercise left to the programmer using the tool. Implementations of SimpleServer generally only support use attributes because of the complexity of managing more. Below, Henri-Damien attests to the difficulties of parsing PQF reliably. SimpleServer does not support SRU. The documentation for SimpleServer is less complete than Zebra documentation. We also have much greater working knowledge of Zebra. I will enquire with IndexData about what options there might be for adding SRU support to SimpleServer. 5. PREFIX QUERY FORMAT.
As I have stated previously, C4::Search ought to be rewritten in future using prefix query format (PQF) as the native language for Z39.50.
Well, Rewriting the whole Search With PQF would not be handy in many aspects. I have thought about that many times. And using PQF still appears to me not to be the solution. a) It is really a pain to maintain and analyse. b) Whenever you need some more feature in your search, you have to add some more qualifiers, and therefore provide a robust parser.
I agree that analysing PQF connectors is tricky in comparison to CCL connectors which Yaz converts to PQF. In my own work independent of Koha, I overcame difficulties by having the user interface display the PQF query which my code would generate. I have code for writing PQF query sets which I had started in 2005 using PHP Yaz before Net::Z3950::ZOOM was available for Perl. My code supports the complete and I mean complete Bib-1 attribute set. I could port the code to Perl with a little effort, although, it would still need some work for more extensibility of the user controlled term sets. Queries built using PQF can be tested by building the same query in CCL and sending it to Yaz for conversion to PQF as a comparison. Writing a PQF parser to interpret incoming PQF queries for SimpleServer would be perhaps an order of magnitude more complex.
Continuing to support Common Command Language (CCL) is trivial because Yaz translates CCL to PQF as it does now for Koha.
6. CODE ABSTRACTION. In the context of
refactoring to support all options, future rewriting of C4::Search for Zebra would be rewriting it in C4::Search::Zebra along with C4::Search::Solr and C4::Search would become a neutral abstraction. Again, we used Data::SearchEngine as a base for coding, and use the results from qurying Data::SearchEngine If anyone is willing to write a Data::SearchEngine::Zebra, Data::SearchEngine::Nutch, Data::SearchEngine::Pazpar2, feel free to do so. We will contribute not just to our little community. But to the wider PERL community.
I had not given enough attention to Data::SearchEngine when giving as much attention as I have to investigating JZKit. Supporting the wider Perl community would be great. I am somewhat doubtful that Data::SearchEngine::Zebra or Data::SearchEngine::Pazpar2 would have much interest outside the Perl for libraries community but that would be much better than merely supporting the Koha community. I recognise that creating Data::SearchEngine::Zebra and Data::SearchEngine::Pazpar2 would require a rewrite rather than merely refactoring. Maintaining Zebra searching should not be necessary for maintaining Zebra as a Z39.50/SRU server. 7. USE CASES AND TESTING.
When the opportunity to rewrite the Zebra code would arise, rewriting would be much easier with known working code to use as a starting point, however imperfects. This is why we are willing to gather use cases.
Ian Ibbotson from Knowledge Integration informed me about local authority libraries in the UK using Z39.50 servers for conducting interlibrary loans between each other. Circulation issue are not my speciality and I asked him for more information about how Z39.50 servers are used as part of the interlibrary loan process. I would be pleased to have an answer from anyone.
To build Tests !!! No tests have ever really been built for C4::Search. So at the moment, I can't assign your fear of loss of features. Provide tests and will do our best to make it pass. If it is proven that we can't then we will talk precisely.
Please excuse a moment of fun. I could devise some search query tests which I think that a good record indexing and retrieval system out to pass but which Koha would always fail. Failing to pass some good tests which I could devise would certainly not be a regression not only because there have never been tests for searching in Koha. There have also never been very demanding specifications for searching in Koha to which tests could have been written apart from the great work which BibLibre have done to allowing authority records to be found by authority tracing and reference fields containing unauthorised terms. 8. RELEVANCY RANKING OF COMPLETE FIELD OR SUBFIELD MATCHES.
By the way, did you know that the "valuable" feature you told about searching "The" was not really a zebra feature as you stated. But provided by the Search itself. It duplicated the old need for null words in Koha. But then again, there was no tests for that.
This another point at which Henri-Damien has apparently misunderstood me. I had not claimed that ranking a complete field or subfield match to the top of the result list even for words some systems treat as stopwords is a Zebra feature, http://lists.koha-community.org/pipermail/koha-devel/2010-October/034477.htm... . I merely expressed my concern that the feature which Joshua Ferraro had written for searching might be an example of good code which could be lost as part of simplification reducing the search code by 90% in BibLibre's rewriting of Koha search code. A title containing 'the' as the only word in a title may not match a realistic case but the principle would be the same. Real world examples of titles which would not be indexed or have low relevancy rankings in many systems include "A" by Andy Warhol and "It" by Stephan King. I do not know that 90% of the Koha search code would be unnecessary without Zebra but maybe with the virtue of switching to Data::SearchEngine would necessitate just such a degree of simplification while maintaining features. Much code could be saved if Solr/Lucene manages what the Koha search code now needs to manage for local searching when using Zebra. Some code is almost certainly inefficient and overly complex without benefit. Code simplicity is not a virtue above all others. Feature sophistication often requires irreducible code complexity to address irreducible complexities in the world. Sophisticated features tend to take more code to implement than less sophisticated ones. Code may need complexity to properly provide simplicity and ease of use for the user. 9. FURTHER EXAMINATION.
I have raised all of these issues on the koha-devel list without much specific response. On the koha-devel list, MJ Ray has also more recently asked for more details about Zebra problems in a form which could be independently examined by others and he should have more complete replies than he has had thus far, http://lists.koha-community.org/pipermail/koha-devel/2010-November/034664.ht...
Well I wanted a meeting to be held and we were working on testing and trying to assing all the raised problems in order to provide you with more technical details. Expect another message from us soon.
A meeting may be helpful but is unlikely to resolve much without further testing and detailed discussion. Some have suggested that Koha code is at fault for some reported problems with Zebra. I could use my own well tested Z39.50 client to test some issues independently from Koha if there is a Zebra server with problematic records and configuration which I can access for that purpose. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
[Correction.] Discussions of programming development issues are more appropriate for the koha-devel mailing list. I encourage people to subscribe to that list. The programming development issue spilled over on to this list as part of a discussion of development management which is more than merely a programming development issue. Correction to my earlier reply inline: On Mon, November 22, 2010 06:56, Thomas Dukleth wrote: [...]
On Sat, November 20, 2010 04:49, LAURENT Henri-Damien wrote:
Le 19/11/2010 22:41, Thomas Dukleth a écrit :
[...]
4. SIMPLESERVER.
Same for the Z3950 server which we wrote a wrapper using Net::Z3950::SimpleServer. This would allow ppl to expose their collection as a Z3950 server.
Net::Z39.50::SimpleServer has been on my list as one option which would need improvement to have features sufficiently comparable to Zebra as a Z39.50 Server. 'Simple' may be taken to mean that supporting complexity is an exercise left to the programmer using the tool. Implementations of SimpleServer generally only support use attributes because of the complexity of managing more. Below, Henri-Damien attests to the difficulties of parsing PQF reliably. SimpleServer does not support SRU. The documentation for SimpleServer is less complete than Zebra documentation. We also have much greater working knowledge of Zebra.
I will enquire with IndexData about what options there might be for adding SRU support to SimpleServer.
I try to be especially careful about being accurate. I easily falsified my claim that SimpleServer does not support SRU without any need to do anything more than examine the documentation more completely. My knowledge that Simple Server had not had SRU support at an important point in the past led me to be less careful than I almost always am before I posted my message. I did check before posting but I did not check well enough while giving my attention to what SimpleServer provides for managing PQF. Even with SRU support the basic problem of SimpleServer being simple remains. SimpleServer requires the implementing programmer to do much work in managing the complexity of PQF. The extent to which SimpleServer provides management of PQF merely changes one data model into another data model without necessarily reducing the complexity. Henri-Damien Laurent had thought it prudent to avoid such complexity when he considered undertaking the simpler task of merely writing PQF queries where Koha acts as a Z39.50 client. Writing PQF for a Z39.50 client is much easier than parsing PQF for a Z39.50 server. Something as simple as distinguishing a list of words to be matched from a phrase to be matched for SimpleServer requires the programmer to manage the complexity of PQF. Zebra takes care of the complexity of parsing PQF for us automatically where we only need to bother about using the configuration files appropriately. Zebra has some problems which would cost something to fix. With an appropriate investment of resources, SimpleServer could be a comparable alternative to Zebra as a Z39.50/SRU server for Koha when using Solr/Lucene for local indexing. As SimpleServer is written in Perl, we may consider that SimpleServer is a better long term option for a Z39.50/SRU server in Perl based Koha than C based Zebra when using Solr/Lucene. There are not any no cost options for replacing Zebra as a Z39.50/SRU server for Koha with a sufficiently comparable feature set when using Solr/Lucene for local indexing. Zebra has a very large feature set as a Z39.50/SRU server which we should not give up easily. The features may be overlooked by most people because Zebra is not nearly as well configured by default in Koha as it could be. Each of the options has its own advantages and disadvantages. We need to understand the details well and give appropriate weight to the various factors. I agree that it would be much easier to maintain one record indexing system at a high level than two and that factor should be weighted appropriately.
5. PREFIX QUERY FORMAT.
As I have stated previously, C4::Search ought to be rewritten in future using prefix query format (PQF) as the native language for Z39.50.
Well, Rewriting the whole Search With PQF would not be handy in many aspects. I have thought about that many times. And using PQF still appears to me not to be the solution. a) It is really a pain to maintain and analyse. b) Whenever you need some more feature in your search, you have to add some more qualifiers, and therefore provide a robust parser.
I agree that analysing PQF connectors is tricky in comparison to CCL connectors which Yaz converts to PQF. In my own work independent of Koha, I overcame difficulties by having the user interface display the PQF query which my code would generate.
I have code for writing PQF query sets which I had started in 2005 using PHP Yaz before Net::Z3950::ZOOM was available for Perl. My code supports the complete and I mean complete Bib-1 attribute set. I could port the code to Perl with a little effort, although, it would still need some work for more extensibility of the user controlled term sets.
Queries built using PQF can be tested by building the same query in CCL and sending it to Yaz for conversion to PQF as a comparison.
Writing a PQF parser to interpret incoming PQF queries for SimpleServer would be perhaps an order of magnitude more complex.
Continuing to support Common Command Language (CCL) is trivial because Yaz translates CCL to PQF as it does now for Koha.
We may need CCL support to work most effectively with CCL based Pazpar2. Basic functionality in Pazpar2 converts CCL to whatever query language is appropriate for each of configured target server. Pazpar2 documentation contains some incomplete descriptions of PQF options. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
participants (16)
-
Chris Cormack -
Chris Nighswonger -
david＠lang.hm -
Irma Birchall -
Joann Ransom -
LAURENT Henri-Damien -
Lenora Oftedahl -
Liz Rea -
Lori Bowen Ayre -
Magnus Enger -
MJ Ray -
Nicholas S. Rosasco -
Paul Poulain -
Thomas Dukleth -
Wagner, Jane -
Zeno Tajoli